draft-ietf-hip-bone-07.txt   rfc6079.txt 
HIP Working Group G. Camarillo Internet Engineering Task Force (IETF) G. Camarillo
Internet-Draft P. Nikander Request for Comments: 6079 P. Nikander
Intended status: Experimental J. Hautakorpi Category: Experimental J. Hautakorpi
Expires: December 24, 2010 A. Keranen ISSN: 2070-1721 A. Keranen
Ericsson Ericsson
A. Johnston A. Johnston
Avaya Avaya
June 22, 2010 January 2011
HIP BONE: Host Identity Protocol (HIP) HIP BONE: Host Identity Protocol (HIP)
Based Overlay Networking Environment Based Overlay Networking Environment (BONE)
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-based (Host Identity
Protocol)-based overlay networks. This framework uses HIP to perform Protocol) 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".
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 Status of This Memo
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 This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for examination, experimental implementation, and
evaluation.
The list of Internet-Draft Shadow Directories can be accessed at This document defines an Experimental Protocol for the Internet
http://www.ietf.org/shadow.html. community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on December 24, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6079.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2011 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 Simplified 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 . . . . . . . . . . . . . . . . . . 6 3.1.2. HIP Base Exchange ...................................5
3.1.3. Locator Management . . . . . . . . . . . . . . . . . . 6 3.1.3. Locator Management ..................................6
3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 7 3.2. NAT Traversal ..............................................6
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 . . . . . . . 8 3.3.2. Identifier Assignment and Authentication ............7
3.3.3. Connection Security . . . . . . . . . . . . . . . . . 9 3.3.3. Connection Security .................................9
3.4. HIP Deployability and Legacy Applications . . . . . . . . 9 3.4. HIP Deployability and Legacy Applications ..................9
4. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 10 4. Framework Overview .............................................10
5. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . 15 5.3. Connection Establishment ..................................15
5.4. Lightweight Message Exchanges . . . . . . . . . . . . . . 15 5.4. Lightweight Message Exchanges .............................15
5.5. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 16 5.5. HIP BONE Instantiation ....................................16
6. Overlay HIP Parameters . . . . . . . . . . . . . . . . . . . . 17 6. Overlay HIP Parameters .........................................17
6.1. Overlay Identifier . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . 20 10.2. Informative References ...................................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 Host Identity Protocol Based Overlay Networking Environment Using HIP-Based Overlay Networking Environment (HIP BONE), as opposed
(HIP BONE), as opposed to a peer protocol, to perform connection to a peer protocol, to perform connection management in an overlay
management in an overlay has a set of advantages. HIP BONE can be has a set of advantages. HIP BONE can be used by any peer protocol.
used by any peer protocol. This keeps each peer protocol from This keeps each peer protocol from defining primitives needed for
defining primitives needed for connection management (e.g., connection management (e.g., primitives to establish connections and
primitives to establish connections and to tunnel messages through to tunnel messages through the overlay) and NAT traversal. Having
the overlay) and NAT traversal. Having this functionality at a lower this functionality at a lower layer allows multiple upper-layer
layer allows multiple upper-layer protocols to take advantage of it. 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
skipping to change at page 4, line 11 skipping to change at page 4, line 7
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
of HIP BONEs, the underlying network is an IP network and the of HIP BONEs, the underlying network is an IP network and the
overlay can be, e.g., a peer-to-peer (P2P) network. overlay can be, e.g., a peer-to-peer (P2P) network.
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.
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. As an example, network. The value is not usually human-friendly. As an example,
it may be a hash of a public key. it may be a hash of a public key.
HIP association: An IP-layer communications context created using HIP association: An IP-layer communications context created using
the Host Identity Protocol. 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) at which a host is known
be reachable at, for example, because there is an active HIP to be reachable, 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 Final recipient: A node is the final recipient of a HIP signaling
packet if one of its Host Identity Tags (HITs) matches to the packet if one of its Host Identity Tags (HITs) matches to the
Receiver's HIT in the HIP packet header. 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
In an IP network, IP addresses typically serve two roles: they are In an IP network, IP addresses typically serve two roles: they are
used as host identifiers and as host locators. IP addresses are used as host identifiers and as host locators. IP addresses are
locators because a given host's IP address indicates where in the locators because a given host's IP address indicates where in the
network that host is located. IP networks route based on these network that host is located. IP networks route based on these
locators. Additionally, IP addresses are used to identify remote locators. Additionally, IP addresses are used to identify remote
hosts. The simultaneous use of IP addresses as host identifiers and hosts. The simultaneous use of IP addresses as host identifiers and
locators makes mobility and multihoming complicated. For example, locators makes mobility and multihoming complicated. For example,
when a host opens a TCP connection, the host identifies the remote when a host opens a TCP connection, the host identifies the remote
end of the connection by the remote IP address (plus port). If the end of the connection by the remote IP address (plus port). If the
remote host changes its IP address, the TCP connection will not remote host changes its IP address, the TCP connection will not
survive, since the transport layer identifier of the remote end of survive, since the transport layer identifier of the remote end of
the connection has changed. the connection has changed.
Mobility solutions such as Mobile IP keep the remote IP address from Mobility solutions such as Mobile IP keep the remote IP address from
changing so that it can still be used as an identifier. HIP, on the changing so that it can still be used as an identifier. HIP, on the
other hand, uses IP addresses as only locators and defines a new other hand, uses IP addresses only as locators and defines a new
identifier space. This approach is referred to as the ID/locator identifier space. This approach is referred to as the ID/locator
split and makes the implementation of mobility and multihoming more split and makes the implementation of mobility and multihoming more
natural. In the previous example, the TCP connection would be bound natural. In the previous example, the TCP connection would be bound
to the remote host's identifier, which would not change when the to the remote host's identifier, which would not change when the
remote hosts moves to a new IP address (i.e., to a new locator). The remote hosts moves to a new IP address (i.e., to a new locator). The
TCP connection is able to survive locator changes because the remote TCP connection is able to survive locator changes because the remote
host's identifier does not change. host's identifier does not change.
3.1.1. Identifier Format 3.1.1. Identifier Format
HIP uses 128-bit ORCHIDs (Overlay Routable Cryptographic Hash HIP uses 128-bit ORCHIDs (Overlay Routable Cryptographic Hash
Identifiers) [RFC4843] as identifiers. ORCHIDs look like IPv6 Identifiers) [RFC4843] as identifiers. ORCHIDs look like IPv6
addresses but cannot collide with regular IPv6 addresses because addresses but cannot collide with regular IPv6 addresses because
ORCHID spaces are registered with the IANA. That is, a portion of ORCHID spaces are registered with the IANA. That is, a portion of
the IPv6 address space is reserved for ORCHIDs. The ORCHID the IPv6 address space is reserved for ORCHIDs. The ORCHID
specification allows creating multiple disjoint identifier spaces. specification allows the creation of multiple disjoint identifier
Each such space is identified by a separate Context Identifier. The spaces. Each such space is identified by a separate Context
Context Identifier can be either drawn implicitly from the context Identifier. The Context Identifier can be either drawn implicitly
the ORCHID is used in or carried explicitly in a protocol. from the context the ORCHID is used in or carried explicitly in a
protocol.
HIP defines a native socket API [I-D.ietf-hip-native-api] that HIP defines a native socket API [HIP-NATIVE-API] that applications
applications can use to establish and manage connections. can use to establish and manage connections. Additionally, HIP can
Additionally, HIP can also be used through the traditional IPv4 and also be used through the traditional IPv4 and IPv6 TCP/IP socket
IPv6 TCP/IP socket APIs. Section 3.4 describes how an application APIs. Section 3.4 describes how an application using these
using these traditional APIs can make use of HIP. Figure 1 shows all traditional APIs can make use of HIP. Figure 1 shows all these APIs
these APIs between the application and the transport layers. between the application and the transport layers.
+-----------------------------------------+ +-----------------------------------------+
| Application | | Application |
+----------------+------------------------+ +----------------+------------------------+
| HIP Native API | Traditional Socket API | | HIP Native API | Traditional Socket API |
+----------------+------------------------+ +----------------+------------------------+
| Transport Layer | | Transport Layer |
+-----------------------------------------+ +-----------------------------------------+
Figure 1: HIP API Figure 1: HIP API
3.1.2. HIP Base Exchange 3.1.2. HIP Base Exchange
Before two HIP hosts exchange upper-layer traffic, they perform a Typically, before two HIP hosts exchange upper-layer traffic, they
four-way handshake that is referred to as the HIP base exchange. perform a four-way handshake that is referred to as the HIP base
Figure 2 illustrates the HIP base exchange. The initiator sends an exchange. Figure 2 illustrates the HIP base exchange. The initiator
I1 packet and receives an R1 packet from the responder. After that, sends an I1 packet and receives an R1 packet from the responder.
the initiator sends an I2 packet and receives an R2 packet from the After that, the initiator sends an I2 packet and receives an R2
responder. packet from the responder.
Initiator Responder Initiator Responder
| I1 | | I1 |
| -------------------------->| |-------------------------->|
| R1 | | R1 |
| <--------------------------| |<--------------------------|
| I2 | | I2 |
| -------------------------->| |-------------------------->|
| R2 | | R2 |
| <--------------------------| |<--------------------------|
Figure 2: HIP Base Exchange Figure 2: HIP Base Exchange
Of course, the initiator needs the responder's locator (or locators) Of course, the initiator needs the responder's locator (or locators)
in order to send its I1 packet. The initiator can obtain locators in order to send its I1 packet. The initiator can obtain locators
for the responder in multiple ways. For example, according to the for the responder in multiple ways. For example, according to the
current HIP specifications the initiator can get the locators current HIP specifications the initiator can get the locators
directly from the DNS [RFC5205] or indirectly by sending packets directly from the DNS [RFC5205] or indirectly by sending packets
through a HIP rendezvous server [RFC5204]. However, as an through a HIP rendezvous server [RFC5204]. However, HIP is an open-
architecture HIP is open ended, and allows the locators to be ended architecture. The HIP architecture allows the locators to be
obtained by any means (e.g., from packets traversing an overlay obtained by any means (e.g., from packets traversing an overlay
network or as part of the candidate address collection process in a network or as part of the candidate address collection process in a
NAT traversal scenario). NAT traversal scenario).
3.1.3. Locator Management 3.1.3. Locator Management
Once a HIP connection between two hosts has been established with a Once a HIP connection between two hosts has been established with a
HIP base exchange, the hosts can start exchanging higher-layer HIP base exchange, the hosts can start exchanging higher-layer
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 endpoints 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 [RFC5770] is based on ICE (Interactive HIP's NAT traversal mechanism [RFC5770] is based on ICE (Interactive
Connectivity Establishment) [RFC5245]. Hosts gather address Connectivity Establishment) [RFC5245]. Hosts gather address
candidates and, as part of the HIP base exchange, hosts perform an candidates and, as part of the HIP base exchange, hosts perform an
ICE offer/answer exchange where they exchange their respective ICE offer/answer exchange where they exchange their respective
address candidates. Hosts perform end-to-end STUN [RFC5389] based address candidates. Hosts perform end-to-end STUN-based [RFC5389]
connectivity checks in order to discover which address candidate connectivity checks in order 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 the
of NATs, HIP sometimes needs to be tunneled in a transport protocol presence of NATs, HIP sometimes needs to be tunneled in a transport
(i.e., HIP packets are carried by a transport protocol such as UDP). protocol (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.
3.3.1. DoS Protection 3.3.1. DoS Protection
HIP provides protection against DoS (Denial of Service) attacks by HIP provides protection against DoS (denial-of-service) attacks by
having initiators resolve a cryptographic puzzle before the responder having initiators resolve a cryptographic puzzle before the responder
stores any state. On receiving an I1 packet, a responder sends a stores any state. On receiving an I1 packet, a responder sends a
pre-generated R1 packet that contains a cryptographic puzzle and pre-generated R1 packet that contains a cryptographic puzzle and
deletes all the state associated with the processing of this I1 deletes all the state associated with the processing of this I1
packet. The initiator needs to resolve the puzzle in the R1 packet packet. The initiator needs to resolve the puzzle in the R1 packet
in order to generate an I2 packet. The difficulty of the puzzle can in order to generate an I2 packet. The difficulty of the puzzle can
be adjusted so that, if a receiver is under a DoS attack, it can be adjusted so that, if a receiver is under a DoS attack, it can
increase the difficulty of its puzzles. increase the difficulty of its puzzles.
On receiving an I2 packet, a receiver checks that the solution in the On receiving an I2 packet, a receiver checks that the solution in the
packet corresponds to a puzzle generated by the receiver and that the packet corresponds to a puzzle generated by the receiver and that the
solution is correct. If it is, the receiver processes the I2 packet. solution is correct. If it is, the receiver processes the I2 packet.
Otherwise, it silently discards it. Otherwise, it silently discards it.
In an overlay scenario, there are multiple ways how this mechanism In an overlay scenario, there are multiple ways in which this
can be utilized within the overlay. One possibility is to cache the mechanism can be utilized within the overlay. One possibility is to
pre-generated R1 packets within the overlay and let the overlay cache the pre-generated R1 packets within the overlay and let the
directly respond with R1s to I1s. In that way the responder is not overlay directly respond with R1s to I1s. In that way, the responder
bothered at all until the initiator sends an I2 packet, with the is not bothered at all until the initiator sends an I2 packet, with
puzzle solution. Furthermore, a more sophisticated overlay could the puzzle solution. Furthermore, a more sophisticated overlay could
verify that an I2 packet has a correctly solved puzzle before verify that an I2 packet has a correctly solved puzzle before
forwarding the packet to the responder. forwarding the packet to the responder.
3.3.2. Identifier Assignment and Authentication 3.3.2. Identifier Assignment and Authentication
As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main
representation for identifiers. Potentially, HIP can use different representation for identifiers. Potentially, HIP can use different
types of ORCHIDs as long as the probability of finding collisions types of ORCHIDs as long as the probability of finding collisions
(i.e., two nodes with the same ORCHID) is low enough. One way to (i.e., two nodes with the same ORCHID) is low enough. One way to
completely avoid this type of collision is to have a central completely avoid this type of collision is to have a central
skipping to change at page 8, line 29 skipping to change at page 8, line 21
and, implicitly, the associated public key. and, implicitly, the associated public key.
Having a central authority works well to completely avoid collisions. Having a central authority works well to completely avoid collisions.
However, having a central authority is impractical in some scenarios. However, having a central authority is impractical in some scenarios.
As defined today, HIP systems generally use a self-certifying ORCHID As defined today, HIP systems generally use a self-certifying ORCHID
type called HIT (Host Identity Tag) that does not require a central type called HIT (Host Identity Tag) that does not require a central
authority (but still allows one to be used). authority (but still allows one to be used).
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 fully impractical with current technology and techniques attack is fully impractical with current technology and techniques
(see [RFC4843]). (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, they 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 somehow authenticates remote nodes the first time they
connect it and, then, remembers their public keys. While user- connect to 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 mechanism (such as in SSH) can be used to
human-operated offline path (such as a telephone call), automated facilitate a human-operated offline path (such as a telephone call),
leap-of-faith can be combined with a reputation management system to automated leap-of-faith mechanisms can be combined with a reputation
create an incentive to behave. However, such considerations go well management system to create an incentive to behave. However, such
beyond the current HIP architecture and even beyond this proposal. considerations go well beyond the current HIP architecture and even
For the purposes of the present document, we merely want to point out beyond this proposal. For the purposes of the present document, we
that architecturally HIP supports both self-generated opportunistic merely want to point out that, architecturally, HIP supports both
identifiers and administratively assigned ones. self-generated opportunistic identifiers and administratively
assigned ones.
3.3.3. Connection Security 3.3.3. Connection Security
Once two nodes complete a base exchange between them, the traffic Once two nodes complete a base exchange between them, the traffic
they exchange is encrypted and integrity protected. The security they exchange is encrypted and integrity protected. The security
mechanism used to protect the traffic is IPsec Encapsulating Security mechanism used to protect the traffic is IPsec Encapsulating Security
Payload (ESP) [RFC5202]. However, there is ongoing work to specify Payload (ESP) [RFC5202]. However, there is ongoing work to specify
how to use different protection mechanisms. how to use other protection mechanisms.
3.4. HIP Deployability and Legacy Applications 3.4. HIP Deployability and Legacy Applications
As discussed earlier, HIP defines a native socket API As discussed earlier, HIP defines a native socket API [HIP-NATIVE-
[I-D.ietf-hip-native-api] that applications can use to establish and API] that applications can use to establish and manage connections.
manage connections. New applications can implement this API to get New applications can implement this API to get full advantage of HIP.
full advantage of HIP. However, in most cases, legacy (i.e., non-HIP However, in most cases, legacy (i.e., non-HIP-aware) applications
aware) applications [RFC5338] can use HIP through the traditional [RFC5338] can use HIP through the traditional IPv4 and IPv6 socket
IPv4 and IPv6 socket APIs. APIs.
The idea is that when a legacy IPv6 application tries and obtains a The idea is that when a legacy IPv6 application tries to obtain a
remote host's IP address (e.g., by querying the DNS) the DNS resolver remote host's IP address (e.g., by querying the DNS), the DNS
passes the remote host's ORCHID (which was also stored in the DNS) to resolver passes the remote host's ORCHID (which was also stored in
the legacy application. At the same time, the DNS resolver stores the DNS) to the legacy application. At the same time, the DNS
the remote host's IP address internally at the HIP module. Since the resolver stores the remote host's IP address internally at the HIP
ORCHID looks like an IPv6 address, the legacy application treats it module. Since the ORCHID looks like an IPv6 address, the legacy
as such. It opens a connection (e.g., TCP) using the traditional application treats it as such. It opens a connection (e.g., TCP)
IPv6 socket API. The HIP module running in the same host as the using the traditional IPv6 socket API. The HIP module running in the
legacy application intercepts this call somehow (e.g., using an same host as the legacy application intercepts this call somehow
interception library or setting up the host's routing tables so that (e.g., using an interception library or setting up the host's routing
the HIP module receives the traffic) and runs HIP (on behalf of the tables so that the HIP module receives the traffic) and runs HIP (on
legacy application) towards the IP address corresponding to the behalf of the legacy application) towards the IP address
ORCHID. This mechanism works well in almost all cases. However, corresponding to the ORCHID. This mechanism works well in almost all
applications involving referrals (i.e., passing of IPv6 addresses cases. However, applications involving referrals (i.e., passing of
between applications) present issues, to be discussed in Section 5 IPv6 addresses between applications) present issues, which are
below. Additionally, management applications that care about the discussed in Section 5 below. Additionally, management applications
exact IP address format may not work well with such a straightforward that care about the exact IP address format may not work well with
approach. such a straightforward 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
used on the wire; not the LSI. In the referral case, if it is not used on the wire; not the LSI. In the referral case, if it is not
skipping to change at page 10, line 13 skipping to change at page 10, line 15
Internet-wide settings. IPv4 LSIs have been successfully used in Internet-wide settings. IPv4 LSIs have been successfully used in
existing HIP deployments within a single corporate network. existing HIP deployments within a single corporate network.
4. Framework Overview 4. Framework Overview
The HIP BONE framework combines HIP with different peer protocols to The HIP BONE framework combines HIP with different peer protocols to
provide robust and secure overlay network solutions. provide robust and secure overlay network solutions.
Many overlays typically require three types of operations: Many overlays typically require three types of operations:
o overlay maintenance. o overlay maintenance,
o data storage and retrieval. o data storage and retrieval, and
o connection management. o connection management.
Overlay maintenance operations deal with nodes joining and leaving Overlay maintenance operations deal with nodes joining and leaving
the overlay and with the maintenance of the overlay's routing tables. the overlay and with the maintenance of the overlay's routing tables.
Data storage and retrieval operations deal with nodes storing, Data storage and retrieval operations deal with nodes storing,
retrieving, and removing information in or from the overlay. retrieving, and removing information in or from the overlay.
Connection management operations deal with the establishment of Connection management operations deal with the establishment of
connections and the exchange of lightweight messages among the nodes connections and the exchange of lightweight messages among the nodes
of the overlay, potentially in the presence of NATs. of the overlay, potentially in the presence of NATs.
The HIP BONE framework uses HIP to perform connection management. The HIP BONE framework uses HIP to perform connection management.
Data storage and retrieval and overlay maintenance are to be Data storage and retrieval and overlay maintenance are to be
implemented using protocols other than HIP. For lack of a better implemented using protocols other than HIP. For lack of a better
name, these protocols are referred to as peer protocols. name, these protocols are referred to as peer protocols.
One way to depict the relationship between the peer protocol and HIP One way to depict the relationship between the peer protocol and HIP
modules is shown in Figure 3. The peer protocol module implements modules is shown in Figure 3. The peer protocol module implements
the overlay construction and maintenance features, and possibly the overlay construction and maintenance features, and possibly
storage (if the particular protocol supports such a feature). The storage (if the particular protocol supports such a feature). The
HIP module consults the peer protocol's overlay topology part for HIP module consults the peer protocol's overlay topology part to make
making routing decisions and the peer protocol uses HIP for routing decisions, and the peer protocol uses HIP for connection
connection management and sending peer protocol messages to other management and sending peer protocol messages to other hosts. The
hosts. The HIP BONE API that applications use is a combination of HIP BONE API that applications use is a combination of the HIP Native
the HIP Native API and traditional socket API (as shown in Figure 1) API and traditional socket API (as shown in Figure 1) with any
with any additional API a particular instance implementation additional API a particular instance implementation provides.
provides.
Application Application
-------------------------------- HIP BONE API -------------------------------- HIP BONE API
+---+ +--------------------+ +---+ +--------------------+
| | | Peer Protocol | | | | Peer Protocol |
| | +--------+ +---------+ | | +--------+ +---------+
| |<->|Topology| |(Storage)| | |<->|Topology| |(Storage)|
| | +---------+----------+ | | +---------+----------+
| | ^ | | ^
| | v | | v
| +------------------------+ | +------------------------+
| HIP | | HIP |
+----------------------------+ +----------------------------+
Figure 3: HIP with Peer Protocol Figure 3: HIP with Peer Protocol
Architecturally, HIP can be considered to create a new thin "waist" Architecturally, HIP can be considered to create a new thin "waist"
layer on top of the IPv4 and IPv6 networks; see Figure 4. The HIP layer on top of the IPv4 and IPv6 networks; see Figure 4. The HIP
layer itself consists of the HIP signaling protocol and one or more layer itself consists of the HIP signaling protocol and one or more
data transport protocols; see Figure 5. The HIP signaling packets data transport protocols; see Figure 5. The HIP signaling packets
and the data transport packets can take different routes. In the HIP and the data transport packets can take different routes. In the HIP
BONE, the HIP signaling packets are typically first routed through BONE scenarios, the HIP signaling packets are typically first routed
the overlay and then directly (if possible), while the data transport through the overlay and then directly (if possible), while the data
packets are typically routed only directly between the end points. transport packets are typically routed only directly between the
endpoints.
+--------------------------------------+ +--------------------------------------+
| Transport (using HITs or LSIs) | | Transport (using HITs or LSIs) |
+--------------------------------------+ +--------------------------------------+
| HIP | | HIP |
+------------------+-------------------+ +------------------+-------------------+
| IPv4 | IPv6 | | IPv4 | IPv6 |
+------------------+-------------------+ +------------------+-------------------+
Figure 4: HIP as a Thin Waist Figure 4: HIP as a Thin Waist
+------------------+-------------------+ +------------------+-------------------+
| HIP signaling | data transports | | HIP signaling | data transports |
+------------------+-------------------+ +------------------+-------------------+
Figure 5: HIP Layer Structure Figure 5: HIP Layer Structure
In HIP BONE, the peer protocol creates a new signaling layer on top In HIP BONE, the peer protocol creates a new signaling layer on top
of HIP. It is used to set up forwarding paths for HIP signaling of HIP. It is used to set up forwarding paths for HIP signaling
messages. This is a similar relationship that an IP routing messages. This is a similar relationship that an IP routing
protocol, such as OSPF, has to the IP protocol itself. In the HIP protocol, such as OSPF, has to the IP protocol itself. In the HIP
BONE case, the peer protocol plays a role similar to OSPF, and HIP BONE case, the peer protocol plays a role similar to OSPF, and HIP
plays a role similar to IP. The ORCHIDs (or, in general, Node IDs if plays a role similar to IP. The ORCHIDs (or, in general, Node IDs if
the ORCHID prefix is not used) are used for forwarding HIP packets the ORCHID prefix is not used) are used for forwarding HIP packets
according to the information in the routing tables. The peer according to the information in the routing tables. The peer
protocols are used to exchange routing information based on Node IDs protocols are used to exchange routing information based on Node IDs
skipping to change at page 12, line 25 skipping to change at page 12, line 23
peer protocol (which needs to use HIP to establish connections with peer protocol (which needs to use HIP to establish connections with
other nodes) and HIP (which needs the peer protocol to know how to other nodes) and HIP (which needs the peer protocol to know how to
route messages to other nodes) for the same reasons as the bootstrap route messages to other nodes) for the same reasons as the bootstrap
of an IP network does not create circular dependencies between OSPF of an IP network does not create circular dependencies between OSPF
and IP. The first connections established by the peer protocol are and IP. The first connections established by the peer protocol are
with nodes whose locators are known. HIP establishes those with nodes whose locators are known. HIP establishes those
connections as any connection between two HIP nodes where no overlays connections as any connection between two HIP nodes where no overlays
are present. That is, there is no need for the overlay to provide a are present. That is, there is no need for the overlay to provide a
rendezvous service for those connections. rendezvous service for those connections.
+--------------------------------------+ +--------------------------------------+
| Peer protocol | | Peer protocol |
+--------------------------------------+ +--------------------------------------+
| Routing table | | Routing table |
+--------------------------------------+ +--------------------------------------+
| HIP | | HIP |
+--------------------------------------+ +--------------------------------------+
Figure 6: Routing Tables Figure 6: Routing Tables
It is possible that different overlays use different routing table It is possible that different overlays use different routing table
formats. For example, the structure of the routing tables of two formats. For example, the structure of the routing tables of two
overlays based on different DHTs (Distributed Hash Tables) may be overlays based on different DHTs (Distributed Hash Tables) may be
very different. In order to make routing decisions, the HIP layer very different. In order to make routing decisions, the HIP layer
needs to convert the routing table generated by the peer protocol needs to convert the routing table generated by the peer protocol
into a forwarding table that allows the HIP layer select a next-hop into a forwarding table that allows the HIP layer select a next hop
for any packet being routed. for any packet being routed.
In HIP BONE, the HIP usage of public keys and deriving ORCHIDs In HIP BONE, the HIP usage of public keys and deriving ORCHIDs
through a hash function can be utilized at the peer protocol side to through a hash function can be utilized at the peer protocol side to
better secure routing table maintenance and to protect against better secure routing table maintenance and to protect against
chosen-peer-ID attacks. chosen-peer-ID attacks.
The HIP BONE provides quite a lot of flexibility with regards to how HIP BONE provides quite a lot of flexibility with regards to how to
to arrange the different protocols in detail. Figure 7 shows one arrange the different protocols in detail. Figure 7 shows one
potential stack structure. potential stack structure.
+-----------------------+--------------+ +-----------------------+--------------+
| peer protocols | media | | peer protocols | media |
+------------------+----+--------------+ +------------------+----+--------------+
| HIP signaling | data transport | | HIP signaling | data transport |
| | | |
+------------------+-------------------+ +------------------+-------------------+
| NAT | non-NAT | | | NAT | non-NAT | |
| | | | | |
| IPv4 | IPv6 | | IPv4 | IPv6 |
+------------------+-------------------+ +------------------+-------------------+
Figure 7: Example HIP BONE Stack Structure Figure 7: Example HIP BONE Stack Structure
5. The HIP BONE Framework 5. The HIP BONE Framework
HIP BONE is a generic framework that allows the use of different peer HIP BONE is a generic framework that allows the use of different peer
protocols. A particular HIP BONE instance uses a particular peer protocols. A particular HIP BONE instance uses a particular peer
protocol. The details on how to implement a HIP BONE using a given protocol. The details on how to implement HIP BONE using a given
peer protocol need to be specified in a, so called, HIP BONE instance peer protocol need to be specified in a, so-called, HIP BONE instance
specification. Section 5.5 discusses what details need to be specification. Section 5.5 discusses what details need to be
specified by HIP BONE instance specifications. For example, the HIP specified by HIP BONE instance specifications. For example, the HIP
BONE instance specification for RELOAD [I-D.ietf-p2psip-base] is BONE instance specification for RELOAD [P2PSIP-BASE] is specified in
specified in [I-D.ietf-hip-reload-instance]. [HIP-RELOAD-INSTANCE].
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.
skipping to change at page 14, line 17 skipping to change at page 14, line 16
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
attributed to users, there may be user public key identifiers, and attributed to users, there may be user public key identifiers, and
there may be separate host public key identifiers. Authorization there may be separate host public key identifiers. Authorization
certificates can be used to bind the different types of identifiers certificates can be used to bind the different types of identifiers
together. together.
HITs, as defined in [RFC5201], always start with the ORCHID prefix. HITs, as defined in [RFC5201], always start with the ORCHID prefix.
Therefore, there are 100 bits left in the HIT for different Node ID Therefore, there are 100 bits left in the HIT for different Node ID
values. If an overlay network requires larger address space, it is values. If an overlay network requires a larger address space, it is
also possible to use all the 128 bits of a HIT for addressing peer also possible to use all the 128 bits of a HIT for addressing peer
layer identifiers. The benefit of using ORCHID prefix for Node IDs layer identifiers. The benefit of using ORCHID prefix for Node IDs
is that it makes possible to use them with legacy socket APIs, but in is that it makes possible to use them with legacy socket APIs, but in
this context most of the applications are assumed to be HIP aware and this context, most of the applications are assumed to be HIP aware
able to use a more advanced API supporting full 128-bit identifiers. and able to use a more advanced API supporting full 128-bit
Even larger address spaces could be supported with an additional HIP identifiers. Even larger address spaces could be supported with an
parameter giving the source and destination Node IDs, but defining additional HIP parameter giving the source and destination Node IDs,
such a parameter, if needed, is left for future documents. but defining such a parameter, if needed, is left for future
documents.
Bootstrap issues such as how to locate an enrollment or a bootstrap Bootstrap issues, such as how to locate an enrollment or a bootstrap
server belong to the peer protocol. server, belong to the peer protocol.
5.2. Overlay Network Identification 5.2. Overlay Network Identification
It is possible for a HIP host to participate simultaneously in It is possible for a HIP host to participate simultaneously in
multiple different overlay networks. It is also possible that some multiple different overlay networks. It is also possible that some
HIP traffic is not intended to be forwarded over an overlay. HIP traffic is not intended to be forwarded over an overlay.
Therefore, a host needs to know to which overlay an incoming HIP Therefore, a host needs to know to which overlay an incoming HIP
message belongs to and the outgoing HIP messages need to be labeled message belongs and the outgoing HIP messages need to be labeled as
belonging to a certain overlay. This document specifies a new belonging to a certain overlay. This document specifies a new
generic HIP parameter (in Section 6.1) for the purpose of directing generic HIP parameter (in Section 6.1) for the purpose of directing
HIP messages to the right overlay. HIP messages to the right overlay.
In addition, an application using HIP BONE needs to define, either In addition, an application using HIP BONE needs to define, either
implicitly or explicitly, the overlay to use for communication. implicitly or explicitly, the overlay to use for communication.
Explicit configuration can happen, e.g., by configuring certain local Explicit configuration can happen, e.g., by configuring certain local
HITs to be be bound to certain overlays or by defining the overlay HITs to 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 connections with other nodes in Nodes in an overlay need to establish connections with other nodes in
skipping to change at page 15, line 48 skipping to change at page 15, line 48
the nodes that are establishing the connection. In order to perform the nodes that are establishing the connection. In order to perform
this exchange, the nodes need to first gather candidate addresses. this exchange, the nodes need to first gather candidate addresses.
Which nodes can be used to obtain reflexive address candidates and Which nodes can be used to obtain reflexive address candidates and
which ones can be used to obtain relayed candidates is defined by the which ones can be used to obtain relayed 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
Section 5.3 for a simple query would be an overkill. A better 5.3 for a simple query would be an overkill. A better solution is to
solution is to forward a HIP message through the overlay with the forward a HIP message through the overlay with the query and another
query and another one with the response to the query. The payload of one with the response to the query. The payload of such HIP packets
such HIP packets is integrity protected [I-D.ietf-hip-hiccups]. is integrity protected [RFC6078].
Nodes in the overlay forward this HIP packet in a hop-by-hop fashion Nodes in the overlay forward this HIP packet in a hop-by-hop fashion
according to the overlay's routing table towards its destination, according to the overlay's routing table towards its destination,
typically through the protected connections established between them. typically through the protected connections established between them.
Again, the overlay acts as a rendezvous server between the nodes Again, the overlay acts as a rendezvous server between the nodes
exchanging the messages. exchanging the messages.
5.5. HIP BONE Instantiation 5.5. HIP BONE Instantiation
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, and
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 [P2PSIP-BASE] is specified in [HIP-RELOAD-INSTANCE].
[I-D.ietf-hip-reload-instance].
The areas not covered by a particular HIP BONE instance specification The areas not covered by a particular HIP BONE instance specification
are specified by the peer protocol or elsewhere. These areas are specified by the peer protocol or 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, and
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 a HIP BONE instance specification and a
peer protocol specifications is blurry. Depending on how generic the peer protocol specifications is fuzzy. Depending on how generic the
specification of a given peer protocol is, its associated HIP BONE specification of a given peer protocol is, its associated HIP BONE
instance specification may need to specify more or less details. instance specification may need to specify more or less details.
Also, a HIP BONE instance specification may leave certain areas Also, a HIP BONE instance specification may leave certain areas
unspecified in order to leave their configuration up to each unspecified in order to leave their configuration up to each
particular overlay. particular overlay.
6. Overlay HIP Parameters 6. Overlay HIP Parameters
This section defines generic format and protocol behavior for the This section defines the generic format and protocol behavior for the
Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that
can be used in HIP based overlay networks. HIP BONE instance can be used in HIP based overlay networks. HIP BONE instance
specifications define the exact format and content of the Overlay specifications define the exact format and content of the Overlay
Identifier parameter, the cases when the Overlay TTL parameter should Identifier parameter, the cases when the Overlay TTL parameter should
be used, and any additional behavior for each packet. be used, and any additional behavior for each packet.
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, all HIP
HIP messages that are sent via an overlay, or as a part of operations 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 any other means possible for preventing overlay instances and any other means possible for preventing
collisions SHOULD be used. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier / | Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding | / | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA; 980 ] Type 4592
Length Length of the Identifier in octets Length Length of the Identifier, in octets
Identifier The identifier value Identifier The identifier value
Padding 0-7 bytes of padding if needed Padding 0-7 bytes of padding if needed
Figure 8: Format of the OVERLAY_ID Parameter Figure 8: Format of the OVERLAY_ID Parameter
6.2. Overlay TTL 6.2. Overlay TTL
HIP packets sent in an overlay network MAY contain an Overlay Time- HIP packets sent in an overlay network MAY contain an Overlay Time-
to-live (OVERLAY_TTL) parameter whose TTL value is decremented on to-live (OVERLAY_TTL) parameter whose TTL value is decremented on
each overlay network hop. When a HIP host receives a HIP packet with each overlay network hop. When a HIP host receives a HIP packet with
an OVERLAY_TTL parameter, and the host is not the final recipient of an OVERLAY_TTL parameter, and the host is not the final recipient of
the packet, it MUST decrement the TTL value in the parameter by one the packet, it MUST decrement the TTL value in the parameter by one
before forwarding the packet. before forwarding the packet.
If the TTL value in a received HIP packet is zero, and the receiving If the TTL value in a received HIP packet is zero, and the receiving
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 NOTIFICATION error type
(value [TBD by IANA; 70]) to the sender of the original HIP packet. OVERLAY_TTL_EXCEEDED (value 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 [RFC6078] parameter (if one exists) of the packet whose TTL was
TTL exceeded. 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 using network byte order. 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 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 all the HIP nodes Section 5.2.1 of [RFC5201]) and therefore all the HIP nodes
forwarding a packet with this parameter 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
skipping to change at page 19, line 24 skipping to change at page 19, line 26
HIP BONE. HIP BONE.
9. IANA Considerations 9. IANA Considerations
This section is to be interpreted according to [RFC5226]. This section is to be interpreted according to [RFC5226].
This document updates the IANA Registry for HIP Parameter Types This document updates the IANA Registry for HIP Parameter Types
[RFC5201] by assigning HIP Parameter Type values for the new HIP [RFC5201] by assigning HIP Parameter Type values for the new HIP
Parameters OVERLAY_ID (defined in Section 6.1) and OVERLAY_TTL Parameters OVERLAY_ID (defined in Section 6.1) and OVERLAY_TTL
(defined in Section 6.2). This document also defines a new HIP (defined in Section 6.2). This document also defines a new HIP
Notify packet type [RFC5201] OVERLAY_TTL_EXCEEDED in Section 6.2. Notify Message Type [RFC5201], OVERLAY_TTL_EXCEEDED in Section 6.2.
This value is allocated in the error range.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
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., Ed., and T.
"Host Identity Protocol", RFC 5201, April 2008. Henderson, "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.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions Keranen, Ed., "Basic Host Identity Protocol (HIP)
for Traversal of Network Address Translators", RFC 5770, Extensions for Traversal of Network Address Translators",
April 2010. RFC 5770, April 2010.
[I-D.ietf-hip-hiccups] [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
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)", RFC 6078, January 2011.
Signaling (HICCUPS)", draft-ietf-hip-hiccups-02 (work in
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, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006. Protocol Architecture", RFC 4251, January 2006.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008. Rendezvous Extension", RFC 5204, April 2008.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", RFC 5205, (HIP) Domain Name System (DNS) Extensions", RFC 5205,
April 2008. April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- [RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko,
Host Mobility and Multihoming with the Host Identity "End-Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008. Protocol", RFC 5206, April 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
Identity Protocol with Legacy Applications", RFC 5338, Identity Protocol with Legacy Applications", RFC 5338,
September 2008. September 2008.
[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] [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)", Work in
draft-ietf-hip-native-api-12 (work in progress), Progress, January 2010.
January 2010.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] 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", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245, April
April 2010. 2010.
[I-D.ietf-p2psip-base] [P2PSIP-BASE]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) and H. Schulzrinne, "REsource LOcation And Discovery
Base Protocol", draft-ietf-p2psip-base-08 (work in (RELOAD) Base Protocol", Work in Progress, November 2010.
progress), March 2010.
[I-D.ietf-hip-reload-instance] [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)
Instance Specification for REsource LOcation And Discovery Instance Specification for REsource LOcation And Discovery
(RELOAD)", draft-ietf-hip-reload-instance-01 (work in (RELOAD)", Work in Progress, January 2011.
progress), March 2010.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com EMail: Gonzalo.Camarillo@ericsson.com
Pekka Nikander Pekka Nikander
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Pekka.Nikander@ericsson.com EMail: Pekka.Nikander@ericsson.com
Jani Hautakorpi Jani Hautakorpi
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Jani.Hautakorpi@ericsson.com EMail: Jani.Hautakorpi@ericsson.com
Ari Keranen Ari Keranen
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas Jorvas 02420
Finland Finland
Email: Ari.Keranen@ericsson.com EMail: Ari.Keranen@ericsson.com
Alan Johnston Alan Johnston
Avaya Avaya
St. Louis, MO 63124 St. Louis, MO 63124
Email: alan@sipstation.com EMail: alan.b.johnston@gmail.com
 End of changes. 95 change blocks. 
321 lines changed or deleted 316 lines changed or added

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