idnits 2.17.1 draft-marocco-p2psip-interwork-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 894. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 900. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2007) is 6265 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) -- Looks like a reference, but probably isn't: '2' on line 738 == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-04 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-01 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-09 == Outdated reference: A later version (-04) exists of draft-willis-p2psip-concepts-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Marocco 3 Internet-Draft Telecom Italia 4 Intended status: Standards Track D. Bryan 5 Expires: September 3, 2007 SIPeerior Technologies Inc. 6 March 2, 2007 8 Interworking between P2PSIP Overlays and Conventional SIP Networks 9 draft-marocco-p2psip-interwork-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 3, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes how user agents registered in P2PSIP overlay 43 networks can interwork with those in conventional SIP networks. 44 Communications between any two user agents will happen through the 45 SIP protocol and the location of SIP servers will follow the usual 46 procedures. However, interworking in some environments may require 47 the support of additional elements; this document also describes such 48 elements and how to locate them in P2PSIP overlays. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1. P2PSIP Overlay Identifier . . . . . . . . . . . . . . . . 8 56 3. Additional Logical Elements for Interworking . . . . . . . . . 9 57 3.1. P2PSIP Proxy Peer . . . . . . . . . . . . . . . . . . . . 9 58 3.1.1. Insertion into DNS . . . . . . . . . . . . . . . . . . 9 59 3.2. Relay Agent Peer . . . . . . . . . . . . . . . . . . . . . 10 60 3.2.1. Relay Agent Peer Selection . . . . . . . . . . . . . . 10 61 3.3. Locating the new Elements . . . . . . . . . . . . . . . . 10 62 3.3.1. P2PSIP Proxy Peer URI . . . . . . . . . . . . . . . . 10 63 3.3.2. Relay Agent Peers URIs . . . . . . . . . . . . . . . . 11 64 3.3.3. Impacts on the Overlay . . . . . . . . . . . . . . . . 11 65 4. User Registration . . . . . . . . . . . . . . . . . . . . . . 12 66 4.1. Registering with the Overlay . . . . . . . . . . . . . . . 12 67 4.2. Registering with a Public SIP Network . . . . . . . . . . 12 68 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 5.1. Caller and Callee within the Overlay . . . . . . . . . . . 13 70 5.2. Callee within a Public SIP Network . . . . . . . . . . . . 14 71 5.3. Caller within a Public SIP Network . . . . . . . . . . . . 16 72 5.4. Callee Registered in a Public Network from an Overlay . . 17 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 74 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 21 75 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 76 8.1. Changes from 00 . . . . . . . . . . . . . . . . . . . . . 22 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 81 Intellectual Property and Copyright Statements . . . . . . . . . . 25 83 1. Introduction 85 This document describes how user agents registered in P2PSIP overlay 86 networks [I-D.willis-p2psip-concepts] can interwork with those in 87 conventional SIP networks [RFC3261]. In particular, no assumption is 88 made about the overlay but that it allows clients and peers to insert 89 and retrieve routing information, possibly bound to URIs [RFC3986]. 91 The main goal of peer-to-peer networks is to build distributed 92 systems using resources such as bandwidth, storage and computation 93 power, shared by participating peers. P2PSIP overlay peer protocols, 94 in particular, aim to enable lookup services for clients initiating 95 and managing SIP protocol sessions without relying on central 96 servers. 98 To enable P2PSIP overlays to fully interwork with conventional SIP 99 networks (i.e. handling sessions either originated or terminated in 100 public domains), some peers must provide more resources than those 101 required for maintaining the overlay through the P2PSIP peer 102 protocol. Indeed, connectivity with public domains requires some 103 peers willing to share their ability to exchange messages with public 104 hosts on the Internet and, even more important, to be registered in 105 the public naming service (DNS) for a fully qualified domain name 106 (FQDN) which uniquely identifies the overlay they participate in. 108 The purpose of this document is to define the elements which can 109 supply the additional resources required for full interworking, to 110 specify how such elements can register and be located within the 111 overlay, and to describe how user agents (UAs) can establish sessions 112 across overlay boundaries. 114 1.1. Terminology 116 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 117 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 118 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 119 described RFC 2119 [RFC2119]. 121 Terminology defined in RFC 3261 [RFC3261] and in P2PSIP concepts 122 draft [I-D.willis-p2psip-concepts] is used without definition. 124 Conventional SIP Network: A SIP network where location and routing 125 functionalities are provided by centralized elements, as described in 126 RFC 3261 [RFC3261]. 128 Public SIP Network: A SIP network, either conventional or P2PSIP 129 based, whose user agents can be located using procedures specified in 130 RFC 3263 [RFC3263]. 132 P2PSIP Proxy Peer: An element registered with the P2PSIP overlay 133 which is able to route SIP messages directed to public URLs. If a 134 P2PSIP proxy peer is bound to a FQDN, it can be used also for routing 135 SIP messages directed to UAs in the P2PSIP overlay. 137 Relay Agent Peer: An element registered with the P2PSIP overlay which 138 provides relayed transport addresses through protocols like TURN 139 [I-D.ietf-behave-turn] and TEREDO [RFC4380] for allowing media 140 streaming between UAs without direct connectivity. 142 2. Overview 144 User agents registered in a P2PSIP overlay are able to reach each 145 other through the SIP protocol, with resource location handled by the 146 overlay itself. Figure 1 shows a typical example of the very basic 147 deployment, where the overlay supplies the functionalities which, in 148 canonical networks, are usually provided by registrars and proxies. 150 sip:alice@p2psip.org 151 ___ 152 /_\ Media--------+ 153 SIP | 154 : | 155 +-----------:-----------+ | 156 |p2psip.org : | | 157 | : | | 158 | : | | 159 |P2PSIP : | | 160 |Overlay : | | 161 | : | | 162 | : | | 163 | : | | 164 | : | | 165 +-----------:-----------+ | 166 : | 167 : | 168 ___ | 169 /_\ -------------+ 171 sip:bob@p2psip.org 173 Session between P2PSIP user agents. Media streams flow directly 174 between UAs. 176 Figure 1 178 The example in Figure 1 requires that all UAs have direct 179 connectivity with each other. However, since such connectivity is 180 often impeded by environmental constraints introduced by NATs, 181 firewalls or simply by lack of physical links, resources other than 182 those used for maintaining the overlay are generally needed for users 183 to effectively establish multimedia sessions. 185 Figure 2 shows an example where UAs use the overlay to store and 186 locate locations of relay agent peers (Section 3.2) used to 187 effectiverly exchange data such as media even when NATs are present. 189 sip:alice@p2psip.org 190 ___ 191 /_\ Media--------+ 192 SIP | 193 : | 194 +-----------:-----------+ | 195 |p2psip.org : +-----------------+ 196 | : +-----------------+| 197 | : |Relay Agent Peer |+ 198 |P2PSIP : +-----------------+ 199 |Overlay : | | 200 | : | | 201 | : | | 202 | : | | 203 | : | | 204 +-----------:-----------+ | 205 : | 206 : | 207 ___ | 208 /_\ -------------+ 210 sip:bob@p2psip.org 212 Session between P2PSIP user agents. Media streams are relayed. 214 Figure 2 216 Overlays such as those depicted in Figure 1 and Figure 2 can be used 217 only for local communications. Even in network environments where 218 connectivity is not a problem, interworking with non-P2PSIP nodes 219 must be considered. While P2PSIP UAs can initiate sessions with 220 conventional SIP UAs using common resolution procedures defined in 221 RFC 3263 [RFC3263], they cannot be addressed in any way from outside 222 the overlay. 224 Overlays intended to provide global connectivity must provide 225 interworking with canonical SIP, in addition to providing relaying 226 services amongst the P2PSIP overlay peers. These overlays must 227 provide mechanisms for routing SIP messages to conventional SIP 228 entities in the public Internet and to be located and contacted using 229 standard SIP procedures. Figure 3 shows an example where 230 communication is enabled both within the overlay and across its 231 boundaries, thanks to resources shared by P2PSIP Proxy Peers 232 (Section 3.1). 234 sip:alice@p2psip.org sip:carol@example.com 235 ___ ___ 236 /_\ Media--------+ +--------------------- /_\ 237 SIP | | : 238 : | | : 239 +-----------:-----------+ | | : 240 |p2psip.org : +-----------------+ : 241 | : +-----------------+| : 242 | : |Relay Agent Peer |+ : 243 |P2PSIP : +-----------------+ : 244 |Overlay : | : 245 | : +-----------------+ : 246 | : +-----------------+| +---------+ 247 | :.......|P2PSIP Proxy Peer|+...........|SIP Proxy| 248 | +-----------------+ +---------+ 249 +-----------------------+sip:p2psip.org sip:example.com 251 Example of a system connecting a UA in a P2PSIP overlay and one in a 252 conventional SIP network. The user in the P2PSIP overlay is 253 addressed by her local URI and data streams are relayed. 255 Figure 3 257 It is worth noting that, in the example in Figure 3, users who 258 register in the overlay MUST have URLs whose host parts match with 259 the FQDN for which overlay's P2PSIP proxy peers are bound to. That 260 is, the P2P overlay identifier for the overlay must be an FQDN. 261 Section 4 defines the detailed procedure for user registration. 263 Overlays such as the one in Figure 3, which have resources for both 264 relaying data and routing SIP messages to and from public servers can 265 be considered equivalent to conventional SIP networks when viewed 266 from the outside. Such a property is extremely important for P2PSIP 267 UAs which have also an account with conventional SIP providers, but 268 do not have direct connectivity with their servers. Indeed, such 269 UAs, following the usual procedures defined in RFC 3261 [RFC3261], 270 can register their overlay URL as a contact for their conventional 271 SIP address of record (AOR). 273 Figure 4 shows an example where a user (alice) registers both in an 274 overlay (p2psip.org) and, through P2PSIP proxy peers, with a 275 conventional SIP network (sip:example.org). SIP messages sent by 276 another user (carol) who only knows her conventional SIP URL 277 (sip:alice@example.org) are routed to her conventional SIP proxy 278 (sip:example.org) and, from here, to overlay's P2PSIP proxy 279 peers(sip:p2psip.org) which eventually reach her through the overlay. 281 sip:alice@example.org (public AOR) 282 sip:alice@p2psip.org sip:carol@example.com 283 ___ ___ 284 /_\ Media--------+ +--------------------- /_\ 285 SIP | | : 286 : | | : 287 +-----------:-----------+ | | : 288 |p2psip.org : +-----------------+ : 289 | : +-----------------+| : 290 | : |Relay Agent Peer |+ : 291 |P2PSIP : +----------------+ : 292 |Overlay : | : 293 | : +-----------------+ : 294 | : +-----------------+| +---------+ 295 | :.......|P2PSIP Proxy Peer|+.... ....|SIP Proxy| 296 | +-----------------+ : : +---------+ 297 +-----------------------+sip:p2psip.org : : sip:example.com 298 : : 299 : : 300 +---------+ 301 |SIP Proxy| 302 +---------+ 303 sip:example.org 304 (alice's client-server proxy) 306 Interworking between one UA in a P2PSIP overlay and one in a 307 conventional SIP network. The user in the P2PSIP overlay is 308 addressed by her well known global URI and data streams are relayed 310 Figure 4 312 2.1. P2PSIP Overlay Identifier 314 For overlays which wish to interconnect with existing SIP networks, 315 the P2PSIP overlay identifier MUST be a FQDN. Moreover, some entity 316 (humans or automata) responsible for the overlay MUST be able to 317 manipulate DNS records referring to such identifier for registering 318 and unregistering P2PSIP proxy peers as defined in Section 3.1. 320 Procedures for selecting overlay identifiers and for manipulating DNS 321 records are outside of the scope of this document. 323 3. Additional Logical Elements for Interworking 325 This section describes the network elements which provide the 326 additional resources that P2PSIP overlays need for interworking with 327 conventional SIP networks. Note that these are logical roles, and 328 may (and in fact likely would) be combined into one entity such as a 329 P2PSIP UA. As with the functions in RFC 3261 [RFC3261], we treat 330 them as separate entities in this document for clarity. 332 3.1. P2PSIP Proxy Peer 334 A P2PSIP proxy peer, as mentioned in [I-D.willis-p2psip-concepts] 335 (Section 3.1, "What Kinds of P2PSIP Peers and Clients Might Exist?"), 336 is an element which can exchange SIP messages with public domains and 337 provides this function as a service to the overlay it is registered 338 in. In particular, the most important characteristics are the 339 following: 341 o A P2PSIP proxy peer MUST be able to send SIP requests and receive 342 SIP responses directed to hosts with a public Internet address. 344 o A P2PSIP proxy peer MUST be able to perform location procedures 345 defined in RFC 3263 [RFC3263]. This implies that it MUST also be 346 able to query the DNS. 348 o A P2PSIP proxy peer SHOULD have a binding in the DNS so that any 349 resolution for the overlay identifier performed according to 350 location procedures defined in RFC 3263 [RFC3263] returns a list 351 of P2PSIP proxy peers including this node. If such binding 352 doesn't exist for any of the P2PSIP proxy peers, the overlay 353 cannot be reached by public SIP networks. 355 P2PSIP proxy peer MUST record route on SIP request crossing overlay's 356 boundaries, using the overlay identifier instead of their local 357 address, due to the ephemeral nature of P2PSIP nodes. 359 3.1.1. Insertion into DNS 361 The mechanism for registering P2PSIP proxy peers with the DNS is a 362 critical point of the overlay. In fact, if the authorization 363 policies are too permissive, it could be exploited by malicious nodes 364 for denial of service attacks, while, if they are too strict, it 365 could introduce a bottleneck in negation with the peer-to-peer model. 366 Future specifications need to provide mechanisms for managing 367 controlled registration with the DNS, allowing the adoption of 368 different policies in different deployments. 370 P2PSIP proxy peers will generally be located on devices with direct 371 Internet access. It is NOT RECOMMENDED to insert records in the DNS 372 for P2PSIP proxy peers behind NATs. While NAT traversal mechanisms 373 such as STUN [I-D.ietf-behave-rfc3489bis] and TEREDO [RFC4380] can be 374 used to determine a public address and port which can be registered 375 in the DNS, NAT binding changes are not deterministic and can cause 376 inconsistencies. 378 3.2. Relay Agent Peer 380 A relay agent peer is an element which can directly exchange media 381 with hosts on the public Internet. STUN relay servers (previously 382 called TURN servers), specified in the STUN draft 383 [I-D.ietf-behave-turn] and TEREDO [RFC4380] relays are typical 384 examples of relay agents. 386 Relay agent peers can be located behind some types of NATs if, using 387 traversal mechanisms not based on relay (e.g. STUN 388 [I-D.ietf-behave-rfc3489bis]), they can obtain several public 389 address-port pairs. 391 3.2.1. Relay Agent Peer Selection 393 It is extremely difficult to determine apriori which type of relay 394 agent peer fits best for a media session with a particular UA. To 395 avoid this choice, UAs SHOULD find as many relay agent peers as 396 possible and MUST establish media sessions using the ICE 397 [I-D.ietf-mmusic-ice] mechanism so that the most appropriate relay 398 can be chosen at run time. 400 3.3. Locating the new Elements 402 P2PSIP UAs often need to locate resources or obtain services provided 403 by P2PSIP proxy peers and relay agent peers. Such lookup is 404 performed directly in the overlay through the P2PSIP client protocol. 406 One possible way to allow the location of resources within the 407 overlay is to define URI for identifying the elements which provide 408 them. While many mechanisms are possible, we outline a simple 409 possible approach below. 411 3.3.1. P2PSIP Proxy Peer URI 413 P2PSIP proxy peers act as SIP servers and are identified by SIP URLs. 414 Such URLs MUST have only the host field set, and its value MUST match 415 the overlay identifier. 417 For example, the URL which identifies P2PSIP proxy peers registered 418 within the overlay "p2psip.org" could be "sip:p2psip.org". 420 It is worth noting that the lookups of P2PSIP proxy peers, made in 421 the overlay or in the DNS, are conceptually identical. 423 3.3.2. Relay Agent Peers URIs 425 Since relay agent peers can implement different protocols, there will 426 be different URI schemas for identifying each kind. As a general 427 rule, URLs identifying relay agent peers which implement a given 428 protocol, will be formed according to the specific scheme and will 429 have the host field (or the equivalent field) matching the overlay 430 identifier. 432 While such URI schema do not currently exist, one could use something 433 like "turn:p2psip.org" and "teredo:p2psip.org" identify relay agent 434 peers registered in the overlay "p2psip.org" and implementing TURN 435 and TEREDO protocols respectively. 437 3.3.3. Impacts on the Overlay 439 In overlays where the load balancing among all peers utilizes a key- 440 partitioning approach, the lookup of services based on well known 441 URIs would cause dangerous displacements of the overlay traffic. In 442 fact, since many clients and peers need to know the location of a 443 relay agent peer, the peer responsible for a URI which identifies any 444 of those would have to handle much more lookup requests than other 445 peers which store only user records. 447 4. User Registration 449 In order to be reachable from a conventional SIP UA, a UA 450 participating in a P2PSIP overlay that supports interworking MUST 451 create a binding in the overlay between its local contact and an URL 452 (i.e. P2PSIP overlay user identifier) as defined in Section 4.1. If 453 the user associated with the UA has another public SIP URI, they MAY 454 register such a URL with the authoritative registrar using a P2PSIP 455 proxy peer as described in Section 4.2. 457 4.1. Registering with the Overlay 459 UAs perform registration in the overlay through the P2PSIP client 460 protocol. Such registration consists of an insertion of a P2PSIP 461 overlay user routing record bound to the user identifier. 463 To support interworking with canonical SIP, the user identifier MUST 464 be a well formed SIP URL, with the host field matching the overlay 465 identifier. The user field MUST be set, and its value will usually 466 be the P2PSIP overlay user identifier. 468 According to local policies, the user MAY need to enroll and obtain 469 appropriate credentials for their URL before being able to register 470 records for it. 472 4.2. Registering with a Public SIP Network 474 Users registered in fully interworking P2PSIP overlays can use P2PSIP 475 proxy peers for sending messages to public SIP networks. This is 476 especially useful for registering bindings for AORs for which the 477 overlay is not authoritative. This mechanism can be used to register 478 the contact for a node participating in a P2PSIP overlay with a well 479 known SIP URI associated with the user that is well known to their 480 usual buddies but outside the overlay. 482 For registering with a public SIP network, an UA follows these steps: 484 1. The UA MUST perform user registration as defined in Section 4.1. 486 2. The UA MUST get the address of a P2PSIP proxy peer performing a 487 lookup as defined in Section 3.3. 489 3. The UA MUST send a REGISTER message for binding the URL it has 490 registered in the overlay to its public AOR. The message MUST be 491 sent using the P2PSIP proxy peer as an outbound proxy. 493 5. Examples 495 5.1. Caller and Callee within the Overlay 497 The following example refers to the network depicted in Figure 2. 499 Alice overlay relay relay Bob 500 | | | | | 501 | | | | | 502 | (1) Get Relay | | | | 503 |-------------->| | | | 504 | (2) Response | | | | 505 |<--------------| | | | 506 | | | | | 507 | (3) Init Relay| | | | 508 |------------------------------>| | | 509 | (4) Ok | | | | 510 |<------------------------------| | | 511 | | | | | 512 | (5) INVITE | | | | 513 |-------------->| (6) INVITE | | | 514 | |---------------------------------------------->| 515 | | | | | 516 | | | | (7) Get Relay | 517 | |<----------------------------------------------| 518 | | | | (8) Response | 519 | |---------------------------------------------->| 520 | | | | | 521 | | | |(9) Init Relay | 522 | | | |<--------------| 523 | | | | (10) Ok | 524 | | | |-------------->| 525 | | | | | 526 | | | | | 527 | (11) ICE | | | | 528 | /-----------\ | /-------------------------------------------\ | 529 |/ \|/ \| 530 |\ /|\ /| 531 | \-----------/ | \-------------------------------------------/ | 532 | | | | | 533 | (12) Media | | | | 534 |<=============================>|<=============>|<=============>| 535 | | | | | 537 Figure 5 539 First Alice queries the overlay for discovering the location of some 540 relay agent peers (1-2) and initializes one (3-4) for preparing an 541 ICE candidate. Then she sends an INVITE request with an ICE offer to 542 Bob through the overlay (5-6). 544 When Bob receives the INVITE, he queries the overlay to obtain the 545 location of some relay agent peers (7-8) and initializes one (9-10) 546 for preparing an ICE candidate. Then the session establishment 547 completes carrying ICE offers and answers and following the signaling 548 path of the first INVITE (11). 550 Eventually, the media is relayed across both Alice's and Bob's relay 551 agent peers (12). 553 5.2. Callee within a Public SIP Network 555 The following example refers to the network depicted in Figure 3. 557 ---------------- overlay members ------------- ----- public ----- 558 Alice overlay relay P2PSIP Carol's Carol 559 | | | proxy peer proxy | 560 | | | | | | 561 |(1) Get Relay | | | | | 562 |------------->| | | | | 563 |(2) Response | | | | | 564 |<-------------| | | | | 565 | | | | | | 566 |(3) Init Relay| | | | | 567 |------------------------->| | | | 568 |(4) Ok | | | | | 569 |<-------------------------| | | | 570 | | | | | | 571 |(5) Get Proxy | | | | | 572 |------------->| | | | | 573 |(6) Response | | | | | 574 |<-------------| | | | | 575 | | | | | | 576 |(7) INVITE | | | | | 577 |------------------------------------->|(8) INVITE | | 578 | | | |---------->|(9) INVITE | 579 | | | | |---------->| 580 | | | | | | 581 | (10) ICE | | | | | 582 | /----------------------------------\ | /-------------------\ | 583 |/ \|/ \| 584 |\ /|\ /| 585 | \----------------------------------/ | \-------------------/ | 586 | | | | | | 587 |(11) Media | | | | | 588 |<========================>|<=================================>| 589 | | | | | | 591 Figure 6 593 First Alice queries the overlay for discovering the location of one 594 or more relay agent peers (1-2) and initializes one (3-4) for 595 preparing an ICE candidate. Then she queries the overlay requesting 596 the location of some P2PSIP proxy peers (5-6) and sends an INVITE 597 request with an ICE offer to Carol through one of those (7). 599 The P2PSIP proxy peers performs common location procedures and 600 discovers the address of Carol's authoritative proxy for routing the 601 INVITE. Before sending (8), it adds to the message a Record-Route 602 header with a value equal to the overlay identifier, so that any 603 other request will reach a P2PSIP proxy peer registered in the same 604 overlay. Carol's location is found by her proxy based on 605 registration information (9). 607 When Carol receives the INVITE, the session establishment completes 608 carrying ICE offers and answers (if supported) (10). 610 Media is relayed across Alice's relay agent peer (11). 612 5.3. Caller within a Public SIP Network 614 The following example refers to the network depicted in Figure 3. 616 Alice overlay relay P2PSIP Carol 617 | | | proxy peer | 618 | | | | | 619 | | | | (1) INVITE | 620 | | | (2) INVITE |<--------------| 621 | (3) INVITE |<------------------------------| | 622 |<--------------| | | | 623 | | | | | 624 |(4) Get Relay | | | | 625 |-------------->| | | | 626 |(5) Response | | | | 627 |<--------------| | | | 628 | | | | | 629 |(6) Init Relay | | | | 630 |------------------------------>| | | 631 |(7) Ok | | | | 632 |<------------------------------| | | 633 | | | | | 634 | (8) ICE | | | | 635 | /-------------------------------------------\ | /-----------\ | 636 |/ \|/ \| 637 |\ /|\ /| 638 | \-------------------------------------------/ | \-----------/ | 639 | | | | | 640 | (9) Media | | | | 641 |<=============================>|<=============================>| 642 | | | | | 644 Figure 7 646 When Carol wants to contact Alice (using the address bound to the P2P 647 overlay identifier), she performs a conventional SIP location 648 procedure (RFC3263) and finds the address of one or more P2PSIP proxy 649 peers for the overlay. Carol then sends an INVITE message addressed 650 to Alice to any one of the set of such addresses (1). The P2PSIP 651 proxy peer routes the INVITE to Alice through the overlay (2-3) using 652 the overlay's resource location and routing mechanisms. 654 When Alice receives the INVITE, she queries the overlay to discover 655 the location of one or more relay agent peers (4-5) and initializes 656 one for preparing an ICE candidate (or an answer, if the INVITE 657 didn't declare to support ICE) (6-7). 659 Then the session establishment completes carrying ICE offers and 660 answers (if the INVITE declared to support it) (8). 662 Finally, media is relayed across Alice's relay agent peer (9). 664 5.4. Callee Registered in a Public Network from an Overlay 666 The following example refers to the network depicted in Figure 3. 668 ---------------- overlay members ------------- ----- public ----- 669 Alice overlay relay P2PSIP Alice's Carol 670 | | | proxy peer proxy | 671 | | | | | | 672 |(1) Get Proxy | | | | | 673 |------------->| | | | | 674 |(2) Response | | | | | 675 |<-------------| | | | | 676 | | | | | | 677 |(3) REGISTER | | | | | 678 |------------------------------------->|(4) REGISTER | 679 | | | |---------->| | 680 : : : : : : 681 : : : : : : 682 : : : : : : 683 | | | | |(5) INVITE | 684 | | | |(6) INVITE |<----------| 685 | | |(7) INVITE |<----------| | 686 | (8) INVITE |<----------------------| | | 687 |<-------------| | | | | 688 | | | | | | 689 |(9) Get Relay | | | | | 690 |------------->| | | | | 691 |(10)Response | | | | | 692 |<-------------| | | | | 693 | | | | | | 694 |(11)Init Relay| | | | | 695 |------------------------->| | | | 696 |(12)Ok | | | | | 697 |<-------------------------| | | | 698 | | | | | | 699 | (13) ICE | | | | | 700 | /----------------------------------\ | /-------------------\ | 701 |/ \|/ \| 702 |\ /|\ /| 703 | \----------------------------------/ | \-------------------/ | 704 | | | | | | 705 |(14) Media | | | | | 706 |<========================>|<=================================>| 707 | | | | | | 709 Figure 8 711 Right after registering in the overlay, Alices queries the location 712 of some P2PSIP proxy peers (1-2) and sends a REGISTER request to her 713 public SIP server through one of them, binding the URL registered in 714 the overlay to her public AOR (4-3). 716 When Carol wants to contact Alice, she sends an INVITE request 717 addressed to her public SIP proxy (5). The proxy finds in its local 718 database the binding with the URL registered in the overlay, so it 719 performs a conventional SIP location procedure (RFC3263) for the 720 overlay identifier (i.e. the domain of the URL) and finds the address 721 of one or more P2PSIP proxy peers. Then it routes the INVITE message 722 to any of those (6), which in turn routes the INVITE to Alice through 723 the overlay (7-8) using the overlay's resource location and routing 724 mechanisms. 726 When Alice receives the INVITE, she queries the overlay to discover 727 the location of one or more relay agent peers (9-10) and initializes 728 one for preparing an ICE candidate (or an answer, if the INVITE 729 didn't declare to support ICE) (11-12). 731 Then the session establishment completes carrying ICE offers and 732 answers (if the INVITE declared to support it) (13). 734 Finally, media is relayed across Alice's relay agent peer (14). 736 6. Security Considerations 738 Besides the security issues already raised in SIP [2] and other 739 P2PSIP work, the interconnection model based on "well known" URIs is 740 vulnerable to spoofing attacks. More work, or the application of 741 existing SIP work on identity should applied to this to mitigate this 742 risk. 744 Another security issue is the registration of P2PSIP proxy peers with 745 a public DNS; it could be either a point of failure, if registration 746 policies are too permissive, or a threat to the peer-to-peer model, 747 if they are too restrictive. Mechanisms must allow for nodes to be 748 entered and removed, in a secure fashion. This work is related to 749 and likely to use dynamic DNS. 751 In a full interworking scenario identity assertion is critically 752 important; this document shows how it could be achieved proxying 753 regular authentication to traditional SIP domains. Mechanisms such 754 as issuing certificates to assert and validate user identities should 755 be used. 757 7. Open Issues 759 1. We need to define a mechanism for authenticating, inserting and 760 removing DNS records for the overlay. Need to work with dynamic 761 DNS group to address this. 763 2. Service location based on well-known URIs impacts the overlay 764 load-balance, especially if it is based on key partitioning among 765 peers. 767 3. Clients route SIP messages addressed to external hosts directly 768 to P2PSIP proxy peers, without involving the overlay. We should 769 define in details how and why this works, but there are some 770 implications on the P2PSIP client protocol to be defined. If the 771 overlay is supposed to let also conventional SIP user agents 772 work, such routing must be done directly by peers. 774 4. URI schemes for relay agent peers are not defined and are also 775 needed for things besides interworking. Is it feasible to define 776 URNs for those protocols for which a URI schema does not exist? 778 5. As security/identity mechanisms for P2PSIP (certificate based or 779 otherwise) emerge, they should be worked into this document. 781 8. Changes 783 8.1. Changes from 00 785 Introduced the issue of the P2PSIP proxy peer registration with the 786 DNS outside "Security Considerations". 788 Introduced the issue of load-balancing when lookup is based on well- 789 known URIs. 791 Included the example showing registration with public SIP networks. 793 9. References 795 9.1. Normative References 797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, March 1997. 800 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 801 A., Peterson, J., Sparks, R., Handley, M., and E. 802 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 803 June 2002. 805 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 806 Protocol (SIP): Locating SIP Servers", RFC 3263, 807 June 2002. 809 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 810 Resource Identifier (URI): Generic Syntax", STD 66, 811 RFC 3986, January 2005. 813 9.2. Informative References 815 [I-D.ietf-behave-rfc3489bis] 816 Rosenberg, J., "Simple Traversal Underneath Network 817 Address Translators (NAT) (STUN)", 818 draft-ietf-behave-rfc3489bis-04 (work in progress), 819 July 2006. 821 [I-D.ietf-behave-turn] 822 Rosenberg, J., "Obtaining Relay Addresses from Simple 823 Traversal of UDP Through NAT (STUN)", 824 draft-ietf-behave-turn-01 (work in progress), June 2006. 826 [I-D.ietf-mmusic-ice] 827 Rosenberg, J., "Interactive Connectivity Establishment 828 (ICE): A Methodology for Network Address Translator (NAT) 829 Traversal for Offer/Answer Protocols", 830 draft-ietf-mmusic-ice-09 (work in progress), June 2006. 832 [I-D.willis-p2psip-concepts] 833 Willis, D., Bryan, D., Matthews, P., and E. Shim, 834 "Concepts and Terminology for Peer to Peer SIP", 835 draft-willis-p2psip-concepts-00 (work in progress), 836 June 2006. 838 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 839 Network Address Translations (NATs)", RFC 4380, 840 February 2006. 842 Authors' Addresses 844 Enrico Marocco 845 Telecom Italia 846 Via G. Reiss Romoli, 274 847 Turin 10148 848 Italy 850 Phone: +39 011 228 5029 851 Email: enrico.marocco@telecomitalia.it 853 David Bryan 854 SIPeerior Technologies, Inc. and College of William and Mary 855 3000 Easter Circle 856 Williamsburg, VA 23188 857 USA 859 Phone: +1.757.565.0101 860 Email: dbryan@SIPeerior.com 862 Full Copyright Statement 864 Copyright (C) The IETF Trust (2007). 866 This document is subject to the rights, licenses and restrictions 867 contained in BCP 78, and except as set forth therein, the authors 868 retain all their rights. 870 This document and the information contained herein are provided on an 871 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 872 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 873 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 874 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 875 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 876 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 878 Intellectual Property 880 The IETF takes no position regarding the validity or scope of any 881 Intellectual Property Rights or other rights that might be claimed to 882 pertain to the implementation or use of the technology described in 883 this document or the extent to which any license under such rights 884 might or might not be available; nor does it represent that it has 885 made any independent effort to identify any such rights. Information 886 on the procedures with respect to rights in RFC documents can be 887 found in BCP 78 and BCP 79. 889 Copies of IPR disclosures made to the IETF Secretariat and any 890 assurances of licenses to be made available, or the result of an 891 attempt made to obtain a general license or permission for the use of 892 such proprietary rights by implementers or users of this 893 specification can be obtained from the IETF on-line IPR repository at 894 http://www.ietf.org/ipr. 896 The IETF invites any interested party to bring to its attention any 897 copyrights, patents or patent applications, or other proprietary 898 rights that may cover technology that may be required to implement 899 this standard. Please address the information to the IETF at 900 ietf-ipr@ietf.org. 902 Acknowledgment 904 Funding for the RFC Editor function is provided by the IETF 905 Administrative Support Activity (IASA).