summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4238.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4238.txt')
-rw-r--r--doc/rfc/rfc4238.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc4238.txt b/doc/rfc/rfc4238.txt
new file mode 100644
index 0000000..b703332
--- /dev/null
+++ b/doc/rfc/rfc4238.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+