Skip to main content

Voice Message Routing Service
draft-ietf-vpim-routing-10

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4238.
Author Gregory Vaudreuil
Last updated 2020-01-21 (Latest revision 2005-04-08)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4238 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Scott Hollenbeck
Send notices to (None)
draft-ietf-vpim-routing-10
Internet Draft                                       Greg Vaudreuil 
       Expires in six months                           Lucent Technologies 
                                                             April 8, 2005  
                                   
                         Voice Message Routing Service 

                        <draft-ietf-vpim-routing-10.txt> 

                                         

     Status of this Memo 

       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 draft documents 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/1id-abstracts.html 

       The list of Internet-Draft Shadow Directories can be accessed at 
       http://www.ietf.org/shadow.html 

     Intellectual Property Notice 

       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. 

     Copyright Notice 

       Copyright (C) The Internet Society (2005).  All Rights Reserved. 

     Abstract 

       Voice messaging is traditionally addressed using telephone number 
       addressing. This document describes two techniques for routing 
       voice messages based on a telephone number.  The complete service 
       uses the VPIM Directory service 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 basic 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.  

        



       Internet Draft            VPIM Routing                April 8, 2005 

       Please send comments on this document to the VPIM working group 
       mailing list <vpim@ietf.org> 

       Vaudreuil                Expires 9/8/05                    [Page 2] 



       Internet Draft            VPIM Routing                April 8, 2005 

        

     Table of Contents 

     1.   DESIGN GOALS.....................................................4 
     2.   THE COMPLETE SERVICE.............................................5 
      2.1  Specification of Service "E2U+VPIM:LDAP"........................5 
      2.2  VPIM Directory Discovery........................................5 
      2.3  Address Query...................................................6 
     3.   THE BASIC SERVICE................................................7 
      3.1  Specification of Service "E2U+VPIM:Mailto:".....................7 
      3.2  Address Construction............................................8 
      3.3  Interdomain Message Routing.....................................8 
      3.4  Intradomain Message Routing.....................................8 
     4.   SECURITY CONSIDERATIONS..........................................10 
     5.   IANA CONSIDERATIONS..............................................10 
     6.   NORMATIVE REFERENCES.............................................10 
     7.   INTELLECTUAL PROPERTY NOTICE.....................................11 
     8.   COPYRIGHT NOTICE.................................................11 
     9.   AUTHORSÆ ADDRESSES...............................................12 
       

       Vaudreuil                Expires 9/8/05                    [Page 3] 



       Internet Draft            VPIM Routing                April 8, 2005 

     1.  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 use the ENUM address resolution 
       service to determine the VPIM directory, and then use LDAP to 
       retreive the VPIM-specific email address to use for message 
       routing.   

       The more 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 available.  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 9/8/05                    [Page 4] 



       Internet Draft            VPIM Routing                April 8, 2005 

     2. 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 should then 
       query that server for the email address and any additional 
       attributes desired. 

     2.1 Specification of Service "E2U+VPIM:LDAP" 

          * Service Name: E.164 to VPIM LDAP URL 

          * URI Type: "LDAP:" 

          * Type: VPIM 

          * Subtype: LDAP 

          * Functional Specification: See section 3.2 through 3.3 

          * Intended Usage: COMMON 

          * Author: Greg Vaudreuil (gregv@ieee.org) 

          * 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 LDAP URL. The possible intent may be to cause 
                the client to connect to a rogue LDAP server and 
                retrieve (or fail to retrieve) a resource containing 
                fraudulent or damaging information. 

             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 LDAP directory server. 

        

     2.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 as additional digits. 

       Vaudreuil                Expires 9/8/05                    [Page 5] 



       Internet Draft            VPIM Routing                April 8, 2005 

     Example: 

               Query: 2.1.2.1.5.5.5.3.1.6.1.e164.arpa  
               Responses:  
                 IN NAPTR  10 10 "U" "E2U+VPIM:LDAP" \   
                  "!^.*$!ldap://vdir1.Zcorp.com/telephoneNumber=\1!" .  

                 IN NAPTR  10 20 "U" " E2U+VPIM:LDAP" \   
                  "!^.*$!ldap://vdir2.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-1, NAPTR-2, 
       NAPTR-3, NAPTR-4] 

     2.3 Address Query 

       Once the VPIM directory is discovered, the client SHOULD issue a 
       LDAP query for the vPIMrFC822Mailbox, 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 9/8/05                    [Page 6] 



       Internet Draft            VPIM Routing                April 8, 2005 

     3. The Basic Service 

       The basic service relies upon NAPTR rewrite rules to mechanically 
       construct a valid VPIM-specific email address.  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 V2 profile. 

     3.1 Specification of Service "E2U+VPIM:Mailto:" 

          * Service Name: E.164 to VPIM MailTo: URL 

          * URI Type: "Mailto:" 

          * Type: VPIM 

          * Subtype: MAILTO 

          * Functional Specification: See section 4.2 through 4.4 

          * Intended Usage: COMMON 

          * Author: Greg Vaudreuil (gregv@ieee.org) 

          * 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 E2U+VPIM:Mailto 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 email URL. The possible intent may be to 
                cause the client to send the information to an 
                incorrect destination. 

       Vaudreuil                Expires 9/8/05                    [Page 7] 



       Internet Draft            VPIM Routing                April 8, 2005 

             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.   
                 

     3.2 Address Construction 

       Construct an VPIM email address using the address rewrite rules 
       of the NAPTR records associated with the VPIM service.  

        

     3.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. 

        

     3.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.   

       Vaudreuil                Expires 9/8/05                    [Page 8] 



       Internet Draft            VPIM Routing                April 8, 2005 

     3.4.1  Directory-Enabled Routing 

       Various proprietary directory mechanisms 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. 

                   Example address: +12145551212@sp.net 

        

     3.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 constructed domain name to 
       reroute messages. 

                   Example address: +12145551212@VPIM.sp.net 

        

       Vaudreuil                Expires 9/8/05                    [Page 9] 



       Internet Draft            VPIM Routing                April 8, 2005 

     4. 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. 

     4.1 Unsolicited Bulk Email 

       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. 

     4.2 DNS-based attacks 

       Both the complete and basic services rely upon the DNS to provide 
       the information necessary to validate a recipient or send a 
       message. The message sender is a casual, unauthenticated use of 
       the indicated servers, and relies upon the DNS for accurate 
       information. If the DNS is compromised, an attacker can redirect 
       messages by providing malicious email address or indicate a rogue 
       directory with malicious LDAP URL's.  Use of DNS Security 
       protocols [DNSSEC] substantially reduce the risk of a domain 
       being hijacked.  If the E.164 zone is secured with DNSSEC, then 
       the attack is precluded if the client can trust the key used to 
       sign the zone. DNS security does not protect against the LDAP 
       service independently being compromised.  Further discussion on 
       the risk to this LDAP service is provided in [VPIMDIR].  

     5. IANA Considerations  

       This specification registers the E2U+VPIM and E2U+Voice services 
       according to the specifications and guidelines in RFC 3761 [ENUM] 
       and the definitions in this document. 

     6. References 

     6.1 Normative References 

     [E164] CCITT Recommendation E.164 (1991), Telephone Network and 
        ISDN Operation, Numbering, Routing and Mobile Service - 
        Numbering Plan for the ISDN Era.   

     [ENUM] Falstrom, P., M. Mealling, "The E.164 to Uniform Resource 
        Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 
        Application (ENUM)", RFC3761, April 2004 RFC 3761 

     [NAPTR-1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 
        Part One: The Comprehensive DDDS", RFC 3401, October 2002. 

       Vaudreuil                Expires 9/8/05                   [Page 10] 



       Internet Draft            VPIM Routing                April 8, 2005 

     [NAPTR-2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 
        Part Two: The Algorithm", RFC 3402, October 2002. 

     [NAPTR-3]  Mealling, M., "Dynamic Delegation Discovery System 
        (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 
        3403, October 2002. 

     [NAPTR-4]  Mealling, M., "Dynamic Delegation Discovery System 
        (DDDS) Part Four: The Uniform Resource Identifiers (URI) 
        Resolution Application", RFC 3404, October 2002. 

      [VPIMDIR] G. Vaudreuil "VPIM Directory Schema", work-in-progress, 
        <draft-ietf-vpim-vpimdir-11.txt>, October 12, 2004. 

     6.2 Informative References 

     [VPIMV2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for 
        Internet Mail, Version 2", RFC 3801, June 2004. 

     [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D. and S. 
        Rose,, "DNS Security Introduction and Requirements", <draft-
        ietf-dnsext-dnssec-intro-13.txt>, April 2005. 

      

     7. Intellectual Property Notice 

       The IETF takes no position regarding the validity or scope of any 
       intellectual property or other rights that might be claimed to 
       pertain to the implementation or use of the technology described 
       in this document or the extent to which any license under such 
       rights might or might not be available; neither does it represent 
       that it has made any effort to identify any such rights.  
       Information on the IETF's procedures with respect to rights in 
       standards-track and standards-related documentation can be found 
       in BCP-11.  Copies of claims of rights made available for 
       publication and any assurances of licenses to be made available, 
       or the result of an attempt made to obtain a general license or 
       permission for the use of such proprietary rights by implementors 
       or users of this specification can be obtained from the IETF 
       Secretariat. 

       The IETF invites any interested party to bring to its attention 
       any copyrights, patents or patent applications, or other 
       proprietary rights which may cover technology that may be 
       required to practice this standard.  Please address the 
       information to the IETF Executive Director. 

     8. Copyright Notice 

       Copyright (C) The Internet Society (2005).  This document is 
       subject to the rights, licenses and restrictions contained in BCP 

       Vaudreuil                Expires 9/8/05                   [Page 11] 



       Internet Draft            VPIM Routing                April 8, 2005 

       78, and except as set forth therein, the authors retain all their 
       rights. 

       This document and the information contained herein are provided 
       on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
       REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 
       THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 
        9489 Bartgis Ct  
        Frederick, MD 21702 
        Email: GregV@ieee.org 

        

       Vaudreuil                Expires 9/8/05                   [Page 12]