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