idnits 2.17.1 draft-ietf-iptel-tel-enumdi-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 326. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 25, 2006) is 6507 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) ** Obsolete normative reference: RFC 4234 (ref. '2') (Obsoleted by RFC 5234) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 3761 (ref. '4') (Obsoleted by RFC 6116, RFC 6117) == Outdated reference: A later version (-06) exists of draft-ietf-iptel-tel-reg-00 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPTEL R. Stastny 3 Internet-Draft Oefeg 4 Expires: December 27, 2006 R. Shockey 5 Neustar Inc. 6 L. Conroy 7 Roke Manor Research 8 June 25, 2006 10 The ENUM Dip Indicator parameter for the "tel" URI 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 27, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document defines a new parameter "enumdi" for the "tel" Uniform 45 Resource Identifier (URI) to support the handling of ENUM queries in 46 VoIP (Voice over Internet Protocol) network elements. A VoIP network 47 element may receive an URI containing an E.164 number, where that URI 48 contains an "enumdi" parameter. The presence of the "enumdi" 49 parameter indicates that an ENUM query has already been performed on 50 the E.164 number by a previous VoIP network element. Equally, if a 51 VoIP network element sends such an URI, it asserts that an ENUM query 52 has been carried out on this number. 54 Table of Contents 56 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Normative Rules . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4.1. Options for ENUM domain providers . . . . . . . . . . . . . 3 61 4.2. Client behaviour for VoIP network elements . . . . . . . . 4 62 4.2.1. Handling an URI with the "enumdi" parameter . . . . . . 4 63 4.2.2. Adding the "enumdi" parameter to URIs . . . . . . . . . 4 64 4.2.3. Handling an URI retrieved from ENUM . . . . . . . . . . 4 65 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 Intellectual Property and Copyright Statements . . . . . . . . . . 9 75 1. Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 78 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 79 this document are to be interpreted as described in BCP 14, RFC2119 80 [1]. 82 2. Introduction 84 VoIP network elements (including User Agent Servers and User Agent 85 Clients) may be set up in different ways to handle E.164 [3] numbers 86 during call setup, depending on the capabilities provided. One 87 common approach is to query ENUM as defined in RFC3761 [4], and to 88 use the set of NAPTR (Naming Authority Pointer to resource) resource 89 records that is returned. 91 If the ENUM query leads to a result, the call is set-up accordingly. 92 If the ENUM query does not lead finally to a result, another database 93 may be queried and/or the call may finally be routed to the PSTN 94 (Public Switched Telecommunications Network). In doing so, the call 95 may be routed to another VoIP network element. To indicate in 96 signalling to this next VoIP element that an ENUM query has already 97 be made for the "tel" URI (specified in RFC3966 [5]), the "enumdi" 98 parameter is used, to prevent the next VoIP network element from 99 repeating redundant queries. 101 3. Formal Syntax 103 The following syntax specification uses the Augmented Backus-Naur 104 Form (ABNF) as described in RFC4234 [2] to extend the syntax of the 105 "par" production defined in the ABNF of RFC3966 [5]. 107 par =/ enum-dip-indicator 109 enum-dip-indicator = ";enumdi" 111 The enum-dip-indicator is an optional parameter for the "tel" URI. 112 Note also that enum-dip-indicator can appear at most once in any 113 "tel" URI. 115 4. Normative Rules 117 4.1. Options for ENUM domain providers 119 A domain provider can, at its choosing, populate a NAPTR record with 120 a tel URI that contains the enum dip indicator. This would, as a 121 consequence of the rules stated below, inform the client that it 122 should not bother performing a query and pass the request on. 124 4.2. Client behaviour for VoIP network elements 126 This section discusses how a VoIP network element handles a received 127 "tel" URI that contains the "enumdi" parameter or has queried ENUM in 128 e164.arpa. for a given E.164 number. 130 4.2.1. Handling an URI with the "enumdi" parameter 132 If a VoIP network element receives a "tel" URI containing the 133 "enumdi" parameter, the VoIP network element SHOULD NOT retrieve the 134 related information for this number from ENUM in e164.arpa. even if 135 it would normally do so. 137 Note that the recipient network element may reasonably choose to 138 query ENUM if it does not have a trust relationship with the 139 immediate sender of the URI. 141 If the "tel" URI (received from a trusted entity) is to be passed to 142 the next network element, the VoIP network element MUST pass on the 143 received URI containing the "enumdi" parameter unchanged. 145 If, however, the URI has been received from an untrusted entity then 146 the recipient entity may either strip it before sending the URI 147 onwards, or instead to carry out its own ENUM query and add the 148 parameter accordingly to the URI (see next). 150 4.2.2. Adding the "enumdi" parameter to URIs 152 When a VoIP network element queries ENUM in e164.arpa. for a given 153 E.164 number and the result of the query is DNS error code 3 154 (commonly known as "NXDOMAIN"), then if that network element chooses 155 to pass the call to another network element by using a "tel" URI, the 156 "enumdi" parameter MUST be set. 158 4.2.3. Handling an URI retrieved from ENUM 160 When a VoIP network element queries ENUM in e164.arpa. for a given 161 E.164 number and either: 162 o the result of the query includes a NAPTR resource record 163 containing a "tel" URI that has the same E.164 number, or 164 o the result of the query includes a NAPTR resource record 165 containing a "tel" URI with the "enumdi" parameter set, 167 then if that retrieved "tel" URI is chosen to be passed to another 168 network element, the sending VoIP network element MUST pass on the 169 retrieved URI with the "enumdi" parameter set. 171 When a VoIP network element queries ENUM in e164.arpa. for a given 172 E.164 number and the result is a tel URI with a different E.164 173 number that lacks the enum dip indicator, the client can either 174 perform another query against that number, or pass the request on, as 175 a matter of local policy. 177 5. Examples 179 a. A VoIP network element called server.example.com receives a "tel" 180 URI tel:+441632960038. The VoIP network element queries the DNS 181 for NAPTR resource records in 8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa., 182 and gets an error response with code = 3 (commonly known as 183 "NXDOMAIN"). The VoIP network element decides to route the call 184 to the PSTN via another VoIP network element called 185 gw.example.com. 187 It therefore signals to the next VoIP network element with: 188 tel:+441632960038;enumdi 189 or (using the procedures of RFC3261 [6] section 19.1.6): 190 sip:+441632960038;enumdi@gw.example.com;user=phone 192 b. A VoIP network element called server.example.com receives a "tel" 193 URI tel:+441632960038. The VoIP network element queries the DNS 194 for NAPTR resource records in 8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa., 195 and receives the same "tel" URI in reply (i.e. 196 tel:+4416232960038). 198 The VoIP network element decides to route the call to the PSTN 199 via another VoIP network element called gw.example.com. 201 It therefore signals to this next VoIP network element with: 202 tel:+441632960038;enumdi 203 or (using the procedures of RFC3261 [6] section 19.1.6): 204 sip:+441632960038;enumdi@gw.example.com;user=phone 206 6. Security Considerations 208 In addition to those security implications discussed in the "tel" URI 209 [5] specification, there are new security implications associated 210 with the defined parameter. 212 If the "enumdi" is illegally inserted into the "tel" URI when the 213 signalling message carrying the "tel" URI is en route to the 214 destination entity, the call may be routed to the PSTN network, 215 incurring unexpected charges or causing a downstream VoIP network 216 element to reject the call setup. Many network elements that will 217 process URIs containing this parameter will maintain trust 218 relationships with others. If such a URI is received from an entity 219 outside the trust boundary of the recipient, then that recipient 220 entity may reasonably ignore it and make an ENUM query itself. In so 221 doing, it can avoid this potential attack. 223 It is less a problem if the "enumdi" is illegally removed. An 224 additional ENUM query may be performed to retrieve the routing number 225 information and have the "enumdi" included again. 227 It is RECOMMENDED that protocols carrying the "tel" URI ensure 228 message integrity during the message transfer between the two 229 communicating network elements so as to detect any unauthorised 230 changes to the content of the "tel" URI and other information. 232 7. IANA Considerations 234 This document does not itself require any IANA actions. 236 It does define a parameter for the "tel" URI. Further information on 237 a registry for such parameters is covered in 238 draft-ietf-iptel-tel-reg-00 [7]. 240 8. Acknowledgements 242 Many thanks for the thorough review provided by Alex Mayrhofer. 244 9. References 246 9.1. Normative References 248 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 249 Levels", RFC 2119, BCP 14, March 1997. 251 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 252 Specifications: ABNF", RFC 4234, October 2005. 254 [3] ITU-T, "The International Public Telecommunication Number Plan", 255 Recommendation E.164, May 1997. 257 [4] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 258 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 259 Application (ENUM)", RFC 3761, April 2004. 261 [5] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 262 December 2004. 264 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 265 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 266 Session Initiation Protocol", RFC 3261, June 2002. 268 9.2. Informative References 270 [7] Jennings, C. and V. Gurbani, "The Internet Assigned Number 271 Authority (IANA) tel Uniform Resource Identifier (URI) Parameter 272 Registry", draft-ietf-iptel-tel-reg-00.txt (work in progress), 273 December 2005. 275 Authors' Addresses 277 Richard Stastny 278 Oefeg 279 Postbox 147 280 1103 Vienna 281 Austria 283 Phone: +43-664-420-4100 284 Email: Richard.stastny@oefeg.at 286 Richard Shockey 287 Neustar Inc. 288 46000 Center Oak Plaza 289 Sterling, VA 20166 290 United States 292 Phone: +1-571-434-5651 293 Email: richard.shockey@neustar.biz 295 Lawrence Conroy 296 Roke Manor Research 297 Roke Manor 298 Romsey 299 United Kingdom 301 Phone: +44-1794-833666 302 Email: lconroy@insensate.co.uk 304 Intellectual Property Statement 306 The IETF takes no position regarding the validity or scope of any 307 Intellectual Property Rights or other rights that might be claimed to 308 pertain to the implementation or use of the technology described in 309 this document or the extent to which any license under such rights 310 might or might not be available; nor does it represent that it has 311 made any independent effort to identify any such rights. Information 312 on the procedures with respect to rights in RFC documents can be 313 found in BCP 78 and BCP 79. 315 Copies of IPR disclosures made to the IETF Secretariat and any 316 assurances of licenses to be made available, or the result of an 317 attempt made to obtain a general license or permission for the use of 318 such proprietary rights by implementers or users of this 319 specification can be obtained from the IETF on-line IPR repository at 320 http://www.ietf.org/ipr. 322 The IETF invites any interested party to bring to its attention any 323 copyrights, patents or patent applications, or other proprietary 324 rights that may cover technology that may be required to implement 325 this standard. Please address the information to the IETF at 326 ietf-ipr@ietf.org. 328 Disclaimer of Validity 330 This document and the information contained herein are provided on an 331 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 332 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 333 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 334 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 335 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 336 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 338 Copyright Statement 340 Copyright (C) The Internet Society (2006). This document is subject 341 to the rights, licenses and restrictions contained in BCP 78, and 342 except as set forth therein, the authors retain all their rights. 344 Acknowledgment 346 Funding for the RFC Editor function is currently provided by the 347 Internet Society.