Internet DRAFT - draft-hautakorpi-p2psip-with-hip


P2PSIP Working Group                                       J. Hautakorpi
Internet-Draft                                              G. Camarillo
Intended status: Standards Track                                Ericsson
Expires: May 22, 2008                                         J. Koskela
                                                       November 19, 2007

Utilizing HIP (Host Identity Protocol) for P2PSIP (Peer-to-peer Session
                          Initiation Protocol)

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   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

   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",
   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

   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|
     |                                                               |
     |                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
   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

   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

   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
   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

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

   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

                       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

 |                             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

   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
   Hirsalantie 11
   Jorvas  02420


   Gonzalo Camarillo
   Hirsalantie 11
   Jorvas  02420


   Joakim Koskela
   Helsinki Institute for Information Technology
   Metsaenneidonkuja 4
   Espoo  02130


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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Hautakorpi, et al.        Expires May 22, 2008                 [Page 20]