Network Working Group J. Peterson Internet-Draft Neustar Intended status: Informational C. Wendt Expires: September 6, 2018 Comcast March 5, 2018 Using Telephone Related Information (TeRI) with the Distributed Registry Protocol (DRiP) draft-peterson-modern-drip-teri-00.txt Abstract The Distributed Registry Protocol (DRiP) allows a set of nodes to implement a decentralized registry function. This document explores how Telephone Related Information (TeRI) Records can be shared by DRiP, and a decentralized registry approaches the operations necessary to assign, provision, and route for telephone numbers. 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 https://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 September 6, 2018. Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of 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 Peterson & Wendt Expires September 6, 2018 [Page 1] Internet-Draft DRiP TeRI March 2018 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. CSP Acquires a Block . . . . . . . . . . . . . . . . . . 4 3.3. CSP Acquires a Single Number . . . . . . . . . . . . . . 4 3.4. CSP Assigns a Single Number within its Block . . . . . . 5 3.5. Number Porting . . . . . . . . . . . . . . . . . . . . . 5 4. Identity Elements in TeRI . . . . . . . . . . . . . . . . . . 6 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Informative References . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The Distributed Registry Protocol (DRiP) [I-D.wendt-modern-drip] is a protocol that enables a distributed set of nodes to synchronize information in real-time with a minimal amount of delay. DRiP assumes a peer-to-peer gossip network that shares key-value pairs. The protocol is intended to carry information related to personal communication, including identifiers like telephone numbers and related identity information about the participants in communication. The Telephone Related Information [I-D.peterson-modern-teri] information model provides a framework for distributing Records that convey service or administrative data about telephone numbers. TeRI Records are signed by entities such as CSPs or Registrars who possess credentials which enable relying parties to trust that Records have been created or modified by the appropriate parties for a particular telephone number, such as STIR [RFC8226] certificates. In TeRI parlance, anyone holding such a credential attesting authority over telephone number resources is called an "Authority." TeRI Records containing service data provide routing information for telephone numbers, and may be retrieved from local caches, remote services, or even a distributed network, as relying parties trust Authorities rather than services. The TeRI Record format therefore seems suitable for distribution via DRiP. Following the MODERN framework [I-D.ietf-modern-problem-framework], TeRI usages for centralized registries support three fundamental operations on telephone numbers: acquisition, management, and Peterson & Wendt Expires September 6, 2018 [Page 2] Internet-Draft DRiP TeRI March 2018 retrieval. There are at a high level a couple of potential ways to approach using TeRI with DRiP: for example, the gossip protocol could be used as a transport layer to pass client-server requests to what is effectively a centralized Authority that actually creates and signs TeRI Records; or, more interestingly, nodes in the gossip network might all act as Authorities, possessing credentials that enable them to create and sign TeRI Records themselves and then vote on their validity to prevent conflicts and race conditions. The possibility of a decentralized registry based on the latter principle largely motivates this exploration of the intersection between TeRI and DRiP. This initial draft explores some key use cases for TeRI over DRiP, and how they differ from the use cases already given in the baseline MODERN framework [I-D.ietf-modern-problem-framework]. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]. 3. Use Cases 3.1. Assumptions It is assumed in the MODERN system that before any actor can interact with a Registry, a Credential Authority provides certificate credentials to individual actors corresponding to their identity and role: such as the CSPs and Users of the MODERN framework [I-D.ietf-modern-problem-framework]. For the purposes of this document, we assume those credentials are STIR [RFC8226] certificates associated with telephone number blocks that can be managed by the distributed Registry. These use cases explore the possibility that there could be more than one distinct administrative entity who holds credentials authorizing them to generate TeRI Records for the same numbering resources: effectively, that set of Authorities functions as a distributed Registry. Imagine, for example, that in the North American Numbering Plan an experimental area code were created that enabled any CSP authorized by the distributed Registry to reserve a new telephone number on a first come first serve basis - with some policy controls. For these use cases we assume that a policy governs the acquisition of telephone numbers in the distributed Registry. For example, there could be a financial cost of acquiring numbers that goes up Peterson & Wendt Expires September 6, 2018 [Page 3] Internet-Draft DRiP TeRI March 2018 dramatically if CSPs acquire resources too greedily; or alternatively, there could be some policy enforcement of the ratio of allocated to assigned numbers a CSP has claimed to maintain an agreed reasonable level of number inventory per CSP. In the DRiP gossip network, there could moreover be a "policy node" that simply votes "no" when new TeRI Records that conflict with the policy are propagated. These initial use cases are however "sunny day" cases where we assume that CSPs scrupulously adhere to policy. 3.2. CSP Acquires a Block In the following case, a CSP performs acquires a block of telephone numbers, placing it under their control using their credentials. First, assume that a Numbering Authority has unallocated number blocks that are eligible for allocation, and that these resources have been made available to the distributed Registry. Then, a CSP participating in the distributed Registry declares its intention to allocate one such block of Numbers. In centralized MODERN architectures, the CSP would send a TeRI acquisition operation query to the Registry, and receive a Record for the Block (along with associated credentials) from the Registry response. In this distributed architecture, the CSP simply creates a new administrative TeRI Record for the block and signs it with its own credential. It then propagates that Record through the gossip network. If no node in the network votes against the Record, it is cached by all nodes, and that Record becomes a new administrative Record for that block. Note that per the MODERN framework [I-D.ietf-modern-problem-framework], a CSP can act directly as a Registrar itself, or it can use a third-party Registrar to effect these transactions. 3.3. CSP Acquires a Single Number In the following case, a CSP acquires a single available number in a block. Imagine, for example, that a new freephone area code 8yy were allocated in the North American Numbering Plan that allowed any Responsible Organization to acquire numbers on a first-come-first- serve basis under some governing policy. First, assume that there are numbers under 8yy available for assignment. Then, a CSP acting as a RespOrg participating in the distributed Registry declares its intention to allocate and assign a number to a customer. In this distributed architecture, the CSP simply creates a Peterson & Wendt Expires September 6, 2018 [Page 4] Internet-Draft DRiP TeRI March 2018 new administrative TeRI Record for the individual TN and signs it with its own credential, marking it as assigned. It then propagates that Record through the gossip network. If no node in the network votes against the Record, it is cached by all nodes, and that Record becomes a new administrative Record for that block. 3.4. CSP Assigns a Single Number within its Block In the following case, a CSP had already allocated a block to itself per Section 3.2. Now, it intends to assign a single number in that block. In centralized MODERN architectures, the CSP would contact the Registry with a TeRI management operation, notifying the Registry that the number's status had changed to assigned. In this distributed Registry, the CSP creates a new TeRI record for that individual number, marking it as assigned, signs it, and then propagates that Record through the gossip network. The same would apply for marking a sub-block within the block as assigned: the CSP creates a new TeRI record for that individual sub- block, marking it as assigned, signs it, and then propagates that Record through the gossip network. 3.5. Number Porting The most difficult use cases for the distributed Registry are ones where control of resources has been allocated or assigned to one CSP but must now move to a new CSP. Number portability is the most common cause of this, though various other business reasons might result in changes of control over allocated and/or assigned numbers. Suppose that CSP B has allocated and assigned a block to itself, and that TeRI records for that block are cached throughout the gossip network. Now, CSP A declares its intention to assign a particular TN within the block of CSP B. CSP A does so by creating a new TeRI Record for the number which CSP A signs, allocating the number to itself and marking it as assigned. As this Record propagates through the gossip network, CSP B recognizes this transaction and does not vote "no", in effect authorizing the transfer. If CSP B's customer were not porting the number to CSP A, then CSP B would vote "no." From a policy oversight perspective, this could require a "policy node" or similar actor in the network to make sure it is not abused. Peterson & Wendt Expires September 6, 2018 [Page 5] Internet-Draft DRiP TeRI March 2018 4. Identity Elements in TeRI [Future versions of this specification will explore extensions to baseline TeRI for DRiP use cases.] 5. Acknowledgments We would like to thank you for your contributions to this problem statement and framework. 6. IANA Considerations This document contains no instructions for the IANA. 7. Security Considerations TBD. 8. Informative References [I-D.ietf-acme-acme] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", draft-ietf-acme-acme-09 (work in progress), December 2017. [I-D.ietf-acme-service-provider] Barnes, M. and C. Wendt, "ACME Identifiers and Challenges for VoIP Service Providers", draft-ietf-acme-service- provider-02 (work in progress), October 2017. [I-D.ietf-acme-star] Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. Fossati, "Support for Short-Term, Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME)", draft-ietf-acme-star-03 (work in progress), March 2018. [I-D.ietf-acme-telephone] Peterson, J. and R. Barnes, "ACME Identifiers and Challenges for Telephone Numbers", draft-ietf-acme- telephone-01 (work in progress), October 2017. [I-D.ietf-modern-problem-framework] Peterson, J. and T. McGarry, "Modern Problem Statement, Use Cases, and Framework", draft-ietf-modern-problem- framework-03 (work in progress), July 2017. Peterson & Wendt Expires September 6, 2018 [Page 6] Internet-Draft DRiP TeRI March 2018 [I-D.ietf-stir-certificates] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", draft-ietf-stir- certificates-18 (work in progress), December 2017. [I-D.ietf-stir-passport] Wendt, C. and J. Peterson, "Personal Assertion Token (PASSporT)", draft-ietf-stir-passport-11 (work in progress), February 2017. [I-D.ietf-stir-rfc4474bis] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 (work in progress), February 2017. [I-D.peterson-modern-teri] Peterson, J., "An Architecture and Information Model for Telephone-Related Information (TeRI)", draft-peterson- modern-teri-03 (work in progress), July 2017. [I-D.rescorla-stir-fallback] Rescorla, E. and J. Peterson, "STIR Out of Band Architecture and Use Cases", draft-rescorla-stir- fallback-02 (work in progress), June 2017. [I-D.wendt-modern-drip] Wendt, C. and H. Bellur, "Distributed Registry Protocol (DRiP)", draft-wendt-modern-drip-02 (work in progress), July 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . Peterson & Wendt Expires September 6, 2018 [Page 7] Internet-Draft DRiP TeRI March 2018 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, . Authors' Addresses Jon Peterson Neustar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Email: jon.peterson@neustar.biz Chris Wendt Comcast One Comcast Center Philadelphia, PA 19103 USA Email: chris-ietf@chriswendt.net Peterson & Wendt Expires September 6, 2018 [Page 8]