draft-ietf-hip-hiccups-05.txt   rfc6078.txt 
HIP Working Group G. Camarillo Internet Engineering Task Force (IETF) G. Camarillo
Internet-Draft J. Melen Request for Comments: 6078 J. Melen
Intended status: Experimental Ericsson Category: Experimental Ericsson
Expires: January 13, 2011 July 12, 2010 ISSN: 2070-1721 January 2011
HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- Host Identity Protocol (HIP) Immediate Carriage and Conveyance
layer Protocol Signaling (HICCUPS) of Upper-Layer Protocol Signaling (HICCUPS)
draft-ietf-hip-hiccups-05
Abstract Abstract
This document defines a new HIP (Host Identity Protocol) packet type This document defines a new Host Identity Protocol (HIP) packet type
called DATA. HIP DATA packets are used to reliably convey called DATA. HIP DATA packets are used to reliably convey
authenticated arbitrary protocol messages over various overlay authenticated arbitrary protocol messages over various overlay
networks. networks.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for examination, experimental implementation, and
evaluation.
The list of Internet-Draft Shadow Directories can be accessed at This document defines an Experimental Protocol for the Internet
http://www.ietf.org/shadow.html. community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on January 13, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6078.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 4 3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Message formats . . . . . . . . . . . . . . . . . . . . . 4 3.1. Message Formats . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. HIP fixed header . . . . . . . . . . . . . . . . . . . 4 3.1.1. HIP Fixed Header . . . . . . . . . . . . . . . . . . . 4
3.1.2. HIP parameter format . . . . . . . . . . . . . . . . . 5 3.1.2. HIP Parameter Format . . . . . . . . . . . . . . . . . 5
3.2. HIP Base Exchange, Updates, and State Removal . . . . . . 5 3.2. HIP Base Exchange, Updates, and State Removal . . . . . . 5
4. Definition of the HIP DATA Packet . . . . . . . . . . . . . . 6 4. Definition of the HIP_DATA Packet . . . . . . . . . . . . . . 6
4.1. Definition of the SEQ_DATA Parameter . . . . . . . . . . . 7 4.1. Definition of the SEQ_DATA Parameter . . . . . . . . . . . 8
4.2. Definition of the ACK_DATA Parameter . . . . . . . . . . . 8 4.2. Definition of the ACK_DATA Parameter . . . . . . . . . . . 8
4.3. Definition of the PAYLOAD_MIC Parameter . . . . . . . . . 9 4.3. Definition of the PAYLOAD_MIC Parameter . . . . . . . . . 9
4.4. Definition of the TRANSACTION_ID Parameter . . . . . . . . 10 4.4. Definition of the TRANSACTION_ID Parameter . . . . . . . . 10
5. Generation and Reception of HIP DATA Packets . . . . . . . . . 10 5. Generation and Reception of HIP_DATA Packets . . . . . . . . . 10
5.1. Handling of SEQ_DATA and ACK_DATA . . . . . . . . . . . . 10 5.1. Handling of SEQ_DATA and ACK_DATA . . . . . . . . . . . . 10
5.2. Generation of a HIP DATA packet . . . . . . . . . . . . . 11 5.2. Generation of a HIP_DATA Packet . . . . . . . . . . . . . 11
5.3. Reception of a HIP DATA packet . . . . . . . . . . . . . . 12 5.3. Reception of a HIP_DATA Packet . . . . . . . . . . . . . . 12
5.3.1. Handling of SEQ_DATA in a Received HIP DATA packet . . 13 5.3.1. Handling of SEQ_DATA in a Received HIP_DATA Packet . . 13
5.3.2. Handling of ACK_DATA in a Received HIP DATA packet . . 13 5.3.2. Handling of ACK_DATA in a Received HIP_DATA Packet . . 14
6. Use of the HIP DATA Packet . . . . . . . . . . . . . . . . . . 14 6. Use of the HIP_DATA Packet . . . . . . . . . . . . . . . . . . 14
7. Security considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative references . . . . . . . . . . . . . . . . . . 16 10.2. Informative references . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Two hosts can use HIP [RFC5201] to establish a Security Association Two hosts can use HIP [RFC5201] to establish a security association
(SA) between them in order to exchange arbitrary protocol messages (SA) between them in order to exchange arbitrary protocol messages
over that security association. The establishment of such a security over that security association. The establishment of such a security
association involves a four-way handshake referred to as the HIP base association involves a four-way handshake referred to as the HIP base
exchange. When handling communications between the hosts, HIP exchange. When handling communications between the hosts, HIP
supports mobility, multihoming, security, and NAT traversal. Some supports mobility, multihoming, security, and NAT traversal. Some
applications require these features for their communications but applications require these features for their communications but
cannot accept the overhead involved in establishing a security cannot accept the overhead involved in establishing a security
association (i.e., the HIP base exchange) before those communications association (i.e., the HIP base exchange) before those communications
can start. can start.
In this document, we define the HIP DATA packet, which can be used to In this document, we define the HIP DATA packet, which can be used to
convey (in a authenticated and reliable way) protocol messages to a convey (in a authenticated and reliable way) protocol messages to a
remote host without running the HIP base exchange between them. The remote host without running the HIP base exchange. The HIP_DATA
HIP DATA packet has following semantics: unordered, duplicate free, packet has the following semantics: unordered, duplicate free,
reliable, and authenticated message-based delivery service. We also reliable, and authenticated message-based delivery service. We also
discuss the trade offs involved in using this packet (i.e., less discuss the trade-offs involved in using this packet (i.e., less
overhead but also less DoS protection) and the situations where it is overhead but also less denial-of-service (DoS) protection) and the
appropriate to use this packet. The HIP_DATA packet is not intended situations where it is appropriate to use this packet. The HIP_DATA
to be a replacement for the Encapsulating Security Payload (ESP) packet is not intended to be a replacement for the Encapsulating
transport instead it SHOULD NOT be used to exchange more than a few Security Payload (ESP) transport; instead, it SHOULD NOT be used to
packets between the peers. If a continuous communication is required exchange more than a few packets between peers. If a continuous
or communication that requires confidentiality protection then hosts communication is required or communication that requires
MUST run the HIP base exchange to set up ESP security association. confidentiality protection then hosts MUST run the HIP base exchange
Additionally APIs to higher-level protocols that might use this to set up an ESP security association. Additionally, APIs to higher-
service are outside of the scope of this document. level protocols that might use this service are outside of the scope
of this document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In addition this document uses the terms defined in [RFC5201]. In addition, this document uses the terms defined in [RFC5201].
Message Integrity Code (MIC) is a collision-resistant hash sum Message Integrity Code (MIC) is a collision-resistant hash sum
calculated over the message which is being integrity protected. calculated over the message that is being integrity protected.
The MIC does not use secret keys and thus it needs additional The MIC does not use secret keys, and thus it needs additional
means to ensure that it has not been tampered with during means to ensure that it has not been tampered with during
transmission. Essentially MIC is same as Message Authentication transmission. Essentially, the MIC is same as the Message
Code (MAC) with the distinction that MIC does not use secret key. Authentication Code (MAC) with the distinction that the MIC does
MIC is also often referred as Integrity Check Value (ICV), not use secret keys. The MIC is also often referred as the
fingerprint, or unkeyed MAC. Integrity Check Value (ICV), fingerprint, or unkeyed MAC.
3. Background on HIP 3. Background on HIP
The HIP protocol specification [RFC5201] defines a number of messages The HIP specification [RFC5201] defines a number of messages and
and parameters. The parameters are encoded as TLVs, as shown in parameters. The parameters are encoded as TLVs, as shown in
Section 3.1.2. Furthermore, the HIP header carries a Next Header Section 3.1.2. Furthermore, the HIP header carries a Next Header
field, allowing other arbitrary packets to be carried within HIP field, allowing other arbitrary packets to be carried within HIP
packets. packets.
3.1. Message formats 3.1. Message Formats
3.1.1. HIP fixed header 3.1.1. HIP Fixed Header
The HIP packet format consists of a fixed header followed by a The HIP packet format consists of a fixed header followed by a
variable number of parameters. The parameter format is described in variable number of parameters. The parameter format is described in
Section 3.1.2. Section 3.1.2.
The fixed header is defined in Section 5.1 of [RFC5201] and copied The fixed header is defined in Section 5.1 of [RFC5201] and copied
below. below.
0 1 2 3 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 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
skipping to change at page 4, line 48 skipping to change at page 4, line 48
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ HIP Parameters / / HIP Parameters /
/ / / /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The HIP header is logically an IPv6 extension header. The HIP The HIP header is logically an IPv6 extension header. The HIP
protocol specification [RFC5201] defines handling only for Next specification [RFC5201] defines handling only for Next Header value
Header value decimal 59, IPPROTO_NONE [PROTOCOL-NUMBERS], the IPv6 decimal 59, IPv6-NoNxt [PROTOCOL-NUMBERS], the IPv6 'no next header'
'no next header' value. This document describes processing for Next value. This document describes processing for Next Header values
Header values other than decimal 59 which indicates that there are other than decimal 59, which indicates that there are either more
either more extensions header and/or data following the HIP header. extension headers and/or data following the HIP header.
3.1.2. HIP parameter format 3.1.2. HIP Parameter Format
The HIP parameter format is defined in Section 5.2.1 of [RFC5201], The HIP parameter format is defined in Section 5.2.1 of [RFC5201],
and copied below. and copied below.
0 1 2 3 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 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 | | Type |C| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Contents / / Contents /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type code for the parameter. 16 bits long, C-bit Type Type code for the parameter. 16 bits long, C-bit
being part of the Type code. being part of the Type code.
C Critical. One if this parameter is critical, and C Critical. One if this parameter is critical, and
MUST be recognized by the recipient, zero otherwise. MUST be recognized by the recipient; zero otherwise.
The C bit is considered to be a part of the Type The C bit is considered to be a part of the Type
field. Consequently, critical parameters are always field. Consequently, critical parameters are always
odd and non-critical ones have an even value. odd and non-critical ones have an even value.
Length Length of the Contents, in octets. Length Length of the Contents, in octets.
Contents Parameter specific, defined by Type. Contents Parameter specific, defined by Type.
Padding Padding, 0-7 octets, added if needed. Padding Padding, 0-7 octets, added if needed.
3.2. HIP Base Exchange, Updates, and State Removal 3.2. HIP Base Exchange, Updates, and State Removal
The HIP base exchange is a four-message authentication and key The HIP base exchange is a four-message authentication and key
exchange protocol that creates shared, mutually authenticated keying exchange protocol that creates shared, mutually authenticated keying
material at the communicating parties. These keying materials, material at the communicating parties. These keying materials,
together with associated public keys and IP addresses, form a HIP together with associated public keys and IP addresses, form a HIP
Security Association (SA). The details of the protocol are defined security association (SA). The details of the protocol are defined
in the HIP base exchange specification [RFC5201]. in the HIP base exchange specification [RFC5201].
In addition to creating the HIP SA, the base exchange messages may In addition to creating the HIP SA, the base exchange messages may
carry additional parameters that are used to create additional state. carry additional parameters that are used to create additional state.
For example, the HIP ESP specification [RFC5202] defines how HIP can For example, the HIP ESP specification [RFC5202] defines how HIP can
be used to create end-to-end, host-to-host IPsec ESP Security be used to create end-to-end, host-to-host IPsec ESP security
Associations, used to carry data packets. However, it is important associations, used to carry data packets. However, it is important
to understand that the HIP base exchange is by no means bound to 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 IPsec; using IPsec ESP to carry data traffic forms just a baseline
and ensures interoperability between initial HIP implementations. and ensures interoperability between initial HIP implementations.
Once there is a HIP SA between two HIP-enabled hosts, they can Once there is a HIP SA between two HIP-enabled hosts, they can
exchange further HIP control messages. Typically, UPDATE messages exchange further HIP control messages. Typically, UPDATE messages
are used. For example, the HIP mobility and multihoming are used. For example, the HIP mobility and multihoming
specification [RFC5206] defines how to use UPDATE messages to change specification [RFC5206] defines how to use UPDATE messages to change
the set of IP addresses associated with a HIP SA. the set of IP addresses associated with a HIP SA.
In addition to the base exchange and updates, the HIP base protocol 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 specification also defines how one can remove a HIP SA once it is no
longer needed. longer needed.
4. Definition of the HIP DATA Packet 4. Definition of the HIP_DATA Packet
The HIP DATA packet can be used to convey protocol messages to a The HIP DATA packet can be used to convey protocol messages to a
remote host without running the HIP base exchange between them. HIP remote host without running the HIP base exchange. HIP DATA packets
DATA packets are transmitted reliably, as discussed in Section 5. are transmitted reliably, as discussed in Section 5. The payload of
The payload of a HIP DATA packet is placed after the HIP header and a HIP_DATA packet is placed after the HIP header and protected by a
protected by a PAYLOAD_MIC parameter, which is defined in PAYLOAD_MIC parameter, which is defined in Section 4.3. The
Section 4.3. The following is the definition of the HIP DATA packet following is the definition of the HIP_DATA packet (see the
(see definition of notation in [RFC5201] section 2.2): definition of notation in [RFC5201], Section 2.2):
Header: Header:
Packet Type = [ TBD by IANA: 32 ] Packet Type = 32
SRC HIT = Sender's HIT SRC HIT = Sender's HIT
DST HIT = Receiver's HIT DST HIT = Receiver's HIT
IP ( HIP ( [HOST_ID, ] SEQ_DATA, PAYLOAD_MIC, [ PAYLOAD_MIC, ..., ] IP ( HIP ( [HOST_ID, ] SEQ_DATA, PAYLOAD_MIC, [ PAYLOAD_MIC, ..., ]
HIP_SIGNATURE) PAYLOAD ) HIP_SIGNATURE) PAYLOAD )
IP ( HIP ( [HOST_ID, ] SEQ_DATA, ACK_DATA, PAYLOAD_MIC, IP ( HIP ( [HOST_ID, ] SEQ_DATA, ACK_DATA, PAYLOAD_MIC,
[ PAYLOAD_MIC, ..., ] HIP_SIGNATURE) PAYLOAD ) [ PAYLOAD_MIC, ..., ] HIP_SIGNATURE) PAYLOAD )
IP ( HIP ( [HOST_ID, ] ACK_DATA, HIP_SIGNATURE)) IP ( HIP ( [HOST_ID, ] ACK_DATA, HIP_SIGNATURE))
The SEQ_DATA and ACK_DATA parameters are defined in Section 4.1 and The SEQ_DATA and ACK_DATA parameters are defined in Sections 4.1 and
Section 4.2 respectively. They are used to provide a reliable 4.2, respectively. They are used to provide a reliable delivery of
delivery of HIP DATA packets, as discussed in Section 5. HIP_DATA packets, as discussed in Section 5.
The HOST_ID parameter is defined in Section 5.2.8 of [RFC5201]. This 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 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 HIP_DATA packet's signature and to verify it against the received
signature. The HOST_ID parameter is optional as it MAY have been signature. The HOST_ID parameter is optional as it MAY have been
delivered using out-of-band mechanism to the receiver. If host delivered using out-of-band mechanism to the receiver. If the host
doesn't have reliable information that the corresponding node has its doesn't have reliable information that the corresponding node has its
HOST_ID it MUST always include it in to the packet. If the receiver HOST_ID, it MUST always include the HOST_ID in the packet. If the
is unable to verify the SIGNATURE then the packet MUST be dropped and receiver is unable to verify the SIGNATURE, then the packet MUST be
appropriate NOTIFY packet SHOULD be sent to the sender indicating dropped and the appropriate NOTIFY packet SHOULD be sent to the
AUTHENTICATION_FAILED as described in [RFC5201] section 5.2.16. sender indicating AUTHENTICATION_FAILED as described in [RFC5201],
Section 5.2.16.
The PAYLOAD_MIC parameter is defined in Section 4.3. This parameter The PAYLOAD_MIC parameter is defined in Section 4.3. This parameter
contains the MIC of the payload carried by the HIP DATA packet. The contains the MIC of the payload carried by the HIP_DATA packet. The
PAYLOAD_MIC contains the collision-resistant hash of the payload PAYLOAD_MIC contains the collision-resistant hash of the payload
following after the HIP DATA. The PAYLOAD_MIC is included in the following the HIP DATA. The PAYLOAD_MIC is included in the signed
signed part of the HIP DATA packet giving integrity protection also part of the HIP DATA packet and gives integrity protection for the
for the payload carried after HIP DATA packet. packet as well as the payload carried after it.
The HIP_SIGNATURE parameter is defined in Section 5.2.11. of The HIP_SIGNATURE parameter is defined in Section 5.2.11 of
[RFC5201]. It contains a signature over the contents of the HIP DATA [RFC5201]. It contains a signature over the contents of the HIP_DATA
packet. The calculation and verification of the signature is defined packet. The calculation and verification of the signature is defined
Section 6.4.2. of [RFC5201] in Section 6.4.2. of [RFC5201].
Section 5.3 of [RFC5201] states the following: Section 5.3 of [RFC5201] states the following:
In the future, an OPTIONAL upper-layer payload MAY follow the HIP In the future, an OPTIONAL upper-layer payload MAY follow the HIP
header. The Next Header field in the header indicates if there is header. The Next Header field in the header indicates if there is
additional data following the HIP header. additional data following the HIP header.
We have chosen to place the payload after the HIP extension header We have chosen to place the payload after the HIP extension header
and only to place an MIC of the payload in to the HIP extension and only to place a MIC of the payload into the HIP extension header
header in a PAYLOAD_MIC parameter because that way the data integrity in a PAYLOAD_MIC parameter because that way the data integrity is
is protected by a public key signature with the help of MIC. The protected by a public key signature with the help of the MIC. The
payload that is protected by the PAYLOAD_MIC parameter has been payload that is protected by the PAYLOAD_MIC parameter has been
linked to the appropriate upper-layer protocol by storing the upper- linked to the appropriate upper-layer protocol by storing the upper-
layer protocol number, 8 octets of payload data, and by calculating a layer protocol number, 8 octets of payload data, and by calculating a
hash sum (MIC) over the data. The HIP DATA packet MAY contain one or hash sum (MIC) over the data. The HIP_DATA packet MAY contain one or
more PAYLOAD_MIC parameters each bound to different next header type. more PAYLOAD_MIC parameters, each bound to a different Next Header
The hash algorithm used to generate MIC is same as the algorithm used type. The hash algorithm used to generate the MIC is the same as the
to generate the Host Identity Tag [RFC5201]. algorithm used to generate the Host Identity Tag [RFC5201].
Upper-layer protocol messages, such as overlay network control Upper-layer protocol messages, such as overlay network control
traffic, sent in HIP DATA messages may need to be matched to traffic, sent in HIP DATA messages may need to be matched to
different transactions. For this purpose, a DATA message MAY also different transactions. For this purpose, a DATA message MAY also
contain a TRANSACTION_ID parameter. The identifier value is a contain a TRANSACTION_ID parameter. The identifier value is a
variable length bit string in network-byte-order that is unique for variable length bit string in network byte order that is unique for
each transaction. A response to a request uses the same identifier each transaction. A response to a request uses the same identifier
value allowing the receiver to match requests to responses. value, thereby allowing the receiver to match requests to responses.
4.1. Definition of the SEQ_DATA Parameter 4.1. Definition of the SEQ_DATA Parameter
The following is the definition of the SEQ_DATA parameter: The following is the definition of the SEQ_DATA parameter:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number | | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: Type 4481
4481 = (2^12 + 2^8 + 2^7 + 1) ] Length 4
Length 4 Sequence number 32-bit unsigned integer in network byte order that
Sequence number 32-bit unsigned integer in network byte order which MUST NOT be reused before it has been acknowledged
MUST NOT reused before it has been acknowledged by by the receiver.
the receiver.
This parameter has critical bit set and if it is not supported by the This parameter has the critical bit set. If it is not supported by
receiver packet MUST be dropped and appropriate NOTIFY packet SHOULD the receiver, the packet MUST be dropped and the appropriate NOTIFY
be sent to the sender indicating UNSUPPORTED_CRITICAL_PARAMETER_TYPE packet SHOULD be sent to the sender indicating
as described in [RFC5201] section 5.2.16. UNSUPPORTED_CRITICAL_PARAMETER_TYPE as described in [RFC5201],
Section 5.2.16.
4.2. Definition of the ACK_DATA Parameter 4.2. Definition of the ACK_DATA Parameter
The following is the definition of the ACK_DATA parameter: The following is the definition of the ACK_DATA parameter:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acked Sequence number / | Acked Sequence number /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: Type 4545
4545 = (2^12 + 2^8 + 2^7 + 2^6 + 1) ]
Length variable (multiple of 4) Length variable (multiple of 4)
Acked Sequence number A sequence of 32-bit unsigned integers in Acked Sequence number A sequence of 32-bit unsigned integers in
network byte order corresponding to the network byte order corresponding to the
sequence numbers being acknowledged sequence numbers being acknowledged.
This parameter has critical bit set and if it is not supported by the This parameter has the critical bit set. If it is not supported by
receiver packet MUST be dropped and appropriate NOTIFY packet SHOULD the receiver, the packet MUST be dropped and the appropriate NOTIFY
be sent to the sender indicating UNSUPPORTED_CRITICAL_PARAMETER_TYPE packet SHOULD be sent to the sender indicating
as described in [RFC5201] section 5.2.16. UNSUPPORTED_CRITICAL_PARAMETER_TYPE as described in [RFC5201],
Section 5.2.16.
4.3. Definition of the PAYLOAD_MIC Parameter 4.3. Definition of the PAYLOAD_MIC Parameter
The following is the definition of the PAYLOAD_MIC parameter: The following is the definition of the PAYLOAD_MIC parameter:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next header | Reserved | | Next Header | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data | | Payload Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ MIC Value / / MIC Value /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: Type 4577
4577 = (2^12 + 2^8 + 2^7 + 2^6 + 2^5 + 1) ] Length Length in octets, excluding Type, Length, and
Length length in octets, excluding Type, Length, and
Padding. Padding.
Next Header Identifies the data that is protected by this MIC. Next Header Identifies the data that is protected by this MIC.
The values for this field are defined by IANA The values for this field are defined by IANA
"Protocol Numbers" [PROTOCOL-NUMBERS] "Protocol Numbers" [PROTOCOL-NUMBERS].
Payload Data 8 last octets of the payload data over which the Payload Data Last 8 octets of the payload data over which the
MIC is calculated. This field is used to MIC is calculated. This field is used to
uniquely bind PAYLOAD_MIC parameter to next header, uniquely bind the PAYLOAD_MIC parameter to the Next
in case there are multiple copies of same type. Header, in case there are multiple copies of the
same type.
MIC Value MIC computed over the data to which the Next MIC Value MIC computed over the data to which the Next
Header and Payload Data points. The size of Header and Payload Data point. The size of the MIC
the MIC is the natural size of the computation is the natural size of the computation output
output depending on the function used. depending on the function used.
This parameter has critical bit set and if it is not supported by the This parameter has the critical bit set. If it is not supported by
receiver packet MUST be dropped and appropriate NOTIFY packet SHOULD the receiver, the packet MUST be dropped and the appropriate NOTIFY
be sent to the sender indicating UNSUPPORTED_CRITICAL_PARAMETER_TYPE packet SHOULD be sent to the sender indicating
as described in [RFC5201] section 5.2.16. UNSUPPORTED_CRITICAL_PARAMETER_TYPE as described in [RFC5201],
Section 5.2.16.
There is a theoretical possibility that when generating multiple There is a theoretical possibility that when generating multiple
PAYLOAD_MIC parameters that will be carried in a single packet would PAYLOAD_MIC parameters that will be carried in a single packet, they
have identical Next Header and Payload Data fields thus it is would have identical Next Header and Payload Data fields; thus, it is
required that PAYLOAD_MIC parameters MUST follow the natural order of required that PAYLOAD_MIC parameters MUST follow the natural order of
extensions headers in the packet making it possible to bind extension headers in the packet so that it's possible to bind
PAYLOD_MICs to correct payload data. In case the receiving host is PAYLOAD_MICs to correct payload data. In case the receiving host is
still unable to identify the payloads, it MUST drop the packet and still unable to identify the payloads, it MUST drop the packet and
SHOULD send a NOTIFY packet to the sender indicating INVALID_SYNTAX SHOULD send a NOTIFY packet to the sender indicating INVALID_SYNTAX
as described in [RFC5201] section 5.2.16. as described in [RFC5201], Section 5.2.16.
4.4. Definition of the TRANSACTION_ID Parameter 4.4. Definition of the TRANSACTION_ID Parameter
The following is the definition of the TRANSACTION_ID parameter: The following is the definition of the TRANSACTION_ID parameter:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier / | Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding | / | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA; Type 4580
4580 = (2^12 + 2^8 + 2^7 + 2^6 + 2^5 + 2^2 ) ] Length Length of the Identifier, in octets
Length Length of the Identifier in octets
Identifier The identifier value Identifier The identifier value
Padding 0-7 octets of padding if needed Padding 0-7 octets of padding if needed
Figure 1: Format of the TRANSACTION_ID parameter Figure 1
5. Generation and Reception of HIP DATA Packets 5. Generation and Reception of HIP_DATA Packets
HIP DATA packets are transmitted reliably. Reliable delivery is HIP_DATA packets are transmitted reliably. Reliable delivery is
achieved through the use of retransmissions and of the SEQ_DATA and achieved through the use of retransmissions and of the SEQ_DATA and
ACK_DATA parameters. ACK_DATA parameters.
5.1. Handling of SEQ_DATA and ACK_DATA 5.1. Handling of SEQ_DATA and ACK_DATA
A HIP DATA packet MUST contain at least one of a SEQ_DATA or an A HIP_DATA packet MUST contain at least one of a SEQ_DATA or an
ACK_DATA parameter; if both parameters are missing, then packet MUST ACK_DATA parameter; if both parameters are missing, then packet MUST
be dropped as invalid. be dropped as invalid.
A HIP DATA packet containing SEQ_DATA parameter MUST contain one or A HIP_DATA packet containing a SEQ_DATA parameter MUST contain one or
more PAYLOAD_MIC parameter or otherwise packet MUST be dropped. The more PAYLOAD_MIC parameters; otherwise, the packet MUST be dropped.
presence of a SEQ_DATA parameter indicates that the receiver MUST ACK The presence of a SEQ_DATA parameter indicates that the receiver MUST
the HIP DATA packet. A HIP DATA packet that does not contain a 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 SEQ_DATA parameter is simply an ACK of a previous HIP_DATA packet,
MUST NOT be ACKed. and it MUST NOT be ACKed.
A HIP DATA packet containing ACK_DATA parameter echoes the SEQ_DATA A HIP_DATA packet containing an ACK_DATA parameter echoes the
sequence numbers of the HIP DATA packet packets being acknowledged. SEQ_DATA sequence numbers of the HIP_DATA packets being acknowledged.
ACK_DATA parameter MUST acknowledge at least one SEQ_DATA sequence The ACK_DATA parameter MUST acknowledge at least one SEQ_DATA
number and MAY acknowledge multiple SEQ_DATA sequence numbers by sequence number and MAY acknowledge multiple SEQ_DATA sequence
adding all of them to the ACK_DATA parameter numbers by adding all of them to the ACK_DATA parameter.
A HIP DATA packet MAY contain both a SEQ_DATA and an ACK_DATA 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 parameter. In this case, the ACK is being piggybacked on an outgoing
HIP DATA packet. In general, HIP DATA packets carrying SEQ_DATA HIP_DATA packet. In general, HIP_DATA packets carrying SEQ_DATA
SHOULD be ACKed upon completion of the processing of the HIP 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 packet. A host MAY choose to hold the HIP DATA packet carrying an
for a short period of time to allow for the possibility of ACK for a short period of time to allow for the possibility of
piggybacking the ACK parameter, in a manner similar to TCP delayed piggybacking the ACK_DATA parameter, in a manner similar to TCP
acknowledgments. delayed acknowledgments.
5.2. Generation of a HIP DATA packet 5.2. Generation of a HIP_DATA Packet
When a host has upper-layer protocol data to send, it either runs the 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 HIP base exchange and sends the data over a SA, or sends the data
directly using a HIP DATA packet. Section 6 discusses when it is directly using a HIP_DATA packet. Section 6 discusses when it is
appropriate to use each method. This section discusses the case when 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 the host chooses to use a HIP_DATA packet to send the upper-layer
protocol data. protocol data.
1. The host creates a HIP DATA packet that contains a SEQ_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. The host is free to choose any value for the SEQ_DATA
sequence number in the first HIP DATA packet it sends to a sequence number in the first HIP_DATA packet it sends to a
destination. After that first packet, the host MUST choose the destination. After that first packet, the host MUST choose the
value of the SEQ_DATA sequence number in subsequent HIP DATA value of the SEQ_DATA sequence number in subsequent HIP_DATA
packets to the same destination so that no SEQ_DATA sequence packets to the same destination so that no SEQ_DATA sequence
number is reused before the receiver has closed the processing number is reused before the receiver has closed the processing
window for the previous packet using the same SEQ_DATA sequence window for the previous packet using the same SEQ_DATA sequence
number. Practically, giving the values of the retransmission number. Practically, giving the values of the retransmission
timers used with HIP DATA packets, this means that hosts must timers used with HIP_DATA packets, this means that hosts must
wait the maximum likely lifetime of the packet before reusing a wait the maximum likely lifetime of the packet before reusing a
given SEQ_DATA sequence number towards a given destination. given SEQ_DATA sequence number towards a given destination.
However, it is not required for node to know the maximum packet However, it is not required for the node to know the maximum
lifetime. Rather, it is assumed that the requirement can be met packet lifetime. Rather, it is assumed that the requirement can
by maintaining the value as a simple, 32-bit, "wrap-around" be met by maintaining the value as a simple, 32-bit, "wrap-
counter, incremented each time a packet is sent. It is an around" counter, incremented each time a packet is sent. It is
implementation choice whether to maintain a single counter for an implementation choice whether to maintain a single counter for
the node or multiple counters (one for each source HIT, the node or multiple counters (one for each <source, destination>
destination HIT combination). HIT pair).
2. The host creates PAYLOAD_MIC parameter. MIC is a hash calculated
over the whole PAYLOAD which the Next Header field of PAYLOAD_MIC
parameter indicates. If there is multiple next header types
which the host wants to protect it SHOULD create separate
PAYLOAD_MIC parameter for each of these. The receiver MUST
validate all these MICs as described in Section 5.3.1. For
calculating MIC 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 2. The host creates the PAYLOAD_MIC parameter. The MIC is a hash
calculated over the whole PAYLOAD that the Next Header field of
the PAYLOAD_MIC parameter indicates. If there are multiple Next
Header types that the host wants to protect, it SHOULD create
separate PAYLOAD_MIC parameters for each of these. The receiver
MUST validate all these MICs as described in Section 5.3.1. For
calculating the MIC, 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 the HIP_SIGNATURE parameter. The signature is
calculated over the whole HIP envelope, excluding any parameters calculated over the whole HIP envelope, excluding any parameters
after the HIP_SIGNATURE, as defined in Section 5.2.11. of after the HIP_SIGNATURE, as defined in Section 5.2.11. of
[RFC5201]. The receiver MUST validate this signature. It MAY [RFC5201]. The receiver MUST validate this signature. It MAY
use either the HI in the packet or the HI acquired by some other use either the HI in the packet or the HI acquired by some other
means. means.
4. The hosts sends the created HIP DATA packet and starts a DATA
4. The host sends the created HIP_DATA packet and starts a DATA
timer. The default value for the timer is 3 seconds. If timer. The default value for the timer is 3 seconds. If
multiple HIP DATA packets are outstanding, multiple timers are in multiple HIP DATA packets are outstanding, multiple timers are in
effect. effect.
5. If the DATA timer expires, the HIP DATA packet is resent. The
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 HIP DATA packet can be resent DATA_RETRY_MAX times. The DATA
timer MUST be exponentially backed off for subsequent timer MUST be exponentially backed off for subsequent
retransmissions. If no acknowledgment is received from the peer retransmissions. If no acknowledgment is received from the peer
after DATA_RETRY_MAX times, the delivery of the HIP DATA packet after DATA_RETRY_MAX times, the delivery of the HIP_DATA packet
is considered unsuccessful and the application is notified about is considered unsuccessful and the application is notified about
the error. The DATA timer is canceled upon receiving an ACK from the error. The DATA timer is canceled upon receiving an ACK from
the peer that acknowledges receipt of the HIP DATA packet. The the peer that acknowledges receipt of the HIP_DATA packet. The
default value for DATA_RETRY_MAX SHOULD be 5 retries, but it MAY default value for DATA_RETRY_MAX SHOULD be 5 retries, but it MAY
be changed through local policy. be changed through local policy.
5.3. Reception of a HIP DATA packet 5.3. Reception of a HIP_DATA Packet
A host receiving a HIP DATA packet makes a decision whether to A host receiving a HIP_DATA packet makes a decision whether or not to
process the packet or not. If the host, following its local policy, process the packet. If the host, following its local policy,
suspects that this packet could be part of a DoS attack. The host suspects that this packet could be part of a DoS attack. The host
MAY respond with an R1 packet to the HIP DATA packet, if the packet MAY respond with an R1 packet to the HIP_DATA packet, if the packet
contained SEQ_DATA and PAYLOAD_MIC parameter, in order to indicate contained SEQ_DATA and PAYLOAD_MIC parameters, in order to indicate
that HIP base exchange MUST be completed before accepting payload that HIP base exchange MUST be completed before accepting payload
packets from the originator of the HIP DATA packet. If the host packets from the originator of the HIP_DATA packet.
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 From RFC 5201 (Section 4.1):
in [RFC5201] Section 5.3.2. The host SHOULD drop the received data
packet if it responded with a R1 packet to the HIP_DATA packet. The The HIP base exchange serves to manage the establishment of
sender of HIP_DATA packet is responsible for retransmission of the state between an Initiator and a Responder. The first packet,
upper-layer protocol data after successful completion of the HIP Base I1, initiates the exchange, and the last three packets, R1, I2,
Exchange. and R2, constitute an authenticated Diffie-Hellman [DIF76] key
exchange for session key generation.
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. The host SHOULD drop the
received data packet if it responded with an R1 packet to the
HIP_DATA packet. The sender of HIP_DATA packet is responsible for
retransmission of the upper-layer protocol data after successful
completion of the HIP base exchange.
If the host, following its local policy, decides to process the If the host, following its local policy, decides to process the
incoming HIP DATA packet, it processes it according to the following incoming HIP_DATA packet, it processes the packet according to the
rules: following rules:
1. If the HIP DATA packet contains a SEQ_DATA parameter and no 1. If the HIP_DATA packet contains a SEQ_DATA parameter and no
ACK_DATA parameter, the HIP DATA packet is processed and replied ACK_DATA parameter, the HIP_DATA packet is processed and replied
to as described in Section 5.3.1. to as described in Section 5.3.1.
2. If the HIP DATA packet contains an ACK_DATA parameter and no
SEQ_DATA parameter, the HIP DATA packet is processed as described 2. If the HIP_DATA packet contains an ACK_DATA parameter and no
SEQ_DATA parameter, the HIP_DATA packet is processed as described
in Section 5.3.2. in Section 5.3.2.
3. If the HIP DATA packet contains both a SEQ_DATA parameter and an 3. If the HIP_DATA packet contains both a SEQ_DATA parameter and an
ACK_DATA parameter, the HIP DATA packet is processed first as ACK_DATA parameter, the HIP_DATA packet is processed first as
described in Section 5.3.2 and then the rest of the HIP DATA described in Section 5.3.2, and then the rest of the HIP_DATA
packet is processed and replied to as described in Section 5.3.1. packet is processed and replied to as described in Section 5.3.1.
5.3.1. Handling of SEQ_DATA in a Received HIP DATA packet 5.3.1. Handling of SEQ_DATA in a Received HIP_DATA Packet
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
handling a SEQ_DATA parameter in a received HIP DATA packet. handling a SEQ_DATA parameter in a received HIP_DATA packet.
The system MUST verify the SIGNATURE in the HIP DATA packet. If the The system MUST verify the SIGNATURE in the HIP_DATA packet. If the
verification fail, the packet SHOULD be dropped and an error message verification fails, the packet SHOULD be dropped and an error message
logged. logged.
If the value in the received SEQ_DATA and MIC value received If the value in the received SEQ_DATA and the MIC value in the
PAYLOAD_MIC corresponds to a HIP DATA packet that has recently been received PAYLOAD_MIC correspond to a HIP_DATA packet that has
processed, the packet is treated as a retransmission. It is recently been processed, the packet is treated as a retransmission.
recommended that a host cache HIP DATA packets with ACKs to avoid the It is recommended that a host cache HIP_DATA packets with ACKs to
cost of generating a new ACK packet to respond to a retransmitted HIP avoid the cost of generating a new ACK packet to respond to a
DATA packet. The host MUST acknowledge, again, such (apparent) HIP retransmitted HIP_DATA packet. The host MUST acknowledge, again,
DATA packet retransmissions but SHOULD also consider rate-limiting such (apparent) HIP_DATA packet retransmissions but SHOULD also
such retransmission responses to guard against replay attacks. consider rate-limiting such retransmission responses to guard against
replay attacks.
The system MUST verify the PAYLOAD_MIC by calculating MIC over the The system MUST verify the PAYLOAD_MIC by calculating the MIC over
PAYLOAD which the Next Header field indicates. For calculating the the PAYLOAD that the Next Header field indicates. For calculating
MIC the host will use the same hash algorithm that has been used to the MIC, the host will use the same hash algorithm that has been used
generate the sender's HIT as defined in Section 3.2. of [RFC5201]. to generate the sender's HIT as defined in Section 3.2. of [RFC5201].
If the packet carried multiple PAYLOAD_MIC parameters each of them If the packet carried multiple PAYLOAD_MIC parameters, each of them
are verified as described above. If one or more of the verification are verified as described above. If one or more of the verifications
fails, the packet SHOULD be dropped and an error message logged. fail, the packet SHOULD be dropped and an error message logged.
If a new SEQ parameter is being processed, the parameters in the HIP If a new SEQ parameter is being processed, the parameters in the HIP
DATA packet are then processed. DATA packet are then processed.
A HIP DATA packet with an ACK_DATA parameter is prepared and sent to 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 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 DATA packet or piggybacked in a HIP_DATA packet with a SEQ_DATA
parameter. The ACK_DATA parameter MAY acknowledge more than one of parameter. The ACK_DATA parameter MAY acknowledge more than one of
the peer's HIP DATA packets. the peer's HIP_DATA packets.
5.3.2. Handling of ACK_DATA in a Received HIP DATA packet 5.3.2. Handling of ACK_DATA in a Received HIP_DATA Packet
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
handling an ACK_DATA parameter in a received HIP DATA packet. handling an ACK_DATA parameter in a received HIP_DATA packet.
The system MUST verify the SIGNATURE in the HIP DATA packet. If the The system MUST verify the SIGNATURE in the HIP_DATA packet. If the
verification fails, the packet SHOULD be dropped and an error message verification fails, the packet SHOULD be dropped and an error message
logged. logged.
The sequence numbers reported in the ACK_DATA must match with an The sequence numbers reported in the ACK_DATA must match with a
previously sent HIP DATA packet containing SEQ_DATA that has not previously sent HIP_DATA packet containing SEQ_DATA that has not
already been acknowledged. If no match is found or if the ACK_DATA already been acknowledged. If no match is found or if the ACK_DATA
does not acknowledge a new HIP DATA packets, the packet MUST either does not acknowledge a new HIP_DATA packet, the packet either MUST be
be dropped if no SEQ_DATA parameter is present, or the processing dropped if no SEQ_DATA parameter is present or the processing steps
steps in Section 5.3.1 are followed. in Section 5.3.1 are followed.
The corresponding DATA timer is stopped so that the now acknowledged The corresponding DATA timer is stopped so that the now acknowledged
HIP DATA packet is no longer retransmitted. If multiple HIP DATA HIP_DATA packet is no longer retransmitted. If multiple HIP_DATA
packets are newly acknowledged, multiple timers are stopped. packets are newly acknowledged, multiple timers are stopped.
6. Use of the HIP DATA Packet 6. Use of the HIP_DATA Packet
HIP currently requires that the four-message base exchange is HIP currently requires that the four-message base exchange is
executed at the first encounter of hosts that have not communicated executed at the first encounter of hosts that have not communicated
before. This may add additional RTTs (Round Trip Time) to protocols before. This may add additional RTTs (Round-Trip Times) to protocols
based on a single message exchange. However, the four-message based on a single message exchange. However, the four-message
exchange is essential to preserve the DoS protection nature of the exchange is essential to preserve the DoS protection nature of the
base exchange. The use of the HIP DATA packet defined in this base exchange. The use of the HIP_DATA packet defined in this
document reduces the initial overhead in the communications between document reduces the initial overhead in the communications between
two hosts. However, the HIP DATA packet itself does not provide any two hosts. However, the HIP_DATA packet itself does not provide any
protection against DoS attacks. Therefore, the HIP DATA packet MUST protection against DoS attacks. Therefore, the HIP_DATA packet MUST
only be used in environment whose policies provide protection against only be used in environments whose policies provide protection
DoS attacks. For example, a HIP-based overlay may have policies in against DoS attacks. For example, a HIP-based overlay may have
place to control which nodes can join the overlay. However, policies in place to control which nodes can join the overlay.
authorization who is allowed to join the overlay is beyond the scope However, authorization of who is allowed to join the overlay is
of this specification. Any particular node in the overlay may want beyond the scope of this specification. Any particular node in the
to accept HIP DATA packets from other nodes in the overlay given that overlay may want to accept HIP_DATA packets from other nodes in the
those other nodes were authorized to join the overlay. However, the overlay, given that those other nodes were authorized to join the
same node will not accept HIP DATA packets from random nodes that are overlay. However, the same node will not accept HIP_DATA packets
not part of the overlay. Additionally, the HIP DATA packet itself from random nodes that are not part of the overlay. Additionally,
does not provide confidentiality for its payload. Therefore, the HIP the HIP_DATA packet itself does not provide confidentiality for its
DATA packet MUST NOT be used in environments that do not provide an payload. Therefore, the HIP_DATA packet MUST NOT be used in
appropriate level of confidentiality (e.g., a HIP-based overlay MUST environments that do not provide an appropriate level of
NOT send HIP DATA packets unless the connections between overlay confidentiality (e.g., a HIP-based overlay MUST NOT send HIP_DATA
nodes are encrypted). packets unless the connections between overlay nodes are encrypted).
The type of data to be sent is also relevant to whether the use of a 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 HIP_DATA packet is appropriate. HIP itself does not support
fragmentation but relies on underlying IP-layer fragmentation. This fragmentation but relies on underlying IP-layer fragmentation. This
may lead to reliability problems in the case where a message cannot may lead to reliability problems in the case where a message cannot
be easily split over multiple HIP messages. Therefore, applications be easily split over multiple HIP messages. Therefore, applications
in environments where fragmentation could be an issue SHOULD NOT in environments where fragmentation could be an issue SHOULD NOT
generate too large HIP DATA packets that may lead to fragmentation. generate large HIP_DATA packets that may lead to fragmentation. The
The implementation SHOULD check the MTU of the link before sending implementation SHOULD check the MTU of the link before sending the
the packet and if the packet size is larger than MTU it SHOULD signal packet, and if the packet size is larger than MTU, it SHOULD signal
to the upper-layer protocol if the packet results in to a ICMP error to the upper-layer protocol if the packet results in an ICMP error
message. Note that there are environments where fragmentation is not message. Note that there are environments where fragmentation is not
an issue. For example, in some HIP-based overlays, nodes can an issue. For example, in some HIP-based overlays, nodes can
exchange HIP DATA packets on top of TCP connections that provide exchange HIP_DATA packets on top of TCP connections that provide
transport-level fragmentation and, thus, avoid IP-level transport-level fragmentation and, thus, avoid IP-level
fragmentation. fragmentation.
HIP currently requires that all messages excluding I1s but including HIP currently requires that all messages excluding I1s but including
HIP DATA packets are digitally signed. This adds to the packet size HIP_DATA packets are digitally signed. This adds to the packet size
and the processing capacity needed to send packets. However, in and the processing capacity needed to send packets. However, in
applications where security is not paramount, it is possible to use applications where security is not paramount, it is possible to use
very short keys, thereby reducing resource consumption. very short keys, thereby reducing resource consumption.
7. Security considerations 7. Security Considerations
HIP is designed to provide secure authentication of hosts. HIP also HIP is designed to provide secure authentication of hosts. HIP also
attempts to limit the exposure of the host to various denial-of- attempts to limit the exposure of the host to various denial-of-
service and man-in-the-middle (MitM) attacks. However, HIP DATA service and man-in-the-middle (MitM) attacks. However, HIP_DATA
packet, which can be sent without running the HIP base exchange packet, which can be sent without running the HIP base exchange
between hosts has a trade off that it does not provide the denial-of- between hosts has a trade-off that it does not provide the denial-of-
service protection or confidentiality protection that HIP generally service protection or confidentiality protection that HIP generally
provides. Thus, the host should consider always situations where it provides. Thus, the host should consider always situations where it
is appropriate to send or receive HIP DATA packet. If the is appropriate to send or receive HIP_DATA packet. If the
communication consists more than few round-trips of data or the data communication consists more than few round trips of data or the data
is highly sensitive in nature the host SHOULD run the base exchange is highly sensitive in nature the host SHOULD run the base exchange
with the peer host. with the peer host.
HIP DATA packet is designed to protect hosts from second preimage HIP_DATA packet is designed to protect hosts from second preimage
attacks allowing receiving host to be able to detect, if the message attacks allowing receiving host to be able to detect, if the message
was tampered during the transport. This property is also know as was tampered during the transport. This property is also know as
weak-collision-resistance. If a host tries to generate a second "weak collision-resistance". If a host tries to generate a second
preimage it would need to generate such second image where 8 last preimage, it would need to generate it such that the last 8 octets
octets are matching with original message. match with the original message.
When handling the PAYLOAD_MIC parameter in the receiving host, using When handling the PAYLOAD_MIC parameter in the receiving host, using
the 8-last octets to identify the upper layer protocol doesn't give the last 8 octets to identify the upper-layer protocol doesn't give
any guarantee that the MIC would be correct thus an attacker could any guarantee that the MIC would be correct; thus, an attacker could
send packets where the next header and last 8-octets matches to the send packets where the next header and last 8 octets match the values
values carried by PAYLOAD_MIC parameter and thus it is always carried by the PAYLOAD_MIC parameter. Therefore, it is always
mandatory to verify the MIC value by calculating the hash over the mandatory to verify the MIC value by calculating the hash over the
payload. payload.
8. IANA considerations 8. IANA Considerations
This document updates the IANA Registry for HIP Packet types by This document updates the IANA registry for HIP packet types by
introducing new packet type for the new HIP_DATA (Section 4) packet. introducing a new packet type for the HIP_DATA (Section 4) packet.
This document updates the IANA Registry for HIP Parameter Types by This document updates the IANA registry for HIP parameter types by
introducing new parameter values for the SEQ_DATA (Section 4.1), introducing new parameter values for the SEQ_DATA (Section 4.1),
ACK_DATA (Section 4.2), PAYLOAD_MIC (Section 4.3), and TRANSACTION_ID ACK_DATA (Section 4.2), PAYLOAD_MIC (Section 4.3), and TRANSACTION_ID
(Section 4.4) parameters. (Section 4.4) parameters.
9. Acknowledgments 9. Acknowledgments
Pekka Nikander was one of the original authors of the draft. Also, Pekka Nikander was one of the original authors of the document.
in the usual IETF fashion, a large number of people have contributed Also, in the usual IETF fashion, a large number of people have
to the actual text or ideas. The list of these people include Miika contributed to the actual text or ideas. The list of these people
Komu, Tobias Heer, Ari Keranen, Samu Varjonen, Thomas Henderson, and include Miika Komu, Tobias Heer, Ari Keranen, Samu Varjonen, Thomas
Jukka Ylitalo. Our apologies to anyone whose name is missing. Henderson, and Jukka Ylitalo. Our apologies to anyone whose name is
missing.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997. Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T.
"Host Identity Protocol", RFC 5201, April 2008. Henderson, "Host Identity Protocol", RFC 5201,
April 2008.
[PROTOCOL-NUMBERS] [PROTOCOL-NUMBERS] IANA, "Protocol Numbers", <http://www.iana.org>.
IANA, "Protocol Numbers",
<http://www.iana.org/assignments/protocol-numbers>.
10.2. Informative references 10.2. Informative references
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander,
Encapsulating Security Payload (ESP) Transport Format with "Using the Encapsulating Security Payload (ESP)
the Host Identity Protocol (HIP)", RFC 5202, April 2008. Transport Format with the Host Identity Protocol
(HIP)", RFC 5202, April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J.
Host Mobility and Multihoming with the Host Identity Arkko, "End-Host Mobility and Multihoming with
Protocol", RFC 5206, April 2008. the Host Identity Protocol", RFC 5206, April
2008.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com EMail: Gonzalo.Camarillo@ericsson.com
Jan Melen Jan Melen
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Jan.Melen@ericsson.com EMail: Jan.Melen@ericsson.com
 End of changes. 127 change blocks. 
342 lines changed or deleted 354 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/