idnits 2.17.1 draft-ietf-enum-rfc2916bis-06.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 (May 12, 2003) is 7656 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 741, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 744, 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' -- 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: 2 errors (**), 0 flaws (~~), 6 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: November 10, 2003 VeriSign 6 May 12, 2003 8 The E.164 to URI DDDS Application (ENUM) 9 draft-ietf-enum-rfc2916bis-06.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 November 10, 2003. 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 . . . . . . . . . . 10 63 3.1 Registration Requirements . . . . . . . . . . . . . . . . . 10 64 3.1.1 Functionality Requirement . . . . . . . . . . . . . . . . . 10 65 3.1.2 Naming requirement . . . . . . . . . . . . . . . . . . . . . 10 66 3.1.3 Security requirement . . . . . . . . . . . . . . . . . . . . 11 67 3.1.4 Publication Requirements . . . . . . . . . . . . . . . . . . 12 68 3.2 Registration procedure . . . . . . . . . . . . . . . . . . . 12 69 3.2.1 IANA Registration . . . . . . . . . . . . . . . . . . . . . 12 70 3.2.2 Registration Template . . . . . . . . . . . . . . . . . . . 12 71 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 74 6. Security Considerations . . . . . . . . . . . . . . . . . . 16 75 6.1 DNS Security . . . . . . . . . . . . . . . . . . . . . . . . 16 76 6.2 Caching Security . . . . . . . . . . . . . . . . . . . . . . 18 77 6.3 Call Routing Security . . . . . . . . . . . . . . . . . . . 18 78 6.4 URI Resolution Security . . . . . . . . . . . . . . . . . . 18 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 80 8. Changes since RFC 2916 . . . . . . . . . . . . . . . . . . . 20 81 Normative References . . . . . . . . . . . . . . . . . . . . 21 82 Non-normative references . . . . . . . . . . . . . . . . . . 22 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 84 Intellectual Property and Copyright Statements . . . . . . . 23 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 domain name in a 93 decentralized way with distributed management of the different levels 94 in the lookup 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 specifies how "ENUM" works, that is how to handle 121 numbers allocated according to the ITU-T recommendation E.164. But, a 122 similar mechanism can be used also for other numbers, such as private 123 dialing plans. To implement that (a) the suffix MUST be selected, 124 MUST NOT be e164.arpa, MUST be known for all parties using the same 125 dialing plan (b) the application unique string SHOULD be the full 126 number as specified but without the leading '+'. 128 1.3 Application of local policy 130 The Order field in the NAPTR record specifies in what order the DNS 131 records are to be interpreted. This is because DNS does not guarantee 132 the order of records returned in the answer section of a DNS packet. 133 In most ENUM cases this isn't an issue because the typical regular 134 expression will be '!^.*$!' since the first query often results in a 135 terminal Rule. 137 But there are other cases (non-terminal Rules) where two different 138 Rules both match the given Application Unique String. As each Rule is 139 evaluated within the algorithm, one may match a more significant 140 piece of the AUS than the other. For example, by using a non-terminal 141 NAPTR a given set of numbers is sent to some 142 private-dialing-plan-specific zone. Within that zone there are two 143 Rules that state that if a match is for the entire exchange and the 144 service is SIP related then the first, SIP-specific rule is used. But 145 the other Rule matches a longer piece of the AUS, specifying that for 146 some other service (instant messaging) that the Rule denotes a 147 departmental level service. If the shorter matching Rule comes before 148 the longer match, it can 'mask' the other rules. Thus, the order in 149 which each Rule is tested against the AUS is an important corner case 150 that many DDDS applications take advantage of. 152 In the case where the zone authority wishes to state that two Rules 153 have the same effect or are identical in usage, then the Order for 154 those records is set to the same value. In that case, the Preference 155 is used to specify a locally over-ridable suggestion by the zone 156 authority that one Rule might simply be better than another for some 157 reason. 159 For ENUM this specifies where a client is allowed to apply local 160 policy and where it is not. The Order field in the NAPTR is a 161 request from the holder of the E.164 number that the records be 162 handled in a specific way. The Preference field is merely a 163 suggestion from that E.164 holder that one record might be better 164 than another. A client implementing ENUM MUST adhere to the Order 165 field but can simply take the Preference value "on advisement" as 166 part of a client context specific selection method. 168 2. The ENUM Application Specifications 170 This template defines the ENUM DDDS Application according to the 171 rules and requirements found in [1]. The DDDS database used by this 172 Application is found in [2] which is the document that defines the 173 NAPTR DNS Resource Record type. 175 ENUM is only applicable for E.164 numbers. ENUM compliant 176 applications MUST only query DNS for what it believes is an E.164 177 number. Since there are numerous dialing plans which can change over 178 time , it is probably impossible for a client application to have 179 perfect knowledge about every valid and dialable E.164 number. 180 Therefore a client application, doing everything within its power, 181 can end up with what it thinks is a syntactically correct E.164 182 number which in reality is not actually valid or dialable. This 183 implies that applications MAY send DNS queries when, for example, a 184 user mistypes a number in a user interface. Because of this, there is 185 the risk that collisions between E.164 numbers and non-E.164 numbers 186 can occur. To mitigate this risk, the E2U portion of the service 187 field MUST NOT be used for non-E.164 numbers. 189 2.1 Application Unique String 191 The Application Unique String is a fully qualified E.164 number minus 192 any non-digit characters except for the '+' character which appears 193 at the beginning of the number. The "+" is kept to provide a well 194 understood anchor for the AUS in order to distinguish it from other 195 telephone numbers that are not part of the E.164 namespace. 197 For example, the E.164 number could start out as "+1-770-923-9595". 198 To ensure that no syntactic sugar is allowed into the AUS, all 199 non-digits except for "+" are removed, yielding "+17709239595". 201 2.2 First Well Known Rule 203 The First Well Known Rule for this Application is the identity rule. 204 The output of this rule is the same as the input. This is because the 205 E.164 namespace and this Applications databases are organized in such 206 a way that it is possible to go directly from the name to the 207 smallest granularity of the namespace directly from the name itself. 209 Take the previous example, the AUS is "+17709239595". Applying the 210 First Well Known Rule produces the exact same string, "+17709239595". 212 2.3 Expected Output 214 The output of the last DDDS loop is a Uniform Resource Identifier in 215 its absolute form according to the 'absoluteURI' production in the 216 Collected ABNF found in RFC2396 [3]. 218 2.4 Valid Databases 220 At present only one DDDS Database is specified for this Application. 221 "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS 222 Database" (RFC 3403) [2] specifies a DDDS Database that uses the 223 NAPTR DNS resource record to contain the rewrite rules. The Keys for 224 this database are encoded as domain-names. 226 The output of the First Well Known Rule for the ENUM Application is 227 the E.164 number minus all non-digit characters except for the +. In 228 order to convert this to a unique key in this Database the string is 229 converted into a domain-name according to this algorithm: 231 1. Remove all characters with the exception of the digits. For 232 example, the First Well Known Rule produced the Key 233 "+4689761234". This step would simply remove the leading "+", 234 producing "4689761234". 236 2. Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 238 3. Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 240 4. Append the string ".e164.arpa" to the end. Example: 241 4.3.2.1.6.7.9.8.6.4.e164.arpa 243 This domain-name is used to request NAPTR records which may contain 244 the end result or, if the flags field is blank, produces new keys in 245 the form of domain-names from the DNS. 247 Some nameserver implementations attempt to be intelligent about items 248 that are inserted into the additional information section of a given 249 DNS response. For example, BIND will attempt to determine if it is 250 authoritative for a domain whenever it encodes one into a packet. If 251 it is, then it will insert any A records it finds for that domain 252 into the additional information section of the answer until the 253 packet reaches the maximum length allowed. It is therefore 254 potentially useful for a client to check for this additional 255 information. It is also easy to contemplate an ENUM enhanced 256 nameserver that understand the actual contents of the NAPTR records 257 it is serving and inserts more appropriate information into the 258 additional information section of the response. Thus, DNS servers MAY 259 interpret Flag values and use that information to include appropriate 260 resource records in the Additional Information portion of the DNS 261 packet. Clients are encouraged to check for additional information 262 but are not required to do so. See the Additional Information 263 Processing section of RFC 3403 [1], Section 4.2 for more information 264 on NAPTR records and the Additional Information section of a DNS 265 response packet. 267 The character set used to encode the substitution expression is 268 UTF-8. The allowed input characters are all those characters that are 269 allowed anywhere in an E.164 number. The characters allowed to be in 270 a Key are those that are currently defined for DNS domain-names. 272 2.4.1 Flags 274 This Database contains a field that contains flags that signal when 275 the DDDS algorithm has finished. At this time only one flag, "U", is 276 defined. This means that this Rule is the last one and that the 277 output of the Rule is a URI [3]. See RFC 3404 [2]. 279 If a client encounters a record with an unknown flag, it MUST ignore 280 it and move to the next Rule. This test takes precedence over any 281 ordering since flags can control the interpretation placed on fields. 282 A novel flag might change the interpretation of the regexp and/or 283 replacement fields such that it is impossible to determine if a 284 record matched a given target. 286 If this flag is not present then this rule is non-terminal. If a Rule 287 is non-terminal then clients MUST use the Key produced by this 288 Rewrite Rule as the new Key in the DDDS loop (i.e. causing the client 289 to query for new NAPTR records at the domain-name that is the result 290 of this Rule). 292 2.4.2 Services Parameters 294 Service Parameters for this Application take the following form and 295 are found in the Service field of the NAPTR record. 297 service_field = "E2U" 1*(servicespec) 298 servicespec = "+" enumservice 299 enumservice = type 0*(subtypespec) 300 subtypespec = ":" subtype 301 type = 1*32(ALPHA / DIGIT) 302 subtype = 1*32(ALPHA / DIGIT) 304 In other words, a non-optional "E2U" (used to denote ENUM only 305 Rewrite Rules in order to mitigate record collisions) followed by 1 306 or more or more Enumservices which indicate what class of 307 functionality a given end point offers. Each Enumservice is indicated 308 by an initial '+' character. 310 2.4.2.1 ENUM Services 312 Enumservice specifications contain the functional specification (i.e. 313 what it can be used for), the valid protocols, and the URI schemes 314 that may be returned. Note that there is no implicit mapping between 315 the textual string "type" or "subtype" in the grammar for the 316 Enumservice and URI schemes or protocols. The mapping, if any, have 317 to be made explicit in the specification for the Enumservice itself. 318 A registration of a specific Type also have to specify the Subtypes 319 allowed. 321 The only exception to the registration rule is for Types and Subtypes 322 used for experimental purposes, and those are to start with the facet 323 "X-". These elements are unregistered, experimental, and should be 324 used only with the active agreement of the parties exchanging them. 326 The registration mechanism is specified in Section 3. 328 2.5 What constitutes an 'Enum Resolver'? 330 There has been some confusion over what exactly an ENUM Resolver 331 returns and what relation that has to the 'Note 1' section in RFC 332 3402. On first reading it seems as though it might be possible for an 333 ENUM Resolver to return two Rules. The answer to that depends on 334 which of two possible definitions you use for an ENUM Resolver: 336 The first type of resolver can be called an 'intelligent' resolver. 337 It understands its target application very well. In that case the 338 test done at the beginning of Step 4 in the algorithm is a very 339 complex one. It can include call backs to the calling thread, GUI 340 events, etc. Its at this point that a client can be presented with 341 the idea of "multiple Rules" because its at this step that Order is 342 understood relative to the other ordered records. In this case the 343 ENUM Resolver still returns one Rule to the calling application but 344 its smart enough internally that it can apply application specific 345 knowledge to the Rule selection test. 347 The other type of resolver can be called a 'dumb' or 'driven' 348 resolver. It is generic in the sense that there is no internal 349 application knowledge. It is run from the 'outside' by a smart 350 application that changes the selection criteria that are fed to the 351 ENUM Resolver before it starts its resolution task. It returns one 352 Rule only and the caller has to determine if that Rule is OK or not. 353 If it isn't then it re-runs the resolver with a new set of selection 354 criteria. Some might consider the combination of this dumb resolver 355 and the application that's driving it as some uber-ENUM-Resolver. In 356 that case it can "return more than one Rule" because it can simply 357 re-run the algorithm several times to collect an appropriate set of 358 Rules. But that uber-ENUM-Resolver is stretching the definition of an 359 ENUM Resolver to the point of being unrecognizable. 361 The key point is that the Algorithm only returns one Rule. 363 3. Registration mechanism for Enumservices 365 As specified in the ABNF found in Section 2.4.2, an 'enumservice' is 366 made up of 'types' and 'subtypes'. For any given 'type', the 367 allowable 'subtypes' must be specified in the registration. There is 368 currently no concept of a registered 'subtype' outside the scope of a 369 given 'type'. Thus the registration process uses the 'type' as its 370 main key within the IANA Registry. While the combination of each 371 type and all of its subtypes constitutes the allowed values for the 372 'enumservice' field, it is not sufficient to simply document those 373 values. A complete registration will also include the allowed URI 374 schemes, a functional specification, security considerations, 375 intended usage, and any other information needed to allow for 376 interoperability within ENUM. In order to be a registered ENUM 377 Service, the entire specification, including the template, requires 378 approval by the IESG and publication of the Enumservice registration 379 specification as an RFC. 381 3.1 Registration Requirements 383 Service registration proposals are all expected to conform to various 384 requirements laid out in the following sections. 386 3.1.1 Functionality Requirement 388 A registered Enumservice must be able to function as a selection 389 mechanism when choosing one NAPTR resource record from another. That 390 means that the registration MUST specify what is expected when using 391 that very NAPTR record, and the URI which is the outcome of the use 392 of it. 394 Specifically, a registered Enumservice MUST specify the URI scheme(s) 395 that may be used for the Enumservice, and, when needed, other 396 information which will have to be transfered into the URI resolution 397 process itself (LDAP Distinguished Names, transferring of the AUS 398 into the resulting URI, etc). 400 3.1.2 Naming requirement 402 The Enumservice MUST be unique in order to be useful as a selection 403 criteria. Since the Enumservice is made up of a type and a 404 type-dependent subtype, it is sufficient to require that the 'type' 405 itself be unique. The 'type' MUST be unique, conform to the ABNF 406 specified in Section 2.4.2, and MUST NOT start with the facet "X-" 407 which is reserved for experimental, private use. 409 The subtype, being dependent on the type, MUST be unique within a 410 given 'type'. It must conform to the ABNF specified in Section 2.4.2, 411 and MUST NOT start with the facet "X-" which is reserved for 412 experimental, private use. The subtype for one type MAY be the same 413 as a subtype for a different registered type but it is not sufficient 414 to simply reference another type's subtype. The function of each 415 subtype must be specified in the context of the type being 416 registered. 418 3.1.3 Security requirement 420 An analysis of security issues is required for all registered 421 Enumservices. (This is in accordance with the basic requirements for 422 all IETF protocols.) 424 All descriptions of security issues must be as accurate as possible 425 regardless of registration tree. In particular, a statement that 426 there are "no security issues associated with this Enumservice" must 427 not be confused with "the security issues associates with this 428 Enumservice have not been assessed". 430 There is no requirement that Enumservices registered must be secure 431 or completely free from risks. Nevertheless, all known security 432 risks must be identified in the registration of a Enumservice. 434 The security considerations section of all registrations is subject 435 to continuing evaluation and modification. 437 Some of the issues that should be looked at in a security analysis of 438 a Enumservice are: 440 1. Complex Enumservices may include provisions for directives that 441 institute actions on a user's resources. In many cases provision 442 can be made to specify arbitrary actions in an unrestricted 443 fashion which may then have devastating results. Especially if 444 there is a risk for a new ENUM lookup, and because of that an 445 infinite loop in the overall resolution process of the E.164. 447 2. Complex Enumservices may include provisions for directives that 448 institute actions which, while not directly harmful, may result 449 in disclosure of information that either facilitates a subsequent 450 attack or else violates the users privacy in some way. 452 3. An Enumservice might be targeted for applications that require 453 some sort of security assurance but do not provide the necessary 454 security mechanisms themselves. For example, a Enumservice could 455 be defined for storage of confidential security services 456 information such as alarm systems or message service passcodes, 457 which in turn require an external confidentiality service. 459 3.1.4 Publication Requirements 461 Proposals for Enumservices registered must be published as RFCs on 462 the Standards Track or as a BCP. IANA will retain copies of all 463 Enumservice registration proposals and "publish" them as part of the 464 ENUM Enumservice Registration tree itself. 466 3.2 Registration procedure 468 3.2.1 IANA Registration 470 Provided that the Enumservice has obtained the necessary approval, 471 and the RFC is published, IANA will register the Enumservice and make 472 the Enumservice registration available to the community in addition 473 to the RFC publication itself. 475 3.2.1.1 Location of ENUM Enumservice Registrations 477 Enumservice registrations will be published in the IANA repository 478 and made available via anonymous FTP at the following URI: "ftp:// 479 ftp.iana.org/assignments/enum-services/". 481 3.2.1.2 Change Control 483 Change control of Enumservices stay with the IETF via the RFC 484 publication process. Especially, Enumservice registrations may not be 485 deleted; Enumservices which are no longer believed appropriate for 486 use can be declared OBSOLETE by publication of a new RFC and a change 487 to their "intended use" field; such Enumservice will be clearly 488 marked in the lists published by IANA. 490 3.2.2 Registration Template 492 Enumservice Type: 494 Enumservice Subtype(s): 496 URI Scheme(s): 498 Functional Specification: 500 Security considerations: 502 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) 504 Author: 506 Any other information that the author deems interesting: 508 Note: In the case where a particular field has no value, that field 509 is left completely blank, especially in the case where a given type 510 has no subtypes. 512 4. Examples 514 The examples below use theoretical services which uses Enumservices 515 which might not make sense, but they are still used for educational 516 purposes. For example, the protocol used is in some cases exactly 517 the the same string as the URI scheme. That was the specification in 518 RFC 2916, but this default specification of a Enumservice is no 519 longer allowed. All Enumservices need to be registered explicitly by 520 the procedure specified in section Section 3. 522 4.1 Example 524 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. 525 IN NAPTR 10 100 "u" "E2U+sip" 526 "!^.*$!sip:info@example.com!" . 527 IN NAPTR 10 101 "u" "E2U+h323" 528 "!^.*$!h323:info@example.com!" . 529 IN NAPTR 10 102 "u" "E2U+msg:mailto" 530 "!^.*$!mailto:info@example.com!" . 532 This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is 533 preferably contacted by SIP, secondly via H.323 for voice, and 534 thirdly by SMTP for messaging. Note that the tokens "sip", "msg", 535 "h323", "voice" and "mailto" are Types and Subtypes registered with 536 IANA, and they have no implicit connection with the protocols or URI 537 schemes with the same names. 539 In all cases, the next step in the resolution process is to use the 540 resolution mechanism for each of the protocols, (specified by the URI 541 schemes sip, h323 and mailto) to know what node to contact for each. 543 5. IANA Considerations 545 This memo requests that the IANA delegate the E164.ARPA domain 546 following instructions to be provided by the IAB. Names within this 547 zone are to be delegated to parties according to the ITU-T 548 Recommendation E.164. The names allocated should be hierarchic in 549 accordance with ITU-T Recommendation E.164, and the codes should 550 assigned in accordance with that Recommendation. 552 IAB is to coordinate with ITU-T TSB if the technical contact for the 553 domain e164.arpa is to change, as ITU-T TSB has an operational 554 working relationship with this technical contact which needs to be 555 reestablished. 557 Delegations in the zone e164.arpa (not delegations in delegated 558 domains of e164.arpa) should be done after Expert Review, and the 559 IESG will appoint a designated expert. 561 IANA is to create a registry for ENUM Enumservices as specified in 562 Section 3. Whenever a new ENUM Enumservice is registered by the RFC 563 process in the IETF, IANA is at the time of publication of the RFC to 564 register the Enumservice and add a pointer to the RFC itself. 566 6. Security Considerations 568 6.1 DNS Security 570 As ENUM uses DNS, which in its current form is an insecure protocol, 571 there is no mechanism for ensuring that the data one gets back is 572 authentic. As ENUM is deployed on the global Internet, it is expected 573 to be a popular target for various kind of attacks, and attacking the 574 underlying DNS infrastructure is one way of attacking the ENUM 575 service itself. 577 There are multiple types of attacks that can happen against DNS that 578 ENUM implementations should be aware of. The following threats are 579 taken from Threat Analysis Of The Domain Name System [9]: 581 Packet Interception 582 Some of the simplest threats against DNS are various forms of 583 packet interception: monkey-in-the-middle attacks, eavesdropping 584 on requests combined with spoofed responses that beat the real 585 response back to the resolver, and so forth. In any of these 586 scenarios, the attacker can simply tell either party (usually the 587 resolver) whatever it wants that party to believe. While packet 588 interception attacks are far from unique to DNS, DNS's usual 589 behavior of sending an entire query or response in a single 590 unsigned, unencrypted UDP packet makes these attacks particularly 591 easy for any bad guy with the ability to intercept packets on a 592 shared or transit network. 594 ID Guessing and Query Prediction 595 Since the ID field in the DNS header is only a 16-bit field and 596 the server UDP port associated with DNS is a well-known value, 597 there are only 2**32 possible combinations of ID and client UDP 598 port for a given client and server. Thus it is possible for a 599 reasonable brut force attack to allow an attacker to masquerade as 600 a trusted server. In most respects, this attack is similar to a 601 packet interception attack except that it does not require the 602 attacker to be on a transit or shared network. 604 Name-based Attacks 605 Name-based attacks use the actual DNS caching behavior as a tool 606 to insert bad data into a victim's cache, thus potentially 607 subverting subsequent decisions based on DNS names. Most examples 608 occur with CNAME, NS and DNAME Resource Records as they redirect a 609 victim's query to another location. The common thread in all of 610 these attacks is that response messages allow the attacker to 611 introduce arbitrary DNS names of the attacker's choosing and 612 provide further information that the attacker claims is associated 613 with those names; unless the victim has better knowledge of the 614 data associated with those names, the victim is going to have a 615 hard time defending against this class of attacks. 617 Betrayal By A Trusted Server 618 Another variation on the packet interception attack is the trusted 619 server that turns out not to be so trustworthy, whether by 620 accident or by intent. Many client machines are only configured 621 with stub resolvers, and use trusted servers to perform all of 622 their DNS queries on their behalf. In many cases the trusted 623 server is furnished by the user's ISP and advertised to the client 624 via DHCP or PPP options. Besides accidental betrayal of this 625 trust relationship (via server bugs, successful server break-ins, 626 etc), the server itself may be configured to give back answers 627 that are not what the user would expect (whether in an honest 628 attempt to help the user or to further some other goal such as 629 furthering a business partnership between the ISP and some third 630 party). 632 Denial of Service 633 As with any network service (or, indeed, almost any service of any 634 kind in any domain of discourse), DNS is vulnerable to denial of 635 service attacks. DNS servers are also at risk of being used as 636 denial of service amplifiers, since DNS response packets tend to 637 be significantly longer than DNS query packets. 639 Authenticated Denial of Domain Names 640 The existence of RR types whose absence causes an action other 641 than immediate failure (such as missing MX and SRV RRs, which fail 642 over to A RRs) constitutes a real threat. In the specific case of 643 ENUM, even the immediate failure of a missing RR can be considered 644 a problem as a method for changing call routing policy. 646 Because of these threats, a deployed ENUM service SHOULD include 647 mechanisms which ameliorate these threats. Most of these threats can 648 be solved by verifying the authenticity of the data via mechanisms 649 such as DNSSEC [7] once it is deployed. Others, such and Denial Of 650 Service attacks, cannot be solved by data authentication. It is 651 important to remember that these threats include not only the NAPTR 652 lookups themselves, but also the various records needed for the 653 services to be useful (for example NS, MX, SRV and A records). 655 Even if DNSSEC is deployed, a service which uses ENUM for address 656 translation should not blindly trust that the peer is the intended 657 party as all kind of attacks against DNS can not be protected against 658 with DNSSEC. A service should always authenticate the peers as part 659 of the setup process for the service itself and never blindly trust 660 any kind of addressing mechanism. 662 Finally, as an ENUM service will be implementing some type of 663 security mechanism, software which implements ENUM MUST be prepared 664 to receive DNSSEC and other standardized DNS security responses, 665 including large responses, EDNS0 signaling, unknown RRs, etc. 667 6.2 Caching Security 669 The caching in DNS can make the propagation time for a change take 670 the same amount of time as the time to live for the NAPTR records in 671 the zone that is changed. The use of this in an environment where 672 IP-addresses are for hire (for example, when using DHCP [8]) must 673 therefore be done very carefully. 675 6.3 Call Routing Security 677 There are a number of countries (and other numbering environments) in 678 which there are multiple providers of call routing and number/name- 679 translation services. In these areas, any system that permits users, 680 or putative agents for users, to change routing or supplier 681 information may provide incentives for changes that are actually 682 unauthorized (and, in some cases, for denial of legitimate change 683 requests). Such environments should be designed with adequate 684 mechanisms for identification and authentication of those requesting 685 changes and for authorization of those changes. 687 6.4 URI Resolution Security 689 A large amount of Security Issues have to do with the resolution 690 process itself, and use of the URIs produced by the DDDS mechanism. 691 Those have to be specified in the registration of the ENUM 692 Enumservice used, as specified in Section 3.1.3. 694 7. Acknowledgments 696 Support and ideas leading to RFC 2916 have come from people at 697 Ericsson, Bjorn Larsson and the group which implemented this scheme 698 in their lab to see that it worked. Input has also arrived from 699 ITU-T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and 700 Enumservice Definition), the ENUM working group in the IETF, John 701 Klensin and Leif Sunnegardh. 703 This update of RFC 2916 is created with specific input from: Randy 704 Bush, David Conrad, Richard Hill, Jon Peterson, Jim Reid, Joakim 705 Stralmark, Robert Walter and James Yu. 707 8. Changes since RFC 2916 709 Part from clarifications in the text in this document, the major 710 changes are two: 712 The document uses an explicit DDDS algorithm, and not only NAPTR 713 resource records in an "ad-hoc" mode. In reality this doesn't imply 714 any changes in deployed base of applications, as the algorithm used 715 for ENUM resolution is exactly the same. 717 The format of the service field has changed. The old format was of 718 the form "example+E2U", while the new format is "E2U+example". Reason 719 for this change have to with the added subtypes in the enumservice, 720 the ability to support more than one enumservice per NAPTR RR, and a 721 general agreement in the IETF that the main selector between 722 different NAPTR with the same owner (E2U in this case) should be 723 first. 725 Normative References 727 [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 728 Three: The DNS Database", RFC 3403, February 2002. 730 [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 731 Four: The URI Resolution Application", RFC 3404, February 2002. 733 [3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 734 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 736 [4] ITU-T, "The International Public Telecommunication Number Plan", 737 Recommendation E.164, May 1997. 739 Non-normative references 741 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 742 One: The Comprehensive DDDS Standard", RFC 3401, February 2002. 744 [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 745 Two: The Algorithm", RFC 3402, February 2002. 747 [7] Eastlake, D., "Domain Name System Security Extensions", RFC 748 2535, March 1999. 750 [8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 751 March 1997. 753 [9] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name 754 System", draft-ietf-dnsext-dns-threats-01 (work in progress), 755 February 2002. 757 Authors' Addresses 759 Patrik Faltstrom 760 Cisco Systems Inc 761 Ledasa 762 273 71 Lovestad 763 Sweden 765 EMail: paf@cisco.com 766 URI: http://www.cisco.com 768 Michael Mealling 769 VeriSign 770 21345 Ridgetop Circle 771 Sterling, VA 20166 772 US 774 EMail: michael@neonym.net 775 URI: http://www.verisignlabs.com 777 Intellectual Property Statement 779 The IETF takes no position regarding the validity or scope of any 780 intellectual property or other rights that might be claimed to 781 pertain to the implementation or use of the technology described in 782 this document or the extent to which any license under such rights 783 might or might not be available; neither does it represent that it 784 has made any effort to identify any such rights. Information on the 785 IETF's procedures with respect to rights in standards-track and 786 standards-related documentation can be found in BCP-11. Copies of 787 claims of rights made available for publication and any assurances of 788 licenses to be made available, or the result of an attempt made to 789 obtain a general license or permission for the use of such 790 proprietary rights by implementors or users of this specification can 791 be obtained from the IETF Secretariat. 793 The IETF invites any interested party to bring to its attention any 794 copyrights, patents or patent applications, or other proprietary 795 rights which may cover technology that may be required to practice 796 this standard. Please address the information to the IETF Executive 797 Director. 799 Full Copyright Statement 801 Copyright (C) The Internet Society (2003). All Rights Reserved. 803 This document and translations of it may be copied and furnished to 804 others, and derivative works that comment on or otherwise explain it 805 or assist in its implementation may be prepared, copied, published 806 and distributed, in whole or in part, without restriction of any 807 kind, provided that the above copyright notice and this paragraph are 808 included on all such copies and derivative works. However, this 809 document itself may not be modified in any way, such as by removing 810 the copyright notice or references to the Internet Society or other 811 Internet organizations, except as needed for the purpose of 812 developing Internet standards in which case the procedures for 813 copyrights defined in the Internet Standards process must be 814 followed, or as required to translate it into languages other than 815 English. 817 The limited permissions granted above are perpetual and will not be 818 revoked by the Internet Society or its successors or assignees. 820 This document and the information contained herein is provided on an 821 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 822 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 823 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 824 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 825 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 827 Acknowledgement 829 Funding for the RFC Editor function is currently provided by the 830 Internet Society.