HIP Working Group P. Nikander Internet-Draft G. Camarillo Intended status: Experimental J. Melen Expires: January 31, 2009 Ericsson July 30, 2008 HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signalling (HICCUPS) draft-nikander-hip-hiccups-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 January 31, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This memo defines how one can use HIP packet formats, and optionally the HIP base exchange, to securely convey arbitrary signalling messages over the Internet or various overlay networks. Nikander, et al. Expires January 31, 2009 [Page 1] Internet-Draft HICCUPS July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Message formats . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. HIP fixed header . . . . . . . . . . . . . . . . . . . 3 2.1.2. HIP parameter format . . . . . . . . . . . . . . . . . 4 2.2. HIP base exchange, updates, and state removal . . . . . . 5 2.3. Basic ways to extend HIP . . . . . . . . . . . . . . . . . 5 2.4. Present limitations to extendability . . . . . . . . . . . 6 2.5. Mobility, multi-homing, and NAT traversal . . . . . . . . 7 2.6. Routing HIP packets . . . . . . . . . . . . . . . . . . . 7 3. Using HIP to carry signalling protocol messages . . . . . . . 7 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Observations . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Main benefits and drawbacks . . . . . . . . . . . . . . . 9 4. Security considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Informative references . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Nikander, et al. Expires January 31, 2009 [Page 2] Internet-Draft HICCUPS July 2008 1. Introduction There has recently been discussion at the IETF on how to design and route new signalling protocols. Typical to these discussions are that the requirements for supporting mobility, multi-homing, security, NAT traversal, or overlay routing go beyond of what is currently possible with plain IP, UDP, or TCP. In this memo we briefly outline how the Host Identity Protocol (HIP) can be used, either in parts or as a whole, to convey signalling messages when the above mentioned properties are of paramount value. 2. Background The HIP protocol defines a number of messages and parameters [RFC5201]. The parameters are encoded as TLVs, as shown in Section 2.1.2. Furthermore, the HIP header carries a Next Header field, allowing other arbitrary packets to be carried within HIP packets. 2.1. Message formats 2.1.1. HIP fixed header The HIP packet format consists of a fixed header, followed by a variable number of parameters. The parameter format is described in Section 2.1.2, below. The fixed header is defined in Section 5.1 of [RFC5201], and copied below. Nikander, et al. Expires January 31, 2009 [Page 3] Internet-Draft HICCUPS July 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Header Length |0| Packet Type | VER. | RES.|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Controls | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / HIP Parameters / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1.2. HIP parameter format The HIP parameter format is defined in Section 5.2.1 of [RFC5201], and copied below. 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 |C| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Contents / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type code for the parameter C Critical bit, part of the Type. Length Length of the parameter, in bytes. Contents Parameter specific, defined by Type. Padding Padding, 0-7 bytes, added if needed. Nikander, et al. Expires January 31, 2009 [Page 4] Internet-Draft HICCUPS July 2008 2.2. HIP base exchange, updates, and state removal The HIP base exchange is a four message half-stateless authentication and key exchange protocol that creates shared, mutually authenticated keying material at the communicating parties. These keying materials, together with associated public keys and IP addresses, form a HIP Security Association (SA). The details of the protocol are defined in the HIP base exchange specification [RFC5201]. In addition to creating the HIP SA, the base exchange message may carry additional parameters that are used to create additional state. For example, the HIP ESP specification [RFC5202] defines how HIP can be used to create end-to-end, host-to-host IPsec ESP Security Associations, used to carry data packets. However, it is important to understand that the HIP base exchange is by no means bound to IPsec; using IPsec ESP to carry data traffic forms just a baseline and ensures interoperability between initial HIP implementations. Once there is a HIP SA between two HIP-enabled hosts, they can exchange further HIP control messages. Typically, UPDATE messages are used. The contents of UPDATE messages is completely open; for example, the HIP mobility and multi-homing specification [RFC5206] defines how to use UPDATE messages to change the set of IP addresses associated with a HIP SA. In addition to the base exchange and updates, the HIP base protocol specification also defines how one can remove a HIP SA once it is no longer needed. 2.3. Basic ways to extend HIP As a protocol, HIP has been defined as a secure, extensible protocol that can be used for any kinds of host-to-host negotiations. Since HIP packets can carry additional payloads, it can also be used to carry upper layer, application specific signalling negotiations. However, as the HIP packets by default always carry a digital signature in order to facilitate third party packet authentication, they are somewhat expensive to produce and therefore typically not suitable for bulk data traffic. The protocol contains the following basic extension mechanisms: o The currently defined Host Identity value in HIP is a sole public key. However, as explained in the architecture specification [RFC4423], in theory the Host Identity can also consist of some other data. In practise, the public key can be extended with additional identifying data or alternative identifiers. Nikander, et al. Expires January 31, 2009 [Page 5] Internet-Draft HICCUPS July 2008 o To facilitate the HIP protocol machinery, each HIP packet carries an 8-bit packet type. Currently only a few of these packet types are used. Consequently, for extensions that require more states at the HIP base exchange and protocol level, the best way to extend is to define new packet types. o The fixed header carries a 16-bit Controls field, which can be used to introduce new base level features that are orthogonal to the protocol state machine. o Each HIP packet can carry zero or more parameters. Each parameter type is identified with a 16-bit Type value. As only few of these are defined, perhaps the generally best way to extend HIP is to define new parameter types and define what kind of HIP packets may be used to exchange them. As a part of this, many of the existing parameter values can be used to help defining new extensions, see below. o The Next Header field in the fixed header allows a HIP packet to carry arbitary data; for example, simple SIP messages may be exchange over HIP in this way. o The HIP registration extension [RFC5203] defines a generic protocol that can be used to announce availability of HIP based services and to register as a user to such a service. The extension has itself been designed to be extensible, allowing it to be used for announcing and using different services. o The SEQ and ACK parameters allow several request-reply pairs to be reliably and parallelly exchanged over a single HIP SA. o The SIG and HMAC parameters allow HIP-based message exchanges to be authenticated. o The ENCRYPTED parameter allows any HIP parameters to be optionally encrypted. o The CERT parameter allows HIP peers to exchange certificates. 2.4. Present limitations to extendability As HIP extensions are a relatively unexplored area, there may still be features in the HIP protocol that make extensions harder than necessary. The author is presently aware of the following limitations: o HIP itself does not support fragmentation but relies on underlying IP-layer fragmentation. This may lead to reliability problems in the case where a message cannot be easily split over multiple HIP messages. o HIP currently requires always that the four-message base exchange is executed at the first encounter of hosts that have not communicated before. This may add an additional round trip time to protocols based on a single message exchange. However, the four-message exchange is essential to preserve the half-stateless, DoS protection nature of the base exchange; see Section 4. Nikander, et al. Expires January 31, 2009 [Page 6] Internet-Draft HICCUPS July 2008 o HIP currently requires that all messages (but I1) are digitally signed. This adds to the packet size and the processing capacity needed to send packets. However, in applications where security is not paramount, it is possible to use very short keys, thereby reducing resource consumption. 2.5. Mobility, multi-homing, and NAT traversal The HIP mobility and multi-homing specification [RFC5206] defines how one can move the end-points of an existing HIP association from one IP address to another (due to e.g. host mobility) or to associate multiple IP addresses with an end-point (e.g. to help with multi- homing or NAT traversal). 2.6. Routing HIP packets Each HIP packet carries two identifiers: the Host Identity Tag (HIT) of the sender and that of the receiver. The HITs are 128-bit long entities, consisting of a fixed prefix as defined in [RFC4843], and a 100-bits long hash of an upper-layer Host Identifier value. In the base Internet, HIP packets are routed as any IP traffic, based on the IP addresses in the IP header preceeding the HIP header. When more flexible routing constructions are needed, such as for overlay networks, it is possible to create and maintain forwarding state based on the HITs. For one particular example of how this can be done, one can consider the Host Identity Indirection Infrastructure (Hi3) proposal [paper-hi3], which basically combines HIP with the Internet Indirection Infrastructure (i3) [paper-i3]. Another example if the HIP BONE framework [I-D.camarillo-hip-bone]. 3. Using HIP to carry signalling protocol messages Above we have briefly described the basic facilities provided by HIP and succintly explained various options to expand it. In this section we discuss, in general terms, how one can use the HIP extension capabilities to use HIP, either in whole or in parts, to facilitate signalling message exchange. We start with a few brief examples, and then continue to some more generic observations, and finally outline potential benefits and drawbacks that may stem from using HIP to carry signalling messages. Nikander, et al. Expires January 31, 2009 [Page 7] Internet-Draft HICCUPS July 2008 3.1. Examples The SHIM6 protocol [I-D.ietf-shim6-proto] uses the same packet format and parameter formats as HIP does. The protocols have been carefully designed to be compatible, so that it should be very easy to adopt features from one protocol to another. Furthermore, most early SHIM6 implementations are based on existing open-source HIP implementations, basically borrowing the underlying implementation architecture. The Lightweight HIP [I-D.heer-hip-lhip] proposal specifies a new security model for HIP, using hash chains instead of public keys. Other than that, the proposal preserves HIP semantics and packet formats, and is fully compatible with HIP, thereby providing a different way of securing HIP-based mobility, multi-homing, NAT- traversal, registration, etc. 3.2. Observations Based on the argumentation and examples above, our thinking can be summarised into the following observations: o The HIP base protocol [RFC5201], with the basic extensions [RFC5206][RFC5203][RFC5204], offers a well-researched, experimental protocol that provides reasonable DoS resistence, public-key-based mutual authentication, host mobility and multi- homing with inherent route-optimisation and multi-home-agent support. o The HIP mobility and multi-homing work across IPv4 and IPv6, thereby providing good IP version transition support for any protocols that utilise HIP. o The HIP base protocol is suitable for low-volume, highly secure signalling-type traffic where interaction with middle boxes is important. The main reasons for these characteristics are that all packets contain a public-key signature, designed to be verifiable by middle boxes. o The HIP base protocol is not suitable for high-volume data traffic. Instead, it is recommended that an extension is used to establish separate security associations for data protocols. Currently the only such extension is the ESP extension [RFC5202]. o The HIP base protocol has been designed to be extensible with different methods, as described in Section 2.3. o The HIP packets are identified by the source and destination HITs, which are essentially hashes over some other identifiers (typically public keys). This allows the HIP packets to be routed on the bases of these identifiers, as long as the routing system supports routing on flat names. Nikander, et al. Expires January 31, 2009 [Page 8] Internet-Draft HICCUPS July 2008 o The logical location of HIP directly at the top of IPv4 and IPv6, together with its ability to simultaneously work on both, combined with mobility, multi-homing, and NAT-traversal functions, provides a good bases for universal connectivity in the current Internet, independent of the applications. o Architecturally, any signalling protocol whose purpose is to control data traffic that flows over IPv4 and IPv6 can be converted to run on the top of HIP, while simutaneously either continuing the data traffic completely unmodified or converting it to run on the top of some security protocol, such as IPsec, SRTP, or perhaps even TLS. While doing the protocol conversion, the signalling protocol may benefit from the DoS resistance, security, mobility, multi-homing, IPv4/IPv6 interoperability, and NAT- traversal features of HIP. 3.3. Main benefits and drawbacks In this section we list the main features of HIP that may be beneficial or harmful, depending on the point of view. o Packet routability on flat, hash-based names. o Strong authentication, visible to third parties. o Creation of keying material, available for other protocols. o Support for host mobility, over IPv4 and IPv6. o Support for host multi-homing, over IPv4 and IPv6. o Good compatibility with legacy IPv4 and IPv6 applications. o Extensibility. 4. Security considerations The HIP security model is based on the assumption that the peer hosts (or applications running on them) have secure access to their peer's public keys. How this access is established falls beyond the scope of HIP, and may be arranged, for example, opportunistically, using leap-of-faith, using extenal key distribution, or using third parties and certificates. The HIT security model is based on the assumption that the used hash algorithm (currently SHA-1) is secure against second preimage attacks, thereby providing assurance that a given HIT corresponds to a given public key. In practical terms, this means that whenever an application has securely acquired a HIT and is using the HIT to name the peer, the underlying HIP machinery makes sure that all communications takes place with the entity denoted by the HIT, or does not place at all. One two HIP hosts have access to their peer's public keys and know at least one currently reachable IP address of the peer or the peer's Nikander, et al. Expires January 31, 2009 [Page 9] Internet-Draft HICCUPS July 2008 rendezvous server, the HIP hosts can establish a HIP Security Association. The association formation is carried by the HIP base exchange protocol, based on the SIGMA family of cryptographic key exchange protocols. The protocol contains methods to mitigate some types of CPU and state exhausting denial-of-service attacks. Currently, the HIP base exchange protocol is the simplest known protocol that provides the level of authentication, key formation, integrity protection, and DoS resistance that the protocol provides. Furthermore, there are strong reasons to believe that it is not possible to design significantly simpler protocols that accomplish the same characteristics. The HIP mobility and multi-homing extension creates a secure, dynamic, one-to-many binding between the peer's host identity and the IP addresses through which the peer is currently reachable at. Security is based on public key signaturs, HMACs based on session keys, return routability, and credit based authorisation. The native HIP NAT traversal proposal (SPINAT) provides a secure, stateful address translation facility between addressing domains. The legacy HIP NAT traversal proposal is vulnerable to same kind of session stealing attacks as plain NAT or STUN and TURN; however, since the signalling protocol itself is secure and since it is possible to use secure data transfer protocols (such as ESP), the only result of such session stealing is a short period of denial-of- service, until the HIP multi-homing facility manages to create new connectivity. For some applications, the HIP security model can be replaced by the Lightweight HIP (LHIP) security model, which is based on opportunistic hash chains. For the security properties of this alternative, see the LHIP specification [I-D.heer-hip-lhip]. 5. IANA considerations This memo defines no IANA actions. 6. Acknowledgments TBD. 7. Informative references [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol Nikander, et al. Expires January 31, 2009 [Page 10] Internet-Draft HICCUPS July 2008 (HIP) Architecture", RFC 4423, May 2006. [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., 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. [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008. [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008. [I-D.ietf-shim6-proto] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work in progress), February 2008. [I-D.heer-hip-lhip] Heer, T., "LHIP Lightweight Authentication Extension for HIP", draft-heer-hip-lhip-00 (work in progress), March 2007. [I-D.camarillo-hip-bone] Camarillo, G., Nikander, P., and J. Hautakorpi, "HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment", draft-camarillo-hip-bone-00 (work in progress), December 2007. [paper-hi3] Nikander, P., Arkko, J., and B. Ohlman, "Host Identity Indirection Infrastructure (Hi3)", 2004. [paper-i3] Stoica, I., Adkins, D., Zhuang, S., Shenker, S., and S. Surana, "Internet Indirection Infrastructure (i3)", 2002. Nikander, et al. Expires January 31, 2009 [Page 11] Internet-Draft HICCUPS July 2008 Authors' Addresses Pekka Nikander Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Pekka.Nikander@ericsson.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Jan Melen Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Jan.Melen@ericsson.com Nikander, et al. Expires January 31, 2009 [Page 12] Internet-Draft HICCUPS July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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). Nikander, et al. Expires January 31, 2009 [Page 13]