idnits 2.17.1 draft-peterson-modern-drip-teri-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-acme-acme' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-acme-service-provider' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-acme-star' is defined on line 269, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-acme-telephone' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-stir-certificates' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-stir-passport' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-stir-rfc4474bis' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'I-D.rescorla-stir-fallback' is defined on line 307, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 322, but no explicit reference was found in the text == Unused Reference: 'RFC7515' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC7519' is defined on line 331, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-09 == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-03 == Outdated reference: A later version (-04) exists of draft-ietf-modern-problem-framework-03 == Outdated reference: A later version (-04) exists of draft-peterson-modern-teri-03 Summary: 0 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar 4 Intended status: Informational C. Wendt 5 Expires: September 6, 2018 Comcast 6 March 5, 2018 8 Using Telephone Related Information (TeRI) with the Distributed Registry 9 Protocol (DRiP) 10 draft-peterson-modern-drip-teri-00.txt 12 Abstract 14 The Distributed Registry Protocol (DRiP) allows a set of nodes to 15 implement a decentralized registry function. This document explores 16 how Telephone Related Information (TeRI) Records can be shared by 17 DRiP, and a decentralized registry approaches the operations 18 necessary to assign, provision, and route for telephone numbers. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 6, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. CSP Acquires a Block . . . . . . . . . . . . . . . . . . 4 59 3.3. CSP Acquires a Single Number . . . . . . . . . . . . . . 4 60 3.4. CSP Assigns a Single Number within its Block . . . . . . 5 61 3.5. Number Porting . . . . . . . . . . . . . . . . . . . . . 5 62 4. Identity Elements in TeRI . . . . . . . . . . . . . . . . . . 6 63 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 8. Informative References . . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 The Distributed Registry Protocol (DRiP) [I-D.wendt-modern-drip] is a 72 protocol that enables a distributed set of nodes to synchronize 73 information in real-time with a minimal amount of delay. DRiP 74 assumes a peer-to-peer gossip network that shares key-value pairs. 75 The protocol is intended to carry information related to personal 76 communication, including identifiers like telephone numbers and 77 related identity information about the participants in communication. 79 The Telephone Related Information [I-D.peterson-modern-teri] 80 information model provides a framework for distributing Records that 81 convey service or administrative data about telephone numbers. TeRI 82 Records are signed by entities such as CSPs or Registrars who possess 83 credentials which enable relying parties to trust that Records have 84 been created or modified by the appropriate parties for a particular 85 telephone number, such as STIR [RFC8226] certificates. In TeRI 86 parlance, anyone holding such a credential attesting authority over 87 telephone number resources is called an "Authority." TeRI Records 88 containing service data provide routing information for telephone 89 numbers, and may be retrieved from local caches, remote services, or 90 even a distributed network, as relying parties trust Authorities 91 rather than services. The TeRI Record format therefore seems 92 suitable for distribution via DRiP. 94 Following the MODERN framework [I-D.ietf-modern-problem-framework], 95 TeRI usages for centralized registries support three fundamental 96 operations on telephone numbers: acquisition, management, and 97 retrieval. There are at a high level a couple of potential ways to 98 approach using TeRI with DRiP: for example, the gossip protocol could 99 be used as a transport layer to pass client-server requests to what 100 is effectively a centralized Authority that actually creates and 101 signs TeRI Records; or, more interestingly, nodes in the gossip 102 network might all act as Authorities, possessing credentials that 103 enable them to create and sign TeRI Records themselves and then vote 104 on their validity to prevent conflicts and race conditions. The 105 possibility of a decentralized registry based on the latter principle 106 largely motivates this exploration of the intersection between TeRI 107 and DRiP. 109 This initial draft explores some key use cases for TeRI over DRiP, 110 and how they differ from the use cases already given in the baseline 111 MODERN framework [I-D.ietf-modern-problem-framework]. 113 2. Terminology 115 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 116 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 117 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 118 described in [RFC2119]. 120 3. Use Cases 122 3.1. Assumptions 124 It is assumed in the MODERN system that before any actor can interact 125 with a Registry, a Credential Authority provides certificate 126 credentials to individual actors corresponding to their identity and 127 role: such as the CSPs and Users of the MODERN framework 128 [I-D.ietf-modern-problem-framework]. For the purposes of this 129 document, we assume those credentials are STIR [RFC8226] certificates 130 associated with telephone number blocks that can be managed by the 131 distributed Registry. 133 These use cases explore the possibility that there could be more than 134 one distinct administrative entity who holds credentials authorizing 135 them to generate TeRI Records for the same numbering resources: 136 effectively, that set of Authorities functions as a distributed 137 Registry. Imagine, for example, that in the North American Numbering 138 Plan an experimental area code were created that enabled any CSP 139 authorized by the distributed Registry to reserve a new telephone 140 number on a first come first serve basis - with some policy controls. 142 For these use cases we assume that a policy governs the acquisition 143 of telephone numbers in the distributed Registry. For example, there 144 could be a financial cost of acquiring numbers that goes up 145 dramatically if CSPs acquire resources too greedily; or 146 alternatively, there could be some policy enforcement of the ratio of 147 allocated to assigned numbers a CSP has claimed to maintain an agreed 148 reasonable level of number inventory per CSP. In the DRiP gossip 149 network, there could moreover be a "policy node" that simply votes 150 "no" when new TeRI Records that conflict with the policy are 151 propagated. These initial use cases are however "sunny day" cases 152 where we assume that CSPs scrupulously adhere to policy. 154 3.2. CSP Acquires a Block 156 In the following case, a CSP performs acquires a block of telephone 157 numbers, placing it under their control using their credentials. 159 First, assume that a Numbering Authority has unallocated number 160 blocks that are eligible for allocation, and that these resources 161 have been made available to the distributed Registry. 163 Then, a CSP participating in the distributed Registry declares its 164 intention to allocate one such block of Numbers. In centralized 165 MODERN architectures, the CSP would send a TeRI acquisition operation 166 query to the Registry, and receive a Record for the Block (along with 167 associated credentials) from the Registry response. In this 168 distributed architecture, the CSP simply creates a new administrative 169 TeRI Record for the block and signs it with its own credential. It 170 then propagates that Record through the gossip network. If no node 171 in the network votes against the Record, it is cached by all nodes, 172 and that Record becomes a new administrative Record for that block. 174 Note that per the MODERN framework 175 [I-D.ietf-modern-problem-framework], a CSP can act directly as a 176 Registrar itself, or it can use a third-party Registrar to effect 177 these transactions. 179 3.3. CSP Acquires a Single Number 181 In the following case, a CSP acquires a single available number in a 182 block. Imagine, for example, that a new freephone area code 8yy were 183 allocated in the North American Numbering Plan that allowed any 184 Responsible Organization to acquire numbers on a first-come-first- 185 serve basis under some governing policy. 187 First, assume that there are numbers under 8yy available for 188 assignment. 190 Then, a CSP acting as a RespOrg participating in the distributed 191 Registry declares its intention to allocate and assign a number to a 192 customer. In this distributed architecture, the CSP simply creates a 193 new administrative TeRI Record for the individual TN and signs it 194 with its own credential, marking it as assigned. It then propagates 195 that Record through the gossip network. If no node in the network 196 votes against the Record, it is cached by all nodes, and that Record 197 becomes a new administrative Record for that block. 199 3.4. CSP Assigns a Single Number within its Block 201 In the following case, a CSP had already allocated a block to itself 202 per Section 3.2. Now, it intends to assign a single number in that 203 block. 205 In centralized MODERN architectures, the CSP would contact the 206 Registry with a TeRI management operation, notifying the Registry 207 that the number's status had changed to assigned. In this 208 distributed Registry, the CSP creates a new TeRI record for that 209 individual number, marking it as assigned, signs it, and then 210 propagates that Record through the gossip network. 212 The same would apply for marking a sub-block within the block as 213 assigned: the CSP creates a new TeRI record for that individual sub- 214 block, marking it as assigned, signs it, and then propagates that 215 Record through the gossip network. 217 3.5. Number Porting 219 The most difficult use cases for the distributed Registry are ones 220 where control of resources has been allocated or assigned to one CSP 221 but must now move to a new CSP. Number portability is the most 222 common cause of this, though various other business reasons might 223 result in changes of control over allocated and/or assigned numbers. 225 Suppose that CSP B has allocated and assigned a block to itself, and 226 that TeRI records for that block are cached throughout the gossip 227 network. Now, CSP A declares its intention to assign a particular TN 228 within the block of CSP B. CSP A does so by creating a new TeRI 229 Record for the number which CSP A signs, allocating the number to 230 itself and marking it as assigned. As this Record propagates through 231 the gossip network, CSP B recognizes this transaction and does not 232 vote "no", in effect authorizing the transfer. If CSP B's customer 233 were not porting the number to CSP A, then CSP B would vote "no." 235 From a policy oversight perspective, this could require a "policy 236 node" or similar actor in the network to make sure it is not abused. 238 4. Identity Elements in TeRI 240 [Future versions of this specification will explore extensions to 241 baseline TeRI for DRiP use cases.] 243 5. Acknowledgments 245 We would like to thank you for your contributions to this problem 246 statement and framework. 248 6. IANA Considerations 250 This document contains no instructions for the IANA. 252 7. Security Considerations 254 TBD. 256 8. Informative References 258 [I-D.ietf-acme-acme] 259 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 260 Kasten, "Automatic Certificate Management Environment 261 (ACME)", draft-ietf-acme-acme-09 (work in progress), 262 December 2017. 264 [I-D.ietf-acme-service-provider] 265 Barnes, M. and C. Wendt, "ACME Identifiers and Challenges 266 for VoIP Service Providers", draft-ietf-acme-service- 267 provider-02 (work in progress), October 2017. 269 [I-D.ietf-acme-star] 270 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 271 Fossati, "Support for Short-Term, Automatically-Renewed 272 (STAR) Certificates in Automated Certificate Management 273 Environment (ACME)", draft-ietf-acme-star-03 (work in 274 progress), March 2018. 276 [I-D.ietf-acme-telephone] 277 Peterson, J. and R. Barnes, "ACME Identifiers and 278 Challenges for Telephone Numbers", draft-ietf-acme- 279 telephone-01 (work in progress), October 2017. 281 [I-D.ietf-modern-problem-framework] 282 Peterson, J. and T. McGarry, "Modern Problem Statement, 283 Use Cases, and Framework", draft-ietf-modern-problem- 284 framework-03 (work in progress), July 2017. 286 [I-D.ietf-stir-certificates] 287 Peterson, J. and S. Turner, "Secure Telephone Identity 288 Credentials: Certificates", draft-ietf-stir- 289 certificates-18 (work in progress), December 2017. 291 [I-D.ietf-stir-passport] 292 Wendt, C. and J. Peterson, "Personal Assertion Token 293 (PASSporT)", draft-ietf-stir-passport-11 (work in 294 progress), February 2017. 296 [I-D.ietf-stir-rfc4474bis] 297 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 298 "Authenticated Identity Management in the Session 299 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 300 (work in progress), February 2017. 302 [I-D.peterson-modern-teri] 303 Peterson, J., "An Architecture and Information Model for 304 Telephone-Related Information (TeRI)", draft-peterson- 305 modern-teri-03 (work in progress), July 2017. 307 [I-D.rescorla-stir-fallback] 308 Rescorla, E. and J. Peterson, "STIR Out of Band 309 Architecture and Use Cases", draft-rescorla-stir- 310 fallback-02 (work in progress), June 2017. 312 [I-D.wendt-modern-drip] 313 Wendt, C. and H. Bellur, "Distributed Registry Protocol 314 (DRiP)", draft-wendt-modern-drip-02 (work in progress), 315 July 2017. 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, 319 DOI 10.17487/RFC2119, March 1997, 320 . 322 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 323 Telephone Identity Problem Statement and Requirements", 324 RFC 7340, DOI 10.17487/RFC7340, September 2014, 325 . 327 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 328 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 329 2015, . 331 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 332 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 333 . 335 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 336 Credentials: Certificates", RFC 8226, 337 DOI 10.17487/RFC8226, February 2018, 338 . 340 Authors' Addresses 342 Jon Peterson 343 Neustar, Inc. 344 1800 Sutter St Suite 570 345 Concord, CA 94520 346 US 348 Email: jon.peterson@neustar.biz 350 Chris Wendt 351 Comcast 352 One Comcast Center 353 Philadelphia, PA 19103 354 USA 356 Email: chris-ietf@chriswendt.net