Modern Problem Statement, Use Cases, and Framework
draft-peterson-modern-problems-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Jon Peterson , Tom McGarry | ||
| Last updated | 2016-02-25 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-peterson-modern-problems-03
Network Working Group J. Peterson
Internet-Draft T. McGarry
Intended status: Informational NeuStar, Inc.
Expires: August 28, 2016 February 25, 2016
Modern Problem Statement, Use Cases, and Framework
draft-peterson-modern-problems-03.txt
Abstract
The functions of the public switched telephone network (PSTN) are
rapidly migrating to the Internet. This is generating new
requirements for many traditional elements of the PSTN, including
telephone numbers (TNs). TNs no longer serve simply as telephone
routing addresses, they are now identifiers which may be used by
Internet-based services for a variety of purposes including session
establishment, identity verification, and service enablement. This
problem statement examines how the existing tools for allocating and
managing telephone numbers do not align with the use cases of the
Internet environment, and proposes a framework for Internet-based
services relying on TNs.
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 August 28, 2016.
Copyright Notice
Copyright (c) 2016 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
Peterson & McGarry Expires August 28, 2016 [Page 1]
Internet-Draft Modern Problems February 2016
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
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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Data Management Architectures . . . . . . . . . . . . . . 6
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. CSP Acquires TNs from Registry . . . . . . . . . . . 8
4.1.2. User Acquires TNs from CSP . . . . . . . . . . . . . 9
4.1.3. CSP Delegates TNs to Another CSP . . . . . . . . . . 10
4.1.4. User Acquires TNs from a Delegate . . . . . . . . . . 10
4.1.5. User Acquires Numbers from Registry . . . . . . . . . 10
4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Management of Administrative Data . . . . . . . . . . 11
4.2.1.1. CSP to Registry . . . . . . . . . . . . . . . . . 11
4.2.1.2. User to CSP . . . . . . . . . . . . . . . . . . . 12
4.2.1.3. User to Registry . . . . . . . . . . . . . . . . 12
4.2.2. Management of Service Data . . . . . . . . . . . . . 12
4.2.2.1. CSP to other CSPs . . . . . . . . . . . . . . . . 12
4.2.2.2. User to CSP . . . . . . . . . . . . . . . . . . . 13
4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 13
4.2.3.1. Changing the CSP for an Existing Communications
Service . . . . . . . . . . . . . . . . . . . . . 13
4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 14
4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 15
4.3.2. Retrieval of Semi-restricted Administrative Data . . 15
4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 15
4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 16
5. Distributed Registries and Data Stores . . . . . . . . . . . 16
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Peterson & McGarry Expires August 28, 2016 [Page 2]
Internet-Draft Modern Problems February 2016
1. Problem Statement
The challenges of utilizing telephone numbers (TNs) on the Internet
have been known for some time. Internet telephony provided the first
use case for routing telephone numbers on the Internet in a manner
similar to how calls are routed in the public switched telephone
network (PSTN). As the Internet had no service for discovering the
endpoints associated with telephone numbers, ENUM [3] created a DNS-
based mechanism for resolving TNs in an IP environment, by defining
procedures for translating TNs into URIs for use by protocols such as
SIP [2]. The resulting database was designed to function in a manner
similar to the systems that route calls in the PSTN. Originally, it
was envisioned that ENUM would be deployed as a global hierarchical
service, though in practice, it has only been deployed piecemeal by
various parties. Most notably, ENUM is used as an internal network
function, and is hardly used between service provider networks. The
original ENUM concept of a single root, e164.arpa, proved to be
politically and practically challenging, and less centralized models
have thus flourished. Subsequently, the DRINKS [4] framework showed
ways that authorities might provision information about TNs at an
ENUM service or similar Internet-based directory. These technologies
have also generally tried to preserve the features and architecture
familiar from the PSTN numbering environment.
Over time, Internet telephony has encompassed functions that differ
substantially from traditional PSTN routing and management,
especially as non-traditional providers have begun to utilize
numbering resources. An increasing number of enterprises, over-the-
top Voice over IP providers, text messaging services, and related
non-carrier services have become heavy users of telephone numbers.
An enterprise, for example, could deploy an IP PBX that receives a
block of telephone numbers from a carrier and then in turn distribute
those numbers to new IP telephones when they associate with the PBX.
Internet services offer users portals where they can allocate new
telephone numbers on the fly, assign multiple "alias" telephone
numbers to a single line service, implement various mobility or find-
me-follow-me applications, and so on. Peer-to-peer telephone
networks have encouraged experiments with distributed databases for
telephone number routing and even allocation.
This dynamic control over telephone numbers has few precedents in the
traditional PSTN outside of number portability. Number portability
has been implemented in many countries, and the capability of a user
to choose and change their service provider while retaining their TN
is widely implemented now. However, TN administration processes
rooted in PSTN technology and policies dictate that this be an
exception process fraught with problems and delays. Originally,
processes were built to associate a specific TN to a specific service
Peterson & McGarry Expires August 28, 2016 [Page 3]
Internet-Draft Modern Problems February 2016
provider and never change it. With number portability, the industry
had to build new infrastructure, new administrative functions and
processes to change the association of the TN from one service
provider to another. Thanks to the increasing sophistication of
consumer mobile devices as Internet endpoints as well as telephones,
users now associate TNs with many Internet applications other than
telephony. This has generated interest in alternative models where a
user could drive the porting process and related administrative
functions on their own, perhaps by using Internet services to
directly make changes to the service associated with telephone
numbers without requiring service provider intervention.
Most TNs today are assigned to specific geographies, at both an
international level and within national numbering plans. Numbering
practices today are tightly coupled with the manenr that service
providers interconnect, as well as how TNs are routed and
administered: the PSTN was carefully designed to delegate switching
intelligence geographically. In interexchange carrier routing in
North America, for example, calls to a particular TN are often handed
off to the terminating service provider close to the geography where
that TN is assigned. But the overwhelming success of mobile
telephones has increasing eroded the connection between numbers and
regions. Furthermore, the topology of IP networks is not anchored to
geography in the same way that the telephone network is. In an
Internet environment, establishing a network architecture for routing
TNs could depend little on geography. Adapting TNs to the Internet
requires more security, richer datasets and more complex query and
response capabilities than previous efforts have provided.
This document will create a common understanding of the problem
statement related to allocating, managing, and resolving TNs in an IP
environment, and to outline a framework and motivating use cases for
how to create IP-based mechanisms for TNs. It will be important to
acknowledge that there are various evolvling international and
national policies and processes related to TNs, and any solutions
need to be flexible enough to account for variations in policy and
requirements.
2. Definitions
This section provides definitions for actors, data types and data
management architectures as they are discussed in this document.
2.1. Actors
The following roles of actors are defined in this document:
Peterson & McGarry Expires August 28, 2016 [Page 4]
Internet-Draft Modern Problems February 2016
Numbering Authority: A regulatory body within a country that manages
that country's TNs. The Numbering Authority decides national
numbering policy for the nation, region, or other domain for which
it has authority, including what TNs can be allocated, and which
are reserved.
Registry: An entity that administers the allocation of TNs based on
a Numbering Authority's policies. Numbering authorities can act
as the Registries themselves, or they can outsource the function
to other entities. There are two subtypes of Registries: an
Authoritative Registry and a Distributed Registry. The general
term Registry in this document refers to both kinds of Registries.
Authoritative Registry: An authoritative Registry is a single entity
with sole responsibility for specific numbering resources.
Distributed Registry: Distributed Registries are multiple Registries
responsible for the same numbering resources. (There's more on
distributed Registries later in this section.)
Communication Service Provider (CSP): A provider of communications
services to Users, where those services can be identified by TNs.
This includes both traditional telephone carriers or enterprises
as well as service providers with no presence on the PSTN who use
TNs. This framework does not assume that any single CSP provides
all the communications service related to a particular TN.
Service Enabler: An entity that works with CSPs to enable
communication service to a User; perhaps a vendor, or third-party
integrator.
User: An individual reachable through a communications service;
usually a customer of a communication service provider.
Government Entity: An entity that, due to legal powers deriving from
national policy, has privileged access to information about number
administration under certain conditions.
Note that an individual, company or other entity may act in one or
more of the roles above; for example, an individual may be a User but
also act as their own CSP.
All actors that are recipients of numbering resources, be they a CSP,
Service Enabler, or User, can also be said to have a relationship to
a Registry of either an assignee or delegate:
Assignee: An actor that is assigned a TN directly by the Registry;
an assignee always has a direct relationship with a Registry.
Peterson & McGarry Expires August 28, 2016 [Page 5]
Internet-Draft Modern Problems February 2016
Delegate: An actor that is delegated a TN from an assignee or
another delegate, who does not necessary have a relationship with
a Registry. Delegates may delegate one or more of their TN
assignment(s) to one or more further downstream subdelegates.
Note that although Numbering Authorities are listed as actors, they
are unlikely to actually participate in the protocol flows
themselves.
2.2. Data Types
The following data types are defined in this document:
Administrative Data: assignment data related to the TN and the
relevant actors; it includes TN status (assigned, unassigned,
etc.), contact data for the assignee or delegate, and typically
does not require real-time performance as access to this data is
not required for ordinary call or session establishment.
Service Data: data necessary to enable service for the TN; it
includes addressing data, service features, and so on, and
typically does require real-time performance, in so far as this
data typically must be queried during call set-up.
Administrative and service data can fit into three categories:
Public: data that anyone can access, for example a list of which
numbering resources (unallocated number ranges) are available for
acquisition from the Registry.
Semi-restricted: data that a subset of actors can access, for
example CSPs may be able to access other CSP's service data.
Restricted: data that is only available to a small subset of actors,
for example a Government Entity may be able access contact
information for a User.
While it seems there are really only two categories, public and
restricted based on requestor, the distinction between semi-
restricted and restricted is helpful for the use cases below.
2.3. Data Management Architectures
In addition to traditional centralized Registries, this framework
also supports environments where the same data is being managed by
multiple entities, and stored in many locations. See Section 5 for
more on the latter architecture.
Peterson & McGarry Expires August 28, 2016 [Page 6]
Internet-Draft Modern Problems February 2016
Data store: a service that stores and enables access to
administrative and/or service data.
Reference Address: a URL that dereferences to the location of the
data store.
Distributed data stores: refers to administrative or service data
being stored with multiple actors. For example, CSPs could
provision their service data to multiple other CSPs.
Distributed Registries: refers to multiple Registries managing the
same numbering resource. Actors could interact with one or
multiple Registries. The Registries would update each other when
change occurs. The challenge is to ensure there are no clashes,
e.g., two Registries assigning the same TN to two different
actors.
3. Framework
The framework outlined in this document requires three Internet-based
mechanisms for managing and resolving telephone numbers (TNs) in an
IP environment. These mechanisms will likely reuse existing
protocols for sharing structured data; it is unlikely that new
protocol development work will be required, though new information
models specific to the data itself will be a major focus of framework
development. Likely candidates for reuse here include work done in
DRINKS and WEIRDS, as well as the TeRI [12] framework.
These protocol mechanisms are scoped in a way that makes them likely
to apply to a broad range of future policies for number
administration. It is not the purpose of this framework to dictate
number policy, but instead to provide tools that will work with
policies as they evolve going forward. These mechanisms therefore do
not assume that number administration is centralized, nor that number
"ownership" is restricted to any privileged service providers, though
these tools must and will work in environments with those properties.
The three mechanisms are:
Acquisition: a protocol mechanism for acquiring TNs, including an
enrollment process.
Management: a protocol mechanism for associating data with TNs.
Retrieval: a protocol mechanism for retrieving data about TNs.
The acquisition mechanism will enable actors to acquire TNs for use
with a communications service. The acquisition mechanism will
Peterson & McGarry Expires August 28, 2016 [Page 7]
Internet-Draft Modern Problems February 2016
provide a means to request numbering resources from a service
operated by a Registry, CSP or similar actor. TNs may be requested
either on a number-by-number basis, or as inventory blocks. Any
actor who grants numbering resources will retain metadata about the
assignment, including the responsible organization or individual to
whom numbers have been assigned.
The management mechanism will let actors provision data associated
with TNs. For example, if a User has been assigned a TN, they may
select a CSP to provide a particular service associated with the TN,
or a CSP may assign a TN to a User upon service activation. In
either case, a mechanism is needed to provision data associated with
the TN at that CSP.
The retrieval mechanism will enable actors to learn information about
TNs, typically by sending a request to a CSP. For some information,
an actor may need to send a request to a Registry rather than a CSP.
Different parties may be authorized to receive different information
about TNs.
4. Use Cases
The high-level use cases in this section will provide an overview of
the expected operation of the three interfaces in the MODERN problem
space.
4.1. Acquisition
There are various scenarios for how TNs can be acquired by the
relevant actors: a Registry, CSP, Service Enabler, or User. There
are three actors from which numbers can be acquired: a Registry, a
CSP and a User (presumably one who is delegating to another party).
In these use cases, a User may acquire TNs either from a CSP or a
Registry, or from an intermediate delegate.
4.1.1. CSP Acquires TNs from Registry
The most fundamental and traditional numbering use case is one where
a CSP, such as a carrier, requests a block of numbers from a Registry
to hold as inventory or assign to customers.
Through some out-of-band business process, a CSP develops a
relationship with a Registry. The Registry maintains a profile of
the CSP and what qualifications they possess for requesting TNs. The
CSP may then request TNs from within a specific pool of numbers in
the authority of the Registry; such as region, mobile, wireline,
tollfree, etc. The Registry must authenticate and authorize the CSP,
and then either grant or deny a request. When an assignment occurs,
Peterson & McGarry Expires August 28, 2016 [Page 8]
Internet-Draft Modern Problems February 2016
the Registry creates and stores administrative information related to
the assignment such as TN status and contact information, and removes
the specific TN(s) from the pool of those that are available for
assignment. As a part of the acqusition and assignment process, the
Registry provides any necessary credentials (for example, STIR
certificates [13]) to the CSP to be used to prove the assignment for
future transactions.
Before it is eligible to receive TN assignments, per the policy of a
national authority, the CSP may need to have submitted (again,
through some out-of-band process) additional qualifying information
such as current utilization rate or a demand forecast.
There are two scenarios under which a CSP requests resources; they
are requesting inventory, or they are requesting for a specific User
or delegate. TNs assigned to a User are always considered assigned
by the Registry, not inventory. In this use case, after receiving a
number assignment from the Registry, a User will then obtain
communications service from a CSP, and provide to the CSP the TN to
be used for that service along with the credential. The CSP will
associate service information for that TN, e.g., service address, and
make it available to other CSPs to enable interoperability. The CSP
may need to update the Registry regarding this service activation
(this is part of the "TN status" maintained by the Registry).
4.1.2. User Acquires TNs from CSP
Today, a User typically acquires a TN from CSP when signing up for
communications service or turning on a new device. In this use case,
the User becomes the delegate of the CSP.
A User creates or has a relationship with the CSP, and subscribes to
a communications service which includes the use of a TN. The CSP
collects and stores administrative data about the User. The CSP then
activates the User on their network and creates any necessary service
data to enable interoperability with other CSPs. The CSP could also
update public or privileged databases accessible by other Actors.
The CSP provides any necessary credentials to the User (for example,
a STIR certificate [13]) to prove the assignment for future
transactions. Such credential could be delegated from the one
provided by the Registry to the CSP to continue the chain of
assignment.
The CSP could assign a TN from its existing inventory or it could
acquire a new TN from the Registry as part of the assignment process.
If it assigns it from its existing inventory it would remove the
specific TN from the pool of those available for assignment. It may
Peterson & McGarry Expires August 28, 2016 [Page 9]
Internet-Draft Modern Problems February 2016
also update the Registry about the assignment so the Registry has
current assignment data.
4.1.3. CSP Delegates TNs to Another CSP
A reseller or a service bureau might acquire a block of numbers from
a CSP to be issued to Users.
In this case, the delegate CSP has a business relationship with the
assignee CSP. The assignee CSP collects and stores administrative
data about the delegate. The assignee then activates the delegate on
their network and creates any necessary service data to enable
interoperability with other CSPs. The CSP could also update public
or privileged databases accessible by other Actors. The CSP provides
any necessary credentials to the delegate CSP (for example, a STIR
certificate [13]) to prove the assignment for future transactions.
Such credentials could be delegated from the one provided by the
Registry to the CSP to continue the chain of assignment.
The CSP could assign a block from its existing inventory or it could
acquire new TNs from the Registry as part of the assignment process.
If it assigns it from its existing inventory it would remove the
specific TN from the pool of those available for assignment. It may
also update the Registry about the assignment so the Registry has
current assignment data. The Delegate may need to provide
utilization and assignment data to the Registry, either directly or
through the CSP.
4.1.4. User Acquires TNs from a Delegate
Aquiring a TN from a delegate follows the process in Section 4.1.2,
as it should be similar to how a User acquires TNs from a CSP. In
this case, the delegate re-delegating the TNs would be performing
functions done by the CSP, e.g., providing any credentials,
collecting administrative data, creative service data, and so on.
4.1.5. User Acquires Numbers from Registry
Today, typically Users do not have the capability to request
numbering resources directly from a Registry. MODERN supports this
use case, for those Numbering Authorities and Registries that might
establish policies enabling this use case in the future.
Acquiring a TN from a Registry follows the process in Section 4.1.1,
as it should be similar to how a CSP acquires TNs from a Registry.
In this case, the User must establish some business relationship
directly to a Registry, perhaps similarly to how such functions are
conducted today when Users purchase domain names. For the purpose of
Peterson & McGarry Expires August 28, 2016 [Page 10]
Internet-Draft Modern Problems February 2016
status information kept by the Registry, TNs assigned to a User are
always considered assigned, not inventory.
In this use case, after receiving a number assignment from the
Registry, a User will then obtain communications service from a CSP,
and provide to the CSP the TN to be used for that service. The CSP
will associate service information for that TN, e.g., service
address, and make it available to other CSPs to enable
interoperability.
4.2. Management
The management protocol mechanism is needed to associate
administrative and service data with TNs, and may be used to refresh
or rollover associated credentials.
4.2.1. Management of Administrative Data
Administrative data is primarily related to the status of the TN, its
administrative contacts, and the actors involved in providing service
to the TN. Protocol interactions for administrative data will
therefore predominantly occur between CSPs and Users to the Registry,
or between Users and delegate CSPs to the CSP.
Most administrative data is not a good candidate for a distributed
data store model. Access to it does not require real-time
performance therefore local caches are not necessary. And it will
include sensitive information such as user and contact data.
Some of the data could lend itself to being publicly available, such
as CSP and TN assignment status. In that case it would be deemed
public information for the purposes of the retrieval interface.
4.2.1.1. CSP to Registry
After a CSP acquires a TN or block of TNs from the Registry (per
Section 4.1.1 above), it then provides administrative data to the
Registry as a step in the acquisition process. The Registry will
authenticate the CSP and determine if the CSP is authorized to
provision the administrative data for the TNs in question. The
Registry will update the status of the TN, i.e., that it is
unavailable for assignment. The Registry will also maintain
administrative data provided by the CSP.
Changes to this administrative data will not be frequent. Examples
of changes would be terminating service (see Section 4.2.3.2) and
changing a CSP or delegate. Changes should be authenticated by a
credential to prove administrative responsibility for the TN.
Peterson & McGarry Expires August 28, 2016 [Page 11]
Internet-Draft Modern Problems February 2016
In a distributed Registry model, TN status, e.g., allocated,
assigned, available, unavailable, would need to be provided to other
Registries in real-time. Other administrative data could be sent to
all Registries or other Registries could get a reference address to
the host Registry's data store.
4.2.1.2. User to CSP
After a User acquires a TN or block of TNs from a CSP, the User will
provide administrative data to the CSP. The CSP could maintain the
data and only notify the Registry of the change in TN status. In
this case, the Registry may maintain a reference address to the CSP's
administrative data store so relevant actors have the ability to
access the data. Alternatively they could send the data to the
Registry to store. If there is a delegate between the CSP and user,
they will have to ensure there is a mechanism for the delegate to
update the CSP as change occurs.
4.2.1.3. User to Registry
If the User has a direct relationship with the Registry, then
naturally the user could could provision administrative data
associated with their TN directly to the Registry. While delegates
necessarily are not assignees, some environments as an optimization
might want to support a model where the delegate updates the Registry
directly on changes, as opposed to sending that data to the CSP or
through the CSP to the Registry. As stated already, the protocol
should enable Users to acquire TNs directly from a Registry and in
essence act as their own CSP. In these cases the updates would be
similar to that described in Section 4.2.1.1.
4.2.2. Management of Service Data
Service data is data required by an originating or intermediate CSP
to enable communications service to the delegate or User: a SIP URI
is an example of one service data element commonly used to route
communications. CSPs typically create and manage service data,
however it is possible that delegates and Users could as well. For
most use cases involving individual Users, it is anticipated that
lower-level service information changes would be communicated to CSPs
via existing protocols (like the baseline [2] SIP REGISTER method)
rather than through any new interfaces defined by MODERN.
4.2.2.1. CSP to other CSPs
After a User enrolls for service with a CSP, in the case where the
CSP was assigned the TN by a Registry, the CSP will then create a
service address (such as a SIP URI) and associate it with the TN.
Peterson & McGarry Expires August 28, 2016 [Page 12]
Internet-Draft Modern Problems February 2016
The CSP needs to update this data to enable service interoperability.
There are multiple ways that this update can occur, though most
commonly service data is exposed through the retrieval interface (see
Section 4.3. For certain deployment architectures, like a
distributed data store model, CSPs may need to provide data directly
to other CSPs.
If the CSP is assigning a TN from its own inventory it may not need
to perform service data updates as change occurs because the existing
service data associated with inventory may be sufficient once the TN
is put in service. They would however likely update the Registry on
the change in status.
4.2.2.2. User to CSP
Users could also associate service data to their TNs at the CSP. An
example is a User acquires a TN from the Registry (as described in
Section 4.1.5) and wants to provide that TN to the CSP so the CSP can
enable service. In this case, once the user provides the number to
the CSP, the CSP would update the Registry or other actors as
outlined in Section 4.2.2.1.
4.2.3. Managing Change
This section will address some special use cases that were not
covered in other sections of 4.2.
4.2.3.1. Changing the CSP for an Existing Communications Service
A User who subscribes to a communications service, and received their
TN from that CSP, wishes to retain the same TN but move their service
to a different CSP. The User provides their credential to the new
CSP and the CSP initiates the change in service.
In the simplest scenario, where there's an authoritative Registry
that maintains service data, the new CSP provides the new service
data with the User's credential to the Registry and the Registry
makes the change. The old credential is revoked and a new one is
provided. The new CSP or Registry would send a notification to the
old CSP, so they can disable service. The old CSP will undo any
delegations to the User, including invalidating any cryptographic
credentials (e.g. STIR certificates [13]) previously granted to the
User. Any service data maintained by the CSP must be removed, and
similarly, the CSP must delete any such information it provisioned in
the Registry.
Peterson & McGarry Expires August 28, 2016 [Page 13]
Internet-Draft Modern Problems February 2016
In a similar model that is common practice in some environments
today, the User could provide their credential to the old CSP, and
the old CSP initiates the change in service.
If there was a distributed Registry that maintained service data, the
Registry would also have to update the other Registries of the
change.
If there was a distributed data store the new CSP would have to
update all the other CSPs including the old CSP of the new service
data. In this model both CSPs would have to have the ability to
update all of the same CSPs. That is the new CSP would have to make
sure all of the CSPs provisioned by the old CSP get the updated
service data.
[TBD - more on the case where multiple CSPs provide services for a
given TN, and only one service is "ported" to a new CSP?]
4.2.3.2. Terminating a Service
A User who subscribes to a communications service, and received their
TN from the CSP, wishes to terminate their service. At this time,
the CSP will undo any delegations to the User, including invalidating
any cryptographic credentials (e.g. STIR certificates [13])
previously granted to the User. Any service data maintained by the
CSP must be removed, and similarly, the CSP must delete any such
information it provisioned in the Registry.
The TN will change state from assigned to unassigned, the CSP will
update the Registry. Depending on policies the TN could go back into
the Registry, CSP, or delegate's pool of available TNs and would
likely enter an aging process.
In an alternative use case, a User who received their own TN
assignment directly from the Registry terminates their service with a
CSP. At this time, the User might terminate their assignment from
the Registry, and return the TN to the Registry for re-assignment.
Alternatively, they could retain the TN and elect to assign it to
some other service at a later time.
4.3. Retrieval
Retrieval of administrative or service data will be subject to access
restrictions based on the category of the specific data; public,
semi-restricted or restricted. Both administrative and service data
can have data elements that fall into each of these categories. It
is expected that the majority of administrative and service data will
fall into the semi-restricted category: access to this information
Peterson & McGarry Expires August 28, 2016 [Page 14]
Internet-Draft Modern Problems February 2016
may require some form of authorization, though service data crucial
to reachability will need to be accessible. In some environments,
it's possible that none of the service data will be considered
public.
The retrieval protocol mechanism for semi-restricted and restricted
data needs a way for the receiver of the request to identify the
originator of the request and what is being requested. The receiver
of the request will process that request based on this information.
4.3.1. Retrieval of Public Data
Under most circumstances, a CSP wants its communications service to
be publicly reachable through TNs, so the retrieval interface
supports public interfaces that permit clients to query for service
data about a TN. Some service data may however require that the
client by authorized to receive it, per the use case in Section 4.3.3
below.
Public data can simply be posted on websites or made available
through a publicly available API. Public data hosted by a CSP may
have a reference address at the Registry.
4.3.2. Retrieval of Semi-restricted Administrative Data
A CSP is having service problems completing calls to a specific TN,
so it wants to contact the CSP serving that TN. The Registry
authorizes the originating CSP to access to this information. It
initiates a query to the Registry, the Registry verifies the
requestor and the requested data and Registry responds with the
serving CSP and contact data.
Alternatively that information could be part of a distributed data
store and not stored at the Registry. In that case, the CSP has the
data in a local distributed data store and it initiates the query to
the local data store. The local data store responds with the CSP and
contact data. No verification is necessary because it was done when
the CSP was authorized to receive the data store.
4.3.3. Retrieval of Semi-restricted Service Data
A User on a CSP's network calls a TN. The CSP initiates a query for
service data associated with the TN to complete the call, and will
receive special service data because the CSP operates in a closed
environment where different CSPs receive different responses, and
only authorized CSPs may access service data. The query and response
must have real-time performance. There are multiple scenarios for
the query and response.
Peterson & McGarry Expires August 28, 2016 [Page 15]
Internet-Draft Modern Problems February 2016
In a distributed data store model each CSP distributes its updated
service data to all other CSPs. The originating CSP has the service
data in its local data store and queries it. The local data store
responds with the service data. The service data can be a reference
address to a data store maintained by the serving CSP or it can be
the service address itself. In the case where it's a reference
address the query would go to the serving CSP and they would verify
the requestor and the requested data and respond. In the case where
it's the service address it would process the call using that.
In some environments, aspects of the service data may reside at the
Registry itself (for example, the assigned CSP for a TN), and thus a
the query may be sent to the Registry. The Registry verifies the
requestor and the requested data and responds with the service data,
such as a SIP URI containing the domain of the assigned CSP.
4.3.4. Retrieval of Restricted Data
In this case, a Government Entity wishes to access information about
a particular User, who subscribes to a communications service. The
entity that operates the Registry on behalf of the National Authority
in this case has some pre-defined relationship with the Government
Entity. When the CSP acquired TNs from the National Authority, it
was a condition of that assignment that the CSP provide access for
Government Entities to telephone numbering data when certain
conditions apply. The required data may reside either in the CSP or
in the Registry.
For a case where the CSP delegates a number to the User, the CSP
might provision the Registry with information relevant to the User.
At such a time as the Government Entity needs information about that
User, the Government Entity may contact the Registry or CSP to
acquire the necessary data. The interfaces necessary for this will
be the same as those described in Section 4.3; the Government Entity
will be authenticated, and an authorization decision will be made by
the Registry or CSP under the policy dictates established by the
National Authority.
5. Distributed Registries and Data Stores
It is possible to create a distributed Registry or distributed Data
Stores for the administrative and service information associated with
a TN.
In a distributed Registry there would be multiple duplicate copies of
the Registry data. A CSP or User would interact with one Registry
and that Registry would be responsible for initiating updates to all
other Registries when there is a change. The challenge is to ensure
Peterson & McGarry Expires August 28, 2016 [Page 16]
Internet-Draft Modern Problems February 2016
that there are no clashes, e.g., two Registries assigning the same TN
to two different CSPs.
Similarly multiple entities can maintain duplicate copies of
administrative and service data associated with TNs. For example,
when a CSP enables service for a User they can initiate an update of
the service address to multiple other data stores managed by other
service providers. This may not be the best solution for User
contact data.
[More TBD]
6. Acknowledgments
We would like to thank Henning Schulzrinne for his contributions to
this problem statement and framework, and to thank Pierce Gorman for
detailed comments.
7. IANA Considerations
This memo includes no instructions for the IANA.
8. Security Considerations
The acquisition, management, and retrieval of administrative and
service data associated with telephone numbers raises a number of
security issues.
Any mechanism that allows an individual or organization to acquire
telephone numbers will require a means of mutual authentication, of
integrity protection, and of confidentiality. A Registry as defined
in this document will surely want to authenticate the source of an
acquisition request as a first step in the authorization process to
determine whether or not the resource will be granted. Integrity of
both the request and response is essential to ensuring that tampering
does not allow attackers to block acquisitions, or worse, to
commandeer resources. Confidentiality is essential to preventing
eavesdroppers from learning about allocations, including the
personally identifying information associated with the administrative
or technical contracts for allocations.
A management interface for telephone numbers has similar
requirements. Without proper authentication and authorization
mechanisms in place, an attack could use the management interface to
disrupt service data or administrative data, which could deny service
to users, enable new impersonation attacks, prevent billing systems
from operating properly, and cause similar system failures.
Peterson & McGarry Expires August 28, 2016 [Page 17]
Internet-Draft Modern Problems February 2016
Finally, a retrieval interfaces has its own needs for mutual
authentication, integrity protection, and for confidentiality. Any
CSP sending a request to retrieve service data associated with a
number will want to know that it is reaching the proper authority,
that the response from that authority has not been tampered with in
transit, and in most cases the CSP will not want to reveal to
eavesdroppers the number it is requesting or the response that it has
received. Similarly, any service answering such a query will want to
have a means of authenticating the source of the query, and of
protecting the integrity and confidentiality of its responses.
9. Informative References
[1] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006,
<http://www.rfc-editor.org/info/rfc4474>.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[3] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116,
DOI 10.17487/RFC6116, March 2011,
<http://www.rfc-editor.org/info/rfc6116>.
[4] Channabasappa, S., Ed., "Data for Reachability of Inter-
/Intra-NetworK SIP (DRINKS) Use Cases and Protocol
Requirements", RFC 6461, DOI 10.17487/RFC6461, January
2012, <http://www.rfc-editor.org/info/rfc6461>.
[5] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002,
<http://www.rfc-editor.org/info/rfc3324>.
[6] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002,
<http://www.rfc-editor.org/info/rfc3325>.
Peterson & McGarry Expires August 28, 2016 [Page 18]
Internet-Draft Modern Problems February 2016
[7] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>.
[8] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
2007, <http://www.rfc-editor.org/info/rfc4916>.
[9] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004,
<http://www.rfc-editor.org/info/rfc3966>.
[10] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039,
January 2008, <http://www.rfc-editor.org/info/rfc5039>.
[11] Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP) and the Real-
time Applications and Infrastructure Area", BCP 67,
RFC 5727, DOI 10.17487/RFC5727, March 2010,
<http://www.rfc-editor.org/info/rfc5727>.
[12] Peterson, J., "A Framework and Information Model for
Telephone-Related Information (TeRI)", draft-peterson-
modern-teri-00 (work in progress), October 2015.
[13] Peterson, J., "Secure Telephone Identity Credentials:
Certificates", draft-ietf-stir-certificates-02 (work in
progress), July 2015.
[14] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
Huguenin, "Verification Involving PSTN Reachability:
Requirements and Architecture Overview", draft-jennings-
vipr-overview-06 (work in progress), December 2013.
[15] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
DOI 10.17487/RFC3263, June 2002,
<http://www.rfc-editor.org/info/rfc3263>.
Authors' Addresses
Peterson & McGarry Expires August 28, 2016 [Page 19]
Internet-Draft Modern Problems February 2016
Jon Peterson
Neustar, Inc.
1800 Sutter St Suite 570
Concord, CA 94520
US
Email: jon.peterson@neustar.biz
Tom McGarry
Neustar, Inc.
1800 Sutter St Suite 570
Concord, CA 94520
US
Email: tom.mcgarry@neustar.biz
Peterson & McGarry Expires August 28, 2016 [Page 20]