idnits 2.17.1 draft-jennings-vipr-overview-04.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 (February 25, 2013) is 4076 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) == Unused Reference: 'I-D.jennings-vipr-vap' is defined on line 1059, 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-04 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: Standards Track C. Jennings 5 Expires: August 29, 2013 Cisco 6 J. Rosenberg 7 jdrosen.net 8 M. Petit-Huguenin 9 Unaffiliated 10 February 25, 2013 12 Verification Involving PSTN Reachability: Requirements and Architecture 13 Overview 14 draft-jennings-vipr-overview-04 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 new model and technique for inter-domain federation 26 with SIP involving the Public Switched Telephone Network (PSTN), 27 called Verification Involving PSTN Reachability (VIPR). VIPR 28 addresses the problems that have prevented inter-domain federation 29 over the Internet. It provides fully distributed inter-domain 30 routing for phone numbers, authorized mappings from phone numbers to 31 domains, a new technique for automated SIP anti-spam, and privacy of 32 number 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 August 29, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 69 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. The Phone Number Routing Problem . . . . . . . . . . . . . 5 71 3.2. The Open Pinhole Problem . . . . . . . . . . . . . . . . . 6 72 3.3. Quality of Service Problem . . . . . . . . . . . . . . . . 7 73 3.4. Troubleshooting Problem . . . . . . . . . . . . . . . . . 7 74 4. Summary of Existing Solutions . . . . . . . . . . . . . . . . 8 75 4.1. Domain Routing . . . . . . . . . . . . . . . . . . . . . . 8 76 4.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.3. Private Federations . . . . . . . . . . . . . . . . . . . 9 78 5. Key Requirements . . . . . . . . . . . . . . . . . . . . . . . 10 79 6. Executive Overview . . . . . . . . . . . . . . . . . . . . . . 10 80 6.1. Key Properties . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 21 90 7.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 7.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 23 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 96 10.2. Informative References . . . . . . . . . . . . . . . . . . 25 97 Appendix A. Changes since last version . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 100 1. Introduction 102 The Session Initiation Protocol (SIP) was originally published as 103 [RFC2543] in May of 1999. This was followed by subsequent 104 publication of [RFC3261], which brought the protocol to sufficient 105 maturity to enable large scale market adoption. 107 SIP has achieved large scale market adoption with hundreds of 108 implementations, spanning consumer products, enterprise servers, and 109 large scale carrier equipment. It carries billions and billions of 110 minutes of calls, and has become the standard for interconnection 111 between products from different vendors. If one measures success in 112 deployment, then clearly SIP is a success. 114 SIP was designed from the ground up to enable communications between 115 users in different domains, all over the public Internet. The 116 intention was that real-time communications should be no different 117 than email or the web, with the same any-to-any connectivity that has 118 fueled the successes of those technologies. However, when SIP is 119 used between domains, it is typically through private federation 120 agreements. While such agreements are positive, they have typically 121 been limited to voice, which has limited the use of video and the 122 growth of advanced SIP features, thus preventing the innovation that 123 SIP was expected to drive. Thus, the any-to-any Internet federation 124 model envisioned by SIP has not materialized at scale. 126 This document introduces a new technology, called Verification 127 Involving PSTN Reachability (VIPR), that breaks down the barriers 128 that have prevented inter-domain voice, video and other multimedia 129 services. By stepping back and changing some of the most fundamental 130 assumptions about federation, VIPR is able to address the key 131 problems preventing its deployment. VIPR focuses on incremental 132 deployability. At the same time, VIPR ensures that SIP's trapezoidal 133 model of direct federation between domains without any intermediate 134 processing beyond IP transport is realized. That model is required 135 in order to allow innovative new services to be deployed. 137 2. Conventions and Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in 142 [RFC2119]. 144 Call Agent: An entity in a SIP enabled domain that supports VIPR. 145 The Call Agent performs call processing on behalf of one or more 146 user agents represented by E.164 numbers within the domain. 147 Ticket: A shared secret that is generated after a PSTN call to 148 enable secure call setup on a subsequent inter-domain IP call 149 enabled by VIPR. 150 User Agent: As defined in [RFC3261], with the restriction that the 151 user agent must have an associated E.164 number. 153 3. Problem Statement 155 The first question that must be asked is this - why haven't we seen 156 widespread adoption of inter-domain SIP federation? The reason for 157 this is due to problems with the following - summarized in order of 158 importance/impact: 160 1. Phone number routing 161 2. Open pinhole 162 3. Quality of service 163 4. Troubleshooting 165 The first two are the most significant. 167 3.1. The Phone Number Routing Problem 169 Inter-domain federation requires that the sending domain determine 170 the address of the receiving domain, in the form of a DNS name 171 (example.com) or one or more IP addresses that can be used to reach 172 the domain. In email and in the web, this is easy. The identifiers 173 used by those services - the email address and web URL respectively - 174 embed the address of the receiving domain. A simple DNS lookup is 175 all that is required to route the connection. SIP was designed to 176 use the same email-style identifiers. 178 However, most SIP deployments utilize phone numbers in the form of 179 E.164 numbers [E.164], and not email-style SIP URIs. This is due to 180 the huge installed base of users that continue to exist solely on the 181 PSTN. In order to be reached by users on the PSTN, and in order to 182 reach them, users in SIP deployments need to be assigned a PSTN phone 183 number. Users in SIP deployments need to place that phone number on 184 business cards, use it in their email signatures, and in general, 185 give it out to their friends and colleagues, in order to be reached. 186 While those users could additionally have an email style SIP URI, the 187 phone number serves as a single, global identifier that works for 188 receiving calls from users on the PSTN as well as users within the 189 same SIP domain. 191 There are several reasons why two identifiers are used when one will 192 suffice. The universality of PSTN phone numbers is the reason why 193 most SIP deployments continue to use them - often exclusively. 195 Another reason is that many SIP deployments utilize hardphones or 196 telephony adaptors, and the user interfaces on these devices - 197 patterned after existing phones - only allow phone number based 198 dialing. Consequently, these users are only allocated PSTN phone 199 numbers, and not email-style SIP URI. 201 Finally, a large number of SIP deployments are in domains where the 202 endpoints are not IP. Rather, they are circuit based devices, 203 connected to a SIP network through a gateway. SIP is used within the 204 core of the network, providing lower cost transit, or providing 205 add-on services. Clearly, in these deployments, only phone numbers 206 are used. 208 Consequently, to make inter-domain federation incrementally 209 deployable and widely applicable, it needs to work with PSTN phone 210 numbers rather than email-style SIP URIs. Telephone numbers, unlike 211 email addresses, do not provide any indication of the address of the 212 domain which "owns" the phone number. Indeed, the notion of phone 213 number ownership is somewhat cloudy. Phone numbers can be ported 214 between carriers. They can be assigned to a user or enterprise, and 215 then later re-assigned to someone else. Phone numbers are granted to 216 users and enterprises through a complex delegation process involving 217 the ITU, governments, and telecommunications carriers, often 218 involving local regulations that vary from country to country. 220 Therefore, in order to deploy inter-domain federation, domains are 221 required to utilize some kind of mechanism to map phone numbers to 222 the address of the domain to which calls should be routed. Though 223 several techniques have been developed to address this issue, none 224 have achieved large-scale Internet deployments. 226 3.2. The Open Pinhole Problem 228 The inter-domain federation mechanism built into SIP borrows heavily 229 from email. Each domain runs a SIP server on an open port. When one 230 domain wishes to contact another, it looks up the domain name in the 231 DNS, and connects to that server on the open port. Here, "open" 232 means that the server is reachable from anywhere on the public 233 Internet, and is not blocked by firewalls. 235 This simple design worked well in the early days of email. However, 236 the email system has now become plagued with spam. This has resulted 237 in administrators spending a significant amount of time maintaining 238 spam filters. This does not always benefit the end users as in some 239 cases valid emails are dropped without the user being notified. 240 Thus, administrators of SIP domains are rightfully concerned that if 241 they make a SIP server available for anyone on the Internet to 242 contact, it will open the floodgates for SIP spam, which is far more 243 disruptive than email-based spam [RFC5039]. Administrators are also 244 concerned that an open server will create a back-door for denial-of- 245 service and other attacks that can potentially disrupt their voice 246 and video services. Administrators are often not willing to take 247 that risk since voice deployments demand higher uptimes and better 248 levels of reliability than email, especially for enterprises. 250 Fears around spam and denial-of-service attacks, when put together, 251 form the "open pinhole problem" - that domains are not willing to 252 enable SIP on an open port facing the Internet. 254 To fix this, a new model for federation is needed - a model where 255 these problems are addressed as part of the fundamental design rather 256 than after the functionality has been deployed. 258 3.3. Quality of Service Problem 260 The Internet does not provide any Quality of Service (QoS) 261 guarantees. All traffic is best effort. This is not an issue for 262 data transaction services, like web and email. It is, however, a 263 concern when using real-time services, such as voice and video. 265 That said, there are a large number of existing SIP deployments that 266 run over the Internet. Though the lack of QoS is a concern, it has 267 not proven a barrier to deployment. It is believed that if if the 268 more fundamental issues - the phone number routing and open pinhole 269 problems - can be addressed, the QoS problem will be a non-issue. As 270 such, QoS is not discussed further in this or other VIPR 271 specifications. 273 3.4. Troubleshooting Problem 275 The final problem that is prohibing large scale inter-domain 276 federation is troubleshooting. When connecting calls between 277 domains, problems can occur. Calls can be blocked. Calls can be 278 misdelivered. Features sometimes don't work. There can be one-way 279 media or no media at all. The video may not start. Call quality can 280 be poor. 282 These problems are common in SIP deployments, and they are tough to 283 troubleshoot even within a single administrative domain. When real- 284 time services extend inter-domain, the problem becomes worse. 286 Fortunately, some work has been completed to improve the ability for 287 network administrators to diagnose SIP problems. A Common log format 288 [RFC6873] has been developed. Other work underway, such as 289 consistent session IDs [I-D.ietf-insipid-session-id-reqts] and 290 [I-D.jones-insipid-session-id] can help troubleshoot interdomain 291 calls. 293 In addition to the above, 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. Further consideration of necessary 296 built-in techniques for troubleshooting is required for successful 297 deployment of VIPR. 299 4. Summary of Existing Solutions 301 Given the value of inter-domain SIP federation, there are existing 302 deployed solutions summarized below. However, each solution approach 303 has fundamental limitations that have inhibited widespread 304 deployment. 306 4.1. Domain Routing 308 The first solution for SIP inter-domain federation is built into SIP 309 itself - domain routing. In this technique, users utilize email- 310 style SIP URIs as identifiers. By utilizing the DNS lookup mechanism 311 defined in [RFC3263], SIP enables calls to be routed between domains 312 in much the same way email is 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 in sections Section 3.1 and 324 Section 3.2 respectively. 326 4.2. Public ENUM 328 Public ENUM, defined in [RFC6116] addresses the phone number routing 329 problem by placing phone numbers into the public DNS. Clients can 330 then perform a simple DNS lookup on a phone number, and retrieve a 331 SIP URI which can be used to route to that phone 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 - that 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 evolved 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 4.3. Private Federations 352 Private federations are a cooperative formed amongst a small number 353 of participating domains. The cooperative agrees to use a common 354 technique for federation, and through it, is able to connect to each 355 other. There are many such federations in use today. 357 Some of these federations rely on a central database, typically run 358 by the federation provider, that can be queried by participating 359 domains. The database contains mappings from phone numbers to 360 domains, and is populated by each of the participating domains, often 361 manually. Each domain implements an agreed-upon query interface that 362 can be used to access the database when a number is called. 363 Sometimes ENUM is used for this interface (called private ENUM), 364 other times, a SIP redirection is used. Some federations also 365 utilize private IP networks in order to address QoS problems. 367 Private federations work, but they have one major limitation: scale. 368 As the number of participating domains grows, several problems arise. 369 Firstly, the size of the databases become difficult to manage. 370 Secondly, the correctness of the database becomes an issue, since the 371 odds of misconfigured numbers (either intentionally or accidentally) 372 increases. As the membership grows further, the odds increase that 373 malicious domains will be let in, introducing a source of spam and 374 further problems. The owner of the federation can - and often does - 375 assume responsibility for this, and can attempt to identify and shut 376 down misbehaving participants. Indeed, as the size of the 377 federations grow, the owner of the federation needs to spend 378 increasing levels of capital on maintaining it. This often results 379 in the owners charging for membership, which can be a barrier to 380 entry. 382 5. Key Requirements 384 From the discussion on the problems of inter-domain federation and 385 the solutions that have been attempted so far, several key 386 requirements emerge: 388 REQ-1: The solution must allow for federation between any number of 389 domains. 390 REQ-2: The solution must enable users in one domain to identify 391 users in another domain through the use of their existing E.164 392 based phone numbers. 393 REQ-3: The solution must work with deployments that utilize any kind 394 of endpoint, including non-IP phones connected through gateways, 395 IP softphones and hardphones. 396 REQ-4: The solution must not require any change in user behavior. 397 The devices and techniques that users have been using previously 398 to make inter-domain calls must continue to work, but now result 399 in inter-domain calls using IP. 400 REQ-5: The solution must work worldwide, for any domain anywhere. 401 REQ-6: The solution must not require any new services from any kind 402 of centralized provider. A domain should be able to deploy 403 equipment and connect to the federation without any interaction 404 with or authorization from a centralized provider. 405 REQ-7: The solution must not require any prior arrangement between 406 domains in order to facilitate federation between those domains. 407 Federation must occur opportunistically - connections established 408 when they can be. 409 REQ-8: The solution must work for domains of any size - starting 410 with a single phone up to the largest telecom operator with tens 411 of millions of numbers. 412 REQ-9: The solution must have built-in mechanisms for preventing 413 spam and DoS attacks. These mechanisms must be fully automated. 414 REQ-10: The solution must not require any processing whatsoever by 415 SIP or RTP intermediaries. It must be possible for a direct SIP 416 connection to be established between participating domains. 417 REQ-11: The solution should adapt to VIPR call failures. The 418 solution should allow the user to make calls using the inter- 419 domain calling mechanism used prior to the initial VIPR-enabled 420 call. 422 6. Executive Overview 424 Verification Involving PSTN Reachability (VIPR) is aimed at solving 425 the problems that have prevented large-scale Internet-based SIP 426 federation of voice and video. VIPR solves these problems by 427 creating a hybrid of three technologies - the PSTN itself, a Peer to 428 Peer (P2P) network, and SIP. By using these three technologies 429 together, VIPR enables an incrementally deployable solution to 430 federation. 432 6.1. Key Properties 434 VIPR has several important properties that enable it to solve the 435 federation problem: 437 Works With Numbers: VIPR enables federation for existing PSTN phone 438 numbers. It does not require users or administrators to know or 439 configure email-style identifiers. It does not require the 440 allocation of new numbers. It does not require a change in user 441 behaviors. 442 Works with Existing Endpoints: VIPR does not require any changes to 443 endpoints. Consequently, it works with existing SIP endpoints and 444 with non-IP endpoints connected through gateways. 445 Verified Mappings: VIPR ensures that phone calls cannot be misrouted 446 or numbers stolen. The biggest issue in mapping from a phone 447 number to a domain or IP address, is determining whether the 448 mapping is correct - i.e., does the domain really own the given 449 phone number? While solutions like ENUM have solved this problem 450 by relying on centralized delegations of authorization, VIPR 451 provides a secure mapping in a fully distributed way. 452 Worldwide: VIPR works worldwide. Any domain that is connected to 453 both the PSTN and the Internet can participate. Since VIPR does 454 not depend on availability of any regional services beyond IP and 455 PSTN access - both of which are already available globally - VIPR 456 itself is globally available. 457 Scalibility: VIPR is scaleable. Any number of domains can 458 participate. 459 Self-Scale: VIPR self-scales. This means that the amount of 460 computation, memory, and bandwidth that a domain must deploy 461 scales in direct proportion to the size of their own user base. 462 Self-Learning: VIPR is completely automated. A domain does not 463 require configuration of any information about another domain. It 464 does not require provisioning of IP addresses, domain names, 465 certificates, phone number prefixes or routing rules. 466 Automated Anti-Spam VIPR has a built-in mechanism for preventing SIP 467 spam, which is specific to SIP. It is fundamentally different 468 from existing SIP anti-spam techniques which borrow from email 469 [RFC5039]. This new technique is fully automated, and requires no 470 configuration by administrators and no participation from end 471 users. 472 Feature Velocity: VIPR enables direct SIP connections between two 473 domains seeking to federate. There are no SIP intermediaries of 474 any sort between the two. This means that domains have no 475 dependencies on intermediaries for deployment of new features. 477 Secure: Security is a fundamental part of VIPR and cannot be 478 disabled. 479 Reliable: VIPR is reliable. Through its hybridization of the PSTN 480 and the Internet, it ensures that calls always go through, even in 481 cases of network failure or limited IP connectivity. 483 In order to achieve a solution with these properties, past 484 assumptions about how federations should work must be challenged. 486 6.2. Challenging Past Assumptions 488 Two unstated assumptions of SIP federation are challenged by VIPR. 490 The first assumption that federation solutions have made is this: 491 The purpose of SIP federation is to eliminate the PSTN, and 492 consequently, we cannot assume the PSTN itself as part of the 493 solution. 494 Though unstated, this assumption has clearly been part of the design 495 of existing solutions. SIP federation based on email-style URIs, as 496 defined in RFC 3261, doesn't utilize nor make mention of the PSTN. 497 Solutions like ENUM, or private registries, also do not utilize nor 498 make mention of the PSTN. However, such approaches ignore an 499 incremental solution - a solution which utilizes the PSTN itself to 500 solve the hard problems in SIP federation. 502 There are many advantages to leveraging the PSTN. It reaches 503 worldwide. It provides a global numbering translation service that 504 maps phone numbers to circuits. It is highly reliable, and provides 505 QoS. It has been built up over decades to achieve these goals. 506 Thus, building upon rather than replacing the PSTN, can provide the 507 necessary functionality once another assumption is challenged. 509 This second assumption is: 510 A federation solution must be the same as the final target 511 federation architecture, and not just a step towards it. 512 SIP's email-style federation was a pure 'target architecture'. ENUM 513 was the same - a worldwide global DNS database with everyone's phone 514 numbers providing open connectivity. 516 Historically, technologies are more successful when they are 517 incrementally deployable. As such, VIPR is very much focused on 518 incremental deployability. It discards the notion of perfect IP 519 federation for a solution that federates most, but not all calls, by 520 relying on the PSTN to fill in the gaps. 522 6.3. Technical Overview 524 A high level view of the VIPR architecture with an example is shown 525 in Figure 1. The figure shows four different domains, example.com, 526 example.net, example.org and example.edu, federated using VIPR 527 technology. Each domain is connected to both the public Internet and 528 to the traditional PSTN. For simplicity, the connection for the call 529 agents in example.org and example.edu to the PSTN is not indicated in 530 the diagram as that interface is not relevant to the subsequent 531 examples. 533 +-------+ +-------+ 534 | Call | | Call | 535 example.org | Agent | | Agent | example.edu 536 | | | | 537 +-------+ +-------+ 538 \ / 539 \ / 540 \ / 541 \ / 542 | 543 //--------\\ 544 |// \\| 545 | Internet | 546 +-------+ |\\ //| +-------+ 547 | Call |------ \\ _______//------| Call | 548 //\\ | Agent | | Agent | //\\ 549 \ / | | | | \ / 550 \/ ---| | +-----------+ | |---- \/ 551 User | |======| |======| | User 552 Agent +-------+ | PSTN | +-------+ Agent 553 example.com | | example.net 554 +-----------+ 556 Figure 1: High Level Architecture 558 For purposes of explanation, it is easiest to think of each domain as 559 having a single call agent which participates in the federation 560 solution. The functionality is decomposed into several sub- 561 components, and this is discussed in more detail below. The call 562 agent is connected to one or more user agents in the domain, and is 563 responsible for routing calls, handling features, and processing call 564 state. The call agent is stateful, and is aware of when calls start 565 and stop. Additional detail for the functional components of this 566 architecture are provided in [I-D.petithuguenin-vipr-framework]. 568 Assume that all four domains have a 'fresh' installation of VIPR, and 569 that domain example.net 'owns' +1 408 555 5xxx, a block of 1000 570 numbers allocated by its PSTN provider. 572 The VIPR mechanism can be broken into four basic steps: storage of 573 phone numbers, PSTN first call, validation and caching, and 574 subsequent SIP call(s). 576 6.3.1. Storage of Phone Numbers 578 The first step is that the call agents form a single, worldwide P2P 579 network, using a VIPR specific usage 580 [I-D.petithuguenin-vipr-reload-usage] of RELOAD 581 [I-D.ietf-p2psip-base] with a variant of the Chord algorithm. This 582 P2P network forms a distributed hash table (DHT) running amongst all 583 participating domains. A distributed hash table is like a simple 584 database, allowing storage of key-value pairs, and lookup of objects 585 by key. Unlike a normal hash table, which resides in the memory of a 586 single computer, a distributed hash table is spread across all of the 587 servers which make up the P2P network. In this case, it is spread 588 across all of the domains participating in the VIPR federation. 590 The problem solved by the variant of the Chord algorithm (and by 591 other DHT algorithms), is an answer to the following: given that the 592 desired operation is to read or write an object with key K, which 593 node in the DHT is the box that currently stores the object with that 594 key? The P2P SIP variant of the Chord algorithm provides an 595 algorithm which routes read and write operations through nodes in the 596 DHT until they eventually arrive at the right place. With Chord, 597 this will take no more than log2N hops, where N is the number of 598 nodes in the DHT. Consequently, for a DHT with 1024 nodes, 10 hops 599 are required in the worst case. For 2048, 11 hops. And so on. The 600 logarithmic factor allows DHTs to achieve efficient scale and to 601 provide a large amount of storage summed across all of the nodes that 602 make up the DHT. 604 This logarithmic hopping behavior also means that each node in the 605 DHT does not need to establish a TCP/TLS connection to every other 606 node. Rather, connections are established to a smaller subset - just 607 log(N) of the nodes. 609 In DHTs, each participating entity is identified by a Node-ID. The 610 Node-ID is a 128 bit number, assigned randomly to each entity. They 611 have no inherent semantic meaning; they are not like domain names or 612 IP addresses. 614 In the case of VIPR, each call agent is identified by one or more 615 Node-IDs. For purposes of discussion, consider the case where the 616 call agent has just one Node-ID. Each participating domain, 617 including example.net in our example, uses the DHT to store a mapping 618 from each phone number that it owns, to the domain's Node-ID. In the 619 case of example.net, it would store 1000 entries into the DHT, each 620 one being a mapping from one of its phone numbers, to the domain's 621 Node-ID. Furthermore, when the mappings are stored, the mapping is 622 actually from the SHA-1 hash of the phone number, to the Node-ID of 623 the call agent which claims ownership of that number. 625 For example, if the Node-ID of the call agent in domain example.net 626 is 0x1234 (a shorter 16 bit value to simplify discussion), the 627 entries stored into the DHT by example.net would be: 629 Key | Value 630 ---------------------------------- 631 SHA1(+14085555000) | 0x1234 632 SHA1(+14085555001) | 0x1234 633 SHA1(+14085555002) | 0x1234 634 ..... 635 SHA1(+14085555999) | 0x1234 637 Figure 2: DHT Contents 639 It is important to note that the DHT does not contain phone numbers 640 (it contains hashes of them), nor does it contain IP addresses or 641 domain names. Instead, it is a mapping from the hash of a phone 642 number (in E.164 format) to a Node-ID. 644 example.net will store this mapping when it starts up, or when a new 645 number is provisioned. The information is refreshed periodically by 646 example.net. The actual server on which these mappings are stored 647 depends on the variant of the Chord algorithm. Typically, the 648 entries will be uniformly distributed amongst all of the call agents 649 participating in the network. 651 6.3.2. PSTN First Call 653 At some point, a user agent (Alice) in example.com makes a call to +1 654 408 555 5432, which is her colleague Bob. Even though both sides have 655 VIPR, the call takes place over the plain old PSTN, per Figure 3. 656 Alice talks to Bob for a bit, and they hang up. 658 +-------+ +-------+ 659 | Call | | Call | 660 //\\ | Agent | | Agent | //\\ 661 \ / | | | | \ / 662 \/ ---| | +-----------+ | |---- \/ 663 Alice | |<=======<========>======>| | Bob 664 +-------+ | PSTN | +-------+ 665 example.com | | example.net 666 +-----------+ 668 Figure 3: PSTN First Call 670 At a random point in time after the call has completed, the call 671 agent in example.com "wakes up" and says to itself, "that's 672 interesting, someone in my domain called +1 408 555 5432, and it went 673 over the PSTN. I wonder if that number is reachable over IP 674 instead?". To make this determination, it hashes the called phone 675 number, and looks it up in the DHT. It is important to note that 676 this lookup is not at the time of an actual phone call - this lookup 677 process happens outside of any phone call, and is a background 678 process. 680 The query for +1 408 555 5432 will traverse the DHT, and eventually 681 arrive at the node that is responsible for storing the mapping for 682 that number. Typically, that node will not be example.net, but 683 rather one of the other nodes in the network (e.g., example.org). In 684 many cases, the called number will not find a matching mapping in the 685 DHT. This happens when the number that was dialed is not owned by a 686 domain participating in VIPR. When that happens, example.com takes 687 no further action. Next time there is another call to the same 688 number, it will repeat the process and check once more whether the 689 dialed number is in the DHT. 691 In this case, there is a match in the DHT, and example.com learns the 692 Node-ID of example.net. It then proceeds to the validation step per 693 Section 6.3.3. It is also possible that there are multiple matches 694 in the DHT. This can happen if another domain - example.edu for 695 example - also claims ownership of that number. When there are 696 multiple matching results, example.com learns all of them, and 697 performs the validation step with each. 699 6.3.3. Validation and Caching 701 Why not just store the domain in the DHT, instead of the Node-ID? If 702 the domain was stored in the DHT, once example.com performed the 703 lookup, it would immediately learn that the number maps to 704 example.net, and could then make a direct SIP call next time. 706 The main reason this doesn't work is security. The information in 707 the DHT is completely untrusted. There is nothing so far that 708 enables example.com to know that example.net does, in fact, own the 709 phone number in question. Indeed, if multiple domains make a claim 710 on the number, it has no way to know which one (if any) actually owns 711 it. 713 To address this critical problem, VIPR requires a mechanism called 714 phone number validation. Phone number validation is a key concept in 715 VIPR. There are several models for this validation as detailed in 716 [I-D.petithuguenin-vipr-pvp]. The essential idea is that example.com 717 will connect to the example.net server, by asking the DHT to form a 718 connection to example.net's Node-ID. Once connected, example.com 719 demands proof of ownership of the phone number. This proof comes in 720 the form of demonstrated knowledge of the previous PSTN call. When a 721 call was placed from example.com to +1 408 555 5432, the details of 722 that call - including its caller ID, start time, and stop time, 723 create a shared secret referred to as a "ticket", - information that 724 is only known to entities that participated in the call. Thus, to 725 obtain proof that example.net really owns the number in question, 726 example.com will demand a knowledge proof - that example.net is aware 727 of the details of the call. A consequence of this is that the 728 following property is maintained: 730 A domain can only call a specific number over SIP, if it had 731 previously called that exact same number over the PSTN. 733 This property is key in fighting spam and denial-of-service attacks. 734 Because calling numbers on the PSTN costs money - especially 735 international calls - VIPR creates a financial disincentive for 736 spammers. For a spammer to ring every phone in a domain with a SIP 737 call, it must have previously called every number in the domain with 738 a PSTN call, and had a successfully completed call to each and every 739 one of them. [I-D.petithuguenin-vipr-sip-antispam] provides an 740 overview and further details on the security mechanisms for VIPR for 741 mitigation of SPAM. 743 There are a great many details required for this validation protocol 744 to be secured. For example, the mechanism needs to handle the fact 745 that call start and stop times won't exactly match on both sides. It 746 needs to deal with the fact that many calls start on the top of the 747 hour. It needs to deal with the fact that caller ID is not often 748 delivered, and when it is delivered, is not reliable. It needs to 749 deal with the fact that example.com may in fact be the attacker, 750 trying to use the validation protocol to extract the shared secret 751 from example.net. All of this is, in fact, handled by the protocol. 752 The protocol is based on the Secure Remote Password for TLS 753 Authentication (SRP-TLS) [RFC5054], and is described more fully in 754 [I-D.petithuguenin-vipr-pvp]. 756 Towards the end of the validation process, domains example.com and 757 example.net had determined that each was, in fact in possession of 758 the shared secret information about the prior PSTN call. However, 759 neither side has any information about the domain names of the other 760 side. 762 At the end of the validation process, both example.com and 763 example.net have been able to ascertain that the other side did in 764 fact participate in the previous PSTN call. At that point, 765 example.com sends its domain name to example.net as shown in 766 Figure 4. 768 +-------+ +-------+ 769 | Call | | Call | 770 example.org | Agent | | Agent | example.edu 771 | | | | 772 +-------+ +-------+ 773 \ / 774 +----------------------+ \ / 775 | Hi, I am example.com.| \ / 776 | How do I reach you? | \ / 777 +--------------\-------+ //-------\\ 778 \ // \\ 779 +===\======>========>========>=====+ 780 ^ | Internet | | 781 | | | v 782 +-------+ |\\ //| +-------+ 783 | Call |------ \\ _______//------| Call | 784 //\\ | Agent | | Agent | //\\ 785 \ / | | | | \ / 786 \/ ---| | | |---- \/ 787 Alice | | | | Bob 788 +-------+ +-------+ 789 example.com example.net 791 Figure 4: Ticket Validation Step 1 793 Next, the example.net domain generates the ticket. The ticket has 794 three fundamental parts to it: 796 1. The phone number that was just validated - in this case, +1 408 797 555 5432. 798 2. The domain name that the originating side claims it has - 799 example.com in this case. 800 3. A signature generated by example.net, using a key known to itself 801 only, over the other two pieces of information. 803 Then, example.net sends to example.com - all over a secured channel - 804 a SIP URI to use for routing calls to this number, and a ticket, as 805 shown in Figure 5. The ticket is a cryptographic object, opaque to 806 example.com, but used by example.net to allow incoming SIP calls. It 807 is similar in concept to kerberos tickets - it is a grant of access. 808 In this case, it is a grant of access for example.com to call +1 408 809 555 5432, and only +1 408 555 5432. 811 +-------+ +-------+ 812 | Call | | Call | 813 example.org | Agent | | Agent | example.edu 814 | | | | 815 +-------+ +-------+ 816 \ / 817 \ / +------------------------+ 818 \ / | Here is your ticket | 819 \ / | & SIP URI to reach Bob | 820 //-------\\ +----/-------------------+ 821 // \\ / 822 +==========<========<========<===/=+ 823 | | Internet | ^ 824 v | | | 825 +-------+ |\\ //| +-------+ 826 | Call |------ \\ _______//------| Call | 827 //\\ | Agent | | Agent | //\\ 828 \ / | | | | \ / 829 \/ ---| | | |---- \/ 830 Alice | | | | Bob 831 +-------+ +-------+ 832 example.com example.net 834 Figure 5: Ticket Validation Step 2 836 The example.com call agent receives the SIP URI and ticket, and 837 stores both of them in an internal cache. This cache builds up 838 slowly over time, containing the phone number, SIP URI, and ticket, 839 for those numbers which are called by example.com and validated using 840 VIPR. Because the cache entries are only built for numbers which 841 have actually been called by users in the enterprise, the size of the 842 cache self-scales. A call agent supporting only ten users will build 843 up a cache proportional to the volume of numbers called by ten 844 people, whereas a call agent supporting ten thousand users will build 845 up a cache which is typically a thousand times larger. 847 This cache, containing the phone number, SIP URI and ticket will be 848 accessed later when Alice (or another caller from the same call 849 agent) makes another call to Bob, as detailed in Section 6.3.4. 851 6.3.4. SIP Call 853 At some point in the future, another call is made to +1 408 555 5432. 854 The caller could be Alice, or it could be any other user attached to 855 the same call agent. This time, the call agent notes that it has a 856 cached entry (including the SIP URI and ticket) for the number in 857 question. It is possible that there are multiple entries for a given 858 number. For example, both an Enterprise and Service Provider may 859 register the same number in the RELOAD distributed database. It may 860 also be possible to fork a call using the multiple entries . 861 [Editor's note: this requires further discussion as to whether we 862 want to allow multiple entries.] 864 The example.com call agent attempts to contact the SIP URI by 865 establishing a TCP/TLS connection to the SIP URI it learned. If a 866 connection cannot be made and there are no other cached entries for 867 the number in question, the call agent proceeds with the call over 868 the PSTN. This ensures that, in the event of an Internet failure or 869 server failure, the call can still proceed. Assuming the connection 870 is established, the example.com call agent sends a SIP INVITE to the 871 terminating call agent, over this newly formed secure connection. 872 The SIP INVITE request also contains the ticket, placed into a new 873 SIP header field in the message. 875 When the SIP INVITE arrives at the example.net call agent, the call 876 agent can extract the ticket from the new SIP header field. This 877 ticket is an object, opaque to example.com, that was previously 878 generated by the example.net call agent as described in 879 Section 6.3.3. example.net first verifies the signature over the 880 ticket. Remember that the example.net agent is the one that 881 generated the ticket in the first place; as such, it is in possession 882 of the key required to validate the signature. Once validated, it 883 performs two checks: 885 1. It compares the phone number in the call setup request (the 886 Request URI) against the phone number stored in the ticket. 887 2. It compares the domain name of the calling domain, learned from 888 the certificates in the mutual TLS exchange, against the domain 889 name stored in the ticket. 891 If both match, the example.net call agent knows that the calling 892 party is in fact the domain they claimed previously, and that they 893 had in fact gone through the validation process successfully for the 894 number in question. At this time, the call is now completed per 895 normal SIP processing. 897 7. Security Considerations 899 This section provides an overview of some of the key threats and how 900 they are handled at a high level. Note that the detailed security 901 solutions to handle the threats are detailed in the other relevant 902 VIPR documents as referenced in the sections below. 904 7.1. Attacks on the DHT 906 Attackers could attempt to disrupt service through a variety of 907 attacks on the DHT. 909 Firstly, it must be noted that the DHT is never used at call setup 910 time. It is accessed as a background task, solely to learn NEW 911 numbers and SIP URIs that are not already known. If an attacker was 912 able to completely destroy the P2P network, it would not result in a 913 single call to fail. Furthermore, it would not cause calls to revert 914 to the PSTN - calls to SIP URIs learned previously would still go 915 over the IP network. The only impact to such a devastating attack is 916 that a domain could not learn SIP URIs for new numbers, until the DHT 917 is restored to service. This service failure is hard for users and 918 administrators to even notice. 920 That said, VIPR prevents many of these attacks. The DHT itself is 921 secured using TLS - its usage is mandatory. Quota mechanisms are put 922 into place that prevent an attacker from storing large amounts of 923 data in the DHT as described in 924 [I-D.petithuguenin-vipr-proportional-quota]. Other attacks are 925 prevented by mechanisms defined by RELOAD [I-D.ietf-p2psip-base] 926 itself, and are not VIPR specific. 928 7.2. Theft of Phone Numbers 930 A key security threat that VIPR is trying to address is the theft of 931 phone numbers. In particular, a malicious domain could store, in the 932 DHT, phone numbers that it does not own, in an attempt to steal calls 933 targeted to those numbers. This attack is prevented by the core 934 validation mechanism as described in [I-D.petithuguenin-vipr-pvp] , 935 which performs a proof of knowledge check to verify ownership of 936 numbers. 938 An attacker could try to claim numbers it doesn't own, which are 939 claimed legitimately by other domains in the VIPR network. This 940 attack is prevented as well. Each domain storing information into 941 the DHT can never overwrite information stored by another domain. As 942 a consequence, if two domains claim the same number, two records are 943 stored in the DHT. An originating domain will validate against both, 944 and only one will validate - the real owner. 946 An attacker could actually own a phone number, use it for a while, 947 validate with it, and build up a cache of routes at other domains. 948 Then, it gives back the phone number to the PSTN provider, who 949 allocates it to someone else. However, the attacker still claims 950 ownership of the number, even though they no longer have it. This 951 attack is prevented by expiring the learned routes after a while. 952 Typically, operators do not re-assign a number for a few months, to 953 allow out-of-service messages to be played to people that still have 954 the old number. Thus, the TTL for cached routes is set to match the 955 duration that carriers typically hold numbers. 957 An attacker could advertise a lot of numbers, most of which are 958 correct, some of which are not. VIPR prevents this by requiring each 959 number to be validated individually. 961 An attacker could make a call so they know the call details of the 962 call they made and use this to forge a validation for that call. 963 They could then try to convince other users, which would have to be 964 in the same domain as the attacker, to trust this validation. This 965 is mitigated by not sharing validations inside of domains where the 966 users that can originate call from that domain are not trusted by the 967 domain. 969 7.3. Spam 971 Another serious concern is that attackers may try to launch SIP spam 972 (also known as SPIT) calls into a domain. As described in 973 Section 6.3.3 and as detailed in 974 [I-D.petithuguenin-vipr-sip-antispam], VIPR prevents this by 975 requiring that a domain make a PSTN call to a number before it will 976 allow a SIP call to be accepted to that same number. This provides a 977 financial disincentive to spammers. The current relatively high cost 978 of international calling, and the presence of national do-not-call 979 regulations, have prevented spam on the PSTN to a large degree. VIPR 980 applies those same protections to SIP connections. 982 VIPR still lowers the cost of communications, but it does so by 983 amortizing that savings over a large number of calls. The costs of 984 communications remain high for infrequent calls to many numbers, and 985 become low for frequent calls to a smaller set of numbers. Since the 986 former is more interesting to spammers, VIPR gears its cost 987 incentives away from the spammers, and towards domains which 988 collaborate frequently. 990 It is important to note that VIPR does not completely address the 991 spam problem. A large spamming clearing house organization could 992 actually incur the costs of launching the PSTN calls to numbers, and 993 then, in turn, act as a conduit allowing other spammers to launch 994 their calls to those numbers for a fee. The clearinghouse would 995 actually need to transit the signaling traffic (or, divulge the 996 private keys to their domain name), which would incur some cost. As 997 such, while this is not an impossible situation, the barrier is set 998 reasonably high to start with - high enough that it is likely to 999 deter spammers until it becomes a highly attractive target, at which 1000 point other mechanisms can be brought to bear. 1002 7.4. Eavesdropping 1004 Another class of attacks involves outsiders attempting to listen in 1005 on the calls that run over the Internet, or obtain information about 1006 the call through observation of signaling. 1008 All of these attacks are prevented by requiring the usage of SIP over 1009 TLS and SRTP. These are mandatory to use. 1011 8. IANA Considerations 1013 This specification does not require any actions from IANA. 1015 9. Acknowledgements 1017 Thanks for review comments from Ken Fischer, Rob Maidhof, Michael 1018 Procter, Eric Burger, Richard Barnes and others. Thanks to Theo 1019 Zourzouvillys for pointing out the 5th theft of phone numbers attack 1020 as described in Section 7.2 . 1022 10. References 1023 10.1. Normative References 1025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1026 Requirement Levels", BCP 14, RFC 2119, March 1997. 1028 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1029 A., Peterson, J., Sparks, R., Handley, M., and E. 1030 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1031 June 2002. 1033 [I-D.ietf-p2psip-base] 1034 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 1035 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 1036 Base Protocol", draft-ietf-p2psip-base-26 (work in 1037 progress), February 2013. 1039 [I-D.petithuguenin-vipr-reload-usage] 1040 Petit-Huguenin, M., Rosenberg, J., and C. Jennings, "A 1041 Usage of Resource Location and Discovery (RELOAD) for 1042 Public Switched Telephone Network (PSTN) Verification", 1043 draft-petithuguenin-vipr-reload-usage-04 (work in 1044 progress), March 2012. 1046 [I-D.petithuguenin-vipr-framework] 1047 Petit-Huguenin, M., Jennings, C., and J. Rosenberg, 1048 "Verification Involving PSTN Reachability (VIPR): 1049 Framework", draft-petithuguenin-vipr-framework-00 (work in 1050 progress), October 2011. 1052 [I-D.petithuguenin-vipr-sip-antispam] 1053 Petit-Huguenin, M., Rosenberg, J., and C. Jennings, 1054 "Session Initiation Protocol (SIP) Extensions for Blocking 1055 VoIP Spam Using PSTN Validation", 1056 draft-petithuguenin-vipr-sip-antispam-03 (work in 1057 progress), January 2012. 1059 [I-D.jennings-vipr-vap] 1060 Jennings, C., Rosenberg, J., and M. Petit-Huguenin, 1061 "Verification Involving PSTN Reachability: The ViPR Access 1062 Protocol (VAP)", draft-jennings-vipr-vap-02 (work in 1063 progress), March 2012. 1065 [I-D.petithuguenin-vipr-pvp] 1066 Petit-Huguenin, M., Rosenberg, J., and C. Jennings, "The 1067 Public Switched Telephone Network (PSTN) Validation 1068 Protocol (PVP)", draft-petithuguenin-vipr-pvp-04 (work in 1069 progress), March 2012. 1071 [I-D.petithuguenin-vipr-proportional-quota] 1072 Petit-Huguenin, M., Rosenberg, J., and C. Jennings, 1073 "Proportional Quota in REsource LOcation And Discovery 1074 (RELOAD)", draft-petithuguenin-vipr-proportional-quota-00 1075 (work in progress), October 2011. 1077 10.2. Informative References 1079 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1080 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1081 March 1999. 1083 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1084 Protocol (SIP): Locating SIP Servers", RFC 3263, 1085 June 2002. 1087 [E.164] ITU-T, "The International Public Telecommunication Number 1088 Plan", Recommendation E.164, May 1997. 1090 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 1091 Protocol (SIP) and Spam", RFC 5039, January 2008. 1093 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1094 Uniform Resource Identifiers (URI) Dynamic Delegation 1095 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1096 March 2011. 1098 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 1099 Requirements", RFC 5067, November 2007. 1101 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 1102 "Using the Secure Remote Password (SRP) Protocol for TLS 1103 Authentication", RFC 5054, November 2007. 1105 [RFC6873] Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 1106 Session Initiation Protocol (SIP) Common Log Format 1107 (CLF)", RFC 6873, February 2013. 1109 [I-D.jones-insipid-session-id] 1110 Jones, P., Pearce, C., Polk, J., and G. Salgueiro, "End- 1111 to-End Session Identification in IP-Based Multimedia 1112 Communication Networks", draft-jones-insipid-session-id-02 1113 (work in progress), February 2013. 1115 [I-D.ietf-insipid-session-id-reqts] 1116 Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. 1117 Kaplan, "Requirements for an End-to-End Session 1118 Identification in IP-Based Multimedia Communication 1119 Networks", draft-ietf-insipid-session-id-reqts-04 (work in 1120 progress), January 2013. 1122 Appendix A. Changes since last version 1124 This section must be removed before publication as an RFC. 1126 Modifications between jennings-04 and jennings-03: 1128 1. Updating references to SIPCLF and Session ID (INSIPID) documents. 1130 Modifications between jennings-03 and jennings-02: 1132 1. Reworded REQ -11 to clarify that in the case of call failures 1133 (i.e., IP calls), the system should fallback to inter-domain 1134 calling prior to VIPR. 1135 2. Deleted REQ-12 (Handover) since it's really not specific 1136 functionality provided by VIPR. 1137 3. Moved some text from the -01 version in the Technical Overview 1138 section back into the doc (not sure why it was removed 1139 previously). 1140 4. Other editorial changes: 1142 - Added a Terminology section. 1143 - Clarified the use of the term "Call Agent". 1144 - Reworded discussion of email in section 2.2 (i.e., it's not 1145 useless). 1146 - Either changed or removed altogether terms like "neat", 1147 "clever", "incredible", "enormous" and any text that read like 1148 marketing literature as much as possible. 1149 - Removed some of the more subjective and superfluous language - 1150 i.e., condensed the text to be more concise (Section 5.2 and many 1151 others per the previous change) 1152 - Deleted explicit reference to "SIP Trunking" as the statement 1153 didn't introduce additional information in that paragraph and the 1154 term is not defined in this document. 1155 - and other minor editorial fixes. 1157 Modifications between jennings-02 and jennings-01: 1159 1. Sections 6,7,8 moved to new VIPR framework document. 1160 2. Editorial changes. 1161 3. Clarifications to re-enforce that the primary objective is not 1162 PSTN bypass but rather to enable enhanced services such as video 1163 between domains. Changed "VoIP" to "SIP" since the focus is not 1164 specifically voice. 1166 4. Added reference for new framework document. 1167 5. Section 5.3: Added references to other documents as appropriate 1168 - e.g., -pvp, -spam, etc. 1169 6. Moved validation diagrams and text (from 5.3.4) into Validation 1170 and caching section (5.3.3). 1171 7. Condensed discussion of spam in section 5.3.3 and updated SPAM 1172 section in security section. 1174 Modifications between jennings-01 and rosenberg-04: 1176 o Not specified. 1178 Modifications between rosenberg-04 and rosenberg-03 1180 o Nits. 1181 o Shorter I-Ds references. 1182 o Changed phone numbers to follow E.123 presentation. 1183 o Expanded P2P initialisms. 1184 o Uses +1 408 555 prefix for phone numbers in examples. 1186 Authors' Addresses 1188 Mary Barnes 1189 Polycom 1190 TX 1191 US 1193 Email: mary.ietf.barnes@gmail.com 1195 Cullen Jennings 1196 Cisco 1197 170 West Tasman Drive 1198 MS: SJC-21/2 1199 San Jose, CA 95134 1200 USA 1202 Phone: +1 408 421-9990 1203 Email: fluffy@cisco.com 1204 Jonathan Rosenberg 1205 jdrosen.net 1206 Monmouth, NJ 1207 US 1209 Email: jdrosen@jdrosen.net 1210 URI: http://www.jdrosen.net 1212 Marc Petit-Huguenin 1213 Unaffiliated 1215 Email: petithug@acm.org