draft-ietf-modern-problem-framework-03.txt   draft-ietf-modern-problem-framework-04.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft T. McGarry Internet-Draft T. McGarry
Intended status: Informational NeuStar, Inc. Intended status: Informational NeuStar, Inc.
Expires: January 4, 2018 July 3, 2017 Expires: September 6, 2018 March 5, 2018
Modern Problem Statement, Use Cases, and Framework Modern Problem Statement, Use Cases, and Framework
draft-ietf-modern-problem-framework-03.txt draft-ietf-modern-problem-framework-04.txt
Abstract Abstract
The functions of the public switched telephone network (PSTN) are The functions of the public switched telephone network (PSTN) are
rapidly migrating to the Internet. This is generating new rapidly migrating to the Internet. This is generating new
requirements for many traditional elements of the PSTN, including requirements for many traditional elements of the PSTN, including
telephone numbers (TNs). TNs no longer serve simply as telephone telephone numbers (TNs). TNs no longer serve simply as telephone
routing addresses: they are now identifiers which may be used by routing addresses: they are now identifiers which may be used by
Internet-based services for a variety of purposes including session Internet-based services for a variety of purposes including session
establishment, identity verification, and service enablement. This establishment, identity verification, and service enablement. This
skipping to change at page 1, line 33 skipping to change at page 1, line 33
services relying on TNs. services relying on TNs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 2, line 26 skipping to change at page 2, line 26
2.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Data Management Architectures . . . . . . . . . . . . . . 8 2.3. Data Management Architectures . . . . . . . . . . . . . . 8
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Acquiring TNs from Registrar . . . . . . . . . . . . 12 4.1.1. Acquiring TNs from Registrar . . . . . . . . . . . . 12
4.1.2. Acquiring TNs from CSPs . . . . . . . . . . . . . . . 13 4.1.2. Acquiring TNs from CSPs . . . . . . . . . . . . . . . 13
4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Management of Administrative Data . . . . . . . . . . 14 4.2.1. Management of Administrative Data . . . . . . . . . . 14
4.2.1.1. Managing Data at a Registrar . . . . . . . . . . 14 4.2.1.1. Managing Data at a Registrar . . . . . . . . . . 14
4.2.1.2. Mangaing Data at a CSP . . . . . . . . . . . . . 15 4.2.1.2. Managing Data at a CSP . . . . . . . . . . . . . 15
4.2.2. Management of Service Data . . . . . . . . . . . . . 15 4.2.2. Management of Service Data . . . . . . . . . . . . . 15
4.2.2.1. CSP to other CSPs . . . . . . . . . . . . . . . . 15 4.2.2.1. CSP to other CSPs . . . . . . . . . . . . . . . . 15
4.2.2.2. User to CSP . . . . . . . . . . . . . . . . . . . 16 4.2.2.2. User to CSP . . . . . . . . . . . . . . . . . . . 16
4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 16 4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 16
4.2.3.1. Changing the CSP for an Existing Service . . . . 16 4.2.3.1. Changing the CSP for an Existing Service . . . . 16
4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 17 4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 17
4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 18 4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 18
4.3.2. Retrieval of Semi-restricted Administrative Data . . 18 4.3.2. Retrieval of Semi-restricted Administrative Data . . 18
4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 18 4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 18
4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 19 4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 19
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
8. Informative References . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Problem Statement 1. Problem Statement
The challenges of utilizing telephone numbers (TNs) on the Internet The challenges of utilizing telephone numbers (TNs) on the Internet
have been known for some time. Internet telephony provided the first have been known for some time. Internet telephony provided the first
use case for routing telephone numbers on the Internet in a manner use case for routing telephone numbers on the Internet in a manner
similar to how calls are routed in the public switched telephone similar to how calls are routed in the public switched telephone
network (PSTN). As the Internet had no service for discovering the network (PSTN). As the Internet had no service for discovering the
endpoints associated with telephone numbers, ENUM [3] created a DNS- endpoints associated with telephone numbers, ENUM [3] created a DNS-
skipping to change at page 4, line 4 skipping to change at page 4, line 5
technology and policies dictate that this be an exception process technology and policies dictate that this be an exception process
fraught with problems and delays. Originally, processes were built fraught with problems and delays. Originally, processes were built
to associate a specific TN to a specific service provider and never to associate a specific TN to a specific service provider and never
change it. With number portability, the industry had to build new change it. With number portability, the industry had to build new
infrastructure, new administrative functions and processes to change infrastructure, new administrative functions and processes to change
the association of the TN from one service provider to another. the association of the TN from one service provider to another.
Thanks to the increasing sophistication of consumer mobile devices as Thanks to the increasing sophistication of consumer mobile devices as
Internet endpoints as well as telephones, users now associate TNs Internet endpoints as well as telephones, users now associate TNs
with many Internet applications other than telephony. This has with many Internet applications other than telephony. This has
generated new interest in models similar to those in place for generated new interest in models similar to those in place for
administering freephone services in the United States, where a user administering freephone (non-geographic toll free numbers) services
purchases a number through a sort of number registrar and controls in the United States, where a user purchases a number through a sort
its administration (such as routing) on their own, typically using of number registrar and controls its administration (such as routing)
Internet services to directly make changes to the service associated on their own, typically using Internet services to directly make
with telephone numbers. changes to the service associated with telephone numbers.
Most TNs today are assigned to specific geographies, at both an Most TNs today are assigned to specific geographies, at both an
international level and within national numbering plans. Numbering international level and within national numbering plans. Numbering
practices today are tightly coupled with the manner that service practices today are tightly coupled with the manner that service
providers interconnect, as well as how TNs are routed and providers interconnect, as well as how TNs are routed and
administered: the PSTN was carefully designed to delegate switching administered: the PSTN was carefully designed to delegate switching
intelligence geographically. In interexchange carrier routing in intelligence geographically. In interexchange carrier routing in
North America, for example, calls to a particular TN are often handed North America, for example, calls to a particular TN are often handed
off to the terminating service provider close to the geography where off to the terminating service provider close to the geography where
that TN is assigned. But the overwhelming success of mobile that TN is assigned. But the overwhelming success of mobile
skipping to change at page 4, line 30 skipping to change at page 4, line 31
regions. Furthermore, the topology of IP networks is not anchored to regions. Furthermore, the topology of IP networks is not anchored to
geography in the same way that the telephone network is. In an geography in the same way that the telephone network is. In an
Internet environment, establishing a network architecture for routing Internet environment, establishing a network architecture for routing
TNs could depend little on geography, relying instead on network TNs could depend little on geography, relying instead on network
topologies or other architectural features. Adapting TNs to the topologies or other architectural features. Adapting TNs to the
Internet requires more security, richer datasets and more complex Internet requires more security, richer datasets and more complex
query and response capabilities than previous efforts have provided. query and response capabilities than previous efforts have provided.
This document attempts to create a common understanding of the This document attempts to create a common understanding of the
problem statement related to allocating, managing, and resolving TNs problem statement related to allocating, managing, and resolving TNs
in an IP environment. It outlines a framework and lists motivating in an IP environment, the focus of the IETF MODERN (Managing,
use cases for creating IP-based mechanisms for TNs. It is important Ordering, Distributing, Exposing, and Registering telephone Numbers)
to acknowledge at the outset that there are various evolving working group. It outlines a framework and lists motivating use
cases for creating IP-based mechanisms for TNs. It is important to
acknowledge at the outset that there are various evolving
international and national policies and processes related to TNs, and international and national policies and processes related to TNs, and
any solutions need to be flexible enough to account for variations in any solutions need to be flexible enough to account for variations in
policy and requirements. policy and requirements.
2. Definitions 2. Definitions
This section provides definitions for actors, data types and data This section provides definitions for actors, data types and data
management architectures as they are discussed in this document. management architectures as they are discussed in this document.
Different numbering spaces may instantiate these roles and concepts Different numbering spaces may instantiate these roles and concepts
differently: practices that apply to non-geographic freephone differently: practices that apply to non-geographic freephone
skipping to change at page 5, line 9 skipping to change at page 5, line 9
practices that exist under one Numbering Authority may not be practices that exist under one Numbering Authority may not be
permitted under another. The purpose of this framework is to permitted under another. The purpose of this framework is to
identify the characteristics of protocol tools that will satisfy the identify the characteristics of protocol tools that will satisfy the
diverse requirements for telephone number acquisition, management, diverse requirements for telephone number acquisition, management,
and retrieval on the Internet. and retrieval on the Internet.
2.1. Actors 2.1. Actors
The following roles of actors are defined in this document: The following roles of actors are defined in this document:
Numbering Authority: A regulatory body within a country that manages Numbering Authority: A regulatory body within a region that manages
that country's TNs. The Numbering Authority decides national that regions TNs. The Numbering Authority decides national
numbering policy for the nation, region, or other domain for which numbering policy for the nation, region, or other domain for which
it has authority, including what TNs can be allocated, which are it has authority, including what TNs can be allocated, which are
reserved, and which entities may obtain TNs. reserved, and which entities may obtain TNs.
Registry: An entity that administers the allocation of TNs based on Registry: An entity that administers the allocation of TNs based on
a Numbering Authority's policies. Numbering authorities can act a Numbering Authority's policies. Numbering authorities can act
as the Registries themselves, or they can outsource the function as the Registries themselves, or they can outsource the function
to other entities. Traditional registries are single entities to other entities. Traditional registries are single entities
with sole authority and responsibility for specific numbering with sole authority and responsibility for specific numbering
resources, though distributed registries (see Section 2.3) are resources, though distributed registries (see Section 2.3) are
skipping to change at page 6, line 30 skipping to change at page 6, line 30
Assignee: An actor that is assigned a TN directly by a Registrar; an Assignee: An actor that is assigned a TN directly by a Registrar; an
assignee always has a direct relationship with a Registrar. assignee always has a direct relationship with a Registrar.
Delegate: An actor that is delegated a TN from an assignee or Delegate: An actor that is delegated a TN from an assignee or
another delegate, who does not necessarily have a direct another delegate, who does not necessarily have a direct
relationship with a Registrar. Delegates may delegate one or more relationship with a Registrar. Delegates may delegate one or more
of their TN assignment(s) to one or more further downstream of their TN assignment(s) to one or more further downstream
subdelegates. subdelegates.
As an example, consider a case where a Numbering Authority also acts As an example, consider a case where a Numbering Authority also acts
as a Registry, and it issues 10,000 blocks of TNs to CSPs, which in as a Registry, and it issues blocks of 10,000 TNs to CSPs, which in
this case also act as Registrars. CSP/Registrars would then be this case also act as Registrars. CSP/Registrars would then be
responsible for distributing numbering resources to Users and other responsible for distributing numbering resources to Users and other
CSPs. In this case, an enterprise deploying IP PBXs also acts as a CSPs. In this case, an enterprise deploying IP PBXs also acts as a
CSP, and it acquires number blocks for its enterprise seats in chunks CSP, and it acquires number blocks for its enterprise seats in chunks
of 100 from a CSP acting as a Registrar with whom the enterprise has of 100 from a CSP acting as a Registrar with whom the enterprise has
a business relationship. The enterprise is in this case the a business relationship. The enterprise is in this case the
assignee, as it receives numbering resources directly from a assignee, as it receives numbering resources directly from a
Registrar. As it doles out individual numbers to its Users, the Registrar. As it doles out individual numbers to its Users, the
enterprise delegates its own numbering resources to those Users and enterprise delegates its own numbering resources to those Users and
their communications endpoints. The overall ecosystem might look as their communications endpoints. The overall ecosystem might look as
skipping to change at page 12, line 36 skipping to change at page 12, line 36
the policies of the Numbering Authorities, Registrars may be required the policies of the Numbering Authorities, Registrars may be required
to log these operations. to log these operations.
Before it is eligible to receive TN assignments, per the policy of a Before it is eligible to receive TN assignments, per the policy of a
Numbering Authority, the CSP may need to have submitted (again, Numbering Authority, the CSP may need to have submitted (again,
through some out-of-band process) additional qualifying information through some out-of-band process) additional qualifying information
such as current utilization rate or a demand forecast. such as current utilization rate or a demand forecast.
There are two scenarios under which a CSP requests resources; they There are two scenarios under which a CSP requests resources; they
are requesting inventory, or they are requesting for a specific User are requesting inventory, or they are requesting for a specific User
or delegate. TNs assigned to a User are always considered assigned, or delegate. For the purpose of status information, TNs assigned to
not inventory. The CSP will associate service information for that a User are always considered assigned, not inventory. The CSP will
TN, e.g., service address, and make it available to other CSPs to associate service information for that TN, e.g., service address, and
enable interconnection. The CSP may need to update the Registrar make it available to other CSPs to enable interconnection. The CSP
regarding this service activation; this is part of the "TN status" may need to update the Registrar regarding this service activation;
maintained by the Registrar. this is part of the "TN status" maintained by the Registrar.
There are also use cases in which a User can acquire a TN directly There are also use cases in which a User can acquire a TN directly
from a Registrar. Today, a user wishing to acquire a freephone from a Registrar. Today, a user wishing to acquire a freephone
number may browse the existing inventory through one or more number may browse the existing inventory through one or more
Registrars, comparing their prices and services. Each such Registrar Registrars, comparing their prices and services. Each such Registrar
either is a CSP, or has a business relationship with one or more CSPs either is a CSP, or has a business relationship with one or more CSPs
to provide services for that freephone number. In this case, the to provide services for that freephone number. In this case, the
User must establish some business relationship directly with a User must establish some business relationship directly with a
Registrar, similarly to how such functions are conducted today when Registrar, similarly to how such functions are conducted today when
Users purchase domain names. For the purpose of status information Users purchase domain names. In this use case, after receiving a
kept by the Registry, TNs assigned to a User are always considered number assignment from the Registrar, a User will then obtain
assigned, not inventory.In this use case, after receiving a number communications service from a CSP, and provide to the CSP the TN to
assignment from the Registrar, a User will then obtain communications be used for that service. The CSP will associate service information
service from a CSP, and provide to the CSP the TN to be used for that for that TN, e.g., service address, and make it available to other
service. The CSP will associate service information for that TN, CSPs to enable interconnection. The user will also need to inform
e.g., service address, and make it available to other CSPs to enable the Registrar about this relationship.
interconnection. The user will also need to inform the Registrar
about this relationship.
4.1.2. Acquiring TNs from CSPs 4.1.2. Acquiring TNs from CSPs
Today, a User typically acquires a TN from CSP when signing up for 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, communications service or turning on a new device. In this use case,
the User becomes the delegate of the CSP. A reseller or a service the User becomes the delegate of the CSP. A reseller or a service
bureau might also acquire a block of numbers from a CSP to be issued bureau might also acquire a block of numbers from a CSP to be issued
to Users. to Users.
Consider a case where a User creates or has a relationship with the Consider a case where a User creates or has a relationship with the
skipping to change at page 15, line 20 skipping to change at page 15, line 17
directly from a Registrar, which Registrar may or may not also act as directly from a Registrar, which Registrar may or may not also act as
a CSP. In these cases the updates would be similar to that described a CSP. In these cases the updates would be similar to that described
in Section 4.2.1.1. in Section 4.2.1.1.
In a distributed Registry model, TN status, e.g., allocated, In a distributed Registry model, TN status, e.g., allocated,
assigned, available, unavailable, would need to be provided to other assigned, available, unavailable, would need to be provided to other
Registries in real-time. Other administrative data could be sent to Registries in real-time. Other administrative data could be sent to
all Registries or other Registries could get a reference address to all Registries or other Registries could get a reference address to
the host Registry's data store. the host Registry's data store.
4.2.1.2. Mangaing Data at a CSP 4.2.1.2. Managing Data at a CSP
After a User acquires a TN or block of TNs from a CSP, the User will After a User acquires a TN or block of TNs from a CSP, the User will
provide administrative data to the CSP. The CSP commonly acts as a provide administrative data to the CSP. The CSP commonly acts as a
Registrar in this case, maintaining the administrative data and only Registrar in this case, maintaining the administrative data and only
notifies the Registry of the change in TN status. In this case, the notifies the Registry of the change in TN status. In this case, the
Registry maintains a reference address (see Section 2.3) to the CSP/ Registry maintains a reference address (see Section 2.3) to the CSP/
Registrar's administrative data store so relevant actors have the Registrar's administrative data store so relevant actors have the
ability to access the data. Alternatively, a CSP could send the ability to access the data. Alternatively, a CSP could send the
administrative data to an external Registrar to store. If there is a administrative data to an external Registrar to store. If there is a
delegate between the CSP and user, they will have to ensure there is delegate between the CSP and user, they will have to ensure there is
skipping to change at page 17, line 5 skipping to change at page 16, line 48
data with the User's credential to the Registry/Registrar, which then data with the User's credential to the Registry/Registrar, which then
makes the change. The old credential is revoked and a new one is makes the change. The old credential is revoked and a new one is
provided. The new CSP or the Registrar would send a notification to provided. The new CSP or the Registrar would send a notification to
the old CSP, so they can disable service. The old CSP will undo any the old CSP, so they can disable service. The old CSP will undo any
delegations to the User, including contacting the Credential delegations to the User, including contacting the Credential
Authority to revoke any cryptographic credentials (e.g., STIR Authority to revoke any cryptographic credentials (e.g., STIR
certificates [17]) previously granted to the User. Any service data certificates [17]) previously granted to the User. Any service data
maintained by the CSP must be removed, and similarly, the CSP must maintained by the CSP must be removed, and similarly, the CSP must
delete any such information it provisioned in the Registry. delete any such information it provisioned in the Registry.
In a similar model to common practice in some environments today, the In a model similar to common practice in environments today, the User
User could alternatively provide their credential to the old CSP, and could alternatively provide their credential to the old CSP, and the
the old CSP initiates the change in service. Or, a User could go old CSP initiates the change in service. Or, a User could go
directly to a Registrar to initiate a port. This framework should directly to a Registrar to initiate a port. This framework should
support all of these potential flows. support all of these potential flows.
Note that in cases with a distributed Registry that maintained Note that in cases with a distributed Registry that maintained
service data, the Registry would also have to update the other service data, the Registry would also have to update the other
Registries of the change. Registries of the change.
4.2.3.2. Terminating a Service 4.2.3.2. Terminating a Service
Consider a case where a user who subscribes to a communications Consider a case where a user who subscribes to a communications
skipping to change at page 18, line 5 skipping to change at page 17, line 50
Retrieval of administrative or service data will be subject to access Retrieval of administrative or service data will be subject to access
restrictions based on the category of the specific data: public, restrictions based on the category of the specific data: public,
semi-restricted or restricted. Both administrative and service data semi-restricted or restricted. Both administrative and service data
can have data elements that fall into each of these categories. It can have data elements that fall into each of these categories. It
is expected that the majority of administrative will fall into the is expected that the majority of administrative will fall into the
semi-restricted category: access to this information may require some semi-restricted category: access to this information may require some
form of authorization, though service data crucial to reachability form of authorization, though service data crucial to reachability
will need to be accessible. In some environments, it's possible that will need to be accessible. In some environments, it's possible that
none of the service data necessary to initiate communications will be none of the service data necessary to initiate communications will be
useful to an entity on the public Internet, say, or that all that useful to an entity on the public Internet, say, or that all that
service data will have dependencies on . service data will have dependencies on the origination point of
calls.
The retrieval protocol mechanism for semi-restricted and restricted The retrieval protocol mechanism for semi-restricted and restricted
data needs a way for the receiver of the request to identify the data needs a way for the receiver of the request to identify the
originator of the request and what is being requested. The receiver originator of the request and what is being requested. The receiver
of the request will process that request based on this information. of the request will process that request based on this information.
4.3.1. Retrieval of Public Data 4.3.1. Retrieval of Public Data
Eithert administrative or service data may be made publicly available Either administrative or service data may be made publicly available
by the authority that generates and provisions it. Under most by the authority that generates and provisions it. Under most
circumstances, a CSP wants its communications service to be publicly circumstances, a CSP wants its communications service to be publicly
reachable through TNs, so the retrieval interface supports public reachable through TNs, so the retrieval interface supports public
interfaces that permit clients to query for service data about a TN. interfaces that permit clients to query for service data about a TN.
Some service data may however require that the client be authorized Some service data may however require that the client be authorized
to receive it, per the use case in Section 4.3.3 below. to receive it, per the use case in Section 4.3.3 below.
Public data can simply be posted on websites or made available Public data can simply be posted on websites or made available
through a publicly available API. Public data hosted by a CSP may through a publicly available API. Public data hosted by a CSP may
have a reference address at the Registry. have a reference address at the Registry.
skipping to change at page 20, line 15 skipping to change at page 20, line 9
5. Acknowledgments 5. Acknowledgments
We would like to thank Henning Schulzrinne and Adam Roach for their We would like to thank Henning Schulzrinne and Adam Roach for their
contributions to this problem statement and framework, and to thank contributions to this problem statement and framework, and to thank
Pierce Gorman for detailed comments. Pierce Gorman for detailed comments.
6. IANA Considerations 6. IANA Considerations
This memo includes no instructions for the IANA. This memo includes no instructions for the IANA.
7. Security Considerations 7. Privacy Considerations
This framework defines two categories of information about telephone
numbers: service data and administrative data. Service data
describes how telephone numbers map to particular services and
devices that provide real-time communication for users. As such,
service data could potentially leak resource locations and even
lower-layer network addresses associated with these services, and in
rare cases, with end-user devices. Administrative data more broadly
characterizes who the administrative entities are behind telephone
numbers, which will often identify CSPs, but in some layers of the
architecture could include personally identifying information (PII),
even WHOIS-style information, about the end users behind identifiers.
This could conceivably encompass the sorts of data that carriers and
similar CSPs today keep about their customers for billing purposes,
like real names and postal addresses. The exact nature of
administrative data is not defined by this framework, and it is
anticipated that the protocols that will perform this function will
be extensible for different use cases, so at this point, it is
difficult to characterize exactly how much PII might end up being
housed by these services.
As such, if an attacker were to compromise the registrar services in
this architecture which maintain administrative data, and in some
cases even service data, this could leak PII about end users. These
interfaces, and the systems that host them, are a potentially
attractive target for hackers and need to be hardened accordingly.
Protocols that are selected to fulfill these functions must provide
the security features described in [Sec Cons].
Finally, this framework recognizes that in many jurisdictions,
certain government agencies have a legal right to access service and
administrative data maintained by CSPs. This access is typically
aimed at identifying the users behind communications identifiers in
order to enforce regulatory policy. Those legal entities already
have the power to access the existing data held by CSPs in many
jurisdictions, though potentially the administrative data associated
with this framework could be richer information.
8. Security Considerations
The acquisition, management, and retrieval of administrative and The acquisition, management, and retrieval of administrative and
service data associated with telephone numbers raises a number of service data associated with telephone numbers raises a number of
security issues. security issues.
Any mechanism that allows an individual or organization to acquire Any mechanism that allows an individual or organization to acquire
telephone numbers will require a means of mutual authentication, of telephone numbers will require a means of mutual authentication, of
integrity protection, and of confidentiality. A Registry as defined integrity protection, and of confidentiality. A Registry as defined
in this document will surely want to authenticate the source of an in this document will surely want to authenticate the source of an
acquisition request as a first step in the authorization process to acquisition request as a first step in the authorization process to
skipping to change at page 21, line 5 skipping to change at page 21, line 36
authentication, integrity protection, and for confidentiality. Any authentication, integrity protection, and for confidentiality. Any
CSP sending a request to retrieve service data associated with a CSP sending a request to retrieve service data associated with a
number will want to know that it is reaching the proper authority, number will want to know that it is reaching the proper authority,
that the response from that authority has not been tampered with in 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 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 eavesdroppers the number it is requesting or the response that it has
received. Similarly, any service answering such a query will want to received. Similarly, any service answering such a query will want to
have a means of authenticating the source of the query, and of have a means of authenticating the source of the query, and of
protecting the integrity and confidentiality of its responses. protecting the integrity and confidentiality of its responses.
8. Informative References 9. Informative References
[1] Peterson, J. and C. Jennings, "Enhancements for [1] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006, DOI 10.17487/RFC4474, August 2006,
<http://www.rfc-editor.org/info/rfc4474>. <https://www.rfc-editor.org/info/rfc4474>.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[3] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to [3] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116, Discovery System (DDDS) Application (ENUM)", RFC 6116,
DOI 10.17487/RFC6116, March 2011, DOI 10.17487/RFC6116, March 2011,
<http://www.rfc-editor.org/info/rfc6116>. <https://www.rfc-editor.org/info/rfc6116>.
[4] Channabasappa, S., Ed., "Data for Reachability of Inter- [4] Channabasappa, S., Ed., "Data for Reachability of Inter-
/Intra-NetworK SIP (DRINKS) Use Cases and Protocol /Intra-NetworK SIP (DRINKS) Use Cases and Protocol
Requirements", RFC 6461, DOI 10.17487/RFC6461, January Requirements", RFC 6461, DOI 10.17487/RFC6461, January
2012, <http://www.rfc-editor.org/info/rfc6461>. 2012, <https://www.rfc-editor.org/info/rfc6461>.
[5] Watson, M., "Short Term Requirements for Network Asserted [5] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002,
<http://www.rfc-editor.org/info/rfc3324>. <https://www.rfc-editor.org/info/rfc3324>.
[6] Jennings, C., Peterson, J., and M. Watson, "Private [6] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002, DOI 10.17487/RFC3325, November 2002,
<http://www.rfc-editor.org/info/rfc3325>. <https://www.rfc-editor.org/info/rfc3325>.
[7] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [7] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[8] Elwell, J., "Connected Identity in the Session Initiation [8] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
2007, <http://www.rfc-editor.org/info/rfc4916>. 2007, <https://www.rfc-editor.org/info/rfc4916>.
[9] Schulzrinne, H., "The tel URI for Telephone Numbers", [9] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004, RFC 3966, DOI 10.17487/RFC3966, December 2004,
<http://www.rfc-editor.org/info/rfc3966>. <https://www.rfc-editor.org/info/rfc3966>.
[10] Rosenberg, J. and C. Jennings, "The Session Initiation [10] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039,
January 2008, <http://www.rfc-editor.org/info/rfc5039>. January 2008, <https://www.rfc-editor.org/info/rfc5039>.
[11] Peterson, J., Jennings, C., and R. Sparks, "Change Process [11] Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP) and the Real- for the Session Initiation Protocol (SIP) and the Real-
time Applications and Infrastructure Area", BCP 67, time Applications and Infrastructure Area", BCP 67,
RFC 5727, DOI 10.17487/RFC5727, March 2010, RFC 5727, DOI 10.17487/RFC5727, March 2010,
<http://www.rfc-editor.org/info/rfc5727>. <https://www.rfc-editor.org/info/rfc5727>.
[12] Newton, A. and S. Hollenbeck, "Registration Data Access [12] Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol (RDAP) Query Format", RFC 7482, Protocol (RDAP) Query Format", RFC 7482,
DOI 10.17487/RFC7482, March 2015, DOI 10.17487/RFC7482, March 2015,
<http://www.rfc-editor.org/info/rfc7482>. <https://www.rfc-editor.org/info/rfc7482>.
[13] Roach, A., "Registration for Multiple Phone Numbers in the [13] Roach, A., "Registration for Multiple Phone Numbers in the
Session Initiation Protocol (SIP)", RFC 6140, Session Initiation Protocol (SIP)", RFC 6140,
DOI 10.17487/RFC6140, March 2011, DOI 10.17487/RFC6140, March 2011,
<http://www.rfc-editor.org/info/rfc6140>. <https://www.rfc-editor.org/info/rfc6140>.
[14] Hollenbeck, S., "Generic Registry-Registrar Protocol [14] Hollenbeck, S., "Generic Registry-Registrar Protocol
Requirements", RFC 3375, DOI 10.17487/RFC3375, September Requirements", RFC 3375, DOI 10.17487/RFC3375, September
2002, <http://www.rfc-editor.org/info/rfc3375>. 2002, <https://www.rfc-editor.org/info/rfc3375>.
[15] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [15] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004, DOI 10.17487/RFC3912, September 2004,
<http://www.rfc-editor.org/info/rfc3912>. <https://www.rfc-editor.org/info/rfc3912>.
[16] Peterson, J., "An Architecture and Information Model for [16] Peterson, J., "An Architecture and Information Model for
Telephone-Related Information (TeRI)", draft-peterson- Telephone-Related Information (TeRI)", draft-peterson-
modern-teri-02 (work in progress), October 2016. modern-teri-03 (work in progress), July 2017.
[17] Peterson, J. and S. Turner, "Secure Telephone Identity [17] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", draft-ietf-stir- Credentials: Certificates", RFC 8226,
certificates-14 (work in progress), May 2017. DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>.
[18] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- [18] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
Huguenin, "Verification Involving PSTN Reachability: Huguenin, "Verification Involving PSTN Reachability:
Requirements and Architecture Overview", draft-jennings- Requirements and Architecture Overview", draft-jennings-
vipr-overview-06 (work in progress), December 2013. vipr-overview-06 (work in progress), December 2013.
[19] Bellur, H. and C. Wendt, "Distributed Registry Protocol", [19] Wendt, C. and H. Bellur, "Distributed Registry Protocol
draft-wendt-modern-drip-01 (work in progress), July 2016. (DRiP)", draft-wendt-modern-drip-02 (work in progress),
July 2017.
[20] Rosenberg, J. and H. Schulzrinne, "Session Initiation [20] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
DOI 10.17487/RFC3263, June 2002, DOI 10.17487/RFC3263, June 2002,
<http://www.rfc-editor.org/info/rfc3263>. <https://www.rfc-editor.org/info/rfc3263>.
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
1800 Sutter St Suite 570 1800 Sutter St Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
 End of changes. 40 change blocks. 
65 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/