idnits 2.17.1 draft-jennings-vipr-overview-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 28, 2011) is 4588 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 1057, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-18 == Outdated reference: A later version (-04) exists of draft-petithuguenin-vipr-reload-usage-02 == Outdated reference: A later version (-03) exists of draft-petithuguenin-vipr-sip-antispam-02 == Outdated reference: A later version (-02) exists of draft-jennings-vipr-vap-01 == Outdated reference: A later version (-04) exists of draft-petithuguenin-vipr-pvp-01 -- 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-sipclf-format-02 == Outdated reference: A later version (-01) exists of draft-jones-ipmc-session-id-reqts-00 Summary: 0 errors (**), 0 flaws (~~), 9 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: March 31, 2012 Cisco 6 J. Rosenberg 7 jdrosen.net 8 M. Petit-Huguenin 9 Stonyfish 10 September 28, 2011 12 Verification Involving PSTN Reachability: Requirements and Architecture 13 Overview 14 draft-jennings-vipr-overview-02 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 March 31, 2012. 50 Copyright Notice 52 Copyright (c) 2011 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. The Phone Number Routing Problem . . . . . . . . . . . . . 5 70 2.2. The Open Pinhole Problem . . . . . . . . . . . . . . . . . 6 71 2.3. Quality of Service Problem . . . . . . . . . . . . . . . . 7 72 2.4. Troubleshooting Problem . . . . . . . . . . . . . . . . . 7 73 3. Summary of Existing Solutions . . . . . . . . . . . . . . . . 7 74 3.1. Domain Routing . . . . . . . . . . . . . . . . . . . . . . 8 75 3.2. Public ENUM . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.3. Private Federations . . . . . . . . . . . . . . . . . . . 9 77 4. Key Requirements . . . . . . . . . . . . . . . . . . . . . . . 9 78 5. Executive Overview . . . . . . . . . . . . . . . . . . . . . . 10 79 5.1. Key Properties . . . . . . . . . . . . . . . . . . . . . . 10 80 5.2. Challenging Past Assumptions . . . . . . . . . . . . . . . 12 81 5.3. Technical Overview . . . . . . . . . . . . . . . . . . . . 13 82 5.3.1. Storage of Phone Numbers . . . . . . . . . . . . . . . 14 83 5.3.2. PSTN First Call . . . . . . . . . . . . . . . . . . . 16 84 5.3.3. Validation and Caching . . . . . . . . . . . . . . . . 17 85 5.3.4. SIP Call . . . . . . . . . . . . . . . . . . . . . . . 20 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 6.1. Attacks on the DHT . . . . . . . . . . . . . . . . . . . . 22 88 6.2. Theft of Phone Numbers . . . . . . . . . . . . . . . . . . 22 89 6.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 6.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 24 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 96 Appendix A. Changes since last version . . . . . . . . . . . . . 26 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 99 1. Introduction 101 The Session Initiation Protocol (SIP) was originally published as 102 [RFC2543] in May of 1999. This was followed by subsequent 103 publication of [RFC3261], which brought the protocol to sufficient 104 maturity to enable large scale market adoption. 106 SIP has achieved large scale market adoption with hundreds of 107 implementations, spanning consumer products, enterprise servers, and 108 large scale carrier equipment. It carries billions and billions of 109 minutes of calls, and has become the standard for interconnection 110 between products from different vendors. If one measures success in 111 deployment, then clearly SIP is a success. 113 SIP was designed from the ground up to enable communications between 114 users in different domains, all over the public Internet. The 115 intention was that real-time communications should be no different 116 than email or the web, with the same any-to-any connectivity that has 117 fueled the successes of those technologies. However, when SIP is 118 used between domains, it is typically through private federation 119 agreements. While such agreements are positive, they have typically 120 been limited to voice, which has limited the use of video and the 121 growth of advanced SIP features, thus preventing the innovation that 122 SIP was expected to drive. Thus, the any-to-any Internet federation 123 model envisioned by SIP has not materialized at scale. 125 This document introduces a new technology, called Verification 126 Involving PSTN Reachability (VIPR), that breaks down the barriers 127 that have prevented inter-domain voice, video and other multimedia 128 services. By stepping back and changing some of the most fundamental 129 assumptions about federation, VIPR is able to address the key 130 problems preventing its deployment. VIPR focuses on incremental 131 deployability. At the same time, VIPR ensures that SIP's trapezoidal 132 model of direct federation between domains without any intermediate 133 processing beyond IP transport is realized. That model is required 134 in order to allow innovative new services to be deployed. 136 2. Problem Statement 138 The first question that must be asked is this - why haven't we seen 139 widespread adoption of inter-domain SIP federation? The reason for 140 this is due to problems with the following - summarized in order of 141 importance/impact: 143 1. Phone number routing 144 2. Open pinhole 145 3. Quality of service 146 4. Troubleshooting 148 The first two are the most significant. 150 2.1. The Phone Number Routing Problem 152 Inter-domain federation requires that the sending domain determine 153 the address of the receiving domain, in the form of a DNS name 154 (example.com) or one or more IP addresses that can be used to reach 155 the domain. In email and in the web, this is easy. The identifiers 156 used by those services - the email address and web URL respectively - 157 embed the address of the receiving domain. A simple DNS lookup is 158 all that is required to route the connection. SIP was designed to 159 use the same email-style identifiers. 161 However, most SIP deployments utilize phone numbers, and not email- 162 style SIP URIs. This is due to the huge installed base of users that 163 continue to exist solely on the PSTN. In order to be reached by 164 users on the PSTN, and in order to reach them, users in SIP 165 deployments need to be assigned a regular PSTN number. Users in SIP 166 deployments need to place that PSTN number on business cards, use it 167 in their email signatures, and in general, give it out to their 168 friends and colleagues, in order to be reached. While those users 169 could additionally have an email style SIP URI, the PSTN number 170 serves as a single, global identifier that works for receiving calls 171 from users on the PSTN as well as users within the same SIP domain. 173 There are several reasons why two identifiers are used when one will 174 suffice. The universality of PSTN numbers is the reason why most SIP 175 deployments continue to use them - often exclusively. 177 Another reason is that many SIP deployments utilize hardphones or 178 telephony adaptors, and the user interfaces on these devices - 179 patterned after existing phones - only allow phone-number based 180 dialing. Consequently, these users are only allocated PSTN numbers, 181 and not email-style SIP URI. 183 Finally, a large number of SIP deployments are in domains where the 184 endpoints are not IP. Rather, they are circuit based devices, 185 connected to a SIP network through a gateway. SIP is used within the 186 core of the network, providing lower cost transit, or providing 187 add-on services. Clearly, in these deployments, only phone numbers 188 are used. 190 Consequently, to make inter-domain federation incrementally 191 deployable and widely applicable, it needs to work with PSTN numbers 192 rather than email-style SIP URI. Telephone numbers, unlike email 193 addresses, do not provide any indication of the address of the domain 194 which "owns" the phone number. Indeed, the notion of phone number 195 ownership is somewhat cloudy. Numbers can be ported between 196 carriers. They can be assigned to a user or enterprise, and then 197 later re-assigned to someone else. Numbers are granted to users and 198 enterprises through a complex delegation process involving the ITU, 199 governments, and telecommunications carriers, often involving local 200 regulations that vary from country to country. 202 Therefore, in order to deploy inter-domain federation, domains are 203 required to utilize some kind of mechanism to map phone numbers to 204 the address of the domain to which calls should be routed. Though 205 several techniques have been developed to address this issue, none 206 have achieved large-scale Internet deployments. 208 2.2. The Open Pinhole Problem 210 The inter-domain federation mechanism built into SIP borrows heavily 211 from email. Each domain runs a SIP server on an open port. When one 212 domain wishes to contact another, it looks up the domain name in the 213 DNS, and connects to that server on the open port. Here, "open" 214 means that the server is reachable from anywhere on the public 215 Internet, and is not blocked by firewalls. 217 This simple design worked well in the early days of email. However, 218 the email system has now become plagued with spam, to the point of 219 becoming useless. Administrators of SIP domains fear - rightfully so 220 - that if they make a SIP server available for anyone on the Internet 221 to contact, it will open the floodgates for SIP spam, which is far 222 more disruptive than email-based spam [RFC5039]. Administrators also 223 worry - rightfully so - that an open server will create a back-door 224 for denial-of-service and other attacks that can potentially disrupt 225 their voice and video services. Administrators are simply not 226 willing to take that risk; rightly or wrongly, voice deployments 227 demand higher uptimes and better levels of reliability than email, 228 especially for enterprises. 230 Fears around spam and denial-of-service attacks, when put together, 231 form the "open pinhole problem" - that domains are not willing to 232 enable SIP on an open port facing the Internet. 234 To fix this, a new model for federation is needed - a model where 235 these problems are addressed as part of the fundamental design, and 236 not as an after-thought. 238 2.3. Quality of Service Problem 240 The Internet does not provide any QoS guarantees. All traffic is 241 best effort. This is not an issue for data transaction services, 242 like web and email. It is, however, a concern when using real-time 243 services, such as voice and video. 245 That said, there are a large number of existing SIP deployments that 246 run over the Internet. Though the lack of QoS is a concern, it has 247 not proven a barrier to deployment. We believe that, if the more 248 fundamental issues - the phone number routing and open pinhole 249 problems - can be addressed, the QoS problem will sort itself out. 250 As such, we do not discuss this issue further here. 252 2.4. Troubleshooting Problem 254 The final problem that is stopping large scale inter-domain 255 federation is the troubleshooting problem. When connecting calls 256 between domains, problems will happen. Calls will get blocked. 257 Calls will get misdelivered. Features won't work. There will be 258 one-way media or no media at all. The video won't start. Call 259 quality will be poor. 261 These problems are common in SIP deployments, and they are tough to 262 troubleshoot even within a single administrative domain. When real- 263 time services extend inter-domain, the problem becomes worse. A new 264 angle is introduced: the first step is identifying who is at fault. 266 Fortunately, work is underway to improve the ability for network 267 administrators to diagnose SIP problems. Common log formats 268 [I-D.ietf-sipclf-format] and consistent session IDs 269 [I-D.jones-ipmc-session-id-reqts], for example, can help troubleshoot 270 interdomain calls. 272 In addition to these, any new technology that facilitates inter- 273 domain federation needs to have troubleshooting built-in, so that it 274 is not a barrier to deployment. Further consideration of necessary 275 built-in techniques for troubleshooting is required for successful 276 deployment of VIPR. 278 3. Summary of Existing Solutions 280 Given the value that inter-domain SIP federation brings, it is no 281 surprise that many attempts have been made at solving it. Indeed, 282 these have all been deployed to varying degrees. However, all of 283 them have fundamental limitations that have inhibited widespread 284 deployment. 286 3.1. Domain Routing 288 The first solution that has been proposed for SIP inter-domain 289 federation is built into SIP itself - domain routing. In this 290 technique, users utilize email-style SIP URI as identifiers. By 291 utilizing the DNS lookup mechanism defined in [RFC3263], SIP enables 292 calls to be routed between domains in much the same way email is 293 routed between domains. 295 This technique works well in theory, but it has two limitations which 296 have limited its deployment: 298 1. The majority of SIP deployments utilize phone numbers, often 299 exclusively. In such a case, domain routing cannot be used. 300 2. Domain federation brings with it the possibility (and strong 301 likelihood) of the same levels of spam and DoS attacks that have 302 plagued the email system. 304 These issues have already been discussed above. 306 3.2. Public ENUM 308 Public ENUM, defined in [RFC6116] addresses the phone number routing 309 problem by cleverly placing phone numbers into the public DNS. 310 Clients can then perform a simple DNS lookup on a phone number, and 311 retrieve a SIP URI which can be used to route to that phone number. 313 Unfortunately, public ENUM requires that the entries placed into the 314 DNS be populated following a chain of responsibility that mirrors the 315 ownership of the numbers themselves. This means that, in order for a 316 number to be placed into the DNS, authorization to do so must start 317 with the ITU, and from there, move to the country, telecom regulator, 318 and ultimately the end user. The number of layers of bureaucracy 319 required to accomplish this is non-trivial. In addition, the telecom 320 operators - which would be partly responsible for populating the 321 numbers into the DNS - have little incentive to do so. As a 322 consequence, public ENUM is largely empty, and is likely to remain so 323 for the foreseeable future. 325 Instead, ENUM has morphed into a technique for federation amongst 326 closed peering partners, called private ENUM or infrastructure ENUM 327 [RFC5067]. While there is value in this technology, it does not 328 enable the open federation that public ENUM was designed to solve. 330 It is clear from the legacy of ENUM deployments, that any kind of 331 phone number routing solution should not rely on government or 332 telecom processes for population of the databases. 334 3.3. Private Federations 336 Private federations are a cooperative formed amongst a small number 337 of participating domains. The cooperative agrees to use a common 338 technique for federation, and through it, is able to connect to each 339 other. There are many such federations in use today. 341 Some of these federations rely on a central database, typically run 342 by the federation provider, that can be queried by participating 343 domains. The database contains mappings from phone numbers to 344 domains, and is populated by each of the participating domains, often 345 manually. Each domain implements an agreed-upon query interface that 346 can be used to access the database when a number is called. 347 Sometimes ENUM is used for this interface (called private ENUM), 348 other times, a SIP redirection is used. Some federations also 349 utilize private IP networks in order to address QoS problems. "SIP 350 trunking" - a service being offered by many telecom operators as a 351 SIP-based PRI replacement - is a form of private federation. 353 Private federations work, but they have one major limitation: scale. 354 As the number of participating domains grows, several problems arise. 355 Firstly, the size of the databases become unruly. Secondly, the 356 correctness of the database becomes an issue, since the odds of 357 misconfigured numbers (either intentionally or accidentally) 358 increases. As the membership grows further, the odds increase that 359 "bad" domains will be let in, introducing a source of spam and 360 further problems. The owner of the federation can - and often does - 361 assume responsibility for this, and can attempt to identify and shut 362 down misbehaving participants. Indeed, as the size of the 363 federations grow, the owner of the federation needs to spend 364 increasing levels of capital on maintaining it. This, in turn, 365 requires them to charge money for membership, and this can be a 366 barrier to entry. 368 4. Key Requirements 370 From the discussion on the problems of inter-domain federation and 371 the solutions that have been attempted so far, several key 372 requirements emerge: 374 REQ-1: The solution must allow for federation between any number of 375 domains. 376 REQ-2: The solution must enable users in one domain to identify 377 users in another domain through the use of their existing E.164 378 based phone numbers. 380 REQ-3: The solution must work with deployments that utilize any kind 381 of endpoint, including non-IP phones connected through gateways, 382 IP softphones and hardphones. 383 REQ-4: The solution must not require any change in user behavior. 384 The devices and techniques that users have been using previously 385 to make inter-domain calls must continue to work, but now result 386 in inter-domain IP federation. 387 REQ-5: The solution must work worldwide, for any domain anywhere. 388 REQ-6: The solution must not require any new services from any kind 389 of centralized provider. A domain should be able, of its own 390 free-will and accord, to deploy equipment and connect to the 391 federation. 392 REQ-7: The solution must not require any prior arrangement between 393 domains in order to facilitate federation between those domains. 394 Federation must occur opportunistically - connections established 395 when they can be. 396 REQ-8: The solution must work for domains of any size - starting at 397 a single phone to the largest telecom operator with tens of 398 millions of numbers. 399 REQ-9: The solution must have built-in mechanisms for preventing 400 spam and DoS attacks. These mechanisms must be fully automated. 401 REQ-10: The solution must not require any processing whatsoever by 402 SIP or RTP intermediaries. It must be possible for a direct SIP 403 connection to be established between participating domains. 404 REQ-11: The solution should provide a mechanism for removal of 405 cached routes in cases of failures of VIPR calls using the 406 specific route. 407 REQ-12: The solution should support the handover of a call across 408 domains between different SIP providers. 410 5. Executive Overview 412 Verification Involving PSTN Reachability (VIPR) is a new technology 413 that is aimed at solving the problems that have prevented large-scale 414 Internet-based SIP federation of voice and video. VIPR solves these 415 problems by creating a hybrid of three technologies - the PSTN 416 itself, a Peer to Peer (P2P) network, and SIP. By combining all 417 three, VIPR enables an incrementally deployable solution to 418 federation. 420 5.1. Key Properties 422 VIPR has several important properties that enable it to solve the 423 federation problem: 425 Works With Numbers: VIPR enables federation for existing PSTN 426 numbers. It does not require users or administrators to know or 427 configure email-style identifiers. It does not require the 428 allocation of new numbers. It does not require a change in user 429 behaviors. Whatever way users were dialing numbers yesterday, 430 works with VIPR tomorrow. 431 Works with Existing Endpoints: VIPR does not require any changes to 432 endpoints. Consequently, it works with existing SIP endpoints, or 433 with non-IP endpoints connected through gateways. 434 Verified Mappings: The biggest issue in mapping from a phone number 435 to a domain or IP address, is determining whether the mapping is 436 correct. Does that domain really own the given phone number? 437 While solutions like ENUM have solved this problem by relying on 438 centralized delegations of authorization, VIPR provides a secure 439 mapping in a fully distributed way. VIPR guarantees that phone 440 calls cannot be misrouted or numbers stolen. 441 Worldwide: VIPR works worldwide. Any domain that is connected to 442 both the PSTN and the Internet can participate. It doesn't matter 443 whether the domain is in Africa, the Americas, or Australia. 444 Since VIPR does not depend on availability of any regional 445 services beyond IP and PSTN access - both of which are already 446 available globally - VIPR itself is globally available. 447 Unlimited Scale: VIPR has nearly infinite scale. Any number of 448 domains can participate. 449 Self-Scale: VIPR self-scales. This means that the amount of 450 computation, memory, and bandwidth that a domain must deploy 451 scales in direct proportion to the size of their own user base. 452 Self-Learning: VIPR is completely automated. A domain never, ever 453 has to configure any information about another domain. It never 454 has to provision IP addresses, domain names, certificates, phone 455 number prefixes or routing rules. Without any prior coordination, 456 VIPR enables one domain to connect to a different domain. 457 Automated Anti-Spam VIPR comes with a built-in mechanism for 458 preventing SIP spam. This mechanism is new, and specific to SIP. 459 In this way, it is fundamentally different from existing SIP anti- 460 spam techniques which borrow from email [RFC5039]. This new 461 technique is fully automated, and requires no configuration by 462 administrators and no participation from end users. Though it is 463 not a 100% solution to the problem, it brings substantial economic 464 and legal ammunition to the table to act as a good deterrent for a 465 long while. 466 Feature Velocity: VIPR enables direct SIP connections between two 467 domains seeking to federate. There are no SIP intermediaries of 468 any sort between the two. This means that domains have no 469 dependencies on intermediaries for deployment of new features. 471 Designed for the Modern Internet: VIPR is built to run on the modern 472 Internet. It assumes the worst from everyone. It assumes limited 473 connectivity. It assumes network failures. It assumes there are 474 attackers seeking to eavesdrop calls. Security is built-in and 475 cannot be disabled. 476 Reliable: VIPR is reliable. Through its hybridization of the PSTN 477 and the Internet, it makes sure that calls always go through. 478 Indeed, to route a call between domains A and B, VIPR never 479 depends on a server or service anywhere outside of domains A and B 480 (besides vanilla PSTN and IP access) being operational. 482 Given the assumptions that have traditionally been made about how 483 federation has to work, these properties are impossible to realize. 484 It is only by stepping back, and rethinking these fundamental 485 assumptions, that a solution can be found. 487 5.2. Challenging Past Assumptions 489 Two unstated assumptions of SIP federation are challenged by VIPR. 491 The first assumption that federation solutions have made is this: 492 The purpose of SIP federation is to eliminate the PSTN, and 493 consequently, we cannot assume the PSTN itself as part of the 494 solution. 495 Though unstated, this assumption has clearly been part of the design 496 of existing solutions. SIP federation based on email-style URIs, as 497 defined in RFC 3261, doesn't utilize or make mention of the PSTN. 498 Solutions like ENUM, or private registries, do not utilize or make 499 mention of the PSTN. In one sense, it's obvious that they shouldn't 500 - after all, the purpose is to replace the PSTN. However, such an 501 approach ignores an incremental solution - a solution which utilizes 502 the PSTN itself to solve the hard problems in SIP federation. 504 After all, the PSTN has accomplished a great deal. It reaches 505 worldwide. It provides a global numbering translation service that 506 maps phone numbers to circuits. It is highly reliable, and provides 507 QoS. It has been built up over decades to achieve these goals. This 508 begs the question - can we build upon the capabilities already 509 provided by the PSTN, and use them to solve the problems that plague 510 SIP federation? Indeed, the answer is yes once another assumption is 511 challenged. 513 This second assumption is: 514 A federation solution must be the same as the final target 515 federation architecture, and not just a step towards it. 516 Though unstated, this assumption has also been true. SIP's email- 517 style federation was a pure 'target architecture' - the place we want 518 to get to. ENUM was the same - a worldwide global DNS database with 519 everyone's phone numbers providing open connectivity. 521 Historically, technologies are more successful when they are 522 incrementally deployable. Indeed, in many cases, a target 523 architecture is unrealizable because there is no obvious way to get 524 there. As such, the focus needs to be on the next incremental step 525 and that step in turn creates the technological and market pressures 526 that will drive the next step. In the end, the target may not be the 527 perfect solution originally envisioned, but we've at least arrived. 529 As such, VIPR is very much focused on incremental deployability. It 530 is not the end of the federation story, it is the beginning. It 531 discards the notion of perfect IP federation for a solution that 532 federates most, but not all calls, by relying on the PSTN to fill in 533 the gaps. 535 5.3. Technical Overview 537 A high level view of the VIPR architecture is shown in Figure 1. A 538 more detailed description of the functional components of this 539 architecture is provided in draft-petithuguenin-vipr-framework. 541 In the VIPR architectural model, call agents Alice and Bob are shown 542 in two different domains - example.com and example.net respectively. 543 There are two additional domains, example.org and example.edu, with 544 all four domains federated using VIPR technology. Each domain is 545 connected to both the public Internet and to the traditional PSTN. 546 For simplicity, the connection for the Call Agents in example.org and 547 example.edu to the PSTN is not indicated in the diagram as that 548 interface is not relevant to the subsequent examples. 550 +-------+ +-------+ 551 | Call | | Call | 552 example.org | Agent | | Agent | example.edu 553 | | | | 554 +-------+ +-------+ 555 \ / 556 \ / 557 \ / 558 \ / 559 //-------\\ 560 |// \\| 561 | Internet | 562 +-------+ |\\ //| +-------+ 563 | Call |------ \\ _______//------| Call | 564 //\\ | Agent | | Agent | //\\ 565 \ / | | | | \ / 566 \/ ---| | +-----------+ | |---- \/ 567 Alice | |======| |======| | Bob 568 +-------+ | PSTN | +-------+ 569 example.com | | example.net 570 +-----------+ 572 Figure 1: High Level Architecture 574 For purposes of explanation, it is easiest to think of each domain as 575 having a single call agent which participates in the federation 576 solution. The functionality is decomposed into several sub- 577 components, and this is discussed in more detail below. The call 578 agent is connected to one or more phones in the domain, and is 579 responsible for routing calls, handling features, and processing call 580 state. The call agent is stateful, and is aware of when calls start 581 and stop. 583 Assume that all four domains have a 'fresh' installation of VIPR, and 584 that domain example.net 'owns' +1 408 555 5xxx, a block of 1000 585 numbers allocated by its PSTN provider. 587 The VIPR mechanism can be broken into four basic steps: storage of 588 phone numbers, PSTN first call, validation and caching, and 589 subsequent SIP call(s). 591 5.3.1. Storage of Phone Numbers 593 The first step is that the call agents form a single, worldwide P2P 594 network, using a VIPR specific usage 596 [I-D.petithuguenin-vipr-reload-usage] of RELOAD 597 [I-D.ietf-p2psip-base] with a variant of the Chord algorithm. This 598 P2P network forms a distributed hash table (DHT) running amongst all 599 participating domains. A distributed hash table is like a simple 600 database, allowing storage of key-value pairs, and lookup of objects 601 by key. Unlike a normal hash table, which resides in the memory of a 602 single computer, a distributed hash table is spread across all of the 603 servers which make up the P2P network. In this case, it is spread 604 across all of the domains participating in the VIPR federation. 606 The neat trick solved by the variant of the Chord algorithm (and by 607 other DHT algorithms), is an answer to the following: given that the 608 desired operation is to read or write an object with key K, which 609 node in the DHT is the box that currently stores the object with that 610 key? The P2P SIP variant of the Chord algorithm provides a clever 611 algorithm which routes read and write operations through nodes in the 612 DHT until they eventually arrive at the right place. With Chord, 613 this will take no more than log2N hops, where N is the number of 614 nodes in the DHT. Consequently, for a DHT with 1024 nodes, 10 hops 615 are required in the worst case. For 2048, 11 hops. And so on. The 616 logarithmic factor allows DHTs to achieve incredible scale and to 617 provide enormous storage summed across all of the nodes that make up 618 the DHT. 620 This logarithmic hopping behavior also means that each node in the 621 DHT does not need to establish a TCP/TLS connection to every other 622 node. Rather, connections are established to a smaller subset - just 623 log(N) of the nodes. 625 In DHTs, each participating entity is identified by a Node-ID. The 626 Node-ID is a 128 bit number, assigned randomly to each entity. They 627 have no inherent semantic meaning; they are not like domain names or 628 IP addresses. 630 In the case of VIPR, each call agent is identified by one or more 631 Node-IDs. For purposes of discussion, consider the case where the 632 call agent has just one Node-ID. Each participating domain, 633 including example.net in our example, uses the DHT to store a mapping 634 from each phone number that it owns, to the domain's Node-ID. In the 635 case of example.net, it would store 1000 entries into the DHT, each 636 one being a mapping from one of its phone numbers, to the domain's 637 Node-ID. Furthermore, when the mappings are stored, the mapping is 638 actually from the SHA-1 hash of the phone number, to the Node-ID of 639 the call agent which claims ownership of that number. 641 For example, if the Node-ID of the call agent in domain example.net 642 is 0x1234 (a shorter 16 bit value to simplify discussion), the 643 entries stored into the DHT by example.net would be: 645 Key | Value 646 ---------------------------------- 647 SHA1(+14085555000) | 0x1234 648 SHA1(+14085555001) | 0x1234 649 SHA1(+14085555002) | 0x1234 650 ..... 651 SHA1(+14085555999) | 0x1234 653 Figure 2: DHT Contents 655 It is important to note that the DHT does not contain phone numbers 656 (it contains hashes of them), nor does it contain IP addresses or 657 domain names. Instead, it is a mapping from the hash of a phone 658 number (in E.164 format) to a Node-ID. 660 example.net will store this mapping when it starts up, or when a new 661 number is provisioned. The information is refreshed periodically by 662 example.net. The actual server on which these mappings are stored 663 depends on the variant of the Chord algorithm. Typically, the 664 entries will be uniformly distributed amongst all of the call agents 665 participating in the network. 667 5.3.2. PSTN First Call 669 At some point, a user (Alice) in example.com makes a call to +1 408 670 555 5432, which is her colleague Bob. Even though both sides have 671 VIPR, the call takes place over the plain old PSTN, per Figure 3. 672 Alice talks to Bob for a bit, and they hang up. 674 +-------+ +-------+ 675 | Call | | Call | 676 //\\ | Agent | | Agent | //\\ 677 \ / | | | | \ / 678 \/ ---| | +-----------+ | |---- \/ 679 Alice | |<=======<========>======>| | Bob 680 +-------+ | PSTN | +-------+ 681 example.com | | example.net 682 +-----------+ 684 Figure 3: PSTN First Call 686 At a random point in time after the call has completed, the call 687 agent in example.com "wakes up" and says to itself, "that's 688 interesting, someone in my domain called +1 408 555 5432, and it went 689 over the PSTN. I wonder if that number is reachable over IP 690 instead?". To make this determination, it hashes the called phone 691 number, and looks it up in the DHT. It is important to note that 692 this lookup is not at the time of an actual phone call - this lookup 693 process happens outside of any phone call, and is a background 694 process. 696 The query for +1 408 555 5432 will traverse the DHT, and eventually 697 arrive at the node that is responsible for storing the mapping for 698 that number. Typically, that node will not be example.net, but 699 rather one of the other nodes in the network (e.g., example.org). In 700 many cases, the called number will not find a matching mapping in the 701 DHT. This happens when the number that was dialed is not owned by a 702 domain participating in VIPR. When that happens, example.com takes 703 no further action. Next time there is another call to the same 704 number, it will repeat the process and check once more whether the 705 dialed number is in the DHT. 707 In this case, there is a match in the DHT, and example.com learns the 708 Node-ID of example.net. It then proceeds to the validation step per 709 Section 5.3.3. It is also possible that there are multiple matches 710 in the DHT. This can happen if another domain - example.edu for 711 example - also claims ownership of that number. When there are 712 multiple matching results, example.com learns all of them, and 713 performs the validation step with each. 715 5.3.3. Validation and Caching 717 Why not just store the domain in the DHT, instead of the Node-ID? If 718 the domain was stored in the DHT, once example.com performed the 719 lookup, it would immediately learn that the number maps to 720 example.net, and could then make a direct SIP call next time. 722 The main reason this doesn't work is security. The information in 723 the DHT is completely untrusted. There is nothing so far that 724 enables example.com to know that example.net does, in fact, own the 725 phone number in question. Indeed, if multiple domains make a claim 726 on the number, it has no way to know which one (if any) actually owns 727 it. 729 To address this critical problem, VIPR requires a mechanism called 730 phone number validation. Phone number validation is a key concept in 731 VIPR. There are several models for this validation as detailed in 732 [I-D.petithuguenin-vipr-pvp]. The essential idea is that example.com 733 will connect to the example.net server, by asking the DHT to form a 734 connection to example.net's Node-ID. Once connected, example.com 735 demands proof of ownership of the phone number. This proof comes in 736 the form of demonstrated knowledge of the previous PSTN call. When a 737 call was placed from example.com to +1 408 555 5432, the details of 738 that call - including its caller ID, start time, and stop time, 739 create a form of shared secret - information that is only known to 740 entities that participated in the call. Thus, to obtain proof that 741 example.net really owns the number in question, example.com will 742 demand a knowledge proof - that example.net is aware of the details 743 of the call. A consequence of this is that the following property is 744 maintained: 746 A domain can only call a specific number over SIP, if it had 747 previously called that exact same number over the PSTN. 749 This property is key in fighting spam and denial-of-service attacks. 750 Because calling numbers on the PSTN costs money - especially 751 international calls - VIPR creates a financial disincentive for 752 spammers. For a spammer to ring every phone in a domain with a SIP 753 call, it must have previously called every number in the domain with 754 a PSTN call, and had a successfully completed call to each and every 755 one of them. [I-D.petithuguenin-vipr-sip-antispam] provides an 756 overview and further details on the security mechanisms for VIPR for 757 mitigation of SPAM. 759 There are a great many details required for this validation protocol 760 to be secured. For example, the mechanism needs to handle the fact 761 that call start and stop times won't exactly match on both sides. It 762 needs to deal with the fact that many calls start on the top of the 763 hour. It needs to deal with the fact that caller ID is not often 764 delivered, and when it is delivered, is not reliable. It needs to 765 deal with the fact that example.com may in fact be the attacker, 766 trying to use the validation protocol to extract the shared secret 767 from example.net. All of this is, in fact, handled by the protocol. 768 The protocol is based on the Secure Remote Password for TLS 769 Authentication (SRP-TLS) [RFC5054], and is described more fully in 770 [I-D.petithuguenin-vipr-pvp]. 772 Towards the end of the validation process, domains example.com and 773 example.net had determined that each was, in fact in possession of 774 the shared secret information about the prior PSTN call. However, 775 neither side has any information about the domain names of the other 776 side. 778 At the end of the validation process, both example.com and 779 example.net have been able to ascertain that the other side did in 780 fact participate in the previous PSTN call. At that point, 781 example.com sends its domain name to example.net as shown in 782 Figure 4. 784 +-------+ +-------+ 785 | Call | | Call | 786 example.org | Agent | | Agent | example.edu 787 | | | | 788 +-------+ +-------+ 789 \ / 790 +----------------------+ \ / 791 | Hi, I am example.com.| \ / 792 | How do I reach you? | \ / 793 +--------------\-------+ //-------\\ 794 \ // \\ 795 +===\======>========>========>=====+ 796 ^ | Internet | | 797 | | | v 798 +-------+ |\\ //| +-------+ 799 | Call |------ \\ _______//------| Call | 800 //\\ | Agent | | Agent | //\\ 801 \ / | | | | \ / 802 \/ ---| | | |---- \/ 803 Alice | | | | Bob 804 +-------+ +-------+ 805 example.com example.net 807 Figure 4: Ticket Validation Step 1 809 Next, the example.net domain generates the ticket. The ticket has 810 three fundamental parts to it: 812 1. The phone number that was just validated - in this case, +1 408 813 555 5432. 814 2. The domain name that the originating side claims it has - 815 example.com in this case. 816 3. A signature generated by example.net, using a key known to itself 817 only, over the other two pieces of information. 819 Then, example.net sends to example.com - all over a secured channel - 820 a SIP URI to use for routing calls to this number, and a ticket, as 821 shown in Figure 5. The ticket is a cryptographic object, opaque to 822 example.com, but used by example.net to allow incoming SIP calls. It 823 is similar in concept to kerberos tickets - it is a grant of access. 824 In this case, it is a grant of access for example.com to call +1 408 825 555 5432, and only +1 408 555 5432. 827 +-------+ +-------+ 828 | Call | | Call | 829 example.org | Agent | | Agent | example.edu 830 | | | | 831 +-------+ +-------+ 832 \ / 833 \ / +------------------------+ 834 \ / | Here is your ticket | 835 \ / | & SIP URI to reach Bob | 836 //-------\\ +----/-------------------+ 837 // \\ / 838 +==========<========<========<===/=+ 839 | | Internet | ^ 840 v | | | 841 +-------+ |\\ //| +-------+ 842 | Call |------ \\ _______//------| Call | 843 //\\ | Agent | | Agent | //\\ 844 \ / | | | | \ / 845 \/ ---| | | |---- \/ 846 Alice | | | | Bob 847 +-------+ +-------+ 848 example.com example.net 850 Figure 5: Ticket Validation Step 2 852 The example.com call agent receives the SIP URI and ticket, and 853 stores both of them in an internal cache. This cache builds up 854 slowly over time, containing the phone number, SIP URI, and ticket, 855 for those numbers which are called by example.com and validated using 856 VIPR. Because the cache entries are only built for numbers which 857 have actually been called by users in the enterprise, the size of the 858 cache self-scales. A call agent supporting only ten users will build 859 up a cache proportional to the volume of numbers called by ten 860 people, whereas a call agent supporting ten thousand users will build 861 up a cache which is typically a thousand times larger. 863 This cache, containing the phone number, SIP URI and ticket will be 864 accessed later when Alice (or another caller from the same call 865 agent) makes another call to Bob, as detailed in Section 5.3.4. 867 5.3.4. SIP Call 869 At some point in the future, another call is made to +1 408 555 5432. 870 The caller could be Alice, or it could be any other user attached to 871 the same call agent. This time, the call agent notes that it has a 872 cached route for the number in question, along with a SIP URI that 873 can be used to reach that route. It also has a ticket. It is 874 important to note that there may be multiple routes for a given 875 number. For example, both an Enterprise and Service Provider may 876 register the same number in the RELOAD distributed database. It may 877 also be possible to fork a call using the multiple routes. [Editor's 878 note: this requires further discussion as to whether we want to 879 allow this functionality.] 881 The example.com call agent attempts to contact the SIP URI by 882 establishing a TCP/TLS connection to the SIP URI it learned. If a 883 connection cannot be made and there are no other cached routes (e.g., 884 at the next call agent in the path) for the number in question, the 885 call agent proceeds with the call over the PSTN. This ensures that, 886 in the event of an Internet failure or server failure, the call can 887 still proceed. Assuming the connection is established, the 888 example.com call agent sends a SIP INVITE to the terminating call 889 agent, over this newly formed secure connection. The SIP INVITE 890 request also contains the ticket, placed into a new SIP header field 891 in the message. 893 When the SIP INVITE arrives at the example.net call agent, the call 894 agent can extract the ticket from the new SIP header field. This 895 ticket is an object, opaque to example.com, that was previously 896 generated by the example.net call agent as described in Section 5.3.3 897 . example.net first verifies the signature over the ticket. Remember 898 that the example.net agent is the one that generated the ticket in 899 the first place; as such, it is in possession of the key required to 900 validate the signature. Once validated, it performs two checks: 902 1. It compares the phone number in the call setup request (the 903 Request URI) against the phone number stored in the ticket. 904 2. It compares the domain name of the calling domain, learned from 905 the certificates in the mutual TLS exchange, against the domain 906 name stored in the ticket. 908 If both match, the example.net call agent knows that the calling 909 party is in fact the domain they claimed previously, and that they 910 had in fact gone through the validation process successfully for the 911 number in question. At this time, the call is now completed per 912 normal SIP processing. 914 6. Security Considerations 916 Security is incredibly important for VIPR. This section provides an 917 overview of some of the key threats and how they are handled. 919 6.1. Attacks on the DHT 921 Attackers could attempt to disrupt service through a variety of 922 attacks on the DHT. 924 Firstly, it must be noted that the DHT is never used at call setup 925 time. It is accessed as a background task, solely to learn NEW 926 numbers and routes that are not already known. If, by some tragedy, 927 an attacker destroyed the P2P network completely, it would not cause 928 a single call to fail. Furthermore, it would not cause calls to 929 revert to the PSTN - calls to routes learned previously would still 930 go over the IP network. The only impact to such a devastating 931 attack, is that a domain could not learn *new* routes to new numbers, 932 until the DHT is restored to service. This service failure is hard 933 for users and administrators to even notice. 935 That said, VIPR prevents many of these attacks. The DHT itself is 936 secured using TLS - its usage is mandatory. Quota mechanisms are put 937 into place that prevent an attacker from storing large amounts of 938 data in the DHT. Other attacks are prevented by mechanisms defined 939 by RELOAD itself, and are not VIPR specific. 941 6.2. Theft of Phone Numbers 943 The key security threat that VIPR is trying to address is the theft 944 of phone numbers. In particular, a malicious domain could store, 945 into the DHT, phone numbers that it does not own, in an attempt to 946 steal calls targeted to those numbers. This attack is prevented by 947 the core validation mechanism, which performs a proof of knowledge 948 check to verify ownership of numbers. 950 An attacker could try to claim numbers it doesn't own, which are 951 claimed legitimately by other domains in the VIPR network. This 952 attack is prevented as well. Each domain storing information into 953 the DHT can never overwrite information stored by another domain. As 954 a consequence, if two domains claim the same number, two records are 955 stored in the DHT. An originating domain will validate against both, 956 and only one will validate - the real owner. 958 An attacker could actually own a phone number, use it for a while, 959 validate with it, and build up a cache of routes at other domains. 960 Then, it gives back the phone number to the PSTN provider, who 961 allocates it to someone else. However, the attacker still claims 962 ownership of the number, even though they no longer have it. This 963 attack is prevented by expiring the learned routes after a while. 964 Typically, operators do not re-assign a number for a few months, to 965 allow out-of-service messages to be played to people that still have 966 the old number. Thus, the TTL for cached routes is set to match the 967 duration that carriers typically hold numbers. 969 An attacker could advertise a lot of numbers, most of which are 970 correct, some of which are not. VIPR prevents this by requiring each 971 number to be validated individually. 973 An attacker could make a call so they know the call details of the 974 call they made and use this to forge a validation for that call. 975 They could then try to convince other users, which would have to be 976 in the same domain as the attacker, to trust this validation. This 977 is mitigated by not sharing validations inside of domains where the 978 users that can originate call from that domain are not trusted by the 979 domain. 981 6.3. Spam 983 Another serious concern is that attackers may try to launch SIP spam 984 (also known as SPIT) calls into a domain. As described in 985 Section 5.3.3, VIPR prevents this by requiring that a domain make a 986 PSTN call to a number before it will allow a SIP call to be accepted 987 to that same number. This provides a financial disincentive to 988 spammers. The current relatively high cost of international calling, 989 and the presence of national do-not-call regulations, have prevented 990 spam on the PSTN to a large degree. VIPR applies those same 991 protections to SIP connections. 993 VIPR still lowers the cost of communications, but it does so by 994 amortizing that savings over a large number of calls. The costs of 995 communications remain high for infrequent calls to many numbers, and 996 become low for frequent calls to a smaller set of numbers. Since the 997 former is more interesting to spammers, VIPR gears its cost 998 incentives away from the spammers, and towards domains which 999 collaborate frequently. 1001 It is important to note that VIPR does not completely address the 1002 spam problem. A large spamming clearing house organization could 1003 actually incur the costs of launching the PSTN calls to numbers, and 1004 then, in turn, act as a conduit allowing other spammers to launch 1005 their calls to those numbers for a fee. The clearinghouse would 1006 actually need to transit the signaling traffic (or, divulge the 1007 private keys to their domain name), which would incur some cost. As 1008 such, while this is not an impossible situation, the barrier is set 1009 reasonably high to start with - high enough that it is likely to 1010 deter spammers until it becomes a highly attractive target, at which 1011 point other mechanisms can be brought to bear. This is, again, an 1012 example of the incremental deployability philosophy of VIPR. 1014 6.4. Eavesdropping 1016 Another class of attacks involves outsiders attempting to listen in 1017 on the calls that run over the Internet, or obtain information about 1018 the call through observation of signaling. 1020 All of these attacks are prevented by requiring the usage of SIP over 1021 TLS and SRTP. These are mandatory to use. 1023 7. IANA Considerations 1025 This specification does not require any actions from IANA. 1027 8. Acknowledgements 1029 Thanks for review comments from Ken Fischer, Rob Maidhof, Michael 1030 Procter, and others. Thanks to Theo Zourzouvillys for pointing out 1031 the 5th thief of phone numbers attack. 1033 9. References 1035 9.1. Normative References 1037 [I-D.ietf-p2psip-base] 1038 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 1039 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 1040 Base Protocol", draft-ietf-p2psip-base-18 (work in 1041 progress), August 2011. 1043 [I-D.petithuguenin-vipr-reload-usage] 1044 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, "A 1045 Usage of Resource Location and Discovery (RELOAD) for 1046 Public Switched Telephone Network (PSTN) Verification", 1047 draft-petithuguenin-vipr-reload-usage-02 (work in 1048 progress), July 2011. 1050 [I-D.petithuguenin-vipr-sip-antispam] 1051 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, 1052 "Session Initiation Protocol (SIP) Extensions for Blocking 1053 VoIP Spam Using PSTN Validation", 1054 draft-petithuguenin-vipr-sip-antispam-02 (work in 1055 progress), July 2011. 1057 [I-D.jennings-vipr-vap] 1058 Jennings, C., Rosenberg, J., and M. Petit-Huguenin, 1059 "Verification Involving PSTN Reachability: The ViPR Access 1060 Protocol (VAP)", draft-jennings-vipr-vap-01 (work in 1061 progress), July 2011. 1063 [I-D.petithuguenin-vipr-pvp] 1064 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, "The 1065 Public Switched Telephone Network (PSTN) Validation 1066 Protocol (PVP)", draft-petithuguenin-vipr-pvp-01 (work in 1067 progress), June 2011. 1069 9.2. Informative References 1071 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1072 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1073 March 1999. 1075 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1076 A., Peterson, J., Sparks, R., Handley, M., and E. 1077 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1078 June 2002. 1080 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1081 Protocol (SIP): Locating SIP Servers", RFC 3263, 1082 June 2002. 1084 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 1085 Protocol (SIP) and Spam", RFC 5039, January 2008. 1087 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1088 Uniform Resource Identifiers (URI) Dynamic Delegation 1089 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1090 March 2011. 1092 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 1093 Requirements", RFC 5067, November 2007. 1095 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 1096 "Using the Secure Remote Password (SRP) Protocol for TLS 1097 Authentication", RFC 5054, November 2007. 1099 [I-D.ietf-sipclf-format] 1100 Salgueiro, G. and V. Gurbani, "Format for the Session 1101 Initiation Protocol (SIP) Common Log Format (CLF)", 1102 draft-ietf-sipclf-format-02 (work in progress), 1103 September 2011. 1105 [I-D.jones-ipmc-session-id-reqts] 1106 Jones, P., Salgueiro, G., Polk, J., R, P., Liess, L., 1107 Jesske, R., Loreto, S., and H. Kaplan, "Requirements for 1108 an End-to-End Session Identification in IP-Based 1109 Multimedia Communication Networks", 1110 draft-jones-ipmc-session-id-reqts-00 (work in progress), 1111 May 2011. 1113 Appendix A. Changes since last version 1115 This section must be removed before publication as an RFC. 1117 Modifications between jennings-02 and jennings-01: 1119 1. Sections 6,7,8 moved to new VIPR framework document. 1120 2. Editorial changes. 1121 3. Clarifications to re-enforce that the primary objective is not 1122 PSTN bypass but rather to enable enhanced services such as video 1123 between domains. Changed "VoIP" to "SIP" since the focus is not 1124 specifically voice. 1125 4. Added reference for new framework document. 1126 5. Section 5.3: Added references to other documents as appropriate 1127 - e.g., -pvp, -spam, etc. 1128 6. Moved validation diagrams and text (from 5.3.4) into Validation 1129 and caching section (5.3.3). 1130 7. Condensed discussion of spam in section 5.3.3 and updated SPAM 1131 section in security section. 1133 Modifications between jennings-01 and rosenberg-04: 1135 o Not specified. 1137 Modifications between rosenberg-04 and rosenberg-03 1139 o Nits. 1140 o Shorter I-Ds references. 1141 o Changed phone numbers to follow E.123 presentation. 1142 o Expanded P2P initialisms. 1143 o Uses +1 408 555 prefix for phone numbers in examples. 1145 Authors' Addresses 1147 Mary Barnes 1148 Polycom 1149 TX 1150 US 1152 Email: mary.ietf.barnes@gmail.com 1154 Cullen Jennings 1155 Cisco 1156 170 West Tasman Drive 1157 MS: SJC-21/2 1158 San Jose, CA 95134 1159 USA 1161 Phone: +1 408 421-9990 1162 Email: fluffy@cisco.com 1164 Jonathan Rosenberg 1165 jdrosen.net 1166 Monmouth, NJ 1167 US 1169 Email: jdrosen@jdrosen.net 1170 URI: http://www.jdrosen.net 1172 Marc Petit-Huguenin 1173 Stonyfish 1175 Email: marc@stonyfish.com