idnits 2.17.1 draft-ietf-modern-problem-framework-01.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 (July 7, 2016) is 2821 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 896, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 919, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 923, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 929, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 934, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 938, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 942, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 946, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 965, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 974, 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-00 == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-06 == Outdated reference: A later version (-02) exists of draft-wendt-modern-drip-00 Summary: 1 error (**), 0 flaws (~~), 14 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: January 8, 2017 July 7, 2016 7 Modern Problem Statement, Use Cases, and Framework 8 draft-ietf-modern-problem-framework-01.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 http://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 January 8, 2017. 41 Copyright Notice 43 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1.1. CSP Acquires TNs from Registrar . . . . . . . . . . . 11 67 4.1.2. User Acquires TNs from CSP . . . . . . . . . . . . . 12 68 4.1.3. CSP Delegates TNs to Another CSP . . . . . . . . . . 12 69 4.1.4. User Acquires TNs from a Delegate . . . . . . . . . . 13 70 4.1.5. User Acquires Numbers from Registrar . . . . . . . . 13 71 4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.2.1. Management of Administrative Data . . . . . . . . . . 13 73 4.2.1.1. CSP to Registrar . . . . . . . . . . . . . . . . 14 74 4.2.1.2. User to CSP . . . . . . . . . . . . . . . . . . . 14 75 4.2.1.3. User to Registrar . . . . . . . . . . . . . . . . 15 76 4.2.2. Management of Service Data . . . . . . . . . . . . . 15 77 4.2.2.1. CSP to other CSPs . . . . . . . . . . . . . . . . 15 78 4.2.2.2. User to CSP . . . . . . . . . . . . . . . . . . . 16 79 4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 16 80 4.2.3.1. Changing the CSP for an Existing Communications 81 Service . . . . . . . . . . . . . . . . . . . . . 16 82 4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 16 83 4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 17 84 4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 17 85 4.3.2. Retrieval of Semi-restricted Administrative Data . . 18 86 4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 18 87 4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 18 88 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 8. Informative References . . . . . . . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 94 1. Problem Statement 96 The challenges of utilizing telephone numbers (TNs) on the Internet 97 have been known for some time. Internet telephony provided the first 98 use case for routing telephone numbers on the Internet in a manner 99 similar to how calls are routed in the public switched telephone 100 network (PSTN). As the Internet had no service for discovering the 101 endpoints associated with telephone numbers, ENUM [3] created a DNS- 102 based mechanism for resolving TNs in an IP environment, by defining 103 procedures for translating TNs into URIs for use by protocols such as 104 SIP [2]. The resulting database was designed to function in a manner 105 similar to the systems that route calls in the PSTN. Originally, it 106 was envisioned that ENUM would be deployed as a global hierarchical 107 service, though in practice, it has only been deployed piecemeal by 108 various parties. Most notably, ENUM is used as an internal network 109 function, and is hardly used between service provider networks. The 110 original ENUM concept of a single root, e164.arpa, proved to be 111 politically and practically challenging, and less centralized models 112 have thus flourished. Subsequently, the DRINKS [4] framework showed 113 ways that authorities might provision information about TNs at an 114 ENUM service or similar Internet-based directory. These technologies 115 have also generally tried to preserve the features and architecture 116 familiar to the PSTN numbering environment. 118 Over time, Internet telephony has encompassed functions that differ 119 substantially from traditional PSTN routing and management, 120 especially as non-traditional providers have begun to utilize 121 numbering resources. An increasing number of enterprises, over-the- 122 top Voice over IP providers, text messaging services, and related 123 non-carrier services have become heavy users of telephone numbers. 124 An enterprise, for example, could deploy an IP PBX that receives a 125 block of telephone numbers from a carrier and then in turn distribute 126 those numbers to new IP telephones when they associate with the PBX. 127 Internet services offer users portals where they can allocate new 128 telephone numbers on the fly, assign multiple "alias" telephone 129 numbers to a single line service, implement various mobility or find- 130 me-follow-me applications, and so on. Peer-to-peer telephone 131 networks have encouraged experiments with distributed databases for 132 telephone number routing and even allocation. 134 This dynamic control over telephone numbers has few precedents in the 135 traditional PSTN outside of number portability. Number portability 136 has been implemented in many countries, and the capability of a user 137 to choose and change their service provider while retaining their TN 138 is widely implemented now. However, TN administration processes 139 rooted in PSTN technology and policies dictate that this be an 140 exception process fraught with problems and delays. Originally, 141 processes were built to associate a specific TN to a specific service 142 provider and never change it. With number portability, the industry 143 had to build new infrastructure, new administrative functions and 144 processes to change the association of the TN from one service 145 provider to another. Thanks to the increasing sophistication of 146 consumer mobile devices as Internet endpoints as well as telephones, 147 users now associate TNs with many Internet applications other than 148 telephony. This has generated new interest in models similar to 149 those in place for administering freephone services in the United 150 States, where a user purchases a number through a sort of number 151 registrar and controls its administration (such as routing) on their 152 own, typically using Internet services to directly make changes to 153 the service associated with telephone numbers. 155 Most TNs today are assigned to specific geographies, at both an 156 international level and within national numbering plans. Numbering 157 practices today are tightly coupled with the manner that service 158 providers interconnect, as well as how TNs are routed and 159 administered: the PSTN was carefully designed to delegate switching 160 intelligence geographically. In interexchange carrier routing in 161 North America, for example, calls to a particular TN are often handed 162 off to the terminating service provider close to the geography where 163 that TN is assigned. But the overwhelming success of mobile 164 telephones has increasing eroded the connection between numbers and 165 regions. Furthermore, the topology of IP networks is not anchored to 166 geography in the same way that the telephone network is. In an 167 Internet environment, establishing a network architecture for routing 168 TNs could depend little on geography. Adapting TNs to the Internet 169 requires more security, richer datasets and more complex query and 170 response capabilities than previous efforts have provided. 172 This document will create a common understanding of the problem 173 statement related to allocating, managing, and resolving TNs in an IP 174 environment. It outlines a framework and lists motivating use cases 175 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 country that manages 199 that country's 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, and which 202 are reserved. 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. There are two subtypes of Registries: an 208 Authoritative Registry and a Distributed Registry. The general 209 term Registry in this document refers to both kinds of Registries. 211 Authoritative Registry: An authoritative Registry is a single entity 212 with sole responsibility for specific numbering resources. 214 Distributed Registry: Distributed Registries are multiple Registries 215 responsible for the same numbering resources. 217 Registrar: An entity that distributes the telephone numbers 218 administered by a Registry; typically, there are many Registrars 219 that can distribute numbers from a single Registry, through 220 Registrars may serve multiple Registries as well. A Registrar has 221 business relationships with its assignees and collects 222 administrative information from them. 224 Communication Service Provider (CSP): A provider of communications 225 services, where those services can be identified by TNs. This 226 includes both traditional telephone carriers or enterprises as 227 well as service providers with no presence on the PSTN who use 228 TNs. This framework does not assume that any single CSP provides 229 all the communications service related to a particular TN. 231 Service Enabler: An entity that works with CSPs to enable 232 communication service to a User; perhaps a vendor, or third-party 233 integrator. 235 User: An individual reachable through a communications service; 236 usually a customer of a communication service provider. 238 Government Entity: An entity that, due to legal powers deriving from 239 national policy, has privileged access to information about number 240 administration under certain conditions. 242 Note that an individual, company or other entity may act in one or 243 more of the roles above; for example, a company may be a CSP and also 244 a Registrar. Although Numbering Authorities are listed as actors, 245 they are unlikely to actually participate in the protocol flows 246 themselves, though in some situations a Numbering Authority and 247 Registry may be the same administrative entity. 249 All actors that are recipients of numbering resources, be they a CSP, 250 Service Enabler, or User, can also be said to have a relationship to 251 a Registry of either an assignee or delegate: 253 Assignee: An actor that is assigned a TN directly by a Registrar; an 254 assignee always has a direct relationship with a Registrar. 256 Delegate: An actor that is delegated a TN from an assignee or 257 another delegate, who does not necessarily have a direct 258 relationship with a Registrar. Delegates may delegate one or more 259 of their TN assignment(s) to one or more further downstream 260 subdelegates. 262 As an example, consider a case where a Numbering Authority also acts 263 as a Registry, and it issues 10,000 blocks of TNs to CSPs, which in 264 this case also act as Registrars. CSP/Registrars would then be 265 responsible for distributing numbering resources to Users and other 266 CSPs. In this case, an enterprise deploying IP PBXs also acts as a 267 CSP, and it acquires number blocks for its enterprise seats in chunks 268 of 100 from a CSP acting as a Registrar with whom the enterprise has 269 a business relationship. The enterprise is in this case the 270 assignee, as it receives numbering resources directly from a 271 Registrar. As it doles out individual numbers to its Users, the 272 enterprise delegates its own numbering resources to those Users and 273 their communications endpoints. The overall ecosystem might look as 274 follows. 276 +---------+ 277 |Numbering| 278 |Authority|Registry 279 +----+----+ 280 | 281 V 10,000 TNs 282 +---------+ 283 | CSP |Registrar 284 +----+----+ 285 | 286 V 100 TNs 287 +---------+ 288 | PBX |Assignee 289 +---------+ 290 | 291 V 1 TN 292 +---------+ 293 | User |Delegate 294 +---------+ 296 Figure 1: Chain of Number Assignment 298 2.2. Data Types 300 The following data types are defined in this document: 302 Administrative Data: assignment data related to the TN and the 303 relevant actors; it includes TN status (assigned, unassigned, 304 etc.), contact data for the assignee or delegate, and typically 305 does not require real-time performance as access to this data is 306 not required for ordinary call or session establishment. 308 Service Data: data necessary to enable service for the TN; it 309 includes addressing data, service features, and so on, and 310 typically does require real-time performance, in so far as this 311 data typically must be queried during call set-up. 313 Administrative and service data can fit into three categories: 315 Public: data that anyone can access, for example a list of which 316 numbering resources (unallocated number ranges) are available for 317 acquisition from the Registry. 319 Semi-restricted: data that a subset of actors can access, for 320 example CSPs may be able to access other CSP's service data. 322 Restricted: data that is only available to a small subset of actors, 323 for example a Government Entity may be able access contact 324 information for a User. 326 While it might appear there are really only two categories, public 327 and restricted based on requestor, the distinction between semi- 328 restricted and restricted is helpful for the use cases below. 330 2.3. Data Management Architectures 332 This framework generally assumes that administrative and service data 333 is maintained by CSPs, Registrars, and Registries. The role of a 334 Registry described here is a "thin" one, where the Registry manages 335 basic allocation information for the numbering space, such as 336 information about whether or not the number is assigned, and if 337 assigned, by which Registrar. It is the Registrar that in turn 338 manages detailed administrative data about those assignments, such as 339 contact or billing information for the assignee. In some models, 340 CSPs and Registrars will be composed (the same administrative 341 entity), and in others the Registry and Registrar may similarly be 342 composed. Typically, service data resides largely at the CSP itself, 343 though in some models a "thicker" Registry may itself contain a 344 pointer to the servicing CSP for a number or number block. In 345 addition to traditional centralized Registries, this framework also 346 supports environments where the same data is being managed by 347 multiple administrative entities, and stored in many locations. A 348 distribute registry system is discussed further in [16]. 350 Data store: a service that stores and enables access to 351 administrative and/or service data. 353 Reference Address: a URL that dereferences to the location of the 354 data store. 356 Distributed data stores: refers to administrative or service data 357 being stored with multiple actors. For example, CSPs could 358 provision their service data to multiple other CSPs. 360 Distributed Registries: refers to multiple Registries managing the 361 same numbering resource. Actors could interact with one or 362 multiple Registries. The Registries would update each other when 363 change occurs. The challenge is to ensure there are no clashes, 364 e.g., two Registries assigning the same TN to two different 365 actors. 367 3. Framework 369 The framework outlined in this document requires three Internet-based 370 mechanisms for managing and resolving telephone numbers (TNs) in an 371 IP environment. These mechanisms will likely reuse existing 372 protocols for sharing structured data; it is unlikely that new 373 protocol development work will be required, though new information 374 models specific to the data itself will be a major focus of framework 375 development. Likely candidates for reuse here include work done in 376 DRINKS [4] and WEIRDS [12], as well as the TeRI [13] framework. 378 These protocol mechanisms are scoped in a way that makes them likely 379 to apply to a broad range of future policies for number 380 administration. It is not the purpose of this framework to dictate 381 number policy, but instead to provide tools that will work with 382 policies as they evolve going forward. These mechanisms therefore do 383 not assume that number administration is centralized, nor that number 384 allocations are restricted to any category of service providers, 385 though these tools must and will work in environments with those 386 properties. 388 The three mechanisms are: 390 Acquisition: a protocol mechanism for acquiring TNs, including an 391 enrollment process. 393 Management: a protocol mechanism for associating data with TNs. 395 Retrieval: a protocol mechanism for retrieving data about TNs. 397 The acquisition mechanism will enable actors to acquire TNs for use 398 with a communications service. The acquisition mechanism will 399 provide a means to request numbering resources from a service 400 operated by a Registrar, CSP or similar actor. TNs may be requested 401 either on a number-by-number basis, or as inventory blocks. Any 402 actor who grants numbering resources will retain metadata about the 403 assignment, including the responsible organization or individual to 404 whom numbers have been assigned. 406 The management mechanism will let actors provision data associated 407 with TNs. For example, if a User has been assigned a TN, they may 408 select a CSP to provide a particular service associated with the TN, 409 or a CSP may assign a TN to a User upon service activation. In 410 either case, a mechanism is needed to provision data associated with 411 the TN at that CSP. 413 The retrieval mechanism will enable actors to learn information about 414 TNs, typically by sending a request to a CSP. For some information, 415 an actor may need to send a request to a Registry rather than a CSP. 416 Different parties may be authorized to receive different information 417 about TNs. 419 As an example, a CSP might use the acquisition interface to acquire a 420 chunk of numbers from a Registrar. Users might then provision 421 administrative data associated with those numbers at the CSP through 422 the management interface, and query for service data relating to 423 those numbers through the retrieval interface of the CSP. 425 +--------+ 426 |Registry| 427 +---+----+ 428 | 429 V 430 +---------+ 431 |Registrar| 432 +---------+ 433 \ 434 \\ 435 Acquisition \\ 436 \\+-------+ 437 \ CSP | 438 +---+---+ 439 A A 440 | | 441 Management | | Retrieval 442 | | 443 | | 444 +-------++ ++-------+ 445 | User | | User | 446 +--------+ +--------+ 448 Figure 2: Example of the Three Interfaces 450 4. Use Cases 452 The high-level use cases in this section will provide an overview of 453 the expected operation of the three interfaces in the MODERN problem 454 space. 456 4.1. Acquisition 458 There are various scenarios for how TNs can be acquired by the 459 relevant actors: a CSP, Service Enabler, or User. There are three 460 actors from which numbers can be acquired: a Registrar, a CSP and a 461 User (presumably one who is delegating to another party). It is 462 assumed that Registrars are either composed with Registries, or that 463 Registrars have established business relationships with Registries 464 that enable them to distribute the numbers that the Registries here 465 administer. In these use cases, a User may acquire TNs either from a 466 CSP or a Registry, or from an intermediate delegate. 468 4.1.1. CSP Acquires TNs from Registrar 470 The most fundamental and traditional numbering use case is one where 471 a CSP, such as a carrier, requests a block of numbers from a 472 Registrar to hold as inventory or assign to customers. 474 Through some out-of-band business process, a CSP develops a 475 relationship with a Registrar. The Registrar maintains a profile of 476 the CSP and what qualifications they possess for requesting TNs. The 477 CSP may then request TNs from within a specific pool of numbers in 478 the authority of the Registry; such as region, mobile, wireline, 479 tollfree, etc. The Registrar must authenticate and authorize the 480 CSP, and then either grant or deny a request. When an assignment 481 occurs, the Registry creates and stores administrative information 482 related to the assignment such as TN status and Registrar contact 483 information, and removes the specific TN(s) from the pool of those 484 that are available for assignment. As a part of the acquisition and 485 assignment process, the Registry provides any necessary credentials 486 (for example, STIR certificates [14]) to the Registrar to be used to 487 prove the assignment for future transactions. 489 Before it is eligible to receive TN assignments, per the policy of a 490 national authority, the CSP may need to have submitted (again, 491 through some out-of-band process) additional qualifying information 492 such as current utilization rate or a demand forecast. 494 There are two scenarios under which a CSP requests resources; they 495 are requesting inventory, or they are requesting for a specific User 496 or delegate. TNs assigned to a User are always considered assigned, 497 not inventory. The CSP will associate service information for that 498 TN, e.g., service address, and make it available to other CSPs to 499 enable interoperability. The CSP may need to update the Registrar 500 regarding this service activation (this is part of the "TN status" 501 maintained by the Registrar). 503 4.1.2. User Acquires TNs from CSP 505 Today, a User typically acquires a TN from CSP when signing up for 506 communications service or turning on a new device. In this use case, 507 the User becomes the delegate of the CSP. 509 A User creates or has a relationship with the CSP, and subscribes to 510 a communications service which includes the use of a TN. The CSP 511 collects and stores administrative data about the User. The CSP then 512 activates the User on their network and creates any necessary service 513 data to enable interoperability with other CSPs. The CSP could also 514 update public or privileged databases accessible by other Actors. 515 The CSP provides any necessary credentials to the User (for example, 516 a STIR certificate [14]) to prove the assignment for future 517 transactions. Such credential could be delegated from the one 518 provided by the Registrar to the CSP to continue the chain of 519 assignment. 521 The CSP could assign a TN from its existing inventory or it could 522 acquire a new TN from the Registrar as part of the assignment 523 process. If it assigns it from its existing inventory it would 524 remove the specific TN from the pool of those available for 525 assignment. It may also update the Registrar about the assignment so 526 the Registrar has current assignment data. 528 4.1.3. CSP Delegates TNs to Another CSP 530 A reseller or a service bureau might acquire a block of numbers from 531 a CSP to be issued to Users. 533 In this case, the delegate CSP has a business relationship with the 534 assignee CSP. The assignee CSP collects and stores administrative 535 data about the delegate. The assignee then activates the delegate on 536 their network and creates any necessary service data to enable 537 interoperability with other CSPs. The CSP could also update public 538 or privileged databases accessible by other Actors. The CSP provides 539 any necessary credentials to the delegate CSP (for example, a STIR 540 certificate [14]) to prove the assignment for future transactions. 541 Such credentials could be delegated from the one provided by the 542 Registry to the CSP to continue the chain of assignment. 544 The CSP could assign a block from its existing inventory or it could 545 acquire new TNs from the Registrar as part of the assignment process. 546 If it assigns it from its existing inventory it would remove the 547 specific TN from the pool of those available for assignment. It may 548 also update the Registrar about the assignment so the Registrar has 549 current assignment data. The Delegate may need to provide 550 utilization and assignment data to the Registry, either directly or 551 through the CSP. 553 4.1.4. User Acquires TNs from a Delegate 555 Acquiring a TN from a delegate follows the process in Section 4.1.2, 556 as it should be similar to how a User acquires TNs from a CSP. In 557 this case, the delegate re-delegating the TNs would be performing 558 functions done by the CSP, e.g., providing any credentials, 559 collecting administrative data, creative service data, and so on. 561 4.1.5. User Acquires Numbers from Registrar 563 Today, a user wishing to acquire a freephone number may browse the 564 existing inventory through one or more Registrars, comparing their 565 prices and services. Each such Registrar either is a CSP, or has a 566 business relationship with a CSP to provide services for that 567 freephone number. 569 Acquiring a TN from a Registrar follows the process in Section 4.1.1, 570 as it should be similar to how a CSP acquires TNs from a Registrar. 571 In this case, the User must establish some business relationship 572 directly to a Registrar, similarly to how such functions are 573 conducted today when Users purchase domain names. For the purpose of 574 status information kept by the Registry, TNs assigned to a User are 575 always considered assigned, not inventory. 577 In this use case, after receiving a number assignment from the 578 Registrar, a User will then obtain communications service from a CSP, 579 and provide to the CSP the TN to be used for that service. The CSP 580 will associate service information for that TN, e.g., service 581 address, and make it available to other CSPs to enable 582 interoperability. 584 4.2. Management 586 The management protocol mechanism is needed to associate 587 administrative and service data with TNs, and may be used to refresh 588 or rollover associated credentials. 590 4.2.1. Management of Administrative Data 592 Administrative data is primarily related to the status of the TN, its 593 administrative contacts, and the actors involved in providing service 594 to the TN. Protocol interactions for administrative data will 595 therefore predominantly occur between CSPs and Users to the 596 Registrar, or between Users and delegate CSPs to the CSP. 598 Most administrative data is not a good candidate for a distributed 599 data store model. Access to it does not require real-time 600 performance therefore local caches are not necessary. And it will 601 include sensitive information such as user and contact data. 603 Some of the data could lend itself to being publicly available, such 604 as CSP and TN assignment status. In that case it would be deemed 605 public information for the purposes of the retrieval interface. 607 4.2.1.1. CSP to Registrar 609 After a CSP acquires a TN or block of TNs from the Registrar (per 610 Section 4.1.1 above), it then provides administrative data to the 611 Registrar as a step in the acquisition process. The Registrar will 612 authenticate the CSP and determine if the CSP is authorized to 613 provision the administrative data for the TNs in question. The 614 Registry will update the status of the TN, i.e., that it is 615 unavailable for assignment. The Registrar will also maintain 616 administrative data provided by the CSP. 618 Changes to this administrative data will not be frequent. Examples 619 of changes would be terminating service (see Section 4.2.3.2) and 620 changing a CSP or delegate. Changes should be authenticated by a 621 credential to prove administrative responsibility for the TN. 623 In a distributed Registry model, TN status, e.g., allocated, 624 assigned, available, unavailable, would need to be provided to other 625 Registries in real-time. Other administrative data could be sent to 626 all Registries or other Registries could get a reference address to 627 the host Registry's data store. 629 4.2.1.2. User to CSP 631 After a User acquires a TN or block of TNs from a CSP, the User will 632 provide administrative data to the CSP. The CSP commonly acts as a 633 Registrar in this case, maintaining the administrative data and only 634 notify the Registry of the change in TN status. In this case, the 635 Registry maintains a reference address to the CSP/Registrar's 636 administrative data store so relevant actors have the ability to 637 access the data. Alternatively a CSP could send the administrative 638 data to an external Registrar to store. If there is a delegate 639 between the CSP and user, they will have to ensure there is a 640 mechanism for the delegate to update the CSP as change occurs. 642 4.2.1.3. User to Registrar 644 If the User has a direct relationship with the Registrar, then 645 naturally the user could provision administrative data associated 646 with their TN directly to the Registrar. This is the case, for 647 example, with the freephone example, where a User has a business 648 relationship with its freephone provider, and the freephone provider 649 maintains account and billing data. While delegates necessarily are 650 not assignees, some environments as an optimization might want to 651 support a model where the delegate updates the Registrar directly on 652 changes, as opposed to sending that data to the CSP or through the 653 CSP to the Registrar. As stated already, the protocol should enable 654 Users to acquire TNs directly from a Registrar, which Registrar may 655 or may not also act as a CSP. In these cases the updates would be 656 similar to that described in Section 4.2.1.1. 658 4.2.2. Management of Service Data 660 Service data is data required by an originating or intermediate CSP 661 to enable communications service to a User: a SIP URI is an example 662 of one service data element commonly used to route communications. 663 CSPs typically create and manage service data, however it is possible 664 that delegates and Users could as well. For most use cases involving 665 individual Users, it is anticipated that lower-level service 666 information changes would be communicated to CSPs via existing 667 protocols (like the baseline SIP REGISTER [2] method) rather than 668 through any new interfaces defined by MODERN. 670 4.2.2.1. CSP to other CSPs 672 After a User enrolls for service with a CSP, in the case where the 673 CSP was assigned the TN by a Registrar, the CSP will then create a 674 service address (such as a SIP URI) and associate it with the TN. 675 The CSP needs to update this data to enable service interoperability. 676 There are multiple ways that this update can occur, though most 677 commonly service data is exposed through the retrieval interface (see 678 Section 4.3. For certain deployment architectures, like a 679 distributed data store model, CSPs may need to provide data directly 680 to other CSPs. 682 If the CSP is assigning a TN from its own inventory it may not need 683 to perform service data updates as change occurs because the existing 684 service data associated with inventory may be sufficient once the TN 685 is put in service. They would however likely update the Registry on 686 the change in status. 688 4.2.2.2. User to CSP 690 Users could also associate service data to their TNs at the CSP. An 691 example is a User acquires a TN from the Registrar (as described in 692 Section 4.1.5) and wants to provide that TN to the CSP so the CSP can 693 enable service. In this case, once the user provides the number to 694 the CSP, the CSP would update the Registry or other actors as 695 outlined in Section 4.2.2.1. 697 4.2.3. Managing Change 699 This section will address some special use cases that were not 700 covered in other sections of 4.2. 702 4.2.3.1. Changing the CSP for an Existing Communications Service 704 A User who subscribes to a communications service, and received their 705 TN from that CSP, wishes to retain the same TN but move their service 706 to a different CSP. The User provides their credential to the new 707 CSP and the CSP initiates the change in service. 709 In the simplest scenario, where there's an authoritative composed 710 Registry/Registrar that maintains service data, the new CSP provides 711 the new service data with the User's credential to the Registry/ 712 Registrar, which then makes the change. The old credential is 713 revoked and a new one is provided. The new CSP or the Registrar 714 would send a notification to the old CSP, so they can disable 715 service. The old CSP will undo any delegations to the User, 716 including invalidating any cryptographic credentials (e.g. STIR 717 certificates [13]) previously granted to the User. Any service data 718 maintained by the CSP must be removed, and similarly, the CSP must 719 delete any such information it provisioned in the Registry. 721 In a similar model to common practice in some environments today, the 722 User could provide their credential to the old CSP, and the old CSP 723 initiates the change in service. 725 If there was a distributed Registry that maintained service data, the 726 Registry would also have to update the other Registries of the 727 change. 729 4.2.3.2. Terminating a Service 731 A User who subscribes to a communications service, and received their 732 TN from the CSP, wishes to terminate their service. At this time, 733 the CSP will undo any delegations to the User, including invalidating 734 any cryptographic credentials (e.g. STIR certificates [13]) 735 previously granted to the User. Any service data maintained by the 736 CSP must be removed, and similarly, the CSP must delete any such 737 information it provisioned in the Registrar. 739 The TN will change state from assigned to unassigned, the CSP will 740 update the Registry. Depending on policies the TN could go back into 741 the Registry, CSP, or delegate's pool of available TNs and would 742 likely enter an ageing process. 744 In an alternative use case, a User who received their own TN 745 assignment directly from a Registrar terminates their service with a 746 CSP. At this time, the User might terminate their assignment from 747 the Registrar, and return the TN to the Registry for re-assignment. 748 Alternatively, they could retain the TN and elect to assign it to 749 some other service at a later time. 751 4.3. Retrieval 753 Retrieval of administrative or service data will be subject to access 754 restrictions based on the category of the specific data; public, 755 semi-restricted or restricted. Both administrative and service data 756 can have data elements that fall into each of these categories. It 757 is expected that the majority of administrative and service data will 758 fall into the semi-restricted category: access to this information 759 may require some form of authorization, though service data crucial 760 to reachability will need to be accessible. In some environments, 761 it's possible that none of the service data will be considered 762 public. 764 The retrieval protocol mechanism for semi-restricted and restricted 765 data needs a way for the receiver of the request to identify the 766 originator of the request and what is being requested. The receiver 767 of the request will process that request based on this information. 769 4.3.1. Retrieval of Public Data 771 Under most circumstances, a CSP wants its communications service to 772 be publicly reachable through TNs, so the retrieval interface 773 supports public interfaces that permit clients to query for service 774 data about a TN. Some service data may however require that the 775 client by authorized to receive it, per the use case in Section 4.3.3 776 below. 778 Public data can simply be posted on websites or made available 779 through a publicly available API. Public data hosted by a CSP may 780 have a reference address at the Registry. 782 4.3.2. Retrieval of Semi-restricted Administrative Data 784 A CSP is having service problems completing calls to a specific TN, 785 so it wants to contact the CSP serving that TN. The Registry 786 authorizes the originating CSP to access this information. It 787 initiates a query to the Registry, the Registry verifies the 788 requestor and the requested data and Registry responds with the 789 serving CSP and contact data. 791 Alternatively that information could be part of a distributed data 792 store and not stored at the Registry. In that case, the CSP has the 793 data in a local distributed data store and it initiates the query to 794 the local data store. The local data store responds with the CSP and 795 contact data. No verification is necessary because it was done when 796 the CSP was authorized to receive the data store. 798 4.3.3. Retrieval of Semi-restricted Service Data 800 A User on a CSP's network calls a TN. The CSP initiates a query for 801 service data associated with the TN to complete the call, and will 802 receive special service data because the CSP operates in a closed 803 environment where different CSPs receive different responses, and 804 only authorized CSPs may access service data. The query and response 805 must have real-time performance. There are multiple scenarios for 806 the query and response. 808 In a distributed data store model each CSP distributes its updated 809 service data to all other CSPs. The originating CSP has the service 810 data in its local data store and queries it. The local data store 811 responds with the service data. The service data can be a reference 812 address to a data store maintained by the serving CSP or it can be 813 the service address itself. In the case where it's a reference 814 address the query would go to the serving CSP and they would verify 815 the requestor and the requested data and respond. In the case where 816 it's the service address it would process the call using that. 818 In some environments, aspects of the service data may reside at the 819 Registry itself (for example, the assigned CSP for a TN), and thus a 820 the query may be sent to the Registry. The Registry verifies the 821 requestor and the requested data and responds with the service data, 822 such as a SIP URI containing the domain of the assigned CSP. 824 4.3.4. Retrieval of Restricted Data 826 In this case, a Government Entity wishes to access information about 827 a particular User, who subscribes to a communications service. The 828 entity that operates the Registry on behalf of the National Authority 829 in this case has some pre-defined relationship with the Government 830 Entity. When the CSP acquired TNs from the National Authority, it 831 was a condition of that assignment that the CSP provide access for 832 Government Entities to telephone numbering data when certain 833 conditions apply. The required data may reside either in the CSP or 834 in the Registrar. 836 For a case where the CSP delegates a number to the User, the CSP 837 might provision the Registrar (or itself, if the CSP is composed with 838 a Registrar) with information relevant to the User. At such a time 839 as the Government Entity needs information about that User, the 840 Government Entity may contact the Registrar or CSP to acquire the 841 necessary data. The interfaces necessary for this will be the same 842 as those described in Section 4.3; the Government Entity will be 843 authenticated, and an authorization decision will be made by the 844 Registrar or CSP under the policy dictates established by the 845 National Authority. 847 5. Acknowledgments 849 We would like to thank Henning Schulzrinne for his contributions to 850 this problem statement and framework, and to thank Pierce Gorman for 851 detailed comments. 853 6. IANA Considerations 855 This memo includes no instructions for the IANA. 857 7. Security Considerations 859 The acquisition, management, and retrieval of administrative and 860 service data associated with telephone numbers raises a number of 861 security issues. 863 Any mechanism that allows an individual or organization to acquire 864 telephone numbers will require a means of mutual authentication, of 865 integrity protection, and of confidentiality. A Registry as defined 866 in this document will surely want to authenticate the source of an 867 acquisition request as a first step in the authorization process to 868 determine whether or not the resource will be granted. Integrity of 869 both the request and response is essential to ensuring that tampering 870 does not allow attackers to block acquisitions, or worse, to 871 commandeer resources. Confidentiality is essential to preventing 872 eavesdroppers from learning about allocations, including the 873 personally identifying information associated with the administrative 874 or technical contracts for allocations. 876 A management interface for telephone numbers has similar 877 requirements. Without proper authentication and authorization 878 mechanisms in place, an attack could use the management interface to 879 disrupt service data or administrative data, which could deny service 880 to users, enable new impersonation attacks, prevent billing systems 881 from operating properly, and cause similar system failures. 883 Finally, a retrieval interfaces has its own needs for mutual 884 authentication, integrity protection, and for confidentiality. Any 885 CSP sending a request to retrieve service data associated with a 886 number will want to know that it is reaching the proper authority, 887 that the response from that authority has not been tampered with in 888 transit, and in most cases the CSP will not want to reveal to 889 eavesdroppers the number it is requesting or the response that it has 890 received. Similarly, any service answering such a query will want to 891 have a means of authenticating the source of the query, and of 892 protecting the integrity and confidentiality of its responses. 894 8. Informative References 896 [1] Peterson, J. and C. Jennings, "Enhancements for 897 Authenticated Identity Management in the Session 898 Initiation Protocol (SIP)", RFC 4474, 899 DOI 10.17487/RFC4474, August 2006, 900 . 902 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 903 A., Peterson, J., Sparks, R., Handley, M., and E. 904 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 905 DOI 10.17487/RFC3261, June 2002, 906 . 908 [3] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 909 Uniform Resource Identifiers (URI) Dynamic Delegation 910 Discovery System (DDDS) Application (ENUM)", RFC 6116, 911 DOI 10.17487/RFC6116, March 2011, 912 . 914 [4] Channabasappa, S., Ed., "Data for Reachability of Inter- 915 /Intra-NetworK SIP (DRINKS) Use Cases and Protocol 916 Requirements", RFC 6461, DOI 10.17487/RFC6461, January 917 2012, . 919 [5] Watson, M., "Short Term Requirements for Network Asserted 920 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 921 . 923 [6] Jennings, C., Peterson, J., and M. Watson, "Private 924 Extensions to the Session Initiation Protocol (SIP) for 925 Asserted Identity within Trusted Networks", RFC 3325, 926 DOI 10.17487/RFC3325, November 2002, 927 . 929 [7] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 930 of Named Entities (DANE) Transport Layer Security (TLS) 931 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 932 2012, . 934 [8] Elwell, J., "Connected Identity in the Session Initiation 935 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 936 2007, . 938 [9] Schulzrinne, H., "The tel URI for Telephone Numbers", 939 RFC 3966, DOI 10.17487/RFC3966, December 2004, 940 . 942 [10] Rosenberg, J. and C. Jennings, "The Session Initiation 943 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 944 January 2008, . 946 [11] Peterson, J., Jennings, C., and R. Sparks, "Change Process 947 for the Session Initiation Protocol (SIP) and the Real- 948 time Applications and Infrastructure Area", BCP 67, 949 RFC 5727, DOI 10.17487/RFC5727, March 2010, 950 . 952 [12] Newton, A. and S. Hollenbeck, "Registration Data Access 953 Protocol (RDAP) Query Format", RFC 7482, 954 DOI 10.17487/RFC7482, March 2015, 955 . 957 [13] Peterson, J., "A Framework and Information Model for 958 Telephone-Related Information (TeRI)", draft-peterson- 959 modern-teri-00 (work in progress), October 2015. 961 [14] Peterson, J. and S. Turner, "Secure Telephone Identity 962 Credentials: Certificates", draft-ietf-stir- 963 certificates-06 (work in progress), July 2016. 965 [15] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 966 Huguenin, "Verification Involving PSTN Reachability: 967 Requirements and Architecture Overview", draft-jennings- 968 vipr-overview-06 (work in progress), December 2013. 970 [16] Bellur, H. and C. Wendt, "Distributed Registry Protocol", 971 draft-wendt-modern-drip-00 (work in progress), October 972 2015. 974 [17] Rosenberg, J. and H. Schulzrinne, "Session Initiation 975 Protocol (SIP): Locating SIP Servers", RFC 3263, 976 DOI 10.17487/RFC3263, June 2002, 977 . 979 Authors' Addresses 981 Jon Peterson 982 Neustar, Inc. 983 1800 Sutter St Suite 570 984 Concord, CA 94520 985 US 987 Email: jon.peterson@neustar.biz 989 Tom McGarry 990 Neustar, Inc. 991 1800 Sutter St Suite 570 992 Concord, CA 94520 993 US 995 Email: tom.mcgarry@neustar.biz