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]
`
`AT&T Exhibit 1031
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1031
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1031
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1031
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1031
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1031
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1031
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1031
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1031
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1031
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1031
`AT&T v. VoIP, IPR 2017-01384
`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]
`
`AT&T Exhibit 1031
`AT&T v. VoIP, IPR 2017-01384
`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
`