Network Working Group J. Peterson Internet-Draft Neustar Intended status: Informational C. Wendt Expires: January 4, 2018 Comcast July 3, 2017 A TeRI Profile for Representing Valid and Allocated Numbers draft-peterson-modern-teri-valid-00.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 in order to prevent abuse. 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 http://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 January 4, 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 (http://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 January 4, 2018 [Page 1] Internet-Draft JSON Valid July 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 Allocated Numbers . . . . . . . . . . . . . . 4 4. TeRI Profile for Valid and Allocated Numbers . . . . . . . . 5 4.1. TeRI Record Format for Allocated Numbers . . . . . . . . 5 4.2. TeRI Retrieval Operation with an Allocation Restriction . 6 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 serves primarily as a vehicle to give examples of 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 that are valid for origination. This list could be used by service providers and applications to make authorization decisions about forwarding or Peterson & Wendt Expires January 4, 2018 [Page 2] Internet-Draft JSON Valid July 2017 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 cannot originate calls, or as a whitelist, a list of those that can 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. 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 allocates numbers from those ranges to individual users or organizations. However, there are some use cases where assignment occurs on an individual telephone number level (for example, for freephone numbers in the United States). Therefore, this mechanism considers two different data formats for representing allocation: 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. During operations, the database of Records maintained by a TeRI service would be consulted to determine if a calling party number falls within a valid and allocated Record for 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 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. Peterson & Wendt Expires January 4, 2018 [Page 3] Internet-Draft JSON Valid July 2017 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 delegation 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 has been allocated at any given moment. As new blocks are assigned 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. Other TeRI services could acquire and cache this Record. 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. 3.2. Individual Allocated Numbers In some deployments, it may be possible to determine whether or not individual telephone numbers are allocated 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 thus 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. Moreover, for some experimental number allocation systems like DRiP [I-D.wendt-modern-drip], a distributed Registry may share a pool of numbers available for allocation, which requires a synchronization mechanism that allows all TeRI services to have fresh information about the allocation of individual telephone numbers. In that model, any of several entities may be authorized to generate and sign new TeRI Records reflecting a number allocation which are then distributed and persisted at multiple places in the network. Peterson & Wendt Expires January 4, 2018 [Page 4] Internet-Draft JSON Valid July 2017 4. TeRI Profile for Valid and Allocated Numbers This profile describes a TeRI extension with an additional Element to represent the allocation status of a number. There is no particular need for any Element to establish that a number is valid, as TeRI Records will not exist for numbers that are invalid. This profile furthermore illustrates a TeRI Retrieval Operation that attempts to read one or more Records at a Service. The Subject of the Query is a particular telephone number. The introduction of a new 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. 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. 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", "no", or "unknown". This 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 "unknown" would only rarely be applicable to individual numbvers. A value of "yes" may be used only when all of the numbers in the block are known to be allocated. A distributed Registry, for example, could aggregate individual number allocations into a blocks of ten or one hundred numbers, so that a Retrieval Query for a single TN in the block would receive a Response containing the block Record. An "allocated" value of "no" indicates that the number or number block is valid but unallocated at this time. The value of "unknown" may be used when the entity creating the Record lacks real-time knowledge of the allocation of numbers within the block; this is the option that would typically be used by a Registry that created a block Record for numbers assigned to a CSP. This would also apply to number ranges where, due to number portability or pooling, the block in question contains numbers that have been assigned to different administrative entities. Peterson & Wendt Expires January 4, 2018 [Page 5] Internet-Draft JSON Valid July 2017 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 encoding 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: { "TeRI":"Response", "Code":"Success", "Record":[{ "Identifier":"x989hjfd0", "Authority":"registry.example.org", "Access":"Public", "Subject":[{"R":"12125551"}], ... "Allocated":"unknown" }] } 5. Acknowledgments We would like to thank you for your contributions to this problem statement and framework. 6. 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. Peterson & Wendt Expires January 4, 2018 [Page 6] Internet-Draft JSON Valid July 2017 7. Security Considerations TBD. 8. 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-02 (work in progress), March 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-02 (work in progress), October 2016. [I-D.peterson-modern-teri-json] Peterson, J., "A JSON Binding and Encoding for TeRI", draft-peterson-modern-teri-json-00 (work in progress), October 2016. [I-D.wendt-modern-drip] Bellur, H. and C. Wendt, "Distributed Registry Protocol", draft-wendt-modern-drip-01 (work in progress), July 2016. [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, . Peterson & Wendt Expires January 4, 2018 [Page 7] Internet-Draft JSON Valid July 2017 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 January 4, 2018 [Page 8]