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