From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4238.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc4238.txt (limited to 'doc/rfc/rfc4238.txt') 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 . + + 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] + -- cgit v1.2.3