[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-enum-experiences

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 [1].

    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 [1] and the Dynamic Delegation Discovery System (DDDS)
    [2] [3] [4] [5] 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 [6] 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

[1]   P. Faltstrom, M. Mealling, draft-ietf-enum-rfc2916bis-07.txt,
       "The E.164 to URI DDDS Application (ENUM)",
       October 2003 - Work in Progress

[2]   M. Mealling, RFC 3401,
       "Dynamic Delegation Discovery System (DDDS) Part One:
       The Comprehensive DDDS",
       October 2002

[3]   M. Mealling, RFC 3402,
       "Dynamic Delegation Discovery System (DDDS) Part Two:
       The Algorithm",
       October 2002

[4]  M. Mealling, RFC 3403,
       "Dynamic Delegation Discovery System (DDDS) Part Three:
       The Domain Name System (DNS) Database",
       October 2002

[5]   M. Mealling, RFC 3404,
       "Dynamic Delegation Discovery System (DDDS) Part Four:
       The Uniform Resource Identifiers (URI)",
       October 2002

Non-normative Reference:

[6]  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: lwc@roke.co.uk
    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.


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/