Subject: [Enum] On the issue of RFC 3761bis...

From: "Richard Shockey" <[email-masked]>
Date: Fri, 6 Jul 2007 11:44:55 -0400

Patrik Falstrom has requested that he be relieved of editing responsibility
for RFC 3761bis due to personal and professional time restraints.

The chairs have selected Scott Bradner as the new document editor. Scott as
many of you know was, in large measure, responsible for creating the ENUM
work group when he was AD for Transport and is intimately familiar with the
protocol and the many issues associated with it.

It is vitally important that we continue to provide Scott with input to
RFC3761bis so we can make progress towards submitting the document as a
Draft Standard as we progress towards winding down the ENUM WG.

We will be allotting some time in Chicago to a discussion of open issues. If
there are issues Scott needs to be aware of, now would be an appropriate
time to post them to the list.

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: lconroy <[email-masked]>
Date: Fri, 6 Jul 2007 21:21:39 +0100

Hi Richard,
   First issue is - on which version are we to comment?
AFAICT, draft-ietf-enum-3761bis-00.txt is no more.
Please can someone publish a current version?
(before Monday)?
atb,
   L

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 6 Jul 2007 17:18:45 -0400

Humm good point..that should have been part of the WG ID list.

Patrik can you resubmit 00 for the ID Editors?

-----Original Message-----
From: lconroy [mailto:[email-masked]] 
Sent: Friday, July 06, 2007 4:22 PM
To: Richard Shockey
Cc: 'enum'; 'Patrik Fältström'; 'Scott O. Bradner'
Subject: Re: [Enum] On the issue of RFC 3761bis...

Hi Richard,

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 7 Jul 2007 12:47:13 +0200

Yes, I will make sure a new version exists.

And, I will continue to work with Scott. It is "time for typing" that  
I do not have enough of. I read mail on this list, follow the  
discussions, etc etc...

    Patrik

---

From: lconroy <[email-masked]>
Date: Mon, 16 Jul 2007 01:39:27 +0100

Hi Patrik, folks,
  That's good to hear.

Given that we're now in ID shadow and this work is kinda urgent, does  
anyone
have a copy of 3761bis-00 that they could post to this list real  
soon, please?

all the best,
   Lawrence

On 7 Jul 2007, at 11:47, Patrik Fältström wrote:
> And, I will continue to work with Scott. It is "time for typing"  
> that I do not have enough of. I read mail on this list, follow the  
> discussions, etc etc...
>
>    Patrik
>

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 16 Jul 2007 09:21:44 +0200

Hi,
 
here it is
 
I would also suggest to format 01 better
 
Richard

________________________________

Von: lconroy [mailto:[email-masked]]
Gesendet: Mo 16.07.2007 02:39
An: Patrik Fältström
Cc: 'enum'; 'Scott O. Bradner'; Richard Shockey
Betreff: Re: [Enum] On the issue of RFC 3761bis...

Hi Patrik, folks,
  That's good to hear.

all the best,
   Lawrence

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 16 Jul 2007 09:40:06 +0200

On 16 jul 2007, at 02.39, lconroy wrote:

> Given that we're now in ID shadow and this work is kinda urgent,  
> does anyone

I tried to send a -01 that is exactly like -00 before the shadow, but  
had some mail problems (of course) so it might have arrived too late  
to the secretariat as it seems.

FWIW: You can find any I-D that has been created at a service I built  
for myself, but you can as well also know about it.

Go to http://stupid.domain.name/ietf/-enum-

And you get all I-Ds ever posted that I have found that include the  
string "enum" in the name. You can that way for example go to http:// 
stupid.domain.name/ietf/draft-ietf-enum and get all drafts ever  
posted in the ENUM wg, etc.

    Patrik

---

From: [email-masked] (Scott O. Bradner)
Date: Sun, 15 Jul 2007 20:43:20 -0400 (EDT)

> anyone
> have a copy of 3761bis-00 that they could post to this list real =20
> soon, please?

here is what I have in my archive

Scott

----

ENUM                                                        P. Faltstrom
Internet-Draft                                                     Cisco
Intended status: Standards Track                          September 2006
Expires: March 5, 2007

    The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
                Discovery System (DDDS) Application (ENUM)
                      draft-ietf-enum-3761bis-00.txt

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    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.

    This Internet-Draft will expire on March 5, 2007.

Copyright Notice

    Copyright (C) The Internet Society (2006).

Abstract

    This document discusses the use of the Domain Name System (DNS) for
    storage of E.164 [E164] numbers, and resolving those to URIs that  
can
    be used for (for example) call setup.  This include how DNS can be
    used for identifying available services connected to one E.164
    number.  It obsoletes RFC 3761 [RFC3761].

    This version of the document (00) is not more than the start of a

Faltstrom                 Expires March 5, 2007                 [Page 1]
Internet-Draft                    ENUM                    September 2006

    discussion for detailed changes.

Table of Contents

    1.   
Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
      1.1.   
Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
      1.2.  Use for these mechanisms for private dialing  
plans . . . .  3
      1.3.  Application of local  
policy  . . . . . . . . . . . . . . .  4
    2.  The ENUM Application  
Specifications  . . . . . . . . . . . . .  5
      2.1.  Application Unique  
String  . . . . . . . . . . . . . . . .  5
      2.2.  First Well Known  
Rule  . . . . . . . . . . . . . . . . . .  5
      2.3.  Expected  
Output  . . . . . . . . . . . . . . . . . . . . .  6
      2.4.  Valid  
Databases  . . . . . . . . . . . . . . . . . . . . .  6
        2.4.1.   
Flags  . . . . . . . . . . . . . . . . . . . . . . . .  7
        2.4.2.  Services  
Parameters  . . . . . . . . . . . . . . . . .  7
      2.5.  What constitutes an 'Enum  
Resolver'? . . . . . . . . . . .  8
    3.  Registration mechanism for  
Enumservices  . . . . . . . . . . .  8
      3.1.  Registration  
Requirements  . . . . . . . . . . . . . . . .  9
        3.1.1.  Functionality  
Requirement  . . . . . . . . . . . . . .  9
        3.1.2.  Naming  
requirement . . . . . . . . . . . . . . . . . .  9
        3.1.3.  Security  
requirement . . . . . . . . . . . . . . . . .  9
        3.1.4.  Publication  
Requirements . . . . . . . . . . . . . . . 10
      3.2.  Registration  
procedure . . . . . . . . . . . . . . . . . . 10
        3.2.1.  IANA  
Registration  . . . . . . . . . . . . . . . . . . 11
        3.2.2.  Registration  
Template  . . . . . . . . . . . . . . . . 11
    4.   
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
      4.1.   
Example  . . . . . . . . . . . . . . . . . . . . . . . . . 12
    5.  IANA  
Considerations  . . . . . . . . . . . . . . . . . . . . . 12
    6.  Security  
Considerations  . . . . . . . . . . . . . . . . . . . 13
      6.1.  DNS  
Security . . . . . . . . . . . . . . . . . . . . . . . 13
      6.2.  Caching  
Security . . . . . . . . . . . . . . . . . . . . . 15
      6.3.  Call Routing  
Security  . . . . . . . . . . . . . . . . . . 15
      6.4.  URI Resolution  
Security  . . . . . . . . . . . . . . . . . 15
    7.   
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
    8.  Changes in RFC 3761 from RFC  
2916  . . . . . . . . . . . . . . 16
    9.  Changes from RFC  
3761  . . . . . . . . . . . . . . . . . . . . 16
    10.  
References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
      10.1. Normative  
References . . . . . . . . . . . . . . . . . . . 16
      10.2. Non-normative  
references . . . . . . . . . . . . . . . . . 17
    Author's  
Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
    Intellectual Property and Copyright  
Statements . . . . . . . . . . 18

Faltstrom                 Expires March 5, 2007                 [Page 2]
Internet-Draft                    ENUM                    September 2006

1.  Introduction

    This document discusses the use of the Domain Name System (DNS) for
    storage of E.164 [E164] numbers, and resolving those to URIs that  
can
    be used for (for example) call setup.  This include how DNS can be
    used for identifying available services connected to one E.164
    number.  It obsoletes RFC 3761 [RFC3761].  It contains an Dynamic
    Delegation Discovery System (DDDS) Application specification as  
found
    in the document series specified in RFC 3401 [RFC3401].

    Through transformation of International Public Telecommunication
    Numbers in the international format [5], called within this document
    E.164 numbers, into DNS names and the use of existing DNS services
    like delegation through NS records and NAPTR records, one can  
look up
    what services are available for a specific E.164 in a decentralized
    way with distributed management of the different levels in the  
lookup
    process.

    The domain "e164.arpa" is being populated in order to provide the
    infrastructure in DNS for storage of E.164 numbers.  In order to
    facilitate distributed operations, this domain is divided into
    subdomains.  Holders of E.164 numbers which want to be listed in DNS
    should contact the appropriate zone administrator according to the
    policy which is attached to the zone.  One should start looking for
    this information by examining the SOA resource record associated  
with
    the zone, just like in normal DNS operations.

    Of course, as with other domains, policies for such listings will be
    controlled on a subdomain basis and may differ in different parts of
    the world.

1.1.  Terminology

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in BCP 14, RFC 2119 [1].

    All other capitalized terms are taken from the vocabulary found in
    the DDDS algorithm specification found in RFC 3403 [2].

1.2.  Use for these mechanisms for private dialing plans

    This document describes the operation of these mechanisms in the
    context of numbers allocated according to the ITU-T recommendation
    E.164.  The same mechanisms might be used for private dialing plans.
    If these mechanisms are re-used, the suffix used for the private
    dialing plan MUST NOT be e164.arpa, to avoid conflict with this
    specification.  Parties to the private dialing plan will need to  
know

Faltstrom                 Expires March 5, 2007                 [Page 3]
Internet-Draft                    ENUM                    September 2006

    the suffix used by their private dialing plan for correct operation
    of these mechanisms.  Further, the application unique string used
    SHOULD be the full number as specified, but without the leading '+',
    and such private use MUST NOT be called "ENUM".

1.3.  Application of local policy

    The Order field in the NAPTR record specifies in what order the DNS
    records are to be interpreted.  This is because DNS does not
    guarantee the order of records returned in the answer section of a
    DNS packet.  In most ENUM cases this isn't an issue because the
    typical regular expression will be '!^.*$!' since the first query
    often results in a terminal Rule.

    But there are other cases (non-terminal Rules) where two different
    Rules both match the given Application Unique String.  As each Rule
    is evaluated within the algorithm, one may match a more significant
    piece of the AUS than the other.  For example, by using a non-
    terminal NAPTR a given set of numbers is sent to some private-
    dialing-plan-specific zone.  Within that zone there are two Rules
    that state that if a match is for the entire exchange and the  
service
    is SIP related then the first, SIP-specific rule is used.  But the
    other Rule matches a longer piece of the AUS, specifying that for
    some other service (instant messaging) that the Rule denotes a
    departmental level service.  If the shorter matching Rule comes
    before the longer match, it can 'mask' the other rules.  Thus, the
    order in which each Rule is tested against the AUS is an important
    corner case that many DDDS applications take advantage of.

    In the case where the zone authority wishes to state that two Rules
    have the same effect or are identical in usage, then the Order for
    those records is set to the same value.  In that case, the  
Preference
    is used to specify a locally over-ridable suggestion by the zone
    authority that one Rule might simply be better than another for some
    reason.

    For ENUM this specifies where a client is allowed to apply local
    policy and where it is not.  The Order field in the NAPTR is a
    request from the holder of the E.164 number that the records be
    handled in a specific way.  The Preference field is merely a
    suggestion from that E.164 holder that one record might be better
    than another.  A client implementing ENUM MUST adhere to the Order
    field but can simply take the Preference value "on advisement" as
    part of a client context specific selection method.

Faltstrom                 Expires March 5, 2007                 [Page 4]
Internet-Draft                    ENUM                    September 2006

2.  The ENUM Application Specifications

    This template defines the ENUM DDDS Application according to the
    rules and requirements found in [7].  The DDDS database used by this
    Application is found in [2] which is the document that defines the
    NAPTR DNS Resource Record type.

    ENUM is only applicable for E.164 numbers.  ENUM compliant
    applications MUST only query DNS for what it believes is an E.164
    number.  Since there are numerous dialing plans which can change  
over
    time, it is probably impossible for a client application to have
    perfect knowledge about every valid and dialable E.164 number.
    Therefore a client application, doing everything within its power,
    can end up with what it thinks is a syntactically correct E.164
    number which in reality is not actually valid or dialable.  This
    implies that applications MAY send DNS queries when, for example, a
    user mistypes a number in a user interface.  Because of this, there
    is the risk that collisions between E.164 numbers and non-E.164
    numbers can occur.  To mitigate this risk, the E2U portion of the
    service field MUST NOT be used for non-E.164 numbers.

2.1.  Application Unique String

    The Application Unique String is a fully qualified E.164 number  
minus
    any non-digit characters except for the '+' character which appears
    at the beginning of the number.  The "+" is kept to provide a well
    understood anchor for the AUS in order to distinguish it from other
    telephone numbers that are not part of the E.164 namespace.

    For example, the E.164 number could start out as "+44-116-496-0348".
    To ensure that no syntactic sugar is allowed into the AUS, all non-
    digits except for "+" are removed, yielding "+441164960348".

2.2.  First Well Known Rule

    The First Well Known Rule for this Application is the identity rule.
    The output of this rule is the same as the input.  This is because
    the E.164 namespace and this Applications databases are organized in
    such a way that it is possible to go directly from the name to the
    smallest granularity of the namespace directly from the name itself.

    Take the previous example, the AUS is "+441164960348".  Applying the
    First Well Known Rule produces the exact same string,
    "+441164960348".

Faltstrom                 Expires March 5, 2007                 [Page 5]
Internet-Draft                    ENUM                    September 2006

2.3.  Expected Output

    The output of the last DDDS loop is a Uniform Resource Identifier in
    its absolute form according to the 'absoluteURI' production in the
    Collected ABNF found in RFC2396 [4].

2.4.  Valid Databases

    At present only one DDDS Database is specified for this Application.
    "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
    Database" (RFC 3403) [2] specifies a DDDS Database that uses the
    NAPTR DNS resource record to contain the rewrite rules.  The Keys  
for
    this database are encoded as domain-names.

    The output of the First Well Known Rule for the ENUM Application is
    the E.164 number minus all non-digit characters except for the  
+.  In
    order to convert this to a unique key in this Database the string is
    converted into a domain-name according to this algorithm:
    1.  Remove all characters with the exception of the digits.  For
        example, the First Well Known Rule produced the Key
        "+442079460148".  This step would simply remove the leading "+",
        producing "442079460148".
    2.  Put dots (".") between each digit.  Example:
        4.4.2.0.7.9.4.6.0.1.4.8
    3.  Reverse the order of the digits.  Example:
        8.4.1.0.6.4.9.7.0.2.4.4
    4.  Append the string ".e164.arpa" to the end.  Example:
        8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa

    This domain-name is used to request NAPTR records which may contain
    the end result or, if the flags field is blank, produces new keys in
    the form of domain-names from the DNS.

    Some nameserver implementations attempt to be intelligent about  
items
    that are inserted into the additional information section of a given
    DNS response.  For example, BIND will attempt to determine if it is
    authoritative for a domain whenever it encodes one into a  
packet.  If
    it is, then it will insert any A records it finds for that domain
    into the additional information section of the answer until the
    packet reaches the maximum length allowed.  It is therefore
    potentially useful for a client to check for this additional
    information.  It is also easy to contemplate an ENUM enhanced
    nameserver that understand the actual contents of the NAPTR records
    it is serving and inserts more appropriate information into the
    additional information section of the response.  Thus, DNS servers
    MAY interpret Flag values and use that information to include
    appropriate resource records in the Additional Information  
portion of
    the DNS packet.  Clients are encouraged to check for additional

Faltstrom                 Expires March 5, 2007                 [Page 6]
Internet-Draft                    ENUM                    September 2006

    information but are not required to do so.  See the Additional
    Information Processing section of RFC 3403 [2], Section 4.2 for more
    information on NAPTR records and the Additional Information section
    of a DNS response packet.

    The character set used to encode the substitution expression is UTF-
    8.  The allowed input characters are all those characters that are
    allowed anywhere in an E.164 number.  The characters allowed to  
be in
    a Key are those that are currently defined for DNS domain-names.

2.4.1.  Flags

    This Database contains a field that contains flags that signal when
    the DDDS algorithm has finished.  At this time two flags are  
defined,
    "U" and "D".  "U" is defined means that this Rule is the last one  
and
    that the output of the Rule is a URI [4].  See RFC 3404 [3].  "D"
    means the replacement field gives a domain name that should be used
    when looking up a URI resource record.  See
    draft-ietf-enum-uri-00.txt.

    If a client encounters a record with an unknown flag, it MUST ignore
    it and move to the next Rule.  This test takes precedence over any
    ordering since flags can control the interpretation placed on  
fields.

    A novel flag might change the interpretation of the regexp and/or
    replacement fields such that it is impossible to determine if a
    record matched a given target.

    If this flag is not present then this rule is non-terminal.  If a
    Rule is non-terminal then clients MUST use the Key produced by this
    Rewrite Rule as the new Key in the DDDS loop (i.e., causing the
    client to query for new NAPTR records at the domain-name that is the
    result of this Rule).

2.4.2.  Services Parameters

    Service Parameters for this Application take the following form and
    are found in the Service field of the NAPTR record.

                                                    service-field =  
"E2U" 1*(servicespec)
                                                    servicespec   =  
"+" enumservice
                                                    enumservice   =  
type 0*(subtypespec)
                                                    subtypespec   =  
":" subtype
                                                    type          =  
1*32(ALPHA / DIGIT)
                                                    subtype       =  
1*32(ALPHA / DIGIT)

Faltstrom                 Expires March 5, 2007                 [Page 7]
Internet-Draft                    ENUM                    September 2006

    In other words, a non-optional "E2U" (used to denote ENUM only
    Rewrite Rules in order to mitigate record collisions) followed by 1
    or more or more Enumservices which indicate what class of
    functionality a given end point offers.  Each Enumservice is
    indicated by an initial '+' character.

2.4.2.1.  ENUM Services

    Enumservice specifications contain the functional specification
    (i.e., what it can be used for), the valid protocols, and the URI
    schemes that may be returned.  Note that there is no implicit  
mapping
    between the textual string "type" or "subtype" in the grammar for  
the
    Enumservice and URI schemes or protocols.  The mapping, if any, must
    be made explicit in the specification for the Enumservice itself.  A
    registration of a specific Type also has to specify the Subtypes
    allowed.

    The only exception to the registration rule is for Types and  
Subtypes
    used for experimental purposes, and those are to start with the  
facet
    "X-".  These elements are unregistered, experimental, and should be
    used only with the active agreement of the parties exchanging them.

    The registration mechanism is specified in Section 3.

2.5.  What constitutes an 'Enum Resolver'?

    There has been some confusion over what exactly an ENUM Resolver
    returns and what relation that has to the 'Note 1' section in RFC
    3402.  On first reading it seems as though it might be possible for
    an ENUM Resolver to return two Rules.

    The ENUM algorithm always returns a single rule.  Specific
    applications may have application-specific knowledge or facilities
    that allow them to present multiple results or speed selection, but
    these should never change the operation of the algorithm.

3.  Registration mechanism for Enumservices

    As specified in the ABNF found in Section 2.4.2, an 'enumservice' is
    made up of 'types' and 'subtypes'.  For any given 'type', the
    allowable 'subtypes' must be specified in the registration.   
There is
    currently no concept of a registered 'subtype' outside the scope  
of a
    given 'type'.  Thus the registration process uses the 'type' as its
    main key within the IANA Registry.  While the combination of each
    type and all of its subtypes constitutes the allowed values for the
    'enumservice' field, it is not sufficient to simply document those
    values.  A complete registration will also include the allowed URI

Faltstrom                 Expires March 5, 2007                 [Page 8]
Internet-Draft                    ENUM                    September 2006

    schemes, a functional specification, security considerations,
    intended usage, and any other information needed to allow for
    interoperability within ENUM.  In order to be a registered ENUM
    Service, the entire specification, including the template, requires
    approval by the IESG and publication of the Enumservice registration
    specification as an RFC.

3.1.  Registration Requirements

    Service registration proposals are all expected to conform to  
various
    requirements laid out in the following sections.

3.1.1.  Functionality Requirement

    A registered Enumservice must be able to function as a selection
    mechanism when choosing one NAPTR resource record from another.   
That
    means that the registration MUST specify what is expected when using
    that very NAPTR record, and the URI which is the outcome of the use
    of it.

    Specifically, a registered Enumservice MUST specify the URI scheme 
(s)
    that may be used for the Enumservice, and, when needed, other
    information which will have to be transferred into the URI  
resolution
    process itself (LDAP Distinguished Names, transferring of the AUS
    into the resulting URI, etc).

3.1.2.  Naming requirement

    An Enumservice MUST be unique in order to be useful as a selection
    criteria.  Since an Enumservice is made up of a type and a type-
    dependent subtype, it is sufficient to require that the 'type'  
itself
    be unique.  The 'type' MUST be unique, conform to the ABNF specified
    in Section 2.4.2, and MUST NOT start with the facet "X-" which is
    reserved for experimental, private use.

    The subtype, being dependent on the type, MUST be unique within a
    given 'type'.  It must conform to the ABNF specified in Section
    2.4.2, and MUST NOT start with the facet "X-" which is reserved for
    experimental, private use.  The subtype for one type MAY be the same
    as a subtype for a different registered type but it is not  
sufficient
    to simply reference another type's subtype.  The function of each
    subtype must be specified in the context of the type being
    registered.

3.1.3.  Security requirement

    An analysis of security issues is required for all registered
    Enumservices.  (This is in accordance with the basic requirements  
for

Faltstrom                 Expires March 5, 2007                 [Page 9]
Internet-Draft                    ENUM                    September 2006

    all IETF protocols.)

    All descriptions of security issues must be as accurate as possible
    regardless of registration tree.  In particular, a statement that
    there are "no security issues associated with this Enumservice" must
    not be confused with "the security issues associated with this
    Enumservice have not been assessed".

    There is no requirement that an Enumservice must be secure or
    completely free from risks.  Nevertheless, all known security risks
    must be identified in the registration of an Enumservice.

    The security considerations section of all registrations is subject
    to continuing evaluation and modification.

    Some of the issues that should be looked at in a security  
analysis of
    an Enumservice are:
    1.  Complex Enumservices may include provisions for directives that
        institute actions on a user's resources.  In many cases  
provision
        can be made to specify arbitrary actions in an unrestricted
        fashion which may then have devastating results.  Especially if
        there is a risk for a new ENUM lookup, and because of that an
        infinite loop in the overall resolution process of the E.164.
    2.  Complex Enumservices may include provisions for directives that
        institute actions which, while not directly harmful, may result
        in disclosure of information that either facilitates a  
subsequent
        attack or else violates the users privacy in some way.
    3.  An Enumservice might be targeted for applications that require
        some sort of security assurance but do not provide the necessary
        security mechanisms themselves.  For example, an Enumservice
        could be defined for storage of confidential security services
        information such as alarm systems or message service passcodes,
        which in turn require an external confidentiality service.

3.1.4.  Publication Requirements

    Proposals for Enumservices registrations MUST be published as one of
    the following documents; RFC on the Standards Track, Experimental
    RFC, or as a BCP.

    IANA will retain copies of all Enumservice registration proposals  
and
    "publish" them as part of the Enumservice Registration tree itself.

3.2.  Registration procedure

Faltstrom                 Expires March 5, 2007                [Page 10]
Internet-Draft                    ENUM                    September 2006

3.2.1.  IANA Registration

    Provided that the Enumservice has obtained the necessary approval,
    and the RFC is published, IANA will register the Enumservice and  
make
    the Enumservice registration available to the community in addition
    to the RFC publication itself.

3.2.1.1.  Location of Enumservice Registrations

    Enumservice registrations will be published in the IANA repository
    and made available via anonymous FTP at the following URI:
    "ftp://ftp.iana.org/assignments/enum-services/".

3.2.1.2.  Change Control

    Change control of Enumservices stay with the IETF via the RFC
    publication process.  Especially, Enumservice registrations may not
    be deleted; Enumservices which are no longer believed appropriate  
for
    use can be declared OBSOLETE by publication of a new RFC and a  
change
    to their "intended use" field; such Enumservice will be clearly
    marked in the lists published by IANA.

3.2.2.  Registration Template

    Enumservice Type:

    Enumservice Subtype(s):

    URI Scheme(s):

    Functional Specification:

    Security considerations:

    Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)

    Author:

    Any other information that the author deems interesting:

    Note: In the case where a particular field has no value, that field
    is left completely blank, especially in the case where a given type
    has no subtypes.

4.  Examples

    The examples below use theoretical services that contain  
Enumservices

Faltstrom                 Expires March 5, 2007                [Page 11]
Internet-Draft                    ENUM                    September 2006

    which might not make sense, but that are still used for educational
    purposes.  For example, the protocol used is in some cases exactly
    the same string as the URI scheme.  That was the specification in  
RFC
    2916, but this 'default' specification of an Enumservice is no  
longer
    allowed.  All Enumservices need to be registered explicitly by the
    procedure specified in section Section 3.

4.1.  Example

                                                    $ORIGIN  
3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
                                                    NAPTR 10 100 (
                                                            "u"
                                                            "E2U+sip"
                                                            ""
                                                             
3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. )
                                                    NAPTR 10 101 (
                                                            "u"
                                                            "E2U+h323"
                                                            ""
                                                             
3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
                                                    NAPTR 10 102 "u"  
"E2U+msg" "!^.*$!mailto:[email-masked]!" .
                                                    _sip._e2u  IN URI  
10 10 "sip:[email-masked]"
                                                    _h323._e2u IN URI  
10 10 "h323:[email-masked]"
                                                    _msg._e2u  IN URI  
10 10 "mailto:[email-masked]"

    This describes that the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is
    preferably contacted by SIP, secondly via H.323 for voice, and
    thirdly by SMTP for messaging.  Note that the tokens "sip", "h323",
    and "msg" are Types registered with IANA, and they have no implicit
    connection with the protocols or URI schemes with the same names.

    In all cases, the next step in the resolution process is to use the
    lookup the URI resource record in DNS, after which resolution
    mechanism for each of the protocols, (specified by the URI schemes
    sip, h323 and mailto) to know what node to contact for each.

5.  IANA Considerations

    RFC 2916 (which this document replaces) requested IANA to delegate
    the E164.ARPA domain following instructions to be provided by the
    IAB.  The domain was delegated according to those instructions.
    Names within this zone are to be delegated to parties according to
    the ITU-T Recommendation E.164.  The names allocated should be
    hierarchic in accordance with ITU-T Recommendation E.164, and the

Faltstrom                 Expires March 5, 2007                [Page 12]
Internet-Draft                    ENUM                    September 2006

    codes should be assigned in accordance with that Recommendation.

    IAB is to coordinate with ITU-T TSB if the technical contact for the
    domain e164.arpa is to change, as ITU-T TSB has an operational
    working relationship with this technical contact which needs to be
    reestablished.

    Delegations in the zone e164.arpa (not delegations in delegated
    domains of e164.arpa) should be done after Expert Review, and the
    IESG will appoint a designated expert.

    IANA has created a registry for Enumservices as specified in Section
    3.  Whenever a new Enumservice is registered by the RFC process in
    the IETF, IANA is at the time of publication of the RFC to register
    the Enumservice and add a pointer to the RFC itself.

6.  Security Considerations

6.1.  DNS Security

    As ENUM uses DNS, which in its current form is an insecure protocol,
    there is no mechanism for ensuring that the data one gets back is
    authentic.  As ENUM is deployed on the global Internet, it is
    expected to be a popular target for various kind of attacks, and
    attacking the underlying DNS infrastructure is one way of attacking
    the ENUM service itself.

    There are multiple types of attacks that can happen against DNS that
    ENUM implementations should be aware of.  The following threats are
    taken from Threat Analysis Of The Domain Name System [10]:
    Packet Interception  Some of the simplest threats against DNS are
       various forms of packet interception: monkey-in-the-middle
       attacks, eavesdropping on requests combined with spoofed  
responses
       that beat the real response back to the resolver, and so forth.
       In any of these scenarios, the attacker can simply tell either
       party (usually the resolver) whatever it wants that party to
       believe.  While packet interception attacks are far from  
unique to
       DNS, DNS's usual behavior of sending an entire query or response
       in a single unsigned, unencrypted UDP packet makes these attacks
       particularly easy for any bad guy with the ability to intercept
       packets on a shared or transit network.
    ID Guessing and Query Prediction  Since the ID field in the DNS
       header is only a 16-bit field and the server UDP port associated
       with DNS is a well-known value, there are only 2**32 possible
       combinations of ID and client UDP port for a given client and
       server.  Thus it is possible for a reasonable brute force attack
       to allow an attacker to masquerade as a trusted server.  In most

Faltstrom                 Expires March 5, 2007                [Page 13]
Internet-Draft                    ENUM                    September 2006

       respects, this attack is similar to a packet interception attack
       except that it does not require the attacker to be on a  
transit or
       shared network.
    Name-based Attacks  Name-based attacks use the actual DNS caching
       behavior as a tool to insert bad data into a victim's cache, thus
       potentially subverting subsequent decisions based on DNS names.
       Most examples occur with CNAME, NS and DNAME Resource Records as
       they redirect a victim's query to another location.  The common
       thread in all of these attacks is that response messages allow  
the
       attacker to introduce arbitrary DNS names of the attacker's
       choosing and provide further information that the attacker claims
       is associated with those names; unless the victim has better
       knowledge of the data associated with those names, the victim is
       going to have a hard time defending against this class of  
attacks.
    Betrayal By A Trusted Server  Another variation on the packet
       interception attack is the trusted server that turns out not  
to be
       so trustworthy, whether by accident or by intent.  Many client
       machines are only configured with stub resolvers, and use trusted
       servers to perform all of their DNS queries on their behalf.  In
       many cases the trusted server is furnished by the user's ISP and
       advertised to the client via DHCP or PPP options.  Besides
       accidental betrayal of this trust relationship (via server bugs,
       successful server break-ins, etc), the server itself may be
       configured to give back answers that are not what the user would
       expect (whether in an honest attempt to help the user or to
       further some other goal such as furthering a business partnership
       between the ISP and some third party).
    Denial of Service  As with any network service (or, indeed, almost
       any service of any kind in any domain of discourse), DNS is
       vulnerable to denial of service attacks.  DNS servers are also at
       risk of being used as denial of service amplifiers, since DNS
       response packets tend to be significantly longer than DNS query
       packets.
    Authenticated Denial of Domain Names  The existence of RR types  
whose
       absence causes an action other than immediate failure (such as
       missing MX and SRV RRs, which fail over to A RRs) constitutes a
       real threat.  In the specific case of ENUM, even the immediate
       failure of a missing RR can be considered a problem as a method
       for changing call routing policy.

    Because of these threats, a deployed ENUM service SHOULD include
    mechanisms which ameliorate these threats.  Most of these threats  
can
    be solved by verifying the authenticity of the data via mechanisms
    such as DNSSEC [8] once it is deployed.  Others, such and Denial Of
    Service attacks, cannot be solved by data authentication.  It is
    important to remember that these threats include not only the NAPTR
    lookups themselves, but also the various records needed for the
    services to be useful (for example NS, MX, SRV and A records).

Faltstrom                 Expires March 5, 2007                [Page 14]
Internet-Draft                    ENUM                    September 2006

    Even if DNSSEC is deployed, a service that uses ENUM for address
    translation should not blindly trust that the peer is the intended
    party as all kind of attacks against DNS can not be protected  
against
    with DNSSEC.  A service should always authenticate the peers as part
    of the setup process for the service itself and never blindly trust
    any kind of addressing mechanism.

    Finally, as an ENUM service will be implementing some type of
    security mechanism, software which implements ENUM MUST be prepared
    to receive DNSSEC and other standardized DNS security responses,
    including large responses, EDNS0 signaling, unknown RRs, etc.

6.2.  Caching Security

    The caching in DNS can make the propagation time for a change take
    the same amount of time as the time to live for the NAPTR records in
    the zone that is changed.  The use of this in an environment where
    IP-addresses are for hire (for example, when using DHCP [9]) must
    therefore be done very carefully.

6.3.  Call Routing Security

    There are a number of countries (and other numbering  
environments) in
    which there are multiple providers of call routing and number/name-
    translation services.  In these areas, any system that permits  
users,
    or putative agents for users, to change routing or supplier
    information may provide incentives for changes that are actually
    unauthorized (and, in some cases, for denial of legitimate change
    requests).  Such environments should be designed with adequate
    mechanisms for identification and authentication of those requesting
    changes and for authorization of those changes.

6.4.  URI Resolution Security

    A large amount of Security Issues have to do with the resolution
    process itself, and use of the URIs produced by the DDDS mechanism.
    Those have to be specified in the registration of the Enumservice
    used, as specified in Section 3.1.3.

7.  Acknowledgements

    Support and ideas leading to RFC 2916 have come from people at
    Ericsson, Bjorn Larsson and the group which implemented this scheme
    in their lab to see that it worked.  Input has also arrived from
    ITU-T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility  
and
    Enumservice Definition), the ENUM working group in the IETF, John
    Klensin and Leif Sunnegardh.

Faltstrom                 Expires March 5, 2007                [Page 15]
Internet-Draft                    ENUM                    September 2006

    RFC 3761 was created with specific input from: Randy Bush, David
    Conrad, Richard Hill, Jon Peterson, Jim Reid, Joakim Stralmark,
    Robert Walter and James Yu.

    This document was created with input from many people including...

8.  Changes in RFC 3761 from RFC 2916

    Part from clarifications in the text in this document, the major
    changes are two:

    The document uses an explicit DDDS algorithm, and not only NAPTR
    resource records in an "ad-hoc" mode.  In reality this doesn't imply
    any changes in deployed base of applications, as the algorithm used
    for ENUM resolution is exactly the same.

    The format of the service field has changed.  The old format was of
    the form "example+E2U", while the new format is "E2U+example".
    Reason for this change have to with the added subtypes in the
    enumservice, the ability to support more than one enumservice per
    NAPTR RR, and a general agreement in the IETF that the main selector
    between different NAPTR with the same owner (E2U in this case)  
should
    be first.

9.  Changes from RFC 3761

    The changes are part from clarifying issues (that is not all in
    version 00) addition of the URI resource record.  See examples.

10.  References

10.1.  Normative References

    [E164]     ITU-T, "The International Public Telecommunication Number
               Plan", Recommendation E.164, May 1997.

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

    [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
               Resource Identifiers (URI) Dynamic Delegation Discovery
               System (DDDS) Application (ENUM)", RFC 3761, April 2004.

Faltstrom                 Expires March 5, 2007                [Page 16]
Internet-Draft                    ENUM                    September 2006

10.2.  Non-normative references

Author's Address

    Patrik Faltstrom
    Cisco Systems

    Email: [email-masked]

Faltstrom                 Expires March 5, 2007                [Page 17]
Internet-Draft                    ENUM                    September 2006

Full Copyright Statement

    Copyright (C) The Internet Society (2006).

    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights.

    This document and the information contained herein are provided  
on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE  
REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be  
claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.   
Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the  
use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR  
repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    [email-masked].

Acknowledgment

    Funding for the RFC Editor function is provided by the IETF
    Administrative Support Activity (IASA).

Faltstrom                 Expires March 5, 2007                [Page 18]