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]
