Framework for ENUM Neutrality A.M. Rutkowski Document: VeriSign, Inc Expires: 1 Mar 2002 29 Aug 2001 Framework for ENUM Neutrality Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. However, see Author's Copyright Statement, below which accomplishes the same public availability. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The pursuit by major national Administrations of declared policies of ENUM technical and administrative neutrality among implementations in the marketplace suggest the need for a framework for such neutrality and a focus on interworking among them. [1] [2] This document draws upon the ENUM Working Group archive of discussions as well as public activities in other standards forums and the marketplace to construct an ENUM options framework for facilitating neutrality. This framework includes not only protocol considerations, but also various critical technical and administrative support functions such as authentication and ancillary directory services. Table of Contents 1. Introduction 2. Scope 3. ENUM Neutrality Framework and Elements 4. Security Considerations 5. References 6. Author's Address 7. Author's Copyright Statement 1. Introduction In the course of its development of domestic and international policies relating to ENUM implementations, the U.S. government established a set of principles for ENUM implementation neutrality. These principles were conveyed to the ITU-T Meeting of Study Group 2 (Geneva, 4-14 Sep 2001) along with a call for ongoing work of the Study Group to reflect these principles. [1] [2] These principles will be considered if not adopted by multiple Administrations. The principles call for several ongoing actions among multiple technical and operational communities. These include a requirement that "...deployments of ENUM and other similar protocols in any other top level DNS domain, nor restrict the development of other innovative services that may serve as competing ENUM alternatives." See [1] It notes specifically that "the promotion of interworking between different approaches and systems should be an ongoing pursuit." As general norms, ENUM implementations "must not be inconsistent with the positive goals of competition in telecommunications, the encouragement of innovation, the promotion of advanced data services, and the minimization of regulatory involvement and intervention." Ibid. ENUM is essentially about using a telephone number representation to map in diverse ways to some set of applications on various networked devices employed by a user or user agents for communication purposes. Telephone numbers are one of many identifiers possible to do this. The foci of recent ENUM efforts have been Internet based, although there have been numerous efforts undertaken to devise universal communications identifiers over many years. [3] The work on ENUM has proceeded over nearly the past decade going back to the pioneering work of Marshall Rose and Carl Malamud in 1993 that resulted in the Rose-Malamud schema for representing a telephone number in the Internet Domain Name System (DNS). [4] [5] [6] [7] When more recent efforts to establish telephone number mapping schema arose in the IETF in 1998, an array of different protocols and schema were proposed. At about the same time, pioneering companies like NetNumber began to develop and introduce ENUM implementations in the commercial marketplace using a combination of both DNS and LDAP protocols. [8] [9] [10] Last year, one particular ENUM approach based on the Rose-Malamud DNS schema and using a new DNS resource record type developed by Michael Mealling and Ron Daniel - Naming Authority Pointers (NAPTR) was considered by an IETF Working Group and denominated a Proposed Standard. [11] [12] Almost immediately, liaison communications via the Internet Society ensued with ITU-T Study Group 2 and ITU staff attempting to establish some kind of ITU related administrative relationship associated with this particular ENUM approach. The proposed standard attracted interest among some technical communities as a possible Internet DNS based mapping service based on telephone numbers to create a "universal communications identifier." This interest is reflected in some current ITU-T draft material that exclusively deals with the RFC 2916 ENUM schema. The RFC 2916 approach is attractive for its simplicity and flexibility in the use of URIs. However, it has some attributes, however, that may make it unattractive as a universal communications identifier in the public commercial marketplace. These notably include: 1) the ambiguous mapping of telephone numbers to end user identifiers, 2) the inability to control access to information that user may want to keep private, and 3) the tendencies to associate the number with E.164 regulatory regimes and telephone provider relationships. Additionally, the performance and trust characteristics of the RFC 2916 ENUM approach on a large-scale for some of its potential applications are completely unknown - particularly with multiple tiers. Although these may not be relevant in closed corporate Intranets, these factors represent very substantial consumer marketplace impediments. Late last year, NetNumber, Inc. evolved its hybrid DNS/LDAP ENUM solution to technically conform with RFC2916 by providing DNS based NAPTR lookups from the domain "e164.com". Several parties - including VeriSign - have maintained testbeds for experimentation, as required for new Internet protocols to determine protocol workability and marketplace interest. At the same time during the past year, a variety of telephony/ wireless, Internet standards, and large-scale proprietary provider developments have occurred that make it clear that multiple ENUM approaches and continuing evolution of the marketplace will continue. These developments include an ensemble of standards and services collectively known as Presence and Access Management (PAM), and the emergence of the Session Initiation Protocol (SIP) as a kind of universal communication platform. [10] - [17] These commercial implementations appear to provide viable solutions to the mapping, privacy, customer control, and security problems extant with the RFC 2916 approach. The resulting environment is almost certain to be richly multiprotocol and highly competitive among small and large players in the commercial marketplace worldwide. 2. Scope This is an informational Internet Draft containing a proposed technical and administrative framework and elements for ENUM neutrality among implementations. Such a framework is important to assure that if some special public governmental or intergovernmental arrangements are sought for particular ENUM offerings in the marketplace, such actions: 1) avoid prejudice to commercial ENUM offerings employing other element options, and 2) provide for fair and non-discriminatory access by other commercial competitive ENUM providers to publicly supported administrative and information resources. 3. ENUM Neutrality Framework and Elements In light of the requirement for ENUM neutrality, a wealth of discussions in the ENUM Working Group and other diverse forums, including commercial initiatives of AOL, Microsoft, and Sun in the entwined Presence and Access Management (PAM) sphere, can be assembled as an ensemble of different ENUM related implementation options. A. Mapping Protocol components for Telephone Number to Object Tags Basic Elements and Options: o Number Specification - E.164 - E.191 - Other o Querying Protocol(s) - DNS - LDAP - HTTP - Other o Querying Protocol Port and Other Variables - Standard (e.g., 53, 80, 389) - Other o Domain Used - e164.arpa. - e164.int. - e164.com. - e164.net. - other - Not Applicable o Number Structure - Rose-Malamud (e.g., 2.2.3.5.5.2.2.8.8.8.1.[domain] ) - DNS number (18882255322.[domain] ) - XML schema - Telcordia GR Series specification for SS7 based data - Proprietary - Other o Record Type(s) (for DNS based ENUM) - NAPTR [RFC2915] - SRV [RFC2782] - A [RFC1035] - AAAA (IPv6) - CNAME [RFC1035] - DNAME [RFC2672] - NS [RFC1035] - PTR [RFC1035] - RP [RFC1183] - LOC (geo location) - TKEY [RFC2930] - TSIG [RFC2845] - SIG [RFC2535] - KEY [RFC2535] - CERT [RFC2538] - Not Applicable o Objects - regex+URI - URI - rules - routing preferences - IP address - other data o Presence, Privacy and Access Controls - PAMforum PAM Specification - SIMPLE - Proprietary (AOL, Microsoft, Sun) - Other - None o Administrative Architecture - Numbering Plan Administration - Government - Cartel - Tiered Providers (e.g., Level 0, 1, 2, 3, ...) - Registry-Registrar bifurcation (e.g., using EPP) - Commercial enterprise - Other B. Support Components Basic Elements and Options: o Number Authentication - User service provider or agent - CNAM query - LIDB query - Other - None o Query Authentication(s) - DNSsec - Digital certificates - Reverse DNS lookups - SIMPLE - Proprietary (AOL, Microsoft, Sun) - Other - None o Object Authentication(s) - User service provider or agent - Digital certificates - SIMPLE - Proprietary (AOL, Microsoft, Sun) - Other - None o Ancillary Directory - LDAP - Whois - Aggregated directory information (e.g., RWhois,RDAP) - Disaggregated directory information - None Example 1: Using this framework, RFC2916 ENUM implementations would consist of the following Elements and options: A. Mapping Protocol components o Number Specification - E.164 o Querying Protocol - DNS o Querying Protocol Port and Other Variables - Standard (53) o Domain Used - e164.arpa. o Number Structure - Rose-Malamud (e.g., 2.2.3.5.5.2.2.8.8.8.1.[domain] ) o Record Type (for DNS based ENUM) - NAPTR [RFC2915] o Objects - regex+URI o Presence, Privacy and Access Control - None o Administrative Architecture - Government B. Support Components None specified Example 2: Using this framework, a hypothetical commercial competitive ENUM implementation might consist of the following Elements and options: A. Mapping Protocol components o Number Specification - E.164 o Querying Protocol(s) - DNS - LDAP - HTTP o Querying Protocol Port and Other Variables - Standard (e.g., 53, 80, 389) o Domain Used - e164.net. o Number Structure - Rose-Malamud (e.g., 2.2.3.5.5.2.2.8.8.8.1.e164.net) o Record Type(s) (for DNS based ENUM) - SRV - A o Objects - PAM based data o Presence, Privacy and Access Control - PAM implementation o Administrative Architecture - Commercial enterprise B. Support Components o Number Authentication - User service provider or agent - LIDB query o Query Authentication(s) - Digital certificates - Reverse DNS lookups - Proprietary (AOL, Microsoft, Sun) o Object Authentication(s) - User service provider or agent - Digital certificates - Proprietary (AOL, Microsoft, Sun) o Ancillary Directory - Aggregated directory information (e.g., RWhois, RDAP) 4. Security Considerations The diverse array of ENUM implementations in the marketplace give rise to a number of authentication, security, and privacy considerations. This framework attempts to identify some of these considerations as elements within the proffered framework. The providers of ENUM services will likely deploy an array of methods to enhance trust in the mapping of telephone numbers to digital objects. This autonomy suggests the usefulness of common trust methods and the availability of SS7 based services such as LIDB and CNAM. 5. References [1] United States of America, Participation in a Global Common ENUM DNS Domain, Doc. COM2-D.46, ITU Telecommunication Standardization Sector, Study Group 2, Geneva, 4 September - 14 September 2001. [2] United States of America, Continuation of the Rapporteur's Group on ENUM Supplement, Doc. COM2-D.43, ITU Telecommunication Standardization Sector, Study Group 2, Geneva, 4 September - 14 September 2001. [3] ITU-T Rec. F.500, International public directory services (08/92) [4] M. Rose and C. Malamud, An Experiment in Remote Printing, RFC 1486 (Aug 1993) [5] M. Rose and C. Malamud, Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures, RFC 1528 (Oct 1993 [6] M. Rose and C. Malamud, Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies, RFC 1529 (Oct 1993 [7] M. Rose and C. Malamud, Principles of Operation for the TPC.INT Subdomain: General Principles and Policy, RFC 1530 (Oct 1993). [8] IETF ENUM Working Group archives, ftp://ftp.ietf.org/ietf-mail-archive/enum/ [9] NetNumber, Inc. site, http://www.netnumber.com [10] A. Gulbrandsen, P. Vixie, L. Esibov, A DNS RR for specifying the location of services (DNS SRV), RFC 2782, Feb 2000 [11] M. Mealling, R. Daniel, The Naming Authority Pointer (NAPTR) DNS Resource Record, RFC 2915 (Sep 2000) [12] P. Falstrom, E.164 number and DNS, RFC 2916 (Sep 2000) [13] IETF Secretariat, IETF SIMPLE Working Group, http://www.ietf.org/html.charters/simple-charter.html [13] PAM Forum, PAM Specification Document, Ver. 1.0, http://www.pamforum.org/learn_more/PAMspec_1.0draft3.pdf (Apr 2001) [14] AOL Time-Warner, Open IM Architecture Design, http://aim.aol.com/openim/ [15] FCC Public Release, Messaging Interoperability, (DA No. 01-1791), (Dkt No 00-30). FCC 27 July 2001 http://www.fcc.gov/csb/aolim1.pdf [16] Microsoft, Windows XP home, http://www.microsoft.com/windowsxp/default.asp [17] Sun Microsystems, Liberty (SunOne), http://www.iplanet.com/learning/cd_content/sunone_ip.html (17 Aug 2001) 6. Author's Address for Comments Anthony M. Rutkowski Vice President for Internet Strategy VeriSign, Inc. 505 Huntmar Park Drive Herndon VA 20170 USA mailto:trutkowski@netsol.com tel: +1 703.742.4905 7. Author's Copyright Statement This compilation is expressly placed in the public domain by the author and is available to anyone for any purpose except their assertion of copyright ownership.