idnits 2.17.1 draft-hautakorpi-p2psip-with-hip-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 874. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 892. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 898. 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 Copyright Line does not match the current year == Line 275 has weird spacing: '...gnaling d) Su...' -- 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 (November 19, 2007) is 6003 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: 'UDP' on line 784 ** Downref: Normative reference to an Informational draft: draft-willis-p2psip-concepts (ref. '1') ** Obsolete normative reference: RFC 4423 (ref. '3') (Obsoleted by RFC 9063) == Outdated reference: A later version (-09) exists of draft-ietf-hip-nat-traversal-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-nat-traversal (ref. '4') -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-06) exists of draft-ahrenholz-hiprg-dht-01 ** Downref: Normative reference to an Informational draft: draft-ahrenholz-hiprg-dht (ref. '9') ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '10') == Outdated reference: A later version (-04) exists of draft-bryan-p2psip-reload-01 == Outdated reference: A later version (-01) exists of draft-baset-p2psip-p2pp-00 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Working Group J. Hautakorpi 3 Internet-Draft G. Camarillo 4 Intended status: Standards Track Ericsson 5 Expires: May 22, 2008 J. Koskela 6 HIIT 7 November 19, 2007 9 Utilizing HIP (Host Identity Protocol) for P2PSIP (Peer-to-peer Session 10 Initiation Protocol) 11 draft-hautakorpi-p2psip-with-hip-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 22, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document specifies how Host Identity Protocol (HIP) can be 45 utilized in Peer-to-Peer Session Initiation Protocol (P2PSIP) 46 networks. Peers in a P2PSIP network need to have long-lived 47 connections to other peers in the network, and HIP can be utilized to 48 setup and maintain those connections. HIP is a good choice for 49 connection maintenance, because it provides functionalities like 50 Network Address Translation (NAT) traversal, mobility, multi-homing, 51 and enhanced security properties. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Short Overview of HIP . . . . . . . . . . . . . . . . . . . . 3 58 3.1. HIP's NAT Traversal Mechanism . . . . . . . . . . . . . . 4 59 4. Managing Long-lived Connections in P2PSIP . . . . . . . . . . 6 60 4.1. Joining Phase . . . . . . . . . . . . . . . . . . . . . . 8 61 4.2. Normal Operation Phase . . . . . . . . . . . . . . . . . . 8 62 4.3. Leaving Phase . . . . . . . . . . . . . . . . . . . . . . 10 63 5. Using Relays . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 5.1. Baseline Relay Search . . . . . . . . . . . . . . . . . . 11 65 5.2. Distributed Relay Search . . . . . . . . . . . . . . . . . 12 66 6. Mobility Scenario - Make-Before-Break . . . . . . . . . . . . 12 67 7. Mobility Scenario - Break-Before-Make . . . . . . . . . . . . 14 68 8. Multi-homing Scenario . . . . . . . . . . . . . . . . . . . . 15 69 9. Other Benefits that HIP Provides for P2PSIP . . . . . . . . . 15 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 74 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 75 Appendix A. Peer's Software Architecture . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 77 Intellectual Property and Copyright Statements . . . . . . . . . . 20 79 1. Introduction 81 P2PSIP [1] is a mechanism which incorporates Peer-to-Peer (P2P) 82 technologies and the Session Initiation Protocol (SIP) [2] signaling 83 in a way which allows the transfer of proxy-registrar functionality 84 to the end-hosts. 86 In P2PSIP network, storage and routing services are provided by Peers 87 which participate to the overlay. Peers need to have long-lived 88 connections to other peers. This document describes how Host 89 Identity protocol (HIP) [3], and HIP's NAT traversal mechanisms [4], 90 can be used for establishing and maintaining those connections. This 91 draft utilizes HIP as it is, and does not propose any changes or 92 modifications to it. 94 The complexity of the actual P2PSIP application implementations 95 decrease as they can utilize the Interactive Connectivity 96 Establishment (ICE) [5] NAT traversal methodology built into HIP [4]. 97 Using HIP provides many other transparent benefits for applications 98 as well, such as mobility, multi-homing, and enhanced security 99 properties. 101 The remainder of this document is organized as follows. Section 3 102 gives a short overview to HIP and HIP's NAT traversal mechanism. 103 Section 4 present how HIP can be utilized for P2PSIP. Section 5 104 speficifies how relays can be used. Section 6 and Section 7 105 illustrates mobility scenarios and how they can be handled with HIP. 106 Section 8 presents multi-homing scenarios. Section 9 lists other 107 benefits that HIP provides for P2PSIP networks. Finally Section 10 108 and Section 11 present security and IANA considerations respectively. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [6]. 116 Most of the terminology and concepts presented in this document are 117 aligned with [1], and [4]. Other terms are defined when used. 119 3. Short Overview of HIP 121 HIP [3] is a new communication architecture which introduces a 122 protocol between the network and transport layers which binds 123 connection end-points to cryptographicly generated host identifiers 124 instead of network addresses. 126 A host identifier (HI) is the public part of a public/private key 127 pair owned by the host. More commonly used for representing the 128 identity are Host Identity Tags (HITs), a 128-bit hash of the HI, 129 presented as IPv6 addresses. 131 The HIP protocol is used to securely set up and maintain connection 132 states between two identifiers. The initial set up is performed 133 using a four-way handshake called the base-exchange, which includes a 134 Sigma-compliant Diffie-Hellman key exchange. The initiating party is 135 referred to as the Initiator and the target as the Responder. The 136 four packets sent during the base-exchange are named I1 and R1 - the 137 initial packet and its response, I2 and R2 - the subsequental 138 Initiator-originated packet and its response. After the state is set 139 up, data traffic is exchanged using Encapsulating Security Payload 140 (ESP) or another suitable security protocol. 142 Due to the identifier / locator split, HIP provides transparent 143 mobility and multi-homing support for applications. The application- 144 level connections (for example TCP) will pass uninterrupted through 145 changes in the host's network location (IP address changes), as it 146 only affects the encapsulating data connections, not the encapsulated 147 application-level connections. 149 3.1. HIP's NAT Traversal Mechanism 151 HIP cannot typically operate as-is across legacy NAT devices. 152 Extensions have therefore been proposed to allow HIP communication 153 across NAT middleboxes. Current HIP NAT traversal proposals are 154 based on utilizing the ICE methodology [5], transport-layer 155 encapsulation of signalling, and the use of HIP rendezvous servers 156 [7] and relays. 158 Rendezvous Servers (RVSs) act as public contact points for hosts that 159 are not able to reliably receive HIP traffic due to frequent 160 mobility. Hosts use the HIP registration extensions to register 161 their HITs with RVSs. This causes the RVSs to forward I1 packets to 162 the host that are addressed to those HITs. Methods for finding RVS 163 servers to which a HIT has been registered include using the Domain 164 Name System (DNS) and Distributed Hash Tables (DHTs) [8] [9]. 166 An RVS server assists in rudimentary NAT traversal as it adds the 167 locator of the Initiator to the forwarded I1 packet. The Responder 168 uses this locator to complete the base exchange without any further 169 involvement of the RVS server. Combined with transport-layer 170 encapsulation, this may successfully establish a peer-to-peer path 171 depending on the type of NAT middleboxes involved. 173 This RVS-based base exchange is illustrated in Figure 1 [7]. 175 I1(RVS, R, HIT-I, HIT-R 176 I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC) 177 +----------------------->| |--------------------+ 178 | | RVS | | 179 | | | | 180 | +---------+ | 181 | V 182 +-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+ 183 | |<---------------------------------------------| | 184 | | | | 185 | I | I2(I, R, HIT-I, HIT-R) | R | 186 | |--------------------------------------------->| | 187 | |<---------------------------------------------| | 188 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 190 Figure 1: RVS-based Base Exchange 192 As the RVS-based base exchange does not work in all network 193 configurations (especially those with symmetric NATs), the current 194 HIP NAT traversal proposals suggest the use of ICE methodology and 195 traffic relays to overcome middleboxes. 197 Greatly simplified, these ICE-based proposials are based on the peers 198 exchanging locators during the base-exchange through which they may 199 be reachable. These may include addresses of local interfaces, 200 intermediate middleboxes and different relays. These locators are 201 paired up on both sides, and connectivity checks are made to discover 202 most optimal working pair. How the addresses are discovered 203 (possibly reserved) and which are provided (e.g. filtering for 204 security reasons) are matters to be discussed in the relevant 205 proposals. 207 This requires the introduction of a network entity to assist in 208 (relay) the base-exchange to ensure its success, as the whole 209 methodology depends on it. One proposal specifies the use of a HIP- 210 specific server, the HIP relay, which is similar to an RVS although 211 it forwards the whole base-exchange, not only I1 packets. It is also 212 conceivable that the relaying is not performed by isolated components 213 at all, but by a distributed network or overlay of some sort. 215 After the base exchange, a path between the hosts is sought by 216 pairing up and prioritizing the candidate locators and performing 217 connectivity checks. The process is depicted in Figure 2. In this 218 scenario, both hosts are behind NATs and have completed the base 219 exchange (the last R2 packet is illustrated). A similar process is 220 also performed when a peer changes its network location (peer 221 mobility). The locators are then exchanged using HIP UPDATE packets 222 instead of the base-exchange. 224 I Relay R 225 | 2. R2(RELAY_TO) | 1. R2(RELAY_TO) | 226 +<------------------------------+-------------------------------+ 227 | | 228 | 3. UPDATE(ECHO_REQUEST,FROM_PEER) NAT-R:DROP| 229 +------------------------------------------------------------->X| 230 | | 231 | 4. UPDATE(ECHO_REQUEST,FROM_PEER) | 232 |<--------------------------------------------------------------+ 233 | | 234 | 5. UPDATE(ECHO_RESP,TO_PEER) | 235 +-------------------------------------------------------------->+ 236 | | 237 | 6. UPDATE(ECHO_REQUEST,FROM_PEER) | 238 +-------------------------------------------------------------->| 239 | | 240 | 7. UPDATE(ECHO_RESP,TO_PEER) | 241 |<--------------------------------------------------------------+ 242 | | 244 Figure 2: HIP Connectivity Checks 246 4. Managing Long-lived Connections in P2PSIP 248 HIP is used to setup and maintain connections between peers in the 249 overlay. Each peer MUST setup and maintain connections to the 250 neighboring peers with HIP. There MUST be an alive connection to 251 each peer listed in the DHT Data Structure. The DHT data structure 252 means, it this context, the data that describes the partial structure 253 of the DHT network on each peer. If Chord [11] is used as a DHT, for 254 example, then the Chord's Finger Table is the largest part of the DHT 255 data structure. 257 The peer MAY also setup and maintain other connections with HIP. The 258 peer may, for example, setup a connection to all the nodes listed in 259 the buddylist. 261 +---------------+ 262 | HIP | 263 +---------------+ +---------------+ +---------------+ 264 | Peer Protocol | | Peer Protocol | | SIP & Data | 265 +---------------+ +---------------+ +---------------+ +---------------+ 266 | Transport pr. | | Transport pr. | | Transport pr. | | HIP | 267 +---------------+ +---------------+ +---------------+ +---------------+ 268 | e.g. ESP | | e.g. ESP | | e.g. ESP | | e.g. ESP | 269 +---------------+ +---------------+ +---------------+ +---------------+ 270 | UDP | | UDP | | UDP | | UDP | 271 +---------------+ +---------------+ +---------------+ +---------------+ 272 | IP | | IP | | IP | | IP | 273 +---------------+ +---------------+ +---------------+ +---------------+ 275 a) Initial HIP b) Peer c) SIP signaling d) Subsequent 276 Base Exchange Protocol and data HIP packets 278 Figure 3: Protocol Layering 280 The network protocol layering, in four distinct cases, is illustrated 281 in Figure 3. The main idea is that the Peer Protocol and data are 282 always transported inside HIP initiated connections, which can be, 283 for example IPsec connections with Encapsulating Security Payload 284 (ESP) [12] header. The Peer Protocol could be, for example, Resource 285 Location and Discovery (RELOAD) [13], Address Settlement by Peer-to- 286 Peer (ASP) [14] or Peer-to-Peer Protocol (P2PP) [15]. 288 The distinct layering cases are the following: 290 a. Initial HIP Base Exchange: When a peer establishes a connection 291 to some other peer, it encapsulates HIP's I1 packet to the Peer 292 Protocol and send it to the destination peer. The initial base 293 exchange (I1, R1, I2, and R2) is transported via the P2PSIP 294 overlay. 295 b. Peer Protocol: All the Peer Protocol packets are always 296 transported over the HIP initiated connections. 297 c. SIP signaling and Data: All SIP and data packets are always 298 transported over the HIP initiated connections. The data, in 299 this context, means for example a Real-time Transport Protocol 300 (RTP) stream or Message Session Relay Protocol (MSRP) session. 301 d. Subsequent HIP packets: When the initial HIP Base Exchange is 302 done, all the subsequent HIP packets, such as UPDATE packets in 303 mobility scenarios, are always transported over the HIP initiated 304 connections. 306 The operation of P2PSIP peer can be broken into three phases: 307 joining, normal operation, and leaving phase. The following 308 subsections describe how HIP can be utilized by a P2PSIP peers in 309 each phase. 311 4.1. Joining Phase 313 The details of the joining phase is highly dependent on the overlay's 314 logic (i.e., what DHT algorith is used). Generally speaking, it can 315 roughly be divided into three steps: finding a contact point, 316 establishing the initial connection, and possible protocol specific 317 re-negotiations. Of these three, only the second step involves HIP. 319 The first step is simply to acquire an address to a peer which 320 provides the initial contact with the overlay (the bootstrap peer). 321 The exact detail on how this is done are explained by the used Peer 322 Protocol, and therefore this is not specific to HIP. 324 The second step is to establish a connection to the bootstrap peer. 325 The connection MUST be established by using the HIP protocol. It can 326 be established either directly or with the help of an relay. At this 327 point, the client will have a HIP initiated connection to a member of 328 the overlay which, although transparent for the application, might 329 have traversed intermediate NAT middleboxes and can utilize all other 330 benefits that HIP provides. 332 The third step includes e.g., authentication, connection re- 333 negotiation or other procedures the overlay implementation might 334 require in order to accept a new node. As in step one, the exact 335 details of this step are defined by the used Peer Protocol and 336 therefore they are not specific to HIP. Overlay implementations 337 typically require the joining node to establish additional 338 connections (such as the finger nodes in Chord). HIP is not involved 339 in the logic of this, but will be called upon if additional 340 connections are required. That is, the connections between the peers 341 in the P2PSIP network MUST always be formed by using HIP. 343 4.2. Normal Operation Phase 345 The idea is that peer protocol messages are always transported inside 346 the HIP initiated connections. The following example, illustrated in 347 Figure 4, presents a typical scenario where a media session is 348 established between two users, Alice and Bob. The HIP initiated 349 connections are illusrated with dotted lines in the Figure (e.g., PP1 350 message is transported inside a HIP initiated connection). 352 Alice Bob 353 Peer A Peer B Peer C Peer D 354 | | | | 355 | ............... | ............... | | 356 |------ PP1 ----->|------ PP2 ----->|[Bob's RR ] | 357 | ............... | ............... |[Bob's HIT] | 358 | | | | 359 | ............... | ............... | | 360 |<----- PP4 ------|<----- PP3 ------| | 361 | ............... | ............... | | 362 | | | | 363 | ............... | ............... | ............... | 364 |---- PP5+I1 ---->|---- PP6+I1 ---->|---- PP7+I1 ---->| 365 | ............... | ............... | ............... | 366 | | | | 367 | ............... | ............... | ............... | 368 |<--- PP10+R1 ----|<--- PP9+R1 -----|<--- PP8+R1 -----| 369 | ............... | ............... | ............... | 370 | | | | 371 | ............... | ............... | ............... | 372 |---- PP11+I2 --->|---- PP12+I2 --->|---- PP13+I2 --->| 373 | ............... | ............... | ............... | 374 | | | | 375 | ............... | ............... | ............... | 376 |<--- PP16+R2 ----|<---- PP15+R2 ---|<--- PP14+R2 ----| 377 | ............... | ............... | ............... | 378 | | | | 379 | | 380 :<<------------ ICE connectivity checks ------------>>: 381 | | 382 | ................................................... | 383 |---------------------- INVITE ---------------------->| 384 |<--------------------- 200 OK -----------------------| 385 | | 386 |<====================== Media ======================>| 387 | ................................................... | 388 | | 390 Figure 4: Message Sequence - Establishing a Multimedia Session 392 When Alice calls to Bob, first she needs to acquire Bob's Resource 393 Record (RR). The resource record MUST contain Bob's HIT and it does 394 not have to contains Bob's IP address(es). Alice fetches the 395 resource record by using a peer protocol, messages PP1-PP4 in the 396 Figure 4. All the peer protocol messages are trasported inside the 397 HIP initiated connections. That is, peer B is one of the "fingers" 398 in peer A, and peer C is one of the "fingers" in peer B. 400 When Alice has Bob's resource record, her user agent can launch a HIP 401 base exchange [10] towards Bob's peer (peer D). For the initial HIP 402 base exchange, the HIP signaling MUST be encapsulated into a peer 403 protocol (note: e.g., RELOAD's [13] TRANSPORT-TUNNEL message can be 404 used for this purpose). Thus, the initial HIP base exchange is done 405 via the P2PSIP overlay in messages PP5-PP16. It is noteworthy that 406 the ICE candidates (i.e., locators) are gathered and exchanged during 407 the HIP base exchange, as explained in [4]. 409 After the initial base exchange has been done via the overlay, then 410 the ICE connectivity checks can be executed. The ICE connectivity 411 checks are done by using the mechanism described in [4]. When the 412 connectivity checks are done, then both parties (peer A and peer D) 413 know which is the best candidate pair and the HIP initiated 414 connection is established between them. 416 The SIP signaling and media MUST use the HIP initiated connection 417 between peer A and peer D for all following traffic between the 418 peers. The HIP initiated connection between peers might traverse via 419 relays if there are NAT devices between the peers, but that is 420 transparent from the applications viewpoint. For clarity, these 421 possible NAT devices and relays are not depicted in Figure 4. 423 When the HIP initiated connections are traversing NATs, they are 424 continuously maintained by sending keepalive messages between the 425 peers. If the application layer has not sent data traffic over a HIP 426 initiated connection in a given period in the past (e.g., in 20 427 seconds) then specific keepalive message MUST be sent. The exact 428 details of keepalive messages are described in [4]. 430 4.3. Leaving Phase 432 When closing the application, all connections MUST be terminated in 433 order to avoid wasting resources. HIP stack should terminate the HIP 434 states using appropriate signalling. This prevents vain NAT 435 keepalives and other maintenance traffic from being transmitted. 437 As the data traffic has been encapsulated in HIP initiated 438 connections, closing the HIP states prevents also unwanted traffic 439 from being received. For example, normally a datagram-based media 440 stream may continue to be sent (and delivered to the host) even after 441 the receiving application is closed. This is harmful in mobile 442 environments where it drains the battery and may be expensive without 443 flat-rate pricing. 445 5. Using Relays 447 The methods described in this section crosses somewhat the border 448 between the HIP layer and P2PSIP overlay layer. Our approach tries 449 to keep these separate and comment only on how HIP could be utilized, 450 steering clear of the overlay structure, logic or content. Our model 451 is however reliant on the presence of relays, which can be seen as 452 the weak link of the approach. This compels us to address the issue 453 to some extent, which is done in following method for decreasing the 454 reliance on infrastructure, which involves the overlay to a small 455 degree. 457 As peers of the overlay might not be publicly accessible, HIP 458 connections may have to be initiated through a relay to traverse NAT 459 and other middleboxes. However, peers may not have suitable 460 infrastructure support, i.e., relays, at their disposal. 462 This can be solved by having peers of the overlay act as relays. 463 Peers who seem to be in a suitable position could register themselves 464 in the DHT overlay as such. The peer MAY register itself as a relay 465 if it fulfills the following criterions: 467 o Peer has a public IP address 468 o Peer has a non-blocking firewall (as far as the peer itself is 469 aware) 470 o Peer has sufficient online history (e.g., has been online 75% of 471 time during the last week) 473 As all of these supposedly suitable peers might not turn out to be so 474 (due to incorrect probing, maliciousness or other reasons), peers 475 SHOULD register to a number of these to increase the odds that at 476 least one works correctly. The actual method how peers can register 477 to a relay are out of scope for this document. 479 The procedures for searching relays are described in Section 5.1 and 480 Section 5.2. Those procedures MUST be used if the used peer protocol 481 does not provide such procedures. However, if the peer protocol 482 provides procedures for searching relays, then those MUST be used 483 instead. 485 5.1. Baseline Relay Search 487 The peers of the overlay should be able to use fixed, centralized 488 relays. Typically a peer knows an IP or a FQDN (Fully Qualified 489 Domain Name) of a fixed relay and can contact it directly without 490 consulting the overlay network. 492 Another possiblity is to use some of the neighboring peers in the 493 overlay network as relays. As a default, a peer has HIP initiated 494 connections to all the neighboring peers, so those connections can be 495 re-used (i.e., no additional HIP initiated connections are needed). 496 The actual mechanism for finding out whether a neighbor can act as a 497 relay or not is out of scope for this document (that kind of 498 mechanism can be e.g., a part of a peer protocol). It is noteworthy 499 that if neighboring peers are used as relays, it also provides a very 500 simple load balancing functionality. That is, the relays and their 501 usage is quite evenly distributed to the overlay identifier space 502 (assuming that peer identifiers are evenly scattered). 504 5.2. Distributed Relay Search 506 Depending on the overlay algorithm used, it might be needed to 507 distribute the load on certain nodes caused by the quite frequent 508 registrations of relays and subsequent lookups. One way is to 509 utilize the HIT as salt when generating the entry key. For example, 510 consider a relay with the HIT 0xa1b2c3d4e5 that is about to register 511 itself in the DHT. For finding a service in general, there needs to 512 be a pre-defined prefix used to construct the keys - here we use 513 "relay:". 515 Initially, the relay tries to register to the "root" entry of the 516 service which is under the key constructed from the prefix alone - 517 'HASH("relay:")'. If the amount of registered entries is under a 518 certain limit (e.g., 100), the relay will try the next branch. The 519 key for it is made by appending the first character of the host's HIT 520 as expressed in hex to the common prefix - HASH("relay:a"). The same 521 check is performed - if the number of registered entries exceed the 522 limit, the relay tries yet the next branch, HASH("relay:a1"), and 523 continues until a suitable slot is found. 525 When searching for a relay, peers do the opposite - start from the 526 outer-most branch and work their way to the root until enough entries 527 are found. This way the most common operation (lookup of relay) and 528 burden of storing the registrations is distributed, at least 529 partially, throughout the DHT. 531 The relay registration/search mechanism described above can also be 532 applied to other popular services. For example, a voicemail service 533 could use similar mechanism. 535 6. Mobility Scenario - Make-Before-Break 537 In the make-before-break mobility scenario a new connection is 538 established before the old connections is closed. This kind of 539 scenario can happen for example in a case where a laptop with stable 540 Wireless Local Area Network (WLAN) connectivity is plugged into 541 ethernet. 543 Peer A Peer B 544 : : 545 A wants to change : : 546 to a new connection : : 547 (new IP) | | 548 | | .......... Existing connection ......... | 549 +------------->| | 550 |------------ 1. HIP UPDATE -------------->| 551 |<----------- 2. HIP UPDATE ---------------| 552 | ........................................ | 553 | | 554 :<<------ ICE connectivity checks ------->>: 555 | | 556 | .......... Existing connection ......... | 557 |------------ 3. HIP UPDATE -------------->| 558 |<----------- 4. HIP UPDATE ---------------| 559 | ........................................ | 560 | | 561 | | 562 | ............. New connection ........... | 563 | | 564 | ........................................ | 565 | | 566 | | 568 Figure 5: Message Sequence - Make-Before-Break 570 Figure 5 is presenting a signaling flow in make-before-break 571 scenario. The trigger for changing to a new connection can be e.g., 572 an event where a peer acquires a new network interface which has 573 higher priority that the currently used network interface. The 574 establishment of a new HIP initiated connection is started by sending 575 a HIP update message (1) to the other party. That message contains 576 new ICE candidates, as described in [4]. 578 When the other party, Peer B in Figure 5, receives the HIP UPDATE (1) 579 it replies with its own ICE candidates to Peer A (2). After that the 580 ICE connectivity checks will be done. When the ICE connectivity 581 checks have finished, then the old HIP initiated connection can be 582 closed with appropriate HIP UPDATE messages (3-4). After that the 583 new HIP initiated connection, which is bound to the Peer A's new IP, 584 can be used for further signaling and traffic. 586 7. Mobility Scenario - Break-Before-Make 588 In the break-before-make mobility scenario an old connection has been 589 terminated before a new connection is established. This kind of 590 scenario can happen for example in a case where a laptop using WLAN 591 is going outside the coverage area and is then plugged into ethernet. 593 Peer A Peer C 594 : : 595 A notices that : : 596 the active and only : : 597 interface has gone | | 598 down | | 599 | | | 600 +------------->| | 601 : Peer B : 602 +------------->| (with public IP) | 603 | |---- 1. HIP UPDATE ---->| | 604 A notices that a |<--- 2. HIP UPDATE -----| | 605 new connection has | | | 606 come up :<<-- ICE con. checks ->>: | 607 | | | 608 | ... new connection ... | ............... | 609 |------ PP1+UPDATE ----->|-- PP2+UPDATE -->| 610 |<----- PP4+UPDATE ------|<- PP3+UPDATE ---| 611 | ...................... | ............... | 612 | | | 613 | | 614 :<<------ ICE connectivity checks ------->>: 615 | | 616 | .............. new connection .......... | 617 | | 618 | ........................................ | 619 | | 621 Figure 6: Message Sequence - Break-Before-Make (non-multi-homed peer) 623 Figure 6 is presenting a signaling flow in a case where a non-multi- 624 homed peer (i.e., peer has only one active network interface) is 625 subjected to a break-before-make mobility scenario. The mobility 626 signaling in break-before-make scenario is triggered by the event 627 where the peer notices that the interface it was using has gone down. 628 When the node regains connectivity, which is bound to a different IP 629 address than the previous intercase, it needs to re-establish 630 connections to all its neighboring peers. 632 The re-establishment of HIP initiated connections is started by 633 sending HIP UPDATE packets to those neighboring peers that were not 634 behind a NAT. In Figure 6 this is the Peer B. The update packet (1), 635 and its reply (2) can be sent e.g., directy on top of IP protocol. 636 Then the ICE connectivity checks are executed and a new connection is 637 established to Peer B. When peer A has established at least one 638 connection to some neighboring peer, it can use that connection to 639 reach all the other nodes even if they are behind a NAT. 641 In the Figure the connection to peer C is established with the peer 642 protocol messages PP1-PP4, which carry the HIP update packets. When 643 the encapsulated HIP UPDATE packets have been exchanged, peers will 644 execute connectivity checks. The connectivity check results in re- 645 established, HIP initiated connection between peers A and C. 647 If the peer subjected to a break-before-make scenario would have been 648 multi-homed (see Section 8), and if it would have had HIP initiated 649 connections from more that one interface, then the scenario would 650 have been more easy to handle. The peer could have just used its 651 existing HIP initiated connections from the interfaces that did not 652 go down, and send HIP UPDATE messages on top of peer protocol via 653 those connections. 655 8. Multi-homing Scenario 657 In multi-homing scenario a peer has more than one network interface 658 that it can use. This kind of scenarion can be e.g., a laptop which 659 has both WLAN and ethernet network interfaces up. 661 Multi-homed peers should follow the procedures explained in [5]. 662 That is, a multi-homed peer can gather ICE candidates and establish 663 HIP initiated connections from each of its interfaces. For example, 664 a laptop with WLAN and ethernet interfaces could have HIP initiated 665 connections bound to both interfaces. It is noteworthy that ICE 666 allows preset local preferences for the candidate addresses, so it is 667 posible to favor one interface over another. 669 If a P2PSIP peer is multi-homed and it is using more that one 670 interface for HIP initiated connections, its operation is more robust 671 in failure cases where one interface suddenly goes down. That kind 672 of failure cases typically lead to break-before-make mobility 673 scenarios, see Section 7. 675 9. Other Benefits that HIP Provides for P2PSIP 677 HIP is based on asymmetric cryptography and it requires the 678 generation of an asymmetric key pair (e.g., by using Rivest Shamir 679 Adelman (RSA) algorithm). The hosts are identified by using a HIT, 680 which is a hash (calculated e.g., by using SHA-1 algorithm) from the 681 generated public key. The host identifiers could be used also as 682 peer identifiers in a P2PSIP network. It is worth highlighting that 683 the HITs are used to identify hosts and not users or services. 685 If HITs are used as peer identifiers in a P2PSIP network, it has 686 positive security implications. Section 11.2. in [13] states that a 687 large number from threats agains P2P networks can be avoided, or at 688 least alleviated, if the malicious nodes cannot be injected into a 689 freely chosen location in an overlay address space. 691 The free choice of peer identifiers can be prevented at least in two 692 ways; either by using some central authority that distributes 693 asserted peer identifiers or by using HITs as peer identifiers. The 694 usage of central authority is not explored in this document. If HITs 695 are used as peer identifiers, an attacker cannot freely choose the 696 peer identifier, because the generation of asymmetric key pair is 697 computationally demanding operation and it would need to be executed 698 a considerable number of times in a large P2P network. 700 10. Security Considerations 702 The security considerations of this document to the P2PSIP network as 703 a whole are going to be studied in the coming versions. 705 11. IANA Considerations 707 No IANA considerations. 709 12. References 711 12.1. Normative References 713 [1] Willis, D., "Concepts and Terminology for Peer to Peer SIP", 714 draft-willis-p2psip-concepts-04 (work in progress), March 2007. 716 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 717 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 718 Session Initiation Protocol", RFC 3261, June 2002. 720 [3] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) 721 Architecture", RFC 4423, May 2006. 723 [4] Schmitt, V., "HIP Extensions for the Traversal of Network 724 Address Translators", draft-ietf-hip-nat-traversal-02 (work in 725 progress), July 2007. 727 [5] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 728 Protocol for Network Address Translator (NAT) Traversal for 729 Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in 730 progress), October 2007. 732 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 733 Levels", BCP 14, RFC 2119, March 1997. 735 [7] Eggert, L. and J. Laganier, "Host Identity Protocol (HIP) 736 Rendezvous Extensions", draft-eggert-hip-rvs-00 (work in 737 progress), July 2004. 739 [8] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) 740 Domain Name System (DNS) Extensions", draft-nikander-hip-dns-00 741 (work in progress), July 2004. 743 [9] Ahrenholz, J., "HIP DHT Interface", 744 draft-ahrenholz-hiprg-dht-01 (work in progress), February 2007. 746 [10] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 747 "Host Identity Protocol", draft-ietf-hip-base-10 (work in 748 progress), October 2007. 750 12.2. Informative References 752 [11] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Frans 753 Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A 754 Scalable Peer-to-peer Lookup Service for Internet 755 Applications", IEEE Transactions on Networking, 2003. 757 [12] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 758 December 2005. 760 [13] Bryan, D., "REsource LOcation And Discovery (RELOAD)", 761 draft-bryan-p2psip-reload-01 (work in progress), July 2007. 763 [14] Jennings, C. and J. Rosenberg, "Address Settlement by Peer to 764 Peer", draft-jennings-p2psip-asp-00 (work in progress), 765 July 2007. 767 [15] Baset, S. and H. Schulzrinne, "Peer-to-Peer Protocol (P2PP)", 768 draft-baset-p2psip-p2pp-00 (work in progress), July 2007. 770 Appendix A. Peer's Software Architecture 772 This appendix in meant only as a guideline for the implementors. The 773 Figure 7 present the architecture of a P2PSIP Peer which is using HIP 774 for establishing and maintaining long-lived connections to other 775 peers. 777 +---------------------------------------------------------------------+ 778 | P2PSIP Peer | 779 |+-----------------+ +-----------------+ +-----------------+| 780 || P2PSIP | | | API2 | || 781 || Communication | API1 | P2P |----->| HIP || 782 || Application |----->| Module | | Daemon || 783 || | | | API3 | || 784 || [UDP/TCP] | | [UDP/TCP] |<-----| [UDP] || 785 |+-----------------+ +-----------------+ +-----------------+| 786 | ^ ^ ^ ^ | 787 | | | | | | 788 |+----------------------------------------------------------+ | | 789 || HIP Data Plane (e.g. IPsec) | | | 790 |+----------------------------------------------------------+ | | 791 | | | | | | 792 |+-------------------------------------------------------------------+| 793 || IPv4/IPv6 || 794 |+-------------------------------------------------------------------+| 795 | | | | | | 796 +---------------------------------------------------------------------+ 797 :|: :|: :|: | 798 :|: :|: :|: | 799 v v v v 800 SIP Peer Protocol HIP HIP 802 Figure 7: Architecture of a P2PSIP Peer 804 The "blocks" in Figure 7 are the following: 806 o P2PSIP Communication Application: It contains the user interface, 807 buddylist, etc. 808 o P2P Module: It contains DHT specific functions, such as overlay 809 maintenance and overlay routing. This can be though as a daemon. 810 o HIP Daemon: It contains HIP signaling specific stuff. It also 811 contains functions needed for NAT traversal, such as ICE candidate 812 gathering and exchange, connectivity checks and keepalives. As 813 the name implies, it can be though as a daemon. 814 o HIP Data Plane: Contains the encapsulation of further signaling 815 and media into a HIP initiated connection. Can be for example an 816 IPsec implementation. 818 o IPv4/IPv6: Ordinary IP stack. 820 The Application Programming Interfaces (APIs) in Figure 7 are the 821 following: 823 o API1: Returns a peer identifier/HIT to a P2PSIP communication 824 application when a hash from an SIP URI has been given as an input 825 to the P2P Module. 826 o API2: P2P module is able to pass information regarding the relays 827 to the HIP daemon. 828 o API3: By using this API the HIP daemon is able to send and receive 829 packets that are transported on top of a peer protocol. 831 SIP, Peer Protocol, and HIP can traverse HIP Initiated connections, 832 which is illustrated with dotted "tubes" in the bottom of Figure 7. 834 Authors' Addresses 836 Jani Hautakorpi 837 Ericsson 838 Hirsalantie 11 839 Jorvas 02420 840 Finland 842 Email: jani.hautakorpi@ericsson.com 844 Gonzalo Camarillo 845 Ericsson 846 Hirsalantie 11 847 Jorvas 02420 848 Finland 850 Email: gonzalo.camarillo@ericsson.com 852 Joakim Koskela 853 Helsinki Institute for Information Technology 854 Metsaenneidonkuja 4 855 Espoo 02130 856 Finland 858 Email: joakim.koskela@hiit.fi 860 Full Copyright Statement 862 Copyright (C) The IETF Trust (2007). 864 This document is subject to the rights, licenses and restrictions 865 contained in BCP 78, and except as set forth therein, the authors 866 retain all their rights. 868 This document and the information contained herein are provided on an 869 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 870 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 871 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 872 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 873 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 874 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 876 Intellectual Property 878 The IETF takes no position regarding the validity or scope of any 879 Intellectual Property Rights or other rights that might be claimed to 880 pertain to the implementation or use of the technology described in 881 this document or the extent to which any license under such rights 882 might or might not be available; nor does it represent that it has 883 made any independent effort to identify any such rights. Information 884 on the procedures with respect to rights in RFC documents can be 885 found in BCP 78 and BCP 79. 887 Copies of IPR disclosures made to the IETF Secretariat and any 888 assurances of licenses to be made available, or the result of an 889 attempt made to obtain a general license or permission for the use of 890 such proprietary rights by implementers or users of this 891 specification can be obtained from the IETF on-line IPR repository at 892 http://www.ietf.org/ipr. 894 The IETF invites any interested party to bring to its attention any 895 copyrights, patents or patent applications, or other proprietary 896 rights that may cover technology that may be required to implement 897 this standard. Please address the information to the IETF at 898 ietf-ipr@ietf.org. 900 Acknowledgment 902 Funding for the RFC Editor function is provided by the IETF 903 Administrative Support Activity (IASA).