VALUE X500 OPERATIONAL INTERWORKING FORUM AND PLATFORM TECHNICAL QUARTERLY REPORTS INRIA 01-04-93 30-06-93 01-07-93 30-09-93 PLAN ==== 1. Introduction 2. DIT distribution and knowledge model 2.1 Distribution of the immediate subordinate entries of an entry 2.2 Setting references pointing to many immediately subordinate entries 2.3 Efficiency of the one-level search 2.4 Cross Referencing 3. Chained operations 3.1 Defect regarding the search type modification 3.2 DSA behaviour - Evaluation phase - Multiple object evaluation 4. Client algorithms 5. Aliases 5.1 Alias dereferencing and search type modification 5.2 Option : searchAlias 5.3 Alias at a non-leaf level 6. Miscellaneous problems 6.1 Bind / Session connect 6.2 ASN1 Error 6.3 Syntax error 6.4 Virtual entry 7. Conclusion - Further investigations 1. INTRODUCTION ============== The Operational Interworking Forum and Platform (OIFP) is part of the VALUE PARADISE X500 Project which is an initiative of the European Commission to continue the provision of some essential X500 services. Initial experiences have demonstrated that different implementations, all conformant to the same standard may fail to provide acceptable operational interworking under specific data or knowledge distribution configurations. For this reason, it was decided to provide the DSA managers and the developers/suppliers of X500 Directory software with the OIFP service. The main goal is to identify and discuss interworking problems, not to give a label to implementations. In order not to make any positive or negative publicity, the name of the implementations is not disclosed. This technical report presents the main issues that have been studied up to now in the framework of the OIFP activity. This report is intended for people who have a general knowledge of X.500, it is not aimed at X.500 expert. If you require any further information regarding this report or the OIFP activity, you can contact : Name : Paul-Andre Pays Bruno Koechlin Telephone: +33 1 39 63 54 58 +33 1 39 63 57 36 Email: oifp@pamir.inria.fr S=OIFP; OU=pamir; O=INRIA; P=INRIA; A=ATLAS; C=FR Address: INRIA Institut National de Recherche en Informatique et Automatique B.P. 105 / 78153 Le Chesnay Cedex / France Fax : +33 1 39 63 53 30 / Twx: 697033 F We have classified the problems encountered in the following categories : - DIT distribution and knowledge model - chained operations - aliases - client algorithms - miscellaneous problems We also propose a severity level associated with the type of problem. - PD : preventing operational deployement - VS : very serious - LC : may severely limit the capabilities or manageability 2. DIT DISTRIBUTION AND KNOWLEDGE MODEL ======================================= 2.1 Distribution of the immediate subordinate entries of an entry ----------------------------------------------------------------- Introduction : -------------- The standard allows you to distribute all the immediate subordinate entries of an entry in different DSAs. For instance the two entries C=FR; O=CNRS and C=FR; O=INRIA which are both immediate subordinate entries of C=FR can be held by two different DSAs. This is not possible with all X500 implementations. Description of the problem : ---------------------------- In one X500 implementation all the subordinate entries must be in the same DSA : For instance the entries C=FR; O=CNRS and C=FR; O=INRIA must be held by the same DSA. These two organizations may wish to have their own entry held in their own DSA rather than have it held by an external service provider which they will have to contact if they want to update their entry. . If this implementation is connected to another DSA which has distributed immediate subordinate entries in different DSAs, this type of DIT distribution cannot be represented with the type of knowledge references available to the DSA manager. You can get round this problem partly by registering copies of the distributed subordinate entries but this may lead to having either 2 originals or only 2 copies without original of the same entry in the DIT. Cause of the problem -------------------- The X500 standard defines two types of subordinate references : - the (specific) subordinate reference - the non-specific subordinate reference In this implementation the subordinate reference is not implemented although it is mandatory in the standard and a special case of the non-specific subordinate reference is implemented : A subordinate reference is composed of : - a relative distinguished name - an Access Point of a DSA The entry named by the relative distinguished name is held by the DSA whose Access Point is mentioned. Given that my DSA holds the entry C=FR, a subordinate reference, related to C=FR, composed of : O=CNRS Access point to the "CNRS" DSA means that C=FR; O=CNRS is held by the "CNRS" DSA A Non-Specific subordinate reference is related to one entry and consists of the Access Point of a DSA which holds one or more immediately subordinate naming contexts of the entry. For instance a Non-Specific subordinate reference, related to C=FR; O=CNRS composed of Access point to the "UREC" DSA means that the "UREC" DSA holds one or more subordinate naming contexts under C=FR; O=CNRS. For instance C=FR; O=INRIA; OU=UREC may be held by the "UREC" DSA. This implementation provides only one "subordinate" reference which is a special case of the non-specific subordinate reference. This "subordinate" reference is related to one entry and consists of the Access Point of a DSA which holds all the immediately subordinate naming contexts of the entry. For instance this reference, related to C=FR; O=CNRS composed of Access point to the "UREC" DSA means that the "UREC" DSA holds all the subordinate entries of C=FR; O=CNRS. For example C=FR; O=INRIA; OU=UREC is held by the "UREC" DSA. As all the subordinate entries of C=FR; O=CNRS are supposed to be held by the "UREC" DSA, they cannot be distributed among different DSAs. Severity Level: PD !!!!!!!!!!!!!!!!! 2.2 Setting references pointing to many immediately subordinate entries ----------------------------------------------------------------------- Introduction : -------------- Bear in mind the definition of the subordinate and non-specific subordinate references (paragraph 2.1). Suppose that an entry is held by a superior DSA and that this entry has many subordinate entries held by another subordinate DSA. How can this knowledge be represented in the superior DSA ? Description of the problem : ---------------------------- In an implementation you must set in the superior DSA a subordinate reference for each subordinate entry registered in the subordinate DSA. This is not a serious problem if you have only a few subordinate entries but management difficulties arise if you have a large number : Each time the manager of the subordinate DSA adds or deletes an entry, he must inform the manager of the superior DSA to add or delete the corresponding reference. This a major inconvenience since you lose a part of the benefits of a distributed administration of the entries. Cause of the problem : ---------------------- The knowledge of the subordinate entries can be represented in the superior DSA by a non-specific subordinate reference but this type of reference is not available to the DSA manager in this implementation. Even if the non-specific subordinate reference is optional in the X500 standard, this example shows that this type of reference can be useful. Severity Level: LC 2.3 Efficiency of the oneLevel search ------------------------------------- Introduction : -------------- The X500 standard defines 3 types of search : 1 baseObject The search is applied to the base object 2 oneLevel The search is applied to the immediate subordinates of the base object only. 3 wholeSubtree The search is applied to the base object and all its subordinates (not only immediate subordinates) We can assume that all kinds of search wholeSubtree will not be allowed by DSA managers to avoid overloading the X500 infrastructure. For instance a search wholesubtree, baseObject=root, filter="favoriteDrink = tea" is unrealistic in a wide scale directory. For this reason "evolved" DUA algorithms use the oneLevel search operation to go down in the DIT level by level, before performing a wholeSubtree search. The efficiency of the oneLevel search depends on the DIT distribution. Description of the problem : ---------------------------- A oneLevel search is very efficient if all the subordinates are in the same DSA. Of course with implementations which cannot distribute the immediate subordinate entries you always have high performances. But if the immediate subordinates are distributed among several DSAs and no partial subtree replication is being used for such entries each oneLevel search must be distributed to all the subordinate DSAs. entry i.1 held by DSA i | ------------------------------ | | | entry i+1.1 entry i+1.2 entry i+1.n all held by DSA i+i a oneLevel search baseObject=entry i.1 will be efficient, all the i+i.j entries are held by DSA i+i entry i.1 held by DSA i | ----------------------------------------- | | | entry i+1.1 entry i+1.2 entry i+1.n held by DSA i+1.1 held by DSA i+1.2 held by DSA i+1.n a oneLevel search baseObject=entry i.1 will be less efficient, the search must be distributed to all the i+i.j DSAs Cause of the problem : ---------------------- We cannot assume that all the subordinates of an entry can be held in the same DSA. For instance, under a country, organizations may wish to hold their own entry. In this case, to enhance the performance of the oneLevel search, we could register a copy of the i+1.j entries in the DSA i and the original entries would stay in the i+i.j DSAs : entry i.1 held by DSA i | ----------------------------------------- | | | copy entry i+1.1 entry i+1.2 entry i+1.n held by DSA i original entry i+1.1 entry i+1.2 entry i+1.n held by DSA i+1.1 held by DSA i+1.2 held by DSA i+1.n This solution requires a replication mechanism that will be available with the 1992-1993 standard. As this protocole will not be operational in the short term other ways to achieve replication should be considered (out-of-band data transfer, extraction tools ...). Severity Level: PD 2.4 Cross Referencing --------------------- Introduction : -------------- This reference consists of : - Context prefix - The Access point of a DSA which has Administrative Authority for that naming context. This type of reference optimizes name resolution and allows an operation not to go up to the top of the DIT and down again to reach an object. For instance if a DSA is responsible for C=FR; O=INRIA and if this DSA receives many operations related to C=FR; O=CNRS; OU=UREC you can enhance the performance of the INRIA DSA by setting up a Cross Reference : - C=FR; O=CNRS; OU=UREC - "UREC" DSA Without this cross reference, the INRIA DSA would chain an operation related to C=FR; O=CNRS; OU=UREC to the DSA responsible for C=FR, the operation would then be chained to the DSAs responsible for C=FR; O=CNRS and C=FR; O=CNRS; OU=UREC. With this cross reference, the INRIA DSA would chain an operation related to C=FR; O=CNRS; OU=UREC directly to the DSA responsible for C=FR; O=CNRS; OU=UREC. Description of the problem : ---------------------------- In an implementation it is not possible to set a cross reference. Cause of the problem : ---------------------- The cross reference is not available to the DSA manager. Only the subordinate reference is available. Severity Level: VS 3. CHAINED OPERATIONS ===================== 3.1 Defect regarding the modification of the search type -------------------------------------------------------- Introduction : -------------- A chained operation contains the original DUA-supplied arguments and the chaining arguments. In certain circumstances the search type (subset component of the protocol) must be changed from OneLevel to baseObject when it is chained. Description of the problem : ---------------------------- If this modification takes place between two different X500 implementations the following inconveniences may occur : - no entry may be returned although entries should be returned - entries may be returned although they should not be returned. Cause of the problem : ---------------------- The search type is present in the orginal DUA-supplied arguments which must not be modified. This type is not in the chaining arguments which could be modified. A defect report has been issued : a new component has been added in the chaining arguments to make the modification of the search type possible. This new component "entryOnly" is also defined in the 1992 standard. If an implementation which has taken into account the defect report and uses the "entryOnly" component chains a search oneLevel, becoming a search baseObject, to an implementation which does not support this new component, the second implementation will interpret it as a search oneLevel instead of a search baseObject and a wrong result will be returned. This problem can only arise if an alias is dereferenced during the resolution of the name of an immediate subordinate of the targetObject. Severity Level: LC 3.2 DSA behaviour - Evaluation phase - Multiple object evaluation ------------------------------------------------------------------ Introduction : -------------- The standard has defined every directory operation as comprising three distinct phases : - the Name Resolution phase - the Evaluation phase - the Result Merging phase Name Resolution is the process of sequentially matching each RDN in a purported Name to an arc (or vertex) of the DIT, beginning logically at the Root and progressing downwards in the DIT. This phase can be distributed among several DSAs, at the end of this phase the targetObject must be located if it exists. The required operation is performed in the Evaluation Phase. The operation may involve a single entry or multiple entries. The latter case is much more complex since the multiple entries may be distributed in several DSAs. It is the case of the List and Search operations. The phase is then called the Multiple object evaluation phase. We have focused on the search operation, which is more useful and complex than the List operation, and have found several problems. Description of the problems : ----------------------------- We have distributed DIT subtrees between different implementations. Depending on the subtree, an implementation is in the position of the superior or subordinate DSA. We have met two major problems : - entries are not found - loops are induced Cause of the problems --------------------- During the Multiple-object evaluation, the following components must be updated to complete it properly : - targetObject - OperationProgress (nameResolutionPhase) These parameters are in the ChainingArguments component of the chained operation. Most problems are due to the fact that these components are not handled properly : - The baseObject cannot be modified, only the targetObject can be modified. We have found an implementation which modifies the baseObject. - The targetObject is not properly modified - If the targetObject is equal to the baseObject, it is optional. One implementation did not support the absence of the targetObject. - The nameResolutionPhase component of the OperationProgress component is not set properly, for instance it is not set to completed although the nameResolutionPhase was completed. The current conclusion is that we have too many conformance problems to go ahead with the assessment of this directory feature and are testing fixes and waiting for others. Severity Level: PD (Must be fixed asap by implementors) 4. CLIENT ALGORITHMS ==================== These comments are the results of observations made not only on the OIFP platforms but in the framework of the general PARADISE infrastruture. Clients use proprietary attributes or objects to perform requests. For instance one DUA implementation used a specific attribute to determine whether an object is a leaf or a non-leaf object in order to perform or not a oneLevel search based on this object. If your implementation did not handle this attribute, a useless search oneLevel was performed for every leaf object of your DIT, overloading your DSA. Suppose that a DSA holds C=FR; O=OIFP, that under OIFP we have 1000 leaf entries, and that this specific attribute was not used. If this DUA performed a oneLevel search, with baseObject C=FR; O=OIFP which failed, it collected all the entries under C=FR; O=OIFP and performed a search-oneLevel for each entry (1000). Each time this is observed we contact the people concerned to try to persuade them to enhance their algorithm to avoid such inconveniences. One implementation can use a specific attribute of an entry which indicates whether this entry is or not a leaf entry. Experience has shown that this feature is useful an efficient. In our opinion it should be integrated in the standard. We have also encountered clients algorithms, which do not use explicit proprietary objects or attributes, but rely heavily on a specific DSA behaviour or configuration, or on a specific distribution of the entries between the DSAs : Many DUAs do not follow the referrals returned by DSAs. It is assumed that the DSA they are connected to, follows the referrals for them and chain the operations. If this kind of DUA connects to a DSA which returns referrals it will not get any entry except the entries held by this DSA. A solution is badly needed . either clients have to be able to "follow" referrals . or they should only bind to a smart "Relay-DSA" which will be able (technicaly) and configured (management) for performing this on the behalf of the clients (DUA) 5. ALIASES ========== As regards aliases we have found bugs rather than problems resulting from difficulties in interpreting or implementing the standard. This is why we will not go into detail. 5.1 Alias dereferencing and modification of the type of the search ------------------------------------------------------------------ See the problem described in paragraph 3.1 5.2 Option : searchAlias ------------------------ Once the base Object has been located, a search operation tries to find all the entries which match the filter. The search can encounter aliases and dereference them or not depending on an option called "searchAlias" set by the originator of the request. In one implementation this option only works if the entry pointed by the the alias is held by the same DSA. If an alias points to an entry outside the naming contexts of the DSA, it is not dereferenced. If C=FR; O=OIFP-1; OU=ALI; CN=ALI-1 is an alias pointing to C=FR; O=OIFP-1; OU=ALI; CN=POINTED-1 and if these two entries are held by the same DSA the alias is dereferenced. If C=FR; O=OIFP-1; OU=ALI; CN=ALI-1 is an alias pointing to C=FR; O=OIFP-2; OU=ALI; CN=POINTED-1 and if these two entries are held by two DSAs the alias is not dereferenced. 5.3 Alias at a non-leaf level ----------------------------- An alias can point to a non-leaf object. In one implementation this kind of alias is not dereferenced properly, the DN is truncated : If C=FR; O=OIFP-1; OU=ALI is an alias pointing to C=FR; O=OIFP-2; OU=POINTED if the entry C=FR; O=OIFP-1; OU=ALI; CN=ALI-1 is dereferenced the result should be C=FR; O=OIFP-2; OU=POINTED; CN=ALI-1. and it is C=FR; O=OIFP-2; OU=POINTED CN=ALI-1 is lost. 6. MISCELLANEOUS PROBLEMS ========================= The problems mentioned below are bugs rather than problems resulting from difficulties in interpreting or implementing the standard. This is why we will not go into detail. 6.1 Bind / Session connect -------------------------- The BIND between two implementations failed. One implementation does not send the optional Connect Accept Item in a session connect. In that case the recipient must use the default value of the version number and it did not. 6.2 ASN1 Error -------------- We met one ASN1 error when an implementation was chaining a result, the oid of an attribute was deleted. 6.3 Syntax error ---------------- One implementation sent a country code using a T.61 string instead of a printable string. 6.4 Virtual entry ----------------- One implementation kept for its internal use virtual entries related to the RDNs of the context prefix. Read and search operations did (and do) not return these entries (which is right) whereas the list operation returned them (which is wrong). If the DSA held C=FR; O=OIFP and not C=FR : The operation list "root" returned C=FR The operation read C=FR returned "Name Error : noSuchObject" 7. CONCLUSION - FURTHER INVESTIGATIONS ======================================= This study has already brought to light several problems. In our opinion, the main ones regard the knowledge model and the operations distribution. To progress, we propose two study two new issues : - Loop detection : We have already encountered an undetected loop between two DSAs and the problem seems even more serious when a DUA is involved. - Referrals : In the Paraside infrastructure most of the DSAs are configured so as to chain operations. In a wide scale infrastructure, at least the top level DSAs will no longer chain but will return referrals. It is very important to experiment this mode of operation as soon as possible. The first tests have already shown many problems. Taking current implementations into account, until these problems have been satisfactory resolved we cannot foresee how a heterogeneous directory could provide a sufficiently high quality of service. In fact, with the products available as of writing, these problems are completely preventing any production quality service deployment. What exists and is being deployed in Paradise is nearly a single implementation infrastructure with only a few identified exceptions. We feel it is our responsibility to advise against any further deployment until at least - the most severe problems presented in this report have been fixed. - products taking into account these problems are available and deployed. The productive relationships that exist today with the major suppliers allow us to be optimistic, as they have all undertaken to find solutions and deliver better interworking products. Anyhow, whatever the efforts and goodwill, we learned that the should really wait for these new versions and check the effective interworking before we can claim with confidence that X.500 exists and is alive and operational.