ENUM P. Faltstrom Internet-Draft Cisco Systems Inc Expires: November 30, 2002 M. Mealling VeriSign June 2002 The E.164 to URI DDDS Application draft-ietf-enum-rfc2916bis-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 November 30, 2002. Copyright Notice Copyright (C) The Internet Society (2002). 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 WWWW. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC WWWW. Faltstrom & Mealling Expires November 30, 2002 [Page 1] Internet-Draft ENUM June 2002 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 . . . . . . . . . . . . . . . 3 2. The ENUM Application Specifications . . . . . . . . . . . 4 2.1 Application Unique String . . . . . . . . . . . . . . . . 4 2.2 First Well Known Rule . . . . . . . . . . . . . . . . . . 4 2.3 Expected Output . . . . . . . . . . . . . . . . . . . . . 4 2.4 Valid Databases . . . . . . . . . . . . . . . . . . . . . 4 2.4.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4.2 Services Parameters . . . . . . . . . . . . . . . . . . . 6 2.4.2.1 ENUM Services . . . . . . . . . . . . . . . . . . . . . . 6 3. Registration mechanism for Enumservices . . . . . . . . . 8 3.1 Registration Requirements . . . . . . . . . . . . . . . . 8 3.1.1 Functionality Requirement . . . . . . . . . . . . . . . . 8 3.1.2 Naming requirement . . . . . . . . . . . . . . . . . . . . 8 3.1.3 Security requirement . . . . . . . . . . . . . . . . . . . 8 3.1.4 Publication Requirements . . . . . . . . . . . . . . . . . 9 3.2 Registration procedure . . . . . . . . . . . . . . . . . . 9 3.2.1 IANA Registration . . . . . . . . . . . . . . . . . . . . 9 3.2.1.1 Location of ENUM Enumservice Registrations . . . . . . . . 9 3.2.1.2 Change Control . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2 Registration Template . . . . . . . . . . . . . . . . . . 10 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . 18 Faltstrom & Mealling Expires November 30, 2002 [Page 2] Internet-Draft ENUM June 2002 1. Introduction Through transformation of E.164 [9] 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 domain name 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 in order to be listed, 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 RFC 2119. All capitalized terms are taken from the vocabulary found in the DDDS algorithm specification found in RFC ZZZZ [3]. 1.2 Use for these mechanisms for private dialing plans This document specifies how "ENUM" works, that is how to handle numbers allocated according to the ITU-T standard E.164. But, a similar mechanism can be used also for other numbers, such as private dialing plans. To implement that (a) a different domain, well-known for all parties using the same dialing plan, SHOULD be selected and (b) the application unique string (see section 3.1 below) SHOULD be the full number as specified but without the leading '+'. 1.3 Application of local policy The priority field in the NAPTR is a request from the holder of the E.164 in what order the records are to be used. It is to be noted that the party looking up the records MAY apply a local policy for in what order the records are to be used based on a combination of the service fields and URI schemes. Faltstrom & Mealling Expires November 30, 2002 [Page 3] Internet-Draft ENUM June 2002 2. The ENUM Application Specifications This template defines the ENUM DDDS Application according to the rules and requirements found in [3]. The DDDS database used by this Application is found in [4] which is the document that defines the NAPTR DNS Resource Record type. 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 "+1-770-923-9595". To ensure that no syntactic sugar is allowed into the AUS, all non- digits except for "+" are removed, yielding "+17709239595". 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 "+17709239595". Applying the First Well Known Rule produces the exact same string, "+17709239595". 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 [7]. 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 ZZZZ) [4] 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: Faltstrom & Mealling Expires November 30, 2002 [Page 4] Internet-Draft ENUM June 2002 1. Remove all characters with the exception of the digits. For example, the First Well Known Rule produced the Key "+4689761234". This step would simply remove the leading "+", producing "4689761234". 2. Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 3. Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 4. Append the string ".e164.arpa" to the end. Example: 4.3.2.1.6.7.9.8.6.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. 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 YYYY 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 [7]. 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). Faltstrom & Mealling Expires November 30, 2002 [Page 5] Internet-Draft ENUM June 2002 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*(enumservice) enumservice = service [":" protocol] service = 1*32(ALPHA / DIGIT) protocol = 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. The empty string is also valid. This will typically be seen at the beginning of a series of Rules, when it is impossible to know what services and protocols will be offered at the end of a particular delegation path. 2.4.2.1 ENUM Services An enumservice MUST be registered with the IANA via a description in an RFC. Enumservices 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 "protocol" and "service" in the grammar for the Enumserver and URI schemes. The mapping have to be made explicit in the specification for the Enumservice itself. It is allowed to specify the service and protocol in two different documents, to make the description coherent and easy to understand. For example, the Enumservice "presence" (note, no protocol specification) would define the various URI schemes ("im:", "mailto:") can be used and what the service can be used for ("Where is the owner of this E.164 number?"). Another example might be "talk:sip" which can specify that the URI must use the 'sip:' URI scheme and use the SIP protocol to make a voice call (as opposed to a voice mail call or fax call). What final protocol to use for the actual transport of voice is negotiated in the SIP protocol negotiation. The only exception to the registration rule is for services and protocols used for experimental purposes, and those are to start with the facet "X-". These types are unregistered, experimental, and should be used only with the active agreement of the parties Faltstrom & Mealling Expires November 30, 2002 [Page 6] Internet-Draft ENUM June 2002 exchanging them. The registration mechanism is specified in Section 3. Faltstrom & Mealling Expires November 30, 2002 [Page 7] Internet-Draft ENUM June 2002 3. Registration mechanism for Enumservices Registration of Enumservices requires approval by the IESG and publication of the Enumservice registration as some form of 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 An Enumservice registered 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 transfered into the URI resolution process itself (LDAP DNs, transferring of the AUS into the resulting URI, etc). 3.1.2 Naming requirement The name of an Enumservice 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. 3.1.3 Security requirement An analysis of security issues is required for for all Enumservices registered. (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 associates with this Enumservice have not been assessed". There is absolutely no requirement that Enumservices registered must be secure or completely free from risks. Nevertheless, all known security risks must be identified in the registration of a Enumservice. The security considerations section of all registrations is subject Faltstrom & Mealling Expires November 30, 2002 [Page 8] Internet-Draft ENUM June 2002 to continuing evaluation and modification. Some of the issues that should be looked at in a security analysis of a Enumservice are: 1. Complex Enumservices may include provisions for directives that institute actions on a users 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 not provide the necessary security mechanisms themselves. For example, a Enumservice could be defined for storage of confidential medical information which in turn requires an external confidentiality service. 3.1.4 Publication Requirements Proposals for Enumservices registered must be published as RFCs. IANA will retain copies of all Enumservice registration proposals and "publish" them as part of the ENUM Enumservice Registration tree itself. 3.2 Registration procedure Normal IETF processes should be used for publication of the RFC which is the basis of the registration of the Enumservice itself. 3.2.1 IANA Registration Provided that the Enumservice has obtained approval that is necessary, 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 ENUM Enumservice Registrations Enumservice registrations will be published in the IANA repository and made available via anonymous FTP at the following URI: "ftp:// ftp.isi.edu/in-notes/iana/assignments/enum-services/". Faltstrom & Mealling Expires November 30, 2002 [Page 9] Internet-Draft ENUM June 2002 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 media types will be clearly marked in the lists published by IANA. 3.2.2 Registration Template Enumservice Name: 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: Faltstrom & Mealling Expires November 30, 2002 [Page 10] Internet-Draft ENUM June 2002 4. Examples The examples below use theoretical services which uses Enumservices which might not make sense, but they are still used for educational purposes. For example, the protocol used is exactly the same as the URI scheme. That was the specification in RFC 2916, but this default specification of a Enumservice is no longer allowed. All Enumservices need to be registered explicitly by the procedure specified in section Section 3N. 4.1 Example 1 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "E2U+talk:sip" "!^.*$!sip:info@tele2.se!" . IN NAPTR 102 10 "u" "E2U+message:mailto" "!^.*$!mailto:info@tele2.se!" . This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is preferably contacted by SIP for voice, and secondly by SMTP for messaging. In both 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 and SMTP) to know what node to contact for each. 4.2 Example 2 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "u" "E2U+talk:sip+message:sip" "!^.*$!sip:paf@swip.net!" . IN NAPTR 102 10 "u" "E2U+message:mailto" "!^.*$!mailto:paf@swip.net!" . IN NAPTR 102 10 "u" "E2U+talk:tel" "!^(.*$)$!tel:\1!" . Note that one can use the sip protocol for both "talk" and "message", and that the sip URI is the preferred URI to use. The URI is resolved as described in RFC 2543 [6]. In the case of the "tel" URI scheme [7], a replacement "\1" is used. The rest of the resolution of the routing is done as described above. 4.3 Example 3 Faltstrom & Mealling Expires November 30, 2002 [Page 11] Internet-Draft ENUM June 2002 $ORIGIN 6.4.e164.arpa. * IN NAPTR 100 10 "u" "E2U+vpim:ldap" "!^+46(.*)$!ldap://ldap.se/cn=\1!" . We see in this example that information about all E.164 numbers in the 46 countrycode (for Sweden) exists in an LDAP server, and the search to do is specified by the LDAP URI [8]. The service vpim is used to mention that the database explicitly holds data according to some (hypothetical) vpim (Voice Profile for Internet Mail) specification. Faltstrom & Mealling Expires November 30, 2002 [Page 12] Internet-Draft ENUM June 2002 5. IANA Considerations This memo requests that the IANA delegate the E164.ARPA domain following instructions to be provided by the IAB. Names within this zone are to be delegated to parties according to the ITU recommendation E.164. The names allocated should be hierarchic in accordance with ITU Recommendation E.164, and the codes should 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 is to create a registry for ENUM Enumservices as specified in Section 3. Whenever a new ENUM 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. Faltstrom & Mealling Expires November 30, 2002 [Page 13] Internet-Draft ENUM June 2002 6. Security Considerations As this system is built on top of DNS, one can not be sure that the information one get back from DNS is more secure than any DNS query. To solve that, the use of DNSSEC [9] for securing and verifying zones is to be recommended. 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 [11]) must therefore be done very carefully. 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. 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 ENUM Enumservice used, as specified in Section 3.1.3. Faltstrom & Mealling Expires November 30, 2002 [Page 14] Internet-Draft ENUM June 2002 7. Acknowledgments 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, Jim Reid, Joakim Stralmark, Robert Walter and James Yu. Faltstrom & Mealling Expires November 30, 2002 [Page 15] Internet-Draft ENUM June 2002 References [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf-urn- ddds-toc-02.txt (work in progress), February 2002. [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-06.txt (work in progress), February 2002. [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- database-08.txt (work in progress), February 2002. [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The URI Resolution Application", RFC YYYY, draft-ietf-urn- uri-res-ddds-06.txt (work in progress), February 2002. [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf-urn- net-procedures-10.txt (work in progress), February 2002. [6] Mealling, M., "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999. [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [8] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", RFC 2717, BCP 35, November 1999. [9] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. Authors' Addresses Patrik Faltstrom Cisco Systems Inc 170 W Tasman Drive SJ-13/2 San Jose, CA 95134 USA EMail: paf@cisco.com URI: http://www.cisco.com Faltstrom & Mealling Expires November 30, 2002 [Page 16] Internet-Draft ENUM June 2002 Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US EMail: michael@neonym.net URI: http://www.verisignlabs.com Faltstrom & Mealling Expires November 30, 2002 [Page 17] Internet-Draft ENUM June 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Faltstrom & Mealling Expires November 30, 2002 [Page 18]