| Network Working Group | J. Peterson |
| Internet-Draft | T. McGarry |
| Intended status: Informational | NeuStar, Inc. |
| Expires: September 22, 2016 | March 21, 2016 |
Modern Problem Statement, Use Cases, and Framework
draft-peterson-modern-problems-04.txt
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.
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 September 22, 2016.
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 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.
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 [RFC6116] 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 [RFC3261]. 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 [RFC6461] 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 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 new interest in models similar to those in place for administering freephone services in the United States, where a user purchases a number through a sort of number registrar and controls its administration (such as routing) on their own, typically using Internet services to directly make changes to the service associated with telephone numbers.
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. 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 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.
This section provides definitions for actors, data types and data management architectures as they are discussed in this document. Different numbering spaces may instantiate these roles and concepts differently: practices that apply to non-geographic freephone numbers, for example, may not apply to geographic numbers, and practices that exist under one Numbering Authority may not be permitted under another. The purpose of this framework is to identify the characteristics of protocol tools that will satisfy the diverse requirements for telephone number acquisition, management, and retrieval on the Internet.
The following roles of actors are defined in this document:
Note that an individual, company or other entity may act in one or more of the roles above; for example, a company may be a CSP and also a Registrar. Although Numbering Authorities are listed as actors, they are unlikely to actually participate in the protocol flows themselves, though in some situations a Numbering Authority and Registry may be the same administrative entitiy.
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:
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 this case also act as Registrars. CSP/Registrars would then be responsible for distributing numbering resources to Users and other 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 of 100 from a CSP acting as a Registrar with whom the enterprise has a business relationship. The enterprise is in this case the assignee, as it receives numbering resources directly from a Registrar. As it doles out individual numbers to its Users, the enterprise delegates its own numbering resources to those Users and their communications endpoints. The overall ecosystem might look as follows.
+---------+
|Numbering|
|Authority|Registry
+----+----+
|
V 10,000 TNs
+---------+
| CSP |Registrar
+----+----+
|
V 100 TNs
+---------+
| PBX |Assignee
+---------+
|
V 1 TN
+---------+
| User |Delegate
+---------+
Figure 1: Chain of Number Assignment
The following data types are defined in this document:
Administrative and service data can fit into three categories:
While it might appear 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.
This framework generally assumes that administrative and service data is maintained by CSPs, Registrars, and Registries. The role of a Registry described here is a "thin" one, where the Registry manages basic allocation information for the numbering space, such as information about whether or not the number is assigned, and if assigned, by which Registrar. It is the Registrar that in turn manages detailed administrative data about those assignments, such as contact or billing information for the assignee. In some models, CSPs and Registrars will be composed (the same administrative entity), and in others the Registry and Registrar may similarly be composed. Typically, service data resides largely at the CSP itself, though in some models a "thicker" Registry may itself contain a pointer to the servicing CSP for a number or number block. In addition to traditional centralized Registries, this framework also supports environments where the same data is being managed by multiple administrative entities, and stored in many locations. A distribute registry system is discussed further in [15].
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 [I-D.peterson-modern-teri] 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 allocations are restricted to any category of service providers, though these tools must and will work in environments with those properties.
The three mechanisms are:
The acquisition mechanism will enable actors to acquire TNs for use with a communications service. The acquisition mechanism will provide a means to request numbering resources from a service operated by a Registrar, 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.
As an example, a CSP might use the acquisition interface to acquire a chunk of numbers from a Registrar. Users might then provision administrative data associated with those numbers at the CSP through the management interface, and query for service data relating to those numbers through the retrieval interface of the CSP.
+--------+
|Registry|
+---+----+
|
V
+---------+
|Registrar|
+---------+
\
\\
Acquisition \\
\\+-------+
\ CSP |
+---+---+
A A
| |
Management | | Retrieval
| |
| |
+-------++ ++-------+
| User | | User |
+--------+ +--------+
Figure 2: Example of the Three Interfaces
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.
There are various scenarios for how TNs can be acquired by the relevant actors: a CSP, Service Enabler, or User. There are three actors from which numbers can be acquired: a Registrar, a CSP and a User (presumably one who is delegating to another party). It is assumed that Registrars are either composed with Registries, or that Registrars have established business relationships with Registries that enable them to distribute the numbers that the Registries here administer. In these use cases, a User may acquire TNs either from a CSP or a Registry, or from an intermediate delegate.
The most fundamental and traditional numbering use case is one where a CSP, such as a carrier, requests a block of numbers from a Registrar to hold as inventory or assign to customers.
Through some out-of-band business process, a CSP develops a relationship with a Registrar. The Registrar 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 Registrar must authenticate and authorize the CSP, and then either grant or deny a request. When an assignment occurs, 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 [I-D.ietf-stir-certificates]) 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 Registrar, not inventory. In this use case, after receiving a number assignment from the Registrar, 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 Registrar regarding this service activation (this is part of the "TN status" maintained by the Registrar).
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 [I-D.ietf-stir-certificates]) to prove the assignment for future transactions. Such credential could be delegated from the one provided by the Registrar 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 Registrar 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 Registrar about the assignment so the Registrar has current assignment data.
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 [I-D.ietf-stir-certificates]) 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 Registrar 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 Registrar about the assignment so the Registrar has current assignment data. The Delegate may need to provide utilization and assignment data to the Registry, either directly or through the CSP.
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.
Today, a user wishing to acquire a freephone number may browse the existing inventory through one or more Registrars, comparing their prices and services. Each such Registrar either is a CSP, or has a business relationship wtih a CSP to provide services for that freephone number.
Acquiring a TN from a Registrar follows the process in Section 4.1.1, as it should be similar to how a CSP acquires TNs from a Registrar. In this case, the User must establish some business relationship directly to a Registrar, similarly to how such functions are conducted today when Users purchase domain names. For the purpose of 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 Registrar, 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.
The management protocol mechanism is needed to associate administrative and service data with TNs, and may be used to refresh or rollover associated credentials.
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 Registrar, 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.
After a CSP acquires a TN or block of TNs from the Registrar (per Section 4.1.1 above), it then provides administrative data to the Registrar as a step in the acquisition process. The Registrar 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 Registrar 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.
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.
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 Regisrar in this case, maintaining the administrative data and only notify the Registry of the change in TN status. In this case, the Registry maintains a reference address to the CSP/Registrar's administrative data store so relevant actors have the ability to access the data. Alternatively a CSP could send the 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 a mechanism for the delegate to update the CSP as change occurs.
If the User has a direct relationship with the Registrar, then naturally the user could could provision administrative data associated with their TN directly to the Registrar. This is the case, for example, with the freephone example, where a User has a business relationship with its freephone provider, and the freephone provider maintains account and billing data. While delegates necessarily are not assignees, some environments as an optimization might want to support a model where the delegate updates the Registrar directly on changes, as opposed to sending that data to the CSP or through the CSP to the Registrar. As stated already, the protocol should enable Users to acquire TNs 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 in Section 4.2.1.1.
Service data is data required by an originating or intermediate CSP to enable communications service to a 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 SIP REGISTER [2] method) rather than through any new interfaces defined by MODERN.
After a User enrolls for service with a CSP, in the case where the CSP was assigned the TN by a Registrar, the CSP will then create a service address (such as a SIP URI) and associate it with the TN. 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.
Users could also associate service data to their TNs at the CSP. An example is a User acquires a TN from the Registrar (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.
This section will address some special use cases that were not covered in other sections of 4.2.
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 composed Registry/Registrar that maintains service data, the new CSP provides the new service 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 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 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.
In a similar model to 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.
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 Registrar.
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 a Registrar terminates their service with a CSP. At this time, the User might terminate their assignment from the Registrar, 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.
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 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.
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.
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.
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.
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.
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 Registrar.
For a case where the CSP delegates a number to the User, the CSP might provision the Registrar (or itself, if the CSP is composed with a Registrar) 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 Registrar 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 Registrar or CSP under the policy dictates established by the National Authority.
We would like to thank Henning Schulzrinne for his contributions to this problem statement and framework, and to thank Pierce Gorman for detailed comments.
This memo includes no instructions for the IANA.
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.
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.