idnits 2.17.1 draft-jennings-vipr-overview-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 4673 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-11 == Outdated reference: A later version (-21) exists of draft-ietf-p2psip-sip-05 -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 3761 (Obsoleted by RFC 6116, RFC 6117) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 VIPR WG C. Jennings 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Rosenberg 5 Expires: January 12, 2012 jdrosen.net 6 M. Petit-Huguenin 7 Stonyfish 8 July 11, 2011 10 Verification Involving PSTN Reachability: Requirements and Architecture 11 Overview 12 draft-jennings-vipr-overview-01 14 Abstract 16 The Session Initiation Protocol (SIP) has seen widespread deployment 17 within individual domains, typically supporting voice and video 18 communications. Though it was designed from the outset to support 19 inter-domain federation over the public Internet, such federation has 20 not materialized. The primary reasons for this are the complexities 21 of inter-domain phone number routing and concerns over security. 22 This document reviews this problem space, outlines requirements, and 23 then describes a new model and technique for inter-domain federation 24 with SIP, called Verification Involving PSTN Reachability (ViPR). 25 ViPR addresses the problems that have prevented inter-domain 26 federation over the Internet. It provides fully distributed inter- 27 domain routing for phone numbers, authorized mappings from phone 28 numbers to domains, a new technique for automated VoIP anti-spam, and 29 privacy of number ownership, all while preserving the trapezoidal 30 model of SIP. 32 Legal 34 This documents and the information contained therein are provided on 35 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 36 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 37 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 38 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 39 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 40 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 41 FOR A PARTICULAR PURPOSE. 43 Status of this Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on January 12, 2012. 60 Copyright Notice 62 Copyright (c) 2011 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 79 2.1. The Phone Number Routing Problem . . . . . . . . . . . . . 6 80 2.2. The Open Pinhole Problem . . . . . . . . . . . . . . . . . 7 81 2.3. Quality of Service Problem . . . . . . . . . . . . . . . . 7 82 2.4. Troubleshooting Problem . . . . . . . . . . . . . . . . . 8 83 3. Summary of Existing Solutions . . . . . . . . . . . . . . . . 8 84 3.1. Domain Routing . . . . . . . . . . . . . . . . . . . . . . 8 85 3.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 9 86 3.3. Private Federations . . . . . . . . . . . . . . . . . . . 9 87 4. Key Requirements . . . . . . . . . . . . . . . . . . . . . . . 10 88 5. Executive Overview . . . . . . . . . . . . . . . . . . . . . . 11 89 5.1. Key Properties . . . . . . . . . . . . . . . . . . . . . . 11 90 5.2. Challenging Past Assumptions . . . . . . . . . . . . . . . 13 91 5.3. Technical Overview . . . . . . . . . . . . . . . . . . . . 14 92 5.3.1. Storage of Phone Numbers . . . . . . . . . . . . . . . 16 93 5.3.2. PSTN First Call . . . . . . . . . . . . . . . . . . . 17 94 5.3.3. Validation and Caching . . . . . . . . . . . . . . . . 18 95 5.3.4. SIP Call . . . . . . . . . . . . . . . . . . . . . . . 19 96 6. Architecture Components and Functions . . . . . . . . . . . . 24 97 6.1. ViPR Server . . . . . . . . . . . . . . . . . . . . . . . 25 98 6.2. Call Agent . . . . . . . . . . . . . . . . . . . . . . . . 26 99 6.3. Border Element . . . . . . . . . . . . . . . . . . . . . . 27 100 6.4. Enrollment Server . . . . . . . . . . . . . . . . . . . . 28 101 6.5. P2P Network . . . . . . . . . . . . . . . . . . . . . . . 28 102 7. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 28 103 7.1. P2P: RELOAD . . . . . . . . . . . . . . . . . . . . . . . 28 104 7.1.1. ViPR Usage . . . . . . . . . . . . . . . . . . . . . . 29 105 7.1.2. Certificate Usage . . . . . . . . . . . . . . . . . . 30 106 7.2. ViPR Access Protocol (VAP) . . . . . . . . . . . . . . . . 30 107 7.3. Validation Protocol . . . . . . . . . . . . . . . . . . . 31 108 7.4. SIP Extensions . . . . . . . . . . . . . . . . . . . . . . 32 109 8. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 32 110 8.1. PSTN Call and VCR Upload . . . . . . . . . . . . . . . . . 32 111 8.2. DHT Query and Validation . . . . . . . . . . . . . . . . . 34 112 8.3. DHT Query and No Match . . . . . . . . . . . . . . . . . . 35 113 8.4. SIP Call . . . . . . . . . . . . . . . . . . . . . . . . . 35 114 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 115 9.1. Attacks on the DHT . . . . . . . . . . . . . . . . . . . . 37 116 9.2. Theft of Phone Numbers . . . . . . . . . . . . . . . . . . 37 117 9.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 118 9.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 38 119 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 120 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 121 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 122 12.1. Normative References . . . . . . . . . . . . . . . . . . . 39 123 12.2. Informative References . . . . . . . . . . . . . . . . . . 40 124 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 41 125 A.1. Modifications between rosenberg-04 and rosenberg-03 . . . 41 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 128 1. Introduction 130 The Session Initiation Protocol (SIP) was originally published as RFC 131 2543 [RFC2543] in May of 1999. This was followed by subsequent 132 publication of RFC 3261 [RFC3261], which brought the protocol to 133 sufficient maturity to enable large scale market adoption. 135 And indeed, it has seen large scale market adoption. SIP has seen 136 hundreds of implementations, spanning consumer products, enterprise 137 servers, and large scale carrier equipment. It carries billions and 138 billions of minutes of calls, and has become the lingua franca of 139 interconnection between products from different vendors. If one 140 measures success in deployment, then clearly SIP is a success. 142 Though SIP is used between domains, it is typically through private 143 federation agreements. While such agreements are positive, they 144 cause a "least common denominator" problem, which has limited the 145 growth of advanced SIP features, and prevented the innovation that we 146 expected SIP to drive. SIP was designed from the ground up to enable 147 communications between users in different domains, all over the 148 public Internet. The intention was that real-time communications 149 should be no different than email or the web, with the same any-to- 150 any connectivity that has fueled the successes of those technologies. 151 Though SIP is used between domains, it is typically through private 152 federation agreements. The any-to-any Internet federation model 153 envisioned by SIP has not materialized at scale. 155 This document introduces a new technology, called Verification 156 Involving PSTN Reachability (ViPR), that enables us to break down the 157 barriers that have prevented inter-domain VoIP. By stepping back and 158 changing some of the most fundamental assumptions about federation, 159 ViPR is able to address the key problems preventing its deployment. 160 ViPR focuses on incremental deployability over the unrealizable 161 nirvana. At the same time, ViPR ensures that SIP's trapezoidal model 162 - direct federation between domains without any intermediate 163 processing beyond IP transport - is realized. That model is required 164 in order to allow innovative new services to be deployed. 166 2. Problem Statement 168 The first question that must be asked is this - why haven't we seen 169 widespread adoption of inter-domain SIP federation? 171 There are many reasons for it. They are - in order of importance - 172 the phone number routing problem, the open pinhole problem, the 173 quality of service problem, and the troubleshooting problem. The two 174 former ones are the most significant. 176 2.1. The Phone Number Routing Problem 178 Inter-domain federation requires that the sending domain determine 179 the address of the receiving domain, in the form of a DNS name 180 (example.com) or one or more IP addresses that can be used to reach 181 the domain. In email and in the web, this is easy. The identifiers 182 used by those services - the email address and web URL respectively - 183 embed the address of the receiving domain. A simple DNS lookup is 184 all that is required to route the connection. SIP was designed to 185 use the same email-style identifiers. 187 However, most SIP deployments utilize phone numbers, and not email- 188 style SIP URIs. This is due to the huge installed base of users that 189 continue to exist solely on the public switched telephone network 190 (PSTN). In order to be reached by users on the PSTN, and in order to 191 reach them, users in SIP deployments need to be assigned a regular 192 PSTN number. Users in SIP deployments need to place that PSTN number 193 on business cards, use it in their email signatures, and in general, 194 give it out to their friends and colleagues, in order to be reached. 195 While those users could additionally have an email style SIP URI, the 196 PSTN number serves as a single, global identifier that works for 197 receiving calls from users on the PSTN as well as users within the 198 same SIP domain. Why have two identifiers when one will suffice? 199 The universality of PSTN numbers is the reason why most SIP 200 deployments continue to use them - often exclusively. 202 Another reason is that many SIP deployments utilize hardphones or 203 telephony adaptors, and the user interfaces on these devices - 204 patterned after existing phones - only allow phone-number based 205 dialing. Consequently, these users are only allocated PSTN numbers, 206 and not email-style SIP URI. 208 Finally, a large number of SIP deployments are in domains where the 209 endpoints are not IP. Rather, they are circuit based devices, 210 connected to a SIP network through a gateway. SIP is used within the 211 core of the network, providing lower cost transit, or providing 212 add-on services. Clearly, in these deployments, only phone numbers 213 are used. 215 Consequently, to make inter-domain federation incrementally 216 deployable and widely applicable, it needs to work with PSTN numbers 217 rather than email-style SIP URI. Telephone numbers, unlike email 218 addresses, do not provide any indication of the address of the domain 219 which "owns" the phone number. Indeed, the notion of phone number 220 ownership is somewhat cloudy. Numbers can be ported between 221 carriers. They can be assigned to a user or enterprise, and then 222 later re-assigned to someone else. Numbers are granted to users and 223 enterprises through a complex delegation process involving the ITU, 224 governments, and telecommunications carriers, often involving local 225 regulations that vary from country to country. 227 Therefore, in order to deploy inter-domain federation, domains are 228 required to utilize some kind of mechanism to map phone numbers to 229 the address of the domain to which calls should be routed. Though 230 several techniques have been developed to address this issue, none 231 have achieved large-scale Internet deployments. 233 2.2. The Open Pinhole Problem 235 The inter-domain federation mechanism built into SIP borrows heavily 236 from email. Each domain runs a SIP server on an open port. When one 237 domain wishes to contact another, it looks up the domain name in the 238 DNS, and connects to the that server on the open port. Here, "open" 239 means that the server is reachable from anywhere on the public 240 Internet, and is not blocked by firewalls. 242 This simple design worked well in the early days of email. However, 243 the email system has now become plagued with spam, to the point of 244 becoming useless. Administrators of SIP domains fear - rightfully so 245 - that if they make a SIP server available for anyone on the Internet 246 to contact, it will open the floodgates for VoIP spam, which is far 247 more disruptive than email-based spam [RFC5039]. Administrators also 248 worry - rightfully so - that an open server will create a back-door 249 for denial-of-service and other attacks that can potentially disrupt 250 their voice service. Administrators are simply not willing to take 251 that risk; rightly or wrongly, voice deployments demand higher 252 uptimes and better levels of reliability than email, especially for 253 enterprises. 255 Fears around spam and denial-of-service attacks, when put together, 256 form the "open pinhole problem" - that domains are not willing to 257 enable SIP on an open port facing the Internet. 259 To fix this, a new model for federation is needed - a model where 260 these problems are addressed as part of the fundamental design, and 261 not as an after-thought. 263 2.3. Quality of Service Problem 265 The Internet does not provide any QoS guarantees. All traffic is 266 best effort. This is not an issue for data transaction services, 267 like web and email. It is, however, a concern when using real-time 268 services, such as voice and video. 270 That said, there are a large number of existing VoIP deployments that 271 run over the Internet. Though the lack of QoS is a concern, it has 272 not proven a barrier to deployment. We believe that, if the more 273 fundamental issues - the phone number routing and open pinhole 274 problems - can be addressed, the QoS problem will sort itself out. 275 As such, we do not discuss this issue further here. 277 2.4. Troubleshooting Problem 279 The final problem that is stopping large scale inter-domain 280 federation is the troubleshooting problem. When connecting calls 281 between domains, problems will happen. Calls will get blocked. 282 Calls will get misdelivered. Features won't work. There will be 283 one-way media or no media at all. The video won't start. Call 284 quality will be poor. 286 These problems are common in VoIP deployments, and they are tough to 287 troubleshoot even within a single administrative domain. When real- 288 time services extend inter-domain, the problem becomes worse. A new 289 angle is introduced: the first step is identifying who is at fault. 291 Fortunately, work is underway to improve the ability for network 292 administrators to diagnose VoIP problems. Common log formats 293 [CLF-SYNTAX] and consistent session IDs [SESSION-ID], for example, 294 can help troubleshoot interdomain calls. 296 In addition to these, any new technology that facilitates inter- 297 domain federation needs to have troubleshooting built-in, so that it 298 is not a barrier to deployment. 300 3. Summary of Existing Solutions 302 Given the value that inter-domain SIP federation brings, it is no 303 surprise that many attempts have been made at solving it. Indeed, 304 these have all been deployed to varying degrees. However, all of 305 them have fundamental limitations that have inhibited widespread 306 deployment. 308 3.1. Domain Routing 310 The first solution that has been proposed for SIP inter-domain 311 federation is built into SIP itself - domain routing. In this 312 technique, users utilize email-style SIP URI as identifiers. By 313 utilizing the DNS lookup mechanism defined in [RFC3263], SIP enables 314 calls to be routed between domains in much the same way email is 315 routed between domains. 317 This technique works well in theory, but it has two limitations which 318 have limited its deployment: 320 1. The majority of SIP deployments utilize phone numbers, often 321 exclusively. In such a case, domain routing cannot be used. 322 2. Domain federation brings with it the possibility (and strong 323 likelihood) of the same levels of spam and DoS attacks that have 324 plagued the email system. 326 These issues have already been discussed above. 328 3.2. Public ENUM 330 Public ENUM, defined in [RFC3761], tries to address the phone number 331 routing problem by cleverly placing phone numbers into the public 332 DNS. Clients can then perform a simple DNS lookup on a phone number, 333 and retrieve a SIP URI which can be used to route to that phone 334 number. 336 Unfortunately, public ENUM requires that the entries placed into the 337 DNS be populated following a chain of responsibility that mirrors the 338 ownership of the numbers themselves. This means that, in order for a 339 number to be placed into the DNS, authorization to do so must start 340 with the ITU, and from there, move to the country, telecom regulator, 341 and ultimately the end user. The number of layers of bureaucracy 342 required to accomplish this is non-trivial. In addition, the telecom 343 operators - which would be partly responsible for populating the 344 numbers into the DNS - have little incentive to do so. As a 345 consequence, public ENUM is largely empty, and is likely to remain so 346 for the foreseeable future. 348 Instead, ENUM has morphed into a technique for federation amongst 349 closed peering partners, called private ENUM or infrastructure ENUM 350 [RFC5067]. While there is value in this technology, it does not 351 enable the open federation that public ENUM was designed to solve. 353 It is clear from the legacy of ENUM deployments, that any kind of 354 phone number routing solution should not rely on government or 355 telecom processes for population of the databases. 357 3.3. Private Federations 359 Private federations are a cooperative formed amongst a small number 360 of participating domains. The cooperative agrees to use a common 361 technique for federation, and through it, is able to connect to each 362 other. There are many such federations in use today. 364 Some of these federations rely on a central database, typically run 365 by the federation provider, that can be queried by participating 366 domains. The database contains mappings from phone numbers to 367 domains, and is populated by each of the participating domains, often 368 manually. Each domain implements an agreed-upon query interface that 369 can be used to access the database when a number is called. 370 Sometimes ENUM is used for this interface (called private ENUM), 371 other times, a SIP redirection is used. Some federations also 372 utilize private IP networks in order to address QoS problems. "SIP 373 trunking" - a service being offered by many telecom operators as a 374 SIP-based PRI replacement - is a form of private federation. 376 Private federations work, but they have one major limitation: scale. 377 As the number of participating domains grows, several problems arise. 378 Firstly, the size of the databases become unruly. Secondly, the 379 correctness of the database becomes an issue, since the odds of 380 misconfigured numbers (either intentionally or accidentally) 381 increases. As the membership grows further, the odds increase that 382 "bad" domains will be let in, introducing a source of spam and 383 further problems. The owner of the federation can - and often does - 384 assume responsibility for this, and can attempt to identify and shut 385 down misbehaving participants. Indeed, as the size of the 386 federations grow, the owner of the federation needs to spend 387 increasing levels of capital on maintaining it. This, in turn, 388 requires them to charge money for membership, and this can be a 389 barrier to entry. 391 4. Key Requirements 393 From the discussion on the problems of inter-domain federation and 394 the solutions that have been attempted so far, several key 395 requirements emerge: 397 REQ-1: The solution should allow for federation between any number 398 of domains. 399 REQ-2: The solution must enable users in one domain to identify 400 users in another domain through the use of their existing E.164 401 based phone numbers. 402 REQ-3: The solution must work with deployments that utilize any kind 403 of endpoint, including non-IP phones connected through gateways, 404 IP softphones and hardphones. 405 REQ-4: The solution should not require any change in user behavior. 406 The devices and techniques that users have been using previously 407 to make inter-domain calls should continue to work, but now result 408 in inter-domain IP federation. 409 REQ-5: The solution should work worldwide, for any domain anywhere. 410 REQ-6: The solution should not require any new services from any 411 kind of centralized provider. A domain should be able, of its own 412 free-will and accord, to deploy equipment and connect to the 413 federation. 415 REQ-7: The solution should not require any prior arrangement between 416 domains in order to facilitate federation between those domains. 417 Federation must occur opportunistically - connections established 418 when they can be. 419 REQ-8: The solution must work for domains of any size - starting at 420 a single phone to the largest telecom operator with tens of 421 millions of numbers. 422 REQ-9: The solution must have built-in mechanisms for preventing 423 spam and DoS attacks. These mechanisms must be fully automated. 424 REQ-10: The solution must not require any processing whatsoever by 425 SIP or RTP intermediaries. It must be possible for a direct SIP 426 connection to be established between participating domains. 428 These requirements, when put together, appear to be mutually 429 unsolvable. And indeed, they have been - until now. 431 5. Executive Overview 433 Verification Involving PSTN Reachability (ViPR) is a new technology 434 that is aimed at solving the problems that have prevented large-scale 435 Internet-based SIP federation of voice and video. ViPR solves these 436 problems by creating a hybrid of three technologies - the PSTN 437 itself, a Peer to Peer (P2P) network, and SIP. By combining all 438 three, ViPR enables an incrementally deployable solution to 439 federation. 441 5.1. Key Properties 443 ViPR has several important properties that enable it to solve the 444 federation problem: 446 Works With Numbers: ViPR enables federation for existing PSTN 447 numbers. It does not require users or administrators to know or 448 configure email-style identifiers. It does not require the 449 allocation of new numbers. It does not require a change in user 450 behaviors. Whatever way users were dialing numbers yesterday, 451 works with ViPR tomorrow. 452 Works with Existing Endpoints: ViPR does not require any changes to 453 endpoints. Consequently, it works with existing SIP endpoints, or 454 with non-IP endpoints connected through gateways. 455 Fully Distributed: ViPR does not require any kind of central 456 authority or provider. A domain wishing to utilize ViPR just 457 deploys it on their own. ViPR utilizes the existing PSTN and 458 existing Internet connectivity the domain already has, and by 459 combining them, achieves inter-domain federation. Domains do not 460 need to wait for their service providers to roll out any kind of 461 new features, databases, or functionality. 463 Verified Mappings: The biggest issue in mapping from a phone number 464 to a domain or IP address, is determining whether the mapping is 465 correct. Does that domain really own the given phone number? 466 While solutions like ENUM have solved this problem by relying on 467 centralized delegations of authorization, ViPR provides a secure 468 mapping in a fully distributed way. ViPR guarantees that phone 469 calls cannot be misrouted or numbers stolen. 470 Worldwide: ViPR works worldwide. Any domain that is connected to 471 both the PSTN and the Internet can participate. It doesn't matter 472 whether the domain is in Africa, the Americas, or Australia. 473 Since ViPR does not depend on availability of any regional 474 services beyond IP and PSTN access - both of which are already 475 available globally - ViPR itself is globally available. 476 Unlimited Scale: ViPR has nearly infinite scale. Any number of 477 domains can participate. 478 Self-Scale: ViPR self-scales. This means that the amount of 479 computation, memory, and bandwidth that a domain must deploy 480 scales in direct proportion to the size of their own user base. 481 Self-Learning: ViPR is completely automated. A domain never, ever 482 has to configure any information about another domain. It never 483 has to provision IP addresses, domain names, certificates, phone 484 number prefixes or routing rules. Without any prior coordination, 485 ViPR enables one domain to connect to a different domain. 486 Automated Anti-Spam ViPR comes with a built-in mechanism for 487 preventing VoIP spam. This mechanism is new, and specific to 488 VoIP. In this way, it is fundamentally different from existing 489 VoIP anti-spam techniques which borrow from email [RFC5039]. This 490 new technique is fully automated, and requires no configuration by 491 administrators and no participation from end users. Though it is 492 not a 100% solution to the problem, it brings substantial economic 493 and legal ammunition to the table to act as a good deterrent for a 494 long while. 495 Feature Velocity: ViPR enables direct SIP connections between two 496 domains seeking to federate. There are no SIP intermediaries of 497 any sort between the two. This means that domains have no 498 dependencies on intermediaries for deployment of new features. 499 Designed for the Modern Internet: ViPR is built to run on the modern 500 Internet. It assumes the worst from everyone. It assumes limited 501 connectivity. It assumes network failures. It assumes there are 502 attackers seeking to eavesdrop calls. Security is built-in and 503 cannot be disabled. 504 Reliable: ViPR is reliable. Through its hybridization of the PSTN 505 and the Internet, it makes sure that calls always go through. 506 Indeed, to route a call between domains A and B, ViPR never 507 depends on a server or service anywhere outside of domains A and B 508 (besides vanilla PSTN and IP access) being operational. 510 At first glance, these properties seem impossible to realize. And 511 indeed, given the assumptions that have traditionally been made about 512 how federation has to work, these properties are impossible to 513 realize. It is only by stepping back, and rethinking these 514 fundamental assumptions, that a solution can be found. 516 5.2. Challenging Past Assumptions 518 Two unstated assumptions of SIP federation are challenged by ViPR. 520 The first assumption that federation solutions have made is this: 521 The purpose of SIP federation is to eliminate the PSTN, and 522 consequently, we cannot assume the PSTN itself as part of the 523 solution. 524 Though unstated, this assumption has clearly been part of the design 525 of existing solutions. SIP federation based on email-style URIs, as 526 defined in RFC 3261, doesn't utilize or make mention of the PSTN. 527 Solutions like ENUM, or private registries, do not utilize or make 528 mention of the PSTN. In one sense, it's obvious that they shouldn't 529 - after all, the purpose is to replace the PSTN. However, such an 530 approach ignores an incremental solution - a solution which utilizes 531 the PSTN itself to solve the hard problems in SIP federation. 533 After all, the PSTN has accomplished a great deal. It reaches 534 worldwide. It provides a global numbering translation service that 535 maps phone numbers to circuits. It is highly reliable, and provides 536 QoS. It has been built up over decades to achieve these goals. This 537 begs the question - can we build upon the capabilities already 538 provided by the PSTN, and use them to solve the problems that plague 539 SIP federation? 541 Indeed, the answer is yes once another assumption is challenged. 542 This second assumption is: 543 A federation solution must be the same as the final target 544 federation architecture, and not just a step towards it. 545 Though unstated, this assumption has also been true. SIP's email- 546 style federation was a pure 'target architecture' - the place we want 547 to get to. ENUM was the same - a worldwide global DNS database with 548 everyone's phone numbers - an unrealizable nirvana of open 549 connectivity. 551 Historically, technologies are more successful when they are 552 incrementally deployable. Indeed, in many cases, the target 553 architecture is unrealizable because there is no obvious way to get 554 there. As such, the focus needs to be on the next incremental step 555 that we can take, and that step in turn creates the technological and 556 market pressures that will drive the next step. In the end, the 557 target may not be the perfect nirvana we all imagined, but we've at 558 least arrived. 560 As such, ViPR is very much focused on incremental deployability. It 561 is not the end of the federation story, it is the beginning. It 562 discards the nirvana of perfect IP federation for a solution that 563 federates most, but not all calls, by relying on the PSTN to fill in 564 the gaps. ViPR's philosophy is not to let the perfect be the enemy 565 of the good. 567 5.3. Technical Overview 569 A high level view of the architecture is shown in Figure 1. The 570 figure shows four different domains, a.com, b.com, c.com and d.com, 571 federating using ViPR technology. Each domain is connected to both 572 the public Internet and to the traditional PSTN. 574 //\\ 575 \/ 576 | 577 | 578 | 579 +-------+ 580 | Call | 581 | Agent | 582 | | 583 | | d.com 584 +-------+ 585 | 587 //-------\\ 588 |// \\| 589 | Internet | 590 +-------+ |\\ //| +-------+ 591 | Call | \\-------// | Call | 592 //\\ | Agent |-- --| Agent | //\\ 593 \/ ---| | //-------\\ | |---- \/ 594 | | |// \\| | | 595 +-------+ | PSTN | +-------+ 596 |\\ //| 597 a.com \\-------// b.com 599 | 600 +-------+ 601 | Call | 602 | Agent | 603 | | 604 | | 605 +-------+ 606 | c.com 607 | 608 //\\ 609 \/ 611 Figure 1: High Level Architecture 613 For purposes of explanation, it is easiest to think of each domain as 614 having a single call agent which participates in the federation 615 solution. In actuality, the functionality is decomposed into several 616 sub-components, and this is discussed in more detail below. The call 617 agent is connected to one or more phones in the domain, and is 618 responsible for routing calls, handling features, and processing call 619 state. The call agent is stateful, and is aware of when calls start 620 and stop. 622 Assume that all four domains have a 'fresh' installation of ViPR, and 623 that domain b.com 'owns' +1 408 555 5..., a block of 1000 numbers 624 allocated by its PSTN provider. 626 The ViPR mechanism can be broken into four basic steps: storage of 627 phone numbers, PSTN first call, validation and caching, and SIP call. 629 5.3.1. Storage of Phone Numbers 631 The first step is that the call agents form a single, worldwide P2P 632 network, using RELOAD [P2PSIP-BASE] with the Chord algorithm. This 633 P2P network forms a distributed hash table (DHT) running amongst all 634 participating domains. A distributed hash table is like a simple 635 database, allowing storage of key-value pairs, and lookup of objects 636 by key. Unlike a normal hash table, which resides in the memory of a 637 single computer, a distributed hash table is spread across all of the 638 servers which make up the P2P network. In this case, it is spread 639 across all of the domains participating in the ViPR federation. 641 The neat trick solved by Chord (and by other DHT algorithms), is an 642 answer to the following: given that the desired operation is to read 643 or write an object with key K, which node in the DHT is the box that 644 currently stores the object with that key? Chord provides a clever 645 algorithm which routes read and write operations through nodes in the 646 DHT until they eventually arrive at the right place. With Chord, 647 this will take no more than log2N hops, where N is the number of 648 nodes in the DHT. Consequently, for a DHT with 1024 nodes, 10 hops 649 are required in the worst case. For 2048, 11 hops. And so on. The 650 logarithmic factor allows DHTs to achieve incredible scale and to 651 provide enormous storage summed across all of the nodes that make up 652 the DHT. 654 This logarithmic hopping behavior also means that each node in the 655 DHT does not need to establish a TCP/TLS connection to every other 656 node. Rather, connections are established to a smaller subset - just 657 log(N) of the nodes. 659 In DHTs, each participating entity is identified by a Node-ID. The 660 Node-ID is a 128 bit number, assigned randomly to each entity. They 661 have no inherent semantic meaning; they are not like domain names or 662 IP addresses. 664 In the case of ViPR, each call agent is identified by one or more 665 Node-IDs. For purposes of discussion, consider the case where the 666 call agent has just one. Each participating domain, including b.com 667 in our example, uses the DHT to store a mapping from each phone 668 number that it owns, to its own Node-ID. In the case of b.com, it 669 would store 1000 entries into the DHT, each one being a mapping from 670 one of its phone numbers, to its own Node-ID. Furthermore, when the 671 mappings are stored, the mapping is actually from the SHA-1 hash of 672 the phone number, to the Node-ID of the call agent which claims 673 ownership of that number. 675 Pretending that the Node-ID of the call agent in domain b.com is 676 0x1234 (a shorter 16 bit value to simplify discussion), the entries 677 stored into the DHT by b.com would be: 679 Key | Value 680 ---------------------------------- 681 SHA1(+14085555000) | 0x1234 682 SHA1(+14085555001) | 0x1234 683 SHA1(+14085555002) | 0x1234 684 ..... 685 SHA1(+14085555999) | 0x1234 687 Figure 2: DHT Contents 689 It is important to note that the DHT does not contain phone numbers 690 (it contains hashes of them), nor does it contain IP addresses or 691 domain names. Instead, it is a mapping from the hash of a phone 692 number (in E.164 format) to a Node-ID. 694 b.com will store this mapping when it starts up, or when a new number 695 is provisioned. The information is refreshed periodically by b.com. 696 The actual server on which these mappings are stored depends on the 697 Chord algorithm. Typically, the entries will be uniformly 698 distributed amongst all of the call agents participating in the 699 network. 701 5.3.2. PSTN First Call 703 At some point, a user (Alice) in a.com makes a call to +1 408 555 704 5432, which is her colleague Bob. Even though both sides have ViPR, 705 the call takes place over the plain old PSTN. Alice talks to Bob for 706 a bit, and they hang up. 708 At a random point of time after the call has completed, the call 709 agent in a.com "wakes up" and says to itself, "that's interesting, 710 someone in my domain called +1 408 555 5432, and it went over the 711 PSTN. I wonder if that number is reachable over IP instead?". To 712 make this determination, it hashes the called phone number, and looks 713 it up in the DHT. It is important to note that this lookup is not at 714 the time of an actual phone call - this lookup process happens 715 outside of any phone call, and is a background process. 717 The query for +1 408 555 5432 will traverse the DHT, and eventually 718 arrive at the node that is responsible for storing the mapping for 719 that number. Typically, that node will not be b.com, but rather one 720 of the other nodes in the network (for example. c.com). In many 721 cases, the called number will not find a matching mapping in the DHT. 722 This happens when the number that was dialed is not owned by a domain 723 participating in ViPR. When that happens, a.com takes no further 724 action. Next time there is another call to the same number, it will 725 repeat the process and check once more whether the dialed number is 726 in the DHT. 728 In this case, there is a match in the DHT, and a.com learns the 729 Node-ID of b.com. It then proceeds to the validation step. It is 730 also possible that there are multiple matches in the DHT. This can 731 happen if another domain - d.com for example - also claims ownership 732 of that number. When there are multiple matching results, a.com 733 learns all of them, and performs the validation step with each. 735 5.3.3. Validation and Caching 737 Why not just store the domain in the DHT, instead of the Node-ID? In 738 that case, once a.com performed the lookup, it would immediately 739 learn that the number maps to b.com, and could then make a direct SIP 740 call next time. 742 The main reason this doesn't work is security. The information in 743 the DHT is completely untrusted. There is nothing so far that 744 enables a.com to know that b.com does, in fact, own the phone number 745 in question. Indeed, if multiple domains make a claim on the number, 746 it has no way to know which one (if any) actually owns it. 748 To address this critical problem, ViPR utilizes a technique called 749 phone number validation. Phone number validation is the key concept 750 in ViPR. The essential idea is that a.com will connect to the b.com 751 server, by asking the DHT to form a connection to b.com's Node-ID. 752 Once connected, a.com demands proof of ownership of the phone number. 753 This proof comes in the form of demonstrated knowledge of the 754 previous PSTN call. When a call was placed from a.com to +1 408 555 755 5432, the details of that call - including its caller ID, start time, 756 and stop time, create a form of shared secret - information that is 757 only known to entities that participated in the call. Thus, to 758 obtain proof that b.com really owns the number in question, a.com 759 will demand a knowledge proof - that b.com is aware of the details of 760 the call. The only way that b.com could know these details is if it 761 had received the call, and the only way it could have received the 762 call is if it owned the phone number. 764 There are a great many details required for this validation protocol 765 to be secured. It needs to handle the fact that call start and stop 766 times won't exactly match on both sides. It needs to deal with the 767 fact that many calls start on the top of the hour. It needs to deal 768 with the fact that caller ID is not often delivered, and when it is 769 delivered, is not reliable. It needs to deal with the fact that 770 a.com may in fact be the attacker, trying to use the validation 771 protocol to extract the shared secret from b.com. All of this is, in 772 fact, handled by the protocol. The protocol is based on the Secure 773 Remote Password for TLS Authentication (SRP-TLS) [RFC5054], and is 774 described more fully in [VIPR-PVP]. 776 At the end of the validation process, both a.com and b.com have been 777 able to ascertain that the other side did in fact participate in the 778 previous PSTN call. At that point, a.com sends its domain name to 779 b.com (this is described in more detail below), and b.com sends to 780 a.com - all over a secured channel - a SIP URL to use for routing 781 calls to this number, and a ticket. The ticket is a cryptographic 782 object, opaque to a.com, but used by b.com to allow incoming SIP 783 calls. It is similar in concept to kerberos tickets - it is a grant 784 of access. In this case, it is a grant of access for a.com to call 785 +1 408 555 5432, and only +1 408 555 5432. 787 The a.com call agent receives the SIP URI and ticket, and stores both 788 of them in an internal cache. This cache builds up slowly over time, 789 containing the phone number, SIP URI, and ticket, for those numbers 790 which are called by a.com and validated using ViPR. Because the 791 cache entries are only built for numbers which have actually been 792 called by users in the enterprise, the size of the cache self-scales. 793 A call agent supporting only ten users will build up a cache 794 proportional to the volume of numbers called by ten people, whereas a 795 call agent supporting ten thousand users will build up a cache which 796 is typically a thousand times larger. 798 5.3.4. SIP Call 800 At some point in the future, another call is made to +1 408 555 5432. 801 The caller could be Alice, or it could be any other user attached to 802 the same call agent. This time, the call agent notes that it has a 803 cached route for the number in question, along with a SIP URI that 804 can be used to reach that route. It also has a ticket. 806 The a.com call agent attempts to contact the SIP URI by establishing 807 a TCP/TLS connection to the SIP URI it learned. If this connection 808 cannot be made, it proceeds with the call over the PSTN. This 809 ensures that, in the event of an Internet failure or server failure, 810 the call can still proceed. Assuming the connection is established, 811 the a.com call agent sends a traditional SIP INVITE to the 812 terminating call agent, over this newly formed secure connection. 814 The SIP call setup request also contains the ticket, placed into a 815 new SIP header in the message. 817 When this call setup request arrives at the b.com border element, it 818 can extract the ticket from the new SIP header. This ticket is an 819 object, opaque to a.com, that was previously generated by the b.com 820 call agent. Figure 3 illustrates how this ticket is generated and 821 used. 823 //\\ 824 \/ 825 +----------------------+ | 826 | | | 827 | Hi, I am a.com. | | 828 | How do I reach you? | +-------+ 829 | | | Call | 830 +--------------\-------+ | Agent | 831 \ | | 832 \ | | d.com 833 \ +-------+ 834 \ | 835 \ 836 \ //-------\\ 837 +===================================+ 838 ^ | Internet | V 839 +-------+ |\\ //| +-------+ 840 | Call | \\-------// | Call | 841 //\\ | Agent |-- --| Agent | //\\ 842 \/ ---| | //-------\\ | |---- \/ 843 | | |// \\| | | 844 +-------+ | PSTN | +-------+ 845 |\\ //| 846 a.com \\-------// b.com 848 | 849 +-------+ 850 | Call | 851 | Agent | 852 | | 853 | | 854 +-------+ 855 | c.com 856 | 857 //\\ 858 \/ 860 Figure 3: Ticket Validation Step 1 862 Towards the end of the validation process, domains a.com and b.com 863 had determined that each was, in fact in possession of the shared 864 secret information about the prior PSTN call. However, neither side 865 has any information about the domain names of the other side. The 866 originating domain - a.com - tells b.com that its domain name is 867 a.com. It offers no proof of this assertion at this time. 869 Next, the b.com domain generates the ticket. The ticket has three 870 fundamental parts to it: 872 1. The phone number that was just validated - in this case, +1 408 873 555 5432. 874 2. The domain name that the originating side claims it has - a.com 875 in this case. 876 3. A signature generated by b.com, using a key known to itself only, 877 over the other two pieces of information. 879 This ticket is then sent back to a.com at the end of the validation 880 process, as shown in Figure 4. 882 //\\ 883 \/ 884 | 885 | 886 | +--------------------+ 887 +-------+ | Here is your ticket| 888 | Call | |and a SIP URI to | 889 | Agent | | reach this number. | 890 | | | | 891 | | d.com +--------------------+ 892 +-------+ / 893 | / 894 / 895 //-------\\ / 896 +===================================+ 897 V | Internet | ^ 898 +-------+ |\\ //| +-------+ 899 | Call | \\-------// | Call | 900 //\\ | Agent |-- --| Agent | //\\ 901 \/ ---| | //-------\\ | |---- \/ 902 | | |// \\| | | 903 +-------+ | PSTN | +-------+ 904 |\\ //| 905 a.com \\-------// b.com 907 | 908 +-------+ 909 | Call | 910 | Agent | 911 | | 912 | | 913 +-------+ 914 | c.com 915 | 916 //\\ 917 \/ 919 Figure 4: Ticket Validation Step 2 921 When a.com generates a SIP INVITE, it will contain this ticket. The 922 INVITE arrives at the b.com call agent over the mutually 923 authenticated TLS connection established between the domains. 925 The b.com border element looks for the SIP header field in the INVITE 926 that contains the ticket. First, it verifies the signature over the 927 ticket. Remember that the b.com agent is the one that generated the 928 ticket in the first place; as such, it is in possession of the key 929 required to validate the signature. Once validated, it performs two 930 checks: 932 1. It compares the phone number in the call setup request (the 933 Request URI) against the phone number stored in the ticket. 934 2. It compares the domain name of the calling domain, learned from 935 the certificates in the mutual TLS exchange, against the domain 936 name stored in the ticket. 938 If both match, the b.com call agent knows that the calling party is 939 in fact the domain they claimed previously, and that they had in fact 940 gone through the validation process successfully for the number in 941 question. A consequence of this is that the following property is 942 maintained: 944 A domain can only call a specific number over SIP, if it had 945 previously called that exact same number over the PSTN. 947 This property is key in fighting spam and denial-of-service attacks. 948 Because calling numbers on the PSTN costs money - especially 949 international calls - ViPR creates a financial disincentive for 950 spammers. For a spammer to ring every phone in a domain with a SIP 951 call, it must have previously called every number in the domain with 952 a PSTN call, and had a successfully completed call to each and every 953 one of them. Of course, once that PSTN call had been placed, the 954 spammer would have already achieved their goals, and at cost. The 955 additional VoIP call is not so exciting. 957 This property also means that, in order for an attacker to spam call 958 numbers on VoIP, it must have already spam-called those same numbers 959 on the PSTN. This means that the attacker would clearly be subject 960 to regulations and laws governing usage of the PSTN for calling. As 961 an example, a spammer in the United States would have already 962 violated U.S. do-not-call rules by initiating the spam calls to the 963 PSTN numbers. 965 It is important to note that ViPR does not completely address the 966 spam problem. A large spamming clearing house organization could 967 actually incur the costs of launching the PSTN calls to numbers, and 968 then, in turn, act as a conduit allowing other spammers to launch 969 their calls to those numbers for a fee. The clearinghouse would 970 actually need to transit the signaling traffic (or, divulge the 971 private keys to their domain name), which would incur some cost. As 972 such, while this is not an impossible situation, the barrier is set 973 reasonably high to start with - high enough that it is likely to 974 deter spammers until it becomes a highly attractive target, at which 975 point other mechanisms can be brought to bear. This is, again, an 976 example of the incremental deployability philosophy that ViPR takes - 977 let not the perfect be the enemy of the good. 979 6. Architecture Components and Functions 981 The architecture in Figure 1 is overly simplistic. ViPR allows the 982 functionality embedded within the call agent to be split up into 983 three components, as shown in Figure 5: 985 +-+ +-+ 986 | | | | +------+ 987 | | +-----| |---|Enroll| 988 | | | | | +------+ 989 |I| | |I| 990 |n| +-----+ |n| 991 VAP |t| | ViPR| |t| 992 +----------|r|---|Srvr |--|e|----------------- 993 | |a| | | |r| P2P-Validation 994 | |n| +-----+ |n| 995 | |e| |e| 996 | |t| |t| 997 +-----+ SIP | | +-----+ | | 998 | CA |-------|F|---| |--|F| --------------- 999 +-----+ |i| | | |i| SIP/TLS 1000 . |r| | . | |r| 1001 SIP/ . |e| | | |e| 1002 MGCP/ . |w| | BE | |w| 1003 TDM . |a| | | |a| 1004 . |l| | | |l| 1005 +-----+ |l| | | |l| 1006 | UA |-------| |---| |--| |----------------- 1007 +-----+ | | +-----+ | | SRTP 1008 | | | | 1009 +-+ +-+ 1010 | | 1011 +--------------------+-----------------+ 1012 | 1013 Single administrative domain 1015 Figure 5: Architecture 1017 Within each domain, there are three components that are ViPR-aware. 1018 These are the ViPR server, the call agent (CA), and the border 1019 element (BE). Outside of the domain, there is a P2P network and an 1020 enrollment server. A domain will typically have firewalls - an 1021 Internet firewall and an intranet firewall. 1023 The sections which follow describe the roles and responsibilities of 1024 each component in more detail. 1026 6.1. ViPR Server 1028 The ViPR server is the heart of the system. It performs several key 1029 functions: 1031 1. It implements the P2P protocol, acting as one or more nodes in 1032 the DHT. By placing this function separate from the call agent, 1033 it allows the call agent to be isolated from the traffic and 1034 security concerns that are often associated with a P2P network. 1035 2. It implements the validation mechanism. It is informed of call 1036 events by the call agent, and sometime after the call, looks up 1037 the number in the DHT, and if found, attempts to connect to the 1038 node claiming ownership of the number, and then validates it. 1039 3. It pushes newly learned routes to the call agent once validation 1040 has occurred. The ViPR server does not hold the call routes; 1041 this eliminates the need for an off-box query to perform call 1042 routing logic. 1043 4. It stores numbers into the DHT. The call agent informs the ViPR 1044 servers of numbers to be published, and the ViPR server places 1045 them into the P2P network. Refreshing the stored numbers (by 1046 asking the ViPR server to re-store them) is the responsibility of 1047 the call agent. 1048 5. It implements a distributed quota enforcement algorithm, ensuring 1049 that malicious ViPR servers cannot store excessive data into the 1050 network. 1051 6. It implements a policing function, pacing its store and fetch 1052 requests into the DHT to ensure that the network is not 1053 overwhelmed. 1055 In order to join the P2P network and be able to receive incoming 1056 validation requests, the ViPR server must have open access to the 1057 public Internet. For this reason, it is typically placed into the 1058 DMZ. The Internet firewall will not require any pinholes to be 1059 opened towards the ViPR server. 1061 It is important to understand that the ViPR server does not perform 1062 any call processing. It does not process SIP or RTP traffic. It is 1063 a non-real-time server that performs validation processing in the 1064 background, outside of actual call attempts. 1066 The ViPR server needs to connect with the call agent. This is done 1067 through the ViPR Access Protocol (VAP). VAP is described in more 1068 detail below. 1070 6.2. Call Agent 1072 The call agent is a box within the domain which performs call 1073 processing on behalf of one or more phones within the domain. ViPR 1074 can work with a wide variety of call agents, as long as they meet 1075 some specific criteria: 1077 o The call agent must be know of the start time, stop time, caller 1078 ID, and called numbers of calls placed from phones towards the 1079 PSTN. 1080 o The call agent must be capable of making routing decisions for 1081 outbound calls from phones that would otherwise go to the PSTN, 1082 directing them towards the PSTN or towards other domains (based on 1083 ViPR routing rules). 1085 Based on this definition, many different types of products typically 1086 found within a domain could act as the call agent. An IP PBX or TDM 1087 PBX with a SIP interface can be the call agent. A Session Border 1088 Controller (SBC) that connects calls from a PBX to the PSTN, can act 1089 as the call agent. An IMS application server can act as the call 1090 agent. A PSTN gateway, used for all calls egressing a domain from a 1091 set of phones, can act as a call agent. 1093 A SIP proxy can act as a call agent; as long as it is capable of 1094 stashing the relevant call information into Record-Route headers for 1095 usage at the end of the call, it can even operate without retaining 1096 call state. 1098 A single phone can also act as the call agent, representing itself 1099 and its own phone number. 1101 In ViPR, the call agent performs several key functions specific to 1102 ViPR: 1104 o It informs the ViPR server of the phone numbers to be stored in 1105 the DHT for its domain. 1106 o It refreshes those numbers in the DHT, redoing the storage 1107 operation periodically. 1108 o At the end of a call, the call agent sends a ViPR Call Record 1109 (VCR) to the ViPR server, containing the start time, stop time, 1110 caller ID and called party number. 1111 o It learns validated routes from the ViPR server. These routes 1112 consist of a phone number, a SIP URI to utilize when contacting 1113 that phone number, and a corresponding ticket. The call agent is 1114 responsible for storing those routes. 1115 o When a call is to be made towards a PSTN number, the call agent is 1116 responsible for checking whether there is a route for that number, 1117 learned via a prior notification from the ViPR server. If so, it 1118 is responsible for sending the INVITE towards the learned SIP URI, 1119 and for including the ticket the ViPR-Ticket header field. 1121 Those functions which require communications with the ViPR server are 1122 done by implementing VAP. VAP is a client-server protocol, with the 1123 call agent acting as the client, and the ViPR server acting as the 1124 server. For this reason, the call agent is sometimes called the VAP 1125 client or ViPR client. 1127 6.3. Border Element 1129 The border element is responsible for the SIP layer perimeter 1130 security functions. In particular: 1132 o The border element ensures that all egress SIP traffic is carried 1133 over TLS. Border elements must reject any incoming SIP requests 1134 which are not over TLS. SIP over TLS is mandatory-to-use in ViPR, 1135 and it must be performed using mutual TLS. 1136 o The border element ensures that all egress RTP traffic is actually 1137 carried using SRTP. If the traffic originated by the UA in the 1138 domain is inherently SRTP, the criteria is met. However, many 1139 domains do not utilize SRTP internally, and if it is not used 1140 internally, the border element must convert to SRTP. Similarly, 1141 the border element is responsible for rejecting any incoming SIP 1142 calls that are not set up with SRTP. SRTP is mandatory in ViPR. 1143 o The border element ensures that ingress and egress SIP traffic is 1144 'fixed up' so that it can pass through the Internet firewall 1145 successfully. Typically, this is done using a traditional SBC/ALG 1146 function. 1147 o The border element inspects all incoming SIP INVITEs, and performs 1148 ticket verification. In this process, it looks for the ViPR- 1149 Ticket header field in the INVITE. If not present, it discards 1150 the request. If present, it verifies the signature, and then 1151 compares the called number and remote TLS domain against the 1152 contents of the ticket. If they do not match, the border element 1153 discards the INVITE. 1155 The border element can perform other, non-ViPR tasks, as is common 1156 for border elements. These include header inspection and validation, 1157 anti-virus checks on embedded content, SIP state machine conformance, 1158 policy checks on various services, and so on. 1160 The role of the border element can be fulfilled by any number of 1161 products typically found within domains. These include Session 1162 Border Controllers and firewalls. Indeed, the border element 1163 function can be embedded directly in the Internet firewall. 1165 The border element is connected to the call agent via SIP, and to the 1166 user agent (UA) via RTP. The border element has no direct connection 1167 to the ViPR server. However, in order for ticket processing to work 1168 in this model, the ViPR server and border element must share a secret 1169 that is used to create the tickets. This is discussed in more detail 1170 below. 1172 6.4. Enrollment Server 1174 P2P protocols - including RELOAD - require the usage of an enrollment 1175 server in order to obtain the certificates that are used to secure 1176 the network. ViPR uses, and indeed requires, that all RELOAD traffic 1177 be over TCP/TLS with mutual authentication. The certificates used 1178 are obtained through an enrollment process. The details on how P2P 1179 enrollment is done are beyond the scope of this document. 1181 6.5. P2P Network 1183 The collection of ViPR servers form a single, worldwide, P2P network 1184 utilizing RELOAD and the Chord algorithm. 1186 It is very important to understand that the DHT is never accessed in 1187 real-time. It is not queried at call setup time. This is because 1188 the DHT is slow, involving many hops. Queries could take seconds. 1189 Furthermore, we don't want to rely on proper operation of the DHT to 1190 actually make calls. 1192 7. Protocols 1194 The overall ViPR solution utilizes several protocols, each performing 1195 a different function. 1197 7.1. P2P: RELOAD 1199 ViPR utilizes the RELOAD protocol [P2PSIP-BASE] to run amongst each 1200 of the ViPR servers. Each ViPR server acts as one or more nodes in 1201 the DHT. The number of nodes that the ViPR server implements 1202 directly determines the quota allocated to that ViPR server, and in 1203 turn, the amount of work it must perform storing data. 1205 ViPR, however, does not implement the SIP usage that has been defined 1206 for RELOAD [P2PSIP-SIP]. That is because the DHT is not used as a 1207 traditional distributed registrar. Instead, it implements a new 1208 usage - the ViPR usage - which stores phone numbers. It also 1209 utilizes the DHT for storage of certificates, using a certificate 1210 usage. 1212 7.1.1. ViPR Usage 1214 The ViPR usage is described in detail in [VIPR-RELOAD-USAGE]. This 1215 section provides a brief overview. 1217 The ViPR usage makes use of the dictionary type. Each resource-ID is 1218 a key, computed by taking the SHA1 hash of an E.164 formatted phone 1219 number. The value stored at this resource-ID is a dictionary. The 1220 dictionary entries are the set of virtual ViPR servers which claim 1221 ownership of those numbers. 1223 Since a ViPR server might support a multiplicity of call agents from 1224 different domains, it is necessary to logically segment a ViPR server 1225 so that - from a security perspective - it operates logically like 1226 different virtual ViPR servers, one for each call agent. Each 1227 virtual instance of a ViPR server is called a VService. Thus, the 1228 entries in the dictionary are key value pairs whose key is the 1229 concatenation of the Node-ID and an identifier for the VService 1230 within that node. The value at each key is the Node-ID to contact 1231 for validation. 1233 When a node in the DHT receives a Store request, and it is the 1234 responsible node for the resource-ID, it will verify that the Node-ID 1235 in both the key and value of the dictionary entry match the Node-ID 1236 in the certificate it presents. This ensures that one ViPR server 1237 can never overwrite data from another ViPR server. 1239 The ViPR usage also specifies a quota mechanism. Unlike the SIP 1240 usage, where there are very specific rules about what resource-IDs a 1241 node may store into the DHT, with ViPR, there is no way to restrict 1242 what resource-IDs may be stored by a ViPR server. This is because, 1243 in ViPR, the resource-IDs are derived from phone numbers, and at the 1244 time of storage, there is no way to know whether the node performing 1245 the store actually owns this phone number. Consequently, a 1246 responsible node will accept stores from any node for any 1247 resource-ID. However, to limit malicious users from consuming all of 1248 the resources of the DHT, the ViPR usage imposes a quota on storage. 1249 Each node performing a store is allocated a fixed quota on the number 1250 of records it can place into the DHT. A probabilistic enforcement 1251 model is utilized at each responsible node based on the fraction of 1252 the hashspace owned by that responsible node. Roughly speaking, if 1253 the system quota is 10,000 phone numbers per Node-ID, if a 1254 responsible node owns 10% of the DHT, it will accept an average of 1255 1000 phone numbers from any one single Node-ID. 1257 7.1.2. Certificate Usage 1259 Further details pending. 1261 7.2. ViPR Access Protocol (VAP) 1263 The ViPR Access Protocol (VAP) is documented in [VIPR-VAP]. 1265 VAP is a client-server protocol that runs between the call agent and 1266 the ViPR server. VAP is a simple, binary based, request/response 1267 protocol. It utilizes the same syntactic structure and transaction 1268 state machinery as STUN [RFC5389], but otherwise is totally distinct 1269 from it. VAP clients initiate TCP/TLS connections towards the ViPR 1270 server. The ViPR server never opens connections towards the call 1271 agent. This allows the ViPR servers to run on the public side of 1272 NATs and firewalls. 1274 Once the connections are established, the call agent sends a Register 1275 message to the ViPR server. This register message primarily provides 1276 authentication and connects the client to the ViPR server. VAP 1277 provides several messages for different purposes: 1278 o Publish: The Publish message informs the ViPR server of service 1279 information. There are two types of Publishes supported in ViPR. 1280 The first is the ViPR Service (VService). This informs the ViPR 1281 server of the SIP URIs on the call agent and black and white lists 1282 used by the ViPR server to block validations. The ViPR server 1283 stores that information locally and uses it during the validation 1284 process, as described above. The second Publish is the ViPR 1285 number service. The ViPR server, upon receiving this message, 1286 performs a Store operation into the DHT. 1287 o UploadVCR: This message comes in two flavors - an originating and 1288 terminating message. An originating UploadVCR comes from a call 1289 agent upon completion of a non-ViPR call to the PSTN. A 1290 terminating UploadVCR comes from an agent upon completion of a 1291 call received FROM the PSTN. The ViPR server behavior for both 1292 messages is very different. For Originating UploadVCR, the ViPR 1293 server will store these, and at a random time later, query the DHT 1294 for the called number and attempt validation against the ViPR 1295 servers that are found. For a terminating UploadVCR, the ViPR 1296 server will store these, awaiting receipt of a validation against 1297 them. 1298 o Subscribe: Call agents can subscribe for information from the 1299 ViPR server. There is one service that the call agent can 1300 subscribe for: number Service. When a new number is validated, 1301 the ViPR server will send a Notify to the call agent, containing 1302 the validated number, the ticket, and a set of SIP trunk URIs. 1304 o Notify: The ViPR server sends this message to the call agent when 1305 it has an event to report for a particular subscription. 1307 The VAP protocol provides authentication by including an integrity 1308 object in each message. This integrity message is the hash of the 1309 contents of the message and a shared secret between the ViPR server 1310 and the client. VAP can also be run over TLS, which enhances 1311 security further. 1313 The P2P network introduces rate limits for the purposes of 1314 performance management and limiting denial of service attacks. Each 1315 node in the DHT comes with it a limit on the amount of stores per 1316 second, reads per second, and total amount of data it can store in 1317 the DHT. The ViPR server rigorously follows those limits. 1319 As a consequence, when numbers are stored into the DHT, they are 1320 written in slowly based on the rate limits. The call agent will send 1321 a Publish operation for each individual number. The ViPR server will 1322 perform the store in a rate-limited fashion. When the store is 1323 complete, the ViPR server responds to the Publish, and the call agent 1324 can move to the next DID to publish. Thus, it may take hours or even 1325 days to fully store the set of numbers into the DHT. The process 1326 then repeats several days later in order to refresh the data in the 1327 DHT. 1329 7.3. Validation Protocol 1331 The core of ViPR is the validation protocol. The validation protocol 1332 is used by one ViPR server to connect to another, demand proof-of- 1333 knowledge of a previous PSTN call, and once proven, securely learn a 1334 SIP URI and ticket for usage in future SIP calls between domains. 1336 The validation protocol is documented in [VIPR-PVP]. 1338 The validation protocol is built using TLS-SRP [RFC5054]. TLS-SRP 1339 creates a secure TLS connection, but instead of using certificates, 1340 utilizes a password. TLS-SRP was designed for cases where the 1341 passwords are relatively weak. In the case of the validation 1342 protocol, the passwords are formed from parameters of a previous PSTN 1343 call. Once a secure TLS connection is formed, a simple request/ 1344 response protocol is run over it. The request contains the domain 1345 name of the originating ViPR server, and the response contains the 1346 SIP URI and ticket for that number. 1348 The validation protocol properly handles time offsets between the two 1349 domains for the start and stop times of the calls, the relatively 1350 weak entropy of a single phone call, the grand chessmaster attack, 1351 and non-delivery or inaccurate delivery of caller-ID, amongst other 1352 issues. The validation protocol can be tuned by administrators to 1353 allow for arbitrary levels of security, measured in terms of 1354 equivalent entropy. The equivalent entropy is the number of bits of 1355 entropy that must be demonstrated, as if the domains were 1356 authenticating each other using a password with that amount of 1357 entropy. This gives domains a 'nerd knob' they can turn to trade off 1358 security for performance. 1360 Because the validation protocol utilizes TLS-SRP, it does not run 1361 directly through the DHT. This is why a ViPR server requires a 1362 separate pinhole to be opened for the validation protocol. 1364 7.4. SIP Extensions 1366 The connection between the call agents in different domains is SIP. 1367 ViPR requires that the inter-domain connections run over TLS, and 1368 furthermore, utilize SRTP keyed with Sdescriptions. 1370 ViPR extends SIP with its anti-spam mechanism. This takes the form 1371 of a ticket, present in a SIP header field. [VIPR-SIP-ANTISPAM] 1372 defines this header field and the format of the ticket it contains. 1374 8. Example Call Flows 1376 This section provides call flows for the key use cases. 1378 8.1. PSTN Call and VCR Upload 1380 A call flow for the initial PSTN call and VCR upload is shown in 1381 Figure 6. 1383 Alice CA+O GW+O VIPR+O GW+T CA+T VIPR+T Bob 1384 |(1) Call NumX | | | | | | 1385 |------->| | | | | | | 1386 | |(2) INVITE NumX | | | | | 1387 | |------->| | | | | | 1388 | | |(3) setup NumX | | | | 1389 | | |---------------->| | | | 1390 | | | | |(4) INVITE NumX | | 1391 | | | | |------->| | | 1392 | | | | | |(5) Call NumX | 1393 | | | | | |---------------->| 1394 | | | | | | | Answers 1395 | | | | | |(6) answer | 1396 | | | | | |<----------------| 1397 | | | | |(7) 200 OK | | 1398 | | | | |<-------| | | 1399 | | | | |(8) ACK | | | 1400 | | | | |------->| | | 1401 | | |(9) answer | | | | 1402 | | |<----------------| | | | 1403 | |(10) 200 OK | | | | | 1404 | |<-------| | | | | | 1405 | |(11) ACK| | | | | | 1406 | |------->| | | | | | 1407 |(12) accept | | | | | | 1408 |<-------| | | | | | | 1409 |hangs up| | | | | | | 1410 |(13) hangup | | | | | | 1411 |------->| | | | | | | 1412 | |(14) BYE| | | | | | 1413 | |------->| | | | | | 1414 | |(15) 200 OK | | | | | 1415 | |<-------| | | | | | 1416 | | |(16) hangup | | | | 1417 | | |---------------->| | | | 1418 | | | | |(17) BYE| | | 1419 | | | | |------->| | | 1420 | | | | |(18) 200 OK | | 1421 | | | | |<-------| | | 1422 | | | | | |(19) hangup | 1423 | | | | | |---------------->| 1424 | |(20) Orig UploadVCR | | | | 1425 | |---------------->| | | | | 1426 | |(21) Success | | | | | 1427 | |<----------------| | | | | 1428 | | | |Set timer | | | 1429 | | | | | |(22) Term UploadVCR 1430 | | | | | |------->| | 1431 | | | | | |(23) Success | 1432 | | | | | |<-------| | 1434 Figure 6: PSTN Call and Upload 1436 In message 1, Alice calls the number of her colleague, Bob. This is 1437 NumX. This call is routed over the PSTN, through the terminating 1438 call agent, and rings Bob's phone (messages 1-5). Bob answers the 1439 phone, and this is propagated back to Alice (messages 6-12). Bob and 1440 Alice talk for a while, and then Alice hangs up. This hangup is 1441 propagated to Bob, and the call is terminated (messages 13-19). 1443 The originating call agent notes that this call went to the PSTN, and 1444 might be a candidate for a future SIP call. It sends an UploadVCR 1445 message to its ViPR server (message 20), containing the start time, 1446 stop time, callerID and called party number. The ViPR server 1447 acknowledges this (message 21), and then sets a timer for a random 1448 time into the future, at which point it will attempt validation. The 1449 terminating side is similar; it sends an UploadVCR to its ViPR server 1450 (message 22), which is acknowledged (message 23). The terminating 1451 side does not set a timer; it waits for a possible validation attempt 1452 which may or may not arrive in the future. 1454 8.2. DHT Query and Validation 1456 This section provides the call flow for what happens on the 1457 originating ViPR server when the timer fires, in Figure 7. 1459 CA+O VIPR+O DHT VIPR+T 1460 | |timer fires | | 1461 | |(1) Query NumX | | 1462 | |-------------------->| | 1463 | |(2) Node-ID T | | 1464 | |<--------------------| | 1465 | |(3) Connect Node-ID T| | 1466 | |-------------------->| | 1467 | | |(4) Connect Node-ID T| 1468 | | |-------------------->| 1469 | | |(5) Connect resp. | 1470 | | |<--------------------| 1471 | |(6) Connect resp. | | 1472 | |<--------------------| | 1473 | |(7) TCP Connect | | 1474 | |------------------------------------------>| 1475 | |(8) TLS-SRP | | 1476 | |------------------------------------------>| 1477 | |(9) ValExchange(a.com) | 1478 | |------------------------------------------>| 1479 | |(10) ValResponse(URI, ticket) | 1480 | |<------------------------------------------| 1481 |(11) Notify(NumX,URI,ticket) | | 1482 |<-------------------| | | 1483 |Store route | | | 1485 Figure 7: Validation Flow 1487 First, the timer that was set by the originating ViPR server in 1488 Figure 6 fires. When it fires, the ViPR server examines the called 1489 party number from the VCR. It performs a query into the DHT, to see 1490 if this number has been stored by any domain (message 1). In this 1491 case, it has, and the DHT returns with a successful query response 1492 (message 2). This response indicates that the terminating ViPR 1493 server, with node-ID T, claims ownership of the number. 1495 The originating ViPR server asks the DHT to form a connection between 1496 itself and the terminating ViPR server. This message exchanges IP 1497 addresses and ports through which a TCP connection can be attempted; 1498 details are omitted (messages 3-6). Now, the originating ViPR server 1499 can establish a TCP connection to the terminating ViPR server 1500 (message 7). Next, the originating ViPR server begins negotiation of 1501 a TLS-SRP connection. The TLS-SRP uses the caller ID and called 1502 number as a "username" for this exchange, and the start time and stop 1503 time of the call as a password. As both sides share the same values 1504 for this secret, the secure connection is established. This is now a 1505 TLS connection between the two ViPR servers. 1507 Over this secure connection, the originating ViPR server sends a 1508 ValExchange request. This request contains the domain name that is 1509 claimed by the originating ViPR server (this claim is not verified at 1510 this time) (message 9). This is received by the terminating ViPR 1511 server, which then creates a ticket for that domain and NumX, and 1512 passes the ticket and the SIP URI back to the originating ViPR server 1513 (message 10). The originating ViPR server sends this information to 1514 its call agent (message 11), which then stores it for usage in a 1515 future call. 1517 8.3. DHT Query and No Match 1519 In this case, after the PSTN call of Figure 6, the timer fires, but 1520 the originating ViPR server finds no match in the DHT. This is an 1521 alternative case to the flow in Figure 7. 1523 CA+O VIPR+O DHT VIPR+T 1524 | |timer fires | | 1525 | |(1) Query NumX | | 1526 | |------------------->| | 1527 | |(2) noMatch | | 1528 | |<-------------------| | 1530 Figure 8: DHT No-Match 1532 8.4. SIP Call 1534 In this case, shown in Figure 9, a user makes a call to a number 1535 which has been learned via ViPR. 1537 Alfred CA+O BE+O BE+T CA+T Bob 1538 |(1) Call X | | | | | 1539 |------------>| | | | | 1540 | |(2) INVITE X | | | | 1541 | |Ticket | | | | 1542 | |------------>| | | | 1543 | | |(3) TCP and TLS | | 1544 | | |w domain certs | | 1545 | | |------------>| | | 1546 | | |(4) INVITE X | | | 1547 | | |Ticket | | | 1548 | | |------------>| | | 1549 | | | |Validate Ticket | 1550 | | | |(5) INVITE X | | 1551 | | | |Ticket | | 1552 | | | |------------>| | 1553 | | | | |(6)INVITE X| 1554 | | | | |---------->| 1556 Figure 9: SIP Call 1558 First, a user in the originating domain - Alfred - calls Bob's number 1559 (message 1). The originating call agent notes that it has a cached 1560 route for that number. It extracts the SIP URI, using it as the 1561 topmost Route header field, and then attaches the ticket to the ViPR- 1562 Ticket header field. This INVITE is sent to a default next hop 1563 border element (message 2). The border element establishes a TCP/TLS 1564 connection with the domain in the Route header. It uses a 1565 traditional domain certification for this TLS connection (message 3). 1566 Once established, it sends the INVITE over the connection (message 1567 4). 1569 This arrives at the terminating call agent, which extracts the ticket 1570 and verifies it. To verify it, it checks the signature using the key 1571 that was used to create the ticket. Then, it compares the domain 1572 name in the ticket with the domain name from the TLS connection 1573 handshake. Finally, it compares the called party number in the 1574 Request-URI with the value from the ticket. Assuming they all match, 1575 the call is forwarded to the terminating call agent (message 5), 1576 where it is finally delivered to Bob (message 6). 1578 9. Security Considerations 1580 Security is incredibly important for ViPR. This section provides an 1581 overview of some of the key threats and how they are handled. 1583 9.1. Attacks on the DHT 1585 Attackers could attempt to disrupt service through a variety of 1586 attacks on the DHT. 1588 Firstly, it must be noted that the DHT is never used at call setup 1589 time. It is accessed as a background task, solely to learn NEW 1590 numbers and routes that are not already known. If, by some tragedy, 1591 an attacker destroyed the P2P network completely, it would not cause 1592 a single call to fail. Furthermore, it would not cause calls to 1593 revert to the PSTN - calls to routes learned previously would still 1594 go over the IP network. The only impact to such a devastating 1595 attack, is that a domain could not learn *new* routes to new numbers, 1596 until the DHT is restored to service. This service failure is hard 1597 for users and administrators to even notice. 1599 That said, ViPR prevents many of these attacks. The DHT itself is 1600 secured using TLS - its usage is mandatory. Quota mechanisms are put 1601 into place that prevent an attacker from storing large amounts of 1602 data in the DHT. Other attacks are prevented by mechanisms defined 1603 by RELOAD itself, and are not ViPR specific. 1605 9.2. Theft of Phone Numbers 1607 The key security threat that ViPR is trying to address is the theft 1608 of phone numbers. In particular, a malicious domain could store, 1609 into the DHT, phone numbers that it does not own, in an attempt to 1610 steal calls targeted to those numbers. This attack is prevented by 1611 the core validation mechanism, which performs a proof of knowledge 1612 check to verify ownership of numbers. 1614 An attacker could try to claim numbers it doesn't own, which are 1615 claimed legitimately by other domains in the ViPR network. This 1616 attack is prevented as well. Each domain storing information into 1617 the DHT can never overwrite information stored by another domain. As 1618 a consequence, if two domains claim the same number, two records are 1619 stored in the DHT. An originating domain will validate against both, 1620 and only one will validate - the real owner. 1622 An attacker could actually own a phone number, use it for a while, 1623 validate with it, and build up a cache of routes at other domains. 1624 Then, it gives back the phone number to the PSTN provider, who 1625 allocates it to someone else. However, the attacker still claims 1626 ownership of the number, even though they no longer have it. This 1627 attack is prevented by expiring the learned routes after a while. 1628 Typically, operators do not re-assign a number for a few months, to 1629 allow out-of-service messages to be played to people that still have 1630 the old number. Thus, the TTL for cached routes is set to match the 1631 duration that carriers typically hold numbers. 1633 An attacker could advertise a lot of numbers, most of which are 1634 correct, some of which are not. ViPR prevents this by requiring each 1635 number to be validated individually. 1637 An attacker could make a call so they know the call details of the 1638 call they made and use this to forge a validation for that call. 1639 They could then try to convince other users, which would have to be 1640 in the same domain as the attacker, to trust this validation. This 1641 is mitigated by not sharing validations inside of domains where the 1642 users that can originate call from that domain are not trusted by the 1643 domain. 1645 9.3. Spam 1647 Another serious concern is that attackers may try to launch VoIP spam 1648 (also known as SPIT) calls into a domain. ViPR prevents this by 1649 requiring that a domain make a PSTN call to a number before it will 1650 allow a SIP call to be accepted to that same number. This provides a 1651 financial disincentive to spammers. The current relatively high cost 1652 of international calling, and the presence of national do-not-call 1653 regulations, have prevented spam on the PSTN to a large degree. ViPR 1654 applies those same protections to SIP connections. 1656 As noted above, ViPR still lowers the cost of communications, but it 1657 does so by amortizing that savings over a large number of calls. The 1658 costs of communications remain high for infrequent calls to many 1659 numbers, and become low for frequent calls to a smaller set of 1660 numbers. Since the former is more interesting to spammers, ViPR 1661 gears its cost incentives away from the spammers, and towards domains 1662 which collaborate frequently. 1664 Of course, ViPR's built-in mechanism is not a guarantee. A SPIT 1665 clearinghouse could shoulder the costs of the PSTN calls, and then 1666 re-sell its access for a fee. However, this still causes the 1667 clearinghouse to utilize non-trivial resources in its attack. Though 1668 these costs are less than the PSTN, they are more than zero, and 1669 should act as a deterrent for a long while. 1671 9.4. Eavesdropping 1673 Another class of attacks involves outsiders attempting to listen in 1674 on the calls that run over the Internet, or obtain information about 1675 the call through observation of signaling. 1677 All of these attacks are prevented by requiring the usage of SIP over 1678 TLS and SRTP. These are mandatory to use. 1680 10. IANA Considerations 1682 This specification does not require any actions from IANA. 1684 11. Acknowledgements 1686 Thanks for review comments from Ken Fischer, Rob Maidhof, Michael 1687 Procter, and others. Thanks to Theo Zourzouvillys for pointing out 1688 the 5th thief of phone numbers attack. 1690 12. References 1692 12.1. Normative References 1694 [P2PSIP-BASE] 1695 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 1696 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 1697 Base Protocol", draft-ietf-p2psip-base-11 (work in 1698 progress), October 2010. 1700 [P2PSIP-SIP] 1701 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 1702 H. Schulzrinne, "A SIP Usage for RELOAD", 1703 draft-ietf-p2psip-sip-05 (work in progress), July 2010. 1705 [VIPR-RELOAD-USAGE] 1706 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, "A 1707 Usage of Resource Location and Discovery (RELOAD) for 1708 Public Switched Telephone Network (PSTN) Verification", 1709 draft-rosenberg-dispatch-vipr-reload-usage-03 (work in 1710 progress), October 2010. 1712 [VIPR-SIP-ANTISPAM] 1713 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, 1714 "Session Initiation Protocol (SIP) Extensions for Blocking 1715 VoIP Spam Using PSTN Validation", 1716 draft-rosenberg-dispatch-vipr-sip-antispam-03 (work in 1717 progress), October 2010. 1719 [VIPR-VAP] 1720 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, 1721 "Verification Involving PSTN Reachability: The ViPR Access 1722 Protocol (VAP)", draft-rosenberg-dispatch-vipr-vap-03 1723 (work in progress), October 2010. 1725 [VIPR-PVP] 1726 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, "The 1727 Public Switched Telephone Network (PSTN) Validation 1728 Protocol (PVP)", draft-rosenberg-dispatch-vipr-pvp-03 1729 (work in progress), October 2010. 1731 12.2. Informative References 1733 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1734 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1735 March 1999. 1737 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1738 A., Peterson, J., Sparks, R., Handley, M., and E. 1739 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1740 June 2002. 1742 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1743 Protocol (SIP): Locating SIP Servers", RFC 3263, 1744 June 2002. 1746 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 1747 Protocol (SIP) and Spam", RFC 5039, January 2008. 1749 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 1750 Resource Identifiers (URI) Dynamic Delegation Discovery 1751 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 1753 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1754 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1755 October 2008. 1757 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 1758 Requirements", RFC 5067, November 2007. 1760 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 1761 "Using the Secure Remote Password (SRP) Protocol for TLS 1762 Authentication", RFC 5054, November 2007. 1764 [CLF-SYNTAX] 1765 Roach, A., "Binary Syntax for SIP Common Log Format", 1766 draft-roach-sipping-clf-syntax-01 (work in progress), 1767 May 2009. 1769 [SESSION-ID] 1770 Kaplan, H., "A Session Identifier for the Session 1771 Initiation Protocol (SIP)", draft-kaplan-sip-session-id-02 1772 (work in progress), March 2009. 1774 Appendix A. Release notes 1776 This section must be removed before publication as an RFC. 1778 A.1. Modifications between rosenberg-04 and rosenberg-03 1780 o Nits. 1781 o Shorter I-Ds references. 1782 o Changed phone numbers to follow E.123 presentation. 1783 o Expanded P2P initialisms. 1784 o Uses +1 408 555 prefix for phone numbers in examples. 1786 Authors' Addresses 1788 Cullen Jennings 1789 Cisco 1790 170 West Tasman Drive 1791 MS: SJC-21/2 1792 San Jose, CA 95134 1793 USA 1795 Phone: +1 408 421-9990 1796 Email: fluffy@cisco.com 1798 Jonathan Rosenberg 1799 jdrosen.net 1800 Monmouth, NJ 1801 US 1803 Email: jdrosen@jdrosen.net 1804 URI: http://www.jdrosen.net 1806 Marc Petit-Huguenin 1807 Stonyfish 1809 Email: marc@stonyfish.com