A TeRI Profile for Representing Valid and Allocated Numbers
draft-peterson-modern-teri-valid-00

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

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]