P2PSIP Working Group J. Hautakorpi Internet-Draft G. Camarillo Intended status: Standards Track Ericsson Expires: May 22, 2008 J. Koskela HIIT November 19, 2007 Utilizing HIP (Host Identity Protocol) for P2PSIP (Peer-to-peer Session Initiation Protocol) draft-hautakorpi-p2psip-with-hip-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies how Host Identity Protocol (HIP) can be utilized in Peer-to-Peer Session Initiation Protocol (P2PSIP) networks. Peers in a P2PSIP network need to have long-lived connections to other peers in the network, and HIP can be utilized to setup and maintain those connections. HIP is a good choice for Hautakorpi, et al. Expires May 22, 2008 [Page 1] Internet-Draft Utilizing HIP for P2PSIP November 2007 connection maintenance, because it provides functionalities like Network Address Translation (NAT) traversal, mobility, multi-homing, and enhanced security properties. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Short Overview of HIP . . . . . . . . . . . . . . . . . . . . 3 3.1. HIP's NAT Traversal Mechanism . . . . . . . . . . . . . . 4 4. Managing Long-lived Connections in P2PSIP . . . . . . . . . . 6 4.1. Joining Phase . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Normal Operation Phase . . . . . . . . . . . . . . . . . . 8 4.3. Leaving Phase . . . . . . . . . . . . . . . . . . . . . . 10 5. Using Relays . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Baseline Relay Search . . . . . . . . . . . . . . . . . . 11 5.2. Distributed Relay Search . . . . . . . . . . . . . . . . . 12 6. Mobility Scenario - Make-Before-Break . . . . . . . . . . . . 12 7. Mobility Scenario - Break-Before-Make . . . . . . . . . . . . 14 8. Multi-homing Scenario . . . . . . . . . . . . . . . . . . . . 15 9. Other Benefits that HIP Provides for P2PSIP . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Peer's Software Architecture . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Hautakorpi, et al. Expires May 22, 2008 [Page 2] Internet-Draft Utilizing HIP for P2PSIP November 2007 1. Introduction P2PSIP [1] is a mechanism which incorporates Peer-to-Peer (P2P) technologies and the Session Initiation Protocol (SIP) [2] signaling in a way which allows the transfer of proxy-registrar functionality to the end-hosts. In P2PSIP network, storage and routing services are provided by Peers which participate to the overlay. Peers need to have long-lived connections to other peers. This document describes how Host Identity protocol (HIP) [3], and HIP's NAT traversal mechanisms [4], can be used for establishing and maintaining those connections. This draft utilizes HIP as it is, and does not propose any changes or modifications to it. The complexity of the actual P2PSIP application implementations decrease as they can utilize the Interactive Connectivity Establishment (ICE) [5] NAT traversal methodology built into HIP [4]. Using HIP provides many other transparent benefits for applications as well, such as mobility, multi-homing, and enhanced security properties. The remainder of this document is organized as follows. Section 3 gives a short overview to HIP and HIP's NAT traversal mechanism. Section 4 present how HIP can be utilized for P2PSIP. Section 5 speficifies how relays can be used. Section 6 and Section 7 illustrates mobility scenarios and how they can be handled with HIP. Section 8 presents multi-homing scenarios. Section 9 lists other benefits that HIP provides for P2PSIP networks. Finally Section 10 and Section 11 present security and IANA considerations respectively. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]. Most of the terminology and concepts presented in this document are aligned with [1], and [4]. Other terms are defined when used. 3. Short Overview of HIP HIP [3] is a new communication architecture which introduces a protocol between the network and transport layers which binds connection end-points to cryptographicly generated host identifiers instead of network addresses. Hautakorpi, et al. Expires May 22, 2008 [Page 3] Internet-Draft Utilizing HIP for P2PSIP November 2007 A host identifier (HI) is the public part of a public/private key pair owned by the host. More commonly used for representing the identity are Host Identity Tags (HITs), a 128-bit hash of the HI, presented as IPv6 addresses. The HIP protocol is used to securely set up and maintain connection states between two identifiers. The initial set up is performed using a four-way handshake called the base-exchange, which includes a Sigma-compliant Diffie-Hellman key exchange. The initiating party is referred to as the Initiator and the target as the Responder. The four packets sent during the base-exchange are named I1 and R1 - the initial packet and its response, I2 and R2 - the subsequental Initiator-originated packet and its response. After the state is set up, data traffic is exchanged using Encapsulating Security Payload (ESP) or another suitable security protocol. Due to the identifier / locator split, HIP provides transparent mobility and multi-homing support for applications. The application- level connections (for example TCP) will pass uninterrupted through changes in the host's network location (IP address changes), as it only affects the encapsulating data connections, not the encapsulated application-level connections. 3.1. HIP's NAT Traversal Mechanism HIP cannot typically operate as-is across legacy NAT devices. Extensions have therefore been proposed to allow HIP communication across NAT middleboxes. Current HIP NAT traversal proposals are based on utilizing the ICE methodology [5], transport-layer encapsulation of signalling, and the use of HIP rendezvous servers [7] and relays. Rendezvous Servers (RVSs) act as public contact points for hosts that are not able to reliably receive HIP traffic due to frequent mobility. Hosts use the HIP registration extensions to register their HITs with RVSs. This causes the RVSs to forward I1 packets to the host that are addressed to those HITs. Methods for finding RVS servers to which a HIT has been registered include using the Domain Name System (DNS) and Distributed Hash Tables (DHTs) [8] [9]. An RVS server assists in rudimentary NAT traversal as it adds the locator of the Initiator to the forwarded I1 packet. The Responder uses this locator to complete the base exchange without any further involvement of the RVS server. Combined with transport-layer encapsulation, this may successfully establish a peer-to-peer path depending on the type of NAT middleboxes involved. This RVS-based base exchange is illustrated in Figure 1 [7]. Hautakorpi, et al. Expires May 22, 2008 [Page 4] Internet-Draft Utilizing HIP for P2PSIP November 2007 I1(RVS, R, HIT-I, HIT-R I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC) +----------------------->| |--------------------+ | | RVS | | | | | | | +---------+ | | V +-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+ | |<---------------------------------------------| | | | | | | I | I2(I, R, HIT-I, HIT-R) | R | | |--------------------------------------------->| | | |<---------------------------------------------| | +-----+ R2(R, I, HIT-R, HIT-I) +-----+ Figure 1: RVS-based Base Exchange As the RVS-based base exchange does not work in all network configurations (especially those with symmetric NATs), the current HIP NAT traversal proposals suggest the use of ICE methodology and traffic relays to overcome middleboxes. Greatly simplified, these ICE-based proposials are based on the peers exchanging locators during the base-exchange through which they may be reachable. These may include addresses of local interfaces, intermediate middleboxes and different relays. These locators are paired up on both sides, and connectivity checks are made to discover most optimal working pair. How the addresses are discovered (possibly reserved) and which are provided (e.g. filtering for security reasons) are matters to be discussed in the relevant proposals. This requires the introduction of a network entity to assist in (relay) the base-exchange to ensure its success, as the whole methodology depends on it. One proposal specifies the use of a HIP- specific server, the HIP relay, which is similar to an RVS although it forwards the whole base-exchange, not only I1 packets. It is also conceivable that the relaying is not performed by isolated components at all, but by a distributed network or overlay of some sort. After the base exchange, a path between the hosts is sought by pairing up and prioritizing the candidate locators and performing connectivity checks. The process is depicted in Figure 2. In this scenario, both hosts are behind NATs and have completed the base exchange (the last R2 packet is illustrated). A similar process is also performed when a peer changes its network location (peer mobility). The locators are then exchanged using HIP UPDATE packets instead of the base-exchange. Hautakorpi, et al. Expires May 22, 2008 [Page 5] Internet-Draft Utilizing HIP for P2PSIP November 2007 I Relay R | 2. R2(RELAY_TO) | 1. R2(RELAY_TO) | +<------------------------------+-------------------------------+ | | | 3. UPDATE(ECHO_REQUEST,FROM_PEER) NAT-R:DROP| +------------------------------------------------------------->X| | | | 4. UPDATE(ECHO_REQUEST,FROM_PEER) | |<--------------------------------------------------------------+ | | | 5. UPDATE(ECHO_RESP,TO_PEER) | +-------------------------------------------------------------->+ | | | 6. UPDATE(ECHO_REQUEST,FROM_PEER) | +-------------------------------------------------------------->| | | | 7. UPDATE(ECHO_RESP,TO_PEER) | |<--------------------------------------------------------------+ | | Figure 2: HIP Connectivity Checks 4. Managing Long-lived Connections in P2PSIP HIP is used to setup and maintain connections between peers in the overlay. Each peer MUST setup and maintain connections to the neighboring peers with HIP. There MUST be an alive connection to each peer listed in the DHT Data Structure. The DHT data structure means, it this context, the data that describes the partial structure of the DHT network on each peer. If Chord [11] is used as a DHT, for example, then the Chord's Finger Table is the largest part of the DHT data structure. The peer MAY also setup and maintain other connections with HIP. The peer may, for example, setup a connection to all the nodes listed in the buddylist. Hautakorpi, et al. Expires May 22, 2008 [Page 6] Internet-Draft Utilizing HIP for P2PSIP November 2007 +---------------+ | HIP | +---------------+ +---------------+ +---------------+ | Peer Protocol | | Peer Protocol | | SIP & Data | +---------------+ +---------------+ +---------------+ +---------------+ | Transport pr. | | Transport pr. | | Transport pr. | | HIP | +---------------+ +---------------+ +---------------+ +---------------+ | e.g. ESP | | e.g. ESP | | e.g. ESP | | e.g. ESP | +---------------+ +---------------+ +---------------+ +---------------+ | UDP | | UDP | | UDP | | UDP | +---------------+ +---------------+ +---------------+ +---------------+ | IP | | IP | | IP | | IP | +---------------+ +---------------+ +---------------+ +---------------+ a) Initial HIP b) Peer c) SIP signaling d) Subsequent Base Exchange Protocol and data HIP packets Figure 3: Protocol Layering The network protocol layering, in four distinct cases, is illustrated in Figure 3. The main idea is that the Peer Protocol and data are always transported inside HIP initiated connections, which can be, for example IPsec connections with Encapsulating Security Payload (ESP) [12] header. The Peer Protocol could be, for example, Resource Location and Discovery (RELOAD) [13], Address Settlement by Peer-to- Peer (ASP) [14] or Peer-to-Peer Protocol (P2PP) [15]. The distinct layering cases are the following: a. Initial HIP Base Exchange: When a peer establishes a connection to some other peer, it encapsulates HIP's I1 packet to the Peer Protocol and send it to the destination peer. The initial base exchange (I1, R1, I2, and R2) is transported via the P2PSIP overlay. b. Peer Protocol: All the Peer Protocol packets are always transported over the HIP initiated connections. c. SIP signaling and Data: All SIP and data packets are always transported over the HIP initiated connections. The data, in this context, means for example a Real-time Transport Protocol (RTP) stream or Message Session Relay Protocol (MSRP) session. d. Subsequent HIP packets: When the initial HIP Base Exchange is done, all the subsequent HIP packets, such as UPDATE packets in mobility scenarios, are always transported over the HIP initiated connections. The operation of P2PSIP peer can be broken into three phases: joining, normal operation, and leaving phase. The following subsections describe how HIP can be utilized by a P2PSIP peers in Hautakorpi, et al. Expires May 22, 2008 [Page 7] Internet-Draft Utilizing HIP for P2PSIP November 2007 each phase. 4.1. Joining Phase The details of the joining phase is highly dependent on the overlay's logic (i.e., what DHT algorith is used). Generally speaking, it can roughly be divided into three steps: finding a contact point, establishing the initial connection, and possible protocol specific re-negotiations. Of these three, only the second step involves HIP. The first step is simply to acquire an address to a peer which provides the initial contact with the overlay (the bootstrap peer). The exact detail on how this is done are explained by the used Peer Protocol, and therefore this is not specific to HIP. The second step is to establish a connection to the bootstrap peer. The connection MUST be established by using the HIP protocol. It can be established either directly or with the help of an relay. At this point, the client will have a HIP initiated connection to a member of the overlay which, although transparent for the application, might have traversed intermediate NAT middleboxes and can utilize all other benefits that HIP provides. The third step includes e.g., authentication, connection re- negotiation or other procedures the overlay implementation might require in order to accept a new node. As in step one, the exact details of this step are defined by the used Peer Protocol and therefore they are not specific to HIP. Overlay implementations typically require the joining node to establish additional connections (such as the finger nodes in Chord). HIP is not involved in the logic of this, but will be called upon if additional connections are required. That is, the connections between the peers in the P2PSIP network MUST always be formed by using HIP. 4.2. Normal Operation Phase The idea is that peer protocol messages are always transported inside the HIP initiated connections. The following example, illustrated in Figure 4, presents a typical scenario where a media session is established between two users, Alice and Bob. The HIP initiated connections are illusrated with dotted lines in the Figure (e.g., PP1 message is transported inside a HIP initiated connection). Hautakorpi, et al. Expires May 22, 2008 [Page 8] Internet-Draft Utilizing HIP for P2PSIP November 2007 Alice Bob Peer A Peer B Peer C Peer D | | | | | ............... | ............... | | |------ PP1 ----->|------ PP2 ----->|[Bob's RR ] | | ............... | ............... |[Bob's HIT] | | | | | | ............... | ............... | | |<----- PP4 ------|<----- PP3 ------| | | ............... | ............... | | | | | | | ............... | ............... | ............... | |---- PP5+I1 ---->|---- PP6+I1 ---->|---- PP7+I1 ---->| | ............... | ............... | ............... | | | | | | ............... | ............... | ............... | |<--- PP10+R1 ----|<--- PP9+R1 -----|<--- PP8+R1 -----| | ............... | ............... | ............... | | | | | | ............... | ............... | ............... | |---- PP11+I2 --->|---- PP12+I2 --->|---- PP13+I2 --->| | ............... | ............... | ............... | | | | | | ............... | ............... | ............... | |<--- PP16+R2 ----|<---- PP15+R2 ---|<--- PP14+R2 ----| | ............... | ............... | ............... | | | | | | | :<<------------ ICE connectivity checks ------------>>: | | | ................................................... | |---------------------- INVITE ---------------------->| |<--------------------- 200 OK -----------------------| | | |<====================== Media ======================>| | ................................................... | | | Figure 4: Message Sequence - Establishing a Multimedia Session When Alice calls to Bob, first she needs to acquire Bob's Resource Record (RR). The resource record MUST contain Bob's HIT and it does not have to contains Bob's IP address(es). Alice fetches the resource record by using a peer protocol, messages PP1-PP4 in the Figure 4. All the peer protocol messages are trasported inside the HIP initiated connections. That is, peer B is one of the "fingers" in peer A, and peer C is one of the "fingers" in peer B. Hautakorpi, et al. Expires May 22, 2008 [Page 9] Internet-Draft Utilizing HIP for P2PSIP November 2007 When Alice has Bob's resource record, her user agent can launch a HIP base exchange [10] towards Bob's peer (peer D). For the initial HIP base exchange, the HIP signaling MUST be encapsulated into a peer protocol (note: e.g., RELOAD's [13] TRANSPORT-TUNNEL message can be used for this purpose). Thus, the initial HIP base exchange is done via the P2PSIP overlay in messages PP5-PP16. It is noteworthy that the ICE candidates (i.e., locators) are gathered and exchanged during the HIP base exchange, as explained in [4]. After the initial base exchange has been done via the overlay, then the ICE connectivity checks can be executed. The ICE connectivity checks are done by using the mechanism described in [4]. When the connectivity checks are done, then both parties (peer A and peer D) know which is the best candidate pair and the HIP initiated connection is established between them. The SIP signaling and media MUST use the HIP initiated connection between peer A and peer D for all following traffic between the peers. The HIP initiated connection between peers might traverse via relays if there are NAT devices between the peers, but that is transparent from the applications viewpoint. For clarity, these possible NAT devices and relays are not depicted in Figure 4. When the HIP initiated connections are traversing NATs, they are continuously maintained by sending keepalive messages between the peers. If the application layer has not sent data traffic over a HIP initiated connection in a given period in the past (e.g., in 20 seconds) then specific keepalive message MUST be sent. The exact details of keepalive messages are described in [4]. 4.3. Leaving Phase When closing the application, all connections MUST be terminated in order to avoid wasting resources. HIP stack should terminate the HIP states using appropriate signalling. This prevents vain NAT keepalives and other maintenance traffic from being transmitted. As the data traffic has been encapsulated in HIP initiated connections, closing the HIP states prevents also unwanted traffic from being received. For example, normally a datagram-based media stream may continue to be sent (and delivered to the host) even after the receiving application is closed. This is harmful in mobile environments where it drains the battery and may be expensive without flat-rate pricing. Hautakorpi, et al. Expires May 22, 2008 [Page 10] Internet-Draft Utilizing HIP for P2PSIP November 2007 5. Using Relays The methods described in this section crosses somewhat the border between the HIP layer and P2PSIP overlay layer. Our approach tries to keep these separate and comment only on how HIP could be utilized, steering clear of the overlay structure, logic or content. Our model is however reliant on the presence of relays, which can be seen as the weak link of the approach. This compels us to address the issue to some extent, which is done in following method for decreasing the reliance on infrastructure, which involves the overlay to a small degree. As peers of the overlay might not be publicly accessible, HIP connections may have to be initiated through a relay to traverse NAT and other middleboxes. However, peers may not have suitable infrastructure support, i.e., relays, at their disposal. This can be solved by having peers of the overlay act as relays. Peers who seem to be in a suitable position could register themselves in the DHT overlay as such. The peer MAY register itself as a relay if it fulfills the following criterions: o Peer has a public IP address o Peer has a non-blocking firewall (as far as the peer itself is aware) o Peer has sufficient online history (e.g., has been online 75% of time during the last week) As all of these supposedly suitable peers might not turn out to be so (due to incorrect probing, maliciousness or other reasons), peers SHOULD register to a number of these to increase the odds that at least one works correctly. The actual method how peers can register to a relay are out of scope for this document. The procedures for searching relays are described in Section 5.1 and Section 5.2. Those procedures MUST be used if the used peer protocol does not provide such procedures. However, if the peer protocol provides procedures for searching relays, then those MUST be used instead. 5.1. Baseline Relay Search The peers of the overlay should be able to use fixed, centralized relays. Typically a peer knows an IP or a FQDN (Fully Qualified Domain Name) of a fixed relay and can contact it directly without consulting the overlay network. Another possiblity is to use some of the neighboring peers in the Hautakorpi, et al. Expires May 22, 2008 [Page 11] Internet-Draft Utilizing HIP for P2PSIP November 2007 overlay network as relays. As a default, a peer has HIP initiated connections to all the neighboring peers, so those connections can be re-used (i.e., no additional HIP initiated connections are needed). The actual mechanism for finding out whether a neighbor can act as a relay or not is out of scope for this document (that kind of mechanism can be e.g., a part of a peer protocol). It is noteworthy that if neighboring peers are used as relays, it also provides a very simple load balancing functionality. That is, the relays and their usage is quite evenly distributed to the overlay identifier space (assuming that peer identifiers are evenly scattered). 5.2. Distributed Relay Search Depending on the overlay algorithm used, it might be needed to distribute the load on certain nodes caused by the quite frequent registrations of relays and subsequent lookups. One way is to utilize the HIT as salt when generating the entry key. For example, consider a relay with the HIT 0xa1b2c3d4e5 that is about to register itself in the DHT. For finding a service in general, there needs to be a pre-defined prefix used to construct the keys - here we use "relay:". Initially, the relay tries to register to the "root" entry of the service which is under the key constructed from the prefix alone - 'HASH("relay:")'. If the amount of registered entries is under a certain limit (e.g., 100), the relay will try the next branch. The key for it is made by appending the first character of the host's HIT as expressed in hex to the common prefix - HASH("relay:a"). The same check is performed - if the number of registered entries exceed the limit, the relay tries yet the next branch, HASH("relay:a1"), and continues until a suitable slot is found. When searching for a relay, peers do the opposite - start from the outer-most branch and work their way to the root until enough entries are found. This way the most common operation (lookup of relay) and burden of storing the registrations is distributed, at least partially, throughout the DHT. The relay registration/search mechanism described above can also be applied to other popular services. For example, a voicemail service could use similar mechanism. 6. Mobility Scenario - Make-Before-Break In the make-before-break mobility scenario a new connection is established before the old connections is closed. This kind of scenario can happen for example in a case where a laptop with stable Hautakorpi, et al. Expires May 22, 2008 [Page 12] Internet-Draft Utilizing HIP for P2PSIP November 2007 Wireless Local Area Network (WLAN) connectivity is plugged into ethernet. Peer A Peer B : : A wants to change : : to a new connection : : (new IP) | | | | .......... Existing connection ......... | +------------->| | |------------ 1. HIP UPDATE -------------->| |<----------- 2. HIP UPDATE ---------------| | ........................................ | | | :<<------ ICE connectivity checks ------->>: | | | .......... Existing connection ......... | |------------ 3. HIP UPDATE -------------->| |<----------- 4. HIP UPDATE ---------------| | ........................................ | | | | | | ............. New connection ........... | | | | ........................................ | | | | | Figure 5: Message Sequence - Make-Before-Break Figure 5 is presenting a signaling flow in make-before-break scenario. The trigger for changing to a new connection can be e.g., an event where a peer acquires a new network interface which has higher priority that the currently used network interface. The establishment of a new HIP initiated connection is started by sending a HIP update message (1) to the other party. That message contains new ICE candidates, as described in [4]. When the other party, Peer B in Figure 5, receives the HIP UPDATE (1) it replies with its own ICE candidates to Peer A (2). After that the ICE connectivity checks will be done. When the ICE connectivity checks have finished, then the old HIP initiated connection can be closed with appropriate HIP UPDATE messages (3-4). After that the new HIP initiated connection, which is bound to the Peer A's new IP, can be used for further signaling and traffic. Hautakorpi, et al. Expires May 22, 2008 [Page 13] Internet-Draft Utilizing HIP for P2PSIP November 2007 7. Mobility Scenario - Break-Before-Make In the break-before-make mobility scenario an old connection has been terminated before a new connection is established. This kind of scenario can happen for example in a case where a laptop using WLAN is going outside the coverage area and is then plugged into ethernet. Peer A Peer C : : A notices that : : the active and only : : interface has gone | | down | | | | | +------------->| | : Peer B : +------------->| (with public IP) | | |---- 1. HIP UPDATE ---->| | A notices that a |<--- 2. HIP UPDATE -----| | new connection has | | | come up :<<-- ICE con. checks ->>: | | | | | ... new connection ... | ............... | |------ PP1+UPDATE ----->|-- PP2+UPDATE -->| |<----- PP4+UPDATE ------|<- PP3+UPDATE ---| | ...................... | ............... | | | | | | :<<------ ICE connectivity checks ------->>: | | | .............. new connection .......... | | | | ........................................ | | | Figure 6: Message Sequence - Break-Before-Make (non-multi-homed peer) Figure 6 is presenting a signaling flow in a case where a non-multi- homed peer (i.e., peer has only one active network interface) is subjected to a break-before-make mobility scenario. The mobility signaling in break-before-make scenario is triggered by the event where the peer notices that the interface it was using has gone down. When the node regains connectivity, which is bound to a different IP address than the previous intercase, it needs to re-establish connections to all its neighboring peers. The re-establishment of HIP initiated connections is started by sending HIP UPDATE packets to those neighboring peers that were not Hautakorpi, et al. Expires May 22, 2008 [Page 14] Internet-Draft Utilizing HIP for P2PSIP November 2007 behind a NAT. In Figure 6 this is the Peer B. The update packet (1), and its reply (2) can be sent e.g., directy on top of IP protocol. Then the ICE connectivity checks are executed and a new connection is established to Peer B. When peer A has established at least one connection to some neighboring peer, it can use that connection to reach all the other nodes even if they are behind a NAT. In the Figure the connection to peer C is established with the peer protocol messages PP1-PP4, which carry the HIP update packets. When the encapsulated HIP UPDATE packets have been exchanged, peers will execute connectivity checks. The connectivity check results in re- established, HIP initiated connection between peers A and C. If the peer subjected to a break-before-make scenario would have been multi-homed (see Section 8), and if it would have had HIP initiated connections from more that one interface, then the scenario would have been more easy to handle. The peer could have just used its existing HIP initiated connections from the interfaces that did not go down, and send HIP UPDATE messages on top of peer protocol via those connections. 8. Multi-homing Scenario In multi-homing scenario a peer has more than one network interface that it can use. This kind of scenarion can be e.g., a laptop which has both WLAN and ethernet network interfaces up. Multi-homed peers should follow the procedures explained in [5]. That is, a multi-homed peer can gather ICE candidates and establish HIP initiated connections from each of its interfaces. For example, a laptop with WLAN and ethernet interfaces could have HIP initiated connections bound to both interfaces. It is noteworthy that ICE allows preset local preferences for the candidate addresses, so it is posible to favor one interface over another. If a P2PSIP peer is multi-homed and it is using more that one interface for HIP initiated connections, its operation is more robust in failure cases where one interface suddenly goes down. That kind of failure cases typically lead to break-before-make mobility scenarios, see Section 7. 9. Other Benefits that HIP Provides for P2PSIP HIP is based on asymmetric cryptography and it requires the generation of an asymmetric key pair (e.g., by using Rivest Shamir Adelman (RSA) algorithm). The hosts are identified by using a HIT, Hautakorpi, et al. Expires May 22, 2008 [Page 15] Internet-Draft Utilizing HIP for P2PSIP November 2007 which is a hash (calculated e.g., by using SHA-1 algorithm) from the generated public key. The host identifiers could be used also as peer identifiers in a P2PSIP network. It is worth highlighting that the HITs are used to identify hosts and not users or services. If HITs are used as peer identifiers in a P2PSIP network, it has positive security implications. Section 11.2. in [13] states that a large number from threats agains P2P networks can be avoided, or at least alleviated, if the malicious nodes cannot be injected into a freely chosen location in an overlay address space. The free choice of peer identifiers can be prevented at least in two ways; either by using some central authority that distributes asserted peer identifiers or by using HITs as peer identifiers. The usage of central authority is not explored in this document. If HITs are used as peer identifiers, an attacker cannot freely choose the peer identifier, because the generation of asymmetric key pair is computationally demanding operation and it would need to be executed a considerable number of times in a large P2P network. 10. Security Considerations The security considerations of this document to the P2PSIP network as a whole are going to be studied in the coming versions. 11. IANA Considerations No IANA considerations. 12. References 12.1. Normative References [1] Willis, D., "Concepts and Terminology for Peer to Peer SIP", draft-willis-p2psip-concepts-04 (work in progress), March 2007. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [4] Schmitt, V., "HIP Extensions for the Traversal of Network Address Translators", draft-ietf-hip-nat-traversal-02 (work in Hautakorpi, et al. Expires May 22, 2008 [Page 16] Internet-Draft Utilizing HIP for P2PSIP November 2007 progress), July 2007. [5] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Eggert, L. and J. Laganier, "Host Identity Protocol (HIP) Rendezvous Extensions", draft-eggert-hip-rvs-00 (work in progress), July 2004. [8] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", draft-nikander-hip-dns-00 (work in progress), July 2004. [9] Ahrenholz, J., "HIP DHT Interface", draft-ahrenholz-hiprg-dht-01 (work in progress), February 2007. [10] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", draft-ietf-hip-base-10 (work in progress), October 2007. 12.2. Informative References [11] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Frans Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications", IEEE Transactions on Networking, 2003. [12] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [13] Bryan, D., "REsource LOcation And Discovery (RELOAD)", draft-bryan-p2psip-reload-01 (work in progress), July 2007. [14] Jennings, C. and J. Rosenberg, "Address Settlement by Peer to Peer", draft-jennings-p2psip-asp-00 (work in progress), July 2007. [15] Baset, S. and H. Schulzrinne, "Peer-to-Peer Protocol (P2PP)", draft-baset-p2psip-p2pp-00 (work in progress), July 2007. Hautakorpi, et al. Expires May 22, 2008 [Page 17] Internet-Draft Utilizing HIP for P2PSIP November 2007 Appendix A. Peer's Software Architecture This appendix in meant only as a guideline for the implementors. The Figure 7 present the architecture of a P2PSIP Peer which is using HIP for establishing and maintaining long-lived connections to other peers. +---------------------------------------------------------------------+ | P2PSIP Peer | |+-----------------+ +-----------------+ +-----------------+| || P2PSIP | | | API2 | || || Communication | API1 | P2P |----->| HIP || || Application |----->| Module | | Daemon || || | | | API3 | || || [UDP/TCP] | | [UDP/TCP] |<-----| [UDP] || |+-----------------+ +-----------------+ +-----------------+| | ^ ^ ^ ^ | | | | | | | |+----------------------------------------------------------+ | | || HIP Data Plane (e.g. IPsec) | | | |+----------------------------------------------------------+ | | | | | | | | |+-------------------------------------------------------------------+| || IPv4/IPv6 || |+-------------------------------------------------------------------+| | | | | | | +---------------------------------------------------------------------+ :|: :|: :|: | :|: :|: :|: | v v v v SIP Peer Protocol HIP HIP Figure 7: Architecture of a P2PSIP Peer The "blocks" in Figure 7 are the following: o P2PSIP Communication Application: It contains the user interface, buddylist, etc. o P2P Module: It contains DHT specific functions, such as overlay maintenance and overlay routing. This can be though as a daemon. o HIP Daemon: It contains HIP signaling specific stuff. It also contains functions needed for NAT traversal, such as ICE candidate gathering and exchange, connectivity checks and keepalives. As the name implies, it can be though as a daemon. o HIP Data Plane: Contains the encapsulation of further signaling and media into a HIP initiated connection. Can be for example an IPsec implementation. Hautakorpi, et al. Expires May 22, 2008 [Page 18] Internet-Draft Utilizing HIP for P2PSIP November 2007 o IPv4/IPv6: Ordinary IP stack. The Application Programming Interfaces (APIs) in Figure 7 are the following: o API1: Returns a peer identifier/HIT to a P2PSIP communication application when a hash from an SIP URI has been given as an input to the P2P Module. o API2: P2P module is able to pass information regarding the relays to the HIP daemon. o API3: By using this API the HIP daemon is able to send and receive packets that are transported on top of a peer protocol. SIP, Peer Protocol, and HIP can traverse HIP Initiated connections, which is illustrated with dotted "tubes" in the bottom of Figure 7. Authors' Addresses Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: jani.hautakorpi@ericsson.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: gonzalo.camarillo@ericsson.com Joakim Koskela Helsinki Institute for Information Technology Metsaenneidonkuja 4 Espoo 02130 Finland Email: joakim.koskela@hiit.fi Hautakorpi, et al. Expires May 22, 2008 [Page 19] Internet-Draft Utilizing HIP for P2PSIP November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hautakorpi, et al. Expires May 22, 2008 [Page 20]