HIP Working Group G. Camarillo Internet-Draft P. Nikander Expires: June 23, 2008 J. Hautakorpi Ericsson December 21, 2007 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment draft-camarillo-hip-bone-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 23, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies a framework to build HIP (Host Identity Protocol)-based 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. Camarillo, et al. Expires June 23, 2008 [Page 1] Internet-Draft HIP BONE December 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 3 2.1. ID/locator Split . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Identifier Format . . . . . . . . . . . . . . . . . . 4 2.1.2. HIP Base Exchange . . . . . . . . . . . . . . . . . . 4 2.1.3. Locator Management . . . . . . . . . . . . . . . . . . 5 2.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 6 2.3.2. Identifier Assignment and Authentication . . . . . . . 6 2.3.3. Connection Security . . . . . . . . . . . . . . . . . 7 2.4. HIP Deployability and Legacy Applications . . . . . . . . 7 3. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 8 3.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 8 3.2. Connection Establishment . . . . . . . . . . . . . . . . . 9 3.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 10 4. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 10 5. Relation of HIP BONE with P2PSIP . . . . . . . . . . . . . . . 11 6. Architectural Considerations . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Camarillo, et al. Expires June 23, 2008 [Page 2] Internet-Draft HIP BONE December 2007 1. Introduction The Host Identity Protocol (HIP) [I-D.ietf-hip-base] 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/location 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. The remainder of this document is organized as follows. Section 2 provides background information on HIP. Section 3 described the HIP BONE (HIP-Based Overlay Networking Environment) framework. Section 4 discusses some of the advantages derived from using the HIP BONE framework. Section 5 briefly explores the relationship of this document to the efforts in the IETF P2PSIP Working Group. Finally, before the customary sections, Section 6 attempts to put the presented proposal into a larger architectural context. 2. 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. 2.1. ID/locator Split In an IP network, IP addresses typically serve two roles: they are used as host identifiers and locators. IP addresses are locators because a given host's IP address indicates where in the network that host is. 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 is gone. 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 as only locators and defines a new Camarillo, et al. Expires June 23, 2008 [Page 3] Internet-Draft HIP BONE December 2007 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. 2.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 of ORCHID use or carried explicitly in a protocol. HIP defines a native socket API [I-D.ietf-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 2.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 2.1.2. HIP Base Exchange Before two HIP hosts exchange upper-layer traffic, they to perform a four-way handshake that is referred to as the HIP base exchange. Figure 2 illustrates the HIP base exchange. The initiator 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. Camarillo, et al. Expires June 23, 2008 [Page 4] Internet-Draft HIP BONE December 2007 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 locactors directly from the DNS [I-D.ietf-hip-dns] or indirectly by sending packets through a HIP rendezvous server [I-D.ietf-hip-rvs]. However, as an architecture HIP is open ended, and allows the locators to be obtained by any means (e.g., from packets traversing an overlay network or as part of candidate address collection in a NAT traversal scenario). 2.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 [I-D.ietf-hip-mm], 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 end points 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. 2.2. NAT Traversal HIP's NAT traversal mechanism is based on ICE (Interactive Connectivity Establishment) [I-D.ietf-mmusic-ice]. Hosts gather address candidates and, as part of the HIP base exchange, hosts perform an ICE offer/answer exchange where they exchange their respective address candidates. Hosts perform end-to-end STUN [I-D.ietf-behave-rfc3489bis] based 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 presence of NATs, HIP sometimes needs to be tunneled in a transport protocol Camarillo, et al. Expires June 23, 2008 [Page 5] Internet-Draft HIP BONE December 2007 (i.e., HIP packets are carried by a transport protocol such as UDP). 2.3. Security Security is an essential part of HIP. The following sections describe the security-related functionality provided by HIP. 2.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. 2.3.2. Identifier Assignment and Authentication As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main representation 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 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 Camarillo, et al. Expires June 23, 2008 [Page 6] Internet-Draft HIP BONE December 2007 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 completely impractical (see [RFC4843]). HIP nodes using HITs as ORCHIDs do not typically use certificates during their base exchanges. Instead, the use a leap-of-faith mechanism, similar to SSH, whereby a node authenticates somehow remote nodes the first time they connect it and, then, remembers their public keys. While user-assisted leap-of-faith (such as in SSH) can be used to facilitate a human-operated offline path (such as a telephone call), automated leap-of-faith could 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. 2.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 ESP [I-D.ietf-hip-esp]. However, there is ongoing work to specify how to use different protection mechanisms. 2.4. HIP Deployability and Legacy Applications As discussed earlier, HIP defines a native socket API [I-D.ietf-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 [I-D.ietf-hip-applications] can use HIP through the traditional IPv4 and IPv6 socket APIs. The idea is that when a legacy IPv6 application tries and obtains a remote host's IP address (e.g., by querying the DNS) the DNS respolver 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 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) Camarillo, et al. Expires June 23, 2008 [Page 7] Internet-Draft HIP BONE December 2007 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, to be discussed in Section 3 below. Additionally, management applications that care about the exact IP address format may not work well with such straigthforward 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 instead of LSIs, it may be hard to make IPv4 referrals work in Internet-wide settings. IPv4 LSIs have been succesfully used in existing HIP deployments within a single corporate network. 3. The HIP BONE Framework An overlay typically requires three types of operations: overlay maintenance, data storage and retrieval, and 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. 3.1. Peer ID Assignment and Bootstrap Nodes in an overlay are primarily identified by their Peer IDs. (Note that the Peer ID concept here is a peer-layer protocol concept, Camarillo, et al. Expires June 23, 2008 [Page 8] Internet-Draft HIP BONE December 2007 distinct from the HIP-layer node identifiers. Peer IDs may be long, may have some structure, and may consist of multiple parts.) Overlays typically have an enrollment server that can generate Peer IDs, or at least some part of the Peer ID, and sign certificates. A certificate generated by an enrollment server authorizes a particular user to use a particular Peer ID in a particular overlay. The way users and overlays are identified and the format for Peer IDs are defined by the peer protocol. The enrollment server of an overlay that were to use plain public keys as Peer IDs could just authorize users to use the public keys and HITs associated to their nodes. 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. However, in some cases it is impractical to have the enrollment server generate public/private key pairs for devices. In these cases, the enrollment server simply generates Peer IDs whose format is defined by the peer protocol used in the overlay. Since HIP needs ORCHIDs (and not any type of Peer ID) to work, hosts in the overlay will transform their Peer IDs into ORCHIDs, for example, by taking a hash of the Peer IDs or taking a hash of the Peer ID and the public key. That is a similar process to the one a host follows to generate a HIT from a public key. In such scenarios, each host will need a certificate (e.g., in their HIP base exchanges) provided by the enrollment server to prove that they are authorized to use a particular ORCHID 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 Peer IDs and public keys are attributed, different scenarios become possible. For example, the Peer IDs may be attributed to users, there may be user public key identifiers, and there may be separate host public key identifiers. Authorisation certificates can be used to bind the different types of identifiers together. Bootstrap issues such as how to locate an enrollment or a bootstrap server belong to the peer protocol. 3.2. Connection Establishment Nodes in an overlay need to establish connection with other nodes in different cases. For example, a node typically has connections to the nodes in its finger table. Nodes also need to establish connections with other nodes in order to exchange application-layer messages. Camarillo, et al. Expires June 23, 2008 [Page 9] Internet-Draft HIP BONE December 2007 As discussed earlier, HIP uses the base exchange to establish connections. Therefore, a node uses an I1 packet 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. If the overlay nodes have active connections with other nodes in their finger tables and if those connections are protected (typically with IPsec ESP), I1 packets may be sent over protected connections between nodes. Alternatively, if there no such an active connection but the sending peer node 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 the HIP RVS service. Since HIP supports NAT traversal, a HIP base exchange over the overlay will perform an ICE 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. 3.3. Lightweight Message Exchanges In some cases, nodes need to perform a lightweight query to another node. In this situation, establishing a connection using the mechanisms in Section 3.2 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 packet is integrity protected. 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. 4. Advantages of Using HIP BONE Using 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 Camarillo, et al. Expires June 23, 2008 [Page 10] Internet-Draft HIP BONE December 2007 mechanism and a separate multihoming mechanism can easily lead to unexpected (and unpleasant) interactions. 5. Relation of HIP BONE with P2PSIP At IETF 71, the P2PSIP WG will decide whether or not HIP will be included in the solution standardized by the WG. The following are two of the most obvious potential outcomes: 1. the WG decides to use HIP to implement connection management. 2. the WG decides not to use HIP. However, the peer protocol standardized by the WG is kept functionally and specification wise reasonably modular so that the HIP community can use the peer protocol minus the connection management and NAT traversal modules to experiment with HIP-based overlays. Note that, at present, this is the case with several peer protocols. 6. Architectural Considerations Architecturally, HIP can be considered to create a new thin "waist" layer on the top of the IPv4 and IPv6 networks; see Figure 3. The HIP layer itself consist of the HIP signalling protocol and one or more data transport protocols; see Figure 4. The HIP signalling packets and the data transport packets can take different routes. In the HIP BONE, the HIP signalling 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 end points. +--------------------------------------+ | Transport (using HITs or LSIs) | +--------------------------------------+ | HIP | +------------------+-------------------+ | IPv4 | IPv6 | +------------------+-------------------+ Figure 3: HIP as a thin waist +------------------+-------------------+ | HIP signalling | data transports | +------------------+-------------------+ Camarillo, et al. Expires June 23, 2008 [Page 11] Internet-Draft HIP BONE December 2007 Figure 4: HIP layer structure In HIP BONE, the peer protocol creates a new signalling layer on the top of HIP signalling. It is used to set up forwarding paths for HIP signalling 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 are used for forwarding HIP packets according to the information in the forwarding tables. The peer protocols are used to exchange routing information based on Peer IDs and public keys, and to construct the forwarding tables. In HIP BONE, the HIP usage of public keys and deriving ORCHIDs through a hash function can be utilised at the peer protocol side to better secure routing table (i.e. finger table) maintenance and to protect against chosen-peer-ID attacks. The HIP BONE allows quite a lot of flexibility how to arrange the different protocols in detail. Figure 5 shows one potential stack structure. +-----------------------+--------------+ | peer protocols | media | +------------------+----+--------------+ | HIP signalling | data transport | | | +------------------+-------------------+ | NAT | non-NAT | | | | | | IPv4 | IPv6 | +------------------+-------------------+ Figure 5: Example HIP BONE stack structure 7. Security Considerations TBD. 8. Acknowledgements TBD. Camarillo, et al. Expires June 23, 2008 [Page 12] Internet-Draft HIP BONE December 2007 9. IANA Considerations This document does not contain any IANA actions. 10. Normative References [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007. [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-08 (work in progress), June 2007. [I-D.ietf-hip-native-api] Komu, M., "Native Application Programming Interfaces for SHIM Layer Prococols", draft-ietf-hip-native-api-01 (work in progress), March 2007. [I-D.ietf-hip-dns] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", draft-ietf-hip-dns-09 (work in progress), April 2007. [I-D.ietf-hip-rvs] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", draft-ietf-hip-rvs-05 (work in progress), June 2006. [I-D.ietf-hip-mm] Henderson, T., "End-Host Mobility and Multihoming with the Host Identity Protocol", draft-ietf-hip-mm-05 (work in progress), March 2007. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-16 (work in progress), June 2007. [I-D.ietf-behave-rfc3489bis] Rosenberg, J., "Session Traversal Utilities for (NAT) (STUN)", draft-ietf-behave-rfc3489bis-06 (work in progress), March 2007. [I-D.ietf-hip-esp] Jokela, P., "Using ESP transport format with HIP", Camarillo, et al. Expires June 23, 2008 [Page 13] Internet-Draft HIP BONE December 2007 draft-ietf-hip-esp-06 (work in progress), June 2007. [I-D.ietf-hip-applications] Henderson, T. and P. Nikander, "Using the Host Identity Protocol with Legacy Applications", draft-ietf-hip-applications-01 (work in progress), April 2007. 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 Camarillo, et al. Expires June 23, 2008 [Page 14] Internet-Draft HIP BONE December 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Camarillo, et al. Expires June 23, 2008 [Page 15]