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]