idnits 2.17.1 draft-ietf-vpim-routing-10.txt: -(74): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 3667, Section 5.1 on line 34. -- Found old boilerplate from RFC 3978, Section 5.5 on line 423. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 414), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an Authors' Addresses Section. ** There are 18 instances of too long lines in the document, the longest one being 5 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 118: '... SHOULD query the VPIM directory...' RFC 2119 keyword, line 119: '...ess. The client SHOULD use the ENUM s...' RFC 2119 keyword, line 163: '...for the directory location MAY contain...' RFC 2119 keyword, line 185: '... discovered, the client SHOULD issue a...' RFC 2119 keyword, line 187: '... SHOULD be used as the value for...' (2 more instances...) 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 (April 8, 2005) is 6958 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LASER' is mentioned on line 196, but not defined == Unused Reference: 'E164' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'NAPTR-1' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'NAPTR-2' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'NAPTR-3' is defined on line 366, but no explicit reference was found in the text == Unused Reference: 'NAPTR-4' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'VPIMV2' is defined on line 379, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' ** Obsolete normative reference: RFC 3761 (ref. 'ENUM') (Obsoleted by RFC 6116, RFC 6117) ** Downref: Normative reference to an Informational RFC: RFC 3401 (ref. 'NAPTR-1') -- Possible downref: Non-RFC (?) normative reference: ref. 'VPIMDIR' Summary: 18 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Greg Vaudreuil 3 Expires in six months Lucent Technologies 4 April 8, 2005 6 Voice Message Routing Service 8 10 Status of this Memo 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its Areas, and its Working Groups. Note that 14 other groups may also distribute working documents as Internet 15 Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Intellectual Property Notice 31 By submitting this Internet-Draft, I certify that any applicable 32 patent or other IPR claims of which I am aware have been 33 disclosed, or will be disclosed, and any of which I become aware 34 will be disclosed, in accordance with RFC 3668. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 Voice messaging is traditionally addressed using telephone number 43 addressing. This document describes two techniques for routing 44 voice messages based on a telephone number. The complete service 45 uses the VPIM Directory service to lookup a VPIM email address 46 with a telephone number and confirm that the address is both 47 valid and the associated with the intended recipient. However 48 this service will take time become widely deployed in the nearest 49 term. This document also describes a basic send-and-pray service 50 useful simply to route and deliver messages using only the ENUM 51 telephone number resolution service and the existing DNS mail 52 routing facilies. 54 Please send comments on this document to the VPIM working group 55 mailing list 57 Table of Contents 59 1. DESIGN GOALS.....................................................4 60 2. THE COMPLETE SERVICE.............................................5 61 2.1 Specification of Service "E2U+VPIM:LDAP"........................5 62 2.2 VPIM Directory Discovery........................................5 63 2.3 Address Query...................................................6 64 3. THE BASIC SERVICE................................................7 65 3.1 Specification of Service "E2U+VPIM:Mailto:".....................7 66 3.2 Address Construction............................................8 67 3.3 Interdomain Message Routing.....................................8 68 3.4 Intradomain Message Routing.....................................8 69 4. SECURITY CONSIDERATIONS..........................................10 70 5. IANA CONSIDERATIONS..............................................10 71 6. NORMATIVE REFERENCES.............................................10 72 7. INTELLECTUAL PROPERTY NOTICE.....................................11 73 8. COPYRIGHT NOTICE.................................................11 74 9. AUTHORS� ADDRESSES...............................................12 75 1. Design Goals 77 This profile is intended to provide a range of functional 78 capabilities for message routing based on one of two mechanisms. 79 The most complete service should use the ENUM address resolution 80 service to determine the VPIM directory, and then use LDAP to 81 retreive the VPIM-specific email address to use for message 82 routing. 84 The more basic send-and-pray message service uses only the ENUM 85 service and MX records to route the message to the intended 86 recipient's domain. The intelligence to further route the 87 message to the intended recipient is placed within the message 88 routing system of the recipient's domain. 90 The basic mechanism may be used even when there is a VPIM 91 directory service available. The basic service is useful when 92 LDAP queries are not available, such as may be the case for 93 disconnected mobile terminals or because of firewall or 94 information security policies. 96 The basic mechanism should facilitate the routing of VPIM 97 messages to a suitable internal destination with a minimum of 98 configuration. It is an important goal to avoid any content- 99 processing to determine the nature of the message and its 100 internal destination. It should be possible at a minimum to 101 establish a simple mail forwarding rule to send all inbound VPIM 102 messages to a designated system while facilitating the routing of 103 FAX, SMS, or other telephone-addressed messages to other 104 potentially different systems. 106 It is a goal that the mechanisms outlined in this document be 107 extensible for all store-and-forward, telephone-number addressed 108 messaging services. 110 It is a goal that the VPIM directory discovery and VPIM directory 111 query steps occur within the timing constraints for user 112 interfaces in PSTN networks. In general, that constraint can be 113 generalized to be a two-second response 95% of the time. 115 2. The Complete Service 117 For the complete VPIM message routing service, the sending client 118 SHOULD query the VPIM directory for the VPIM-specific email 119 address. The client SHOULD use the ENUM service to retrieve the 120 identity of the VPIM Directory to query. The client should then 121 query that server for the email address and any additional 122 attributes desired. 124 2.1 Specification of Service "E2U+VPIM:LDAP" 126 * Service Name: E.164 to VPIM LDAP URL 128 * URI Type: "LDAP:" 130 * Type: VPIM 132 * Subtype: LDAP 134 * Functional Specification: See section 3.2 through 3.3 136 * Intended Usage: COMMON 138 * Author: Greg Vaudreuil (gregv@ieee.org) 140 * Security Considerations: 142 o Malicious Redirection 143 One of the fundamental dangers related to any service 144 such as this is that a malicious entry in a resolver's 145 database will cause clients to resolve the E.164 into 146 the wrong LDAP URL. The possible intent may be to cause 147 the client to connect to a rogue LDAP server and 148 retrieve (or fail to retrieve) a resource containing 149 fraudulent or damaging information. 151 o Denial of Service 152 By removing the URL to which the E.164 maps, a 153 malicious intruder may remove the client's ability to 154 access the LDAP directory server. 156 2.2 VPIM Directory Discovery 158 The VPIM directory server is found by using the ENUM protocol and 159 querying for the VPIMDIR service associated with the telephone 160 number of the recipient. 162 The DNS query name is created as described by [ENUM]. The 163 telephone number used for the directory location MAY contain 164 additional sub-address information as additional digits. 166 Example: 168 Query: 2.1.2.1.5.5.5.3.1.6.1.e164.arpa 169 Responses: 170 IN NAPTR 10 10 "U" "E2U+VPIM:LDAP" \ 171 "!^.*$!ldap://vdir1.Zcorp.com/telephoneNumber=\1!" . 173 IN NAPTR 10 20 "U" " E2U+VPIM:LDAP" \ 174 "!^.*$!ldap://vdir2.Zcorp.com/telephoneNumber=\1!" . 176 It is recommended that VPIMDIR servers be deployed in a redundant 177 configuration. NAPTR weight fields provide the ability to give 178 two records indicating the same service and preference a 179 different weight. The same weight can be specified for random 180 distribution between the two servers. See [NAPTR-1, NAPTR-2, 181 NAPTR-3, NAPTR-4] 183 2.3 Address Query 185 Once the VPIM directory is discovered, the client SHOULD issue a 186 LDAP query for the vPIMrFC822Mailbox, that is, the address that 187 SHOULD be used as the value for both the RFC822 To: field and the 188 SMTP RCPT command. See [VPIMDIR] 190 3. The Basic Service 192 The basic service relies upon NAPTR rewrite rules to mechanically 193 construct a valid VPIM-specific email address. In the 194 recipient's domain, the constructed address may be further routed 195 using intradomain mail routing techniques such as those defined 196 in [LASER]. 198 To facilitate a full range of intradomain routing options, the 199 constructed email address indicates that the message is a VPIM 200 message. For ease of processing in the recipient's intradomain 201 mail routing system, the indication that the message is a VPIM 202 message SHOULD be in the domain name portion. 204 Note, that no validation that the constructed address is valid, 205 nor that the constructed address corresponds to the intended 206 recipient. Because no capabilities information is provided about 207 the recipient, messages sent with this mechaism SHOULD be sent 208 using only the media and content types of the VPIM V2 profile. 210 3.1 Specification of Service "E2U+VPIM:Mailto:" 212 * Service Name: E.164 to VPIM MailTo: URL 214 * URI Type: "Mailto:" 216 * Type: VPIM 218 * Subtype: MAILTO 220 * Functional Specification: See section 4.2 through 4.4 222 * Intended Usage: COMMON 224 * Author: Greg Vaudreuil (gregv@ieee.org) 226 * Error Conditions: 227 o E.164 number not in the numbering plan 228 o E.164 number in the numbering plan, but no URLs exist for 229 that number 230 o E2U+VPIM:Mailto Service unavailable 232 * Security Considerations: 234 o Malicious Redirection 235 One of the fundamental dangers related to any service 236 such as this is that a malicious entry in a resolver's 237 database will cause clients to resolve the E.164 into 238 the wrong email URL. The possible intent may be to 239 cause the client to send the information to an 240 incorrect destination. 242 o Denial of Service 243 By removing the URL to which the E.164 maps, a 244 malicious intruder may remove the client's ability to 245 access the resource. 247 o Unsolicited Bulk Email 248 The exposure of email addresses through the ENUM 249 service provides a bulk mailer access to large numbers 250 of email addresses where only the telephone number was 251 previously known. 253 3.2 Address Construction 255 Construct an VPIM email address using the address rewrite rules 256 of the NAPTR records associated with the VPIM service. 258 3.3 Interdomain Message Routing 260 The interdomain routing of a constructed VPIM address is 261 mechanically indistinguishable from existing email routing. No 262 changes to the infrastructure are required. The sending system 263 consults the Domain Name System for an MX record corresponding to 264 the domain name and forwards the message to the indicated system. 266 3.4 Intradomain Message Routing 268 Within the recipient's domain, the message may be further routed 269 to the appropriate messaging system. Two general mechanisms may 270 be used to further route the message to the intended system 271 within a network. 273 Note: This section is strictly informational. The 274 mechanisms for intradomain routing are an internal matter 275 for the domain and do not affect the protocol. It is only 276 necessary that the addresses created by the NAPTR rewrite 277 rules have meaning to the domain advertising them. 278 However, a convention for the creation and use of such 279 address may be useful. 281 3.4.1 Directory-Enabled Routing 283 Various proprietary directory mechanisms provide a means for an 284 inbound mail router of the recipient's domain to send a message 285 to the appropriate internal mail host. In many cases, the local 286 part of the address is used to query for an internal mail 287 address. That internal mail address is substituted for the SMTP 288 RCPT address and used to deliver the message to the recipient 289 mailbox. Note that the mailbox does not need to have any 290 knowledge of the mechanically-constructed telephone number-based 291 address. 293 Example address: +12145551212@sp.net 295 3.4.2 Service-based Mail Routing 297 Alternately, a mail gateway may simply send all voice messages 298 into a separate messaging system. That system may be a single 299 voice messaging server or a service-specific gateway into a 300 larger telephonenumber-based voice-messaging network. 302 Such a mail gateway may be provisioned with a simple rule or 303 small set of rules to forward all messages of a given service 304 type to a pre-defined server. This rule would check for the 305 service name "VPIM" as a prefix to the constructed domain name to 306 reroute messages. 308 Example address: +12145551212@VPIM.sp.net 310 4. Security Considerations 312 There is little information disclosed to the sender of a message 313 that is not already disclosed using standard email protocols 314 beyond the ability to probe, via send-and-fail, the existance of 315 a reachable account associated with a telephone number, and via 316 the NDN, determine in which domain the account resides. 318 4.1 Unsolicited Bulk Email 320 However, the use of ENUM records to create routeable email 321 addresses from telephone numbers provides bulk-emailers the 322 capablities to send email to a large set of recipients where only 323 the telephone number is known or where telephone numbers are 324 guessed. 326 4.2 DNS-based attacks 328 Both the complete and basic services rely upon the DNS to provide 329 the information necessary to validate a recipient or send a 330 message. The message sender is a casual, unauthenticated use of 331 the indicated servers, and relies upon the DNS for accurate 332 information. If the DNS is compromised, an attacker can redirect 333 messages by providing malicious email address or indicate a rogue 334 directory with malicious LDAP URL's. Use of DNS Security 335 protocols [DNSSEC] substantially reduce the risk of a domain 336 being hijacked. If the E.164 zone is secured with DNSSEC, then 337 the attack is precluded if the client can trust the key used to 338 sign the zone. DNS security does not protect against the LDAP 339 service independently being compromised. Further discussion on 340 the risk to this LDAP service is provided in [VPIMDIR]. 342 5. IANA Considerations 344 This specification registers the E2U+VPIM and E2U+Voice services 345 according to the specifications and guidelines in RFC 3761 [ENUM] 346 and the definitions in this document. 348 6. References 350 6.1 Normative References 352 [E164] CCITT Recommendation E.164 (1991), Telephone Network and 353 ISDN Operation, Numbering, Routing and Mobile Service - 354 Numbering Plan for the ISDN Era. 356 [ENUM] Falstrom, P., M. Mealling, "The E.164 to Uniform Resource 357 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 358 Application (ENUM)", RFC3761, April 2004 RFC 3761 360 [NAPTR-1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 361 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 363 [NAPTR-2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 364 Part Two: The Algorithm", RFC 3402, October 2002. 366 [NAPTR-3] Mealling, M., "Dynamic Delegation Discovery System 367 (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 368 3403, October 2002. 370 [NAPTR-4] Mealling, M., "Dynamic Delegation Discovery System 371 (DDDS) Part Four: The Uniform Resource Identifiers (URI) 372 Resolution Application", RFC 3404, October 2002. 374 [VPIMDIR] G. Vaudreuil "VPIM Directory Schema", work-in-progress, 375 , October 12, 2004. 377 6.2 Informative References 379 [VPIMV2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for 380 Internet Mail, Version 2", RFC 3801, June 2004. 382 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D. and S. 383 Rose,, "DNS Security Introduction and Requirements", , April 2005. 386 7. Intellectual Property Notice 388 The IETF takes no position regarding the validity or scope of any 389 intellectual property or other rights that might be claimed to 390 pertain to the implementation or use of the technology described 391 in this document or the extent to which any license under such 392 rights might or might not be available; neither does it represent 393 that it has made any effort to identify any such rights. 394 Information on the IETF's procedures with respect to rights in 395 standards-track and standards-related documentation can be found 396 in BCP-11. Copies of claims of rights made available for 397 publication and any assurances of licenses to be made available, 398 or the result of an attempt made to obtain a general license or 399 permission for the use of such proprietary rights by implementors 400 or users of this specification can be obtained from the IETF 401 Secretariat. 403 The IETF invites any interested party to bring to its attention 404 any copyrights, patents or patent applications, or other 405 proprietary rights which may cover technology that may be 406 required to practice this standard. Please address the 407 information to the IETF Executive Director. 409 8. Copyright Notice 411 Copyright (C) The Internet Society (2005). This document is 412 subject to the rights, licenses and restrictions contained in BCP 413 78, and except as set forth therein, the authors retain all their 414 rights. 416 This document and the information contained herein are provided 417 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 418 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 419 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 420 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 421 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 422 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 423 FOR A PARTICULAR PURPOSE. 425 9. Authors� Addresses 427 Gregory M. Vaudreuil 428 Lucent Technologies 429 9489 Bartgis Ct 430 Frederick, MD 21702 431 Email: GregV@ieee.org