ENUM Working Group Internet Draft S. Lind Document: draft-lind-infrastructure-enum-reqs- AT&T 00.txt Expires: January 2006 July 2005 Infrastructure ENUM Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. 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. 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 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract There has been much discussion in various industries about the concept of infrastructure (or carrier) ENUM. Some of this discussion has been has been reflected within the ENUM WG mailing list and some within other organizations, including ETSI, the US ENUM Forum and the Country Code 1 ENUM LLC. While there has been consensus within some pockets of individual efforts, there has been little consensus industry-wide on even what infrastructure ENUM is, why it seems to be important, or what the requirements for implementing it are. At the request of the WG co-chairs, this document attempts to gather together the bits and pieces from those discussions (i.e., I stole Lind Expires - January 2006 [Page 1]
Infrastructure ENUM Requirements July 2005 the words shamelessly from the various sources) and, with an absolute minimum of editing, present them in some sort of cohesive manner that will enable enlightened discussion and hopefully achieve consensus. Some items listed below may be duplicative and suggest alternative wordings for similar and other contradictory issues. As such, this list is very raw and should not be viewed as complete, cohesive or correct. Conventions used in this document 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 [ii]. Table of Contents 1. Infrastructure ENUM............................................3 1.1 Definition.................................................3 1.2 Importance.................................................3 2. Requirements of Infrastructure ENUM............................4 2.1 Provisioning Requirements..................................4 2.2 Architecture Requirements..................................5 2.3 Application Behavior Requirements..........................5 3. Security Considerations........................................6 4. References.....................................................6 5. Author's Addresses.............................................7 6. Intellectual Property Statement................................7 7. Disclaimer of Validity.........................................8 8. Copyright Statement............................................8 Lind Expires - January 2006 [Page 2]
Infrastructure ENUM Requirements July 2005 1. Infrastructure ENUM 1.1 Definition a. Infrastructure ENUM is defined as the use of RFC 3761 [iii] by the carrier-of-record for a specific E.164 number [iv] to translate into a URI that specifies a specific point of interconnection to that service providerÆs network that could enable the originating party to establish communication with associated terminating party. It is separate from any URIs that the end-user, who registers their E.164 number, may wish to associate with that E.164 number. b. Carriers use E.164 numbers currently as their main naming and routing vehicle. Carrier ENUM in e164.arpa or another public available tree allows Carriers to link Internet based resources such as URIs to E.164 numbers (Note: this is the other way round then User ENUM). This allows Carrier in addition to interconnecting via the PSTN (or exclusively) to peer via IP- based protocols. Carriers may announce all E.164 numbers or number ranges they host, regardless if the final end-user device is on the Internet, on IP-based closed NGNs or on the PSTN, provided an access (e.g. SBC or gateway) to the destination carriers network is available on the Internet. There is also no guarantee that the originating carrier querying Carrier ENUM that is able to access the ingress network element of the destination carriers network. Additional peering and accounting agreements requiring authentication may be necessary. The access provided may also be to a shared network of a group of carriers, resolving the final destination network within the shared network. 1.2 Importance User ENUM in many countries requires end user opt-in and may give the end user the right to select the Tier 2 that hosts the terminal NAPTR records. These constraints are problematic for interconnection which requires registration for all served numbers and carrier control of Tier 2 to ensure reliability. With the move towards all IP networks applications, interworking must be addressed in order to facilitate global interoperability. Different networks should interwork with each other through secure interfaces that provide a high level of trust, particularly with regard to any routing information obtained from an ENUM database. Consideration must be given to how each network will interwork with other networks. Lind Expires - January 2006 [Page 3]
Infrastructure ENUM Requirements July 2005 Until now ENUM according to RFC3761 in e164.arpa (User ENUM) has not been seen as useful to an NGN/Telco/VoIP provider as it is reliant on user action in terms of registration, insertion of data and management of that data. Additionally, there is also controversy regarding the inclusion of data within the NAPTR records which may be publicly exposed in User ENUM. 2. Requirements of Infrastructure ENUM For ease in thinking about these requirements and how any proposed implementation might address them, they have been divided into three categories: provisioning, architecture, and application behavior. 2.1 Provisioning Requirements a. It should not require the introduction of new constructs within existing standards, such as new types or changed semantics of NAPTR records. b. The impact on existing implementations of User ENUM should be kept to a minimum. This implies that modifications to existing RFCs e.g. 3761, 3401-4 should be avoided. c. It should keep the option open for other types of closed-user- group type applications, which might not naturally fit into the predominantly voice-oriented - carrier ENUM scenario, like SMS or MMS POI resolution. d. Infrastructure ENUM should not remove the need for authentication that the party inserting, modifying or removing data in NAPTR records has a right to the corresponding number. Authentication is still required and an appropriate authentication procedure needs to be in place between the ENUM Tier 1 Registry and the carrier serving the number. e. Implementation of Infrastructure ENUM should not impact the ability of an end-user, in a competitive environment, to choose a Registrar and/or Tier 2 name server provider for end-user ENUM registrations. f. Designated DNS infrastructure for housing Infrastructure ENUM- related NAPTR records should have ôcarrier-classö reliability and performance. Lind Expires - January 2006 [Page 4]
Infrastructure ENUM Requirements July 2005 2.2 Architecture Requirements a. It should meet all reasonable privacy concerns about visibility of information an end user has no control over, for example discovery of unlisted numbers, or inadvertent disclosure of user identity. b. provide information on how to route a service to a point of carrier interconnection or ALG as expressed as a URI. For privacy and or network security reasons this information may_ need to be restricted to service providers and not generally available to end users. [editorÆs note: some have argued that they might provide a carrier record that generally points to a public interconnection point, but would provide pointers to specific interconnection points for specific interconnecting network providers.] c. It should be possible to introduce the scheme in a timely manner, supporting current carrier needs. Consequently, it is desirable to deploy the scheme without re-opening already settled questions of roles, responsibilities and international coordination. d. It should leave tree shape intact, i.e. requiring no wholesale changes to existing tree layout. e. It should be applicable for use with all national numbering plans; particular challenges may be to ensure that a global implementation is compatible with the use of variable length numbering (e.g. as used in Germany and Austria) and DDI blocks. f. It should work with both closed and open number plans without resorting to wildcard records in the non-user controlled part of the DNS, both to avoid associated semantic problems as well as keeping the route to DNSSEC deployment open. g. Some other groups, such as the GSM-A, have already decided to use a separate domain of their own for infrastructure ENUM purposes; e.g. "e164enum.net". The envisaged solution should also include these ENUM domains within a global ENUM infrastructure or at least to allow and facilitate interworking between these different domains. 2.3 Application Behavior Requirements Lind Expires - January 2006 [Page 5]
Infrastructure ENUM Requirements July 2005 a. A dialed E.164 number using ENUM should enable a call to go through. b. A single DNS lookup should suffice to resolve any given number. c. A minimum number (ideally one) of independent lookups should be required to obtain as many NAPTR records (end-user and carrier) as possible. d. A minimum number (ideally zero) of dependent lookups should be required to obtain as many NAPTR records (end-user and carrier) as possible. e. Additional functionality should only be imposed on carrier resolvers. f. It should leave user ENUM resolution semantics intact, i.e. requiring no wholesale changes to existing user ENUM resolvers. g. Pre-existing knowledge of the numbering format should be kept to a minimum. 3. Security Considerations Existing security considerations for ENUM detailed in RFC 3761 still apply. Note that some registration validation issues concerning end user ENUM may not apply to carrier ENUM. Where the Tier 1 registry is able to identify the carrier serving a number (e.g., based on industry data for number block assignments and number portability), registration might be more easily automated and a separate registrar not required. 4. References i Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. ii Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 iii Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. Lind Expires - January 2006 [Page 6]
Infrastructure ENUM Requirements July 2005 iv ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. 5. Author's Addresses Steven D. Lind AT&T Room A201 180 Park Avenue Florham Park, NJ 07932 USA Phone: +1-973-236-6787 Email: sdlind@att.com 6. 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Lind Expires - January 2006 [Page 7]
Infrastructure ENUM Requirements July 2005 7. Disclaimer of Validity 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. 8. 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. Lind Expires - January 2006 [Page 8]
