idnits 2.17.1 draft-ietf-enum-rfc2916bis-07.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 20, 2003) is 7456 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) == Unused Reference: '5' is defined on line 725, 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' ** Downref: Normative reference to an Informational RFC: RFC 3401 (ref. '5') -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '7') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-07) exists of draft-ietf-dnsext-dns-threats-01 Summary: 3 errors (**), 0 flaws (~~), 5 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 Obsoletes: 2916 (if approved) M. Mealling 5 Expires: May 20, 2004 VeriSign 6 November 20, 2003 8 The E.164 to URI DDDS Application (ENUM) 9 draft-ietf-enum-rfc2916bis-07.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 other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on May 20, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document discusses the use of the Domain Name System (DNS) for 40 storage of E.164 numbers. More specifically, how DNS can be used for 41 identifying available services connected to one E.164 number. It 42 specifically obsoletes RFC 2916 to bring it in line with the Dynamic 43 Delegation Discovery System (DDDS) Application specification found in 44 the document series specified in RFC 3401. It is very important to 45 note that it is impossible to read and understand this document 46 without reading the documents discussed in RFC 3401. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2 Use for these mechanisms for private dialing plans . . . . . 3 53 1.3 Application of local policy . . . . . . . . . . . . . . . . 3 54 2. The ENUM Application Specifications . . . . . . . . . . . . 5 55 2.1 Application Unique String . . . . . . . . . . . . . . . . . 5 56 2.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 5 57 2.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 5 58 2.4 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 6 59 2.4.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.4.2 Services Parameters . . . . . . . . . . . . . . . . . . . . 7 61 2.5 What constitutes an 'Enum Resolver'? . . . . . . . . . . . . 8 62 3. Registration mechanism for Enumservices . . . . . . . . . . 9 63 3.1 Registration Requirements . . . . . . . . . . . . . . . . . 9 64 3.1.1 Functionality Requirement . . . . . . . . . . . . . . . . . 9 65 3.1.2 Naming requirement . . . . . . . . . . . . . . . . . . . . . 9 66 3.1.3 Security requirement . . . . . . . . . . . . . . . . . . . . 10 67 3.1.4 Publication Requirements . . . . . . . . . . . . . . . . . . 11 68 3.2 Registration procedure . . . . . . . . . . . . . . . . . . . 11 69 3.2.1 IANA Registration . . . . . . . . . . . . . . . . . . . . . 11 70 3.2.2 Registration Template . . . . . . . . . . . . . . . . . . . 11 71 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 74 6. Security Considerations . . . . . . . . . . . . . . . . . . 15 75 6.1 DNS Security . . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.2 Caching Security . . . . . . . . . . . . . . . . . . . . . . 17 77 6.3 Call Routing Security . . . . . . . . . . . . . . . . . . . 17 78 6.4 URI Resolution Security . . . . . . . . . . . . . . . . . . 17 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 80 8. Changes since RFC 2916 . . . . . . . . . . . . . . . . . . . 19 81 Normative References . . . . . . . . . . . . . . . . . . . . 20 82 Non-normative references . . . . . . . . . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 84 Intellectual Property and Copyright Statements . . . . . . . 22 86 1. Introduction 88 Through transformation of International Public Telecommunication 89 Numbers in the international format [4], called within this document 90 E.164 numbers, into DNS names and the use of existing DNS services 91 like delegation through NS records and NAPTR records, one can look up 92 what services are available for a specific E.164 in a decentralized 93 way with distributed management of the different levels in the lookup 94 process. 96 The domain "e164.arpa" is being populated in order to provide the 97 infrastructure in DNS for storage of E.164 numbers. In order to 98 facilitate distributed operations, this domain is divided into 99 subdomains. Holders of E.164 numbers which want to be listed in DNS 100 should contact the appropriate zone administrator according to the 101 policy which is attached to the zone. One should start looking for 102 this information by examining the SOA resource record associated with 103 the zone, just like in normal DNS operations. 105 Of course, as with other domains, policies for such listings will be 106 controlled on a subdomain basis and may differ in different parts of 107 the world. 109 1.1 Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119. 115 All other capitalized terms are taken from the vocabulary found in 116 the DDDS algorithm specification found in RFC 3403 [1]. 118 1.2 Use for these mechanisms for private dialing plans 120 This document describes the operation of these mechanisms in the 121 context of numbers allocated according to the ITU-T recommendation 122 E.164. The same mechanisms might be used for private dialing plans. 123 If these mechanisms are re-used, the suffix used for the private 124 dialing plan MUST NOT be e164.arpa, to avoid conflict with this 125 specification. Parties to the private dialing plan will need to know 126 the suffix used by their private dialing plan for correct operation 127 of these mechanisms. Further, the application unique string used 128 SHOULD be the full number as specified, but without the leading '+', 129 and such private use MUST NOT be called "ENUM". 131 1.3 Application of local policy 133 The Order field in the NAPTR record specifies in what order the DNS 134 records are to be interpreted. This is because DNS does not guarantee 135 the order of records returned in the answer section of a DNS packet. 136 In most ENUM cases this isn't an issue because the typical regular 137 expression will be '!^.*$!' since the first query often results in a 138 terminal Rule. 140 But there are other cases (non-terminal Rules) where two different 141 Rules both match the given Application Unique String. As each Rule is 142 evaluated within the algorithm, one may match a more significant 143 piece of the AUS than the other. For example, by using a non-terminal 144 NAPTR a given set of numbers is sent to some 145 private-dialing-plan-specific zone. Within that zone there are two 146 Rules that state that if a match is for the entire exchange and the 147 service is SIP related then the first, SIP-specific rule is used. But 148 the other Rule matches a longer piece of the AUS, specifying that for 149 some other service (instant messaging) that the Rule denotes a 150 departmental level service. If the shorter matching Rule comes before 151 the longer match, it can 'mask' the other rules. Thus, the order in 152 which each Rule is tested against the AUS is an important corner case 153 that many DDDS applications take advantage of. 155 In the case where the zone authority wishes to state that two Rules 156 have the same effect or are identical in usage, then the Order for 157 those records is set to the same value. In that case, the Preference 158 is used to specify a locally over-ridable suggestion by the zone 159 authority that one Rule might simply be better than another for some 160 reason. 162 For ENUM this specifies where a client is allowed to apply local 163 policy and where it is not. The Order field in the NAPTR is a 164 request from the holder of the E.164 number that the records be 165 handled in a specific way. The Preference field is merely a 166 suggestion from that E.164 holder that one record might be better 167 than another. A client implementing ENUM MUST adhere to the Order 168 field but can simply take the Preference value "on advisement" as 169 part of a client context specific selection method. 171 2. The ENUM Application Specifications 173 This template defines the ENUM DDDS Application according to the 174 rules and requirements found in [6]. The DDDS database used by this 175 Application is found in [1] which is the document that defines the 176 NAPTR DNS Resource Record type. 178 ENUM is only applicable for E.164 numbers. ENUM compliant 179 applications MUST only query DNS for what it believes is an E.164 180 number. Since there are numerous dialing plans which can change over 181 time , it is probably impossible for a client application to have 182 perfect knowledge about every valid and dialable E.164 number. 183 Therefore a client application, doing everything within its power, 184 can end up with what it thinks is a syntactically correct E.164 185 number which in reality is not actually valid or dialable. This 186 implies that applications MAY send DNS queries when, for example, a 187 user mistypes a number in a user interface. Because of this, there is 188 the risk that collisions between E.164 numbers and non-E.164 numbers 189 can occur. To mitigate this risk, the E2U portion of the service 190 field MUST NOT be used for non-E.164 numbers. 192 2.1 Application Unique String 194 The Application Unique String is a fully qualified E.164 number minus 195 any non-digit characters except for the '+' character which appears 196 at the beginning of the number. The "+" is kept to provide a well 197 understood anchor for the AUS in order to distinguish it from other 198 telephone numbers that are not part of the E.164 namespace. 200 For example, the E.164 number could start out as "+44-116-496-0348". 201 To ensure that no syntactic sugar is allowed into the AUS, all 202 non-digits except for "+" are removed, yielding "+441164960348". 204 2.2 First Well Known Rule 206 The First Well Known Rule for this Application is the identity rule. 207 The output of this rule is the same as the input. This is because the 208 E.164 namespace and this Applications databases are organized in such 209 a way that it is possible to go directly from the name to the 210 smallest granularity of the namespace directly from the name itself. 212 Take the previous example, the AUS is "+441164960348". Applying the 213 First Well Known Rule produces the exact same string, 214 "+441164960348". 216 2.3 Expected Output 218 The output of the last DDDS loop is a Uniform Resource Identifier in 219 its absolute form according to the 'absoluteURI' production in the 220 Collected ABNF found in RFC2396 [3]. 222 2.4 Valid Databases 224 At present only one DDDS Database is specified for this Application. 225 "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS 226 Database" (RFC 3403) [1] specifies a DDDS Database that uses the 227 NAPTR DNS resource record to contain the rewrite rules. The Keys for 228 this database are encoded as domain-names. 230 The output of the First Well Known Rule for the ENUM Application is 231 the E.164 number minus all non-digit characters except for the +. In 232 order to convert this to a unique key in this Database the string is 233 converted into a domain-name according to this algorithm: 235 1. Remove all characters with the exception of the digits. For 236 example, the First Well Known Rule produced the Key 237 "+442079460148". This step would simply remove the leading "+", 238 producing "442079460148". 240 2. Put dots (".") between each digit. Example: 241 4.4.2.0.7.9.4.6.0.1.4.8 243 3. Reverse the order of the digits. Example: 244 8.4.1.0.6.4.9.7.0.2.4.4 246 4. Append the string ".e164.arpa" to the end. Example: 247 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa 249 This domain-name is used to request NAPTR records which may contain 250 the end result or, if the flags field is blank, produces new keys in 251 the form of domain-names from the DNS. 253 Some nameserver implementations attempt to be intelligent about items 254 that are inserted into the additional information section of a given 255 DNS response. For example, BIND will attempt to determine if it is 256 authoritative for a domain whenever it encodes one into a packet. If 257 it is, then it will insert any A records it finds for that domain 258 into the additional information section of the answer until the 259 packet reaches the maximum length allowed. It is therefore 260 potentially useful for a client to check for this additional 261 information. It is also easy to contemplate an ENUM enhanced 262 nameserver that understand the actual contents of the NAPTR records 263 it is serving and inserts more appropriate information into the 264 additional information section of the response. Thus, DNS servers MAY 265 interpret Flag values and use that information to include appropriate 266 resource records in the Additional Information portion of the DNS 267 packet. Clients are encouraged to check for additional information 268 but are not required to do so. See the Additional Information 269 Processing section of RFC 3403 [1], Section 4.2 for more information 270 on NAPTR records and the Additional Information section of a DNS 271 response packet. 273 The character set used to encode the substitution expression is 274 UTF-8. The allowed input characters are all those characters that are 275 allowed anywhere in an E.164 number. The characters allowed to be in 276 a Key are those that are currently defined for DNS domain-names. 278 2.4.1 Flags 280 This Database contains a field that contains flags that signal when 281 the DDDS algorithm has finished. At this time only one flag, "U", is 282 defined. This means that this Rule is the last one and that the 283 output of the Rule is a URI [3]. See RFC 3404 [2]. 285 If a client encounters a record with an unknown flag, it MUST ignore 286 it and move to the next Rule. This test takes precedence over any 287 ordering since flags can control the interpretation placed on fields. 288 A novel flag might change the interpretation of the regexp and/or 289 replacement fields such that it is impossible to determine if a 290 record matched a given target. 292 If this flag is not present then this rule is non-terminal. If a Rule 293 is non-terminal then clients MUST use the Key produced by this 294 Rewrite Rule as the new Key in the DDDS loop (i.e. causing the client 295 to query for new NAPTR records at the domain-name that is the result 296 of this Rule). 298 2.4.2 Services Parameters 300 Service Parameters for this Application take the following form and 301 are found in the Service field of the NAPTR record. 303 service_field = "E2U" 1*(servicespec) 304 servicespec = "+" enumservice 305 enumservice = type 0*(subtypespec) 306 subtypespec = ":" subtype 307 type = 1*32(ALPHA / DIGIT) 308 subtype = 1*32(ALPHA / DIGIT) 310 In other words, a non-optional "E2U" (used to denote ENUM only 311 Rewrite Rules in order to mitigate record collisions) followed by 1 312 or more or more Enumservices which indicate what class of 313 functionality a given end point offers. Each Enumservice is indicated 314 by an initial '+' character. 316 2.4.2.1 ENUM Services 318 Enumservice specifications contain the functional specification (i.e. 319 what it can be used for), the valid protocols, and the URI schemes 320 that may be returned. Note that there is no implicit mapping between 321 the textual string "type" or "subtype" in the grammar for the 322 Enumservice and URI schemes or protocols. The mapping, if any, must 323 be made explicit in the specification for the Enumservice itself. A 324 registration of a specific Type also has to specify the Subtypes 325 allowed. 327 The only exception to the registration rule is for Types and Subtypes 328 used for experimental purposes, and those are to start with the facet 329 "X-". These elements are unregistered, experimental, and should be 330 used only with the active agreement of the parties exchanging them. 332 The registration mechanism is specified in Section 3. 334 2.5 What constitutes an 'Enum Resolver'? 336 There has been some confusion over what exactly an ENUM Resolver 337 returns and what relation that has to the 'Note 1' section in RFC 338 3402. On first reading it seems as though it might be possible for an 339 ENUM Resolver to return two Rules. 341 The ENUM algorithm always returns a single rule. Specific 342 applications may have application-specific knowledge or facilities 343 that allow them to present multiple results or speed selection, but 344 these should never change the operation of the algorithm. 346 3. Registration mechanism for Enumservices 348 As specified in the ABNF found in Section 2.4.2, an 'enumservice' is 349 made up of 'types' and 'subtypes'. For any given 'type', the 350 allowable 'subtypes' must be specified in the registration. There is 351 currently no concept of a registered 'subtype' outside the scope of a 352 given 'type'. Thus the registration process uses the 'type' as its 353 main key within the IANA Registry. While the combination of each 354 type and all of its subtypes constitutes the allowed values for the 355 'enumservice' field, it is not sufficient to simply document those 356 values. A complete registration will also include the allowed URI 357 schemes, a functional specification, security considerations, 358 intended usage, and any other information needed to allow for 359 interoperability within ENUM. In order to be a registered ENUM 360 Service, the entire specification, including the template, requires 361 approval by the IESG and publication of the Enumservice registration 362 specification as an RFC. 364 3.1 Registration Requirements 366 Service registration proposals are all expected to conform to various 367 requirements laid out in the following sections. 369 3.1.1 Functionality Requirement 371 A registered Enumservice must be able to function as a selection 372 mechanism when choosing one NAPTR resource record from another. That 373 means that the registration MUST specify what is expected when using 374 that very NAPTR record, and the URI which is the outcome of the use 375 of it. 377 Specifically, a registered Enumservice MUST specify the URI scheme(s) 378 that may be used for the Enumservice, and, when needed, other 379 information which will have to be transferred into the URI resolution 380 process itself (LDAP Distinguished Names, transferring of the AUS 381 into the resulting URI, etc). 383 3.1.2 Naming requirement 385 An Enumservice MUST be unique in order to be useful as a selection 386 criteria. Since an Enumservice is made up of a type and a 387 type-dependent subtype, it is sufficient to require that the 'type' 388 itself be unique. The 'type' MUST be unique, conform to the ABNF 389 specified in Section 2.4.2, and MUST NOT start with the facet "X-" 390 which is reserved for experimental, private use. 392 The subtype, being dependent on the type, MUST be unique within a 393 given 'type'. It must conform to the ABNF specified in Section 2.4.2, 394 and MUST NOT start with the facet "X-" which is reserved for 395 experimental, private use. The subtype for one type MAY be the same 396 as a subtype for a different registered type but it is not sufficient 397 to simply reference another type's subtype. The function of each 398 subtype must be specified in the context of the type being 399 registered. 401 3.1.3 Security requirement 403 An analysis of security issues is required for all registered 404 Enumservices. (This is in accordance with the basic requirements for 405 all IETF protocols.) 407 All descriptions of security issues must be as accurate as possible 408 regardless of registration tree. In particular, a statement that 409 there are "no security issues associated with this Enumservice" must 410 not be confused with "the security issues associated with this 411 Enumservice have not been assessed". 413 There is no requirement that an Enumservice must be secure or 414 completely free from risks. Nevertheless, all known security risks 415 must be identified in the registration of an Enumservice. 417 The security considerations section of all registrations is subject 418 to continuing evaluation and modification. 420 Some of the issues that should be looked at in a security analysis of 421 an Enumservice are: 423 1. Complex Enumservices may include provisions for directives that 424 institute actions on a user's resources. In many cases provision 425 can be made to specify arbitrary actions in an unrestricted 426 fashion which may then have devastating results. Especially if 427 there is a risk for a new ENUM lookup, and because of that an 428 infinite loop in the overall resolution process of the E.164. 430 2. Complex Enumservices may include provisions for directives that 431 institute actions which, while not directly harmful, may result 432 in disclosure of information that either facilitates a subsequent 433 attack or else violates the users privacy in some way. 435 3. An Enumservice might be targeted for applications that require 436 some sort of security assurance but do not provide the necessary 437 security mechanisms themselves. For example, an Enumservice could 438 be defined for storage of confidential security services 439 information such as alarm systems or message service passcodes, 440 which in turn require an external confidentiality service. 442 3.1.4 Publication Requirements 444 Proposals for Enumservices registrations MUST be published as one of 445 the following documents; RFC on the Standards Track, Experimental 446 RFC, or as a BCP. 448 IANA will retain copies of all Enumservice registration proposals and 449 "publish" them as part of the Enumservice Registration tree itself. 451 3.2 Registration procedure 453 3.2.1 IANA Registration 455 Provided that the Enumservice has obtained the necessary approval, 456 and the RFC is published, IANA will register the Enumservice and make 457 the Enumservice registration available to the community in addition 458 to the RFC publication itself. 460 3.2.1.1 Location of Enumservice Registrations 462 Enumservice registrations will be published in the IANA repository 463 and made available via anonymous FTP at the following URI: "ftp:// 464 ftp.iana.org/assignments/enum-services/". 466 3.2.1.2 Change Control 468 Change control of Enumservices stay with the IETF via the RFC 469 publication process. Especially, Enumservice registrations may not be 470 deleted; Enumservices which are no longer believed appropriate for 471 use can be declared OBSOLETE by publication of a new RFC and a change 472 to their "intended use" field; such Enumservice will be clearly 473 marked in the lists published by IANA. 475 3.2.2 Registration Template 477 Enumservice Type: 479 Enumservice Subtype(s): 481 URI Scheme(s): 483 Functional Specification: 485 Security considerations: 487 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) 489 Author: 491 Any other information that the author deems interesting: 493 Note: In the case where a particular field has no value, that field 494 is left completely blank, especially in the case where a given type 495 has no subtypes. 497 4. Examples 499 The examples below use theoretical services that contain Enumservices 500 which might not make sense, but that are still used for educational 501 purposes. For example, the protocol used is in some cases exactly 502 the same string as the URI scheme. That was the specification in RFC 503 2916, but this 'default' specification of an Enumservice is no longer 504 allowed. All Enumservices need to be registered explicitly by the 505 procedure specified in section Section 3. 507 4.1 Example 509 $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. 510 IN NAPTR 10 100 "u" "E2U+sip" 511 "!^.*$!sip:info@example.com!" . 512 IN NAPTR 10 101 "u" "E2U+h323" 513 "!^.*$!h323:info@example.com!" . 514 IN NAPTR 10 102 "u" "E2U+msg:mailto" 515 "!^.*$!mailto:info@example.com!" . 517 This describes that the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is 518 preferably contacted by SIP, secondly via H.323 for voice, and 519 thirdly by SMTP for messaging. Note that the tokens "sip", "msg", 520 "h323", "voice" and "mailto" are Types and Subtypes registered with 521 IANA, and they have no implicit connection with the protocols or URI 522 schemes with the same names. 524 In all cases, the next step in the resolution process is to use the 525 resolution mechanism for each of the protocols, (specified by the URI 526 schemes sip, h323 and mailto) to know what node to contact for each. 528 5. IANA Considerations 530 RFC 2916 (which this document replaces) requested IANA to delegate 531 the E164.ARPA domain following instructions to be provided by the 532 IAB. The domain was delegated according to those instructions. Names 533 within this zone are to be delegated to parties according to the 534 ITU-T Recommendation E.164. The names allocated should be hierarchic 535 in accordance with ITU-T Recommendation E.164, and the codes should 536 be assigned in accordance with that Recommendation. 538 IAB is to coordinate with ITU-T TSB if the technical contact for the 539 domain e164.arpa is to change, as ITU-T TSB has an operational 540 working relationship with this technical contact which needs to be 541 reestablished. 543 Delegations in the zone e164.arpa (not delegations in delegated 544 domains of e164.arpa) should be done after Expert Review, and the 545 IESG will appoint a designated expert. 547 IANA is to create a registry for Enumservices as specified in Section 548 3. Whenever a new Enumservice is registered by the RFC process in the 549 IETF, IANA is at the time of publication of the RFC to register the 550 Enumservice and add a pointer to the RFC itself. 552 6. Security Considerations 554 6.1 DNS Security 556 As ENUM uses DNS, which in its current form is an insecure protocol, 557 there is no mechanism for ensuring that the data one gets back is 558 authentic. As ENUM is deployed on the global Internet, it is expected 559 to be a popular target for various kind of attacks, and attacking the 560 underlying DNS infrastructure is one way of attacking the ENUM 561 service itself. 563 There are multiple types of attacks that can happen against DNS that 564 ENUM implementations should be aware of. The following threats are 565 taken from Threat Analysis Of The Domain Name System [9]: 567 Packet Interception 568 Some of the simplest threats against DNS are various forms of 569 packet interception: monkey-in-the-middle attacks, eavesdropping 570 on requests combined with spoofed responses that beat the real 571 response back to the resolver, and so forth. In any of these 572 scenarios, the attacker can simply tell either party (usually the 573 resolver) whatever it wants that party to believe. While packet 574 interception attacks are far from unique to DNS, DNS's usual 575 behavior of sending an entire query or response in a single 576 unsigned, unencrypted UDP packet makes these attacks particularly 577 easy for any bad guy with the ability to intercept packets on a 578 shared or transit network. 580 ID Guessing and Query Prediction 581 Since the ID field in the DNS header is only a 16-bit field and 582 the server UDP port associated with DNS is a well-known value, 583 there are only 2**32 possible combinations of ID and client UDP 584 port for a given client and server. Thus it is possible for a 585 reasonable brute force attack to allow an attacker to masquerade 586 as a trusted server. In most respects, this attack is similar to a 587 packet interception attack except that it does not require the 588 attacker to be on a transit or shared network. 590 Name-based Attacks 591 Name-based attacks use the actual DNS caching behavior as a tool 592 to insert bad data into a victim's cache, thus potentially 593 subverting subsequent decisions based on DNS names. Most examples 594 occur with CNAME, NS and DNAME Resource Records as they redirect a 595 victim's query to another location. The common thread in all of 596 these attacks is that response messages allow the attacker to 597 introduce arbitrary DNS names of the attacker's choosing and 598 provide further information that the attacker claims is associated 599 with those names; unless the victim has better knowledge of the 600 data associated with those names, the victim is going to have a 601 hard time defending against this class of attacks. 603 Betrayal By A Trusted Server 604 Another variation on the packet interception attack is the trusted 605 server that turns out not to be so trustworthy, whether by 606 accident or by intent. Many client machines are only configured 607 with stub resolvers, and use trusted servers to perform all of 608 their DNS queries on their behalf. In many cases the trusted 609 server is furnished by the user's ISP and advertised to the client 610 via DHCP or PPP options. Besides accidental betrayal of this 611 trust relationship (via server bugs, successful server break-ins, 612 etc), the server itself may be configured to give back answers 613 that are not what the user would expect (whether in an honest 614 attempt to help the user or to further some other goal such as 615 furthering a business partnership between the ISP and some third 616 party). 618 Denial of Service 619 As with any network service (or, indeed, almost any service of any 620 kind in any domain of discourse), DNS is vulnerable to denial of 621 service attacks. DNS servers are also at risk of being used as 622 denial of service amplifiers, since DNS response packets tend to 623 be significantly longer than DNS query packets. 625 Authenticated Denial of Domain Names 626 The existence of RR types whose absence causes an action other 627 than immediate failure (such as missing MX and SRV RRs, which fail 628 over to A RRs) constitutes a real threat. In the specific case of 629 ENUM, even the immediate failure of a missing RR can be considered 630 a problem as a method for changing call routing policy. 632 Because of these threats, a deployed ENUM service SHOULD include 633 mechanisms which ameliorate these threats. Most of these threats can 634 be solved by verifying the authenticity of the data via mechanisms 635 such as DNSSEC [7] once it is deployed. Others, such and Denial Of 636 Service attacks, cannot be solved by data authentication. It is 637 important to remember that these threats include not only the NAPTR 638 lookups themselves, but also the various records needed for the 639 services to be useful (for example NS, MX, SRV and A records). 641 Even if DNSSEC is deployed, a service that uses ENUM for address 642 translation should not blindly trust that the peer is the intended 643 party as all kind of attacks against DNS can not be protected against 644 with DNSSEC. A service should always authenticate the peers as part 645 of the setup process for the service itself and never blindly trust 646 any kind of addressing mechanism. 648 Finally, as an ENUM service will be implementing some type of 649 security mechanism, software which implements ENUM MUST be prepared 650 to receive DNSSEC and other standardized DNS security responses, 651 including large responses, EDNS0 signaling, unknown RRs, etc. 653 6.2 Caching Security 655 The caching in DNS can make the propagation time for a change take 656 the same amount of time as the time to live for the NAPTR records in 657 the zone that is changed. The use of this in an environment where 658 IP-addresses are for hire (for example, when using DHCP [8]) must 659 therefore be done very carefully. 661 6.3 Call Routing Security 663 There are a number of countries (and other numbering environments) in 664 which there are multiple providers of call routing and number/name- 665 translation services. In these areas, any system that permits users, 666 or putative agents for users, to change routing or supplier 667 information may provide incentives for changes that are actually 668 unauthorized (and, in some cases, for denial of legitimate change 669 requests). Such environments should be designed with adequate 670 mechanisms for identification and authentication of those requesting 671 changes and for authorization of those changes. 673 6.4 URI Resolution Security 675 A large amount of Security Issues have to do with the resolution 676 process itself, and use of the URIs produced by the DDDS mechanism. 677 Those have to be specified in the registration of the Enumservice 678 used, as specified in Section 3.1.3. 680 7. Acknowledgments 682 Support and ideas leading to RFC 2916 have come from people at 683 Ericsson, Bjorn Larsson and the group which implemented this scheme 684 in their lab to see that it worked. Input has also arrived from 685 ITU-T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and 686 Enumservice Definition), the ENUM working group in the IETF, John 687 Klensin and Leif Sunnegardh. 689 This update of RFC 2916 is created with specific input from: Randy 690 Bush, David Conrad, Richard Hill, Jon Peterson, Jim Reid, Joakim 691 Stralmark, Robert Walter and James Yu. 693 8. Changes since RFC 2916 695 Part from clarifications in the text in this document, the major 696 changes are two: 698 The document uses an explicit DDDS algorithm, and not only NAPTR 699 resource records in an "ad-hoc" mode. In reality this doesn't imply 700 any changes in deployed base of applications, as the algorithm used 701 for ENUM resolution is exactly the same. 703 The format of the service field has changed. The old format was of 704 the form "example+E2U", while the new format is "E2U+example". Reason 705 for this change have to with the added subtypes in the enumservice, 706 the ability to support more than one enumservice per NAPTR RR, and a 707 general agreement in the IETF that the main selector between 708 different NAPTR with the same owner (E2U in this case) should be 709 first. 711 Normative References 713 [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 714 Three: The DNS Database", RFC 3403, February 2002. 716 [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 717 Four: The URI Resolution Application", RFC 3404, February 2002. 719 [3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 720 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 722 [4] ITU-T, "The International Public Telecommunication Number Plan", 723 Recommendation E.164, May 1997. 725 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 726 One: The Comprehensive DDDS Standard", RFC 3401, February 2002. 728 [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 729 Two: The Algorithm", RFC 3402, February 2002. 731 Non-normative references 733 [7] Eastlake, D., "Domain Name System Security Extensions", RFC 734 2535, March 1999. 736 [8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 737 March 1997. 739 [9] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name 740 System", draft-ietf-dnsext-dns-threats-01 (work in progress), 741 February 2002. 743 Authors' Addresses 745 Patrik Faltstrom 746 Cisco Systems Inc 747 Ledasa 748 273 71 Lovestad 749 Sweden 751 EMail: paf@cisco.com 752 URI: http://www.cisco.com 754 Michael Mealling 755 VeriSign 756 21345 Ridgetop Circle 757 Sterling, VA 20166 758 US 760 URI: http://www.verisignlabs.com 762 Intellectual Property Statement 764 The IETF takes no position regarding the validity or scope of any 765 intellectual property or other rights that might be claimed to 766 pertain to the implementation or use of the technology described in 767 this document or the extent to which any license under such rights 768 might or might not be available; neither does it represent that it 769 has made any effort to identify any such rights. Information on the 770 IETF's procedures with respect to rights in standards-track and 771 standards-related documentation can be found in BCP-11. Copies of 772 claims of rights made available for publication and any assurances of 773 licenses to be made available, or the result of an attempt made to 774 obtain a general license or permission for the use of such 775 proprietary rights by implementors or users of this specification can 776 be obtained from the IETF Secretariat. 778 The IETF invites any interested party to bring to its attention any 779 copyrights, patents or patent applications, or other proprietary 780 rights which may cover technology that may be required to practice 781 this standard. Please address the information to the IETF Executive 782 Director. 784 Full Copyright Statement 786 Copyright (C) The Internet Society (2003). All Rights Reserved. 788 This document and translations of it may be copied and furnished to 789 others, and derivative works that comment on or otherwise explain it 790 or assist in its implementation may be prepared, copied, published 791 and distributed, in whole or in part, without restriction of any 792 kind, provided that the above copyright notice and this paragraph are 793 included on all such copies and derivative works. However, this 794 document itself may not be modified in any way, such as by removing 795 the copyright notice or references to the Internet Society or other 796 Internet organizations, except as needed for the purpose of 797 developing Internet standards in which case the procedures for 798 copyrights defined in the Internet Standards process must be 799 followed, or as required to translate it into languages other than 800 English. 802 The limited permissions granted above are perpetual and will not be 803 revoked by the Internet Society or its successors or assignees. 805 This document and the information contained herein is provided on an 806 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 807 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 808 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 809 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 810 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 812 Acknowledgement 814 Funding for the RFC Editor function is currently provided by the 815 Internet Society.