idnits 2.17.1 draft-ietf-modern-problem-framework-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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: '1' is defined on line 958, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 981, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 985, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 991, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 996, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1000, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1004, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1008, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1050, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '1') (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 7482 (ref. '12') (Obsoleted by RFC 9082) == Outdated reference: A later version (-04) exists of draft-peterson-modern-teri-03 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft T. McGarry 4 Intended status: Informational NeuStar, Inc. 5 Expires: September 6, 2018 March 5, 2018 7 Modern Problem Statement, Use Cases, and Framework 8 draft-ietf-modern-problem-framework-04.txt 10 Abstract 12 The functions of the public switched telephone network (PSTN) are 13 rapidly migrating to the Internet. This is generating new 14 requirements for many traditional elements of the PSTN, including 15 telephone numbers (TNs). TNs no longer serve simply as telephone 16 routing addresses: they are now identifiers which may be used by 17 Internet-based services for a variety of purposes including session 18 establishment, identity verification, and service enablement. This 19 problem statement examines how the existing tools for allocating and 20 managing telephone numbers do not align with the use cases of the 21 Internet environment, and proposes a framework for Internet-based 22 services relying on TNs. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 6, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.3. Data Management Architectures . . . . . . . . . . . . . . 8 63 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1.1. Acquiring TNs from Registrar . . . . . . . . . . . . 12 67 4.1.2. Acquiring TNs from CSPs . . . . . . . . . . . . . . . 13 68 4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 14 69 4.2.1. Management of Administrative Data . . . . . . . . . . 14 70 4.2.1.1. Managing Data at a Registrar . . . . . . . . . . 14 71 4.2.1.2. Managing Data at a CSP . . . . . . . . . . . . . 15 72 4.2.2. Management of Service Data . . . . . . . . . . . . . 15 73 4.2.2.1. CSP to other CSPs . . . . . . . . . . . . . . . . 15 74 4.2.2.2. User to CSP . . . . . . . . . . . . . . . . . . . 16 75 4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 16 76 4.2.3.1. Changing the CSP for an Existing Service . . . . 16 77 4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 17 78 4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 17 79 4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 18 80 4.3.2. Retrieval of Semi-restricted Administrative Data . . 18 81 4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 18 82 4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 19 83 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 85 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 9. Informative References . . . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Problem Statement 92 The challenges of utilizing telephone numbers (TNs) on the Internet 93 have been known for some time. Internet telephony provided the first 94 use case for routing telephone numbers on the Internet in a manner 95 similar to how calls are routed in the public switched telephone 96 network (PSTN). As the Internet had no service for discovering the 97 endpoints associated with telephone numbers, ENUM [3] created a DNS- 98 based mechanism for resolving TNs in an IP environment, by defining 99 procedures for translating TNs into URIs for use by protocols such as 100 SIP [2]. The resulting database was designed to function in a manner 101 similar to the systems that route calls in the PSTN. Originally, it 102 was envisioned that ENUM would be deployed as a global hierarchical 103 service, though in practice, it has only been deployed piecemeal by 104 various parties. Most notably, ENUM is used as an internal network 105 function, and is rarely used between service provider networks. The 106 original ENUM concept of a single root, e164.arpa, proved to be 107 politically and practically challenging, and less centralized models 108 have thus flourished. Subsequently, the DRINKS [4] framework showed 109 ways that service providers might provision information about TNs at 110 an ENUM service or similar Internet-based directory. These 111 technologies have also generally tried to preserve the features and 112 architecture familiar to the PSTN numbering environment. 114 Over time, Internet telephony has encompassed functions that differ 115 substantially from traditional PSTN routing and management, 116 especially as non-traditional providers have begun to utilize 117 numbering resources. An increasing number of enterprises, over-the- 118 top voice-over-IP (VoIP) providers, text messaging services, and 119 related non-carrier services have become heavy users of telephone 120 numbers. An enterprise, for example, can deploy an IP PBX that 121 receives a block of telephone numbers from a carrier and then in turn 122 distribute those numbers to new IP telephones when they associate 123 with the PBX. Internet services offer users portals where they can 124 allocate new telephone numbers on the fly, assign multiple "alias" 125 telephone numbers to a single line service, implement various 126 mobility or find-me-follow-me applications, and so on. Peer-to-peer 127 telephone networks have encouraged experiments with distributed 128 databases for telephone number routing and even allocation. 130 This dynamic control over telephone numbers has few precedents in the 131 traditional PSTN outside of number portability. Number portability 132 allows the capability of a user to choose and change their service 133 provider while retaining their TN; it has been implemented in many 134 countries; either for all telephony services or for subsets such as 135 mobile. However, TN administration processes rooted in PSTN 136 technology and policies dictate that this be an exception process 137 fraught with problems and delays. Originally, processes were built 138 to associate a specific TN to a specific service provider and never 139 change it. With number portability, the industry had to build new 140 infrastructure, new administrative functions and processes to change 141 the association of the TN from one service provider to another. 142 Thanks to the increasing sophistication of consumer mobile devices as 143 Internet endpoints as well as telephones, users now associate TNs 144 with many Internet applications other than telephony. This has 145 generated new interest in models similar to those in place for 146 administering freephone (non-geographic toll free numbers) services 147 in the United States, where a user purchases a number through a sort 148 of number registrar and controls its administration (such as routing) 149 on their own, typically using Internet services to directly make 150 changes to the service associated with telephone numbers. 152 Most TNs today are assigned to specific geographies, at both an 153 international level and within national numbering plans. Numbering 154 practices today are tightly coupled with the manner that service 155 providers interconnect, as well as how TNs are routed and 156 administered: the PSTN was carefully designed to delegate switching 157 intelligence geographically. In interexchange carrier routing in 158 North America, for example, calls to a particular TN are often handed 159 off to the terminating service provider close to the geography where 160 that TN is assigned. But the overwhelming success of mobile 161 telephones has increasingly eroded the connection between numbers and 162 regions. Furthermore, the topology of IP networks is not anchored to 163 geography in the same way that the telephone network is. In an 164 Internet environment, establishing a network architecture for routing 165 TNs could depend little on geography, relying instead on network 166 topologies or other architectural features. Adapting TNs to the 167 Internet requires more security, richer datasets and more complex 168 query and response capabilities than previous efforts have provided. 170 This document attempts to create a common understanding of the 171 problem statement related to allocating, managing, and resolving TNs 172 in an IP environment, the focus of the IETF MODERN (Managing, 173 Ordering, Distributing, Exposing, and Registering telephone Numbers) 174 working group. It outlines a framework and lists motivating use 175 cases for creating IP-based mechanisms for TNs. It is important to 176 acknowledge at the outset that there are various evolving 177 international and national policies and processes related to TNs, and 178 any solutions need to be flexible enough to account for variations in 179 policy and requirements. 181 2. Definitions 183 This section provides definitions for actors, data types and data 184 management architectures as they are discussed in this document. 185 Different numbering spaces may instantiate these roles and concepts 186 differently: practices that apply to non-geographic freephone 187 numbers, for example, may not apply to geographic numbers, and 188 practices that exist under one Numbering Authority may not be 189 permitted under another. The purpose of this framework is to 190 identify the characteristics of protocol tools that will satisfy the 191 diverse requirements for telephone number acquisition, management, 192 and retrieval on the Internet. 194 2.1. Actors 196 The following roles of actors are defined in this document: 198 Numbering Authority: A regulatory body within a region that manages 199 that regions TNs. The Numbering Authority decides national 200 numbering policy for the nation, region, or other domain for which 201 it has authority, including what TNs can be allocated, which are 202 reserved, and which entities may obtain TNs. 204 Registry: An entity that administers the allocation of TNs based on 205 a Numbering Authority's policies. Numbering authorities can act 206 as the Registries themselves, or they can outsource the function 207 to other entities. Traditional registries are single entities 208 with sole authority and responsibility for specific numbering 209 resources, though distributed registries (see Section 2.3) are 210 also in the scope of this framework. 212 Credential Authority: An entity that distributes credentials, such 213 as certificates that attest the authority of assignees (defined 214 below) and delegates. This document assumes that one of more 215 credential authorities may be trusted by actors in any given 216 regulatory environment; policies for establishing such trust 217 anchors are outside the scope of this document. 219 Registrar: An entity that distributes the telephone numbers 220 administered by a Registry; typically, there are many Registrars 221 that can distribute numbers from a single Registry, though 222 Registrars may serve multiple Registries as well. A Registrar has 223 business relationships with number assignees and collects 224 administrative information from them. 226 Communication Service Provider (CSP): A provider of communications 227 services, where those services can be identified by TNs. This 228 includes both traditional telephone carriers or enterprises as 229 well as service providers with no presence on the PSTN who use 230 TNs. This framework does not assume that any single CSP provides 231 all the communications service related to a particular TN. 233 Service Enabler: An entity that works with CSPs to enable 234 communication service to a User; perhaps a vendor, a service 235 bureau, or third-party integrator. 237 User: An individual reachable through a communications service; 238 usually a customer of a communication service provider. 240 Government Entity: An entity that, due to legal powers deriving from 241 national policy, has privileged access to information about number 242 administration under certain conditions. 244 Note that an individual, organization, or other entity may act in one 245 or more of the roles above; for example, a company may be a CSP and 246 also a Registrar. Although Numbering Authorities are listed as 247 actors, they are unlikely to actually participate in the protocol 248 flows themselves, though in some situations a Numbering Authority and 249 Registry may be the same administrative entity. 251 All actors that are recipients of numbering resources, be they a CSP, 252 Service Enabler, or User, can also be said to have a relationship to 253 a Registry of either an assignee or delegate: 255 Assignee: An actor that is assigned a TN directly by a Registrar; an 256 assignee always has a direct relationship with a Registrar. 258 Delegate: An actor that is delegated a TN from an assignee or 259 another delegate, who does not necessarily have a direct 260 relationship with a Registrar. Delegates may delegate one or more 261 of their TN assignment(s) to one or more further downstream 262 subdelegates. 264 As an example, consider a case where a Numbering Authority also acts 265 as a Registry, and it issues blocks of 10,000 TNs to CSPs, which in 266 this case also act as Registrars. CSP/Registrars would then be 267 responsible for distributing numbering resources to Users and other 268 CSPs. In this case, an enterprise deploying IP PBXs also acts as a 269 CSP, and it acquires number blocks for its enterprise seats in chunks 270 of 100 from a CSP acting as a Registrar with whom the enterprise has 271 a business relationship. The enterprise is in this case the 272 assignee, as it receives numbering resources directly from a 273 Registrar. As it doles out individual numbers to its Users, the 274 enterprise delegates its own numbering resources to those Users and 275 their communications endpoints. The overall ecosystem might look as 276 follows. 278 +---------+ 279 |Numbering| 280 |Authority|Registry 281 +----+----+ 282 | 283 V 10,000 TNs 284 +---------+ 285 | CSP |Registrar 286 +----+----+ 287 | 288 V 100 TNs 289 +---------+ 290 | PBX |Assignee 291 +---------+ 292 | 293 V 1 TN 294 +---------+ 295 | User |Delegate 296 +---------+ 298 Figure 1: Chain of Number Assignment 300 2.2. Data Types 302 The following data types are defined in this document: 304 Administrative Data: assignment data related to the TN and the 305 relevant actors; it includes TN status (assigned, unassigned, 306 etc.), contact data for the assignee or delegate, and typically 307 does not require real-time access as this data is not required for 308 ordinary call or session establishment. 310 Service Data: data necessary to enable service for the TN; it 311 includes addressing data and service features. Since this data is 312 necessary to complete calls, it must be obtained in real time. 314 Administrative and service data can fit into three access categories: 316 Public: Anyone can access public data. Such data might include a 317 list of which numbering resources (unallocated number ranges) are 318 available for acquisition from the Registry. 320 Semi-restricted: Only a subset of actors can access semi-restricted 321 data. For example CSPs may be able to access other CSP's service 322 data in some closed environment. 324 Restricted: Only a small subset of actors can access restricted 325 data. For example a Government Entity may be able access contact 326 information for a User. 328 While it might appear there are really only two categories, public 329 and restricted based on requestor, the distinction between semi- 330 restricted and restricted is helpful for the use cases below. 332 2.3. Data Management Architectures 334 This framework generally assumes that administrative and service data 335 is maintained by CSPs, Registrars, and Registries. The terms 336 "registrar" and "registry" are familiar from DNS operations, and 337 indeed the DNS provides an obvious inspiration for the relationships 338 between those entities described here. Protocols for transferring 339 names between registries and registrars have been standardized in the 340 DNS space for some time (see [14]). Similarly, the division between 341 service data acquired by resolving names with the DNS protocol vs. 342 administrative data about names acquired through WHOIS [15] is 343 directly analogous to the distinction between service and 344 administrative data described in Section 2.2. The major difference 345 between the data management architecture of the DNS and this 346 framework is that the distinction between the CSP and User, due to 347 historical policies of the telephone network, will often not exactly 348 correspond to the distinction between a name service and a registrant 349 in the DNS world - a User in the telephone network is today at least 350 rarely in a direct relationship with a Registrar comparable to that 351 of a DNS registrant. 353 The role of a Registry described here is a "thin" one, where the 354 Registry manages basic allocation information for the numbering 355 space, such as information about whether or not the number is 356 assigned, and if assigned, by which Registrar. It is the Registrar 357 that in turn manages detailed administrative data about those 358 assignments, such as contact or billing information for the assignee. 359 In some models, CSPs and Registrars will be combined (the same 360 administrative entity), and in others the Registry and Registrar may 361 similarly be composed. Typically, service data resides largely at 362 the CSP itself, though in some models a "thicker" Registry may itself 363 contain a pointer to the servicing CSP for a number or number block. 364 In addition to traditional centralized Registries, this framework 365 also supports environments where the same data is being managed by 366 multiple administrative entities, and stored in many locations. A 367 distributed registry system is discussed further in [19]. To support 368 those use cases, it is important to distinguish the following: 370 Data store: A Data Store is a service that stores and enables access 371 to administrative and/or service data. 373 Reference Address: A Reference Address is a URL that dereferences to 374 the location of the data store. 376 Distributed data stores: In a Distributed Data Store, administrative 377 or service data can be stored with multiple actors. For example, 378 CSPs could provision their service data to multiple other CSPs. 380 Distributed Registries: Multiple Registries can manage the same 381 numbering resource. In these architectures, actors could interact 382 with one or multiple Registries. The Registries would update each 383 other when change occurs. The Registries have to ensure that data 384 remains consistent, e.g. that the same TN is not assigned to two 385 different actors. 387 3. Framework 389 The framework outlined in this document requires three Internet-based 390 mechanisms for managing and resolving telephone numbers (TNs) in an 391 IP environment. These mechanisms will likely reuse existing 392 protocols for sharing structured data; it is unlikely that new 393 protocol development work will be required, though new information 394 models specific to the data itself will be a major focus of framework 395 development. Likely candidates for reuse here include work done in 396 DRINKS [4] and WEIRDS [12], as well as the TeRI [16] framework. 398 These protocol mechanisms are scoped in a way that makes them likely 399 to apply to a broad range of future policies for number 400 administration. It is not the purpose of this framework to dictate 401 number policy, but instead to provide tools that will work with 402 policies as they evolve going forward. These mechanisms therefore do 403 not assume that number administration is centralized, nor that number 404 allocations are restricted to any category of service providers, 405 though these tools must and will work in environments with those 406 properties. 408 The three mechanisms are: 410 Acquisition: a protocol mechanism for acquiring TNs, including an 411 enrollment process. 413 Management: a protocol mechanism for associating data with TNs. 415 Retrieval: a protocol mechanism for retrieving data about TNs. 417 The acquisition mechanism will enable actors to acquire TNs for use 418 with a communications service by requesting numbering resources from 419 a service operated by a Registrar, CSP or similar actor. TNs may be 420 requested either on a number-by-number basis, or as inventory blocks. 422 Any actor who grants numbering resources will retain metadata about 423 the assignment, including the responsible organization or individual 424 to whom numbers have been assigned. 426 The management mechanism will let actors provision data associated 427 with TNs. For example, if a User has been assigned a TN, they may 428 select a CSP to provide a particular service associated with the TN, 429 or a CSP may assign a TN to a User upon service activation. In 430 either case, a mechanism is needed to provision data associated with 431 the TN at that CSP, and to extend those data sets as CSPs (and even 432 Users) require. 434 The retrieval mechanism will enable actors to learn information about 435 TNs. For real-time service data, this typically involves sending a 436 request to a CSP; for other information, an actor may need to send a 437 request to a Registry rather than a CSP. Different parties may be 438 authorized to receive different information about TNs. 440 As an example, a CSP might use the acquisition interface to acquire a 441 chunk of numbers from a Registrar. Users might then provision 442 administrative data associated with those numbers at the CSP through 443 the management interface, and query for service data relating to 444 those numbers through the retrieval interface of the CSP. 446 +--------+ 447 |Registry| 448 +---+----+ 449 | 450 V 451 +---------+ 452 |Registrar| 453 +---------+ 454 \ 455 \\ 456 Acquisition \\ 457 \\+-------+ 458 \ CSP | 459 +---+---+ 460 A A 461 | | 462 Management | | Retrieval 463 | | 464 | | 465 +-------++ ++-------+ 466 | User | | User | 467 +--------+ +--------+ 468 (delegate) (caller) 470 Figure 2: Example of the Three Interfaces 472 4. Use Cases 474 The high-level use cases in this section will provide an overview of 475 the expected operation of the three interfaces in the MODERN problem 476 space: 478 4.1. Acquisition 480 There are various scenarios for how TNs can be acquired by the 481 relevant actors, that is, a CSP, Service Enabler, and a User. There 482 are three actors from which numbers can be acquired: a Registrar, a 483 CSP and a User (presumably one who is delegating to another party). 484 It is assumed that Registrars are either the same entity as 485 Registries, or that Registrars have established business 486 relationships with Registries that enable them to distribute the 487 numbers that the Registries administer. In these use cases, a User 488 may acquire TNs either from a CSP or a Registry, or from an 489 intermediate delegate. 491 4.1.1. Acquiring TNs from Registrar 493 The most traditional number acquisition use case is one where a CSP, 494 such as a carrier, requests a block of numbers from a Registrar to 495 hold as inventory or assign to customers. 497 Through some out-of-band business process, a CSP develops a 498 relationship with a Registrar. The Registrar maintains a profile of 499 the CSP and assesses whether or not CSPs meet the policy restrictions 500 for acquiring TNs. The CSP may then request TNs from within a 501 specific pool of numbers in the authority of the Registry; such as 502 region, mobile, wireline, or freephone. The Registrar must 503 authenticate and authorize the CSP, and then either grant or deny a 504 request. When an assignment occurs, the Registry creates and stores 505 administrative information related to the assignment such as TN 506 status and Registrar contact information, and removes the specific 507 TN(s) from the pool of those that are available for assignment. As a 508 part of the acquisition and assignment process, the Registry provides 509 to the Registrar any tokens or other material needed by a Credential 510 Authority to issue credentials (for example, STIR certificates [17]) 511 used to attest the assignment for future transactions. Depending on 512 the policies of the Numbering Authorities, Registrars may be required 513 to log these operations. 515 Before it is eligible to receive TN assignments, per the policy of a 516 Numbering Authority, the CSP may need to have submitted (again, 517 through some out-of-band process) additional qualifying information 518 such as current utilization rate or a demand forecast. 520 There are two scenarios under which a CSP requests resources; they 521 are requesting inventory, or they are requesting for a specific User 522 or delegate. For the purpose of status information, TNs assigned to 523 a User are always considered assigned, not inventory. The CSP will 524 associate service information for that TN, e.g., service address, and 525 make it available to other CSPs to enable interconnection. The CSP 526 may need to update the Registrar regarding this service activation; 527 this is part of the "TN status" maintained by the Registrar. 529 There are also use cases in which a User can acquire a TN directly 530 from a Registrar. Today, a user wishing to acquire a freephone 531 number may browse the existing inventory through one or more 532 Registrars, comparing their prices and services. Each such Registrar 533 either is a CSP, or has a business relationship with one or more CSPs 534 to provide services for that freephone number. In this case, the 535 User must establish some business relationship directly with a 536 Registrar, similarly to how such functions are conducted today when 537 Users purchase domain names. In this use case, after receiving a 538 number assignment from the Registrar, a User will then obtain 539 communications service from a CSP, and provide to the CSP the TN to 540 be used for that service. The CSP will associate service information 541 for that TN, e.g., service address, and make it available to other 542 CSPs to enable interconnection. The user will also need to inform 543 the Registrar about this relationship. 545 4.1.2. Acquiring TNs from CSPs 547 Today, a User typically acquires a TN from CSP when signing up for 548 communications service or turning on a new device. In this use case, 549 the User becomes the delegate of the CSP. A reseller or a service 550 bureau might also acquire a block of numbers from a CSP to be issued 551 to Users. 553 Consider a case where a User creates or has a relationship with the 554 CSP, and subscribes to a communications service which includes the 555 use of a TN. The CSP collects and stores administrative data about 556 the User. The CSP then activates the User on their network and 557 creates any necessary service data to enable connectivity with other 558 CSPs. The CSP could also update public or privileged databases 559 accessible by other Actors. The CSP provides any tokens or other 560 material needed by a Credential Authority to issue credentials to the 561 User (for example, a STIR certificate [17]) to prove the assignment 562 for future transactions. Such credentials could be delegated from 563 the one provided by the Credential Authority to the CSP to continue 564 the chain of assignment. CSPs may be required to log such 565 transactions, if required by the policy of the Numbering Authority. 567 Virtually the same flow would work for a reseller: it would form a 568 business relationship with the CSP, at which point the CSP would 569 collect and store administrative data about the reseller and give the 570 reseller any material needed for the reseller to acquire credentials 571 for the numbers. A user might then in turn acquire numbers from the 572 reseller: in this case, the delegate re-delegating the TNs would be 573 performing functions done by the CSP, e.g., providing any 574 credentials, collecting administrative data, or creative service 575 data. 577 The CSP could assign a TN from its existing inventory or it could 578 acquire a new TN from the Registrar as part of the assignment 579 process. If it assigns it from its existing inventory, it would 580 remove the specific TN from the pool of those available for 581 assignment. It may also update the Registrar about the assignment so 582 the Registrar has current assignment data. If a reseller or delegate 583 CSP is acquiring the numbers, it may have the same obligations to 584 provide utilization data to the Registry as the assignee, per 585 Section 4.1.1. 587 4.2. Management 589 The management protocol mechanism is needed to associate 590 administrative and service data with TNs, and may be used to refresh 591 or rollover associated credentials. 593 4.2.1. Management of Administrative Data 595 Administrative data is primarily related to the status of the TN, its 596 administrative contacts, and the actors involved in providing service 597 to the TN. Protocol interactions for administrative data will 598 therefore predominantly occur between CSPs and Users to the 599 Registrar, or between Users and delegate CSPs to the CSP. 601 Some administrative data may be private, and would thus require 602 special handling in a distributed data store model. Access to it 603 does not require real-time performance therefore local caches are not 604 necessary. And it will include sensitive information such as user 605 and contact data. 607 Some of the data could lend itself to being publicly available, such 608 as CSP and TN assignment status. In that case it would be deemed 609 public information for the purposes of the retrieval interface. 611 4.2.1.1. Managing Data at a Registrar 613 After a CSP acquires a TN or block of TNs from the Registrar (per 614 Section 4.1.1 above), it then provides administrative data to the 615 Registrar as a step in the acquisition process. The Registrar will 616 authenticate the CSP and determine if the CSP is authorized to 617 provision the administrative data for the TNs in question. The 618 Registry will update the status of the TN, i.e., that it is 619 unavailable for assignment. The Registrar will also maintain 620 administrative data provided by the CSP. 622 Changes to this administrative data will not be frequent. Examples 623 of changes would be terminating service (see Section 4.2.3.2), 624 changing the name or address of a User or organization, or changing a 625 CSP or delegate. Changes should be authenticated by a credential to 626 prove administrative responsibility for the TN. 628 In some cases, such as the freephone system in North America today, 629 the User has a direct relationship with the Registrar. Naturally, 630 these users could provision administrative data associated with their 631 TNs directly to the Registrar, just as a freephone provider today 632 maintains account and billing data. While delegates may not 633 ordinarily have a direct relationship to a Registrar, some 634 environments as an optimization might want to support a model where 635 the delegate updates the Registrar directly on changes, as opposed to 636 sending that data to the CSP or through the CSP to the Registrar. As 637 stated already, the protocol should enable Users to acquire TNs 638 directly from a Registrar, which Registrar may or may not also act as 639 a CSP. In these cases the updates would be similar to that described 640 in Section 4.2.1.1. 642 In a distributed Registry model, TN status, e.g., allocated, 643 assigned, available, unavailable, would need to be provided to other 644 Registries in real-time. Other administrative data could be sent to 645 all Registries or other Registries could get a reference address to 646 the host Registry's data store. 648 4.2.1.2. Managing Data at a CSP 650 After a User acquires a TN or block of TNs from a CSP, the User will 651 provide administrative data to the CSP. The CSP commonly acts as a 652 Registrar in this case, maintaining the administrative data and only 653 notifies the Registry of the change in TN status. In this case, the 654 Registry maintains a reference address (see Section 2.3) to the CSP/ 655 Registrar's administrative data store so relevant actors have the 656 ability to access the data. Alternatively, a CSP could send the 657 administrative data to an external Registrar to store. If there is a 658 delegate between the CSP and user, they will have to ensure there is 659 a mechanism for the delegate to update the CSP as change occurs. 661 4.2.2. Management of Service Data 663 Service data is data required by an originating or intermediate CSP 664 to enable communications service to a User: a SIP URI is an example 665 of one service data element commonly used to route communications. 666 CSPs typically create and manage service data, however, it is 667 possible that delegates and Users could as well. For most use cases 668 involving individual Users, it is anticipated that lower-level 669 service information changes (such as an end-user device receiving a 670 new IP address) would be communicated to CSPs via existing protocols. 671 For example, the baseline SIP REGISTER [2] method, even for bulk 672 operations [13], would likely be used rather than through any new 673 interfaces defined by MODERN. 675 4.2.2.1. CSP to other CSPs 677 After a User enrolls for service with a CSP, in the case where the 678 CSP was assigned the TN by a Registrar, the CSP will then create a 679 service address such as a SIP URI and associate it with the TN. The 680 CSP needs to update this data to enable service interoperability. 681 There are multiple ways that this update can occur, though most 682 commonly service data is exposed through the retrieval interface (see 683 Section 4.3). For certain deployment architectures, like a 684 distributed data store model, CSPs may need to provision data 685 directly to other CSPs. 687 If the CSP is assigning a TN from its own inventory it may not need 688 to perform service data updates as change occurs because the existing 689 service data associated with inventory may be sufficient once the TN 690 is put in service. They would however likely update the Registry on 691 the change in status. 693 4.2.2.2. User to CSP 695 Users could also associate service data to their TNs at the CSP. An 696 example is a User acquires a TN from the Registrar (as described in 697 Section 4.1.1) and wants to provide that TN to the CSP so the CSP can 698 enable service. In this case, once the user provides the number to 699 the CSP, the CSP would update the Registry or other actors as 700 outlined in Section 4.2.2.1. 702 4.2.3. Managing Change 704 This section will address some special management use cases that were 705 not covered above. 707 4.2.3.1. Changing the CSP for an Existing Service 709 Consider the case where a User who subscribes to a communications 710 service, and received their TN from that CSP, wishes to retain the 711 same TN but move their service to a different CSP. 713 In the simplest scenario, where there's an authoritative combined 714 Registry/Registrar that maintains service data, the User could 715 provide their credential to the new CSP and let the CSP initiate the 716 change in service. The new CSP could then provide the new service 717 data with the User's credential to the Registry/Registrar, which then 718 makes the change. The old credential is revoked and a new one is 719 provided. The new CSP or the Registrar would send a notification to 720 the old CSP, so they can disable service. The old CSP will undo any 721 delegations to the User, including contacting the Credential 722 Authority to revoke any cryptographic credentials (e.g., STIR 723 certificates [17]) previously granted to the User. Any service data 724 maintained by the CSP must be removed, and similarly, the CSP must 725 delete any such information it provisioned in the Registry. 727 In a model similar to common practice in environments today, the User 728 could alternatively provide their credential to the old CSP, and the 729 old CSP initiates the change in service. Or, a User could go 730 directly to a Registrar to initiate a port. This framework should 731 support all of these potential flows. 733 Note that in cases with a distributed Registry that maintained 734 service data, the Registry would also have to update the other 735 Registries of the change. 737 4.2.3.2. Terminating a Service 739 Consider a case where a user who subscribes to a communications 740 service, and received their TN from the CSP, wishes to terminate 741 their service. At this time, the CSP will undo any delegations to 742 the User, which may involve contacting the Credential Authority to 743 revoke any cryptographic credentials (e.g., STIR certificates [17]) 744 previously granted to the User. Any service data maintained by the 745 CSP must be removed, and similarly, the CSP must delete any such 746 information it provisioned in the Registrar. However, per the policy 747 of the Numbering Authority, Registrars and CSPs may be required to 748 preserve historical data that will be accessible to Government 749 Entities or others through audits, even if it is no longer 750 retrievable through service interfaces. 752 The TN will change state from assigned to unassigned, the CSP will 753 update the Registry. Depending on policies the TN could go back into 754 the Registry, CSP, or delegate's pool of available TNs and would 755 likely enter an ageing process. 757 In an alternative use case, a User who received their own TN 758 assignment directly from a Registrar terminates their service with a 759 CSP. At this time, the User might terminate their assignment from 760 the Registrar, and return the TN to the Registry for re-assignment. 761 Alternatively, they could retain the TN and elect to assign it to 762 some other service at a later time. 764 4.3. Retrieval 766 Retrieval of administrative or service data will be subject to access 767 restrictions based on the category of the specific data: public, 768 semi-restricted or restricted. Both administrative and service data 769 can have data elements that fall into each of these categories. It 770 is expected that the majority of administrative will fall into the 771 semi-restricted category: access to this information may require some 772 form of authorization, though service data crucial to reachability 773 will need to be accessible. In some environments, it's possible that 774 none of the service data necessary to initiate communications will be 775 useful to an entity on the public Internet, say, or that all that 776 service data will have dependencies on the origination point of 777 calls. 779 The retrieval protocol mechanism for semi-restricted and restricted 780 data needs a way for the receiver of the request to identify the 781 originator of the request and what is being requested. The receiver 782 of the request will process that request based on this information. 784 4.3.1. Retrieval of Public Data 786 Either administrative or service data may be made publicly available 787 by the authority that generates and provisions it. Under most 788 circumstances, a CSP wants its communications service to be publicly 789 reachable through TNs, so the retrieval interface supports public 790 interfaces that permit clients to query for service data about a TN. 791 Some service data may however require that the client be authorized 792 to receive it, per the use case in Section 4.3.3 below. 794 Public data can simply be posted on websites or made available 795 through a publicly available API. Public data hosted by a CSP may 796 have a reference address at the Registry. 798 4.3.2. Retrieval of Semi-restricted Administrative Data 800 Consider a case in which a CSP is having service problems completing 801 calls to a specific TN, so it wants to contact the CSP serving that 802 TN. The Registry authorizes the originating CSP to access this 803 information. It initiates a query to the Registry, the Registry 804 verifies the requestor and the requested data and Registry responds 805 with the serving CSP and contact data. However, CSPs might not want 806 to make those administrative contact points public data: they are 807 willing to share them with other CSPs for troubleshooting purposes, 808 but not to make them available to general communication. 810 Alternatively that information could be part of a distributed data 811 store and not stored at a monolithic Registry. In that case, the CSP 812 has the data in a local distributed data store and it initiates the 813 query to the local data store. The local data store responds with 814 the CSP and contact data. No verification is necessary because it 815 was done when the CSP was authorized to receive the data store. 817 4.3.3. Retrieval of Semi-restricted Service Data 819 Consider a case where a User on a CSP's network calls a TN. The CSP 820 initiates a query for service data associated with the TN to complete 821 the call, and will receive special service data because the CSP 822 operates in a closed environment where different CSPs receive 823 different responses, and only participating CSPs can initiate 824 communications. This service data would be flagged as semi- 825 restricted. The query and response have real-time performance 826 requirements in that environment. 828 Semi-restricted service data also works in a distributed data store 829 model, where each CSP distributes its updated service data to all 830 other CSPs. The originating CSP has the service data in its local 831 data store and queries it. The local data store responds with the 832 service data. The service data in the response can be a reference 833 address to a data store maintained by the serving CSP, or it can be 834 the service address itself. In the case where the response gives a 835 reference address, a subsequent query would go to the serving CSP, 836 who would in turn authorize the requestor for the requested data and 837 respond appropriate. In the case where the original response 838 contains the service address, the requestor would use that service 839 address as the destination for the call. 841 In some environments, aspects of the service data may reside at the 842 Registry itself (for example, the assigned CSP for a TN), and thus 843 the query may be sent to the Registry. The Registry verifies the 844 requestor and the requested data and responds with the service data, 845 such as a SIP URI containing the domain of the assigned CSP. 847 4.3.4. Retrieval of Restricted Data 849 A Government Entity wishes to access information about a particular 850 User, who subscribes to a communications service. The entity that 851 operates the Registry on behalf of the Numbering Authority in this 852 case has some pre-defined relationship with the Government Entity. 853 When the CSP acquired TNs from the Numbering Authority, it was a 854 condition of that assignment that the CSP provide access for 855 Government Entities to telephone numbering data when certain 856 conditions apply. The required data may reside either in the CSP or 857 in the Registrar. 859 For a case where the CSP delegates a number to the User, the CSP 860 might provision the Registrar (or itself, if the CSP is composed with 861 a Registrar) with information relevant to the User. At such a time 862 as the Government Entity needs information about that User, the 863 Government Entity may contact the Registrar or CSP to acquire the 864 necessary data. The interfaces necessary for this will be the same 865 as those described in Section 4.3; the Government Entity will be 866 authenticated, and an authorization decision will be made by the 867 Registrar or CSP under the policy dictates established by the 868 Numbering Authority. 870 5. Acknowledgments 872 We would like to thank Henning Schulzrinne and Adam Roach for their 873 contributions to this problem statement and framework, and to thank 874 Pierce Gorman for detailed comments. 876 6. IANA Considerations 878 This memo includes no instructions for the IANA. 880 7. Privacy Considerations 882 This framework defines two categories of information about telephone 883 numbers: service data and administrative data. Service data 884 describes how telephone numbers map to particular services and 885 devices that provide real-time communication for users. As such, 886 service data could potentially leak resource locations and even 887 lower-layer network addresses associated with these services, and in 888 rare cases, with end-user devices. Administrative data more broadly 889 characterizes who the administrative entities are behind telephone 890 numbers, which will often identify CSPs, but in some layers of the 891 architecture could include personally identifying information (PII), 892 even WHOIS-style information, about the end users behind identifiers. 893 This could conceivably encompass the sorts of data that carriers and 894 similar CSPs today keep about their customers for billing purposes, 895 like real names and postal addresses. The exact nature of 896 administrative data is not defined by this framework, and it is 897 anticipated that the protocols that will perform this function will 898 be extensible for different use cases, so at this point, it is 899 difficult to characterize exactly how much PII might end up being 900 housed by these services. 902 As such, if an attacker were to compromise the registrar services in 903 this architecture which maintain administrative data, and in some 904 cases even service data, this could leak PII about end users. These 905 interfaces, and the systems that host them, are a potentially 906 attractive target for hackers and need to be hardened accordingly. 907 Protocols that are selected to fulfill these functions must provide 908 the security features described in [Sec Cons]. 910 Finally, this framework recognizes that in many jurisdictions, 911 certain government agencies have a legal right to access service and 912 administrative data maintained by CSPs. This access is typically 913 aimed at identifying the users behind communications identifiers in 914 order to enforce regulatory policy. Those legal entities already 915 have the power to access the existing data held by CSPs in many 916 jurisdictions, though potentially the administrative data associated 917 with this framework could be richer information. 919 8. Security Considerations 921 The acquisition, management, and retrieval of administrative and 922 service data associated with telephone numbers raises a number of 923 security issues. 925 Any mechanism that allows an individual or organization to acquire 926 telephone numbers will require a means of mutual authentication, of 927 integrity protection, and of confidentiality. A Registry as defined 928 in this document will surely want to authenticate the source of an 929 acquisition request as a first step in the authorization process to 930 determine whether or not the resource will be granted. Integrity of 931 both the request and response is essential to ensuring that tampering 932 does not allow attackers to block acquisitions, or worse, to 933 commandeer resources. Confidentiality is essential to preventing 934 eavesdroppers from learning about allocations, including the 935 personally identifying information associated with the administrative 936 or technical contracts for allocations. 938 A management interface for telephone numbers has similar 939 requirements. Without proper authentication and authorization 940 mechanisms in place, an attack could use the management interface to 941 disrupt service data or administrative data, which could deny service 942 to users, enable new impersonation attacks, prevent billing systems 943 from operating properly, and cause similar system failures. 945 Finally, a retrieval interfaces has its own needs for mutual 946 authentication, integrity protection, and for confidentiality. Any 947 CSP sending a request to retrieve service data associated with a 948 number will want to know that it is reaching the proper authority, 949 that the response from that authority has not been tampered with in 950 transit, and in most cases the CSP will not want to reveal to 951 eavesdroppers the number it is requesting or the response that it has 952 received. Similarly, any service answering such a query will want to 953 have a means of authenticating the source of the query, and of 954 protecting the integrity and confidentiality of its responses. 956 9. Informative References 958 [1] Peterson, J. and C. Jennings, "Enhancements for 959 Authenticated Identity Management in the Session 960 Initiation Protocol (SIP)", RFC 4474, 961 DOI 10.17487/RFC4474, August 2006, 962 . 964 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 965 A., Peterson, J., Sparks, R., Handley, M., and E. 966 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 967 DOI 10.17487/RFC3261, June 2002, 968 . 970 [3] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 971 Uniform Resource Identifiers (URI) Dynamic Delegation 972 Discovery System (DDDS) Application (ENUM)", RFC 6116, 973 DOI 10.17487/RFC6116, March 2011, 974 . 976 [4] Channabasappa, S., Ed., "Data for Reachability of Inter- 977 /Intra-NetworK SIP (DRINKS) Use Cases and Protocol 978 Requirements", RFC 6461, DOI 10.17487/RFC6461, January 979 2012, . 981 [5] Watson, M., "Short Term Requirements for Network Asserted 982 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 983 . 985 [6] Jennings, C., Peterson, J., and M. Watson, "Private 986 Extensions to the Session Initiation Protocol (SIP) for 987 Asserted Identity within Trusted Networks", RFC 3325, 988 DOI 10.17487/RFC3325, November 2002, 989 . 991 [7] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 992 of Named Entities (DANE) Transport Layer Security (TLS) 993 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 994 2012, . 996 [8] Elwell, J., "Connected Identity in the Session Initiation 997 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 998 2007, . 1000 [9] Schulzrinne, H., "The tel URI for Telephone Numbers", 1001 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1002 . 1004 [10] Rosenberg, J. and C. Jennings, "The Session Initiation 1005 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 1006 January 2008, . 1008 [11] Peterson, J., Jennings, C., and R. Sparks, "Change Process 1009 for the Session Initiation Protocol (SIP) and the Real- 1010 time Applications and Infrastructure Area", BCP 67, 1011 RFC 5727, DOI 10.17487/RFC5727, March 2010, 1012 . 1014 [12] Newton, A. and S. Hollenbeck, "Registration Data Access 1015 Protocol (RDAP) Query Format", RFC 7482, 1016 DOI 10.17487/RFC7482, March 2015, 1017 . 1019 [13] Roach, A., "Registration for Multiple Phone Numbers in the 1020 Session Initiation Protocol (SIP)", RFC 6140, 1021 DOI 10.17487/RFC6140, March 2011, 1022 . 1024 [14] Hollenbeck, S., "Generic Registry-Registrar Protocol 1025 Requirements", RFC 3375, DOI 10.17487/RFC3375, September 1026 2002, . 1028 [15] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 1029 DOI 10.17487/RFC3912, September 2004, 1030 . 1032 [16] Peterson, J., "An Architecture and Information Model for 1033 Telephone-Related Information (TeRI)", draft-peterson- 1034 modern-teri-03 (work in progress), July 2017. 1036 [17] Peterson, J. and S. Turner, "Secure Telephone Identity 1037 Credentials: Certificates", RFC 8226, 1038 DOI 10.17487/RFC8226, February 2018, 1039 . 1041 [18] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 1042 Huguenin, "Verification Involving PSTN Reachability: 1043 Requirements and Architecture Overview", draft-jennings- 1044 vipr-overview-06 (work in progress), December 2013. 1046 [19] Wendt, C. and H. Bellur, "Distributed Registry Protocol 1047 (DRiP)", draft-wendt-modern-drip-02 (work in progress), 1048 July 2017. 1050 [20] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1051 Protocol (SIP): Locating SIP Servers", RFC 3263, 1052 DOI 10.17487/RFC3263, June 2002, 1053 . 1055 Authors' Addresses 1057 Jon Peterson 1058 Neustar, Inc. 1059 1800 Sutter St Suite 570 1060 Concord, CA 94520 1061 US 1063 Email: jon.peterson@neustar.biz 1064 Tom McGarry 1065 Neustar, Inc. 1066 1800 Sutter St Suite 570 1067 Concord, CA 94520 1068 US 1070 Email: tom.mcgarry@neustar.biz