ENUM Working Group L. Conroy Internet Draft Roke Manor Research INFORMATIONAL Expires: September 2004 February 2004 ENUM Implementation Issues and Experiences <draft-conroy-enum-experiences-01.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 . Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. 1. Introduction The ENUM protocol  and the Dynamic Delegation Discovery System (DDDS)     are defined elsewhere, and those documents alone form the normative definition of the ENUM system. Unfortunately, this document cannot provide an overview of the specifications, so the reader is assumed to have read and understood the complete set of normative documents. From experience of creating ENUM data and of developing client systems to process that data it is apparent that there are some subtleties in the specifications that have led to different interpretations; in addition there are common syntactic mistakes in data currently "out there" on the Internet. This document is intended to help others avoid the potential pitfalls in interpreting the set of documents that specify the protocol. It also reports the kind of data they will "find" and so how to process the intent of the publisher of that ENUM data, regardless of the syntax used. As such, it is in keeping with the principle evinced in RFC791 that "In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior". Note that the DDDS systems is intricate and so in some places there are several potential interpretations of the specifications. This document proposes a suggested interpretation for some of these points, but they are just that; suggestions. This draft covers 11 issues; there are undoubtedly others, and developers are requested to raise any others they find on the IETF ENUM Working group's mailing list and/or by mail to the author (see later for contact information). Note that the author is not aware of any IPR issues that are involved in the suggestions made in this document. 2. ENUM Implementation Issues 2.1. Case Sensitivity From exploration of the ENUM records that are currently published, it's obvious that there are differences of style in the case used for NAPTRs. RFC2916bis describes a Dynamic Delegation Discovery System "Application" and as such inherits the DDDS specification of UTF-8 as the character set for fields. Case sensitivity is thus a non-trivial procedure. The specifications are silent (but see next section) on whether or not case sensitivity is expected. This can be interpreted in one of two ways, so the following is a suggestion only. It seems that, where used for ENUM (i.e. as specified in RFC2916bis), the flag field, the services field, and the matching part of the regexp field are case insensitive. As DNS is case-insensitive in its domain names, the replacement field will be, by definition, also case insensitive. With the exception of any "back references", the explicit text in the subsequent part of the regexp field may be case-sensitive, dependent on the URI produced. Thus, we propose that any ENUM client implementation treat ENUM field contents as case-insensitive, EXCEPT for the subsequent part of the regexp field, the case of which should be left untouched. 2.2. Regular Expression Case Insensitivity Flag For those readers who follow the admonishment to read all of the specification documents, there is a paragraph in section 3.2 of RFC3402 that states that, if the regular expression is followed by an 'i' flag, the Extended Regular Expression matching SHALL be performed in a case- insensitive manner. This is part of the general DDDS specification, and so is "inherited" by ENUM with no further comment. However, ENUM specifies that the Application Unique String (against which the Extended Regular Expression is matched) is an E.164 number stripped of all but the digits and an initial '+' character. Thus, it is hard to see how case sensitivity would ever matter, and so, for the specific case of regular expression matching in ENUM, this flag is inactive. The next sentence in RFC3402 states that any backref replacements MAY be normalized to lower case when the "i" flag is given. Again, this is part of the general DDDS specification. Considering that any back reference in ENUM will be constructed from either digits or a '+' character, this option does not have any impact. In short, the 'i' flag when used in a NAPTR for ENUM is ineffective, and can safely be ignored. However, from observation, some folk have put this flag after the regular expression in their NAPTRs, a number of clients have not expected to see this, and have subsequently failed to process those NAPTRs. There are two proposals that flow from this; don't put this flag into NAPTR records, as there are a number of clients "out there" that will reject the NAPTR. Equally, clients should expect the "closing" delimiter for a Regular Expression field to be either the last character in the field, OR the penultimate one. 2.3. enumservice Syntax Although the work has been completed for some time, RFC2916bis has yet to be published as an RFC. Thus the only IETF RFC specifying ENUM remains the original RFC2916. This specified a more limited syntax to declare an enumservice to which a NAPTR was tied. Most important, it specified that the DDDS Application tag for ENUM, 'E2U', was at the right hand end of the services field. In the new syntax is defined in RFC2916bis this same DDDS Application tag is at the start (left) of the services field. There are NAPTRs "published" at present that follow the old syntax, and there are also NAPTRs that follow the new syntax. Thus there is a quandary for ENUM client developers that can, in practice, only be resolved by supporting both syntactic forms. One possible solution to handling these two differing forms in an ENUM client is to treat the required '+' character as a simple list separator, to treat the 'E2U' token as if it were an enumservice token, and then discard it before processing, having first checked that it exists exactly once in the list of tokens so produced. Equally, there is a quandary for developers of those systems that create and store ENUM NAPTRs; to create NAPTRs according to the not-yet-obsolete syntax of RFC2916, or the not-quite-RFC syntax of RFC2916bis. Whilst the IETF has discouraged implementation to Internet Drafts, the intent and the status of this draft means that its use for creation of NAPTRs seems to be appropriate. Similarly, RFC2916bis is a replacement for the "old" RFC2916, and so fresh development of systems that create NAPTRs to the old syntax is conversely inappropriate. In summary, clients should support both old and new syntactic forms, whilst NAPTR creations systems should create NAPTRs only to the new syntax. This seems best to embody the aim of "being liberal with what you accept, whilst being conservative with what you send". There is one further implication of the need for ENUM clients to process NAPTRs in both syntactic forms. In principle, it would be possible to define an enumservice with the token 'E2U', as it would be distinguishable from the ENUM DDDS Application tag by position within the field. However, given the long gestation of the replacement RFC, it is strongly recommended that no-one propose such an enumservice, as it is likely to cause major problems for clients that are forced to handle both forms. 2.4. Order of evaluation of enumservices RFC2916bis has introduced the option of specifying more than one enumservice that is applicable for a NAPTR. This has some benefits in terms of compactness, as a single NAPTR can be produced which is the equivalent of a set of NAPTRs all of which resolve to the same URI. However, in the future there may be situations in which the order in which multiple enumservices are evaluated matters. Thus is a client to start at the right hand end and work towards the left, or start at the left and work to the right? Either is valid, but we (arbitrarily) choose to evaluate from left to right within the enumservices field. Equally, an ENUM creation system could place enumservices applicable for a NAPTR into any order. By definition, this combined NAPTR is equivalent to a set of NAPTRs each member of which has an identical order field value, identical regular expression field content, and one of the list of enumservices as its service field content. The difference lies in the fact that each of the constituent set of individual NAPTRs should have a different preference/priority field value. By implication, there is an order to the set of NAPTRs as opposed to the otherwise equivalent combined NAPTR with multiple enumservices. As a choice, our ENUM creation system combines the individual enumservices in the order (from left to right) that reflects the preference/priorities of the constituent set of NAPTRs. Thus, the order of the enumservices in a combined NAPTR (taken from left to right) reflects a user preference. 2.5. NAPTRs with identical values in their order and preference fields Whilst it is not a valid configuration, there are sets of NAPTRs that have the same order value AND the same priority/preference value. Given that the goal is to process these if this can be done unambiguously, there are some choices. A client could process these in any arbitrary order - the implication is that NAPTRs with the same order and preference field values are of equivalent priority. However, some DNS systems produce their resource records in a determined order, and it IS possible that the "publisher" of this data was unaware that any intervening DNS system could re-order them when responding to requests. This seems to have been the case with several examples that were seen. Querying the authoritative DNS server always returned the same order of resource records, and a SIP entry was the first, followed by an email entry - an apparently intended order of NAPTR processing. Thus, given that there is no harm in doing so, we choose that our clients process the identical NAPTRs in the order in which they are received in a DNS response. 2.6. Non-final NAPTRs and Services Field processing RFC2916bis refines (with DDDS) the concept of non-final NAPTRs. These are NAPTRs with an empty flags field, an empty regular expression field, and a populated replacement field. It is, however, unclear whether or not the services field should be empty, and whether enumservice checking should be done (at least to see whether or not this NAPTR holds the ENUM application tag 'E2U' and so should be considered in ENUM processing). This of course has implications both on the expected behaviour of ENUM clients and on the NAPTRs that ENUM creation systems should generate. It appears from the thrust of RFC3402 and 3402 that a non-final NAPTR is intended as a generic tool (not tied to a particular DDDS Application), so it is suggested that ENUM creation systems generate such NAPTRs with an empty services field, and that ENUM clients ignore the field, regardless of whether or not it is empty. 2.7. Non-final loop detection A non-final NAPTR indicates that the search for matching NAPTRs for a given Application Unique String (constructed from an E.164 number) should continue with a query of another domain, that domain being defined in its replacement field. Of course, the domain at which the search continues may also include a non-final NAPTR. Thus, by misconfiguration, it is possible for there to be a "loop", in which a non-final NAPTR refers to a domain that has already been traversed in this search. This is an obvious security threat, and clients MUST be able to detect such a loop condition, however complex. This is not quite as simple as it seems. A strictly correct scheme would be to keep a record of each domain traversed during a query, and to check against this list any domain indicated in a non-final NAPTR processed during the search. However, this introduces both an increasing processing load on the client, and an indeterminate memory requirement. These two factors may be exploited by an attacker by "publishing" an appropriately long chain of non-final NAPTRs. A simpler alternative strategy for a client is to keep a count of the number of domain traversals during a search. This does not open either of the potential exploits, but it does mean that some arbitrary limit has to be chosen for the number of such traversals a client will allow during a search before it decides that a loop has been detected. There is a balance between the number of domain traversals that might reasonably be expected in an ENUM search, and the number of times that a client will loop before it detects this fact. We chose to limit the number of traversals to 5, as this seemed more than might reasonably be used when "publishing" a set of ENUM data for any telephone number. It does, of course, have an implication on ENUM creation systems - don't put more than 5 domain traversals into a chain for a given set of ENUM data, or clients will consider it to be a loop. 2.8. Non-final loop treatment As NAPTRs in a domain are processed in order based on the values in their order and priority/preference fields, it is possible that a non-final NAPTR domain traversal is taken before "lower" NAPTRs have been processed. If, subsequent to making this traversal, a loop is detected, then this branch in the search must be rejected. However, a client must make a choice on such detection. The choice taken will have an impact on client behaviour, and so, for testing purposes if for no other, it is convenient for a common choice to be made. The three choices that may be made are: The client could give up on the whole search, returning a failure indication to the system that initiated the ENUM search, or It could return to the NAPTR with a priority immediately lower than the non-final NAPTR that triggered the loop detection (i.e. in the domain that included the "bad" non-final NAPTR), or, where this is different, It might continue at the first domain queried for this telephone number's matching entries, rejecting all of the non-final traversals it had taken to get to the domain that held the "bad" non-final NAPTR. Each of these options has its merits, but we choose the second option. The reasoning was that it does not require any "memory" for domains that have been traversed and it makes the most optimistic assumption - that whilst there is an error in one (non-final) NAPTR, the others will be correct. Given the complexity of arranging non-final NAPTR traversals this seems to us to be the most reasonable approach. 2.9. Order evaluation across non-final domain traversal Some NAPTRs that are held in a domain may be inapplicable for a client; they may indicate an enumservice (and URI) that the client is not capable of using, even though it is a perfectly valid contact. Thus the client must continue its processing at the NAPTR with the next highest order and priority/preference field values. If there are no further NAPTRs to check, then the current search has failed. Where the NAPTRs within a current domain have been reached as a branch of the search resulting from a non-final NAPTR domain traversal, one would expect that this branch has failed and processing would continue at the next NAPTR "after" the non-final one that triggered the branch. However, it is possible for NAPTRs within that branch to have higher order field values than those of the domain from which that traversal started. The DDDS algorithm indicates that all NAPTRs with a lower order field value should be discarded. This might be taken to mean that the search has ended in failure, as all remaining NAPTRs have a lower value that one found (but ignored as inappropriate for the client). The intent of the standard might seem obvious, but such a strict interpretation was made by some developers, so it bears spelling out here. We chose to completely ignore any NAPTRs that were inappropriate for a client, meaning that processing continued in the previous domain with whatever was the order value for any remaining (non-discarded) NAPTRs. Any higher order field value detected in a domain branch that included no appropriate NAPTRs was ignored. 3. Security Issues This document does not specify any standard. It does however make some recommendations, and so the implications of following those suggestions have to be considered. In addition to these issues, those in the basic use of ENUM (and specified in the normative documents for this protocol) should be considered as well; this document does not negate those in any way. The suggestions in sections 2.1, 2.2, 2.3, 2.4, 2.5 and 2.6 do not appear to have any security considerations (either positive or negative). The suggestion in section 2.7 is a valid approach to a known security threat. It does not open an advantage to an attacker in client excess processing or memory usage. It does, however, mean that a client will traverse a "tight loop" of non-final NAPTRs in two domains 5 times before the client detects this as a loop; this does introduce a slightly higher processing load that would be provided using other methods, but avoids the risks they incur. The suggestions in section 2.8 is not thought to have any security impact over the normal use of ENUM; nor does that in section 2.9. 4. IANA Considerations This document is informational only, and does not include any IANA considerations other than the suggestion in section 2.3 that no-one should specify an enumservice with the identifying tag 'E2U'. 5. Acknowledgments I would like to thank the various development teams who have implemented ENUM (both creation systems and clients) and who have read the normative documents differently - without these differences it would have been harder for us all to develop robust clients and suitably conservative management systems. In particular, thanks to Richard Stastny for his hard work on a similar task  under the aegis of ETSI, and for supporting some of the ENUM implementations that exist today. Finally, thanks for the dedication of Michael Mealling in giving us such detailed DDDS specifications, without which the ENUM implementation effort would have had a less rigorous framework on which to build. 6. Normative References  P. Faltstrom, M. Mealling, draft-ietf-enum-rfc2916bis-07.txt, "The E.164 to URI DDDS Application (ENUM)", October 2003 - Work in Progress  M. Mealling, RFC 3401, "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", October 2002  M. Mealling, RFC 3402, "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", October 2002  M. Mealling, RFC 3403, "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", October 2002  M. Mealling, RFC 3404, "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", October 2002 Non-normative Reference:  ETSI TS 102 172, "Minimum Requirements for Interoperability of European ENUM Trials", February 2003 7. Author's Address Lawrence Conroy Roke Manor Research Old Salisbury Lane Romsey Hampshire SO51 0ZN United Kingdom email: email@example.com URI: http://www.sienum.co.uk 8. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.