draft-ietf-hip-bone-06.txt   draft-ietf-hip-bone-07.txt 
HIP Working Group G. Camarillo HIP Working Group G. Camarillo
Internet-Draft P. Nikander Internet-Draft P. Nikander
Intended status: Experimental J. Hautakorpi Intended status: Experimental J. Hautakorpi
Expires: October 11, 2010 A. Keranen Expires: December 24, 2010 A. Keranen
Ericsson Ericsson
A. Johnston A. Johnston
Avaya Avaya
April 9, 2010 June 22, 2010
HIP BONE: Host Identity Protocol (HIP) HIP BONE: Host Identity Protocol (HIP)
Based Overlay Networking Environment Based Overlay Networking Environment
draft-ietf-hip-bone-06.txt draft-ietf-hip-bone-07.txt
Abstract Abstract
This document specifies a framework to build HIP (Host Identity This document specifies a framework to build HIP (Host Identity
Protocol)-based overlay networks. This framework uses HIP to perform Protocol)-based overlay networks. This framework uses HIP to perform
connection management. Other functions, such as data storage and connection management. Other functions, such as data storage and
retrieval or overlay maintenance, are implemented using protocols retrieval or overlay maintenance, are implemented using protocols
other than HIP. These protocols are loosely referred to as peer other than HIP. These protocols are loosely referred to as peer
protocols. protocols.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 11, 2010. This Internet-Draft will expire on December 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 24 skipping to change at page 2, line 24
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 4 3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 4
3.1. ID/locator Split . . . . . . . . . . . . . . . . . . . . . 4 3.1. ID/locator Split . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Identifier Format . . . . . . . . . . . . . . . . . . 5 3.1.1. Identifier Format . . . . . . . . . . . . . . . . . . 5
3.1.2. HIP Base Exchange . . . . . . . . . . . . . . . . . . 5 3.1.2. HIP Base Exchange . . . . . . . . . . . . . . . . . . 6
3.1.3. Locator Management . . . . . . . . . . . . . . . . . . 6 3.1.3. Locator Management . . . . . . . . . . . . . . . . . . 6
3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6 3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 7 3.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Identifier Assignment and Authentication . . . . . . . 7 3.3.2. Identifier Assignment and Authentication . . . . . . . 8
3.3.3. Connection Security . . . . . . . . . . . . . . . . . 8 3.3.3. Connection Security . . . . . . . . . . . . . . . . . 9
3.4. HIP Deployability and Legacy Applications . . . . . . . . 8 3.4. HIP Deployability and Legacy Applications . . . . . . . . 9
4. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 9 4. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 10
5. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 12 5. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 13
5.1. Node ID Assignment and Bootstrap . . . . . . . . . . . . . 13 5.1. Node ID Assignment and Bootstrap . . . . . . . . . . . . . 13
5.2. Overlay Network Identification . . . . . . . . . . . . . . 14 5.2. Overlay Network Identification . . . . . . . . . . . . . . 14
5.3. Connection Establishment . . . . . . . . . . . . . . . . . 14 5.3. Connection Establishment . . . . . . . . . . . . . . . . . 15
5.4. Lightweight Message Exchanges . . . . . . . . . . . . . . 15 5.4. Lightweight Message Exchanges . . . . . . . . . . . . . . 15
5.5. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 15 5.5. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 16
6. Overlay HIP Parameters . . . . . . . . . . . . . . . . . . . . 16 6. Overlay HIP Parameters . . . . . . . . . . . . . . . . . . . . 17
6.1. Overlay Identifier . . . . . . . . . . . . . . . . . . . . 16 6.1. Overlay Identifier . . . . . . . . . . . . . . . . . . . . 17
6.2. Overlay TTL . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Overlay TTL . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [RFC5201] defines a new name space The Host Identity Protocol (HIP) [RFC5201] defines a new name space
between the network and transport layers. HIP provides upper layers between the network and transport layers. HIP provides upper layers
with mobility, multihoming, NAT (Network Address Translation) with mobility, multihoming, NAT (Network Address Translation)
traversal, and security functionality. HIP implements the so called traversal, and security functionality. HIP implements the so called
identifier/locator (ID/locator) split, which implies that IP identifier/locator (ID/locator) split, which implies that IP
addresses are only used as locators, not as host identifiers. This addresses are only used as locators, not as host identifiers. This
split makes HIP a suitable protocol to build overlay networks that split makes HIP a suitable protocol to build overlay networks that
implement identifier-based overlay routing over IP networks, which in implement identifier-based overlay routing over IP networks, which in
turn implement locator-based routing. turn implement locator-based routing.
Using HIP BONE, as opposed to a peer protocol, to perform connection Using Host Identity Protocol Based Overlay Networking Environment
(HIP BONE), as opposed to a peer protocol, to perform connection
management in an overlay has a set of advantages. HIP BONE can be management in an overlay has a set of advantages. HIP BONE can be
used by any peer protocol. This keeps each peer protocol from used by any peer protocol. This keeps each peer protocol from
defining primitives needed for connection management (e.g., defining primitives needed for connection management (e.g.,
primitives to establish connections and to tunnel messages through primitives to establish connections and to tunnel messages through
the overlay) and NAT traversal. Having this functionality at a lower the overlay) and NAT traversal. Having this functionality at a lower
layer allows multiple upper-layer protocols to take advantage of it. layer allows multiple upper-layer protocols to take advantage of it.
Additionally, having a solution that integrates mobility and Additionally, having a solution that integrates mobility and
multihoming is useful in many scenarios. Peer protocols do not multihoming is useful in many scenarios. Peer protocols do not
typically specify mobility and multihoming solutions. Combining a typically specify mobility and multihoming solutions. Combining a
peer protocol including NAT traversal with a separate mobility peer protocol including NAT traversal with a separate mobility
mechanism and a separate multihoming mechanism can easily lead to mechanism and a separate multihoming mechanism can easily lead to
unexpected (and unpleasant) interactions. unexpected (and unpleasant) interactions.
The remainder of this document is organized as follows. Section 3 The remainder of this document is organized as follows. Section 3
provides background information on HIP. Section 4 gives an overview provides background information on HIP. Section 4 gives an overview
of the HIP BONE (HIP-Based Overlay Networking Environment) framework of the HIP BONE (HIP-Based Overlay Networking Environment) framework
and architecture and Section 5 describes the framework in more and architecture and Section 5 describes the framework in more
detail. Finally, before the customary sections, Section 6 introduces detail. Finally, Section 6 introduces new HIP parameters for overlay
new HIP parameters for overlay usage. usage.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The following terms are used in context of HIP BONEs: The following terms are used in context of HIP BONEs:
Overlay network: A network built on top of another network. In case Overlay network: A network built on top of another network. In case
skipping to change at page 4, line 15 skipping to change at page 4, line 19
Peer protocol: A protocol used by nodes in an overlay network for Peer protocol: A protocol used by nodes in an overlay network for
performing, e.g., data storage and retrieval or overlay performing, e.g., data storage and retrieval or overlay
maintenance. HIP is used for conveying the peer protocol messages maintenance. HIP is used for conveying the peer protocol messages
between the nodes in the overlay network. between the nodes in the overlay network.
HIP BONE instance: A HIP-based overlay network that uses a HIP BONE instance: A HIP-based overlay network that uses a
particular peer protocol and is based on the framework presented particular peer protocol and is based on the framework presented
in this document. in this document.
Node ID: A value that uniquely identifies a node in an overlay Node ID: A value that uniquely identifies a node in an overlay
network. The value is not usually human-friendly, but for example network. The value is not usually human-friendly. As an example,
a hash of a public key. it may be a hash of a public key.
HIP association: An IP-layer communications context created using
the Host Identity Protocol.
Valid locator: A Locator (as defined in [RFC5206]; usually an IP Valid locator: A Locator (as defined in [RFC5206]; usually an IP
address or an address and a port number) that a host is known to address or an address and a port number) that a host is known to
be reachable at, for example, because there is an active HIP be reachable at, for example, because there is an active HIP
association with the host. association with the host.
Final recipient: A node is the final recipient of a HIP signaling
packet if one of its Host Identity Tags (HITs) matches to the
Receiver's HIT in the HIP packet header.
3. Background on HIP 3. Background on HIP
This section provides background on HIP. Given the tutorial nature This section provides background on HIP. Given the tutorial nature
of this section, readers that are familiar with what HIP provides and of this section, readers that are familiar with what HIP provides and
how HIP works may want to skip it. All descriptions contain how HIP works may want to skip it. All descriptions contain
references to the relevant HIP specifications where readers can find references to the relevant HIP specifications where readers can find
detailed explanations on the different topics discussed in this detailed explanations on the different topics discussed in this
section. section.
3.1. ID/locator Split 3.1. ID/locator Split
skipping to change at page 6, line 43 skipping to change at page 7, line 7
traffic. If any of the hosts changes its set of locators, it runs an traffic. If any of the hosts changes its set of locators, it runs an
update exchange [RFC5206], which consists of three messages. If a update exchange [RFC5206], which consists of three messages. If a
host is multihomed, it simply provides more than one locator in its host is multihomed, it simply provides more than one locator in its
exchanges. However, if both of the end points move at the same time, exchanges. However, if both of the end points move at the same time,
or through some other reason both lose track of the peers' currently or through some other reason both lose track of the peers' currently
active locators, they need to resort to using a rendezvous server or active locators, they need to resort to using a rendezvous server or
getting new peer locators by some other means. getting new peer locators by some other means.
3.2. NAT Traversal 3.2. NAT Traversal
HIP's NAT traversal mechanism [I-D.ietf-hip-nat-traversal] is based HIP's NAT traversal mechanism [RFC5770] is based on ICE (Interactive
on ICE (Interactive Connectivity Establishment) Connectivity Establishment) [RFC5245]. Hosts gather address
[I-D.ietf-mmusic-ice]. Hosts gather address candidates and, as part candidates and, as part of the HIP base exchange, hosts perform an
of the HIP base exchange, hosts perform an ICE offer/answer exchange ICE offer/answer exchange where they exchange their respective
where they exchange their respective address candidates. Hosts address candidates. Hosts perform end-to-end STUN [RFC5389] based
perform end-to-end STUN [RFC5389] based connectivity checks in order connectivity checks in order to discover which address candidate
to discover which address candidate pairs yield connectivity. pairs yield connectivity.
Even though, architecturally, HIP lies below the transport layer Even though, architecturally, HIP lies below the transport layer
(i.e., HIP packets are carried directly in IP packets), in presence (i.e., HIP packets are carried directly in IP packets), in presence
of NATs, HIP sometimes needs to be tunneled in a transport protocol of NATs, HIP sometimes needs to be tunneled in a transport protocol
(i.e., HIP packets are carried by a transport protocol such as UDP). (i.e., HIP packets are carried by a transport protocol such as UDP).
3.3. Security 3.3. Security
Security is an essential part of HIP. The following sections Security is an essential part of HIP. The following sections
describe the security-related functionality provided by HIP. describe the security-related functionality provided by HIP.
skipping to change at page 8, line 22 skipping to change at page 8, line 37
A HIT is the hash of a node's public key. A node proves that it has A HIT is the hash of a node's public key. A node proves that it has
the right to use a HIT by showing its ability to sign data with its the right to use a HIT by showing its ability to sign data with its
associated private key. This scheme is secure due to the so called associated private key. This scheme is secure due to the so called
second-preimage resistance property of hash functions. That is, second-preimage resistance property of hash functions. That is,
given a fixed public key K1, finding a different public key K2 such given a fixed public key K1, finding a different public key K2 such
that hash(K1) = hash(K2) is computationally very hard. Optimally, a that hash(K1) = hash(K2) is computationally very hard. Optimally, a
preimage attack on the 100-bit hash function used in ORCHIDs will preimage attack on the 100-bit hash function used in ORCHIDs will
take an order of 2^100 operations to be successful, and can be take an order of 2^100 operations to be successful, and can be
expected to take in the average 2^99 operations. Given that each expected to take in the average 2^99 operations. Given that each
operation requires the attacker to generate a new key pair, the operation requires the attacker to generate a new key pair, the
attack is completely impractical (see [RFC4843]). attack is fully impractical with current technology and techniques
(see [RFC4843]).
HIP nodes using HITs as ORCHIDs do not typically use certificates HIP nodes using HITs as ORCHIDs do not typically use certificates
during their base exchanges. Instead, the use a leap-of-faith during their base exchanges. Instead, the use a leap-of-faith
mechanism, similar to the Secure Shell (SSH) protocol [RFC4251], mechanism, similar to the Secure Shell (SSH) protocol [RFC4251],
whereby a node authenticates somehow remote nodes the first time they whereby a node authenticates somehow remote nodes the first time they
connect it and, then, remembers their public keys. While user- connect it and, then, remembers their public keys. While user-
assisted leap-of-faith (such as in SSH) can be used to facilitate a assisted leap-of-faith (such as in SSH) can be used to facilitate a
human-operated offline path (such as a telephone call), automated human-operated offline path (such as a telephone call), automated
leap-of-faith can be combined with a reputation management system to leap-of-faith can be combined with a reputation management system to
create an incentive to behave. However, such considerations go well create an incentive to behave. However, such considerations go well
skipping to change at page 9, line 23 skipping to change at page 9, line 38
as such. It opens a connection (e.g., TCP) using the traditional as such. It opens a connection (e.g., TCP) using the traditional
IPv6 socket API. The HIP module running in the same host as the IPv6 socket API. The HIP module running in the same host as the
legacy application intercepts this call somehow (e.g., using an legacy application intercepts this call somehow (e.g., using an
interception library or setting up the host's routing tables so that interception library or setting up the host's routing tables so that
the HIP module receives the traffic) and runs HIP (on behalf of the the HIP module receives the traffic) and runs HIP (on behalf of the
legacy application) towards the IP address corresponding to the legacy application) towards the IP address corresponding to the
ORCHID. This mechanism works well in almost all cases. However, ORCHID. This mechanism works well in almost all cases. However,
applications involving referrals (i.e., passing of IPv6 addresses applications involving referrals (i.e., passing of IPv6 addresses
between applications) present issues, to be discussed in Section 5 between applications) present issues, to be discussed in Section 5
below. Additionally, management applications that care about the below. Additionally, management applications that care about the
exact IP address format may not work well with such straightforward exact IP address format may not work well with such a straightforward
approach. approach.
In order to make HIP work through the traditional IPv4 socket API, In order to make HIP work through the traditional IPv4 socket API,
the HIP module passes an LSI (Local Scope Identifier), instead of a the HIP module passes an LSI (Local Scope Identifier), instead of a
regular IPv4 address, to the legacy IPv4 application. The LSI looks regular IPv4 address, to the legacy IPv4 application. The LSI looks
like an IPv4 address, but is locally bound to an ORCHID. That is, like an IPv4 address, but is locally bound to an ORCHID. That is,
when the legacy application uses the LSI in a socket call, the HIP when the legacy application uses the LSI in a socket call, the HIP
module intercepts it and replaces the LSI with its corresponding module intercepts it and replaces the LSI with its corresponding
ORCHID. Therefore, LSIs always have local scope. They do not have ORCHID. Therefore, LSIs always have local scope. They do not have
any meaning outside the host running the application. The ORCHID is any meaning outside the host running the application. The ORCHID is
skipping to change at page 13, line 19 skipping to change at page 13, line 39
5.1. Node ID Assignment and Bootstrap 5.1. Node ID Assignment and Bootstrap
Nodes in an overlay are primarily identified by their Node IDs. Nodes in an overlay are primarily identified by their Node IDs.
Overlays typically have an enrollment server that can generate Node Overlays typically have an enrollment server that can generate Node
IDs, or at least some part of the Node ID, and sign certificates. A IDs, or at least some part of the Node ID, and sign certificates. A
certificate generated by an enrollment server authorizes a particular certificate generated by an enrollment server authorizes a particular
user to use a particular Node ID in a particular overlay. The way user to use a particular Node ID in a particular overlay. The way
users are identified is defined by the peer protocol and HIP BONE users are identified is defined by the peer protocol and HIP BONE
instance specification. instance specification.
The enrollment server of an overlay that were to use HITs derived The enrollment server of an overlay using HITs derived from public
from public keys as Node IDs could just authorize users to use the keys as Node IDs could just authorize users to use the public keys
public keys and HITs associated to their nodes. Such a Node ID has and HITs associated to their nodes. Such a Node ID has the same
the same self-certifying property as HITs and the Node ID can also be self-certifying property as HITs and the Node ID can also be used in
used in the HIP and legacy APIs as an ORCHID. This works well as the HIP and legacy APIs as an ORCHID. This works well as long as the
long as the enrollment server is the one generating the public/ enrollment server is the one generating the public/private key pairs
private key pairs for all those nodes. If the enrollment server for all those nodes. If the enrollment server authorizes users to
authorizes users to use HITs that are generated directly by the nodes use HITs that are generated directly by the nodes themselves, the
themselves, the system is open to a type of chosen-peer-ID attack. system is open to a type of chosen-peer-ID attack.
If the overlay network or peer protocol has more specific If the overlay network or peer protocol has more specific
requirements for the Node ID value that prevent using HITs derived requirements for the Node ID value that prevent using HITs derived
from public keys, each host will need a certificate (e.g., in their from public keys, each host will need a certificate (e.g., in their
HIP base exchanges) provided by the enrollment server to prove that HIP base exchanges) provided by the enrollment server to prove that
they are authorized to use a particular identifier in the overlay. they are authorized to use a particular identifier in the overlay.
Depending on how the certificates are constructed, they typically Depending on how the certificates are constructed, they typically
also need to contain the host's self-generated public key. Depending also need to contain the host's self-generated public key. Depending
on how the Node IDs and public keys are attributed, different on how the Node IDs and public keys are attributed, different
scenarios become possible. For example, the Node IDs may be scenarios become possible. For example, the Node IDs may be
skipping to change at page 14, line 34 skipping to change at page 15, line 7
HITs to be be bound to certain overlays or by defining the overlay HITs to be be bound to certain overlays or by defining the overlay
identifier using advanced HIP socket options or other suitable APIs. identifier using advanced HIP socket options or other suitable APIs.
On the other hand, if no explicit configuration for a HIP association On the other hand, if no explicit configuration for a HIP association
is used, a host may have a configured default overlay where all HIP is used, a host may have a configured default overlay where all HIP
messages without a valid locator are sent. The specification for how messages without a valid locator are sent. The specification for how
to implement this coordination for locally originated messages is out to implement this coordination for locally originated messages is out
of scope for this document. of scope for this document.
5.3. Connection Establishment 5.3. Connection Establishment
Nodes in an overlay need to establish connection with other nodes in Nodes in an overlay need to establish connections with other nodes in
different cases. For example, a node typically has connections to different cases. For example, a node typically has connections to
the nodes in its forwarding table. Nodes also need to establish the nodes in its forwarding table. Nodes also need to establish
connections with other nodes in order to exchange application-layer connections with other nodes in order to exchange application-layer
messages. messages.
As discussed earlier, HIP uses the base exchange to establish As discussed earlier, HIP uses the base exchange to establish
connections. A HIP endpoint (the initiator) initiates a HIP base connections. A HIP endpoint (the initiator) initiates a HIP base
exchange with a remote endpoint by sending an I1 packet. The exchange with a remote endpoint by sending an I1 packet. The
initiator sends the I1 packet to the remote endpoint's locator. initiator sends the I1 packet to the remote endpoint's locator.
Initiators that do not have any locator for the remote endpoint need Initiators that do not have any locator for the remote endpoint need
skipping to change at page 15, line 16 skipping to change at page 15, line 37
the connection. If the overlay nodes have active connections with the connection. If the overlay nodes have active connections with
other nodes in their forwarding tables and if those connections are other nodes in their forwarding tables and if those connections are
protected (typically with IPsec ESP), I1 packets may be sent over protected (typically with IPsec ESP), I1 packets may be sent over
protected connections between nodes. Alternatively, if there is no protected connections between nodes. Alternatively, if there is no
such an active connection but the node forwarding the I1 packet has a such an active connection but the node forwarding the I1 packet has a
valid locator for the next hop, the I1 packets may be forwarded valid locator for the next hop, the I1 packets may be forwarded
directly, in a similar fashion to how I1 packets are today forwarded directly, in a similar fashion to how I1 packets are today forwarded
by a HIP rendezvous server. by a HIP rendezvous server.
Since HIP supports NAT traversal, a HIP base exchange over the Since HIP supports NAT traversal, a HIP base exchange over the
overlay will perform an ICE [I-D.ietf-mmusic-ice] offer/answer overlay will perform an ICE [RFC5245] offer/answer exchange between
exchange between the nodes that are establishing the connection. In the nodes that are establishing the connection. In order to perform
order to perform this exchange, the nodes need to first gather this exchange, the nodes need to first gather candidate addresses.
candidate addresses. Which nodes can be used to obtain reflexive Which nodes can be used to obtain reflexive address candidates and
address candidates and which ones can be used to obtain relayed which ones can be used to obtain relayed candidates is defined by the
candidates is defined by the peer protocol. peer protocol.
5.4. Lightweight Message Exchanges 5.4. Lightweight Message Exchanges
In some cases, nodes need to perform a lightweight query to another In some cases, nodes need to perform a lightweight query to another
node (e.g., a request followed by a single response). In this node (e.g., a request followed by a single response). In this
situation, establishing a connection using the mechanisms in situation, establishing a connection using the mechanisms in
Section 5.3 for a simple query would be an overkill. A better Section 5.3 for a simple query would be an overkill. A better
solution is to forward a HIP message through the overlay with the solution is to forward a HIP message through the overlay with the
query and another one with the response to the query. The payload of query and another one with the response to the query. The payload of
such HIP packets is integrity protected [I-D.ietf-hip-hiccups]. such HIP packets is integrity protected [I-D.ietf-hip-hiccups].
skipping to change at page 16, line 4 skipping to change at page 16, line 23
As discussed in Section 5, HIP BONE is a generic framework that As discussed in Section 5, HIP BONE is a generic framework that
allows using different peer protocols. A particular HIP BONE allows using different peer protocols. A particular HIP BONE
instance uses a particular peer protocol. The details on how to instance uses a particular peer protocol. The details on how to
implement a HIP BONE using a given peer protocol need to be specified implement a HIP BONE using a given peer protocol need to be specified
in a, so called, HIP BONE instance specification. A HIP BONE in a, so called, HIP BONE instance specification. A HIP BONE
instance specification needs to define, minimally: instance specification needs to define, minimally:
o the peer protocol to be used. o the peer protocol to be used.
o what kind of Node IDs are used and how they are derived. o what kind of Node IDs are used and how they are derived.
o which peer protocol primitives trigger HIP messages. o which peer protocol primitives trigger HIP messages.
o how the overlay identifier is generated. o how the overlay identifier is generated.
Additionally, a HIP BONE instance specification may need to specify Additionally, a HIP BONE instance specification may need to specify
other details that are specific to the peer protocol used. other details that are specific to the peer protocol used.
As an example, the HIP BONE instance specification for RELOAD As an example, the HIP BONE instance specification for RELOAD
[I-D.ietf-p2psip-base] is specified in [I-D.ietf-p2psip-base] is specified in
[I-D.ietf-hip-reload-instance]. [I-D.ietf-hip-reload-instance].
It is assumed that areas not covered by a particular HIP BONE The areas not covered by a particular HIP BONE instance specification
instance specification are specified by the peer protocol or are specified by the peer protocol or elsewhere. These areas
elsewhere. These areas include: include:
o the algorithm to create the overlay (e.g., a DHT). o the algorithm to create the overlay (e.g., a DHT).
o overlay maintenance functions. o overlay maintenance functions.
o data storage and retrieval functions. o data storage and retrieval functions.
o the process for obtaining a Node ID. o the process for obtaining a Node ID.
o bootstrap function. o bootstrap function.
o how to select STUN and TURN servers for the candidate address o how to select STUN and TURN servers for the candidate address
collection process in NAT traversal scenarios. collection process in NAT traversal scenarios.
Note that the border between HIP BONE instance specification and a Note that the border between HIP BONE instance specification and a
skipping to change at page 17, line 4 skipping to change at page 17, line 23
6.1. Overlay Identifier 6.1. Overlay Identifier
To identify to which overlay network a HIP message belongs to, all To identify to which overlay network a HIP message belongs to, all
HIP messages that are sent via an overlay, or as a part of operations HIP messages that are sent via an overlay, or as a part of operations
specific to a certain overlay, MUST contain an OVERLAY_ID parameter specific to a certain overlay, MUST contain an OVERLAY_ID parameter
with the identifier of the corresponding overlay network. Instance with the identifier of the corresponding overlay network. Instance
specifications define how the identifier is generated for different specifications define how the identifier is generated for different
types of overlay networks. The generation mechanism MUST be such types of overlay networks. The generation mechanism MUST be such
that it is unlikely to generate the same identifier for two different that it is unlikely to generate the same identifier for two different
overlay instances and hence it is RECOMMENDED that the identifier overlay instances and any other means possible for preventing
contains at least 32 bits of randomness. collisions SHOULD be used.
The generic format of the OVERLAY_ID parameter is shown in Figure 8. The generic format of the OVERLAY_ID parameter is shown in Figure 8.
Instance specifications define valid length for the parameter and how Instance specifications define valid length for the parameter and how
the identifier values are generated. the identifier values are generated.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 48 skipping to change at page 18, line 18
host is not the final recipient, the packet MUST be dropped and the host is not the final recipient, the packet MUST be dropped and the
host SHOULD send HIP Notify packet with type OVERLAY_TTL_EXCEEDED host SHOULD send HIP Notify packet with type OVERLAY_TTL_EXCEEDED
(value [TBD by IANA; 70]) to the sender of the original HIP packet. (value [TBD by IANA; 70]) to the sender of the original HIP packet.
The Notification Data field for the OVERLAY_TTL_EXCEEDED The Notification Data field for the OVERLAY_TTL_EXCEEDED
notifications SHOULD contain the HIP header and the TRANSACTION_ID notifications SHOULD contain the HIP header and the TRANSACTION_ID
[I-D.ietf-hip-hiccups] parameter (if one exists) of the packet whose [I-D.ietf-hip-hiccups] parameter (if one exists) of the packet whose
TTL exceeded. TTL exceeded.
Figure 9 shows the format of the OVERLAY_TTL parameter. The TTL Figure 9 shows the format of the OVERLAY_TTL parameter. The TTL
value is given as the number of overlay hops this packet has left and value is given as the number of overlay hops this packet has left and
it is encoded as an unsigned integer. it is encoded as an unsigned integer using network byte order.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Reserved | | TTL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA; 64011 ] Type [ TBD by IANA; 64011 ]
Length 4 Length 4
TTL The Time-to-live value TTL The Time-to-live value
Reserved Reserved for future use Reserved Reserved for future use
Figure 9: Format of the OVERLAY_TTL Parameter Figure 9: Format of the OVERLAY_TTL Parameter
The type of the OVERLAY_TTL parameter is critical (as defined in The type of the OVERLAY_TTL parameter is critical (as defined in
Section 5.2.1 of [RFC5201]) and therefore the final recipient of the Section 5.2.1 of [RFC5201]) and therefore all the HIP nodes
packet, and all HIP hosts on the path, MUST support it. If the forwarding a packet with this parameter MUST support it. If the
parameter is used in a scenario where the final recipient does not parameter is used in a scenario where the final recipient does not
support the parameter, the parameter SHOULD be removed before support the parameter, the parameter SHOULD be removed before
forwarding the packet to the final recipient. forwarding the packet to the final recipient.
7. Security Considerations 7. Security Considerations
This document provides a high-level framework to build HIP-based This document provides a high-level framework to build HIP-based
overlays. The security properties of HIP and its extensions used in overlays. The security properties of HIP and its extensions used in
this framework are discussed in their respective specifications. this framework are discussed in their respective specifications.
Those security properties can be affected by the way HIP is used in a Those security properties can be affected by the way HIP is used in a
skipping to change at page 19, line 33 skipping to change at page 19, line 44
for Overlay Routable Cryptographic Hash Identifiers for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)", RFC 4843, April 2007. (ORCHID)", RFC 4843, April 2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008. "Host Identity Protocol", RFC 5201, April 2008.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008. the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[I-D.ietf-hip-nat-traversal] [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, "Basic Host Identity Protocol (HIP) Extensions
Keranen, "Basic HIP Extensions for Traversal of Network for Traversal of Network Address Translators", RFC 5770,
Address Translators", draft-ietf-hip-nat-traversal-09 April 2010.
(work in progress), October 2009.
[I-D.ietf-hip-hiccups] [I-D.ietf-hip-hiccups]
Camarillo, G. and J. Melen, "HIP (Host Identity Protocol) Camarillo, G. and J. Melen, "HIP (Host Identity Protocol)
Immediate Carriage and Conveyance of Upper- layer Protocol Immediate Carriage and Conveyance of Upper- layer Protocol
Signaling (HICCUPS)", draft-ietf-hip-hiccups-02 (work in Signaling (HICCUPS)", draft-ietf-hip-hiccups-02 (work in
progress), March 2010. progress), March 2010.
10.2. Informative References 10.2. Informative References
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
skipping to change at page 20, line 31 skipping to change at page 20, line 45
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[I-D.ietf-hip-native-api] [I-D.ietf-hip-native-api]
Komu, M. and T. Henderson, "Basic Socket Interface Komu, M. and T. Henderson, "Basic Socket Interface
Extensions for Host Identity Protocol (HIP)", Extensions for Host Identity Protocol (HIP)",
draft-ietf-hip-native-api-12 (work in progress), draft-ietf-hip-native-api-12 (work in progress),
January 2010. January 2010.
[I-D.ietf-mmusic-ice] [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols", RFC 5245,
draft-ietf-mmusic-ice-19 (work in progress), October 2007. April 2010.
[I-D.ietf-p2psip-base] [I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-08 (work in Base Protocol", draft-ietf-p2psip-base-08 (work in
progress), March 2010. progress), March 2010.
[I-D.ietf-hip-reload-instance] [I-D.ietf-hip-reload-instance]
Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity
Protocol-Based Overlay Networking Environment (HIP BONE) Protocol-Based Overlay Networking Environment (HIP BONE)
 End of changes. 29 change blocks. 
66 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/