doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc3761.txt b/doc/rfc/rfc3761.txt
new file mode 100644
index 0000000..8c73151
--- /dev/null
+++ b/doc/rfc/rfc3761.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                       P. Faltstrom
+Request for Comments: 3761                           Cisco Systems, Inc.
+Obsoletes: 2916                                              M. Mealling
+Category: Standards Track                                       VeriSign
+                                                              April 2004
+
+
+            The E.164 to Uniform Resource Identifiers (URI)
+     Dynamic Delegation Discovery System (DDDS) Application (ENUM)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document discusses the use of the Domain Name System (DNS) for
+   storage of E.164 numbers.  More specifically, how DNS can be used for
+   identifying available services connected to one E.164 number.  It
+   specifically obsoletes RFC 2916 to bring it in line with the Dynamic
+   Delegation Discovery System (DDDS) Application specification found in
+   the document series specified in RFC 3401.  It is very important to
+   note that it is impossible to read and understand this document
+   without reading the documents discussed in RFC 3401.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+       1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.2. Use for these mechanisms for private dialing plans. . . .  3
+       1.3. Application of local policy . . . . . . . . . . . . . . .  3
+   2.  The ENUM Application Specifications .  . . . . . . . . . . . .  4
+       2.1. Application Unique String . . . . . . . . . . . . . . . .  5
+       2.2. First Well Known Rule . . . . . . . . . . . . . . . . . .  5
+       2.3. Expected Output . . . . . . . . . . . . . . . . . . . . .  5
+       2.4. Valid Databases . . . . . . . . . . . . . . . . . . . . .  5
+            2.4.1. Flags. . . . . . . . . . . . . . . . . . . . . . .  6
+            2.4.2. Services Parameters. . . . . . . . . . . . . . . .  7
+       2.5. What constitutes an 'Enum Resolver'?. . . . . . . . . . .  8
+   3.  Registration mechanism for Enumservices .  . . . . . . . . . .  8
+
+
+
+Faltstrom & Mealling        Standards Track                     [Page 1]
+
+RFC 3761                          ENUM                        April 2004
+
+
+       3.1. Registration Requirements . . . . . . . . . . . . . . . .  8
+            3.1.1. Functionality Requirement. . . . . . . . . . . . .  8
+            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. . . . . . . . . . . . . . . . . 10
+            3.2.2. Registration Template. . . . . . . . . . . . . . . 11
+   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+       4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
+   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 12
+       6.1. DNS Security. . . . . . . . . . . . . . . . . . . . . . . 12
+       6.2. Caching Security. . . . . . . . . . . . . . . . . . . . . 14
+       6.3. Call Routing Security . . . . . . . . . . . . . . . . . . 14
+       6.4. URI Resolution Security . . . . . . . . . . . . . . . . . 15
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
+   8.  Changes since RFC 2916 . . . . . . . . . . . . . . . . . . . . 15
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+       9.1. Normative References. . . . . . . . . . . . . . . . . . . 16
+       9.2. Informative References. . . . . . . . . . . . . . . . . . 16
+   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
+   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
+
+1.  Introduction
+
+   This document discusses the use of the Domain Name System (DNS) for
+   storage of E.164 numbers.  More specifically, how DNS can be used for
+   identifying available services connected to one E.164 number.  It
+   specifically obsoletes RFC 2916 to bring it in line with the Dynamic
+   Delegation Discovery System (DDDS) Application specification found in
+   the document series specified in RFC 3401 [6].  It is very important
+   to note that it is impossible to read and understand this document
+   without reading the documents discussed in RFC 3401 [6].
+
+   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
+
+
+
+Faltstrom & Mealling        Standards Track                     [Page 2]
+
+RFC 3761                          ENUM                        April 2004
+
+
+   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
+   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
+
+
+
+Faltstrom & Mealling        Standards Track                     [Page 3]
+
+RFC 3761                          ENUM                        April 2004
+
+
+   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.
+
+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.
+
+
+
+
+
+
+
+
+
+Faltstrom & Mealling        Standards Track                     [Page 4]
+
+RFC 3761                          ENUM                        April 2004
+
+
+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".
+
+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".
+
+
+
+
+Faltstrom & Mealling        Standards Track                     [Page 5]
+
+RFC 3761                          ENUM                        April 2004
+
+
+   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
+   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 only one flag, "U", is
+   defined.  This means that this Rule is the last one and that the
+   output of the Rule is a URI [4].  See RFC 3404 [3].
+
+   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.
+
+
+
+Faltstrom & Mealling        Standards Track                     [Page 6]
+
+RFC 3761                          ENUM                        April 2004
+
+
+   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)
+
+   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.
+
+
+
+
+
+
+Faltstrom & Mealling        Standards Track                     [Page 7]
+
+RFC 3761                          ENUM                        April 2004
+
+
+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
+   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).
+
+
+
+Faltstrom & Mealling        Standards Track                     [Page 8]
+
+RFC 3761                          ENUM                        April 2004
+
+
+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
+   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.
+
+
+
+
+
+Faltstrom & Mealling        Standards Track                     [Page 9]
+
+RFC 3761                          ENUM                        April 2004
+
+
+   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
+
+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.
+
+
+
+
+
+
+
+Faltstrom & Mealling        Standards Track                    [Page 10]
+
+RFC 3761                          ENUM                        April 2004
+
+
+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
+   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" "!^.*$!sip:info@example.com!" .
+      NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" .
+      NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" .
+
+   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.
+
+
+
+
+
+
+
+Faltstrom & Mealling        Standards Track                    [Page 11]
+
+RFC 3761                          ENUM                        April 2004
+
+
+   In all cases, the next step in the resolution process is to use the
+   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
+   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
+
+
+
+Faltstrom & Mealling        Standards Track                    [Page 12]
+
+RFC 3761                          ENUM                        April 2004
+
+
+      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 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).
+
+
+
+
+
+
+Faltstrom & Mealling        Standards Track                    [Page 13]
+
+RFC 3761                          ENUM                        April 2004
+
+
+   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).
+
+   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,
+
+
+
+Faltstrom & Mealling        Standards Track                    [Page 14]
+
+RFC 3761                          ENUM                        April 2004
+
+
+   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.
+
+   This update of RFC 2916 is created with specific input from: Randy
+   Bush, David Conrad, Richard Hill, Jon Peterson, Jim Reid, Joakim
+   Stralmark, Robert Walter and James Yu.
+
+8.  Changes since 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.
+
+
+
+
+
+
+
+Faltstrom & Mealling        Standards Track                    [Page 15]
+
+RFC 3761                          ENUM                        April 2004
+
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Three: The Domain Name System (DNS) Database", RFC 3403, October
+        2002.
+
+   [3]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Four: The Uniform Resource Identifiers (URI) Resolution
+        Application", RFC 3404, October 2002.
+
+   [4]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+   [5]  ITU-T, "The International Public Telecommunication Number Plan",
+        Recommendation E.164, May 1997.
+
+   [6]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        One: The Comprehensive DDDS", RFC 3401, October 2002.
+
+   [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Two: The Algorithm", RFC 3402, October 2002.
+
+9.2.  Informative References
+
+   [8]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [9]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+        March 1997.
+
+   [10] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
+        System", Work in Progress, April 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom & Mealling        Standards Track                    [Page 16]
+
+RFC 3761                          ENUM                        April 2004
+
+
+10.  Authors' Addresses
+
+   Patrik Faltstrom
+   Cisco Systems Inc
+   Ledasa
+   273 71 Lovestad
+   Sweden
+
+   EMail: paf@cisco.com
+   URI:   http://www.cisco.com
+
+
+   Michael Mealling
+   VeriSign
+   21345 Ridgetop Circle
+   Sterling, VA  20166
+   US
+
+   Email: michael@verisignlabs.com
+   URI:   http://www.verisignlabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom & Mealling        Standards Track                    [Page 17]
+
+RFC 3761                          ENUM                        April 2004
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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 ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Faltstrom & Mealling        Standards Track                    [Page 18]
+