Telephone Number Mapping (enum) D. Ranalli D. Peek R. Walter Internet Draft Document: NetNumber February 2001 Category: Informational Tier-1 ENUM System Roles and Responsibilities Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This document describes the actors in a global Tier-1 ENUM system and the roles and responsibilities that each of the actors fulfills. In this context, a "Tier-1 ENUM system" refers to an Internet directory system for registering E164 telephone numbers in a DNS top-level domain as described in RFC 2916. The population of NAPTR records with URI's in a Tier-2 ENUM system as described in RFC 2916 is not discussed in this draft. Ranalli, et al Expires - August 2001 1 Tier-1 ENUM Roles and Responsibilities February 2001 2. 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 [2]. 3. Introduction Starting with the assignment of an E164 telephone number to an end- user ("Subscriber"), the roles and responsibilities of various actors in a global Tier-1 ENUM System are described. Please send comments on this document to the ENUM working group or directly to Doug Ranalli at dranalli@netnumber.com 4. Actors In The Tier-1 ENUM System 4.1 E.164 Administration System Well-defined process within the Public Switched Telephone Network (PSTN) for defining dialing plans, creating E164 numbers, and distributing blocks of numbers to network operators and telephone service providers. In the context of a Tier-1 ENUM System, the key players within the E164 Administration System include the following: - International Telecommunications Union (ITU): Defines country codes. - National PSTN Regulatory Agencies: Provide regulatory control over the PSTN numbering system within a country or region. - National Numbering Plan Administrators: Administer a numbering plan within a country or region under contract from a National PSTN Regulatory Agency. Create area-codes/city-codes. Distribute blocks of numbers to network operators and telephone service providers. - Number Portability Administrator: Administers the number portability process within a country or region under contract from a National PSTN Regulatory Agency. Provides mechanisms for shifting control of individual E164 numbers from one Telephone Number Provider to another based on Subscriber choice. 4.2 Telephone Number Provider (TNP) - E164 Control: Entity with contractual control over a block of E164 numbers and/or a set of ported E164 numbers via the E164 Ranalli, et al Expires - August 2001 2 Tier-1 ENUM Roles and Responsibilities February 2001 Administration process. Example: Network operator, application service provider, PSTN service provider, or their agents or assignees. - E164 Sub-allocation or Assignment: Entity that sub-allocates or assigns E164 numbers received from the E164 Administration System to Subscribers. - Tier-1 ENUM Service Disconnect: Entity with authority, but not the obligation, to cancel Tier-1 ENUM service for a given E164 number if the TNP has revoked a Subscriber's assignment of the number for any reason. Example: TNP disconnects a Subscriber's telephone service and puts an E164 number back into a pool for future assignment to a new Subscriber. The Registry disconnect right applies to E164 numbers under contractual control of the TNP through the E164 Administration allocation and sub-allocation process. - Dialing Plan Change Updates: Entity with the authority, but not the obligation, to submit dialing plan changes to the Tier-1 ENUM Registry relating to E164 numbers under the control of the TNP via the E164 Administration Process. 4.3 Subscriber - Individual or Enterprise that has been allocated or assigned an E164 number by a TNP and as a result, has day-to-day control over an E164 number. 4.4 Registrant - Subscriber, or an Agent (i.e.: service provider) acting on behalf of a Subscriber, that registers an E164 number with a Tier-1 ENUM service through an ENUM Registrar. - Agrees to be bound by the terms and conditions of the Tier-1 ENUM "Registration Agreement". Warrants that the e164 number being registered is under the day-to-day control of the Subscriber who's number is being registered. - Agrees to abide by the terms and conditions of the Tier-1 ENUM "Conflict Resolution Process". 4.5 Tier-1 ENUM Registry ("Registry") Entity that operates a Tier-1 ENUM directory service. Responsibilities include: Ranalli, et al Expires - August 2001 3 Tier-1 ENUM Roles and Responsibilities February 2001 - Delegation Services: Delegation of a complete E164 name to the appropriate Tier-2 ENUM service provider. - Registrant Database: Publicly accessible database with minimal information about Registrants to be used to identify potential registration conflicts. - Conflict Resolution: Service provided by the Registry for resolving conflict between two Registrants over valid control of an E164 number that has been registered in the Tier-1 Registry. - Validation Policy: Definition of the acceptable mechanisms that Registrars may employ for validating Registrant authority over an E164 number before submitting a registration in the Tier-1 ENUM service. - Dialing Plan Changes: Service provided by the Registry for modifying existing registrations to reflect dialing plan changes submitted by authorized TNP's. 4.6 ENUM Registrar ("Registrar") - Entity that has been authorized by the Tier-1 ENUM Registry operator to register E164 names and associated NS/A records into the Tier-1 ENUM Registry. - Registrant Validation: Responsible for complying with the validation policies defined by the Tier-1 Registry operator for validating that the E164 numbers being registered are under the day-to-day control of the Subscriber being represented by the Registrant. - TNP Validation: Responsible for validating the identity of any TNP requesting disconnection of Tier-1 ENUM services, or requesting dialing plan changes for Tier-1 ENUM services, to confirm that the TNP has contractual control over the E164 number(s) in question via the E164 Administration process. 4.7 Tier-2 ENUM Provider - Entity that provides Tier-2 ENUM services which involves the registration of URI's in DNS NAPTR resource records as defined in RFC 2916. The full scope of services provided by a Tier-2 ENUM provider is outside the scope of this Internet-Draft. Ranalli, et al Expires - August 2001 4 Tier-1 ENUM Roles and Responsibilities February 2001 5. Entity Relationship Diagram _ Tier-1 ENUM System ------------------- | E.164 | | Administration | | System | ------------------- | | V ------------------- | Telephone |---- | Number Provider | | ------------------- | | | | | V | ------------------- | | Registrant | | | (Subscriber or | | | Agent) | | ------------------- | | | | | V | ------------------- | | ENUM | | | Registrar |<--- ------------------- | | V ------------------- | Tier-1 ENUM | | Registry | ------------------- | | V ------------------- | Tier-2 ENUM | | Provider | ------------------- Ranalli, et al Expires - August 2001 5 Tier-1 ENUM Roles and Responsibilities February 2001 6. Typical Use Cases 6.1 ENUM Registration Registrant (Subscriber or an Agent acting on behalf of a Subscriber) registers an E164 number with a Tier-1 ENUM service through an ENUM Registrar by providing the E164 number and address (NS/A records) of the appropriate Tier-2 ENUM Provider to the Registrar. Registrar validates the identity of the Registrant to confirm day- to-day control over the E164 number being registered. Registrar submits the E164 number, the NS/A records for the appropriate Tier-2 ENUM Provider, and the required Registrant information to the Registry. The Registry either accepts or rejects the registration. If the registration is rejected due to a conflict over control of an E164 number, the Registry initiates the Conflict Resolution Process. 6.2 Conflict Resolution Conflict occurs in the Tier-1 ENUM registration process when two Registrants claim day-to-day control over the same E164 number. The Conflict Resolution service provided by the Registry is utilized by ENUM Registrars to resolve registration conflicts. 6.3 Service Termination By TNP TNP terminates a Subscriber's service and reclaims day-to-day control over an E164 number. TNP makes a request to an ENUM Registrar to terminate Tier-1 ENUM service for the E164 number. Registrar validates that the TNP is the entity with contractual control over the E164 number as defined by the E164 Administration System. The Registrar communicates the termination request to the Registry. The Registry terminates service and sends an e-mail message to the Registrant explaining the reason for the termination and the name of the TNP that terminated the service. 7. Security Considerations Ranalli, et al Expires - August 2001 6 Tier-1 ENUM Roles and Responsibilities February 2001 Tier-1 ENUM registry operators have the responsibility to protect physical and network resources, as well as, to ensure the validity of the DNS and its associated information. General ENUM users must be assured that they will receive valid information, and that they will be allowed access to this data without interruption. Registrars that have authority to manage entries must be assured that they are updating data in an authentic registry, have uninterrupted access to the data and are allowed to update the data after providing valid credentials. When preparing to prevent security breaches, the following types of attacks must be considered: Impersonation: Registrars that attempt to add and update entries must be able to unequivocally prove their identity to the registry. Spoofing or misrepresentation of the identity of the originator of the information could allow unauthorized updates to the database. Invalid or missing data could in turn cause malicious redirection and denial of service. Eavesdropping: If the privacy of the information that is being transmitted is compromised, then registrar-sensitive information such as the registrar's username and password, could be obtained by a malicious intruder. Data Tampering: During the transmission of directory records, valid URI's could be replaced by invalid URI's, in turn causing malicious redirection as discussed below. Since a higher percentage of security breaches such as data tampering are caused by "insiders", physical and network security must be addressed. Malicious Malicious entries into the database will cause users Redirection: to retrieve fraudulent or damaging content. This can be accomplished by either data tampering or server impersonation whereby a malicious server is masquerading as a registry server. Denial of There are several ways that a client could be denied Service: access to the desired registry resources. First, a malicious intruder could remove data from DNS, thus making it impossible for the client to access the information. Secondly, the system could be flooded with bogus requests that prevent communications. And finally, by breaching the physical security of the system, for example, by cutting off electricity to the facility. The SSL protocol is not an IETF Standards Track protocol. However, it is widely available and considered a defacto-standard for securely transmitting data over the Internet. The Transport Layer Security protocol is a Standards Track protocol that provides SSL v3.0 compatibility features and will be used when widely available. Ranalli, et al Expires - August 2001 7 Tier-1 ENUM Roles and Responsibilities February 2001 8. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14,RFC 2119, March 1997 [3] A. Brown, "Telephone Number Mapping", draft-enum-rqmts-01- txt,June 2000. [4] P. Faltstrom, "E.164 number and DNS," RFC 2916, September 2000. 9. Acknowledgements We would like to extend our special thanks to Lynette Khirallah for her expert advice on security considerations. 10. Author's Addresses Douglas Ranalli NetNumber 650 Suffolk Street, Suite 307 Lowell, MA 01854 Phone: +1-978-454-4210 x22 Email: dranalli@netnumber.com David P. Peek NetNumber 650 Suffolk Street, Suite 307 Lowell, MA 01854 Phone: +1-603-362-4315 Email: dpeek@netnumber.com Robert Walter NetNumber 650 Suffolk Street, Suite 307 Lowell, MA 01854 Phone: +1-978-454-4210 x24 Email: rwalter@netnumber.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it Ranalli, et al Expires - August 2001 8 Tier-1 ENUM Roles and Responsibilities February 2001 or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Ranalli, et al Expires - August 2001 9