Verification Involving PSTN Reachability: Requirements and Architecture Overview
draft-jennings-vipr-overview-06

Abstract

The Session Initiation Protocol (SIP) has seen widespread deployment within individual domains, typically supporting voice and video communications. Though it was designed from the outset to support inter-domain federation over the public Internet, such federation has not materialized. The primary reasons for this are the complexities of inter-domain phone number routing and concerns over security. This document reviews this problem space, outlines requirements, and then describes a model and technique for inter-domain federation with SIP involving the Public Switched Telephone Network (PSTN), called Verification Involving PSTN Reachability (VIPR). VIPR addresses the problems that have prevented inter-domain federation over the Internet. It provides fully distributed inter-domain routing for phone numbers, authorized mappings from phone numbers to domains, a new technique for automated SIP anti-spam, and privacy of number ownership, all while preserving the trapezoidal model of SIP.

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.

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 June 12, 2014.

Copyright Notice

Copyright (c) 2013 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.

Table of Contents

• 1. Introduction
• 2. Conventions and Terminology
• 3. Problem Statement
• 3.1. The Phone Number Routing Problem
• 3.2. The Open Pinhole Problem
• 3.3. Quality of Service Problem
• 3.4. Troubleshooting Problem
• 4. Summary of Existing Solutions
• 4.1. Domain Routing
• 4.2. Public ENUM
• 4.3. Private Federations
• 5. Key Requirements
• 6. Executive Overview
• 6.1. Key Properties
• 6.2. Challenging Past Assumptions
• 6.3. Technical Overview
• 6.3.1. Storage of Phone Numbers
• 6.3.2. PSTN First Call
• 6.3.3. Validation and Caching
• 6.3.4. SIP Call
• 7. Security Considerations
• 7.1. Attacks on the DHT
• 7.2. Theft of Phone Numbers
• 7.3. Spam
• 7.4. Eavesdropping
• 7.5. Privacy Leakage and Malicious Servers
• 8. IANA Considerations
• 9. Acknowledgements
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Appendix A. Changes since last version
• Authors' Addresses

1. Introduction

The Session Initiation Protocol (SIP) was originally published as [RFC2543] in May of 1999. This was followed by subsequent publication of [RFC3261], which brought the protocol to sufficient maturity to enable large scale market adoption.

SIP has achieved large scale market adoption with hundreds of implementations, spanning consumer products, enterprise servers, and large scale carrier equipment. It carries billions and billions of minutes of calls, and has become the standard for interconnection between products from different vendors. If one measures success in deployment, then clearly SIP is a success.

SIP was designed from the ground up to enable communications between users in different domains, all over the public Internet. The intention was that real-time communications should be no different than email or the web, with the same any-to-any connectivity that has fueled the successes of those technologies. However, when SIP is used between domains, it is typically through private federation agreements. While such agreements are positive, they have typically been limited to voice, which has limited the use of video and the growth of advanced SIP features, thus preventing the innovation that SIP was expected to drive. Thus, the any-to-any Internet federation model envisioned by SIP has not materialized at scale.

This document introduces a technology, called Verification Involving PSTN Reachability (VIPR), that breaks down the barriers that have prevented inter-domain voice, video and other multimedia services. By stepping back and changing some of the most fundamental assumptions about federation, VIPR is able to address the key problems preventing its deployment. VIPR focuses on incremental deployability. At the same time, VIPR ensures that SIP's trapezoidal model of direct federation between domains without any intermediate processing beyond IP transport is realized. That model is required in order to allow innovative new services to be deployed.

Despite the advantages of the VIPR system, its open, peer-to-peer character makes it vulnerable to certain security and privacy vulnerabilities (see especially Section 7.5). After consideration of potential countermeasures, the VIPR working group elected not to pursue VIPR for standardization. This document therefore describes VIPR for informational purposes, as VIPR has seen some field deployment, and it is furthermore believed that the techniques utilized by VIPR might be reused in new standard architectures in the future.

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Call Agent:

An entity in a SIP enabled domain that supports VIPR. The Call Agent performs call processing on behalf of one or more user agents represented by E.164 numbers within the domain.

Ticket:

A shared secret that is generated after a PSTN call to enable secure call setup on a subsequent inter-domain IP call enabled by VIPR.

User Agent:

As defined in [RFC3261], with the restriction that the user agent must have an associated E.164 number.

3. Problem Statement

The first question that must be asked is this - why haven't we seen widespread adoption of inter-domain SIP federation? The reason for this is due to problems with the following - summarized in order of importance/impact:

1. Phone number routing
2. Open pinhole
3. Quality of service
4. Troubleshooting

The first two are the most significant.

3.1. The Phone Number Routing Problem

Inter-domain federation requires that the sending domain determine the address of the receiving domain, in the form of a DNS name (example.com) or one or more IP addresses that can be used to reach the domain. In email and in the web, this is easy. The identifiers used by those services - the email address and web URL respectively - embed the address of the receiving domain. A simple DNS lookup is all that is required to route the connection. SIP was designed to use the same email-style identifiers.

However, most SIP deployments utilize phone numbers in the form of E.164 numbers [E.164], and not email-style SIP URIs. This is due to the huge installed base of users that continue to exist solely on the PSTN. In order to be reached by users on the PSTN, and in order to reach them, users in SIP deployments need to be assigned a PSTN phone number. Users in SIP deployments need to place that phone number on business cards, use it in their email signatures, and in general, give it out to their friends and colleagues, in order to be reached. While those users could additionally have an email style SIP URI, the phone number serves as a single, global identifier that works for receiving calls from users on the PSTN as well as users within the same SIP domain.

There are several reasons why two identifiers are used when one will suffice. The universality of PSTN phone numbers is the reason why most SIP deployments continue to use them - often exclusively.

Another reason is that many SIP deployments utilize hardphones or telephony adaptors, and the user interfaces on these devices - patterned after existing phones - only allow phone number based dialing. Consequently, these users are only allocated PSTN phone numbers, and not email-style SIP URI.

Finally, a large number of SIP deployments are in domains where the endpoints are not IP. Rather, they are circuit based devices, connected to a SIP network through a gateway. SIP is used within the core of the network, providing lower cost transit, or providing add-on services. Clearly, in these deployments, only phone numbers are used.

Consequently, to make inter-domain federation incrementally deployable and widely applicable, it needs to work with PSTN phone numbers rather than email-style SIP URIs. Telephone numbers, unlike email addresses, do not provide any indication of the address of the domain which "owns" the phone number. Indeed, the notion of phone number ownership is somewhat cloudy. Phone numbers can be ported between carriers. They can be assigned to a user or enterprise, and then later re-assigned to someone else. Phone numbers are granted to users and enterprises through a complex delegation process involving the ITU, governments, and telecommunications carriers, often involving local regulations that vary from country to country.

Therefore, in order to deploy inter-domain federation, domains are required to utilize some kind of mechanism to map phone numbers to the address of the domain to which calls should be routed. Though several techniques have been developed to address this issue, none have achieved large-scale Internet deployments.

3.2. The Open Pinhole Problem

The inter-domain federation mechanism built into SIP borrows heavily from email. Each domain runs a SIP server on an open port. When one domain wishes to contact another, it looks up the domain name in the DNS, and connects to that server on the open port. Here, "open" means that the server is reachable from anywhere on the public Internet, and is not blocked by firewalls.

This simple design worked well in the early days of email. However, the email system has now become plagued with spam. This has resulted in administrators spending a significant amount of time maintaining spam filters. This does not always benefit the end users as in some cases valid emails are dropped without the user being notified. Thus, administrators of SIP domains are rightfully concerned that if they make a SIP server available for anyone on the Internet to contact, it will open the floodgates for SIP spam, which is far more disruptive than email-based spam [RFC5039]. Administrators are also concerned that an open server will create a back-door for denial-of-service and other attacks that can potentially disrupt their voice and video services. Administrators are often not willing to take that risk since voice deployments demand higher uptimes and better levels of reliability than email, especially for enterprises.

Fears around spam and denial-of-service attacks, when put together, form the "open pinhole problem" - that domains are not willing to enable SIP on an open port facing the Internet.

To fix this, a new model for federation is needed - a model where these problems are addressed as part of the fundamental design rather than after the functionality has been deployed.

3.3. Quality of Service Problem

The Internet does not provide any Quality of Service (QoS) guarantees. All traffic is best effort. This is not an issue for data transaction services, like web and email. It is, however, a concern when using real-time services, such as voice and video.

That said, there are a large number of existing SIP deployments that run over the Internet. Though the lack of QoS is a concern, it has not proven a barrier to deployment. It is believed that if if the more fundamental issues - the phone number routing and open pinhole problems - can be addressed, the QoS problem will be a non-issue. As such, QoS is not discussed further in this or other VIPR specifications.

3.4. Troubleshooting Problem

The final problem that is prohibing large scale inter-domain federation is troubleshooting. When connecting calls between domains, problems can occur. Calls can be blocked. Calls can be misdelivered. Features sometimes don't work. There can be one-way media or no media at all. The video may not start. Call quality can be poor.

These problems are common in SIP deployments, and they are tough to troubleshoot even within a single administrative domain. When real-time services extend inter-domain, the problem becomes worse.

Fortunately, some work has been completed to improve the ability for network administrators to diagnose SIP problems. A Common log format [RFC6873] has been developed. Other work underway, such as consistent session IDs [I-D.ietf-insipid-session-id-reqts] and [I-D.jones-insipid-session-id] can help troubleshoot interdomain calls.

In addition to the above, any new technology that facilitates inter-domain federation needs to have troubleshooting built-in, so that it is not a barrier to deployment. Further consideration of necessary built-in techniques for troubleshooting is required for successful deployment of VIPR.

4. Summary of Existing Solutions

Given the value of inter-domain SIP federation, there are existing deployed solutions summarized below. However, each solution approach has fundamental limitations that have inhibited widespread deployment.

4.1. Domain Routing

The first solution for SIP inter-domain federation is built into SIP itself - domain routing. In this technique, users utilize email-style SIP URIs as identifiers. By utilizing the DNS lookup mechanism defined in [RFC3263], SIP enables calls to be routed between domains in much the same way email is routed between domains.

This technique works well in theory, but it has two limitations which have limited its deployment:

1. The majority of SIP deployments utilize phone numbers, often exclusively. In such a case, domain routing cannot be used.
2. Domain federation brings with it the possibility (and strong likelihood) of the same levels of spam and DoS attacks that have plagued the email system.

These issues have already been discussed in sections Section 3.1 and Section 3.2 respectively.

4.2. Public ENUM

Public ENUM, defined in [RFC6116] addresses the phone number routing problem by placing phone numbers into the public DNS. Clients can then perform a simple DNS lookup on a phone number, and retrieve a SIP URI which can be used to route to that phone number.

Unfortunately, public ENUM requires that the entries placed into the DNS be populated following a chain of responsibility that mirrors the ownership of the numbers themselves. This means that, in order for a number to be placed into the DNS, authorization to do so must start with the ITU, and from there, move to the country, telecom regulator, and ultimately the end user. The number of layers of bureaucracy required to accomplish this is non-trivial. In addition, the telecom operators - that would be partly responsible for populating the numbers into the DNS - have little incentive to do so. As a consequence, public ENUM is largely empty, and is likely to remain so for the foreseeable future.

Instead, ENUM has evolved into a technique for federation amongst closed peering partners, called private ENUM or infrastructure ENUM [RFC5067]. While there is value in this technology, it does not enable the open federation that public ENUM was designed to solve.

4.3. Private Federations

Private federations are a cooperative formed amongst a small number of participating domains. The cooperative agrees to use a common technique for federation, and through it, is able to connect to each other. There are many such federations in use today.

Some of these federations rely on a central database, typically run by the federation provider, that can be queried by participating domains. The database contains mappings from phone numbers to domains, and is populated by each of the participating domains, often manually. Each domain implements an agreed-upon query interface that can be used to access the database when a number is called. Sometimes ENUM is used for this interface (called private ENUM), other times, a SIP redirection is used. Some federations also utilize private IP networks in order to address QoS problems.

Private federations work, but they have one major limitation: scale. As the number of participating domains grows, several problems arise. Firstly, the size of the databases become difficult to manage. Secondly, the correctness of the database becomes an issue, since the odds of misconfigured numbers (either intentionally or accidentally) increases. As the membership grows further, the odds increase that malicious domains will be let in, introducing a source of spam and further problems. The owner of the federation can - and often does - assume responsibility for this, and can attempt to identify and shut down misbehaving participants. Indeed, as the size of the federations grow, the owner of the federation needs to spend increasing levels of capital on maintaining it. This often results in the owners charging for membership, which can be a barrier to entry.

5. Key Requirements

From the discussion on the problems of inter-domain federation and the solutions that have been attempted so far, several key requirements emerge:

REQ-1:

The solution must allow for federation between any number of domains.

REQ-2:

The solution must enable users in one domain to identify users in another domain through the use of their existing E.164 based phone numbers.

REQ-3:

The solution must work with deployments that utilize any kind of endpoint, including non-IP phones connected through gateways, IP softphones and hardphones.

REQ-4:

The solution must not require any change in user behavior. The devices and techniques that users have been using previously to make inter-domain calls must continue to work, but now result in inter-domain calls using IP.

REQ-5:

The solution must work worldwide, for any domain anywhere.

REQ-6:

The solution must not require any new services from any kind of centralized provider. A domain should be able to deploy equipment and connect to the federation without any interaction with or authorization from a centralized provider.

REQ-7:

The solution must not require any prior arrangement between domains in order to facilitate federation between those domains. Federation must occur opportunistically - connections established when they can be.

REQ-8:

The solution must work for domains of any size - starting with a single phone up to the largest telecom operator with tens of millions of numbers.

REQ-9:

The solution must have built-in mechanisms for preventing spam and DoS attacks. These mechanisms must be fully automated.

REQ-10:

The solution must not require any processing whatsoever by SIP or RTP intermediaries. It must be possible for a direct SIP connection to be established between participating domains.

REQ-11:

The solution should adapt to VIPR call failures. The solution should allow the user to make calls using the inter-domain calling mechanism used prior to the initial VIPR-enabled call.

6. Executive Overview

Verification Involving PSTN Reachability (VIPR) is aimed at solving the problems that have prevented large-scale Internet-based SIP federation of voice and video. VIPR solves these problems by creating a hybrid of three technologies - the PSTN itself, a Peer to Peer (P2P) network, and SIP. By using these three technologies together, VIPR enables an incrementally deployable solution to federation.

6.1. Key Properties

VIPR has several important properties that enable it to solve the federation problem:

Works With Numbers:

VIPR enables federation for existing PSTN phone numbers. It does not require users or administrators to know or configure email-style identifiers. It does not require the allocation of new numbers. It does not require a change in user behaviors.

Works with Existing Endpoints:

VIPR does not require any changes to endpoints. Consequently, it works with existing SIP endpoints and with non-IP endpoints connected through gateways.

Verified Mappings:

VIPR ensures that phone calls cannot be misrouted or numbers stolen. The biggest issue in mapping from a phone number to a domain or IP address, is determining whether the mapping is correct - i.e., does the domain really own the given phone number? While solutions like ENUM have solved this problem by relying on centralized delegations of authorization, VIPR provides a secure mapping in a fully distributed way.

Worldwide:

VIPR works worldwide. Any domain that is connected to both the PSTN and the Internet can participate. Since VIPR does not depend on availability of any regional services beyond IP and PSTN access - both of which are already available globally - VIPR itself is globally available.

Scalibility:

VIPR is scaleable. Any number of domains can participate.

Self-Scale:

VIPR self-scales. This means that the amount of computation, memory, and bandwidth that a domain must deploy scales in direct proportion to the size of their own user base.

Self-Learning:

VIPR is completely automated. A domain does not require configuration of any information about another domain. It does not require provisioning of IP addresses, domain names, certificates, phone number prefixes or routing rules.

Automated Anti-Spam

VIPR has a built-in mechanism for preventing SIP spam, which is specific to SIP. It is fundamentally different from existing SIP anti-spam techniques which borrow from email [RFC5039]. This new technique is fully automated, and requires no configuration by administrators and no participation from end users.

Feature Velocity:

VIPR enables direct SIP connections between two domains seeking to federate. There are no SIP intermediaries of any sort between the two. This means that domains have no dependencies on intermediaries for deployment of new features.

Secure:

Security is a fundamental part of VIPR and cannot be disabled.

Reliable:

VIPR is reliable. Through its hybridization of the PSTN and the Internet, it ensures that calls always go through, even in cases of network failure or limited IP connectivity.

In order to achieve a solution with these properties, past assumptions about how federations should work must be challenged.

6.2. Challenging Past Assumptions

Two unstated assumptions of SIP federation are challenged by VIPR.

The first assumption that federation solutions have made is this:

• The purpose of SIP federation is to eliminate the PSTN, and consequently, we cannot assume the PSTN itself as part of the solution.

Though unstated, this assumption has clearly been part of the design of existing solutions. SIP federation based on email-style URIs, as defined in RFC 3261, doesn't utilize nor make mention of the PSTN. Solutions like ENUM, or private registries, also do not utilize nor make mention of the PSTN. However, such approaches ignore an incremental solution - a solution which utilizes the PSTN itself to solve the hard problems in SIP federation.

There are many advantages to leveraging the PSTN. It reaches worldwide. It provides a global numbering translation service that maps phone numbers to circuits. It is highly reliable, and provides QoS. It has been built up over decades to achieve these goals. Thus, building upon rather than replacing the PSTN, can provide the necessary functionality once another assumption is challenged.

This second assumption is:

• A federation solution must be the same as the final target federation architecture, and not just a step towards it.

SIP's email-style federation was a pure 'target architecture'. ENUM was the same - a worldwide global DNS database with everyone's phone numbers providing open connectivity.

Historically, technologies are more successful when they are incrementally deployable. As such, VIPR is very much focused on incremental deployability. It discards the notion of perfect IP federation for a solution that federates most, but not all calls, by relying on the PSTN to fill in the gaps.

6.3. Technical Overview

A high level view of the VIPR architecture with an example is shown in Figure 1. The figure shows four different domains, example.com, example.net, example.org and example.edu, federated using VIPR technology. Each domain is connected to both the public Internet and to the traditional PSTN. For simplicity, the connection for the call agents in example.org and example.edu to the PSTN is not indicated in the diagram as that interface is not relevant to the subsequent examples.

                      +-------+    +-------+
                      |  Call |    |  Call |
       example.org    | Agent |    | Agent |  example.edu
                      |       |    |       |                         
                      +-------+    +-------+
                          \           /
                           \         /        
                            \       / 
                             \     / 
                                |
                          //--------\\
                        |//          \\|
                        |   Internet   |
          +-------+     |\\          //|    +-------+
          |  Call |------ \\ _______//------|  Call |
  //\\    | Agent |                         | Agent |    //\\
  \  /    |       |                         |       |    \  /
   \/  ---|       |      +-----------+      |       |---- \/
  User    |       |======|           |======|       |    User
 Agent    +-------+      |    PSTN   |      +-------+   Agent 
          example.com    |           |    example.net
                         +-----------+         
                                 
       

   Key             |    Value
----------------------------------
SHA1(+14085555000)  |   0x1234
SHA1(+14085555001)  |   0x1234
SHA1(+14085555002)  |   0x1234
.....
SHA1(+14085555999)  |   0x1234

          +-------+                         +-------+
          |  Call |                         |  Call |
  //\\    | Agent |                         | Agent |    //\\
  \  /    |       |                         |       |    \  /
   \/  ---|       |      +-----------+      |       |---- \/
   Alice  |       |<=======<========>======>|       |    Bob
          +-------+      |    PSTN   |      +-------+
          example.com    |           |    example.net
                         +-----------+         
                                 
                                    
                               
                               

            
            
            
                      +-------+    +-------+
                      |  Call |    |  Call |
       example.org    | Agent |    | Agent |  example.edu
                      |       |    |       |                         
                      +-------+    +-------+
                         \             /
+----------------------+  \           /
| Hi, I am example.com.|   \         /        
| How do I reach you?  |    \       / 
+--------------\-------+  //-------\\
                \        //         \\
             +===\======>========>========>=====+
             ^          |    Internet  |        |
             |          |              |        v
          +-------+     |\\          //|    +-------+
          |  Call |------ \\ _______//------|  Call |
  //\\    | Agent |                         | Agent |    //\\
  \  /    |       |                         |       |    \  /
   \/  ---|       |                         |       |---- \/
   Alice  |       |                         |       |    Bob
          +-------+                         +-------+
          example.com                      example.net
                         
            

  

            
           
                      +-------+    +-------+
                      |  Call |    |  Call |
       example.org    | Agent |    | Agent |  example.edu
                      |       |    |       |                         
                      +-------+    +-------+
                         \             /
                          \           /    +------------------------+
                           \         /     | Here is your ticket    |    
                            \       /      | & SIP URI to reach Bob |
                          //-------\\      +----/-------------------+
                         //         \\         /
             +==========<========<========<===/=+
             |          |    Internet  |        ^
             v          |              |        |
          +-------+     |\\          //|    +-------+
          |  Call |------ \\ _______//------|  Call |
  //\\    | Agent |                         | Agent |    //\\
  \  /    |       |                         |       |    \  /
   \/  ---|       |                         |       |---- \/
   Alice  |       |                         |       |    Bob
          +-------+                         +-------+
          example.com                       example.net