path: root/doc/rfc/rfc4238.txt

Network Working Group                                       G. Vaudreuil
Request for Comments: 4238                           Lucent Technologies
Category: Standards Track                                   October 2005


                     Voice Message Routing Service

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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
   Voice Profile for Internet Mail (VPIM) Directory service to lookup a
   VPIM email address with a telephone number and confirm that the
   address is both valid and associated with the intended recipient.
   However, this service will take time to become widely deployed in the
   near term.  This document also describes a basic send-and-pray
   service that routes and delivers messages using only the ENUM
   telephone number resolution service and the existing DNS mail routing
   facilities.



















Vaudreuil                   Standards Track                     [Page 1]
^L
RFC 4238             Voice Message Routing Service          October 2005


Table of Contents

   1. Design Goals ....................................................2
   2. The Complete Service ............................................3
      2.1. Specification of Service "E2U+VPIM:LDAP" ...................3
      2.2. VPIM Directory Discovery ...................................4
      2.3. Address Query ..............................................4
   3. The Basic Service ...............................................4
      3.1. Specification of Service "E2U+VPIM:Mailto:" ................5
      3.2. Address Construction .......................................6
      3.3. Interdomain Message Routing ................................6
      3.4. Intradomain Message Routing ................................6
           3.4.1. Directory-Enabled Routing ...........................6
           3.4.2. Service-based Mail Routing ..........................7
   4. Security Considerations .........................................7
      4.1. Unsolicited Bulk Email .....................................7
      4.2. DNS-based Attacks ..........................................7
   5. IANA Considerations .............................................8
   6. References ......................................................8
      6.1. Normative References .......................................8
      6.2. Informative References .....................................8

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 retrieve the
   VPIM-specific email address that will be used 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.  At a minimum, it
   should be possible to establish a simple mail forwarding rule that





Vaudreuil                   Standards Track                     [Page 2]
^L
RFC 4238             Voice Message Routing Service          October 2005


   sends 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.  95% of the time, that constraint can be a two-
   second response.

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




Vaudreuil                   Standards Track                     [Page 3]
^L
RFC 4238             Voice Message Routing Service          October 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 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.

   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 an
   LDAP query for the vPIMrFC822Mailbox, that is, the address that
   SHOULD be used as the value for both the RFC 822 To: field and the
   SMTP RCPT command.  See [VPIMDIR].

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.






Vaudreuil                   Standards Track                     [Page 4]
^L
RFC 4238             Voice Message Routing Service          October 2005


   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 there is no assurance 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 mechanism 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 sections 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                   Standards Track                     [Page 5]
^L
RFC 4238             Voice Message Routing Service          October 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 a 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 addresses may be useful.

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.



Vaudreuil                   Standards Track                     [Page 6]
^L
RFC 4238             Voice Message Routing Service          October 2005


         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
   telephone number-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

4.  Security Considerations

   There is little information disclosed to the sender of the message
   that is not already disclosed using standard email protocols.  The
   ability to use this protocol to probe for valid addresses is
   identical to the sending of test messages and waiting for a non-
   delivery notification in return.

4.1.  Unsolicited Bulk Email

   However, the use of ENUM records to create routable email addresses
   from telephone numbers provides bulk-emailers the capabilities 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 a
   malicious email address or indicating a rogue directory with
   malicious LDAP URL's.  Use of DNS Security protocols [DNSSEC]
   substantially reduces 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 being independently
   compromised.  Further discussion on the risk to this LDAP service is
   provided in [VPIMDIR].




Vaudreuil                   Standards Track                     [Page 7]
^L
RFC 4238             Voice Message Routing Service          October 2005


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

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

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

   [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)", RFC
              3404, October 2002.

   [VPIMDIR]  Vaudreuil, G., "Voice Messaging Directory Service", RFC
              4237, October 2005.

6.2.  Informative References

   [VPIMV2]   Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
              Mail - version 2 (VPIMv2)", RFC 3801, June 2004.

   [DNSSEC]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.












Vaudreuil                   Standards Track                     [Page 8]
^L
RFC 4238             Voice Message Routing Service          October 2005


Author's Address

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

   Gregory M. Vaudreuil
   Lucent Technologies
   9489 Bartgis Ct
   Frederick, MD 21702

   EMail: GregV@ieee.org








































Vaudreuil                   Standards Track                     [Page 9]
^L
RFC 4238             Voice Message Routing Service          October 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Vaudreuil                   Standards Track                    [Page 10]
^L