ENUM Working Group H. Kaplan Internet Draft Acme Packet Intended status: Standards Track R. Walter Expires: June 11, 2008 NetNumber R. Gopal Nominum T. Creighton Comcast Cable Communications December 11, 2007 DNS Extension for ENUM Source-URI draft-kaplan-enum-source-uri-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on June 11, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Kaplan Expires June 1, 2008 [Page 1] DNS Extension for ENUM Source-URI December 2007 Abstract This document defines a specific DNS extension, based on the EDNS0 OPT RR, for an ENUM query to include the source URI which caused the ENUM request. This is useful, for example, to specify the originating SIP or TEL URI from a SIP request which triggered the ENUM query, so the ENUM server can provide a different response. Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. Applicability...............................................3 4. Overview of Operation.......................................3 5. ENUM Client Behavior........................................4 6. ENUM Server Behavior........................................4 7. DNS Extension Option Code...................................4 8. Opt-RR Format...............................................4 9. RDATA Format................................................5 10. Example Exchange............................................5 11. Security Considerations.....................................5 12. IANA Considerations.........................................6 13. References..................................................6 13.1. Normative References...................................6 13.2. Informative References.................................6 Authors' Addresses................................................6 Full Copyright Statement..........................................8 Intellectual Property Statement...................................8 Acknowledgment....................................................8 1. Introduction SIP session routing based on private-ENUM resolution has been gaining ground in some large operator networks. However, a need has arisen to respond with different ENUM/DNS responses based on the originating username or domain of the application request which triggered the ENUM query, such as a SIP request. For example, it is often cheaper to route calls from local source prefix numbers to other local prefixes numbers in a given region directly, whereas out-of-region sources going to the same destination numbers may be cheaper to send through a transit provider or even the PSTN. Another example is when only certain calling domains can source specific calling numbers, and ENUM is used to determine the legitimacy of the source. Kaplan Expires - June 2007 [Page 2] DNS Extension for ENUM Source-URI December 2007 Today such source-based routing with ENUM is performed through various means, which are usually cumbersome and error-prone. A common example is where the proxy performing the lookup changes the ENUM root based on a source prefix, and thus the ENUM server has a separate root per source prefix; or the server returns all possible results with proprietary indicators for source filtering. These mechanisms typically require the ENUM client and server to agree on a common scheme, and require every proxy to know and use the same proprietary scheme, which leads to interoperability problems. This draft proposes a specific, yet flexible, mechanism for performing such lookups. The DNS extension OPT RR mechanism defined in [EDNS0] is used to provide the ENUM server the source URI of the SIP request, with which it can make its own local decision of which responses to provide. Note that using the OPT RR for this purpose is not a perfect model. Local response caching must be avoided, and typically the OPT RR is used for generic DNS capabilities below the database layer, rather than as part of the input to the database lookup. In particular, it does not address how such source information is populated in the DNS server records or tree, which may lead to different implementations, and does not describe how to transfer such data between DNS servers. Instead, this draft is focused on ENUM servers, rather than all DNS servers. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". 3. Applicability This draft proposes a DNS extension based on [EDNS0]. 4. Overview of Operation The general concept is that a SIP/H.323/etc. UAC or Proxy, acting as the ENUM client, inserts the URI from the SIP Request's P-Asserted- Identity header, or the From header, or the calling party info, in an OPT RR RDATA field in the ENUM query. The ENUM server then may use the originating URI information (username, domain, etc.) in choosing what responses to send in response to the query. Kaplan Expires - June 2007 [Page 3] DNS Extension for ENUM Source-URI December 2007 5. ENUM Client Behavior The ENUM client inserts the originating URI in the RDATA portion of an [EDNS0] OPT RR in the ENUM query, by copying the SIP-URI, SIPS- URI or TEL-URI from the P-Asserted-Identity header, if present, and if not present then that from the From header of the request. For H.323 or other protocols, a TEL-URI is formed from the calling number. Note that for SIP, this would include both the full sip:username@domain and any URI parameters. It does NOT include any display-name, less-than or greater-than symbols (LAQUOT/RAQUOT), or header parameters. It is literally the SIP-URI or SIPS-URI as defined by the ABNF in [RFC3261], or the telephone-URI as defined by [RFC3966]. The ENUM client MUST NOT cache responses for such queries, and instead MUST treat the TTL value as zero. Otherwise the local cache would be used for subsequent queries, even if the originating info changed, which would lead to false results. Clearly this could be overridden based on local policy, if the client had control of its DNS cache implementation to include the originating number. However, it should be noted that typical ENUM queries hardly ever benefit from caching, because the probability of the same numbers being dialed in a short interval are very low. 6. ENUM Server Behavior An ENUM Server which supports this extension MAY use the originating URI encoded in the RDATA for its lookup process. The details of how it does so are out of scope of this draft. The ENUM Server MUST support the SIP-URI, SIPS-URI and telephone-URI formats, as defined by [RFC3261] and [RFC3966] respectively. It MUST ignore any parameters it does not understand - i.e., it is not a protocol failure that the URI contains parameters the ENUM server does not understand. The ENUM server MUST set all responses for requests which contained this extension with a TTL of zero. 7. DNS Extension Option Code The EDNS0 Option Code will be assigned by IANA. 8. Opt-RR Format All OPT-RRs used in Source-URI are formatted as follows: Kaplan Expires - June 2007 [Page 4] DNS Extension for ENUM Source-URI December 2007 Field Name Field Type Description ------------------------------------------------------------------- NAME domain name empty (root domain) TYPE u_int16_t OPT CLASS u_int16_t 1220 (minimum)* TTL u_int32_t 0 RDLEN u_int16_t describes RDATA RDATA octet stream (see below) * The CLASS field indicates, as per [EDNS0], the sender's UDP payload size. Per [draft-ietf-enum-edns0], ENUM clients MUST support 1220 bytes, but SHOULD support at least 4000. 9. RDATA Format Field Name Field Type Description -------------------------------------------------------------------- OPTION-CODE u_int16_t Source-URI OPTION-LENGTH u_int16_t Length of following fields VERSION u_int16_t Version of S-URI mechanism URI char_string SIP/SIPS/TEL-URI data The current Version is 0. Future drafts may specify other versions, but they must be compatible with this one. (i.e., they can specify more data, but not less) The URI field is null-terminated, ASCII representation of the URI. One example is a SIP/SIPS/TEL-URI, including the "sip:", "sips:", or "tel:" schemes. Non-Ascii characters, or characters not allowed in the ABNF for a SIP-URI/SIPS-URI/TEL-URI format per [RFC3261] or [RFC3966] MUST be escaped per those formats. 10. Example Exchange [Do we need an example?] 11. Security Considerations There are no specific security issues for this mechanism, beyond those already applicable to DNS and ENUM. Kaplan Expires - June 2007 [Page 5] DNS Extension for ENUM Source-URI December 2007 12. IANA Considerations This document will presumably register appropriate Option code with IANA, if it moves forward. 13. References 13.1. Normative References [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. 13.2. Informative References [draft-ietf-enum-edns0] Conroy, L., Reid, J., "ENUM Requirement for EDNS0 Support", draft-ietf-enum-edns0-00.txt, September 2006. Authors' Addresses Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA Email: hkaplan@acmepacket.com Robert H. Walter NetNumber, Inc. 650 Suffolk Street, Suite 307 Lowell, MA 01854 USA Email: rwalter@netnumber.com Raja Gopal Nominum, Inc. 2385 Bay Road Redwood City, CA 94063 USA Email: raja.gopal@nominum.com Kaplan Expires - June 2007 [Page 6] DNS Extension for ENUM Source-URI December 2007 Tom Creighton Comcast Cable Communications 1500 Market Street Philadelphia, PA 19102 USA Email: tom_creighton@cable.comcast.com Kaplan Expires - June 2007 [Page 7] DNS Extension for ENUM Source-URI December 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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 Statement 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Thanks to Richard Shockey, Prakash Mistry, and David Schwartz for feedback and comments. Kaplan Expires - June 2007 [Page 8]