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]