idnits 2.17.1 draft-ietf-enum-rfc2916bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 68 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The abstract seems to indicate that this document obsoletes RFC2916, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 24, 2002) is 7824 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '9' is mentioned on line 443, but not defined == Missing Reference: '11' is mentioned on line 449, but not defined == Unused Reference: '5' is defined on line 496, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 499, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (ref. '3') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM P. Faltstrom 3 Internet-Draft Cisco Systems Inc 4 Expires: May 25, 2003 M. Mealling 5 VeriSign 6 November 24, 2002 8 The E.164 to URI DDDS Application (ENUM) 9 draft-ietf-enum-rfc2916bis-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 25, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document discusses the use of the Domain Name System (DNS) for 41 storage of E.164 numbers. More specifically, how DNS can be used for 42 identifying available services connected to one E.164 number. It 43 specifically obsoletes RFC 2916 to bring it in line with the Dynamic 44 Delegation Discovery System (DDDS) Application specification found in 45 the document series specified in RFC 3401. It is very important to 46 note that it is impossible to read and understand this document 47 without reading the documents discussed in RFC 3401. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2 Use for these mechanisms for private dialing plans . . . . . 3 54 1.3 Application of local policy . . . . . . . . . . . . . . . . 3 55 2. The ENUM Application Specifications . . . . . . . . . . . . 4 56 2.1 Application Unique String . . . . . . . . . . . . . . . . . 4 57 2.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 4 58 2.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 4 59 2.4 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 4 60 2.4.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.4.2 Services Parameters . . . . . . . . . . . . . . . . . . . . 6 62 3. Registration mechanism for Enumservices . . . . . . . . . . 7 63 3.1 Registration Requirements . . . . . . . . . . . . . . . . . 7 64 3.1.1 Functionality Requirement . . . . . . . . . . . . . . . . . 7 65 3.1.2 Naming requirement . . . . . . . . . . . . . . . . . . . . . 7 66 3.1.3 Security requirement . . . . . . . . . . . . . . . . . . . . 7 67 3.1.4 Publication Requirements . . . . . . . . . . . . . . . . . . 8 68 3.2 Registration procedure . . . . . . . . . . . . . . . . . . . 8 69 3.2.1 IANA Registration . . . . . . . . . . . . . . . . . . . . . 8 70 3.2.2 Registration Template . . . . . . . . . . . . . . . . . . . 9 71 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 74 6. Security Considerations . . . . . . . . . . . . . . . . . . 12 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 76 Normative References . . . . . . . . . . . . . . . . . . . . 14 77 Non-normative references . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 79 Full Copyright Statement . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 Through transformation of E.164 [4] numbers into DNS names and the 84 use of existing DNS services like delegation through NS records and 85 NAPTR records, one can look up what services are available for a 86 specific domain name in a decentralized way with distributed 87 management of the different levels in the lookup process. 89 The domain "e164.arpa" is being populated in order to provide the 90 infrastructure in DNS for storage of E.164 numbers. In order to 91 facilitate distributed operations, this domain is divided into 92 subdomains. Holders of E.164 numbers which want to be listed in DNS 93 should contact the appropriate zone administrator in order to be 94 listed, by examining the SOA resource record associated with the 95 zone, just like in normal DNS operations. 97 Of course, as with other domains, policies for such listings will be 98 controlled on a subdomain basis and may differ in different parts of 99 the world. 101 1.1 Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119. 107 All capitalized terms are taken from the vocabulary found in the DDDS 108 algorithm specification found in RFC 3403 [1]. 110 1.2 Use for these mechanisms for private dialing plans 112 This document specifies how "ENUM" works, that is how to handle 113 numbers allocated according to the ITU-T standard E.164. But, a 114 similar mechanism can be used also for other numbers, such as private 115 dialing plans. To implement that (a) a different domain, well-known 116 for all parties using the same dialing plan, SHOULD be selected and 117 (b) the application unique string (see section 3.1 below) SHOULD be 118 the full number as specified but without the leading '+'. 120 1.3 Application of local policy 122 The priority field in the NAPTR is a request from the holder of the 123 E.164 in what order the records are to be used. It is to be noted 124 that the party looking up the records MAY apply a local policy for in 125 what order the records are to be used based on a combination of the 126 service fields and URI schemes. 128 2. The ENUM Application Specifications 130 This template defines the ENUM DDDS Application according to the 131 rules and requirements found in [1]. The DDDS database used by this 132 Application is found in [2] which is the document that defines the 133 NAPTR DNS Resource Record type. 135 2.1 Application Unique String 137 The Application Unique String is a fully qualified E.164 number minus 138 any non-digit characters except for the '+' character which appears 139 at the beginning of the number. The "+" is kept to provide a well 140 understood anchor for the AUS in order to distinguish it from other 141 telephone numbers that are not part of the E.164 namespace. 143 For example, the E.164 number could start out as "+1-770-923-9595". 144 To ensure that no syntactic sugar is allowed into the AUS, all non- 145 digits except for "+" are removed, yielding "+17709239595". 147 2.2 First Well Known Rule 149 The First Well Known Rule for this Application is the identity rule. 150 The output of this rule is the same as the input. This is because 151 the E.164 namespace and this Applications databases are organized in 152 such a way that it is possible to go directly from the name to the 153 smallest granularity of the namespace directly from the name itself. 155 Take the previous example, the AUS is "+17709239595". Applying the 156 First Well Known Rule produces the exact same string, "+17709239595". 158 2.3 Expected Output 160 The output of the last DDDS loop is a Uniform Resource Identifier in 161 its absolute form according to the 'absoluteURI' production in the 162 Collected ABNF found in RFC2396 [3]. 164 2.4 Valid Databases 166 At present only one DDDS Database is specified for this Application. 167 "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS 168 Database" (RFC 3403) [2] specifies a DDDS Database that uses the 169 NAPTR DNS resource record to contain the rewrite rules. The Keys for 170 this database are encoded as domain-names. 172 The output of the First Well Known Rule for the ENUM Application is 173 the E.164 number minus all non-digit characters except for the +. In 174 order to convert this to a unique key in this Database the string is 175 converted into a domain-name according to this algorithm: 177 1. Remove all characters with the exception of the digits. For 178 example, the First Well Known Rule produced the Key 179 "+4689761234". This step would simply remove the leading "+", 180 producing "4689761234". 182 2. Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 184 3. Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 186 4. Append the string ".e164.arpa" to the end. Example: 187 4.3.2.1.6.7.9.8.6.4.e164.arpa 189 This domain-name is used to request NAPTR records which may contain 190 the end result or, if the flags field is blank, produces new keys in 191 the form of domain-names from the DNS. 193 DNS servers MAY interpret Flag values and use that information to 194 include appropriate resource records in the Additional Information 195 portion of the DNS packet. Clients are encouraged to check for 196 additional information but are not required to do so. See the 197 Additional Information Processing section of RFC 3404 for more 198 information on NAPTR records and the Additional Information section 199 of a DNS response packet. 201 The character set used to encode the substitution expression is UTF- 202 8. The allowed input characters are all those characters that are 203 allowed anywhere in an E.164 number. The characters allowed to be in 204 a Key are those that are currently defined for DNS domain-names. 206 2.4.1 Flags 208 This Database contains a field that contains flags that signal when 209 the DDDS algorithm has finished. At this time only one flag, "U", is 210 defined. This means that this Rule is the last one and that the 211 output of the Rule is a URI [3]. 213 If a client encounters a record with an unknown flag, it MUST ignore 214 it and move to the next Rule. This test takes precedence over any 215 ordering since flags can control the interpretation placed on fields. 216 A novel flag might change the interpretation of the regexp and/or 217 replacement fields such that it is impossible to determine if a 218 record matched a given target. 220 If this flag is not present then this rule is non-terminal. If a 221 Rule is non-terminal then clients MUST use the Key produced by this 222 Rewrite Rule as the new Key in the DDDS loop (i.e. causing the 223 client to query for new NAPTR records at the domain-name that is the 224 result of this Rule). 226 2.4.2 Services Parameters 228 Service Parameters for this Application take the following form and 229 are found in the Service field of the NAPTR record. 231 service_field = "E2U" 1*(enumservice) 232 enumservice = "+" type 0*(subtype) 233 type = 1*32(ALPHA / DIGIT) 234 subtype = ":" 1*32(ALPHA / DIGIT) 236 In other words, a non-optional "E2U" (used to denote ENUM only 237 Rewrite Rules in order to mitigate record collisions) followed by 1 238 or more or more Enumservices which indicate what class of 239 functionality a given end point offers. Each Enumservice is 240 indicated by an initial '+' character. 242 2.4.2.1 ENUM Services 244 An enumservice MUST be registered with the IANA via a description in 245 an RFC. Enumservices specifications contain the functional 246 specification (i.e. what it can be used for), the valid protocols, 247 and the URI schemes that may be returned. Note that there is no 248 implicit mapping between the textual string "type" or "subtype" in 249 the grammar for the Enumservice and URI schemes or protocols. The 250 mapping, if any, have to be made explicit in the specification for 251 the Enumservice itself. A registration of a specific Type also have 252 to specify the Subtypes allowed. 254 The only exception to the registration rule is for Types and Subtypes 255 used for experimental purposes, and those are to start with the facet 256 "X-". These elements are unregistered, experimental, and should be 257 used only with the active agreement of the parties exchanging them. 259 The registration mechanism is specified in Section 3. 261 3. Registration mechanism for Enumservices 263 Registration of Enumservices requires approval by the IESG and 264 publication of the Enumservice registration as some form of RFC. 266 3.1 Registration Requirements 268 Service registration proposals are all expected to conform to various 269 requirements laid out in the following sections. 271 3.1.1 Functionality Requirement 273 An Enumservice registered must be able to function as a selection 274 mechanism when choosing one NAPTR resource record from another. That 275 means that the registration MUST specify what is expected when using 276 that very NAPTR record, and the URI which is the outcome of the use 277 of it. 279 Specifically, a registered Enumservice MUST specify the URI scheme(s) 280 that may be used for the Enumservice, and, when needed, other 281 information which will have to be transfered into the URI resolution 282 process itself (LDAP DNs, transferring of the AUS into the resulting 283 URI, etc). 285 3.1.2 Naming requirement 287 The name of an Enumservice MUST be unique, conform to the ABNF 288 specified in Section 2.4.2, and MUST NOT start with the facet "X-" 289 which is reserved for experimental, private use. 291 3.1.3 Security requirement 293 An analysis of security issues is required for for all Enumservices 294 registered. (This is in accordance with the basic requirements for 295 all IETF protocols.) 297 All descriptions of security issues must be as accurate as possible 298 regardless of registration tree. In particular, a statement that 299 there are "no security issues associated with this Enumservice" must 300 not be confused with "the security issues associates with this 301 Enumservice have not been assessed". 303 There is no requirement that Enumservices registered must be secure 304 or completely free from risks. Nevertheless, all known security 305 risks must be identified in the registration of a Enumservice. 307 The security considerations section of all registrations is subject 308 to continuing evaluation and modification. 310 Some of the issues that should be looked at in a security analysis of 311 a Enumservice are: 313 1. Complex Enumservices may include provisions for directives that 314 institute actions on a users resources. In many cases provision 315 can be made to specify arbitrary actions in an unrestricted 316 fashion which may then have devastating results. Especially if 317 there is a risk for a new ENUM lookup, and because of that an 318 infinite loop in the overall resolution process of the E.164. 320 2. Complex Enumservices may include provisions for directives that 321 institute actions which, while not directly harmful, may result 322 in disclosure of information that either facilitates a subsequent 323 attack or else violates the users privacy in some way. 325 3. An Enumservice might be targeted for applications that require 326 some sort of security assurance but not provide the necessary 327 security mechanisms themselves. For example, a Enumservice could 328 be defined for storage of confidential medical information which 329 in turn requires an external confidentiality service. 331 3.1.4 Publication Requirements 333 Proposals for Enumservices registered must be published as RFCs. 334 IANA will retain copies of all Enumservice registration proposals and 335 "publish" them as part of the ENUM Enumservice Registration tree 336 itself. 338 3.2 Registration procedure 340 Normal IETF processes should be used for publication of the RFC which 341 is the basis of the registration of the Enumservice itself. 343 3.2.1 IANA Registration 345 Provided that the Enumservice has obtained approval that is 346 necessary, and the RFC is published, IANA will register the 347 Enumservice and make the Enumservice registration available to the 348 community in addition to the RFC publication itself. 350 3.2.1.1 Location of ENUM Enumservice Registrations 352 Enumservice registrations will be published in the IANA repository 353 and made available via anonymous FTP at the following URI: "ftp:// 354 ftp.isi.edu/in-notes/iana/assignments/enum-services/". 356 3.2.1.2 Change Control 358 Change control of Enumservices stay with the IETF via the RFC 359 publication process. Especially, Enumservice registrations may not 360 be deleted; Enumservices which are no longer believed appropriate for 361 use can be declared OBSOLETE by publication of a new RFC and a change 362 to their "intended use" field; such media types will be clearly 363 marked in the lists published by IANA. 365 3.2.2 Registration Template 367 Enumservice Name: 369 Type(s): 371 Subtype(s): 373 URI Scheme(s): 375 Functional Specification: 377 Security considerations: 379 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) 381 Author: 383 Any other information that the author deems interesting: 385 4. Examples 387 The examples below use theoretical services which uses Enumservices 388 which might not make sense, but they are still used for educational 389 purposes. For example, the protocol used is in some cases exactly 390 the the same string as the URI scheme. That was the specification in 391 RFC 2916, but this default specification of a Enumservice is no 392 longer allowed. All Enumservices need to be registered explicitly by 393 the procedure specified in section Section 3N. 395 4.1 Example 397 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. 398 IN NAPTR 100 10 "u" "E2U+sip" 399 "!^.*$!sip:info@example.com!" . 400 IN NAPTR 101 10 "u" "E2U+h323:voice" 401 "!^.*$!h323:info@example.com!" . 402 IN NAPTR 102 10 "u" "E2U+message:mailto" 403 "!^.*$!mailto:info@example.com!" . 405 This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is 406 preferably contacted by SIP, secondly via H.323 for voice, and 407 thirdly by SMTP for messaging. Note that the tokens "sip", 408 "message", "h323", "voice" and "mailto" are Types and Subtypes 409 registered with IANA, and they have no implicit connection with the 410 protocols or URI schemes with the same names. 412 In all cases, the next step in the resolution process is to use the 413 resolution mechanism for each of the protocols, (specified by the URI 414 schemes sip, h323 and mailto) to know what node to contact for each. 416 5. IANA Considerations 418 This memo requests that the IANA delegate the E164.ARPA domain 419 following instructions to be provided by the IAB. Names within this 420 zone are to be delegated to parties according to the ITU 421 recommendation E.164. The names allocated should be hierarchic in 422 accordance with ITU Recommendation E.164, and the codes should 423 assigned in accordance with that Recommendation. 425 IAB is to coordinate with ITU-T TSB if the technical contact for the 426 domain e164.arpa is to change, as ITU-T TSB has an operational 427 working relationship with this technical contact which needs to be 428 reestablished. 430 Delegations in the zone e164.arpa (not delegations in delegated 431 domains of e164.arpa) should be done after Expert Review, and the 432 IESG will appoint a designated expert. 434 IANA is to create a registry for ENUM Enumservices as specified in 435 Section 3. Whenever a new ENUM Enumservice is registered by the RFC 436 process in the IETF, IANA is at the time of publication of the RFC to 437 register the Enumservice and add a pointer to the RFC itself. 439 6. Security Considerations 441 As this system is built on top of DNS, one can not be sure that the 442 information one get back from DNS is more secure than any DNS query. 443 To solve that, the use of DNSSEC [9] for securing and verifying zones 444 is to be recommended. 446 The caching in DNS can make the propagation time for a change take 447 the same amount of time as the time to live for the NAPTR records in 448 the zone that is changed. The use of this in an environment where 449 IP-addresses are for hire (for example, when using DHCP [11]) must 450 therefore be done very carefully. 452 There are a number of countries (and other numbering environments) in 453 which there are multiple providers of call routing and number/name- 454 translation services. In these areas, any system that permits users, 455 or putative agents for users, to change routing or supplier 456 information may provide incentives for changes that are actually 457 unauthorized (and, in some cases, for denial of legitimate change 458 requests). Such environments should be designed with adequate 459 mechanisms for identification and authentication of those requesting 460 changes and for authorization of those changes. 462 A large amount of Security Issues have to do with the resolution 463 process itself, and use of the URIs produced by the DDDS mechanism. 464 Those have to be specified in the registration of the ENUM 465 Enumservice used, as specified in Section 3.1.3. 467 7. Acknowledgments 469 Support and ideas leading to RFC 2916 have come from people at 470 Ericsson, Bjorn Larsson and the group which implemented this scheme 471 in their lab to see that it worked. Input has also arrived from ITU- 472 T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and 473 Enumservice Definition), the ENUM working group in the IETF, John 474 Klensin and Leif Sunnegardh. 476 This update of RFC 2916 is created with specific input from: Randy 477 Bush, David Conrad, Richard Hill, Jim Reid, Joakim Stralmark, Robert 478 Walter and James Yu. 480 Normative References 482 [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 483 Three: The DNS Database", RFC 3403, February 2002. 485 [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 486 Four: The URI Resolution Application", RFC 3404, February 2002. 488 [3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 489 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 491 [4] ITU-T, "The International Public Telecommunication Number Plan", 492 Recommendation E.164, May 1997. 494 Non-normative references 496 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 497 One: The Comprehensive DDDS Standard", RFC 3401, February 2002. 499 [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 500 Two: The Algorithm", RFC 3402, February 2002. 502 Authors' Addresses 504 Patrik Faltstrom 505 Cisco Systems Inc 506 Ledasa 507 273 71 Lovestad 508 Sweden 510 EMail: paf@cisco.com 511 URI: http://www.cisco.com 513 Michael Mealling 514 VeriSign 515 21345 Ridgetop Circle 516 Sterling, VA 20166 517 US 519 EMail: michael@neonym.net 520 URI: http://www.verisignlabs.com 522 Full Copyright Statement 524 Copyright (C) The Internet Society (2002). All Rights Reserved. 526 This document and translations of it may be copied and furnished to 527 others, and derivative works that comment on or otherwise explain it 528 or assist in its implementation may be prepared, copied, published 529 and distributed, in whole or in part, without restriction of any 530 kind, provided that the above copyright notice and this paragraph are 531 included on all such copies and derivative works. However, this 532 document itself may not be modified in any way, such as by removing 533 the copyright notice or references to the Internet Society or other 534 Internet organizations, except as needed for the purpose of 535 developing Internet standards in which case the procedures for 536 copyrights defined in the Internet Standards process must be 537 followed, or as required to translate it into languages other than 538 English. 540 The limited permissions granted above are perpetual and will not be 541 revoked by the Internet Society or its successors or assigns. 543 This document and the information contained herein is provided on an 544 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 545 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 546 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 547 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 548 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 550 Acknowledgement 552 Funding for the RFC Editor function is currently provided by the 553 Internet Society.