[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02 03 04                                                
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)

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 31, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


   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

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

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
   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
   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
   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
   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

   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
   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

   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


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.

              Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work
              in progress), February 2008.

              Heer, T., "LHIP Lightweight Authentication Extension for
              HIP", draft-heer-hip-lhip-00 (work in progress),
              March 2007.

              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.

              Nikander, P., Arkko, J., and B. Ohlman, "Host Identity
              Indirection Infrastructure (Hi3)", 2004.

              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
   Hirsalantie 11
   Jorvas  02420

   Email: Pekka.Nikander@ericsson.com

   Gonzalo Camarillo
   Hirsalantie 11
   Jorvas  02420

   Email: Gonzalo.Camarillo@ericsson.com

   Jan Melen
   Hirsalantie 11
   Jorvas  02420

   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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Nikander, et al.        Expires January 31, 2009               [Page 13]