Network Working Group J. Peterson Internet-Draft T. McGarry Intended status: Informational NeuStar, Inc. Expires: January 7, 2016 July 6, 2015 Modern Problem Statement, Use Cases, and Framework draft-peterson-modern-problems-01.txt Abstract The functions of the public switched telephone network (PSTN) are gradually migrating to the Internet. This is generating new requirements for many mechanisms used on the PSTN, including telephone numbers (TNs). TNs no longer serve simply as telephone routing addresses, they are now identifiers which may be used by Internet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the needs of the Internet environment and proposes a framework for Internet-based services relying on TNs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 7, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Peterson & McGarry Expires January 7, 2016 [Page 1] Internet-Draft Modern Problems July 2015 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 2. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Acquiring Telephone Numbers . . . . . . . . . . . . . . . 6 4.1.1. CSP Acquires Numbers from Registry . . . . . . . . . 6 4.1.2. User/Delegate Acquires TNs from CSP . . . . . . . . . 7 4.1.3. User Acquires TNs from a Delegate . . . . . . . . . . 8 4.1.4. User Acquires Numbers from Registry . . . . . . . . . 8 4.2. Accessing Numbering Information . . . . . . . . . . . . . 8 4.2.1. Service Information Access . . . . . . . . . . . . . 8 4.2.2. Privileged Access for Government Entities . . . . . . 9 4.3. Service Management for Numbers . . . . . . . . . . . . . 9 4.3.1. Updating Service Information . . . . . . . . . . . . 9 4.3.2. Updating Administrative Information . . . . . . . . . 10 4.3.3. Changing the CSP for an Existing Communications Service . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.4. Terminating a Service . . . . . . . . . . . . . . . . 10 5. Distributed Registries and Data Stores . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Informative References . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Problem Statement The challenges of utilizing telephone numbers (TNs) on the Internet has been known for some time. Internet telephony provided the main use case for routing telephone numbers on the Internet in a manner similar to how calls are routed in the public switched telephone network (PSTN). As the Internet had no service for discovering the endpoints associated with telephone numbers, ENUM [3] created a DNS- based mechanism for resolving TNs in an IP environment, by defining procedures for translating TNs into URIs for use by protocols such as SIP [2]. Originally, it was envisioned that ENUM would be deployed as a global hierarchical service, though in practice, it has only been deployed piecemeal by various parties. Most notably, ENUM is used as an internal network function, and is hardly used between Peterson & McGarry Expires January 7, 2016 [Page 2] Internet-Draft Modern Problems July 2015 service provider networks. The original ENUM concept of a single root, e164.arpa, proved to be politically challenging, and less centralized models have thus flourished. Subsequently, the DRINKS [4] framework showed ways that authorities might provision information about telephone numbers at an ENUM service or similar Internet-based directory. These technologies have generally tried to preserve the features and architecture familiar from the PSTN numbering environment. Telephone numbering, however, has long been transitioning away from a provider-centric model towards a user-centric model. Number portability has been implemented in many countries, and the right of a user to choose and change their service provider while retaining their TN is widely acknowledged now. However, TN administration processes rooted in PSTN technology and policies dictate that this be an exception process fraught with problems and delays. Thanks to the increasing sophistication of consumer mobile devices, users now associate telephone numbers with many applications other than telephony. Ideally the user would have full control of their TN and would drive the porting process on their own rather than rely on complex and time consuming back office processes among multiple service providers. Most TNs today are assigned to specific geographies, at both an international level and within national numbering plans. This has shaped the way that service providers interconnect, as well as how telephone numbers are routed and administered: the PSTN was carefully designed to delegate switching intelligence geographically. In interexchange carrier routing in North America, for example, calls to a particular TN are often handed off to the terminating service provider close to the geography where that TN is assigned. But the overwhelming success of mobile telephones has increasing eroded the connection between numbers and regions. Furthermore, the topology of IP networks is not anchored to geography in the same way that the telephone network is. In an Internet environment, establishing a network architecture for routing telephone numbers would depend little on geography. Adapting telephone numbers to the Internet requires more security, richer datasets and more complex query and response capabilities than previous efforts have provided. With the PSTN well on its way to transitioning to an all IP network, and TNs showing no signs of sunsetting as a resource, it is time to address the issues of routing, management and administration of TNs in an IP environment. This document will create a common understanding of the problem statement related to TNs in an IP environment and help develop a vision for how to create IP-based mechanisms for TNs. It will be important to acknowledge that there Peterson & McGarry Expires January 7, 2016 [Page 3] Internet-Draft Modern Problems July 2015 are various international and national policies and processes related to TNs, and any solutions need to be flexible enough to account for these variations. 2. Actors The following actors are defined in this document: Numbering Authority: A regulatory body within a country that manages that country's telephone numbers. The numbering authority decides national numbering policy, including what telephone numbers can be allocated, and which are reserved. Registry: An entity that administers the allocation of telephone numbers based on a numbering authority's policies. Numbering authorities can act as the registries themselves, or they can outsource the function to other entities. A registry can act as a sole authoritative entity for a numbering authority, or there can also be multiple registries that manage the same telephone numbers and synchronize with each other. Communication Service Provider: A provider of communications services to users, where those services can be identified by telephone numbers. This includes both traditional telephone carriers or enterprises as well as service providers with no presence on the PSTN who use telephone numbers. This framework does not assume that any single CSP provides all the communications service related to a TN. Service Enabler: An entity that works with CSPs to enable communication service to a user; perhaps a vendor, or third-party integrator. User: An individual reachable through a communications service; usually a customer of a communication service provider who uses telephone numbers to reach and identify services. Sophisticated users may also act as their own CSPs. Government Entity: An entity that, due to legal powers deriving from national policy, has privileged access to information about number administration under certain conditions. Note that a given entity may act in one or more of the roles above. An entity acting as a Communications Service Provider, Service Enabler, or User can also be said to have a relationship to the registry of either an assignee or delegate: Peterson & McGarry Expires January 7, 2016 [Page 4] Internet-Draft Modern Problems July 2015 Assignee.: An entity that is assigned the telephone number by the registry. There is a direct relationship between the registry and the assignee. Delegate: An entity that is delegated a telephone number from an assignee or another delegate for assignment or delegation to others. A delegate is not the assignee or the user. Note that although numbering authorities are listed as actors, they are unlikely to actually participate in the protocol flows themselves. 3. Framework The framework outlined in this document requires three Internet-based mechanisms for managing and resolving telephone numbers (TNs) in an IP environment. These mechanisms will likely reuse existing protocols for sharing structured data; it is unlikely that new protocol development work will be required, though new information models specific to the data itself will be a major focus of framework development. Likely candidates for reuse here include work done in DRINKS and WEIRDS, as well as the TeRQ [12] framework. These protocol mechanisms are scoped in a way that makes them likely to apply to a broad range of future policies for number administration. It is not the purpose of this framework to dictate number policy, but instead to provide tools that will work with policies as they evolve going forward. These mechanisms therefore do not assume that number administration is centralized, nor that number "ownership" is restricted to any privileged service providers, though these tools must and will work in environments with those properties. The three mechanisms are: Acquisition: a protocol mechanism to enable users or CSPs to acquire TNs from authorities, including an enrollment process for the individuals and entities that manage TNs. Management: a protocol mechanism for users to associate data with TNs at a CSP. Retrieval: a protocol mechanism for service providers, users, and government entities to retrieve data about TNs from either an authority or a CSP. The acquisition mechanism will enable actors to acquire telephone numbers for use with a communications service. The acquisition mechanism will provide a means for either a user or a CSP to request Peterson & McGarry Expires January 7, 2016 [Page 5] Internet-Draft Modern Problems July 2015 numbering resources from an authority, either on a number-by-number basis, or as inventory blocks. The authority who grants numbering resources to a user will retain metadata about the assignment, including the responsible organization or individual to whom numbers have been assigned. In the DNS environment, an authority thus might be analogous to either a registrar or a reseller of names, though obvious hierarchical domain names do not have a comparable inventory situation to telephone numbers. The management mechanism will let actors provision data associated with telephone numbers at CSPs. If a user owns a telephone number, they may select a CSP to provide a particular service associated with the number, or a CSP may own a number, and effectively rent these to users. In either case, a user needs a mechanism to provision data associated with the number at a CSP. The resolution mechanism will enable actors to learn information about telephone numbers, typically by sending a request to a CSP. For some information, an actor may need to send a request to a numbering authority rather than a CSP. Different parties may be authorized to receive different information about telephone numbers. 4. Use Cases The high-level use cases in this section will provide an overview of the expected operation of the three protocols in the MODERN problem space. 4.1. Acquiring Telephone Numbers There are various scenarios for how TNs can be acquired by the relevant actors; registry, CSP, delegate, service enabler, and user. The registry perform its functions as defined by the national authority, so the national authority does not participate in the protocol flows in this section. 4.1.1. CSP Acquires Numbers from Registry Through some out-of-band business process, a CSP develops a relationship with a Registry. The Registry has a profile of the CSP and what qualifications they possess for requesting TNs. The CSP may then request TNs from within a specific pool of numbers in the authority of the Registry; such as region, mobile, wireline, tollfree, etc. The Registry must authenticate and authorize the CSP, and then either grant or deny a request. When an assignment occurs, the registry stores information related to the assignment including the resource and the assignee, and removes the specific TN(s) from the pool of those that are available for assignment. As a part of Peterson & McGarry Expires January 7, 2016 [Page 6] Internet-Draft Modern Problems July 2015 the assignment process, the Registry provides credentials (for example, STIR certificates [13]) to the CSP to be used to prove the assignment for future transactions Before it is eligible to receive number assignments, per the policy of a national authority, the CSP may need to have submitted (again, through some out-of-band process) additional qualifying information such as current utilization rate or a demand forecast. There are two scenarios under which a CSP requests resources; they are requesting inventory, or they are requesting for a specific user or delegate. If they are requesting for a user or delegate they may need to register information about the user or delegate with the Registry. Examples of user and delegate information could be contact information that may be required by Government Entities, or some forms of service information. Such data could be provided to the Registry or the Registry could be provided with an address where that data can be accessed. Such an address could be part of the CSP profile with the Registry. 4.1.2. User/Delegate Acquires TNs from CSP A User or Delegate creates or has a relationship with the CSP, and subscribes to a communications service which includes the use of a telephone number. The CSP first collects and stores profile data about the User or Delegate. The CSP then activates the User or Delegate on their network and creates any necessary service data to enable interoperability with other CSPs. The CSP could also update public or privileged databases accessible by other Actors. The CSP provides a credential to the User or Delegate (for example, a STIR certificate [13]) to prove the assignment for future transactions. The credential could be delegated from the one provided by the Registry to the CSP in a continuing the chain of assignment. The CSP could assign a TN from its existing inventory or it could acquire it from the Registry as part of the assignment process. If it assigns it from its existing inventory it would remove the specific TN from the pool of those available for assignment. It may also update the registry about the assignment so the registry has current utilization data. If TNs are assigned to a Delegate for use as inventory to be assigned to Users, the Delegate may need to provide utilization data to the Registry, either directly or through the CSP. Peterson & McGarry Expires January 7, 2016 [Page 7] Internet-Draft Modern Problems July 2015 4.1.3. User Acquires TNs from a Delegate This follows the process in Section 4.1.2, as it should be similar to how a User acquires TNs from a CSP. In this case, the Delegate would be performing functions done by the CSP, e.g., providing credentials, updating the Registry, and so on. 4.1.4. User Acquires Numbers from Registry This follows the process in Section 4.1.1, as it should be similar to how a CSP acquires TNs from a Registry. In this case, the user must establish some business relationship directly to a registry, perhaps similarly to how such functions are conducted today when users purchase domain names. TNs assigned to a user are always considered assigned by the Registry, not inventory. In this use case, after receiving a number assignment from the Registry, a User will then obtain communications service from a CSP, and provide to the CSP the TN to be used for that service. The CSP will associate service information for that TN, e.g., service address, and make it available to other CSPs to enable interoperability. 4.2. Accessing Numbering Information Telephone numbering information will generally fall into two categories; administrative information and service information. Administrative information includes TN status, service provider, contact data, etc. and typically does not require real-time performance. Service information includes addressing data, feature capabilities, etc. and typically does require real-time performance. Telephone numbering data can be stored at the Registry or at the CSP that holds the information. The address for accessing the information would need to be available to others to enable access and interoperability. For example, if the data is held by the Registry, a URL for accessing that data could be published to those that have access to the Registry. The Registry could allow and restrict access to specific information based on the identity of requestor. If the data is held by a CSP, the Registry could host an address for each TN that references the correct CSP, and the CSP would allow or restrict access based on the requestor. 4.2.1. Service Information Access A gateway receives a call for a telephone number. That telephone number is assigned to a CSP, who has delegated to the number to a User. The gateway wants to reach the User through an Internet Peterson & McGarry Expires January 7, 2016 [Page 8] Internet-Draft Modern Problems July 2015 communications endpoint. It therefore send a query to the Registry responsible for the numbering space that the telephone number resides in. The Registry proxies or redirects the request to the CSP that has been assigned the number. The CSP returns Internet endpoint information for that number to the gateway, possibly after making an authorization decision. In an alternative use case, the CSP might provision the Registry with endpoint service information for the telephone number, or the CSP might have delegated to the User the responsibility for provisioning this information with the Registry. 4.2.2. Privileged Access for Government Entities In this case, a Government Entity wishes to access information about a particular User, who subscribes to a communications service. The entity that operates the Registry on behalf of the National Authority in this case has some pre-defined relationship with the Government Entity. When the CSP acquired TNs from the National Authority, it was a condition of that assignment that the CSP provide access for Government Entities to telephone numbering data when certain conditions apply. The required data may reside either in the CSP or in the Registry. For a case where the CSP delegates a number to the User, the CSP might provision the Registry with information relevant to the User. At such a time as the Government Entity needs information about that User, the Government Entity may contact the Registry or CSP to acquire the necessary data. The interfaces necessary for this will be the same as those described in Section 4.2; the Government Entity will be authenticated, and an authorization decision will be made by the Registry or CSP under the policy dictates established by the National Authority. 4.3. Service Management for Numbers The use cases in this section describe ways that numbering data, including administrative information and service information, might be updated at the CSP or Registry after a number has been initially assigned and provisioned. 4.3.1. Updating Service Information A CSP handles all users in a large region through a central set of proxy servers. They provision a URL pointing to that service in the Registry. After a business transition, the CSP wants to point the service to a new URL. The CSP therefore sends a provisioning update to the Registry. Peterson & McGarry Expires January 7, 2016 [Page 9] Internet-Draft Modern Problems July 2015 While some similar use cases may apply to individual Users, it is anticipated that for the most part these lower-level service information changes would be communicated via existing protocols (like the baseline [2] SIP REGISTER method) rather than through any interfaces defined by MODERN. 4.3.2. Updating Administrative Information A User who subscribes to a communications service changes their postal address, moving from one location in the country to another. At this time, the User informs the CSP. The CSP updates its own records, and send an update to the Registry as well, as the National Authority in this case requires that the CSP notify the Registry of changes in the contact information associated with numbering resources. 4.3.3. Changing the CSP for an Existing Communications Service A User who subscribes to a communications service, and received their TN from that CSP, wishes to retain the same TN but move their service to a different CSP. Depending on the policies set by the National Authority, it might be the responsibility of either the old or new CSP to initiate the transition process. The new CSP will then provision the registry with the new service and administrative information associated with the CSP, though much of the administrative information relating to the User may remain the same through this transition. The CSP will perform other functions described above in Section 4.1.2. At this time, the old CSP will undo any delegations to the User, including invalidating any cryptographic credentials (e.g. STIR certificates [13]) previously granted to the user. Any routing or service information maintained by the CSP must be removed, and similarly, the CSP must delete any such information it provisioned in the Registry. [TBD - more on the case where multiple CSPs provide services for a given TN, and only one service is "ported" to a new CSP?] 4.3.4. Terminating a Service This use case is very similar to that in Section 4.3.3. A User who subscribes to a communications service, and received their TN from the CSP, wishes to terminate their service. At this time, the CSP will undo any delegations to the User, including invalidating any cryptographic credentials (e.g. STIR certificates [13]) previously granted to the user. Any routing or service information maintained Peterson & McGarry Expires January 7, 2016 [Page 10] Internet-Draft Modern Problems July 2015 by the CSP must be removed, and similarly, the CSP must delete any such information it provisioned in the Registry. In an alternative use case, a User who received their own TN assignment directly from the Registry terminates their service with a CSP. At this time, the User might terminate their assignment from the Registry, and return the number to the Registry for re- assignment. Alternatively, they could retain the number and elect to assign it to some other service at a later time. 5. Distributed Registries and Data Stores It is possible to create a distributed Registry or distributed Data Stores for the administrative and service information associated with a TN. In a distributed Registry there would be multiple duplicate copies of the Registry data. A CSP or User would interact with one Registry and that Registry would be responsible for initiating updates to all other Registries when there is a change. The challenge is to ensure that there are no clashes, e.g., two Registries assigning the same TN to two different CSPs. Similarly multiple entities can maintain duplicate copies of administrative and service data associated with TNs. For example, when a CSP enables service for a User they can initiative an update of the service address to multiple other data stores managed by other service providers. This may not be the best solution for User contact data. [More TBD] 6. Acknowledgments We would like to thank Henning Schulzrinne for his contributions to this problem statement and framework. 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations TBD. Peterson & McGarry Expires January 7, 2016 [Page 11] Internet-Draft Modern Problems July 2015 9. Informative References [1] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [2] 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. [3] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, March 2011. [4] Channabasappa, S., "Data for Reachability of Inter-/Intra- NetworK SIP (DRINKS) Use Cases and Protocol Requirements", RFC 6461, January 2012. [5] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002. [6] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [7] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012. [8] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007. [9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [10] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, January 2008. [11] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real- time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010. Peterson & McGarry Expires January 7, 2016 [Page 12] Internet-Draft Modern Problems July 2015 [12] Peterson, J., "A Framework and Information Model for Queries about Telephone-Related Queries (TeRQ)", draft- peterson-terq-03 (work in progress), February 2013. [13] Peterson, J., "Secure Telephone Identity Credentials: Certificates", draft-ietf-stir-certificates-01 (work in progress), March 2015. [14] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- Huguenin, "Verification Involving PSTN Reachability: Requirements and Architecture Overview", draft-jennings- vipr-overview-06 (work in progress), December 2013. [15] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. Authors' Addresses Jon Peterson Neustar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Email: jon.peterson@neustar.biz Tom McGarry Neustar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Email: tom.mcgarry@neustar.biz Peterson & McGarry Expires January 7, 2016 [Page 13]