draft-ietf-hip-hiccups-01.txt   draft-ietf-hip-hiccups-02.txt 
HIP Working Group P. Nikander HIP Working Group G. Camarillo
Internet-Draft G. Camarillo Internet-Draft J. Melen
Intended status: Experimental J. Melen Intended status: Experimental Ericsson
Expires: July 30, 2010 Ericsson Expires: September 5, 2010 March 4, 2010
January 26, 2010
HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper-
layer Protocol Signaling (HICCUPS) layer Protocol Signaling (HICCUPS)
draft-ietf-hip-hiccups-01 draft-ietf-hip-hiccups-02
Abstract Abstract
This document defines a new HIP (Host Identity Protocol) packet type This document defines a new HIP (Host Identity Protocol) packet type
called DATA. HIP DATA packets are used to securely and reliably called DATA. HIP DATA packets are used to securely and reliably
convey arbitrary protocol messages over the Internet and various convey arbitrary protocol messages over the Internet and various
overlay networks. overlay networks.
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 30, 2010. This Internet-Draft will expire on September 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 17 skipping to change at page 2, line 16
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 BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 3 3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Message formats . . . . . . . . . . . . . . . . . . . . . 3 3.1. Message formats . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. HIP fixed header . . . . . . . . . . . . . . . . . . . 3 3.1.1. HIP fixed header . . . . . . . . . . . . . . . . . . . 4
3.1.2. HIP parameter format . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . 7
4.2. Definition of the ACK_DATA Parameter . . . . . . . . . . . 7 4.2. Definition of the ACK_DATA Parameter . . . . . . . . . . . 7
4.3. Definition of the PAYLOAD_MAC Parameter . . . . . . . . . 8 4.3. Definition of the PAYLOAD_MIC Parameter . . . . . . . . . 8
4.4. Definition of the TRANSACTION_ID Parameter . . . . . . . . 9 4.4. Definition of the TRANSACTION_ID Parameter . . . . . . . . 9
5. Generation and Reception of HIP DATA Packets . . . . . . . . . 9 5. Generation and Reception of HIP DATA Packets . . . . . . . . . 9
5.1. Handling of SEQ_DATA and ACK_DATA . . . . . . . . . . . . 9 5.1. Handling of SEQ_DATA and ACK_DATA . . . . . . . . . . . . 9
5.2. Generation of a HIP DATA packet . . . . . . . . . . . . . 10 5.2. Generation of a HIP DATA packet . . . . . . . . . . . . . 10
5.3. Reception of a HIP DATA packet . . . . . . . . . . . . . . 11 5.3. Reception of a HIP DATA packet . . . . . . . . . . . . . . 11
5.3.1. Handling of SEQ_DATA in a Received HIP DATA packet . . 11 5.3.1. Handling of SEQ_DATA in a Received HIP DATA packet . . 12
5.3.2. Handling of ACK_DATA in a Received HIP DATA packet . . 12 5.3.2. Handling of ACK_DATA in a Received HIP DATA packet . . 12
6. Use of the HIP DATA Packet . . . . . . . . . . . . . . . . . . 12 6. Use of the HIP DATA Packet . . . . . . . . . . . . . . . . . . 13
7. Security considerations . . . . . . . . . . . . . . . . . . . 13 7. Security considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative references . . . . . . . . . . . . . . . . . . 14 10.2. Informative references . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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 secure and reliable way) protocol messages to a remote convey (in a secure and reliable way) protocol messages to a remote
host without running the HIP base exchange between them. We also host without running the HIP base exchange between them. HIP DATA
discuss the trade offs involved in using this packet (i.e., less packet has following semantics: unordered, duplicate free, reliable,
overhead but also less DoS protection) and the situations where it is and authenticated message-based delivery service. We also discuss
appropriate to use this packet. The HIP_DATA packet is not aimed to the trade offs involved in using this packet (i.e., less overhead but
be a replacement for ESP transport instead it SHOULD only be used to also less DoS protection) and the situations where it is appropriate
to use this packet. The HIP_DATA packet is not aimed to be a
replacement for ESP transport instead it SHOULD only be used to
exchange few packets between the peers. If a continuous exchange few packets between the peers. If a continuous
communication is required hosts SHOULD run the HIP base exchange to communication is required hosts SHOULD run the HIP base exchange to
set up ESP security association. set up ESP security association. Additionally APIs to higher-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].
Message Integrity Code (MIC) is a hash sum calculated over the
message which is being integrity protected. MIC does not use
secret keys and thus need be protected otherwise against
tampering. Essentially MIC is same as MAC with the distinction
that MIC does not use secret key. MIC is also often referred as
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 protocol specification [RFC5201] defines a number of messages
and parameters. The parameters are encoded as TLVs, as shown in and 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
skipping to change at page 6, line 11 skipping to change at page 6, line 12
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 between them. HIP
DATA packets are transmitted reliably, as discussed in Section 5. DATA packets are transmitted reliably, as discussed in Section 5.
The payload of a HIP DATA packet is placed after the HIP header and The payload of a HIP DATA packet is placed after the HIP header and
protected by a PAYLOAD_MAC parameter, which is defined in protected by a PAYLOAD_MIC parameter, which is defined in
Section 4.3. The following is the definition of the HIP DATA packet: Section 4.3. The following is the definition of the HIP DATA packet:
Header: Header:
Packet Type = [ TBD by IANA: 32 ] Packet Type = [ TBD by IANA: 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_MAC, IP ( HIP ( [HOST_ID, ] SEQ_DATA, PAYLOAD_MIC,
HIP_SIGNATURE) PAYLOAD ) HIP_SIGNATURE) PAYLOAD )
IP ( HIP ( [HOST_ID, ] SEQ_DATA, ACK_DATA, PAYLOAD_MAC, IP ( HIP ( [HOST_ID, ] SEQ_DATA, ACK_DATA, PAYLOAD_MIC,
HIP_SIGNATURE) PAYLOAD ) 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 Section 4.1 and
Section 4.2 respectively. They are used to provide a reliable Section 4.2 respectively. They are used to provide a reliable
delivery of HIP DATA packets, as discussed in Section 5. delivery of 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. signature.
The PAYLOAD_MAC parameter is defined in Section 4.3. This parameter The PAYLOAD_MIC parameter is defined in Section 4.3. This parameter
contains the HMAC of the payload carried by the HIP DATA packet. The contains the MIC of the payload carried by the HIP DATA packet. The
PAYLOAD_MAC contains the checksum of the payload following after the PAYLOAD_MIC contains the checksum of the payload following after the
HIP DATA. The PAYLOAD_MAC is included in the signed part of the HIP HIP DATA. The PAYLOAD_MIC is included in the signed part of the HIP
DATA packet giving integrity protection also for the payload carried DATA packet giving integrity protection also for the payload carried
after HIP DATA packet. after HIP DATA packet.
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] 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 HMAC of the payload in to the HIP extension and only to place an MIC of the payload in to the HIP extension
header in a PAYLOAD_MAC parameter because that way the data is header in a PAYLOAD_MIC parameter because that way the data integrity
protected by a public key signature with help of HMAC. The payload is protected by a public key signature with help of MIC. The payload
that is protected by the PAYLOAD_MAC parameter has been linked to the that is protected by the PAYLOAD_MIC parameter has been linked to the
appropriate upper-layer protocol by storing the upper-layer protocol appropriate upper-layer protocol by storing the upper-layer protocol
number, 8 bytes of payload data, and by calculating an HMAC over the number, 8 bytes of payload data, and by calculating a hash sum (MIC)
data. The HMAC algorithm is same as the algorithm used to generate over the data. HIP DATA packet MAY contain one or more PAYLOAD_MIC
the Host Identity Tag. parameter each bound to different next header type. Hash algorithm
used to generate MIC is same as the 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 number contain a TRANSACTION_ID parameter. The identifier value is a number
that is unique for each transaction. A response to a request uses that is unique for each transaction. A response to a request uses
the same identifier value allowing receiver to match requests to the same identifier value allowing receiver to match requests to
responses. responses.
4.1. Definition of the SEQ_DATA Parameter 4.1. Definition of the SEQ_DATA Parameter
skipping to change at page 8, line 15 skipping to change at page 8, line 15
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 [ TBD by IANA:
4545 = (2^12 + 2^8 + 2^7 + 2^6 + 1) ] 4545 = (2^12 + 2^8 + 2^7 + 2^6 + 1) ]
Length 4 Length variable (multiple of 4)
Acked Sequence number 32-bit sequence number corresponding to Acked Sequence number 32-bit sequence number corresponding to
the sequence number being acknowledged the sequence number being acknowledged
4.3. Definition of the PAYLOAD_MAC Parameter 4.3. Definition of the PAYLOAD_MIC Parameter
The following is the definition of the PAYLOAD_MAC 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Payload HMAC / / Payload MIC /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: Type [ TBD by IANA:
4577 = (2^12 + 2^8 + 2^7 + 2^6 + 2^5 + 1) ] 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 protected by this HMAC. Next Header Identifies the data that protected by this MIC.
The values for are defined by IANA "Assigned The values for are defined by IANA "Assigned
Numbers". Numbers".
Payload Data 8 last bytes of the payload data over which the Payload Data 8 last bytes of the payload data over which the
HMAC is calculated. This field is used to MIC is calculated. This field is used to
uniquely identify the extension header, in case uniquely bind PAYLOAD_MIC parameter to next header,
there are multiple copies of same type. in case there are multiple copies of same type.
Payload HMAC HMAC computed over the data to which the Next Payload MIC MIC computed over the data to which the Next
Header and Payload Data points to. The size of Header and Payload Data points to. The size of
the HMAC is the natural size of the computation the MIC is the natural size of the computation
output depending on the used function. output depending on the used function.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 34 skipping to change at page 9, line 34
Figure 1: Format of the TRANSACTION_ID parameter Figure 1: Format of the TRANSACTION_ID parameter
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 contains zero or one SEQ_DATA parameter. The A HIP DATA packet MUST contain SEQ_DATA or ACK_DATA parameter if both
parameters are missing then packet MUST be dropped as invalid.
A HIP DATA packet containing SEQ_DATA parameter MUST contain one or
more PAYLOAD_MIC parameter otherwise packet MUST be dropped. The
presence of a SEQ_DATA parameter indicates that the receiver MUST ACK 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 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 and
MUST NOT be ACKed. MUST NOT be ACKed.
A HIP DATA packet contains zero or one ACK_DATA parameters. The ACK A HIP DATA packet contains zero or one ACK_DATA parameters. The ACK
parameter echoes the SEQ_DATA sequence number of the HIP DATA packet parameter echoes the SEQ_DATA sequence number of the HIP DATA packet
packet being ACKed. packet being ACKed. One ACK_DATA parameter MUST contain one more
sequence numbers of the HIP DATA packets being ACKed.
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 ACK
for a short period of time to allow for the possibility of 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 parameter, in a manner similar to TCP delayed
acknowledgments. 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
parameter in the first HIP DATA packet it sends to a destination. sequence number in the first HIP DATA packet it sends to a
After that first packet, the host MUST choose the value of the destination. After that first packet, the host MUST choose the
SEQ_DATA parameter in subsequent HIP DATA packets to the same value of the SEQ_DATA sequence number in subsequent HIP DATA
destination so that no SEQ_DATA value is reused before the packets to the same destination so that no SEQ_DATA sequence
receiver has closed the processing window for the previous packet number is reused before the receiver has closed the processing
using the same SEQ_DATA value. Practically, giving the values of window for the previous packet using the same SEQ_DATA sequence
the retransmission timers used with HIP DATA packets, this means number. Practically, giving the values of the retransmission
that hosts must wait the maximum likely lifetime of the packet timers used with HIP DATA packets, this means that hosts must
before reusing a given SEQ_DATA value towards a given wait the maximum likely lifetime of the packet before reusing a
destination. However, it is not required for node to know the given SEQ_DATA sequence number towards a given destination.
maximum packet lifetime. Rather, it is assumed that the However, it is not required for node to know the maximum packet
requirement can be met by maintaining the value as a simple, 32- lifetime. Rather, it is assumed that the requirement can be met
bit, "wrap-around" counter, incremented each time a packet is by maintaining the value as a simple, 32-bit, "wrap-around"
sent. It is an implementation choice whether to maintain a counter, incremented each time a packet is sent. It is an
single counter for the node or multiple counters (one for each implementation choice whether to maintain a single counter for
source HIT, destination HIT combination). the node or multiple counters (one for each source HIT,
2. The host creates PAYLOAD_HMAC parameter. The HMAC is calculated destination HIT combination).
over the whole PAYLOAD which the Next Header field of 2. The host creates PAYLOAD_MIC parameter. MIC is a hash calculated
PAYLOAD_HMAC parameter indicates. The receiver MUST validate over the whole PAYLOAD which the Next Header field of PAYLOAD_MIC
this HMAC. For calculating the HMAC the host MUST use the same parameter indicates. If there is multiple next header types
hash algorithm as the one that has been used for generating the which the host wants to protect it SHOULD create separate
host's HIT as defined in Section 3.2. of [RFC5201]. PAYLOAD_MIC parameter for each of these. The receiver MUST
validate these MICs. 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 3. The host creates 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 hosts sends the created HIP DATA packet and starts a DATA
timer. The default value for the timer is 2 * RTT estimate. If timer. The default value for the timer is 2 * RTT estimate. 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 SHOULD be exponentially backed off for subsequent timer SHOULD 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
skipping to change at page 11, line 10 skipping to change at page 11, line 20
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 SHOULD be exponentially backed off for subsequent timer SHOULD 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 peer that acknowledges receipt of the HIP DATA packet.
5.3. Reception of a HIP DATA packet 5.3. Reception of a HIP DATA packet
A host receiving a HIP DATA packet to decide whether to process it or A host receiving a HIP DATA packet makes decision whether to process
not. If the host, following its local policy, suspects that this the packet or not. If the host, following its local policy, suspects
packet could be part of a DoS attack. The host MAY respond with an that this packet could be part of a DoS attack. The host MAY respond
R1 packet to the HIP DATA packet, if the packet contained SEQ_DATA with an R1 packet to the HIP DATA packet, if the packet contained
and PAYLOAD_HMAC parameter, in order to run the HIP base exchange SEQ_DATA and PAYLOAD_MIC parameter, in order to indicate that HIP
with the originator of the HIP DATA packet. If the host chooses to base exchange MUST be completed before accepting payload packets from
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 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 selects a precomputed R1 according to the format described in
[RFC5201] Section 5.3.2. The host SHOULD drop the received data [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 packet if it responded with a R1 packet to the HIP_DATA packet. The
sender of HIP_DATA packet is responsible of retransmission of the sender of HIP_DATA packet is responsible of retransmission of the
upper-layer protocol data after successful completion of the HIP Base upper-layer protocol data after successful completion of the HIP Base
Exchange. 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 it according to the following
rules: rules:
If the HIP DATA packet contains a SEQ_DATA parameter and no 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.
If the HIP DATA packet contains an ACK_DATA parameter and no If the HIP DATA packet contains an ACK_DATA parameter and no
SEQ_DATA parameter, the HIP DATA packet is processed and replied SEQ_DATA parameter, the HIP DATA packet is processed as described
to as described in Section 5.3.2. in Section 5.3.2.
If the HIP DATA packet contains both a SEQ_DATA parameter and an 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.
skipping to change at page 12, line 11 skipping to change at page 12, line 25
DATA packets sent with ACKs to avoid the cost of generating a new ACK DATA packets sent with ACKs to avoid the cost of generating a new ACK
packet to respond to a retransmitted HIP DATA packet. The host MUST packet to respond to a retransmitted HIP DATA packet. The host MUST
acknowledge, again, such (apparent) HIP DATA packet retransmissions acknowledge, again, such (apparent) HIP DATA packet retransmissions
but SHOULD also consider rate-limiting such retransmission responses but SHOULD also consider rate-limiting such retransmission responses
to guard against replay attacks. to guard against replay attacks.
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 system MUST verify the PAYLOAD_HMAC by calculating the HMAC over The system MUST verify the PAYLOAD_MIC by calculating MIC over the
the PAYLOAD which the Next Header field indicates. For calculating PAYLOAD which the Next Header field indicates. For calculating the
the HMAC the host will use the same hash algorithm that has been used MIC the host will use the same hash algorithm that has been used to
to generate the sender's HIT as defined in Section 3.2. of [RFC5201]. 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 If the packet carried multiple PAYLOAD_MIC parameters each of them
message logged. are verified as described above. If one or more of 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 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.
skipping to change at page 14, line 13 skipping to change at page 14, line 25
receive HIP DATA packet. If the communication consists more than few receive HIP DATA packet. If the communication consists more than few
round-trips of data or the data is highly sensitive in nature the round-trips of data or the data is highly sensitive in nature the
host SHOULD run the base exchange with the peer host. host SHOULD run the base exchange with the peer host.
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 new packet type for the new 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), and PAYLOAD_HMAC (Section 4.3) parameters. ACK_DATA (Section 4.2), and PAYLOAD_MIC (Section 4.3) parameters.
9. Acknowledgments 9. Acknowledgments
In the usual IETF fashion, a large number of people have contributed Pekka Nikander was one of the original authors of the draft. Also,
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 to the actual text or ideas. The list of these people include Miika
Komu, Tobias Heer, Ari Keranen, Samu Varjonen, Thomas Henderson, and Komu, Tobias Heer, Ari Keranen, Samu Varjonen, Thomas Henderson, and
Jukka Ylitalo. Our apologies to anyone whose name is missing. 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 Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 15, line 7 skipping to change at page 15, line 17
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008. 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. Arkko, "End-
Host Mobility and Multihoming with the Host Identity Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008. Protocol", RFC 5206, April 2008.
Authors' Addresses Authors' Addresses
Pekka Nikander
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Pekka.Nikander@ericsson.com
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
 End of changes. 33 change blocks. 
117 lines changed or deleted 134 lines changed or added

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