idnits 2.17.1 draft-conroy-enum-experiences-01.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 1) being 489 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 145 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 109: '...ression matching SHALL be performed in...' RFC 2119 keyword, line 120: '...ates that any backref replacements MAY...' RFC 2119 keyword, line 267: '...eat, and clients MUST be able to detec...' 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 (February 2004) is 7377 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) ** Downref: Normative reference to an Informational RFC: RFC 3401 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ENUM Working Group L. Conroy 2 Internet Draft Roke Manor Research 4 INFORMATIONAL 6 Expires: September 2004 February 2004 8 ENUM Implementation Issues and Experiences 9 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 [1]. 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 22 months and may be updated, replaced, or obsoleted by other documents 23 at any 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 27 http://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 Abstract 34 This document captures experience in implementing systems based on the 35 ENUM protocol, and experience of ENUM data that have been created by 36 others. As such, it is informational only, and produced as a help to 37 others in reporting what is "out there" and the potential pitfalls in 38 interpreting the set of documents that specify the protocol. 40 1. Introduction 42 The ENUM protocol [1] and the Dynamic Delegation Discovery System (DDDS) 43 [2] [3] [4] [5] are defined elsewhere, and those documents alone form 44 the normative definition of the ENUM system. Unfortunately, this 45 document cannot provide an overview of the specifications, so the reader 46 is assumed to have read and understood the complete set of normative 47 documents. 49 From experience of creating ENUM data and of developing client systems 50 to process that data it is apparent that there are some subtleties in 51 the specifications that have led to different interpretations; in 52 addition there are common syntactic mistakes in data currently "out 53 there" on the Internet. 55 This document is intended to help others avoid the potential pitfalls in 56 interpreting the set of documents that specify the protocol. It also 57 reports the kind of data they will "find" and so how to process the 58 intent of the publisher of that ENUM data, regardless of the syntax 59 used. As such, it is in keeping with the principle evinced in RFC791 60 that "In general, an implementation must be conservative in its sending 61 behavior, and liberal in its receiving behavior". 63 Note that the DDDS systems is intricate and so in some places there are 64 several potential interpretations of the specifications. This document 65 proposes a suggested interpretation for some of these points, but they 66 are just that; suggestions. 68 This draft covers 11 issues; there are undoubtedly others, and 69 developers are requested to raise any others they find on the IETF ENUM 70 Working group's mailing list and/or by mail to the author (see later for 71 contact information). 73 Note that the author is not aware of any IPR issues that are involved in 74 the suggestions made in this document. 76 2. ENUM Implementation Issues 78 2.1. Case Sensitivity 80 From exploration of the ENUM records that are currently published, it's 81 obvious that there are differences of style in the case used for NAPTRs. 82 RFC2916bis describes a Dynamic Delegation Discovery System "Application" 83 and as such inherits the DDDS specification of UTF-8 as the character 84 set for fields. Case sensitivity is thus a non-trivial procedure. 86 The specifications are silent (but see next section) on whether or not 87 case sensitivity is expected. This can be interpreted in one of two 88 ways, so the following is a suggestion only. 90 It seems that, where used for ENUM (i.e. as specified in RFC2916bis), 91 the flag field, the services field, and the matching part of the regexp 92 field are case insensitive. As DNS is case-insensitive in its domain 93 names, the replacement field will be, by definition, also case 94 insensitive. 96 With the exception of any "back references", the explicit text in the 97 subsequent part of the regexp field may be case-sensitive, dependent on 98 the URI produced. 100 Thus, we propose that any ENUM client implementation treat ENUM field 101 contents as case-insensitive, EXCEPT for the subsequent part of the 102 regexp field, the case of which should be left untouched. 104 2.2. Regular Expression Case Insensitivity Flag 106 For those readers who follow the admonishment to read all of the 107 specification documents, there is a paragraph in section 3.2 of RFC3402 108 that states that, if the regular expression is followed by an 'i' flag, 109 the Extended Regular Expression matching SHALL be performed in a case- 110 insensitive manner. This is part of the general DDDS specification, and 111 so is "inherited" by ENUM with no further comment. 113 However, ENUM specifies that the Application Unique String (against 114 which the Extended Regular Expression is matched) is an E.164 number 115 stripped of all but the digits and an initial '+' character. Thus, it is 116 hard to see how case sensitivity would ever matter, and so, for the 117 specific case of regular expression matching in ENUM, this flag is 118 inactive. 120 The next sentence in RFC3402 states that any backref replacements MAY 121 be normalized to lower case when the "i" flag is given. Again, this is 122 part of the general DDDS specification. Considering that any back 123 reference in ENUM will be constructed from either digits or a '+' 124 character, this option does not have any impact. 126 In short, the 'i' flag when used in a NAPTR for ENUM is ineffective, 127 and can safely be ignored. 129 However, from observation, some folk have put this flag after the 130 regular expression in their NAPTRs, a number of clients have not 131 expected to see this, and have subsequently failed to process those 132 NAPTRs. 134 There are two proposals that flow from this; don't put this flag into 135 NAPTR records, as there are a number of clients "out there" that will 136 reject the NAPTR. Equally, clients should expect the "closing" delimiter 137 for a Regular Expression field to be either the last character in the 138 field, OR the penultimate one. 140 2.3. enumservice Syntax 142 Although the work has been completed for some time, RFC2916bis has yet 143 to be published as an RFC. Thus the only IETF RFC specifying ENUM 144 remains the original RFC2916. This specified a more limited syntax to 145 declare an enumservice to which a NAPTR was tied. Most important, it 146 specified that the DDDS Application tag for ENUM, 'E2U', was at the 147 right hand end of the services field. In the new syntax is defined in 148 RFC2916bis this same DDDS Application tag is at the start (left) of the 149 services field. 151 There are NAPTRs "published" at present that follow the old syntax, and 152 there are also NAPTRs that follow the new syntax. Thus there is a 153 quandary for ENUM client developers that can, in practice, only be 154 resolved by supporting both syntactic forms. 156 One possible solution to handling these two differing forms in an ENUM 157 client is to treat the required '+' character as a simple list 158 separator, to treat the 'E2U' token as if it were an enumservice token, 159 and then discard it before processing, having first checked that it 160 exists exactly once in the list of tokens so produced. 162 Equally, there is a quandary for developers of those systems that create 163 and store ENUM NAPTRs; to create NAPTRs according to the 164 not-yet-obsolete syntax of RFC2916, or the not-quite-RFC syntax of 165 RFC2916bis. 167 Whilst the IETF has discouraged implementation to Internet Drafts, the 168 intent and the status of this draft means that its use for creation of 169 NAPTRs seems to be appropriate. Similarly, RFC2916bis is a replacement 170 for the "old" RFC2916, and so fresh development of systems that create 171 NAPTRs to the old syntax is conversely inappropriate. 173 In summary, clients should support both old and new syntactic forms, 174 whilst NAPTR creations systems should create NAPTRs only to the new 175 syntax. This seems best to embody the aim of "being liberal with what 176 you accept, whilst being conservative with what you send". 178 There is one further implication of the need for ENUM clients to process 179 NAPTRs in both syntactic forms. In principle, it would be possible to 180 define an enumservice with the token 'E2U', as it would be 181 distinguishable from the ENUM DDDS Application tag by position within 182 the field. However, given the long gestation of the replacement RFC, it 183 is strongly recommended that no-one propose such an enumservice, as it 184 is likely to cause major problems for clients that are forced to handle 185 both forms. 187 2.4. Order of evaluation of enumservices 189 RFC2916bis has introduced the option of specifying more than one 190 enumservice that is applicable for a NAPTR. This has some benefits in 191 terms of compactness, as a single NAPTR can be produced which is the 192 equivalent of a set of NAPTRs all of which resolve to the same URI. 193 However, in the future there may be situations in which the order in 194 which multiple enumservices are evaluated matters. Thus is a client to 195 start at the right hand end and work towards the left, or start at the 196 left and work to the right? 198 Either is valid, but we (arbitrarily) choose to evaluate from left to 199 right within the enumservices field. 201 Equally, an ENUM creation system could place enumservices applicable for 202 a NAPTR into any order. By definition, this combined NAPTR is equivalent 203 to a set of NAPTRs each member of which has an identical order field 204 value, identical regular expression field content, and one of the list 205 of enumservices as its service field content. The difference lies in the 206 fact that each of the constituent set of individual NAPTRs should have a 207 different preference/priority field value. By implication, there is an 208 order to the set of NAPTRs as opposed to the otherwise equivalent 209 combined NAPTR with multiple enumservices. 211 As a choice, our ENUM creation system combines the individual 212 enumservices in the order (from left to right) that reflects the 213 preference/priorities of the constituent set of NAPTRs. Thus, the order 214 of the enumservices in a combined NAPTR (taken from left to right) 215 reflects a user preference. 217 2.5. NAPTRs with identical values in their order and preference fields 219 Whilst it is not a valid configuration, there are sets of NAPTRs that 220 have the same order value AND the same priority/preference value. Given 221 that the goal is to process these if this can be done unambiguously, 222 there are some choices. 224 A client could process these in any arbitrary order - the implication is 225 that NAPTRs with the same order and preference field values are of 226 equivalent priority. However, some DNS systems produce their resource 227 records in a determined order, and it IS possible that the "publisher" 228 of this data was unaware that any intervening DNS system could re-order 229 them when responding to requests. 231 This seems to have been the case with several examples that were seen. 232 Querying the authoritative DNS server always returned the same order of 233 resource records, and a SIP entry was the first, followed by an email 234 entry - an apparently intended order of NAPTR processing. Thus, given 235 that there is no harm in doing so, we choose that our clients process 236 the identical NAPTRs in the order in which they are received in a DNS 237 response. 239 2.6. Non-final NAPTRs and Services Field processing 241 RFC2916bis refines (with DDDS) the concept of non-final NAPTRs. These 242 are NAPTRs with an empty flags field, an empty regular expression field, 243 and a populated replacement field. It is, however, unclear whether or 244 not the services field should be empty, and whether enumservice checking 245 should be done (at least to see whether or not this NAPTR holds the ENUM 246 application tag 'E2U' and so should be considered in ENUM processing). 248 This of course has implications both on the expected behaviour of ENUM 249 clients and on the NAPTRs that ENUM creation systems should generate. 250 It appears from the thrust of RFC3402 and 3402 that a non-final NAPTR is 251 intended as a generic tool (not tied to a particular DDDS Application), 252 so it is suggested that ENUM creation systems generate such NAPTRs with 253 an empty services field, and that ENUM clients ignore the field, 254 regardless of whether or not it is empty. 256 2.7. Non-final loop detection 258 A non-final NAPTR indicates that the search for matching NAPTRs for a 259 given Application Unique String (constructed from an E.164 number) 260 should continue with a query of another domain, that domain being 261 defined in its replacement field. 263 Of course, the domain at which the search continues may also include a 264 non-final NAPTR. Thus, by misconfiguration, it is possible for there to 265 be a "loop", in which a non-final NAPTR refers to a domain that has 266 already been traversed in this search. This is an obvious security 267 threat, and clients MUST be able to detect such a loop condition, 268 however complex. 270 This is not quite as simple as it seems. A strictly correct scheme would 271 be to keep a record of each domain traversed during a query, and to 272 check against this list any domain indicated in a non-final NAPTR 273 processed during the search. However, this introduces both an increasing 274 processing load on the client, and an indeterminate memory requirement. 275 These two factors may be exploited by an attacker by "publishing" an 276 appropriately long chain of non-final NAPTRs. 278 A simpler alternative strategy for a client is to keep a count of the 279 number of domain traversals during a search. This does not open either 280 of the potential exploits, but it does mean that some arbitrary limit 281 has to be chosen for the number of such traversals a client will allow 282 during a search before it decides that a loop has been detected. 284 There is a balance between the number of domain traversals that might 285 reasonably be expected in an ENUM search, and the number of times that a 286 client will loop before it detects this fact. We chose to limit the 287 number of traversals to 5, as this seemed more than might reasonably be 288 used when "publishing" a set of ENUM data for any telephone number. 290 It does, of course, have an implication on ENUM creation systems - don't 291 put more than 5 domain traversals into a chain for a given set of ENUM 292 data, or clients will consider it to be a loop. 294 2.8. Non-final loop treatment 296 As NAPTRs in a domain are processed in order based on the values in 297 their order and priority/preference fields, it is possible that a 298 non-final NAPTR domain traversal is taken before "lower" NAPTRs have 299 been processed. If, subsequent to making this traversal, a loop is 300 detected, then this branch in the search must be rejected. However, a 301 client must make a choice on such detection. The choice taken will have 302 an impact on client behaviour, and so, for testing purposes if for no 303 other, it is convenient for a common choice to be made. 305 The three choices that may be made are: 307 The client could give up on the whole search, returning a failure 308 indication to the system that initiated the ENUM search, 309 or 310 It could return to the NAPTR with a priority immediately lower than the 311 non-final NAPTR that triggered the loop detection (i.e. in the domain 312 that included the "bad" non-final NAPTR), 313 or, where this is different, 314 It might continue at the first domain queried for this telephone 315 number's matching entries, rejecting all of the non-final traversals 316 it had taken to get to the domain that held the "bad" non-final NAPTR. 318 Each of these options has its merits, but we choose the second option. 320 The reasoning was that it does not require any "memory" for domains that 321 have been traversed and it makes the most optimistic assumption - that 322 whilst there is an error in one (non-final) NAPTR, the others will be 323 correct. Given the complexity of arranging non-final NAPTR traversals 324 this seems to us to be the most reasonable approach. 326 2.9. Order evaluation across non-final domain traversal 328 Some NAPTRs that are held in a domain may be inapplicable for a client; 329 they may indicate an enumservice (and URI) that the client is not 330 capable of using, even though it is a perfectly valid contact. Thus the 331 client must continue its processing at the NAPTR with the next highest 332 order and priority/preference field values. If there are no further 333 NAPTRs to check, then the current search has failed. 335 Where the NAPTRs within a current domain have been reached as a branch 336 of the search resulting from a non-final NAPTR domain traversal, one 337 would expect that this branch has failed and processing would continue 338 at the next NAPTR "after" the non-final one that triggered the branch. 340 However, it is possible for NAPTRs within that branch to have higher 341 order field values than those of the domain from which that traversal 342 started. The DDDS algorithm indicates that all NAPTRs with a lower order 343 field value should be discarded. 345 This might be taken to mean that the search has ended in failure, as all 346 remaining NAPTRs have a lower value that one found (but ignored as 347 inappropriate for the client). The intent of the standard might seem 348 obvious, but such a strict interpretation was made by some developers, 349 so it bears spelling out here. 351 We chose to completely ignore any NAPTRs that were inappropriate for a 352 client, meaning that processing continued in the previous domain with 353 whatever was the order value for any remaining (non-discarded) NAPTRs. 354 Any higher order field value detected in a domain branch that included 355 no appropriate NAPTRs was ignored. 357 3. Security Issues 359 This document does not specify any standard. It does however make some 360 recommendations, and so the implications of following those suggestions 361 have to be considered. 363 In addition to these issues, those in the basic use of ENUM (and 364 specified in the normative documents for this protocol) should be 365 considered as well; this document does not negate those in any way. 367 The suggestions in sections 2.1, 2.2, 2.3, 2.4, 2.5 and 2.6 do not 368 appear to have any security considerations (either positive or 369 negative). 371 The suggestion in section 2.7 is a valid approach to a known security 372 threat. It does not open an advantage to an attacker in client excess 373 processing or memory usage. It does, however, mean that a client will 374 traverse a "tight loop" of non-final NAPTRs in two domains 5 times 375 before the client detects this as a loop; this does introduce a slightly 376 higher processing load that would be provided using other methods, but 377 avoids the risks they incur. 379 The suggestions in section 2.8 is not thought to have any security 380 impact over the normal use of ENUM; nor does that in section 2.9. 382 4. IANA Considerations 384 This document is informational only, and does not include any IANA 385 considerations other than the suggestion in section 2.3 that no-one 386 should specify an enumservice with the identifying tag 'E2U'. 388 5. Acknowledgments 390 I would like to thank the various development teams who have implemented 391 ENUM (both creation systems and clients) and who have read the normative 392 documents differently - without these differences it would have been 393 harder for us all to develop robust clients and suitably conservative 394 management systems. 396 In particular, thanks to Richard Stastny for his hard work on a similar 397 task [6] under the aegis of ETSI, and for supporting some of the ENUM 398 implementations that exist today. 400 Finally, thanks for the dedication of Michael Mealling in giving us such 401 detailed DDDS specifications, without which the ENUM implementation 402 effort would have had a less rigorous framework on which to build. 404 6. Normative References 406 [1] P. Faltstrom, M. Mealling, draft-ietf-enum-rfc2916bis-07.txt, 407 "The E.164 to URI DDDS Application (ENUM)", 408 October 2003 - Work in Progress 410 [2] M. Mealling, RFC 3401, 411 "Dynamic Delegation Discovery System (DDDS) Part One: 412 The Comprehensive DDDS", 413 October 2002 415 [3] M. Mealling, RFC 3402, 416 "Dynamic Delegation Discovery System (DDDS) Part Two: 417 The Algorithm", 418 October 2002 420 [4] M. Mealling, RFC 3403, 421 "Dynamic Delegation Discovery System (DDDS) Part Three: 422 The Domain Name System (DNS) Database", 423 October 2002 425 [5] M. Mealling, RFC 3404, 426 "Dynamic Delegation Discovery System (DDDS) Part Four: 427 The Uniform Resource Identifiers (URI)", 428 October 2002 430 Non-normative Reference: 432 [6] ETSI TS 102 172, 433 "Minimum Requirements for Interoperability of 434 European ENUM Trials", 435 February 2003 437 7. Author's Address 439 Lawrence Conroy 440 Roke Manor Research 441 Old Salisbury Lane 442 Romsey 443 Hampshire SO51 0ZN 444 United Kingdom 446 email: lwc@roke.co.uk 447 URI: http://www.sienum.co.uk 449 8. Full Copyright Statement 451 Copyright (C) The Internet Society (2000). All Rights Reserved. 453 This document and translations of it may be copied and furnished to 454 others, and derivative works that comment on or otherwise explain it 455 or assist in its implementation may be prepared, copied, published 456 and distributed, in whole or in part, without restriction of any 457 kind, provided that the above copyright notice and this paragraph 458 are included on all such copies and derivative works. However, this 459 document itself may not be modified in any way, such as by removing 460 the copyright notice or references to the Internet Society or other 461 Internet organizations, except as needed for the purpose of 462 developing Internet standards in which case the procedures for 463 copyrights defined in the Internet Standards process must be 464 followed, or as required to translate it into languages other than 465 English. 467 The limited permissions granted above are perpetual and will not be 468 revoked by the Internet Society or its successors or assigns. 470 This document and the information contained herein is provided on an 471 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 472 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 473 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 474 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 475 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.