Internet DRAFT - draft-peterson-modern-teri-valid
draft-peterson-modern-teri-valid
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]
