Network Working Group J. Peterson Internet-Draft Neustar Intended status: Informational C. Wendt Expires: May 3, 2018 Comcast October 30, 2017 A TeRI Profile for Representing Valid and Allocated Numbers draft-peterson-modern-teri-valid-01.txt Abstract The Telephone-Related Information (TeRI) framework defines an information model for data objects used in the acquisiton, management, and retrieval of telephone numbers and information related to them via the Internet. This document defines a profile that extends the base Record format of TeRI to carry information about valid and allocated telephone numbers, which can help to detect and prevent certain forms of abuse in the telephone network. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Peterson & Wendt Expires May 3, 2018 [Page 1] Internet-Draft JSON Valid October 2017 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 2 3.1. Allocated Blocks . . . . . . . . . . . . . . . . . . . . 4 3.2. Individual Assigned Numbers . . . . . . . . . . . . . . . 4 4. TeRI Profile for Valid and Allocated Numbers . . . . . . . . 5 4.1. TeRI Record Format for Allocated Numbers . . . . . . . . 6 4.2. TeRI Retrieval Operation with an Allocation Restriction . 6 5. Bulk Propagation of Allocation Records . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Telephone-Related Information (TeRI) framework [I-D.peterson-modern-teri] defines an information model for data objects used in the acquisiton, management, and retrieval of telephone numbers and information related to them via the Internet. This document defines a TeRI profile that extends the base Record format of TeRI to carry information about valid and allocated telephone numbers which can help to detect certain forms of abuse in the telephone network. This is an early stage Internet-Draft that shows how TeRI might be extended with a profile for a specific use case. 2. Terminology In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. This document also incorporates the terminology of the MODERN Framework [I-D.ietf-modern-problem-framework]. 3. Motivation and Use Cases The primary motivation for this mechanism is to provide a way for TeRI services to convey lists of telephone numbers and telephone number ranges that are valid for call origination. This list could be used by service providers and applications to make authorization Peterson & Wendt Expires May 3, 2018 [Page 2] Internet-Draft JSON Valid October 2017 decisions about forwarding or accepting communications from a particular source. Today, some problem users of the telephone network spoof invalid numbers, as described in [RFC7340]. While solutions like STIR [I-D.ietf-stir-rfc4474bis] promise to enable credentials to prove ownership for numbers, a list of valid telephone numbers serves a somewhat orthogonal need to make sure that valid calling party numbers are presented in the telephone network, regardless of whether or not they have been signed with STIR. It is possible to implement a list of this form as a blacklist, a list of telephone numbers or number ranges that should not originate calls, or as a whitelist, a list of those that can legitimately originate calls. This document follows a whitelist approach, as it is considerably more difficult to syntactically represent all of the possible invalid ways to construct telephone numbers than it is to exhaustively enumerate the valid ones. For bulk operations, this requires that Records enumerate valid and allocated blocks to form a complete whitelist for a numbering plan. Per the model given in [I-D.ietf-modern-problem-framework], this specification furthermore assumes that ranges of telephone numbers are ordinarily allocated to a Communications Service Provider (CSP) such as a telephone network carrier, who then in turn assign numbers from those ranges to individual users or organizations. However, there are some use cases where assignment occurs on an individual telephone number level, such as the assignment of freephone numbers in the United States. Therefore, this mechanism considers two different data formats for representing allocation and assignment: as blocks and as individual numbers. Each has its own area of applicability, and the two formats are presented here as complimentary rather than competing mechanisms. In TeRI [I-D.peterson-modern-teri] terms, a Service could even hold a mixture of salient Records, some corresponding to blocks of numbers and others to individual numbers. At a high level, the property of "allocation" belongs to telephone number blocks (Records with an "R" subject in TeRI), and the property of "assignment" belongs to individual numbers (Records with a "T" subject in TeRI). During operations, the database of Records maintained by a TeRI service would be consulted to determine if a calling party number is covered by a Record in the national numbering plan. As a logical Operation, a TeRI Client can Query a TeRI Service with a given calling party number, and receive as a Response in a success case either a Record indicating the allocated block within which the calling party number falls, or a Record for an allocated individual number; in failure cases, the Response would be an indication that so such Record exists at the TeRI service. Note however that Query and Response does not necessarily mean a network dip; if Records are Peterson & Wendt Expires May 3, 2018 [Page 3] Internet-Draft JSON Valid October 2017 cached at a local TeRI service, then the TeRI Client and Service may be colocated, and the Query and Response may happen over a local API. Methods of propagating bulk lists of allocated numbers between TeRI Services are dicussed in Section 5. 3.1. Allocated Blocks In the simplest case, a TeRI Service can maintain a list of Records that enumerates the valid and allocated blocks of numbers in a given national numbering plan. In North America, for example, this could represent blocks at the ten-thousand number level (NPA/NXX) or "number pooling" blocks at the thousand-block level (NPA/NXX-X), or a mixture of the two. The preferred block size may vary for different national numbering plans. The assignment of numbers within an allocated block to Users is usually a matter internal to CSP operations, though number portability mechanisms can introduce complications: note that just because a number has been ported to another CSP, that does not necessarily mean that it remains assigned at any given moment. As new blocks are allocated by a Registry (see [I-D.ietf-modern-problem-framework]), then in this model the Registry would be responsible for generating and signing a new Record corresponding to the newly allocated block, as well updating any Records that aggregate these allocations into bulk lists. No particular recommendation is made in this document as to how much aggregation Registries should do: this will require some implementation experience to determine. Other TeRI services could acquire and cache these Registry allocation Records, where they could be locally consulted during call processing. 3.2. Individual Assigned Numbers In some deployments, it may be possible to determine whether individual telephone numbers are assigned or not. One example is the freephone system in the United States. Unlike traditional block allocations to CSPs, for the freephone system individual numbers are purchased by consumers, and the pool of available freephone numbers is managed by a standalone Registry (i.e., the SMS/800 system). Those sorts of Registries would need to generate and sign any TeRI Records for numbers that fall under their authority. While a limited amount of aggregation may be possible, for example when a large block of numbers is completely assigned at an enterprise, it is expected that Records in TeRI will mostly reflect individual telephone numbers (the "T" element). Moreover, for some experimental number assignment systems like DRiP [I-D.wendt-modern-drip], entities participating in a distributed Peterson & Wendt Expires May 3, 2018 [Page 4] Internet-Draft JSON Valid October 2017 Registry may share a pool of numbers available for assignment, which requires a synchronization mechanism that allows all TeRI services to have fresh information about the assignment of individual telephone numbers. In that model, any of several entities may be authorized to generate and sign new TeRI Records reflecting a number assignment which are then distributed and persisted at multiple places in the network. 4. TeRI Profile for Valid and Allocated Numbers This profile describes a TeRI extension with an additional Element to represent the allocation or assignment status of a number. There is no need for any Element to state that a number is valid, as TeRI Records will not exist for numbers that are invalid. The set of valid TeRI records for allocation is thus a whitelist that can be checked in real time during call processing to detect the use of invalid or unallocated calling party numbers. This profile furthermore illustrates a TeRI Retrieval Operation for one or more Records related to allocation or assignment at a Service - again, this Retrieval Operation does not necessarily reflect a network dip, it may be performed as a local database operation during real-time call processing. The Subject of the Query may correspond to either a block ("R") or an individual number ("T"); during call processing, for example, a Client might ask the database for Records related to the allocation of a number. The introduction of a new "Allocated" Element in this specification permits a new Restriction for the Query specific to number allocation data. The Response to this Request will consist of a Success with one or more Records if they exist, or a "Subject Does Not Exist" Response if there are no corresponding Records at the Service. Success Responses may contain either allocation or assignment data, depending on what is available at the Service. A query for a particular number, for example, might return a block ("R") indication that the number is within an allocated block. Alternatively, if the Service possesses such a Record, it might return an individual number ("T") record indicating that the number is both allocated and currently assigned. A Service might even possess both Records, and return both in response to a Query. Information on number validity and allocation within the TeRI model is necessarily Administrative Data, and the Records returned by this Operation will not contain Service Data. Peterson & Wendt Expires May 3, 2018 [Page 5] Internet-Draft JSON Valid October 2017 4.1. TeRI Record Format for Allocated Numbers This specification defines a new Administrative Element for Records called "allocated", which can have the values "yes", "assigned", or "no". This element may be used in a Record with a Subject representing a number block (the TeRI "R" element) or an individual number (the TeRI "T" element), though values other than "assigned" would rarely be applicable to individual number Records. A value of "yes" is used when all of the numbers covered by the Record are known to be allocated, but it indicates nothing about assignment status. This would be used for common carrier allocation of number blocks conveyed as ranges ("R") Records, for example. An "allocated" value of "assigned" indicates that all numbers covered by the Record are both allocated and assigned at this time. This would most commonly be used by for individual number Records ("T"). An "allocated" value of "no" indicates that the number or number block is valid in the numbering plan, but all numbers covered by the Record are known to be unallocated at this time. This would for example be used by a numbering plan administrator for a block ("R") Record to show numbering ranges that could be allocated in the future but are not in use today. 4.2. TeRI Retrieval Operation with an Allocation Restriction Per the standard TeRI semantics, a Client may send a Retrieval Query to a TeRI Service. In this profile, the Retrieval Query would indicate that it is looking for the "Allocated" attribute via a Restriction. Following the JSON binding for TeRI given in [I-D.peterson-modern-teri-json], a Request with a Restriction for "Allocated" might look like: { "TeRI":"Retrieval", "Source":[{"Request":"example.com"}], "Subject":{"T":"12125551111"}, "Restriction":["Allocated"] } And a sucesssful Response containing a valid thousand block Record generated by the Registry, one which contains the number that was the Subject of the Query, might look as follows: Peterson & Wendt Expires May 3, 2018 [Page 6] Internet-Draft JSON Valid October 2017 { "TeRI":"Response", "Code":"Success", "Record":[{ "Identifier":"x989hjfd0", "Authority":"registry.example.org", "Access":"Public", "Subject":[{"R":"12125551"}], ... "Allocated":"yes" }] } This Response indicates that the number falls within a block that the Registry considers to be allocated, but does not give any visibility into whether or not the number is assigned. 5. Bulk Propagation of Allocation Records TeRI assumes that the same Retrieval interface that is used to query for Records about individual numbers can be used to fetch bulk data. A query that asks for the total set of allocated numbers under the North American Numbering Plan would look as follows: { "TeRI":"Retrieval", "Source":[{"Request":"example.com"}], "Subject":{"R":"1"}, "Restriction":["Allocated"] } The way that a Service responds to this Query will depend on how Registries choose to organize and aggregate Records. Only a certain amount of hierarchical aggregation of numbering resources will be possible in some numbering plans. For the North American Numbering Plan, for example, prefix aggregation the NPA (area code) level is unlikely to be useful. The reservation of all "easily recognizable codes" (ERCs) that end in two of the same digit (e.g. 200, 211, 222, 233) means that there will always be gaps in allocation for the first digit of every NPA prefix. Moreover, there are still significant gaps in allocation and space left for future expansion. At the time of this writing, say, most of the NPAs beginning with "9" are currently allocated, but many are not: apart from the ten ERCs, all of 960-9 and 990-9 are set aside for future expansion, and around twenty more NPAs, including 921 and 987, remain unallocated, leaving a gap of around 50 NPAs under "9". NPA allocations, once made, can later be revoked: 935, for example, was assigned as a relief NPA for the San Diego area but was subsequently suspended because it was not Peterson & Wendt Expires May 3, 2018 [Page 7] Internet-Draft JSON Valid October 2017 needed, as 858 alleviated number exhaustion; 927 was similarly allocated for mobile phone use in Florida, but then cancelled. According to the TeRI semantics, creating Records with a Subject at the NPA level as follows: { "TeRI":"Response", "Code":"Success", "Record":[{ "Identifier":"x989hjfd0", "Authority":"registry.example.org", "Access":"Public", "Subject":[{"R":"1212"}], ... "Allocated":"yes" }] } ... would signify not just that the "212" area code is allocated, but that all numbers under the 212 area code have been allocated; e.g. that the 212/001 NPA/NXX is valid and allocated. The valid NXX codes under each NPA similarly do not lend themselves to aggregation. Registries should thus attempt to model aggregation on the way that numbering resources are actually allocated: in North America, but the ten-thousand block and thousand block ranges. This does not however mean that there should necessarily be one Record per ten-thousand block generated as a Service. An individual Record might for example contain a set ten allocated thousand-block prefixes, all of which have been allocated to a single carrier, for example: { "TeRI":"Response", "Code":"Success", "Record":[{ "Identifier":"x989hjfd0", "Authority":"registry.example.org", "Access":"Public", "Subject":[ {"R":"1212555"} {"R":"1619555"} {"R":"1858555"} ... ], ... "Allocated":"yes" }] } Peterson & Wendt Expires May 3, 2018 [Page 8] Internet-Draft JSON Valid October 2017 Exactly how high-level allocation Records should be organized is left to implementation. In some TeRI bindings, it may be possible to subscribe to such new Records and receive an automatic update from the Registry at a time that new number blocks are allocated. There may be use cases in which it makes sense for entities other than a Registry to issue the TeRI objects defined in this specification; that is left to future investigation. 6. Acknowledgments We would like to thank Tom McGarry for contributions to this document. 7. IANA Considerations This memo registers a new TeRI Element called "Allocated" which may be used in Administrative Records or in Queries Restrictions for Records. More TBD. 8. Security Considerations TBD. 9. Informative References [I-D.ietf-modern-problem-framework] Peterson, J. and T. McGarry, "Modern Problem Statement, Use Cases, and Framework", draft-ietf-modern-problem- framework-03 (work in progress), July 2017. [I-D.ietf-stir-rfc4474bis] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 (work in progress), February 2017. [I-D.peterson-modern-teri] Peterson, J., "An Architecture and Information Model for Telephone-Related Information (TeRI)", draft-peterson- modern-teri-03 (work in progress), July 2017. [I-D.peterson-modern-teri-json] Peterson, J., "A JSON Binding and Encoding for TeRI", draft-peterson-modern-teri-json-01 (work in progress), July 2017. Peterson & Wendt Expires May 3, 2018 [Page 9] Internet-Draft JSON Valid October 2017 [I-D.wendt-modern-drip] Wendt, C. and H. Bellur, "Distributed Registry Protocol (DRiP)", draft-wendt-modern-drip-02 (work in progress), July 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, . Authors' Addresses Jon Peterson Neustar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Email: jon.peterson@neustar.biz Chris Wendt Comcast One Comcast Center Philadelphia, PA 19103 USA Email: chris-ietf@chriswendt.net Peterson & Wendt Expires May 3, 2018 [Page 10]