\
[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04                                                
HIP Working Group                                            P. Nikander
Internet-Draft                                              G. Camarillo
Intended status: Experimental                                   J. Melen
Expires: May 7, 2009                                            Ericsson
                                                        November 3, 2008


HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper-
                   layer Protocol Signaling (HICCUPS)
                   draft-nikander-hip-hiccups-01.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 May 7, 2009.

Abstract

   This document defines a new HIP (Host Identity Protocol) packet type
   called DATA.  HIP DATA packets are used to securely and reliably
   convey arbitrary protocol messages over the Internet and various
   overlay networks.









Nikander, et al.           Expires May 7, 2009                  [Page 1]


Internet-Draft                   HICCUPS                   November 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Background on HIP  . . . . . . . . . . . . . . . . . . . . . .  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
   3.  Definition of the HIP DATA Packet  . . . . . . . . . . . . . .  5
     3.1.  Definition of the SEQ_DATA Parameter . . . . . . . . . . .  6
     3.2.  Definition of the ACK_DATA Parameter . . . . . . . . . . .  7
     3.3.  Definition of the PAYLOAD_HMAC Parameter . . . . . . . . .  7
   4.  Generation and Reception of HIP DATA Packets . . . . . . . . .  8
     4.1.  Handling of SEQ_DATA and ACK_DATA  . . . . . . . . . . . .  8
     4.2.  Generation of a HIP DATA packet  . . . . . . . . . . . . .  9
     4.3.  Reception of a HIP DATA packet . . . . . . . . . . . . . . 10
       4.3.1.  Handling of SEQ_DATA in a Received HIP DATA packet . . 10
       4.3.2.  Handling of ACK_DATA in a Received HIP DATA packet . . 11
   5.  Use of the HIP DATA Packet . . . . . . . . . . . . . . . . . . 12
   6.  Security considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Informative references . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 15


























Nikander, et al.           Expires May 7, 2009                  [Page 2]


Internet-Draft                   HICCUPS                   November 2008


1.  Introduction

   Two hosts can use HIP [RFC5201] to establish a Security Association
   (SA) between them in order to exchange arbitrary protocol messages
   over that security association.  The establishment of such a security
   association involves a four-way handshake referred to as the HIP base
   exchange.  When handling communications between the hosts, HIP
   supports mobility, multihoming, security, and NAT traversal.  Some
   applications require these features for their communications but
   cannot accept the overhead involved in establishing a security
   association (i.e., the HIP base exchange) before those communications
   can start.

   In this document, we define the HIP DATA packet, which can be used to
   convey (in a secure and reliable way) protocol messages to a remote
   host without running the HIP base exchange between them.  We also
   discuss the trade offs involved in using this packet (i.e., less
   overhead but also less DoS protection) and the situations where it is
   appropriate to use this packet.


2.  Background on HIP

   The HIP protocol specification [RFC5201] defines a number of messages
   and parameters.  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.

   The fixed header is defined in Section 5.1 of [RFC5201] and copied
   below.












Nikander, et al.           Expires May 7, 2009                  [Page 3]


Internet-Draft                   HICCUPS                   November 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                         /
      /                                                               /
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The HIP header is logically an IPv6 extension header.  However, this
   document describes processing for Next Header values as they are
   carried on the HIP DATA packet.

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 May 7, 2009                  [Page 4]


Internet-Draft                   HICCUPS                   November 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 messages 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.  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.


3.  Definition of the HIP DATA Packet

   The HIP DATA packet can be used to convey protocol messages to a
   remote host without running the HIP base exchange between them.  HIP
   DATA packets are transmitted reliably, as discussed in Section 4.
   The payload of a HIP DATA packet is placed after the HIP header and
   protected by a PAYLOAD_HMAC parameter, which is defined in
   Section 3.3.  The following is the definition of the HIP DATA packet:


         Header:
           Packet Type = [ TBD by IANA: 32 ]
           SRC HIT = Sender's HIT
           DST HIT = Receiver's HIT

       IP ( HIP ( [SEQ, ACK, ] [HOST_ID, ] PAYLOAD_HMAC,
                  HIP_SIGNATURE) PAYLOAD )

   The SEQ_DATA and ACK_DATA parameters are defined in Section 3.1 and



Nikander, et al.           Expires May 7, 2009                  [Page 5]


Internet-Draft                   HICCUPS                   November 2008


   Section 3.2 respectively.  They are used to provide a reliable
   delivery of HIP DATA packets, as discussed in Section 4.

   The HOST_ID parameter is defined in Section 5.2.8 of [RFC5201].  This
   parameter is the sender's Host Identifier that is used to compute the
   HIP DATA packet's signature and to verify it against the received
   signature.

   The PAYLOAD_HMAC parameter is defined in Section 3.3.  This parameter
   contains the HMAC of the payload carried by the HIP DATA packet.

   The HIP_SIGNATURE parameter is defined in Section 5.2.11. of
   [RFC5201].  It contains a signature over the contents of the HIP DATA
   packet.  The calculation and verification of the signature is defined
   Section 6.4.2. of [RFC5201]

   Section 5.3 of [RFC5201] states the following:

      In the future, an OPTIONAL upper-layer payload MAY follow the HIP
      header.  The Next Header field in the header indicates if there is
      additional data following the HIP header.

   We have chosen to place the payload after the HIP extension header
   and only to place an HMAC of the payload in to the HIP extension
   header in a PAYLOAD_HMAC parameter because that way the data is
   protected by a public key signature with help of HMAC.  The payload
   that is protected by the PAYLOAD_HMAC parameter has been linked to
   the appropriate upper-layer protocol by storing the upper-layer
   protocol number, 8 bytes of payload data, and by calculating an HMAC
   over the data.

3.1.  Definition of the SEQ_DATA Parameter

   The following is the definition of the SEQ_DATA parameter:

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type              [ TBD by IANA:
                          4481 = (2^12 + 2^8 + 2^7 + 1) ]
      Length            4
      Sequence number   32-bit sequence number




Nikander, et al.           Expires May 7, 2009                  [Page 6]


Internet-Draft                   HICCUPS                   November 2008


3.2.  Definition of the ACK_DATA Parameter

   The following is the definition of the ACK_DATA parameter:

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Acked Sequence number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type                    [ TBD by IANA:
                                4545 = (2^12 + 2^8 + 2^7 + 2^6 + 1) ]
      Length                  4
      Acked Sequence number   32-bit sequence number corresponding to
                              the sequence number being acknowledged

3.3.  Definition of the PAYLOAD_HMAC Parameter

   The following is the definition of the PAYLOAD_HMAC parameter:






























Nikander, et al.           Expires May 7, 2009                  [Page 7]


Internet-Draft                   HICCUPS                   November 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next header  |                   Reserved                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Payload Data                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      /                         Payload HMAC                          /
      /                                               +-+-+-+-+-+-+-+-+
      |                                               |    Padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type              [ TBD by IANA:
                          4577 = (2^12 + 2^8 + 2^7 + 2^6 + 2^5 + 1) ]
      Length            length in octets, excluding Type, Length, and
                        Padding
      Next Header       identifies the data that protected by this HMAC.
                        The values for are defined by IANA "Assigned
                        Numbers".
      Payload Data      8 last bytes of the payload data over which the
                        HMAC is calculated. This field is used to
                        uniquely identify the extension header, in case
                        there are multiple copies of same type.
      Payload HMAC      HMAC computed over the data to which the Next
                        Header and Payload Data points to. The size of
                        the HMAC is the natural size of the hash
                        computation output depending on the used hash
                        function.


4.  Generation and Reception of HIP DATA Packets

   HIP DATA packets are transmitted reliably.  Reliable delivery is
   achieved through the use of retransmissions and of the SEQ_DATA and
   ACK_DATA parameters.

4.1.  Handling of SEQ_DATA and ACK_DATA

   A HIP DATA packet contains zero or one SEQ_DATA parameter.  The
   presence of a SEQ_DATA parameter indicates that the receiver MUST ACK
   the HIP DATA packet.  A HIP DATA packet that does not contain a
   SEQ_DATA parameter is simply an ACK of a previous HIP DATA packet and
   MUST NOT be ACKed.

   A HIP DATA packet contains zero or one ACK_DATA parameters.  The ACK



Nikander, et al.           Expires May 7, 2009                  [Page 8]


Internet-Draft                   HICCUPS                   November 2008


   parameter echoes the SEQ_DATA sequence number of the HIP DATA packet
   packet being ACKed.

   A HIP DATA packet may contain both a SEQ_DATA and an ACK_DATA
   parameter.  In this case, the ACK is being piggybacked on an outgoing
   HIP DATA packet.  In general, HIP DATA packets carrying SEQ_DATA
   SHOULD be ACKed upon completion of the processing of the HIP DATA
   packet.  A host MAY choose to hold the HIP DATA packet carrying ACK
   for a short period of time to allow for the possibility of
   piggybacking the ACK parameter, in a manner similar to TCP delayed
   acknowledgments.

4.2.  Generation of a HIP DATA packet

   When a host has upper-layer protocol data to send, it either runs the
   HIP base exchange and sends the data over a SA, or sends the data
   directly using a HIP DATA packet.  Section 5 discusses when it is
   appropriate to use each method.  This section discusses the case when
   the host chooses to use a HIP DATA packet to send the upper-layer
   protocol data.

   1.  The host creates a HIP DATA packet that contains a SEQ_DATA
       parameter.  The host is free to choose any value for the SEQ_DATA
       parameter in the first HIP DATA packet it sends to a destination.
       After that first packet, the host MUST choose the value of the
       SEQ_DATA parameter in subsequent HIP DATA packets to the same
       destination so that no SEQ_DATA value is reused before the
       receiver has closed the processing window for the previous packet
       using the same SEQ_DATA value.  Practically, giving the values of
       the retransmission timers used with HIP DATA packets, this means
       that hosts must wait the maximum likely lifetime of the packet
       before reusing a given SEQ_DATA value towards a given
       destination.  However, it is not required for node to know the
       maximum packet lifetime.  Rather, it is assumed that the
       requirement can be met by maintaining the value as a simple, 32-
       bit, "wrap-around" counter, incremented each time a packet is
       sent.  It is an implementation choice whether to maintain a
       single counter for the node or multiple counters (one for each
       source HIT, destination HIT combination).
   2.  The host creates PAYLOAD_HMAC parameter.  The HMAC is calculated
       over the whole PAYLOAD which the Next Header field of
       PAYLOAD_HMAC parameter indicates.  The receiver MUST validate
       this HMAC.  For calculating the HMAC the host MUST use the same
       hash algorithm as the one that has been used for generating the
       host's HIT as defined in Section 3.2. of [RFC5201].
   3.  The host creates HIP_SIGNATURE parameter.  The signature is
       calculated over the whole HIP envelope, excluding any parameters
       after the HIP_SIGNATURE, as defined in Section 5.2.11. of



Nikander, et al.           Expires May 7, 2009                  [Page 9]


Internet-Draft                   HICCUPS                   November 2008


       [RFC5201].  The receiver MUST validate this signature.  It MAY
       use either the HI in the packet or the HI acquired by some other
       means.
   4.  The hosts sends the created HIP DATA packet and starts a DATA
       timer.  The default value for the timer is 2 * RTT estimate.  If
       multiple HIP DATA packets are outstanding, multiple timers are in
       effect.
   5.  If the DATA timer expires, the HIP DATA packet is resent.  The
       HIP DATA packet can be resent DATA_RETRY_MAX times.  The DATA
       timer SHOULD be exponentially backed off for subsequent
       retransmissions.  If no acknowledgment is received from the peer
       after DATA_RETRY_MAX times, the delivery of the HIP DATA packet
       is considered unsuccessful and the application is notified about
       the error.  The DATA timer is canceled upon receiving an ACK from
       the peer that acknowledges receipt of the HIP DATA packet.

4.3.  Reception of a HIP DATA packet

   A host receiving a HIP DATA packet to decide whether to process it or
   not.  If the host, following its local policy, suspects that this
   packet could be part of a DoS attack.  The host MAY responds with an
   R1 packet to the HIP DATA packet, if the packet contained SEQ_DATA
   and PAYLOAD_HMAC parameter, in order to run the HIP base exchange
   with the originator of the HIP DATA packet.  If the host chooses to
   respond to the HIP DATA with an R1 packet, it creates a new R1 or
   selects a precomputed R1 according to the format described in
   [RFC5201] Section 5.3.2.

   If the host, following its local policy, decides to process the
   incoming HIP DATA packet, it processes it according to the following
   rules:

      If the HIP DATA packet contains a SEQ_DATA parameter and no
      ACK_DATA parameter, the HIP DATA packet is processed and replied
      to as described in Section 4.3.1.
      If the HIP DATA packet contains an ACK_DATA parameter and no
      SEQ_DATA parameter, the HIP DATA packet is processed and replied
      to as described in Section 4.3.2.
      If the HIP DATA packet contains both a SEQ_DATA parameter and an
      ACK_DATA parameter, the HIP DATA packet is processed first as
      described in Section 4.3.2 and then the rest of the HIP DATA
      packet is processed and replied to as described in Section 4.3.1.

4.3.1.  Handling of SEQ_DATA in a Received HIP DATA packet

   The following steps define the conceptual processing rules for
   handling a SEQ_DATA parameter in a received HIP DATA packet.




Nikander, et al.           Expires May 7, 2009                 [Page 10]


Internet-Draft                   HICCUPS                   November 2008


   If the value in the received SEQ_DATA corresponds to a HIP DATA
   packet that has recently been processed, the packet is treated as a
   retransmission.  The SIGNATURE verification (next step) MUST NOT be
   skipped.  (A byte-by-byte comparison of the received and a stored
   packet would be OK, though.)  It is recommended that a host cache HIP
   DATA packets sent with ACKs to avoid the cost of generating a new ACK
   packet to respond to a replayed HIP DATA packet.  The host MUST
   acknowledge, again, such (apparent) HIP DATA packet retransmissions
   but SHOULD also consider rate-limiting such retransmission responses
   to guard against replay attacks.

   The system MUST verify the SIGNATURE in the HIP DATA packet.  If the
   verification fails, the packet SHOULD be dropped and an error message
   logged.

   The system MUST verify the PAYLOAD_HMAC by calculating the HMAC over
   the PAYLOAD which the Next Header field indicates.  For calculating
   the HMAC the host will use the same hash algorithm that has been used
   to generate the sender's HIT as defined in Section 3.2. of [RFC5201].
   If the verification fails, the packet SHOULD be dropped and an error
   message logged.

   If a new SEQ parameter is being processed, the parameters in the HIP
   DATA packet are then processed.

   A HIP DATA packet with an ACK_DATA parameter is prepared and sent to
   the peer.  This ACK_DATA parameter may be included in a separate HIP
   DATA packet or piggybacked in a HIP DATA packet with a SEQ_DATA
   parameter.  The ACK_DATA parameter MAY acknowledge more than one of
   the peer's HIP DATA packets.

4.3.2.  Handling of ACK_DATA in a Received HIP DATA packet

   The following steps define the conceptual processing rules for
   handling an ACK_DATA parameter in a received HIP DATA packet.

   The sequence number reported in the ACK_DATA must match with an
   earlier sent HIP DATA packet that has not already been acknowledged.
   If no match is found or if the ACK_DATA does not acknowledge a new
   HIP DATA packet, the packet MUST either be dropped if no SEQ_DATA
   parameter is present, or the processing steps in Section 4.3.1 are
   followed.

   The system MUST verify the SIGNATURE in the HIP DATA packet.  If the
   verification fails, the packet SHOULD be dropped and an error message
   logged.

   The corresponding DATA timer is stopped so that the now acknowledged



Nikander, et al.           Expires May 7, 2009                 [Page 11]


Internet-Draft                   HICCUPS                   November 2008


   HIP DATA packet is no longer retransmitted.  If multiple HIP DATA
   packets are newly acknowledged, multiple timers are stopped.


5.  Use of the HIP DATA Packet

   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 additional RTTs (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.  The use of the HIP DATA packet defined
   in this document reduces the initial overhead in the communications
   between two hosts at the expense of decreasing DoS protection.
   Therefore, applications SHOULD NOT use HIP DATA packets in
   environments where DoS attacks are believed to be an issue.  For
   example, a HIP-based overlay may have policies in place to control
   which nodes can join the overlay.  Any particular node in the overlay
   may want to accept HIP DATA packets from other nodes in the overlay
   given that those other were authorized to join the overlay.  However,
   the same node may not want to accept HIP DATA packets from random
   nodes that are not part of the overlay.

   The type of data to be sent is also relevant to whether the use of a
   HIP DATA packet is appropriate.  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.  Therefore, applications
   in environments where fragmentation could be an issue SHOULD NOT
   generate too large HIP DATA packets that may lead to fragmentation.
   Note that there are environments where fragmentation is not an issue.
   For example, in some HIP-based overlays, nodes can exchange HIP DATA
   packets on top of TCP connections that provide transport-level
   fragmentation and, thus, avoid IP-level fragmentation.

   HIP currently requires that all messages excluding I1s but including
   HIP DATA packets 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.


6.  Security considerations

   HIP is designed to provide secure authentication of hosts.  HIP also
   attempts to limit the exposure of the host to various denial-of-
   service and man-in-the-middle (MitM) attacks.  However, HIP DATA
   packet, which can be sent without running the HIP base exchange



Nikander, et al.           Expires May 7, 2009                 [Page 12]


Internet-Draft                   HICCUPS                   November 2008


   between hosts has a trade off that it does not provide the denial-of-
   service protection that HIP generally provides.  Thus, the host
   should consider always situations where it is appropriate to use HIP
   DATA packet.


7.  IANA considerations

   This document updates the IANA Registry for HIP Packet types by
   intrducing new packet type for the new HIP_DATA (Section 3) packet.
   This document updates the IANA Registry for HIP Parameter Types by
   introducing new parameter values for the SEQ_DATA (Section 3.1),
   ACK_DATA (Section 3.2), and PAYLOAD_HMAC (Section 3.3) parameters.


8.  Acknowledgments

   In the usual IETF fashion, a large number of people have contributed
   to the actual text or ideas.  The list of these people include Miika
   Komu, Tobias Heer, Ari Keraenen, Samu Varjonen, Thomas Henderson, and
   Jukka Ylitalo.  Our apologies to anyone whose name is missing.


9.  Informative references

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


Authors' Addresses

   Pekka Nikander
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Pekka.Nikander@ericsson.com





Nikander, et al.           Expires May 7, 2009                 [Page 13]


Internet-Draft                   HICCUPS                   November 2008


   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 May 7, 2009                 [Page 14]


Internet-Draft                   HICCUPS                   November 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.











Nikander, et al.           Expires May 7, 2009                 [Page 15]