GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4238

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] 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] 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] 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] 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] 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] 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] 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] 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] 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4238.txt · Last modified: 2005/10/28 18:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki