doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc6079.txt b/doc/rfc/rfc6079.txt
new file mode 100644
index 0000000..906665b
--- /dev/null
+++ b/doc/rfc/rfc6079.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      G. Camarillo
+Request for Comments: 6079                                   P. Nikander
+Category: Experimental                                     J. Hautakorpi
+ISSN: 2070-1721                                               A. Keranen
+                                                                Ericsson
+                                                             A. Johnston
+                                                                   Avaya
+                                                            January 2011
+
+
+                 HIP BONE: Host Identity Protocol (HIP)
+              Based Overlay Networking Environment (BONE)
+
+Abstract
+
+   This document specifies a framework to build HIP-based (Host Identity
+   Protocol) overlay networks.  This framework uses HIP to perform
+   connection management.  Other functions, such as data storage and
+   retrieval or overlay maintenance, are implemented using protocols
+   other than HIP.  These protocols are loosely referred to as "peer
+   protocols".
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al.             Experimental                      [Page 1]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................3
+   3. Background on HIP ...............................................4
+      3.1. ID/Locator Split ...........................................4
+           3.1.1. Identifier Format ...................................5
+           3.1.2. HIP Base Exchange ...................................5
+           3.1.3. Locator Management ..................................6
+      3.2. NAT Traversal ..............................................6
+      3.3. Security ...................................................7
+           3.3.1. DoS Protection ......................................7
+           3.3.2. Identifier Assignment and Authentication ............7
+           3.3.3. Connection Security .................................9
+      3.4. HIP Deployability and Legacy Applications ..................9
+   4. Framework Overview .............................................10
+   5. The HIP BONE Framework .........................................13
+      5.1. Node ID Assignment and Bootstrap ..........................13
+      5.2. Overlay Network Identification ............................14
+      5.3. Connection Establishment ..................................15
+      5.4. Lightweight Message Exchanges .............................15
+      5.5. HIP BONE Instantiation ....................................16
+   6. Overlay HIP Parameters .........................................17
+      6.1. Overlay Identifier ........................................17
+      6.2. Overlay TTL ...............................................17
+   7. Security Considerations ........................................18
+   8. Acknowledgements ...............................................19
+   9. IANA Considerations ............................................19
+   10. References ....................................................19
+      10.1. Normative References .....................................19
+      10.2. Informative References ...................................20
+
+
+
+
+
+Camarillo, et al.             Experimental                      [Page 2]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+1.  Introduction
+
+   The Host Identity Protocol (HIP) [RFC5201] defines a new name space
+   between the network and transport layers.  HIP provides upper layers
+   with mobility, multihoming, NAT (Network Address Translation)
+   traversal, and security functionality.  HIP implements the so-called
+   identifier/locator (ID/locator) split, which implies that IP
+   addresses are only used as locators, not as host identifiers.  This
+   split makes HIP a suitable protocol to build overlay networks that
+   implement identifier-based overlay routing over IP networks, which in
+   turn implement locator-based routing.
+
+   Using HIP-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 used by any peer protocol.
+   This keeps each peer protocol from defining primitives needed for
+   connection management (e.g., primitives to establish connections and
+   to tunnel messages through the overlay) and NAT traversal.  Having
+   this functionality at a lower layer allows multiple upper-layer
+   protocols to take advantage of it.
+
+   Additionally, having a solution that integrates mobility and
+   multihoming is useful in many scenarios.  Peer protocols do not
+   typically specify mobility and multihoming solutions.  Combining a
+   peer protocol including NAT traversal with a separate mobility
+   mechanism and a separate multihoming mechanism can easily lead to
+   unexpected (and unpleasant) interactions.
+
+   The remainder of this document is organized as follows.  Section 3
+   provides background information on HIP.  Section 4 gives an overview
+   of the HIP BONE (HIP-Based Overlay Networking Environment) framework
+   and architecture and Section 5 describes the framework in more
+   detail.  Finally, Section 6 introduces new HIP parameters for overlay
+   usage.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   The following terms are used in context of HIP BONEs:
+
+   Overlay network:  A network built on top of another network.  In case
+      of HIP BONEs, the underlying network is an IP network and the
+      overlay can be, e.g., a peer-to-peer (P2P) network.
+
+
+
+
+
+Camarillo, et al.             Experimental                      [Page 3]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   Peer protocol:  A protocol used by nodes in an overlay network for
+      performing, e.g., data storage and retrieval or overlay
+      maintenance.
+
+   HIP BONE instance:  A HIP-based overlay network that uses a
+      particular peer protocol and is based on the framework presented
+      in this document.
+
+   Node ID:  A value that uniquely identifies a node in an overlay
+      network.  The value is not usually human-friendly.  As an example,
+      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
+      address or an address and a port number) at which a host is known
+      to be reachable, for example, because there is an active HIP
+      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
+
+   This section provides background on HIP.  Given the tutorial nature
+   of this section, readers that are familiar with what HIP provides and
+   how HIP works may want to skip it.  All descriptions contain
+   references to the relevant HIP specifications where readers can find
+   detailed explanations on the different topics discussed in this
+   section.
+
+3.1.  ID/Locator Split
+
+   In an IP network, IP addresses typically serve two roles: they are
+   used as host identifiers and as host locators.  IP addresses are
+   locators because a given host's IP address indicates where in the
+   network that host is located.  IP networks route based on these
+   locators.  Additionally, IP addresses are used to identify remote
+   hosts.  The simultaneous use of IP addresses as host identifiers and
+   locators makes mobility and multihoming complicated.  For example,
+   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
+   remote host changes its IP address, the TCP connection will not
+   survive, since the transport layer identifier of the remote end of
+   the connection has changed.
+
+
+
+
+Camarillo, et al.             Experimental                      [Page 4]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   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
+   other hand, uses IP addresses only as locators and defines a new
+   identifier space.  This approach is referred to as the ID/locator
+   split and makes the implementation of mobility and multihoming more
+   natural.  In the previous example, the TCP connection would be bound
+   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
+   TCP connection is able to survive locator changes because the remote
+   host's identifier does not change.
+
+3.1.1.  Identifier Format
+
+   HIP uses 128-bit ORCHIDs (Overlay Routable Cryptographic Hash
+   Identifiers) [RFC4843] as identifiers.  ORCHIDs look like IPv6
+   addresses but cannot collide with regular IPv6 addresses because
+   ORCHID spaces are registered with the IANA.  That is, a portion of
+   the IPv6 address space is reserved for ORCHIDs.  The ORCHID
+   specification allows the creation of multiple disjoint identifier
+   spaces.  Each such space is identified by a separate Context
+   Identifier.  The Context Identifier can be either drawn implicitly
+   from the context the ORCHID is used in or carried explicitly in a
+   protocol.
+
+   HIP defines a native socket API [HIP-NATIVE-API] that applications
+   can use to establish and manage connections.  Additionally, HIP can
+   also be used through the traditional IPv4 and IPv6 TCP/IP socket
+   APIs.  Section 3.4 describes how an application using these
+   traditional APIs can make use of HIP.  Figure 1 shows all these APIs
+   between the application and the transport layers.
+
+            +-----------------------------------------+
+            |               Application               |
+            +----------------+------------------------+
+            | HIP Native API | Traditional Socket API |
+            +----------------+------------------------+
+            |             Transport Layer             |
+            +-----------------------------------------+
+
+                        Figure 1: HIP API
+
+3.1.2.  HIP Base Exchange
+
+   Typically, before two HIP hosts exchange upper-layer traffic, they
+   perform a four-way handshake that is referred to as the HIP base
+   exchange.  Figure 2 illustrates the HIP base exchange.  The initiator
+
+
+
+
+
+Camarillo, et al.             Experimental                      [Page 5]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   sends an I1 packet and receives an R1 packet from the responder.
+   After that, the initiator sends an I2 packet and receives an R2
+   packet from the responder.
+
+            Initiator                    Responder
+
+                |            I1             |
+                |-------------------------->|
+                |            R1             |
+                |<--------------------------|
+                |            I2             |
+                |-------------------------->|
+                |            R2             |
+                |<--------------------------|
+
+                 Figure 2: HIP Base Exchange
+
+   Of course, the initiator needs the responder's locator (or locators)
+   in order to send its I1 packet.  The initiator can obtain locators
+   for the responder in multiple ways.  For example, according to the
+   current HIP specifications the initiator can get the locators
+   directly from the DNS [RFC5205] or indirectly by sending packets
+   through a HIP rendezvous server [RFC5204].  However, HIP is an open-
+   ended architecture.  The HIP architecture allows the locators to be
+   obtained by any means (e.g., from packets traversing an overlay
+   network or as part of the candidate address collection process in a
+   NAT traversal scenario).
+
+3.1.3.  Locator Management
+
+   Once a HIP connection between two hosts has been established with a
+   HIP base exchange, the hosts can start exchanging higher-layer
+   traffic.  If any of the hosts changes its set of locators, it runs an
+   update exchange [RFC5206], which consists of three messages.  If a
+   host is multihomed, it simply provides more than one locator in its
+   exchanges.  However, if both of the endpoints move at the same time,
+   or through some other reason both lose track of the peers' currently
+   active locators, they need to resort to using a rendezvous server or
+   getting new peer locators by some other means.
+
+3.2.  NAT Traversal
+
+   HIP's NAT traversal mechanism [RFC5770] is based on ICE (Interactive
+   Connectivity Establishment) [RFC5245].  Hosts gather address
+   candidates and, as part of the HIP base exchange, hosts perform an
+   ICE offer/answer exchange where they exchange their respective
+
+
+
+
+
+Camarillo, et al.             Experimental                      [Page 6]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   address candidates.  Hosts perform end-to-end STUN-based [RFC5389]
+   connectivity checks in order to discover which address candidate
+   pairs yield connectivity.
+
+   Even though, architecturally, HIP lies below the transport layer
+   (i.e., HIP packets are carried directly in IP packets), in the
+   presence 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).
+
+3.3.  Security
+
+   Security is an essential part of HIP.  The following sections
+   describe the security-related functionality provided by HIP.
+
+3.3.1.  DoS Protection
+
+   HIP provides protection against DoS (denial-of-service) attacks by
+   having initiators resolve a cryptographic puzzle before the responder
+   stores any state.  On receiving an I1 packet, a responder sends a
+   pre-generated R1 packet that contains a cryptographic puzzle and
+   deletes all the state associated with the processing of this I1
+   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
+   be adjusted so that, if a receiver is under a DoS attack, it can
+   increase the difficulty of its puzzles.
+
+   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
+   solution is correct.  If it is, the receiver processes the I2 packet.
+   Otherwise, it silently discards it.
+
+   In an overlay scenario, there are multiple ways in which this
+   mechanism can be utilized within the overlay.  One possibility is to
+   cache the pre-generated R1 packets within the overlay and let the
+   overlay directly respond with R1s to I1s.  In that way, the responder
+   is not bothered at all until the initiator sends an I2 packet, with
+   the puzzle solution.  Furthermore, a more sophisticated overlay could
+   verify that an I2 packet has a correctly solved puzzle before
+   forwarding the packet to the responder.
+
+3.3.2.  Identifier Assignment and Authentication
+
+   As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main
+   representation for identifiers.  Potentially, HIP can use different
+   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
+   completely avoid this type of collision is to have a central
+
+
+
+Camarillo, et al.             Experimental                      [Page 7]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   authority generate and assign ORCHIDs to nodes.  To secure the
+   binding between ORCHIDs and any higher-layer identifiers, every time
+   the central authority assigns an ORCHID to a node, it also generates
+   and signs a certificate stating who is the owner of the ORCHID.  The
+   owner of the ORCHID then includes the corresponding certificate in
+   its R1 (when acting as responder) and I2 packets (when acting
+   initiator) to prove that it is actually allowed to use the ORCHID
+   and, implicitly, the associated public key.
+
+   Having a central authority works well to completely avoid collisions.
+   However, having a central authority is impractical in some scenarios.
+   As defined today, HIP systems generally use a self-certifying ORCHID
+   type called HIT (Host Identity Tag) that does not require a central
+   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
+   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
+   second-preimage resistance property of hash functions.  That is,
+   given a fixed public key K1, finding a different public key K2 such
+   that hash(K1) = hash(K2) is computationally very hard.  Optimally, a
+   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
+   expected to take in the average 2^99 operations.  Given that each
+   operation requires the attacker to generate a new key pair, the
+   attack is fully impractical with current technology and techniques
+   (see [RFC4843]).
+
+   HIP nodes using HITs as ORCHIDs do not typically use certificates
+   during their base exchanges.  Instead, they use a leap-of-faith
+   mechanism, similar to the Secure Shell (SSH) protocol [RFC4251],
+   whereby a node somehow authenticates remote nodes the first time they
+   connect to it and, then, remembers their public keys.  While user-
+   assisted leap-of-faith mechanism (such as in SSH) can be used to
+   facilitate a human-operated offline path (such as a telephone call),
+   automated leap-of-faith mechanisms can be combined with a reputation
+   management system to create an incentive to behave.  However, such
+   considerations go well beyond the current HIP architecture and even
+   beyond this proposal.  For the purposes of the present document, we
+   merely want to point out that, architecturally, HIP supports both
+   self-generated opportunistic identifiers and administratively
+   assigned ones.
+
+
+
+
+
+
+
+
+
+Camarillo, et al.             Experimental                      [Page 8]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+3.3.3.  Connection Security
+
+   Once two nodes complete a base exchange between them, the traffic
+   they exchange is encrypted and integrity protected.  The security
+   mechanism used to protect the traffic is IPsec Encapsulating Security
+   Payload (ESP) [RFC5202].  However, there is ongoing work to specify
+   how to use other protection mechanisms.
+
+3.4.  HIP Deployability and Legacy Applications
+
+   As discussed earlier, HIP defines a native socket API [HIP-NATIVE-
+   API] that applications can use to establish and manage connections.
+   New applications can implement this API to get full advantage of HIP.
+   However, in most cases, legacy (i.e., non-HIP-aware) applications
+   [RFC5338] can use HIP through the traditional IPv4 and IPv6 socket
+   APIs.
+
+   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 passes the remote host's ORCHID (which was also stored in
+   the DNS) to the legacy application.  At the same time, the DNS
+   resolver stores the remote host's IP address internally at the HIP
+   module.  Since the ORCHID looks like an IPv6 address, the legacy
+   application treats it 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 legacy application intercepts this call somehow
+   (e.g., using an 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 legacy application) towards the IP address
+   corresponding to the ORCHID.  This mechanism works well in almost all
+   cases.  However, applications involving referrals (i.e., passing of
+   IPv6 addresses between applications) present issues, which are
+   discussed in Section 5 below.  Additionally, management applications
+   that care about the exact IP address format may not work well with
+   such a straightforward approach.
+
+   In order to make HIP work through the traditional IPv4 socket API,
+   the HIP module passes an LSI (Local Scope Identifier), instead of a
+   regular IPv4 address, to the legacy IPv4 application.  The LSI looks
+   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
+   module intercepts it and replaces the LSI with its corresponding
+   ORCHID.  Therefore, LSIs always have local scope.  They do not have
+   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
+   possible to rewrite the application level packets to use ORCHIDs
+
+
+
+
+
+Camarillo, et al.             Experimental                      [Page 9]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   instead of LSIs, it may be hard to make IPv4 referrals work in
+   Internet-wide settings.  IPv4 LSIs have been successfully used in
+   existing HIP deployments within a single corporate network.
+
+4.  Framework Overview
+
+   The HIP BONE framework combines HIP with different peer protocols to
+   provide robust and secure overlay network solutions.
+
+   Many overlays typically require three types of operations:
+
+   o  overlay maintenance,
+   o  data storage and retrieval, and
+   o  connection management.
+
+   Overlay maintenance operations deal with nodes joining and leaving
+   the overlay and with the maintenance of the overlay's routing tables.
+   Data storage and retrieval operations deal with nodes storing,
+   retrieving, and removing information in or from the overlay.
+   Connection management operations deal with the establishment of
+   connections and the exchange of lightweight messages among the nodes
+   of the overlay, potentially in the presence of NATs.
+
+   The HIP BONE framework uses HIP to perform connection management.
+   Data storage and retrieval and overlay maintenance are to be
+   implemented using protocols other than HIP.  For lack of a better
+   name, these protocols are referred to as peer protocols.
+
+   One way to depict the relationship between the peer protocol and HIP
+   modules is shown in Figure 3.  The peer protocol module implements
+   the overlay construction and maintenance features, and possibly
+   storage (if the particular protocol supports such a feature).  The
+   HIP module consults the peer protocol's overlay topology part to make
+   routing decisions, and the peer protocol uses HIP for connection
+   management and sending peer protocol messages to other hosts.  The
+   HIP BONE API that applications use is a combination of the HIP Native
+   API and traditional socket API (as shown in Figure 1) with any
+   additional API a particular instance implementation provides.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al.             Experimental                     [Page 10]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+                       Application
+            -------------------------------- HIP BONE API
+             +---+   +--------------------+
+             |   |   |    Peer Protocol   |
+             |   |   +--------+ +---------+
+             |   |<->|Topology| |(Storage)|
+             |   |   +---------+----------+
+             |   |             ^
+             |   |             v
+             |   +------------------------+
+             |                HIP         |
+             +----------------------------+
+
+            Figure 3: HIP with Peer Protocol
+
+   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 itself consists of the HIP signaling protocol and one or more
+   data transport protocols; see Figure 5.  The HIP signaling packets
+   and the data transport packets can take different routes.  In the HIP
+   BONE scenarios, the HIP signaling packets are typically first routed
+   through the overlay and then directly (if possible), while the data
+   transport packets are typically routed only directly between the
+   endpoints.
+
+            +--------------------------------------+
+            |    Transport (using HITs or LSIs)    |
+            +--------------------------------------+
+            |                 HIP                  |
+            +------------------+-------------------+
+            |      IPv4        |       IPv6        |
+            +------------------+-------------------+
+
+                 Figure 4: HIP as a Thin Waist
+
+            +------------------+-------------------+
+            |  HIP signaling   |  data transports  |
+            +------------------+-------------------+
+
+                 Figure 5: HIP Layer Structure
+
+   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
+   messages.  This is a similar relationship that an IP routing
+   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
+   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
+
+
+
+Camarillo, et al.             Experimental                     [Page 11]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   according to the information in the routing tables.  The peer
+   protocols are used to exchange routing information based on Node IDs
+   and to construct the routing tables.
+
+   Architecturally, routing tables are located between the peer protocol
+   and HIP, as shown in Figure 6.  The peer protocol constructs the
+   routing table and keeps it updated.  The HIP layer accesses the
+   routing table in order to make routing decisions.  The bootstrap of a
+   HIP BONE overlay does not create circular dependencies between the
+   peer protocol (which needs to use HIP to establish connections with
+   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
+   of an IP network does not create circular dependencies between OSPF
+   and IP.  The first connections established by the peer protocol are
+   with nodes whose locators are known.  HIP establishes those
+   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
+   rendezvous service for those connections.
+
+            +--------------------------------------+
+            |            Peer protocol             |
+            +--------------------------------------+
+            |            Routing table             |
+            +--------------------------------------+
+            |                 HIP                  |
+            +--------------------------------------+
+
+                    Figure 6: Routing Tables
+
+   It is possible that different overlays use different routing table
+   formats.  For example, the structure of the routing tables of two
+   overlays based on different DHTs (Distributed Hash Tables) may be
+   very different.  In order to make routing decisions, the HIP layer
+   needs to convert the routing table generated by the peer protocol
+   into a forwarding table that allows the HIP layer select a next hop
+   for any packet being routed.
+
+   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
+   better secure routing table maintenance and to protect against
+   chosen-peer-ID attacks.
+
+   HIP BONE provides quite a lot of flexibility with regards to how to
+   arrange the different protocols in detail.  Figure 7 shows one
+   potential stack structure.
+
+
+
+
+
+
+Camarillo, et al.             Experimental                     [Page 12]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+            +-----------------------+--------------+
+            | peer protocols        |     media    |
+            +------------------+----+--------------+
+            | HIP signaling    |   data transport  |
+            |                                      |
+            +------------------+-------------------+
+            | NAT    | non-NAT |                   |
+            |                  |                   |
+            |      IPv4        |       IPv6        |
+            +------------------+-------------------+
+
+          Figure 7: Example HIP BONE Stack Structure
+
+5.  The HIP BONE Framework
+
+   HIP BONE is a generic framework that allows the use of different peer
+   protocols.  A particular HIP BONE instance uses a particular peer
+   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
+   specification.  Section 5.5 discusses what details need to be
+   specified by HIP BONE instance specifications.  For example, the HIP
+   BONE instance specification for RELOAD [P2PSIP-BASE] is specified in
+   [HIP-RELOAD-INSTANCE].
+
+5.1.  Node ID Assignment and Bootstrap
+
+   Nodes in an overlay are primarily identified by their Node IDs.
+   Overlays typically have an enrollment server that can generate Node
+   IDs, or at least some part of the Node ID, and sign certificates.  A
+   certificate generated by an enrollment server authorizes a particular
+   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
+   instance specification.
+
+   The enrollment server of an overlay using HITs derived from public
+   keys as Node IDs could just authorize users to use the public keys
+   and HITs associated to their nodes.  Such a Node ID has the same
+   self-certifying property as HITs and the Node ID can also be used in
+   the HIP and legacy APIs as an ORCHID.  This works well as long as the
+   enrollment server is the one generating the public/private key pairs
+   for all those nodes.  If the enrollment server authorizes users to
+   use HITs that are generated directly by the nodes themselves, the
+   system is open to a type of chosen-peer-ID attack.
+
+   If the overlay network or peer protocol has more specific
+   requirements for the Node ID value that prevent using HITs derived
+   from public keys, each host will need a certificate (e.g., in their
+   HIP base exchanges) provided by the enrollment server to prove that
+
+
+
+Camarillo, et al.             Experimental                     [Page 13]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   they are authorized to use a particular identifier in the overlay.
+   Depending on how the certificates are constructed, they typically
+   also need to contain the host's self-generated public key.  Depending
+   on how the Node IDs and public keys are attributed, different
+   scenarios become possible.  For example, the Node IDs may be
+   attributed to users, there may be user public key identifiers, and
+   there may be separate host public key identifiers.  Authorization
+   certificates can be used to bind the different types of identifiers
+   together.
+
+   HITs, as defined in [RFC5201], always start with the ORCHID prefix.
+   Therefore, there are 100 bits left in the HIT for different Node ID
+   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
+   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
+   this context, most of the applications are assumed to be HIP aware
+   and able to use a more advanced API supporting full 128-bit
+   identifiers.  Even larger address spaces could be supported with an
+   additional HIP parameter giving the source and destination Node IDs,
+   but defining such a parameter, if needed, is left for future
+   documents.
+
+   Bootstrap issues, such as how to locate an enrollment or a bootstrap
+   server, belong to the peer protocol.
+
+5.2.  Overlay Network Identification
+
+   It is possible for a HIP host to participate simultaneously in
+   multiple different overlay networks.  It is also possible that some
+   HIP traffic is not intended to be forwarded over an overlay.
+   Therefore, a host needs to know to which overlay an incoming HIP
+   message belongs and the outgoing HIP messages need to be labeled as
+   belonging to a certain overlay.  This document specifies a new
+   generic HIP parameter (in Section 6.1) for the purpose of directing
+   HIP messages to the right overlay.
+
+   In addition, an application using HIP BONE needs to define, either
+   implicitly or explicitly, the overlay to use for communication.
+   Explicit configuration can happen, e.g., by configuring certain local
+   HITs to be bound to certain overlays or by defining the overlay
+   identifier using advanced HIP socket options or other suitable APIs.
+   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
+   messages without a valid locator are sent.  The specification for how
+   to implement this coordination for locally originated messages is out
+   of scope for this document.
+
+
+
+
+Camarillo, et al.             Experimental                     [Page 14]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+5.3.  Connection Establishment
+
+   Nodes in an overlay need to establish connections with other nodes in
+   different cases.  For example, a node typically has connections to
+   the nodes in its forwarding table.  Nodes also need to establish
+   connections with other nodes in order to exchange application-layer
+   messages.
+
+   As discussed earlier, HIP uses the base exchange to establish
+   connections.  A HIP endpoint (the initiator) initiates a HIP base
+   exchange with a remote endpoint by sending an I1 packet.  The
+   initiator sends the I1 packet to the remote endpoint's locator.
+   Initiators that do not have any locator for the remote endpoint need
+   to use a rendezvous service.  Traditionally, a HIP rendezvous server
+   [RFC5204] has provided such a rendezvous service.  In HIP BONE, the
+   overlay itself provides the rendezvous service.
+
+   Therefore, in HIP BONE, a node uses an I1 packet (as usual) to
+   establish a connection with another node in the overlay.  Nodes in
+   the overlay forward I1 packets in a hop-by-hop fashion according to
+   the overlay's routing table towards its destination.  This way, the
+   overlay provides a rendezvous service between the nodes establishing
+   the connection.  If the overlay nodes have active connections with
+   other nodes in their forwarding tables and if those connections are
+   protected (typically with IPsec ESP), I1 packets may be sent over
+   protected connections between nodes.  Alternatively, if there is no
+   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
+   directly, in a similar fashion to how I1 packets are today forwarded
+   by a HIP rendezvous server.
+
+   Since HIP supports NAT traversal, a HIP base exchange over the
+   overlay will perform an ICE [RFC5245] offer/answer exchange between
+   the nodes that are establishing the connection.  In order to perform
+   this exchange, the nodes need to first gather candidate addresses.
+   Which nodes can be used to obtain reflexive address candidates and
+   which ones can be used to obtain relayed candidates is defined by the
+   peer protocol.
+
+5.4.  Lightweight Message Exchanges
+
+   In some cases, nodes need to perform a lightweight query to another
+   node (e.g., a request followed by a single response).  In this
+   situation, establishing a connection using the mechanisms in 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 query and another
+   one with the response to the query.  The payload of such HIP packets
+   is integrity protected [RFC6078].
+
+
+
+Camarillo, et al.             Experimental                     [Page 15]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   Nodes in the overlay forward this HIP packet in a hop-by-hop fashion
+   according to the overlay's routing table towards its destination,
+   typically through the protected connections established between them.
+   Again, the overlay acts as a rendezvous server between the nodes
+   exchanging the messages.
+
+5.5.  HIP BONE Instantiation
+
+   As discussed in Section 5, HIP BONE is a generic framework that
+   allows using different peer protocols.  A particular HIP BONE
+   instance uses a particular peer protocol.  The details on how to
+   implement a HIP BONE using a given peer protocol need to be specified
+   in a, so-called, HIP BONE instance specification.  A HIP BONE
+   instance specification needs to define, minimally:
+
+   o  the peer protocol to be used,
+   o  what kind of Node IDs are used and how they are derived,
+   o  which peer protocol primitives trigger HIP messages, and
+   o  how the overlay identifier is generated.
+
+   Additionally, a HIP BONE instance specification may need to specify
+   other details that are specific to the peer protocol used.
+
+   As an example, the HIP BONE instance specification for RELOAD
+   [P2PSIP-BASE] is specified in [HIP-RELOAD-INSTANCE].
+
+   The areas not covered by a particular HIP BONE instance specification
+   are specified by the peer protocol or elsewhere.  These areas
+   include:
+
+   o  the algorithm to create the overlay (e.g., a DHT),
+   o  overlay maintenance functions,
+   o  data storage and retrieval functions,
+   o  the process for obtaining a Node ID,
+   o  bootstrap function, and
+   o  how to select STUN and TURN servers for the candidate address
+      collection process in NAT traversal scenarios.
+
+   Note that the border between a HIP BONE instance specification and a
+   peer protocol specifications is fuzzy.  Depending on how generic the
+   specification of a given peer protocol is, its associated HIP BONE
+   instance specification may need to specify more or less details.
+   Also, a HIP BONE instance specification may leave certain areas
+   unspecified in order to leave their configuration up to each
+   particular overlay.
+
+
+
+
+
+
+Camarillo, et al.             Experimental                     [Page 16]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+6.  Overlay HIP Parameters
+
+   This section defines the generic format and protocol behavior for the
+   Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that
+   can be used in HIP based overlay networks.  HIP BONE instance
+   specifications define the exact format and content of the Overlay
+   Identifier parameter, the cases when the Overlay TTL parameter should
+   be used, and any additional behavior for each packet.
+
+6.1.  Overlay Identifier
+
+   To identify to which overlay network a HIP message belongs, all 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
+   with the identifier of the corresponding overlay network.  Instance
+   specifications define how the identifier is generated for different
+   types of overlay networks.  The generation mechanism MUST be such
+   that it is unlikely to generate the same identifier for two different
+   overlay instances and any other means possible for preventing
+   collisions SHOULD be used.
+
+   The generic format of the OVERLAY_ID parameter is shown in Figure 8.
+   Instance specifications define valid length for the parameter and how
+   the identifier values are generated.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Type              |             Length            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           Identifier                          /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                                               |    Padding    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type        4592
+      Length      Length of the Identifier, in octets
+      Identifier  The identifier value
+      Padding     0-7 bytes of padding if needed
+
+                 Figure 8: Format of the OVERLAY_ID Parameter
+
+6.2.  Overlay TTL
+
+   HIP packets sent in an overlay network MAY contain an Overlay Time-
+   to-live (OVERLAY_TTL) parameter whose TTL value is decremented on
+   each overlay network hop.  When a HIP host receives a HIP packet with
+
+
+
+
+Camarillo, et al.             Experimental                     [Page 17]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   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
+   before forwarding the packet.
+
+   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 SHOULD send HIP Notify packet with NOTIFICATION error type
+   OVERLAY_TTL_EXCEEDED (value 70) to the sender of the original HIP
+   packet.
+
+   The Notification Data field for the OVERLAY_TTL_EXCEEDED
+   notifications SHOULD contain the HIP header and the TRANSACTION_ID
+   [RFC6078] parameter (if one exists) of the packet whose TTL was
+   exceeded.
+
+   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
+   it is encoded as an unsigned integer using network byte order.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Type              |             Length            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             TTL               |            Reserved           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type        64011
+      Length      4
+      TTL         The Time-to-Live value
+      Reserved    Reserved for future use
+
+                Figure 9: Format of the OVERLAY_TTL Parameter
+
+   The type of the OVERLAY_TTL parameter is critical (as defined in
+   Section 5.2.1 of [RFC5201]) and therefore all the HIP nodes
+   forwarding a packet with this parameter MUST support it.  If the
+   parameter is used in a scenario where the final recipient does not
+   support the parameter, the parameter SHOULD be removed before
+   forwarding the packet to the final recipient.
+
+7.  Security Considerations
+
+   This document provides a high-level framework to build HIP-based
+   overlays.  The security properties of HIP and its extensions used in
+   this framework are discussed in their respective specifications.
+   Those security properties can be affected by the way HIP is used in a
+   particular overlay.  However, those properties are mostly affected by
+
+
+
+Camarillo, et al.             Experimental                     [Page 18]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   the design decisions made to build a particular overlay; not so much
+   by the high-level framework specified in this document.  Such design
+   decisions are typically documented in a HIP BONE instance
+   specification, which describes the security properties of the
+   resulting overlay.
+
+8.  Acknowledgements
+
+   HIP BONE is based on ideas coming from conversations and discussions
+   with a number of people in the HIP and P2PSIP communities.  In
+   particular, Philip Matthews, Eric Cooper, Joakim Koskela, Thomas
+   Henderson, Bruce Lowekamp, and Miika Komu provided useful input on
+   HIP BONE.
+
+9.  IANA Considerations
+
+   This section is to be interpreted according to [RFC5226].
+
+   This document updates the IANA Registry for HIP Parameter Types
+   [RFC5201] by assigning HIP Parameter Type values for the new HIP
+   Parameters OVERLAY_ID (defined in Section 6.1) and OVERLAY_TTL
+   (defined in Section 6.2).  This document also defines a new HIP
+   Notify Message Type [RFC5201], OVERLAY_TTL_EXCEEDED in Section 6.2.
+   This value is allocated in the error range.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4843]  Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
+              for Overlay Routable Cryptographic Hash Identifiers
+              (ORCHID)", RFC 4843, April 2007.
+
+   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
+              Henderson, "Host Identity Protocol", RFC 5201, April 2008.
+
+   [RFC5202]  Jokela, P., Moskowitz, R., and P. Nikander, "Using the
+              Encapsulating Security Payload (ESP) Transport Format with
+              the Host Identity Protocol (HIP)", RFC 5202, April 2008.
+
+   [RFC5770]  Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
+              Keranen, Ed., "Basic Host Identity Protocol (HIP)
+              Extensions for Traversal of Network Address Translators",
+              RFC 5770, April 2010.
+
+
+
+
+Camarillo, et al.             Experimental                     [Page 19]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   [RFC6078]  Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
+              Immediate Carriage and Conveyance of Upper-Layer Protocol
+              Signaling (HICCUPS)", RFC 6078, January 2011.
+
+10.2.  Informative References
+
+   [RFC4251]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+              Protocol Architecture", RFC 4251, January 2006.
+
+   [RFC5204]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
+              Rendezvous Extension", RFC 5204, April 2008.
+
+   [RFC5205]  Nikander, P. and J. Laganier, "Host Identity Protocol
+              (HIP) Domain Name System (DNS) Extensions", RFC 5205,
+              April 2008.
+
+   [RFC5206]  Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko,
+              "End-Host Mobility and Multihoming with the Host Identity
+              Protocol", RFC 5206, April 2008.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [RFC5338]  Henderson, T., Nikander, P., and M. Komu, "Using the Host
+              Identity Protocol with Legacy Applications", RFC 5338,
+              September 2008.
+
+   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+              October 2008.
+
+   [HIP-NATIVE-API]
+              Komu, M. and T. Henderson, "Basic Socket Interface
+              Extensions for Host Identity Protocol (HIP)", Work in
+              Progress, January 2010.
+
+   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
+              (ICE): A Protocol for Network Address Translator (NAT)
+              Traversal for Offer/Answer Protocols", RFC 5245, April
+              2010.
+
+   [P2PSIP-BASE]
+              Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
+              and H. Schulzrinne, "REsource LOcation And Discovery
+              (RELOAD) Base Protocol", Work in Progress, November 2010.
+
+
+
+
+
+Camarillo, et al.             Experimental                     [Page 20]
+
+RFC 6079                        HIP BONE                    January 2011
+
+
+   [HIP-RELOAD-INSTANCE]
+              Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity
+              Protocol-Based Overlay Networking Environment (HIP BONE)
+              Instance Specification for REsource LOcation And Discovery
+              (RELOAD)", Work in Progress, January 2011.
+
+Authors' Addresses
+
+   Gonzalo Camarillo
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   EMail: Gonzalo.Camarillo@ericsson.com
+
+   Pekka Nikander
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   EMail: Pekka.Nikander@ericsson.com
+
+   Jani Hautakorpi
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   EMail: Jani.Hautakorpi@ericsson.com
+
+   Ari Keranen
+   Ericsson
+   Hirsalantie 11
+   Jorvas 02420
+   Finland
+
+   EMail: Ari.Keranen@ericsson.com
+
+   Alan Johnston
+   Avaya
+   St. Louis, MO  63124
+
+   EMail: alan.b.johnston@gmail.com
+
+
+
+
+
+
+Camarillo, et al.             Experimental                     [Page 21]
+