[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <https://www.rfc-editor.org/info/rfc7159>.

   [RFC7340]  Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
              Telephone Identity Problem Statement and Requirements",
              RFC 7340, DOI 10.17487/RFC7340, September 2014,
              <https://www.rfc-editor.org/info/rfc7340>.

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]

Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/