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.