VALUE X500 OPERATIONAL INTERWORKING FORUM AND PLATFORM TECHNICAL QUARTERLY REPORT INRIA 01-10-93 31-12-93 Version : 1.0 PLAN ==== 1. Introduction 2. Name Resolution 2.1 State of the OperationProgress component issue 2.2 Control of the Name Resolution / Relay-DSA 3. Subordinate Reference / Non specific subordinate Reference 4. DSA referral / Result with Continuation References 4.1 A specific case 4.2 General considerations 5. Partial result / Limit Problem 6. Encoding Error 6.1 Unbind 6.2 NameError 6.3 DSAReferral 6.4 PSAP RFC-1277 7. Conclusion 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. Three different implementations have been connected. In order not to make any positive or negative publicity, the name of the implementations is not disclosed. Initially only interworking problems were to be addressed. Given that several conformance problems have been encountered so far, it has been decided to take them into account. Nevertheless the general approach has not been changed, we do not check each protocol data unit systematically but try to make interwork different implementations in various contexts. This technical report presents the main problems that were encountered during the 10/93 - 12/93 period. Sixteen reports were issued. If you require any further information regarding this report 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 2. NAME RESOLUTION =================== 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 distributed DIT subtrees between different implementations. Depending on the subtree, an implementation is in the position of the superior or subordinate DSA. Problems have been encountered in the Name Resolution and Evaluation phase. 2.1 Set of the operation progress component ------------------------------------------- Description of the problems : ----------------------------- We met two major problems : - entries are not found - loops are induced Cause of the problems --------------------- Most problems are due to the fact that the operationProgress component is not handled properly : - Bugs and non conformance to the standards have been identified - Problems are also due to the knowledge model of the different implementations, we will focus on this issue in the next phase of the project when main bugs and non conformance problems are to be solved. 2.2 Control of the Name Resolution / Relay-DSA ---------------------------------------------- Introduction : -------------- The standard specifies that, as soon as an operation is in the "proceeding" state, when this operation is chained by a DSA the name resolution must progress in the DSA, which means that at least one new RDN of the DN must be resolved. If not, an error must be returned. One implementation did not respect this recommendation. Description of the problems : ----------------------------- In the present case, this was a bug which led to continuing the name resolution when it should have have been stopped. This can - induce a loop or - make a DIT inconsistency detected a bit too late or - make return a service Error when it is only a non existing object. On the other hand, applying the standard makes using what we have called a "relay DSA" impossible. A relay DSA is a DSA which acts as a relay to/from a domain, it must have references pointing to the internal DSAs of this domain, (these internal DSAs are not directly connected to the whole X500 infrastructure) and enough references pointing towards the whole X500 infrastructure to provide the internal DSAs with the external connectivy they require. A relay DSA can contain only these references and no data. Customers may need "relay" servers for at least 3 main reasons : 1. All the different DSAs may not be fully connected to all the networks. For instance, in our community we have DSAs connected only through IP and others only through X25. 2. For access control reasons DSAs (or the network equipment they are connected to) may accept calls coming only from a specific list of network addresses. 3. For X500 interworking reasons DSA managers may wish to dialog only with one specific DSA and not to have to be faced with several different implementations spread throughout the world. The following configuration is not allowed by the standard because the "relay" DSA would not be able to make the resolution of the name C=FR; O=OIFP progress : --------------------------------------------- | "FR" DSA which | | - holds the C=FR entry | | - contains a subordinate reference for | | O=OIFP pointing to the "relay" DSA | --------------------------------------------- | | --------------------------------------------- | "relay" DSA which | | - holds no entry | | - contains a subordinate reference for | | O=OIFP pointing to "relay" DSA | | - contains a superior reference for | | C=FR pointing to the "FR" DSA | --------------------------------------------- | | --------------------------------------------- | "OIFP" DSA which | | - holds at least the O=OIFP entry | | - contains at least one superior | | reference for C=FR pointing to the | | "relay" DSA | --------------------------------------------- To provide the relay service, a DSA implementation must be modified so that it does not check that the name resolution progresses when it acts as a relay for one of its relayed customer. The problem of the trace information is a bit more difficult : If the relay DSA does not trace, it will work but the loop and problem detection will be more difficult. If the DSA traces, since it does not make the name resolution progress, another DSA which checks the trace information may consider that the status of the operation is still the same and that a loop occurs. One way to get around this problem is to consider that a loop occurs only if an operation is in the same status twice in the same DSA. 3. SUBORDINATE REFERENCE / NON SPECIFIC SUBORDINATE REFERENCE ============================================================= Introduction ------------ Paragraph 2.1 of the first OIFP technical report dealt with the type of the reference used by an implementation : this product considers the reference it uses as a subordinate reference, we argued that it was not a subordinate reference but a specific type of non-specific subordinate reference which does not make it possible to distribute the immediate subordinate entries of an entry among different DSAs. Unfortunately this also has consequences on an operation processing. Description of the problem : ---------------------------- If a user performs an operation on a non existing object, which is perfectly valid, an error should be returned to the user mentioning that this object does not exist. Sometimes this triggers an alarm on a DSA : "service Error, invalid reference" which means that the X.500 infrastructure is not configured properly and that at least one DSA manager must modify the knowledge of his DSA. - the user gets a wrong error message - DSA managers are alerted for a non existing problem Cause of the problem : ---------------------- DIT : C=FR | O=OIFP held by DSA 1 | ----------------------------------------- | | | CN=OIFP-1 CN=OIFP-2 CN=OIFP-3 held by DSA 2 Query : read C=FR; O=OIFP; CN=OIFP-4 DSA 1 has a reference related to C=FR; O=OIFP pointing to DSA 2, which means in its model, that all the subordinates of C=FR; O=OIFP are held by DSA 2. When it chains the query "read C=FR; O=OIFP; CN=OIFP-4" to DSA 2 it considers and writes in the protocol data unit that it used a subordinate reference to chain the query to DSA 2. If DSA 2 has the standard understanding of the subordinate reference, it will consider that DSA 1 chained the operation to it because it has a subordinate reference related to C=FR; O=OIFP; CN=OIFP-4 pointing to DSA 2. Since C=FR; O=OIFP; CN=OIFP-4 does not exist, DSA 2 considers that an invalid reference has been set up in DSA 1 and raises the appropriate alarm. To solve this problem, DSA 1 should set the type of the reference used to non-specific subordinate instead of subordinate. 4. DSA REFERRAL / RESULT WITH CONTINUATION REFERENCES ===================================================== Introduction ------------- The standard defines two basic modes of DSA interaction to process the distributed operations, the "chaining" and the "referral" mode. The principle of the "referral" mode is the following : When a DSA considers that it cannot process a request and must forward it to another DSA (we will call it the target DSA) according to a knowledge reference, it does not forward the query to this target DSA but returns, to the originator of the request, the address of the target DSA with the status of the query in a continuation reference. A continuation reference can be returned in - a dsaReferral in DSP (or Referral in DAP) which is an Error PDU. This PDU can contain only one continuation reference or - a result which can contain in the partialOutComeQualifier component several continuation references. 4.1 A specific case ------------------ Description of the problem : ---------------------------- DIT : C=FR | O=OIFP held by DSA OIFP | ----------------------------------------- | | | CN=OIFP-1 CN=OIFP-2 CN=OIFP-3 held by DSA OIFP-1 held by DSA OIFP-2 held by DSA OIFP-3 DUA : bound to DSA OIFP-1 Query : search - whole subtree - baseObject = C=FR; O=OIFP - filter ... so that C=FR; O=OIFP; CN=OIFP-1 should be returned Result : no result is displayed by the DUA Cause of the problem -------------------- DSA OIFP-1 returns to the DUA a partial result containing - the entry C=FR; O=OIFP; CN=OIFP-1 - a continuation reference related to C=FR; O=OIFP pointing to DSA OIFP with operationProgress.nameResolutionPhase=proceeding This result is not consistent because, on the one hand it returns that C=FR; O=OIFP has not been resolved yet (nameResolutionPhase=proceeding), and on the other hand it returns C=FR; O=OIFP; CN=OIFP-1 which implies that C=FR; O=OIFP has been resolved. In this case if DSA OIFP-1 refuses to chain it should have returned a Referral with a continuation reference - related to C=FR; O=OIFP - pointing to DSA OIFP Nevertheless what should be returned is not always obvious and different implementations have different behaviours which may lead to parts of the DIT being unexplored because referrals are not understood or processed. The fact that the standard has flaws regarding references pointing to copies makes the situation more difficult. We will try to sum up this issue in the next paragraph. 4.2 General considerations Two issues will be dealt with : - when must a dsaReferral (or Referral) or a result with continuation references be returned ? - which directory agent (DUA / DSA) follows each type of reference ? As regards the first point the standard is not very explicit, you can often read "... a reference is returned ...". Nevertheless it describes the resolution of an operation as composed of 3 sequential phases : - the name resolution - the evaluation - the results merging From the description of these different phases we can conclude that no result can be returned as long as the name resolution is not completed. Consequently only dsaReferrals (or Referrals) can be returned during this phase. Since a dsaReferral (or a Referral) can contain only one continuation reference it is impossible to return for one object a reference pointing to its original entry and one or more references pointing to one or more copies of this object. This will be possible with the 93 standard. An interim solution could be to return a result containing no entry and a set of continuation references even if it "breaks" the standard as mentioned above. In this case the result will be consistent, unlike the example presented above, since no entry is returned, it does not imply that the name resolution was completed. This requires that directory agents (DSAs - DUAs) can follow the references contained in results irrespective of the status of the name resolution (completed or not). As regards the second point we have noticed that the different implementations of directory agents have different behaviours regarding the return of references : - DSAs and DUAs can follow dsaReferrals - all the DSAs and DUAs do not follow the continuation references contained in results In practice, a user seldom gets a complete result when a DSA returns a result containing continuation references. We have met different opinions, some consider that it is up to the DUA to follow this type of reference, the DSA should not do it, others consider that a DUA may not have the required connectivity to follow these references, it is up to the DSA bound to the DUA to follow these references. In our opinion, given that users may choose different configurations of their directory agents according to their requirements (type of applications, security level, network connectivity ...), if we want to have interworking applications, products should be configurable so as to follow or not both types of references. 5. PARTIAL RESULT / LIMIT PROBLEM ================================== Introduction ------------ The result of an operation can be partial. In this case it will contain a partialOutcomeQualifier component. We will focus on two components of the partialOutcomeQualifier component : - the limitProblem component which indicates if a time limit, size limit, administrative limit has been reached. - the unexplored component which is a set of continuation references which can be followed if the directory agent wishes to do further processing. Both components are optional. Description of the problem -------------------------- The continuation references returned by an implementation are never followed by another one. Cause of the problem -------------------- The implemention which returns the references always set the limitProblem component to timeLimit, the implementation which receives the references does not follow them if the limitProblem component is set. Of course the limitProblem must not always be set to timeLimit, however we have already noticed that all the implementations have not the same behaviour regarding the semantic of the limitProblem component. We suggest carrying out a further study related to this issue for the next period of the project. 6. ENCODING ERROR ========================= 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 UnBind ----------- The UnBind protocol data unit sent by an implementation was not encoded properly. It did not have a serious effect since the connection was closed but it raised an alarm in implementations which check the Unbind protocol data unit. 6.2 NameError -------------- An implementation did not encode this PDU properly. This had serious negative effects, specially on DUAs which use the matched component of the NameError report to determine how far the resolution name went. 6.3 DSAReferral --------------- The numeric identifier of the dsaReferral error which is used in DSP is 9, the numeric identifier of the Referral error which is used in DAP is 4. An implementation sent in DSP an error whose numeric identifier was 4. An implementation did not encode the dsaReferral properly. The PDU was rejected. Consequently it was impossible to use the referral mode. 6.4 PSAP - RFC-1277 ------------------- RFC-1277 was written in order to be able to use not only ISO addresses but also other types of addresses such as Internet addresses. RFC-1277 specifies a representation of different types of addresses. The three DSA implementations involved in the project support RFC-1277 but one did not respect the RFC. The other implemantations could not use the continuation references returned by this implementation. This prevented the referral mode from being used. 7. CONCLUSION - FURTHER INVESTIGATIONS ======================================= This second period of the project has confirmed the conclusion drawn at the end of the the first phase. We would like to stress that operation processing and distribution is a crucial issue (specially the name resolution and the multiple evaluation phases). Problems are mainly due to : - the complexity of the standard (algorithms are difficult to implement, "encouraging" bugs) - the large number of possible DIT organizations and operations which makes products difficult to validate - the different knowledge model of the implementations We have received new releases fixing bugs. The work done on references has allowed us to identify bugs which must be fixed if we want to study the way directory agents handle and follow references. Nevertheless initial tests have shown that different strategies and the lack of configuration possibilities regarding the way references are followed may lead to interworking problems. The next phase of the project will be dedicated to : - assessing the new releases and carrying out further studies regarding the name resolution and evaluation phases. - loop detection : this issue planned for this period was postponed, main problems related to the distribution of the operations must be fixed beforehand. We intend to do as soon as possible. - referrals : we would like to assess more closely how references are handled and specially the interpretation of the limitProblem component.