idnits 2.17.1 draft-jennings-vipr-overview-06.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 09, 2013) is 3784 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.jennings-vipr-vap' is defined on line 1182, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) == Outdated reference: A later version (-11) exists of draft-ietf-insipid-session-id-reqts-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 VIPR WG M. Barnes, Ed. 3 Internet-Draft Polycom 4 Intended status: Informational C. Jennings 5 Expires: June 12, 2014 Cisco 6 J. Rosenberg 7 jdrosen.net 8 M. Petit-Huguenin 9 Unaffiliated 10 December 09, 2013 12 Verification Involving PSTN Reachability: Requirements and Architecture 13 Overview 14 draft-jennings-vipr-overview-06 16 Abstract 18 The Session Initiation Protocol (SIP) has seen widespread deployment 19 within individual domains, typically supporting voice and video 20 communications. Though it was designed from the outset to support 21 inter-domain federation over the public Internet, such federation has 22 not materialized. The primary reasons for this are the complexities 23 of inter-domain phone number routing and concerns over security. 24 This document reviews this problem space, outlines requirements, and 25 then describes a model and technique for inter-domain federation with 26 SIP involving the Public Switched Telephone Network (PSTN), called 27 Verification Involving PSTN Reachability (VIPR). VIPR addresses the 28 problems that have prevented inter-domain federation over the 29 Internet. It provides fully distributed inter-domain routing for 30 phone numbers, authorized mappings from phone numbers to domains, a 31 new technique for automated SIP anti-spam, and privacy of number 32 ownership, all while preserving the trapezoidal model of SIP. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 12, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 69 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. The Phone Number Routing Problem . . . . . . . . . . . . 4 71 3.2. The Open Pinhole Problem . . . . . . . . . . . . . . . . 6 72 3.3. Quality of Service Problem . . . . . . . . . . . . . . . 6 73 3.4. Troubleshooting Problem . . . . . . . . . . . . . . . . . 7 74 4. Summary of Existing Solutions . . . . . . . . . . . . . . . . 7 75 4.1. Domain Routing . . . . . . . . . . . . . . . . . . . . . 7 76 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.3. Private Federations . . . . . . . . . . . . . . . . . . . 8 78 5. Key Requirements . . . . . . . . . . . . . . . . . . . . . . 9 79 6. Executive Overview . . . . . . . . . . . . . . . . . . . . . 10 80 6.1. Key Properties . . . . . . . . . . . . . . . . . . . . . 10 81 6.2. Challenging Past Assumptions . . . . . . . . . . . . . . 12 82 6.3. Technical Overview . . . . . . . . . . . . . . . . . . . 13 83 6.3.1. Storage of Phone Numbers . . . . . . . . . . . . . . 14 84 6.3.2. PSTN First Call . . . . . . . . . . . . . . . . . . . 15 85 6.3.3. Validation and Caching . . . . . . . . . . . . . . . 16 86 6.3.4. SIP Call . . . . . . . . . . . . . . . . . . . . . . 20 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 7.1. Attacks on the DHT . . . . . . . . . . . . . . . . . . . 21 89 7.2. Theft of Phone Numbers . . . . . . . . . . . . . . . . . 22 90 7.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 7.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 23 92 7.5. Privacy Leakage and Malicious Servers . . . . . . . . . . 23 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 97 10.2. Informative References . . . . . . . . . . . . . . . . . 26 98 Appendix A. Changes since last version . . . . . . . . . . . . . 28 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 101 1. Introduction 103 The Session Initiation Protocol (SIP) was originally published as 104 [RFC2543] in May of 1999. This was followed by subsequent 105 publication of [RFC3261], which brought the protocol to sufficient 106 maturity to enable large scale market adoption. 108 SIP has achieved large scale market adoption with hundreds of 109 implementations, spanning consumer products, enterprise servers, and 110 large scale carrier equipment. It carries billions and billions of 111 minutes of calls, and has become the standard for interconnection 112 between products from different vendors. If one measures success in 113 deployment, then clearly SIP is a success. 115 SIP was designed from the ground up to enable communications between 116 users in different domains, all over the public Internet. The 117 intention was that real-time communications should be no different 118 than email or the web, with the same any-to-any connectivity that has 119 fueled the successes of those technologies. However, when SIP is 120 used between domains, it is typically through private federation 121 agreements. While such agreements are positive, they have typically 122 been limited to voice, which has limited the use of video and the 123 growth of advanced SIP features, thus preventing the innovation that 124 SIP was expected to drive. Thus, the any-to-any Internet federation 125 model envisioned by SIP has not materialized at scale. 127 This document introduces a technology, called Verification Involving 128 PSTN Reachability (VIPR), that breaks down the barriers that have 129 prevented inter-domain voice, video and other multimedia services. 130 By stepping back and changing some of the most fundamental 131 assumptions about federation, VIPR is able to address the key 132 problems preventing its deployment. VIPR focuses on incremental 133 deployability. At the same time, VIPR ensures that SIP's trapezoidal 134 model of direct federation between domains without any intermediate 135 processing beyond IP transport is realized. That model is required 136 in order to allow innovative new services to be deployed. 138 Despite the advantages of the VIPR system, its open, peer-to-peer 139 character makes it vulnerable to certain security and privacy 140 vulnerabilities (see especially Section 7.5). After consideration of 141 potential countermeasures, the VIPR working group elected not to 142 pursue VIPR for standardization. This document therefore describes 143 VIPR for informational purposes, as VIPR has seen some field 144 deployment, and it is furthermore believed that the techniques 145 utilized by VIPR might be reused in new standard architectures in the 146 future. 148 2. Conventions and Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in 153 [RFC2119]. 155 Call Agent: An entity in a SIP enabled domain that supports VIPR. 156 The Call Agent performs call processing on behalf of one or more 157 user agents represented by E.164 numbers within the domain. 159 Ticket: A shared secret that is generated after a PSTN call to 160 enable secure call setup on a subsequent inter-domain IP call 161 enabled by VIPR. 163 User Agent: As defined in [RFC3261], with the restriction that the 164 user agent must have an associated E.164 number. 166 3. 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? The reason for 170 this is due to problems with the following - summarized in order of 171 importance/impact: 173 1. Phone number routing 175 2. Open pinhole 177 3. Quality of service 179 4. Troubleshooting 181 The first two are the most significant. 183 3.1. The Phone Number Routing Problem 184 Inter-domain federation requires that the sending domain determine 185 the address of the receiving domain, in the form of a DNS name 186 (example.com) or one or more IP addresses that can be used to reach 187 the domain. In email and in the web, this is easy. The identifiers 188 used by those services - the email address and web URL respectively - 189 embed the address of the receiving domain. A simple DNS lookup is 190 all that is required to route the connection. SIP was designed to 191 use the same email-style identifiers. 193 However, most SIP deployments utilize phone numbers in the form of 194 E.164 numbers [E.164], and not email-style SIP URIs. This is due to 195 the huge installed base of users that continue to exist solely on the 196 PSTN. In order to be reached by users on the PSTN, and in order to 197 reach them, users in SIP deployments need to be assigned a PSTN phone 198 number. Users in SIP deployments need to place that phone number on 199 business cards, use it in their email signatures, and in general, 200 give it out to their friends and colleagues, in order to be reached. 201 While those users could additionally have an email style SIP URI, the 202 phone number serves as a single, global identifier that works for 203 receiving calls from users on the PSTN as well as users within the 204 same SIP domain. 206 There are several reasons why two identifiers are used when one will 207 suffice. The universality of PSTN phone numbers is the reason why 208 most SIP deployments continue to use them - often exclusively. 210 Another reason is that many SIP deployments utilize hardphones or 211 telephony adaptors, and the user interfaces on these devices - 212 patterned after existing phones - only allow phone number based 213 dialing. Consequently, these users are only allocated PSTN phone 214 numbers, and not email-style SIP URI. 216 Finally, a large number of SIP deployments are in domains where the 217 endpoints are not IP. Rather, they are circuit based devices, 218 connected to a SIP network through a gateway. SIP is used within the 219 core of the network, providing lower cost transit, or providing add- 220 on services. Clearly, in these deployments, only phone numbers are 221 used. 223 Consequently, to make inter-domain federation incrementally 224 deployable and widely applicable, it needs to work with PSTN phone 225 numbers rather than email-style SIP URIs. Telephone numbers, unlike 226 email addresses, do not provide any indication of the address of the 227 domain which "owns" the phone number. Indeed, the notion of phone 228 number ownership is somewhat cloudy. Phone numbers can be ported 229 between carriers. They can be assigned to a user or enterprise, and 230 then later re-assigned to someone else. Phone numbers are granted to 231 users and enterprises through a complex delegation process involving 232 the ITU, governments, and telecommunications carriers, often 233 involving local regulations that vary from country to country. 235 Therefore, in order to deploy inter-domain federation, domains are 236 required to utilize some kind of mechanism to map phone numbers to 237 the address of the domain to which calls should be routed. Though 238 several techniques have been developed to address this issue, none 239 have achieved large-scale Internet deployments. 241 3.2. The Open Pinhole Problem 243 The inter-domain federation mechanism built into SIP borrows heavily 244 from email. Each domain runs a SIP server on an open port. When one 245 domain wishes to contact another, it looks up the domain name in the 246 DNS, and connects to that server on the open port. Here, "open" 247 means that the server is reachable from anywhere on the public 248 Internet, and is not blocked by firewalls. 250 This simple design worked well in the early days of email. However, 251 the email system has now become plagued with spam. This has resulted 252 in administrators spending a significant amount of time maintaining 253 spam filters. This does not always benefit the end users as in some 254 cases valid emails are dropped without the user being notified. 255 Thus, administrators of SIP domains are rightfully concerned that if 256 they make a SIP server available for anyone on the Internet to 257 contact, it will open the floodgates for SIP spam, which is far more 258 disruptive than email-based spam [RFC5039]. Administrators are also 259 concerned that an open server will create a back-door for denial-of- 260 service and other attacks that can potentially disrupt their voice 261 and video services. Administrators are often not willing to take 262 that risk since voice deployments demand higher uptimes and better 263 levels of reliability than email, especially for enterprises. 265 Fears around spam and denial-of-service attacks, when put together, 266 form the "open pinhole problem" - that domains are not willing to 267 enable SIP on an open port facing the Internet. 269 To fix this, a new model for federation is needed - a model where 270 these problems are addressed as part of the fundamental design rather 271 than after the functionality has been deployed. 273 3.3. Quality of Service Problem 275 The Internet does not provide any Quality of Service (QoS) 276 guarantees. All traffic is best effort. This is not an issue for 277 data transaction services, like web and email. It is, however, a 278 concern when using real-time services, such as voice and video. 280 That said, there are a large number of existing SIP deployments that 281 run over the Internet. Though the lack of QoS is a concern, it has 282 not proven a barrier to deployment. It is believed that if if the 283 more fundamental issues - the phone number routing and open pinhole 284 problems - can be addressed, the QoS problem will be a non-issue. As 285 such, QoS is not discussed further in this or other VIPR 286 specifications. 288 3.4. Troubleshooting Problem 290 The final problem that is prohibing large scale inter-domain 291 federation is troubleshooting. When connecting calls between 292 domains, problems can occur. Calls can be blocked. Calls can be 293 misdelivered. Features sometimes don't work. There can be one-way 294 media or no media at all. The video may not start. Call quality can 295 be poor. 297 These problems are common in SIP deployments, and they are tough to 298 troubleshoot even within a single administrative domain. When real- 299 time services extend inter-domain, the problem becomes worse. 301 Fortunately, some work has been completed to improve the ability for 302 network administrators to diagnose SIP problems. A Common log format 303 [RFC6873] has been developed. Other work underway, such as 304 consistent session IDs [I-D.ietf-insipid-session-id-reqts] and 305 [I-D.jones-insipid-session-id] can help troubleshoot interdomain 306 calls. 308 In addition to the above, any new technology that facilitates inter- 309 domain federation needs to have troubleshooting built-in, so that it 310 is not a barrier to deployment. Further consideration of necessary 311 built-in techniques for troubleshooting is required for successful 312 deployment of VIPR. 314 4. Summary of Existing Solutions 316 Given the value of inter-domain SIP federation, there are existing 317 deployed solutions summarized below. However, each solution approach 318 has fundamental limitations that have inhibited widespread 319 deployment. 321 4.1. Domain Routing 323 The first solution for SIP inter-domain federation is built into SIP 324 itself - domain routing. In this technique, users utilize email- 325 style SIP URIs as identifiers. By utilizing the DNS lookup mechanism 326 defined in [RFC3263], SIP enables calls to be routed between domains 327 in much the same way email is routed between domains. 329 This technique works well in theory, but it has two limitations which 330 have limited its deployment: 332 1. The majority of SIP deployments utilize phone numbers, often 333 exclusively. In such a case, domain routing cannot be used. 335 2. Domain federation brings with it the possibility (and strong 336 likelihood) of the same levels of spam and DoS attacks that have 337 plagued the email system. 339 These issues have already been discussed in sections Section 3.1 and 340 Section 3.2 respectively. 342 4.2. Public ENUM 344 Public ENUM, defined in [RFC6116] addresses the phone number routing 345 problem by placing phone numbers into the public DNS. Clients can 346 then perform a simple DNS lookup on a phone number, and retrieve a 347 SIP URI which can be used to route to that phone number. 349 Unfortunately, public ENUM requires that the entries placed into the 350 DNS be populated following a chain of responsibility that mirrors the 351 ownership of the numbers themselves. This means that, in order for a 352 number to be placed into the DNS, authorization to do so must start 353 with the ITU, and from there, move to the country, telecom regulator, 354 and ultimately the end user. The number of layers of bureaucracy 355 required to accomplish this is non-trivial. In addition, the telecom 356 operators - that would be partly responsible for populating the 357 numbers into the DNS - have little incentive to do so. As a 358 consequence, public ENUM is largely empty, and is likely to remain so 359 for the foreseeable future. 361 Instead, ENUM has evolved into a technique for federation amongst 362 closed peering partners, called private ENUM or infrastructure ENUM 363 [RFC5067]. While there is value in this technology, it does not 364 enable the open federation that public ENUM was designed to solve. 366 4.3. Private Federations 368 Private federations are a cooperative formed amongst a small number 369 of participating domains. The cooperative agrees to use a common 370 technique for federation, and through it, is able to connect to each 371 other. There are many such federations in use today. 373 Some of these federations rely on a central database, typically run 374 by the federation provider, that can be queried by participating 375 domains. The database contains mappings from phone numbers to 376 domains, and is populated by each of the participating domains, often 377 manually. Each domain implements an agreed-upon query interface that 378 can be used to access the database when a number is called. 379 Sometimes ENUM is used for this interface (called private ENUM), 380 other times, a SIP redirection is used. Some federations also 381 utilize private IP networks in order to address QoS problems. 383 Private federations work, but they have one major limitation: scale. 384 As the number of participating domains grows, several problems arise. 385 Firstly, the size of the databases become difficult to manage. 386 Secondly, the correctness of the database becomes an issue, since the 387 odds of misconfigured numbers (either intentionally or accidentally) 388 increases. As the membership grows further, the odds increase that 389 malicious domains will be let in, introducing a source of spam and 390 further problems. The owner of the federation can - and often does - 391 assume responsibility for this, and can attempt to identify and shut 392 down misbehaving participants. Indeed, as the size of the 393 federations grow, the owner of the federation needs to spend 394 increasing levels of capital on maintaining it. This often results 395 in the owners charging for membership, which can be a barrier to 396 entry. 398 5. Key Requirements 400 From the discussion on the problems of inter-domain federation and 401 the solutions that have been attempted so far, several key 402 requirements emerge: 404 REQ-1: The solution must allow for federation between any number of 405 domains. 407 REQ-2: The solution must enable users in one domain to identify 408 users in another domain through the use of their existing E.164 409 based phone numbers. 411 REQ-3: The solution must work with deployments that utilize any kind 412 of endpoint, including non-IP phones connected through gateways, 413 IP softphones and hardphones. 415 REQ-4: The solution must not require any change in user behavior. 416 The devices and techniques that users have been using previously 417 to make inter-domain calls must continue to work, but now result 418 in inter-domain calls using IP. 420 REQ-5: The solution must work worldwide, for any domain anywhere. 422 REQ-6: The solution must not require any new services from any kind 423 of centralized provider. A domain should be able to deploy 424 equipment and connect to the federation without any interaction 425 with or authorization from a centralized provider. 427 REQ-7: The solution must not require any prior arrangement between 428 domains in order to facilitate federation between those domains. 429 Federation must occur opportunistically - connections established 430 when they can be. 432 REQ-8: The solution must work for domains of any size - starting 433 with a single phone up to the largest telecom operator with tens 434 of millions of numbers. 436 REQ-9: The solution must have built-in mechanisms for preventing 437 spam and DoS attacks. These mechanisms must be fully automated. 439 REQ-10: The solution must not require any processing whatsoever by 440 SIP or RTP intermediaries. It must be possible for a direct SIP 441 connection to be established between participating domains. 443 REQ-11: The solution should adapt to VIPR call failures. The 444 solution should allow the user to make calls using the inter- 445 domain calling mechanism used prior to the initial VIPR-enabled 446 call. 448 6. Executive Overview 450 Verification Involving PSTN Reachability (VIPR) is aimed at solving 451 the problems that have prevented large-scale Internet-based SIP 452 federation of voice and video. VIPR solves these problems by 453 creating a hybrid of three technologies - the PSTN itself, a Peer to 454 Peer (P2P) network, and SIP. By using these three technologies 455 together, VIPR enables an incrementally deployable solution to 456 federation. 458 6.1. Key Properties 460 VIPR has several important properties that enable it to solve the 461 federation problem: 463 Works With Numbers: VIPR enables federation for existing PSTN phone 464 numbers. It does not require users or administrators to know or 465 configure email-style identifiers. It does not require the 466 allocation of new numbers. It does not require a change in user 467 behaviors. 469 Works with Existing Endpoints: VIPR does not require any changes to 470 endpoints. Consequently, it works with existing SIP endpoints and 471 with non-IP endpoints connected through gateways. 473 Verified Mappings: VIPR ensures that phone calls cannot be misrouted 474 or numbers stolen. The biggest issue in mapping from a phone 475 number to a domain or IP address, is determining whether the 476 mapping is correct - i.e., does the domain really own the given 477 phone number? While solutions like ENUM have solved this problem 478 by relying on centralized delegations of authorization, VIPR 479 provides a secure mapping in a fully distributed way. 481 Worldwide: VIPR works worldwide. Any domain that is connected to 482 both the PSTN and the Internet can participate. Since VIPR does 483 not depend on availability of any regional services beyond IP and 484 PSTN access - both of which are already available globally - VIPR 485 itself is globally available. 487 Scalibility: VIPR is scaleable. Any number of domains can 488 participate. 490 Self-Scale: VIPR self-scales. This means that the amount of 491 computation, memory, and bandwidth that a domain must deploy 492 scales in direct proportion to the size of their own user base. 494 Self-Learning: VIPR is completely automated. A domain does not 495 require configuration of any information about another domain. It 496 does not require provisioning of IP addresses, domain names, 497 certificates, phone number prefixes or routing rules. 499 Automated Anti-Spam VIPR has a built-in mechanism for preventing SIP 500 spam, which is specific to SIP. It is fundamentally different 501 from existing SIP anti-spam techniques which borrow from email 502 [RFC5039]. This new technique is fully automated, and requires no 503 configuration by administrators and no participation from end 504 users. 506 Feature Velocity: VIPR enables direct SIP connections between two 507 domains seeking to federate. There are no SIP intermediaries of 508 any sort between the two. This means that domains have no 509 dependencies on intermediaries for deployment of new features. 511 Secure: Security is a fundamental part of VIPR and cannot be 512 disabled. 514 Reliable: VIPR is reliable. Through its hybridization of the PSTN 515 and the Internet, it ensures that calls always go through, even in 516 cases of network failure or limited IP connectivity. 518 In order to achieve a solution with these properties, past 519 assumptions about how federations should work must be challenged. 521 6.2. Challenging Past Assumptions 523 Two unstated assumptions of SIP federation are challenged by VIPR. 525 The first assumption that federation solutions have made is this: 527 The purpose of SIP federation is to eliminate the PSTN, and 528 consequently, we cannot assume the PSTN itself as part of the 529 solution. 531 Though unstated, this assumption has clearly been part of the design 532 of existing solutions. SIP federation based on email-style URIs, as 533 defined in RFC 3261, doesn't utilize nor make mention of the PSTN. 534 Solutions like ENUM, or private registries, also do not utilize nor 535 make mention of the PSTN. However, such approaches ignore an 536 incremental solution - a solution which utilizes the PSTN itself to 537 solve the hard problems in SIP federation. 539 There are many advantages to leveraging the PSTN. It reaches 540 worldwide. It provides a global numbering translation service that 541 maps phone numbers to circuits. It is highly reliable, and provides 542 QoS. It has been built up over decades to achieve these goals. 543 Thus, building upon rather than replacing the PSTN, can provide the 544 necessary functionality once another assumption is challenged. 546 This second assumption is: 548 A federation solution must be the same as the final target 549 federation architecture, and not just a step towards it. 551 SIP's email-style federation was a pure 'target architecture'. ENUM 552 was the same - a worldwide global DNS database with everyone's phone 553 numbers providing open connectivity. 555 Historically, technologies are more successful when they are 556 incrementally deployable. As such, VIPR is very much focused on 557 incremental deployability. It discards the notion of perfect IP 558 federation for a solution that federates most, but not all calls, by 559 relying on the PSTN to fill in the gaps. 561 6.3. Technical Overview 563 A high level view of the VIPR architecture with an example is shown 564 in Figure 1. The figure shows four different domains, example.com, 565 example.net, example.org and example.edu, federated using VIPR 566 technology. Each domain is connected to both the public Internet and 567 to the traditional PSTN. For simplicity, the connection for the call 568 agents in example.org and example.edu to the PSTN is not indicated in 569 the diagram as that interface is not relevant to the subsequent 570 examples. 572 +-------+ +-------+ 573 | Call | | Call | 574 example.org | Agent | | Agent | example.edu 575 | | | | 576 +-------+ +-------+ 577 \ / 578 \ / 579 \ / 580 \ / 581 | 582 //--------\\ 583 |// \\| 584 | Internet | 585 +-------+ |\\ //| +-------+ 586 | Call |------ \\ _______//------| Call | 587 //\\ | Agent | | Agent | //\\ 588 \ / | | | | \ / 589 \/ ---| | +-----------+ | |---- \/ 590 User | |======| |======| | User 591 Agent +-------+ | PSTN | +-------+ Agent 592 example.com | | example.net 593 +-----------+ 595 Figure 1: High Level Architecture 597 For purposes of explanation, it is easiest to think of each domain as 598 having a single call agent which participates in the federation 599 solution. The functionality is decomposed into several sub- 600 components, and this is discussed in more detail below. The call 601 agent is connected to one or more user agents in the domain, and is 602 responsible for routing calls, handling features, and processing call 603 state. The call agent is stateful, and is aware of when calls start 604 and stop. Additional detail for the functional components of this 605 architecture are provided in [I-D.petithuguenin-vipr-framework]. 607 Assume that all four domains have a 'fresh' installation of VIPR, and 608 that domain example.net 'owns' +1 408 555 5xxx, a block of 1000 609 numbers allocated by its PSTN provider. 611 The VIPR mechanism can be broken into four basic steps: storage of 612 phone numbers, PSTN first call, validation and caching, and 613 subsequent SIP call(s). 615 6.3.1. Storage of Phone Numbers 617 The first step is that the call agents form a single, worldwide P2P 618 network, using a VIPR specific usage 619 [I-D.petithuguenin-vipr-reload-usage] of RELOAD 620 [I-D.ietf-p2psip-base] with a variant of the Chord algorithm. This 621 P2P network forms a distributed hash table (DHT) running amongst all 622 participating domains. A distributed hash table is like a simple 623 database, allowing storage of key-value pairs, and lookup of objects 624 by key. Unlike a normal hash table, which resides in the memory of a 625 single computer, a distributed hash table is spread across all of the 626 servers which make up the P2P network. In this case, it is spread 627 across all of the domains participating in the VIPR federation. 629 The problem solved by the variant of the Chord algorithm (and by 630 other DHT algorithms), is an answer to the following: given that the 631 desired operation is to read or write an object with key K, which 632 node in the DHT is the box that currently stores the object with that 633 key? The P2P SIP variant of the Chord algorithm provides an 634 algorithm which routes read and write operations through nodes in the 635 DHT until they eventually arrive at the right place. With Chord, 636 this will take no more than log2N hops, where N is the number of 637 nodes in the DHT. Consequently, for a DHT with 1024 nodes, 10 hops 638 are required in the worst case. For 2048, 11 hops. And so on. The 639 logarithmic factor allows DHTs to achieve efficient scale and to 640 provide a large amount of storage summed across all of the nodes that 641 make up the DHT. 643 This logarithmic hopping behavior also means that each node in the 644 DHT does not need to establish a TCP/TLS connection to every other 645 node. Rather, connections are established to a smaller subset - just 646 log(N) of the nodes. 648 In DHTs, each participating entity is identified by a Node-ID. The 649 Node-ID is a 128 bit number, assigned randomly to each entity. They 650 have no inherent semantic meaning; they are not like domain names or 651 IP addresses. 653 In the case of VIPR, each call agent is identified by one or more 654 Node-IDs. For purposes of discussion, consider the case where the 655 call agent has just one Node-ID. Each participating domain, 656 including example.net in our example, uses the DHT to store a mapping 657 from each phone number that it owns, to the domain's Node-ID. In the 658 case of example.net, it would store 1000 entries into the DHT, each 659 one being a mapping from one of its phone numbers, to the domain's 660 Node-ID. Furthermore, when the mappings are stored, the mapping is 661 actually from the SHA-1 hash of the phone number, to the Node-ID of 662 the call agent which claims ownership of that number. 664 For example, if the Node-ID of the call agent in domain example.net 665 is 0x1234 (a shorter 16 bit value to simplify discussion), the 666 entries stored into the DHT by example.net would be: 668 Key | Value 669 ---------------------------------- 670 SHA1(+14085555000) | 0x1234 671 SHA1(+14085555001) | 0x1234 672 SHA1(+14085555002) | 0x1234 673 ..... 674 SHA1(+14085555999) | 0x1234 676 Figure 2: DHT Contents 678 It is important to note that the DHT does not contain phone numbers 679 (it contains hashes of them), nor does it contain IP addresses or 680 domain names. Instead, it is a mapping from the hash of a phone 681 number (in E.164 format) to a Node-ID. 683 example.net will store this mapping when it starts up, or when a new 684 number is provisioned. The information is refreshed periodically by 685 example.net. The actual server on which these mappings are stored 686 depends on the variant of the Chord algorithm. Typically, the 687 entries will be uniformly distributed amongst all of the call agents 688 participating in the network. 690 6.3.2. PSTN First Call 692 At some point, a user agent (Alice) in example.com makes a call to +1 693 408 555 5432, which is her colleague Bob. Even though both sides have 694 VIPR, the call takes place over the plain old PSTN, per Figure 3. 695 Alice talks to Bob for a bit, and they hang up. 697 +-------+ +-------+ 698 | Call | | Call | 699 //\\ | Agent | | Agent | //\\ 700 \ / | | | | \ / 701 \/ ---| | +-----------+ | |---- \/ 702 Alice | |<=======<========>======>| | Bob 703 +-------+ | PSTN | +-------+ 704 example.com | | example.net 705 +-----------+ 707 Figure 3: PSTN First Call 709 At a random point in time after the call has completed, the call 710 agent in example.com "wakes up" and says to itself, "that's 711 interesting, someone in my domain called +1 408 555 5432, and it went 712 over the PSTN. I wonder if that number is reachable over IP 713 instead?". To make this determination, it hashes the called phone 714 number, and looks it up in the DHT. It is important to note that 715 this lookup is not at the time of an actual phone call - this lookup 716 process happens outside of any phone call, and is a background 717 process. 719 The query for +1 408 555 5432 will traverse the DHT, and eventually 720 arrive at the node that is responsible for storing the mapping for 721 that number. Typically, that node will not be example.net, but 722 rather one of the other nodes in the network (e.g., example.org). In 723 many cases, the called number will not find a matching mapping in the 724 DHT. This happens when the number that was dialed is not owned by a 725 domain participating in VIPR. When that happens, example.com takes 726 no further action. Next time there is another call to the same 727 number, it will repeat the process and check once more whether the 728 dialed number is in the DHT. 730 In this case, there is a match in the DHT, and example.com learns the 731 Node-ID of example.net. It then proceeds to the validation step per 732 Section 6.3.3. It is also possible that there are multiple matches 733 in the DHT. This can happen if another domain - example.edu for 734 example - also claims ownership of that number. When there are 735 multiple matching results, example.com learns all of them, and 736 performs the validation step with each. 738 6.3.3. Validation and Caching 740 Why not just store the domain in the DHT, instead of the Node-ID? If 741 the domain was stored in the DHT, once example.com performed the 742 lookup, it would immediately learn that the number maps to 743 example.net, and could then make a direct SIP call next time. 745 The main reason this doesn't work is security. The information in 746 the DHT is completely untrusted. There is nothing so far that 747 enables example.com to know that example.net does, in fact, own the 748 phone number in question. Indeed, if multiple domains make a claim 749 on the number, it has no way to know which one (if any) actually owns 750 it. 752 To address this critical problem, VIPR requires a mechanism called 753 phone number validation. Phone number validation is a key concept in 754 VIPR. There are several models for this validation as detailed in 755 [I-D.petithuguenin-vipr-pvp]. The essential idea is that example.com 756 will connect to the example.net server, by asking the DHT to form a 757 connection to example.net's Node-ID. Once connected, example.com 758 demands proof of ownership of the phone number. This proof comes in 759 the form of demonstrated knowledge of the previous PSTN call. When a 760 call was placed from example.com to +1 408 555 5432, the details of 761 that call - including its caller ID, start time, and stop time, 762 create a shared secret referred to as a "ticket", - information that 763 is only known to entities that participated in the call. Thus, to 764 obtain proof that example.net really owns the number in question, 765 example.com will demand a knowledge proof - that example.net is aware 766 of the details of the call. A consequence of this is that the 767 following property is maintained: 769 A domain can only call a specific number over SIP, if it had 770 previously called that exact same number over the PSTN. 772 This property is key in fighting spam and denial-of-service attacks. 773 Because calling numbers on the PSTN costs money - especially 774 international calls - VIPR creates a financial disincentive for 775 spammers. For a spammer to ring every phone in a domain with a SIP 776 call, it must have previously called every number in the domain with 777 a PSTN call, and had a successfully completed call to each and every 778 one of them. [I-D.petithuguenin-vipr-sip-antispam] provides an 779 overview and further details on the security mechanisms for VIPR for 780 mitigation of SPAM. 782 There are a great many details required for this validation protocol 783 to be secured. For example, the mechanism needs to handle the fact 784 that call start and stop times won't exactly match on both sides. It 785 needs to deal with the fact that many calls start on the top of the 786 hour. It needs to deal with the fact that caller ID is not often 787 delivered, and when it is delivered, is not reliable. It needs to 788 deal with the fact that example.com may in fact be the attacker, 789 trying to use the validation protocol to extract the shared secret 790 from example.net. All of this is, in fact, handled by the protocol. 791 The protocol is based on the Secure Remote Password for TLS 792 Authentication (SRP-TLS) [RFC5054], and is described more fully in 793 [I-D.petithuguenin-vipr-pvp]. 795 Towards the end of the validation process, domains example.com and 796 example.net had determined that each was, in fact in possession of 797 the shared secret information about the prior PSTN call. However, 798 neither side has any information about the domain names of the other 799 side. 801 At the end of the validation process, both example.com and 802 example.net have been able to ascertain that the other side did in 803 fact participate in the previous PSTN call. At that point, 804 example.com sends its domain name to example.net as shown in Figure 805 4. 807 +-------+ +-------+ 808 | Call | | Call | 809 example.org | Agent | | Agent | example.edu 810 | | | | 811 +-------+ +-------+ 812 \ / 813 +----------------------+ \ / 814 | Hi, I am example.com.| \ / 815 | How do I reach you? | \ / 816 +--------------\-------+ //-------\\ 817 \ // \\ 818 +===\======>========>========>=====+ 819 ^ | Internet | | 820 | | | v 821 +-------+ |\\ //| +-------+ 822 | Call |------ \\ _______//------| Call | 823 //\\ | Agent | | Agent | //\\ 824 \ / | | | | \ / 825 \/ ---| | | |---- \/ 826 Alice | | | | Bob 827 +-------+ +-------+ 828 example.com example.net 830 Figure 4: Ticket Validation Step 1 832 Next, the example.net domain generates the ticket. The ticket has 833 three fundamental parts to it: 835 1. The phone number that was just validated - in this case, +1 408 836 555 5432. 838 2. The domain name that the originating side claims it has - 839 example.com in this case. 841 3. A signature generated by example.net, using a key known to itself 842 only, over the other two pieces of information. 844 Then, example.net sends to example.com - all over a secured channel - 845 a SIP URI to use for routing calls to this number, and a ticket, as 846 shown in Figure 5. The ticket is a cryptographic object, opaque to 847 example.com, but used by example.net to allow incoming SIP calls. It 848 is similar in concept to kerberos tickets - it is a grant of access. 849 In this case, it is a grant of access for example.com to call +1 408 850 555 5432, and only +1 408 555 5432. 852 +-------+ +-------+ 853 | Call | | Call | 854 example.org | Agent | | Agent | example.edu 855 | | | | 856 +-------+ +-------+ 857 \ / 858 \ / +------------------------+ 859 \ / | Here is your ticket | 860 \ / | & SIP URI to reach Bob | 861 //-------\\ +----/-------------------+ 862 // \\ / 863 +==========<========<========<===/=+ 864 | | Internet | ^ 865 v | | | 866 +-------+ |\\ //| +-------+ 867 | Call |------ \\ _______//------| Call | 868 //\\ | Agent | | Agent | //\\ 869 \ / | | | | \ / 870 \/ ---| | | |---- \/ 871 Alice | | | | Bob 872 +-------+ +-------+ 873 example.com example.net 875 Figure 5: Ticket Validation Step 2 877 The example.com call agent receives the SIP URI and ticket, and 878 stores both of them in an internal cache. This cache builds up 879 slowly over time, containing the phone number, SIP URI, and ticket, 880 for those numbers which are called by example.com and validated using 881 VIPR. Because the cache entries are only built for numbers which 882 have actually been called by users in the enterprise, the size of the 883 cache self-scales. A call agent supporting only ten users will build 884 up a cache proportional to the volume of numbers called by ten 885 people, whereas a call agent supporting ten thousand users will build 886 up a cache which is typically a thousand times larger. 888 This cache, containing the phone number, SIP URI and ticket will be 889 accessed later when Alice (or another caller from the same call 890 agent) makes another call to Bob, as detailed in Section 6.3.4. 892 6.3.4. SIP Call 894 At some point in the future, another call is made to +1 408 555 5432. 895 The caller could be Alice, or it could be any other user attached to 896 the same call agent. This time, the call agent notes that it has a 897 cached entry (including the SIP URI and ticket) for the number in 898 question. It is possible that there are multiple entries for a given 899 number. For example, both an Enterprise and Service Provider may 900 register the same number in the RELOAD distributed database. It may 901 also be possible to fork a call using the multiple entries . 902 [Editor's note: this requires further discussion as to whether we 903 want to allow multiple entries.] 905 The example.com call agent attempts to contact the SIP URI by 906 establishing a TCP/TLS connection to the SIP URI it learned. If a 907 connection cannot be made and there are no other cached entries for 908 the number in question, the call agent proceeds with the call over 909 the PSTN. This ensures that, in the event of an Internet failure or 910 server failure, the call can still proceed. Assuming the connection 911 is established, the example.com call agent sends a SIP INVITE to the 912 terminating call agent, over this newly formed secure connection. 913 The SIP INVITE request also contains the ticket, placed into a new 914 SIP header field in the message. 916 When the SIP INVITE arrives at the example.net call agent, the call 917 agent can extract the ticket from the new SIP header field. This 918 ticket is an object, opaque to example.com, that was previously 919 generated by the example.net call agent as described in 920 Section 6.3.3. example.net first verifies the signature over the 921 ticket. Remember that the example.net agent is the one that 922 generated the ticket in the first place; as such, it is in possession 923 of the key required to validate the signature. Once validated, it 924 performs two checks: 926 1. It compares the phone number in the call setup request (the 927 Request URI) against the phone number stored in the ticket. 929 2. It compares the domain name of the calling domain, learned from 930 the certificates in the mutual TLS exchange, against the domain 931 name stored in the ticket. 933 If both match, the example.net call agent knows that the calling 934 party is in fact the domain they claimed previously, and that they 935 had in fact gone through the validation process successfully for the 936 number in question. At this time, the call is now completed per 937 normal SIP processing. 939 7. Security Considerations 941 This section provides an overview of some of the key threats and how 942 they are handled at a high level. Note that the detailed security 943 solutions to handle the threats are detailed in the other relevant 944 VIPR documents as referenced in the sections below. 946 7.1. Attacks on the DHT 948 Attackers could attempt to disrupt service through a variety of 949 attacks on the DHT. 951 Firstly, it must be noted that the DHT is never used at call setup 952 time. It is accessed as a background task, solely to learn NEW 953 numbers and SIP URIs that are not already known. If an attacker was 954 able to completely destroy the P2P network, it would not result in a 955 single call to fail. Furthermore, it would not cause calls to revert 956 to the PSTN - calls to SIP URIs learned previously would still go 957 over the IP network. The only impact to such a devastating attack is 958 that a domain could not learn SIP URIs for new numbers, until the DHT 959 is restored to service. This service failure is hard for users and 960 administrators to even notice. 962 That said, VIPR prevents many of these attacks. The DHT itself is 963 secured using TLS - its usage is mandatory. Quota mechanisms are put 964 into place that prevent an attacker from storing large amounts of 965 data in the DHT as described in 966 [I-D.petithuguenin-vipr-proportional-quota]. Other attacks are 967 prevented by mechanisms defined by RELOAD [I-D.ietf-p2psip-base] 968 itself, and are not VIPR specific. 970 7.2. Theft of Phone Numbers 972 A key security threat that VIPR is trying to address is the theft of 973 phone numbers. In particular, a malicious domain could store, in the 974 DHT, phone numbers that it does not own, in an attempt to steal calls 975 targeted to those numbers. This attack is prevented by the core 976 validation mechanism as described in [I-D.petithuguenin-vipr-pvp] , 977 which performs a proof of knowledge check to verify ownership of 978 numbers. 980 An attacker could try to claim numbers it doesn't own, which are 981 claimed legitimately by other domains in the VIPR network. This 982 attack is prevented as well. Each domain storing information into 983 the DHT can never overwrite information stored by another domain. As 984 a consequence, if two domains claim the same number, two records are 985 stored in the DHT. An originating domain will validate against both, 986 and only one will validate - the real owner. 988 An attacker could actually own a phone number, use it for a while, 989 validate with it, and build up a cache of routes at other domains. 990 Then, it gives back the phone number to the PSTN provider, who 991 allocates it to someone else. However, the attacker still claims 992 ownership of the number, even though they no longer have it. This 993 attack is prevented by expiring the learned routes after a while. 994 Typically, operators do not re-assign a number for a few months, to 995 allow out-of-service messages to be played to people that still have 996 the old number. Thus, the TTL for cached routes is set to match the 997 duration that carriers typically hold numbers. 999 An attacker could advertise a lot of numbers, most of which are 1000 correct, some of which are not. VIPR prevents this by requiring each 1001 number to be validated individually. 1003 An attacker could make a call so they know the call details of the 1004 call they made and use this to forge a validation for that call. 1005 They could then try to convince other users, which would have to be 1006 in the same domain as the attacker, to trust this validation. This 1007 is mitigated by not sharing validations inside of domains where the 1008 users that can originate call from that domain are not trusted by the 1009 domain. 1011 7.3. Spam 1013 Another serious concern is that attackers may try to launch SIP spam 1014 (also known as SPIT) calls into a domain. As described in 1015 Section 6.3.3 and as detailed in 1016 [I-D.petithuguenin-vipr-sip-antispam], VIPR prevents this by 1017 requiring that a domain make a PSTN call to a number before it will 1018 allow a SIP call to be accepted to that same number. This provides a 1019 financial disincentive to spammers. The current relatively high cost 1020 of international calling, and the presence of national do-not-call 1021 regulations, have prevented spam on the PSTN to a large degree. VIPR 1022 applies those same protections to SIP connections. 1024 VIPR still lowers the cost of communications, but it does so by 1025 amortizing that savings over a large number of calls. The costs of 1026 communications remain high for infrequent calls to many numbers, and 1027 become low for frequent calls to a smaller set of numbers. Since the 1028 former is more interesting to spammers, VIPR gears its cost 1029 incentives away from the spammers, and towards domains which 1030 collaborate frequently. 1032 It is important to note that VIPR does not completely address the 1033 spam problem. A large spamming clearing house organization could 1034 actually incur the costs of launching the PSTN calls to numbers, and 1035 then, in turn, act as a conduit allowing other spammers to launch 1036 their calls to those numbers for a fee. The clearinghouse would 1037 actually need to transit the signaling traffic (or, divulge the 1038 private keys to their domain name), which would incur some cost. As 1039 such, while this is not an impossible situation, the barrier is set 1040 reasonably high to start with - high enough that it is likely to 1041 deter spammers until it becomes a highly attractive target, at which 1042 point other mechanisms can be brought to bear. 1044 7.4. Eavesdropping 1046 Another class of attacks involves outsiders attempting to listen in 1047 on the calls that run over the Internet, or obtain information about 1048 the call through observation of signaling. 1050 All of these attacks are prevented by requiring the usage of SIP over 1051 TLS and SRTP. These are mandatory to use. 1053 7.5. Privacy Leakage and Malicious Servers 1054 A further form of attack involves adding malicious VIPR servers to a 1055 widely implemented (e.g., national or international) RELOAD overlay. 1056 This attack is specific to an uncontrolled RELOAD overlay, in which 1057 any individual or enterprise could add their own VIPR server to the 1058 overlay without authorization, verification or bias. 1060 In this scenario, a malicious VIPR server could be used for analyzing 1061 number registration information for the purpose of spying on called 1062 numbers associated with various participating parties. The 1063 likelihood of this occurring on a large scale is small, because it 1064 might require a prohibitive (and easily-detectable) number of VIPR 1065 servers to capture all of the number registrations of a region under 1066 surveillance; however, more targeted attacks are feasible and should 1067 be recognized as a potential security consideration. 1069 This security breach can occur because all registrations are 1070 considered equally untrusted, and they will be verified by 1071 establishing a TCP connection between the VIPR server of the source 1072 of the call and the VIPR server that stored the registration for a 1073 particular phone number. Multiple pieces of identifying information 1074 are necessarily leaked in this verification process, but it is 1075 specifically easy to identify the enterprise originating the TCP 1076 connection by comparing its source address to public registry data 1077 (such as in-addr.arpa). 1079 For destination phone numbers using VIPR, the vulnerability arises 1080 because the RELOAD overlay permits multiple entities to register for 1081 the same number. The VIPR server at the source of the call may 1082 therefore discover multiple candidate registrations; although 1083 malicious servers registering themselves will not possess the call 1084 details necessary to generate a shared secret, they may learn 1085 sensitive information merely through participating in the 1086 verification process. While it is possible that the real owner of 1087 the number may be tried first and prevent other registrations to be 1088 tried if successful, an attacker could register from multiple VIPR 1089 servers in order to improve their chances of receiving a verification 1090 request. One could easily imagine an attacker determined to learn 1091 who will call a particular number generating a large set of 1092 registrations that would make it very unlikely for the authentic 1093 server to be selected first; with enough such registrations it might 1094 effectively become a denial of service attack. Note however that 1095 this problem is limited to server discovery: as soon as the real 1096 owner sends a SIP route and ticket back, the malicious VIPR server 1097 would no longer receive any information about the calls between the 1098 enterprise and the destination number, with exception of the periodic 1099 renewal of the ticket. 1101 The possible disclosed information includes more than the just the 1102 connection verification. Here is a list of potential leaked 1103 information: 1105 If the malicious VIPR servers leverage a different VServiceId for 1106 each registered phone number, the called number is always leaked. 1108 The called number is leaked during the validation process for both 1109 methods A and B [draft-petithuguenin-vipr-pvp-04, Section 7.2.1, 1110 Section 7.2.2]. 1112 For method A, the caller-ID is leaked (this is encrypted, but it 1113 is possible to decrypt). 1115 For method B, a random time in the middle of the call is leaked. 1117 For method C, the rounded start and stop time of the call are 1118 leaked. 1120 The source IP address of the TCP connection for the PVP 1121 transaction is always leaked. 1123 The addr_port in the AppAttachReq RELOAD message that was used to 1124 establish the TCP connection is leaked. [draft-ietf-p2psip- 1125 base-24] 1127 The certificate of the signer of the AppAttachReq RELOAD message 1128 is leaked. While the certificate does not contain information 1129 about the sender, but it always contains the Node-ID, which can 1130 always be resolved to an IP address by using an Attach request. 1132 8. IANA Considerations 1134 This specification does not require any actions from IANA. 1136 9. Acknowledgements 1138 Thanks for review comments from Ken Fischer, Rob Maidhof, Michael 1139 Procter, Eric Burger, Richard Barnes and others. Thanks to Theo 1140 Zourzouvillys for pointing out the 5th theft of phone numbers attack 1141 as described in Section 7.2 . 1143 10. References 1145 10.1. Normative References 1147 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1148 Requirement Levels", BCP 14, RFC 2119, March 1997. 1150 10.2. Informative References 1152 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1153 A., Peterson, J., Sparks, R., Handley, M., and E. 1154 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1155 June 2002. 1157 [I-D.ietf-p2psip-base] 1158 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 1159 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 1160 Base Protocol", draft-ietf-p2psip-base-26 (work in 1161 progress), February 2013. 1163 [I-D.petithuguenin-vipr-reload-usage] 1164 Petit-Huguenin, M., Rosenberg, J., and C. Jennings, "A 1165 Usage of Resource Location and Discovery (RELOAD) for 1166 Public Switched Telephone Network (PSTN) Verification", 1167 draft-petithuguenin-vipr-reload-usage-04 (work in 1168 progress), March 2012. 1170 [I-D.petithuguenin-vipr-framework] 1171 Petit-Huguenin, M., Jennings, C., and J. Rosenberg, 1172 "Verification Involving PSTN Reachability (VIPR): 1173 Framework", draft-petithuguenin-vipr-framework-00 (work in 1174 progress), October 2011. 1176 [I-D.petithuguenin-vipr-sip-antispam] 1177 Petit-Huguenin, M., Rosenberg, J., and C. Jennings, 1178 "Session Initiation Protocol (SIP) Extensions for Blocking 1179 VoIP Spam Using PSTN Validation", draft-petithuguenin- 1180 vipr-sip-antispam-03 (work in progress), January 2012. 1182 [I-D.jennings-vipr-vap] 1183 Jennings, C., Rosenberg, J., and M. Petit-Huguenin, 1184 "Verification Involving PSTN Reachability: The ViPR Access 1185 Protocol (VAP)", draft-jennings-vipr-vap-02 (work in 1186 progress), March 2012. 1188 [I-D.petithuguenin-vipr-pvp] 1189 Petit-Huguenin, M., Rosenberg, J., and C. Jennings, "The 1190 Public Switched Telephone Network (PSTN) Validation 1191 Protocol (PVP)", draft-petithuguenin-vipr-pvp-04 (work in 1192 progress), March 2012. 1194 [I-D.petithuguenin-vipr-proportional-quota] 1195 Petit-Huguenin, M., Rosenberg, J., and C. Jennings, 1196 "Proportional Quota in REsource LOcation And Discovery 1197 (RELOAD)", draft-petithuguenin-vipr-proportional-quota-00 1198 (work in progress), October 2011. 1200 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1201 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1202 March 1999. 1204 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1205 Protocol (SIP): Locating SIP Servers", RFC 3263, June 1206 2002. 1208 [E.164] ITU-T, "The International Public Telecommunication Number 1209 Plan", Recommendation E.164, May 1997. 1211 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 1212 Protocol (SIP) and Spam", RFC 5039, January 2008. 1214 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1215 Uniform Resource Identifiers (URI) Dynamic Delegation 1216 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1217 March 2011. 1219 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 1220 Requirements", RFC 5067, November 2007. 1222 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 1223 "Using the Secure Remote Password (SRP) Protocol for TLS 1224 Authentication", RFC 5054, November 2007. 1226 [RFC6873] Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 1227 Session Initiation Protocol (SIP) Common Log Format 1228 (CLF)", RFC 6873, February 2013. 1230 [I-D.jones-insipid-session-id] 1231 Jones, P., Pearce, C., Polk, J., and G. Salgueiro, "End- 1232 to-End Session Identification in IP-Based Multimedia 1233 Communication Networks", draft-jones-insipid-session-id-02 1234 (work in progress), February 2013. 1236 [I-D.ietf-insipid-session-id-reqts] 1237 Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. 1238 Kaplan, "Requirements for an End-to-End Session 1239 Identification in IP-Based Multimedia Communication 1240 Networks", draft-ietf-insipid-session-id-reqts-08 (work in 1241 progress), July 2013. 1243 Appendix A. Changes since last version 1245 This section must be removed before publication as an RFC. 1247 Modifications between jennings-04 and jennings-03: 1249 1. Updating references to SIPCLF and Session ID (INSIPID) documents. 1251 Modifications between jennings-03 and jennings-02: 1253 1. Reworded REQ -11 to clarify that in the case of call failures 1254 (i.e., IP calls), the system should fallback to inter-domain 1255 calling prior to VIPR. 1257 2. Deleted REQ-12 (Handover) since it's really not specific 1258 functionality provided by VIPR. 1260 3. Moved some text from the -01 version in the Technical Overview 1261 section back into the doc (not sure why it was removed 1262 previously). 1264 4. Other editorial changes: 1266 - Added a Terminology section. 1268 - Clarified the use of the term "Call Agent". 1270 - Reworded discussion of email in section 2.2 (i.e., it's not 1271 useless). 1273 - Either changed or removed altogether terms like "neat", 1274 "clever", "incredible", "enormous" and any text that read like 1275 marketing literature as much as possible. 1277 - Removed some of the more subjective and superfluous language - 1278 i.e., condensed the text to be more concise (Section 5.2 and many 1279 others per the previous change) 1281 - Deleted explicit reference to "SIP Trunking" as the statement 1282 didn't introduce additional information in that paragraph and the 1283 term is not defined in this document. 1285 - and other minor editorial fixes. 1287 Modifications between jennings-02 and jennings-01: 1289 1. Sections 6,7,8 moved to new VIPR framework document. 1291 2. Editorial changes. 1293 3. Clarifications to re-enforce that the primary objective is not 1294 PSTN bypass but rather to enable enhanced services such as video 1295 between domains. Changed "VoIP" to "SIP" since the focus is not 1296 specifically voice. 1298 4. Added reference for new framework document. 1300 5. Section 5.3: Added references to other documents as appropriate - 1301 e.g., -pvp, -spam, etc. 1303 6. Moved validation diagrams and text (from 5.3.4) into Validation 1304 and caching section (5.3.3). 1306 7. Condensed discussion of spam in section 5.3.3 and updated SPAM 1307 section in security section. 1309 Modifications between jennings-01 and rosenberg-04: 1311 o Not specified. 1313 Modifications between rosenberg-04 and rosenberg-03 1315 o Nits. 1317 o Shorter I-Ds references. 1319 o Changed phone numbers to follow E.123 presentation. 1321 o Expanded P2P initialisms. 1323 o Uses +1 408 555 prefix for phone numbers in examples. 1325 Authors' Addresses 1327 Mary Barnes 1328 Polycom 1329 TX 1330 US 1332 Email: mary.ietf.barnes@gmail.com 1333 Cullen Jennings 1334 Cisco 1335 170 West Tasman Drive 1336 MS: SJC-21/2 1337 San Jose, CA 95134 1338 USA 1340 Phone: +1 408 421-9990 1341 Email: fluffy@cisco.com 1343 Jonathan Rosenberg 1344 jdrosen.net 1345 Monmouth, NJ 1346 US 1348 Email: jdrosen@jdrosen.net 1349 URI: http://www.jdrosen.net 1351 Marc Petit-Huguenin 1352 Unaffiliated 1354 Email: petithug@acm.org