Internet Draft Greg Vaudreuil Expires in six months Lucent Technologies September 10, 2000 Voice Message Routing Service Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. This Internet-Draft is in conformance with Section 10 of RFC2026. Overview Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The VPIM Directory service provides a directory mechanism to lookup a VPIM email address with a telephone number and confirm that the address is both valid and the associated with the intended recipient. However this service will take time become widely deployed in the nearest term. This document also describes a more limited send-and-pray service useful simply to route and deliver messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilies. Please send comments on this document to the VPIM working group mailing list Internet Draft VPIM Routing October 19, 2000 Working Group Summary This is a submission to the IETF VPIM working group. Vaudreuil Expires 1/1/01 [Page 2] Internet Draft VPIM Routing October 19, 2000 Table of Contents 1. ABSTRACT ............................................................4 2. DESIGN GOALS ........................................................4 3. THE COMPLETE SERVICE ................................................5 3.1Specification of Service "VPIMDIR+e2u" ............................5 3.2VPIM Directory Discovery ..........................................6 3.3Address Query .....................................................6 4. THE BASIC SERVICE ...................................................7 4.1Specification of Service "VPIM+e2u" ...............................7 4.2Address Construction ..............................................8 4.3Interdomain Message Routing .......................................8 4.4Intradomain Message Routing .......................................8 5. SECURITY CONSIDERATIONS ............................................10 6. REFERENCES .........................................................10 7. ACKNOWLEDGMENTS ....................................................11 8. COPYRIGHT NOTICE ...................................................11 9. AUTHORS' ADDRESSES .................................................11 Vaudreuil Expires 1/1/01 [Page 3] Internet Draft VPIM Routing October 19, 2000 1. Abstract 2. Design Goals This profile is intended to provide a range of functional capabilities for message routing based on one of two mechanisms. The most complete service should the ENUM address resolution service to determine the VPIM directory, and then use LDAP to retreive the VPIM email address to use for message routing. The most basic send-and-pray message service uses only the ENUM service and MX records to route the message to the intended recipient's domain. The intelligence to further route the message to the intended recipient is placed within the message routing system of the recipient's domain. The basic mechanism may be used even when there is a VPIM directory service avaiable. The basic service is useful when LDAP queries are not available, such as may be the case for disconnected mobile terminals or because of firewall or information security policies. The basic mechanism should facilitate the routing of VPIM messages to a suitable internal destination with a minimum of configuration. It is an important goal to avoid any content-processing to determine the nature of the message and its internal destination. It should be possible at a minimum to establish a simple mail forwarding rule to send all inbound VPIM messages to a designated system while facilitating the routing of FAX, SMS, or other telephone-addressed messages to other potentially different systems. It is a goal that the mechanisms outlined in this document be extensible for all store-and-forward, telephone-number addressed messaging services. It is a goal that the VPIM directory discovery and VPIM directory query steps occur within the timing constraints for user interfaces in PSTN networks. In general, that constraint can be generalized to be a two-second response 95% of the time. Vaudreuil Expires 1/1/01 [Page 4] Internet Draft VPIM Routing October 19, 2000 3. The Complete Service For the complete VPIM message routing service, the sending client SHOULD query the VPIM directory for the VPIM-specific email address. The client SHOULD use the ENUM service to retrieve the identity of the VPIM Directory to query. The client shouldthen query that server for the email address and any additional attributes desired. 3.1 Specification of Service "VPIMDIR+e2u" * Name: E.164 to LDAP: URL * Mnemonic: vpimdir+E2U * Number of Operands: 1 * Type of Each Operand: First operand is an E.164 number. * Format of Each Operand: First operand is the E.164 number with no user presentation characters (Space, parenthesis, dot, dash) but including a leading "+" character * Algorithm: Opaque * Output: One or more LDAP: URLs for servers that support the VPIM LDAP schema [VPIMDIR] * Error Conditions: o E.164 number not in the numbering plan o E.164 number in the numbering plan, but no URLs exist for that number o VPIMdir+e2u Service unavailable * Security Considerations: o Malicious Redirection One of the fundamental dangers related to any service such as this is that a malicious entry in a resolver's database will cause clients to resolve the E.164 into the wrong URL. The possible intent may be to cause the client to retrieve a resource containing fraudulent or damaging material. o Denial of Service By removing the URL to which the E.164 maps, a malicious intruder may remove the client's ability to access the resource. Vaudreuil Expires 1/1/01 [Page 5] Internet Draft VPIM Routing October 19, 2000 3.2 VPIM Directory Discovery The VPIM directory server is found by using the ENUM protocol and querying for the VPIMDIR service associated with the telephone number of the recipient. The DNS query name is created as described by [ENUM]. The telephone number used for the directory location MAY contain additional (sub- address) information. See [ENUMOPS] Example: Query: 2.1.2.1.5.5.5.3.1.6.1.e164.arpa Responses: IN NAPTR 10 10 "U" "vpimdir+E2U" \ "$!ldap://vpimdir1.Zcorp.com/telephoneNumber=\1!" . IN NAPTR 10 20 "U" "vpimdir+E2U" \ "$!ldap://vpimdir2.Zcorp.com/telephoneNumber=\1!" . It is RECOMMENDED that VPIMDIR servers be deployed in a redundant configuration. NAPTR weight fields provide the ability to give two records indicating the same service and preference a different weight. The same weight can be specified for random distribution between the two servers. See [NAPTR] 3.3 Address Query Once the VPIM directory is discovered, the client SHOULD issue a LDAP query for the vPIMrFC822Address. That is, the address that SHOULD be used as the value for both the RFC822 To: field and the SMTP RCPT command. See [VPIMDIR] Vaudreuil Expires 1/1/01 [Page 6] Internet Draft VPIM Routing October 19, 2000 4. The Basic Service The basic service relies upon NAPTR rewrite rules to mechanically construct a valid VPIM. In the recipient's domain, the constructed address may be further routed using intradomain mail routing techniques such as those defined in [LASER]. To facilitate a full range of intradomain routing options, the constructed email address indicates that the message is a VPIM message. For ease of processing in the recipient's intradomain mail routing system, the indication that the message is a VPIM message SHOULD be in the domain name portion. Note, that no validation that the constructed address is valid, nor that the constructed address corresponds to the intended recipient. Because no capabilities information is provided about the recipient, messages sent with this mechaism SHOULD be sent using only the media and content types of the VPIM profile. 4.1 Specification of Service "VPIM+e2u" * Name: E.164 to VPIM MailTo: URL * Mnemonic: vpim+E2U * Number of Operands: 1 * Type of Each Operand: First operand is an E.164 number. * Format of Each Operand: First operand is the E.164 number with no user presentation characters (Space, parenthesis, dot, dash) but including a leading "+" character * Algorithm: Opaque * Output: One or more MailTo: URLs * Error Conditions: o E.164 number not in the numbering plan o E.164 number in the numbering plan, but no URLs exist for that number o VPIM+e2u Service unavailable * Security Considerations: o Malicious Redirection One of the fundamental dangers related to any service such as this is that a malicious entry in a resolver's database will cause clients to resolve the E.164 into the wrong URL. The possible intent may be to cause the client to retrieve a resource containing fraudulent or damaging material. Vaudreuil Expires 1/1/01 [Page 7] Internet Draft VPIM Routing October 19, 2000 o Denial of Service By removing the URL to which the E.164 maps, a malicious intruder may remove the client's ability to access the resource. o Unsolicited Bulk Email The exposure of email addresses through the ENUM service provides a bulk mailer access to large numbers of email addresses where only the telephone number was previously known. 4.2 Address Construction Construct an VPIM email address using the address rewrite rules of the NAPTR records associated with the VPIM service. 4.3 Interdomain Message Routing The interdomain routing of a constructed VPIM address is mechanically indistinguishable from existing email routing. No changes to the infrastructure are required. The sending system consults the Domain Name System for an MX record corresponding to the domain name and forwards the message to the indicated system. 4.4 Intradomain Message Routing Within the recipient's domain, the message may be further routed to the appropriate messaging system. Two general mechanisms may be used to further route the message to the intended system within a network. Note: This section is strictly informational. The mechanisms for intradomain routing are an internal matter for the domain and do not affect the protocol. It is only necessary that the addresses created by the NAPTR rewrite rules have meaning to the domain advertising them. However, a convention for the creation and use of such address may be useful. 4.4.1 LASER-Powered / Directory-Enabled Routing Various proprietary directory mechanisms and the emerging LASER standard mechanism provide a means for an inbound mail router of the recipient's domain to send a message to the appropriate internal mail host. In many cases, the local part of the address is used to query for an internal mail address. That internal mail address is substituted for the SMTP RCPT address and used to deliver the message to the recipient mailbox. Note that the mailbox does not need to have any knowledge of the mechanically-constructed telephone number-based address. Vaudreuil Expires 1/1/01 [Page 8] Internet Draft VPIM Routing October 19, 2000 4.4.2 Service-based Mail Routing Alternately, a mail gateway may simply send all voice messages into a separate messaging system. That system may be a single voice messaging server or a service-specific gateway into a larger telephonenumber-based voice-messaging network. Such a mail gateway may be provisioned with a simple rule or small set of rules to forward all messages of a given service type to a pre- defined server. This rule would check for the service name "_VPIM" as a prefix to the domain name to reroute messages. In many cases, such as with SMS messaging to mobile phones, this server may be external to the customer's network. Vaudreuil Expires 1/1/01 [Page 9] Internet Draft VPIM Routing October 19, 2000 5. Security Considerations There is little information disclosed to the sender of a message that is not already disclosed using standard email protocols beyond the ability to probe, via send-and-fail, the existance of a reachable account associated with a telephone number, and via the NDN, determine in which domain the account resides. However, the use of ENUM records to create routeable email addresses from telephone numbers provides bulk-emailers the capablities to send email to a large set of recipients where only the telephone number is known or where telephone numbers are guessed. 6. References [E164] CCITT Recommendation E.164 (1991), Telephone Network and ISDN Operation, Numbering, Routing and Mobile Service - Numbering Plan for the ISDN Era. [ENUM] P. Faltstrom "E.164 number and DNS", Work-in-Progress, , July 2000. [ENUMOPS] A. Brown and G. Vaudreuil "ENUM Service Specific Provisioning: Principles of Operation", Work-in-Progress, , July 2000. [NAPTR] M. Mealling and R.D. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", work-in-progress, , August 2000. [VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet Mail, Version 2", Work-in-Progress, July 2000. [VPIMDIR] A. Brown and G. Vaudreuil "VPIM Directory Schema", work-in- progress, , July 2000. Vaudreuil Expires 1/1/01 [Page 10] Internet Draft VPIM Routing October 19, 2000 7. Acknowledgments TBD 8. Copyright Notice "Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 9. Authors' Addresses Gregory M. Vaudreuil Lucent Technologies, 17080 Dallas Parkway Dallas, TX 75248-1905 United States Phone/Fax: +1-972-733-2722 Email: GregV@ieee.org Vaudreuil Expires 1/1/01 [Page 11]