RFC 6078
Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)
Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) 🎀
- Number: RFC 6078 📄
- Authors: G. Camarillo and J. Melen, both at Ericsson 💅
- Category: Experimental 🧪
- ISSN: 2070-1721
- Date: January 2011 🗓️
- Obsoletes / Updates: the header doesn't list anything for either one 🙈
Abstract 🌸
okay so this doc defines a brand new HIP packet type called DATA ✨. HIP DATA packets are how you reliably send authenticated, arbitrary protocol messages over all sorts of overlay networks. literally so iconic 🦋
Status of This Memo 💜
This document is not an Internet Standards Track specification. It's being published so people can examine it, try it out with experimental implementations, and evaluate it 🧪.
This document defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that bit 📚.
For info on the current status of this document, any errata, and how to send feedback, check 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) as they were in effect on the date this document was published. Please read these documents carefully because they spell out your rights and restrictions with respect to this document 👀. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . 161. Introduction ✨
okay so two hosts can use HIP [RFC5201] to set up a security association (SA) between them, which lets them swap arbitrary protocol messages over that SA 🔐. Setting up that SA involves a four-way handshake called the HIP base exchange 🤝. When hosts are talking to each other, HIP supports mobility, multihoming, security, and NAT traversal, which is so main character energy 👑. The catch is that some apps need these features but can't handle the overhead of setting up an SA (aka the HIP base exchange) before they can even start talking 😭.
So in this doc we define the HIP DATA packet 🦋. It can convey protocol messages to a remote host in an authenticated and reliable way, without running the HIP base exchange first. The HIP_DATA packet has these semantics: unordered, duplicate free, reliable, and authenticated message-based delivery service 💅. We also talk about the trade-offs of using this packet (less overhead, but also less denial-of-service (DoS) protection 💀) and about when it actually makes sense to use it 🧠.
Not gonna lie, the HIP_DATA packet is NOT 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 you need continuous communication, or communication that needs confidentiality protection, then hosts MUST run the HIP base exchange to set up an ESP security association 🔒. Also, APIs to higher-level protocols that might use this service are outside 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]. On top of that, this document uses the terms defined in [RFC5201] 🧠.
Message Integrity Code (MIC) is a collision-resistant hash sum calculated over the message being integrity protected 🔍. The MIC doesn't use secret keys, so it needs additional means to make sure it hasn't been tampered with during transmission. Basically, the MIC is the same as the Message Authentication Code (MAC), except the MIC doesn't use secret keys 🗝️. People also call the MIC the Integrity Check Value (ICV), a fingerprint, or an unkeyed MAC 🪪.
3. Background on HIP 🧚
The HIP specification [RFC5201] defines a bunch of messages and parameters 💜. The parameters are encoded as TLVs, as shown in Section 3.1.2. Also, the HIP header carries a Next Header field, which lets other arbitrary packets ride along inside HIP packets 🎀.
3.1. Message Formats 🍓
3.1.1. HIP Fixed Header 🌷
The HIP packet format is 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 we copy it down below so you can see it 👀:
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 /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the tea ☕. The HIP header is logically an IPv6 extension header 🧩. The HIP specification [RFC5201] only defines handling for Next Header value decimal 59, which is IPv6-NoNxt [PROTOCOL-NUMBERS], the IPv6 'no next header' value 🚫. This document describes processing for Next Header values other than decimal 59, which means there are more extension headers and/or data after the HIP header 📦.
3.1.2. HIP Parameter Format 🎀
The HIP parameter format is defined in Section 5.2.1 of [RFC5201], and we copy it down 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
Okay so the HIP base exchange is a four-message authentication and key exchange protocol 🔐✨ It creates shared, mutually authenticated keying material at both communicating parties. That keying material, together with the associated public keys and IP addresses, forms a HIP security association (SA). Iconic. All the nitty-gritty details live in the HIP base exchange specification [RFC5201] 💅
The base exchange messages can also carry extra parameters that create additional state 🎀 For example, the HIP ESP specification [RFC5202] explains how HIP can set up end-to-end, host-to-host IPsec ESP security associations that carry data packets. But here's the tea: the HIP base exchange is by no means bound to IPsec 🙈 Using IPsec ESP to carry data traffic is just a baseline, and it ensures interoperability between initial HIP implementations 🫶
Once two HIP-enabled hosts have a HIP SA, they can swap more HIP control messages 💬 Typically those are UPDATE messages. The HIP mobility and multihoming specification [RFC5206] shows how to use UPDATE messages to change the set of IP addresses associated with a HIP SA 🦋
And the base protocol spec also covers how to remove a HIP SA once it's no longer needed 🧹✨
4. Definition of the HIP_DATA Packet ✨
Bestie, the HIP DATA packet lets you send protocol messages to a remote host without running the HIP base exchange 💌 HIP DATA packets are transmitted reliably, which we'll get into in Section 5 🔁 The payload of a HIP_DATA packet sits after the HIP header and gets protected by a PAYLOAD_MIC parameter (defined in Section 4.3) 🛡️ Here's the definition of the HIP_DATA packet (see the notation definition 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're what make HIP_DATA delivery reliable, as discussed in Section 5 💖
The HOST_ID parameter is defined in Section 5.2.8 of [RFC5201] 🪪 It's the sender's Host Identifier, used to compute the HIP_DATA packet's signature and to check it against the received signature. HOST_ID is optional, because it MAY have been delivered to the receiver through an out-of-band mechanism 🙌 But if the host doesn't have reliable information that the other node already has its HOST_ID, it MUST always include the HOST_ID in the packet 🫢 And if the receiver can't 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 😭
The PAYLOAD_MIC parameter is defined in Section 4.3 🌈 It holds the MIC of the payload carried by the HIP_DATA packet. The MIC is the collision-resistant hash of the payload that follows the HIP DATA. PAYLOAD_MIC is included in the signed part of the HIP DATA packet, so it gives integrity protection for the packet and 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. How the signature gets calculated and verified is defined in Section 6.4.2. of [RFC5201] 🧐
Section 5.3 of [RFC5201] says 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.
So, we chose to put the payload after the HIP extension header, and only put a MIC of the payload into the HIP extension header (in a PAYLOAD_MIC parameter) ✨ That way the data integrity is protected by a public key signature with the help of the MIC 🔥 The payload protected by PAYLOAD_MIC gets linked to the right upper-layer protocol by storing the upper-layer protocol number, 8 octets of payload data, and a hash sum (MIC) calculated over the data 🎯 A 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 algorithm used to generate the Host Identity Tag [RFC5201] 🏷️
Upper-layer protocol messages, like overlay network control traffic, that go out in HIP DATA messages may need to be matched to different transactions 🎭 For that, a DATA message MAY also contain a TRANSACTION_ID parameter 🪄 The identifier value is a variable-length bit string in network byte order, unique for each transaction. A response uses the same identifier value as its request, so the receiver can match requests to responses 💘
4.1. Definition of the SEQ_DATA Parameter
Here's the SEQ_DATA parameter definition 📐
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 the receiver doesn't support it, 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
Next up, 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 the receiver doesn't support it, 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.3. Definition of the PAYLOAD_MIC Parameter
Here's the PAYLOAD_MIC parameter, the big one 🧠
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 the receiver doesn't support it, 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's a theoretical possibility 🤔 that when generating multiple PAYLOAD_MIC parameters for a single packet, they could end up with identical Next Header and Payload Data fields. So 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 each PAYLOAD_MIC to the correct payload data 🧵 If the receiving host still can't identify the payloads, it MUST drop the packet, and it 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
And finally, 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 15. Generation and Reception of HIP_DATA Packets ✨
Bestie, HIP_DATA packets are transmitted reliably 💯 That reliability comes from retransmissions plus the SEQ_DATA and ACK_DATA parameters doing their thing 🔁🦋
5.1. Handling of SEQ_DATA and ACK_DATA ✨
okay so 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 with a SEQ_DATA parameter MUST contain one or more PAYLOAD_MIC parameters, otherwise the packet MUST be dropped 🙈 having a SEQ_DATA parameter means the receiver MUST ACK the HIP_DATA packet 🫶 and a HIP_DATA packet with no SEQ_DATA parameter is just an ACK for an earlier HIP_DATA packet, so it MUST NOT be ACKed 🦋
a HIP_DATA packet with an ACK_DATA parameter echoes the SEQ_DATA sequence numbers of the HIP_DATA packets it's acknowledging 🌸 the ACK_DATA parameter MUST acknowledge at least one SEQ_DATA sequence number, and it MAY acknowledge multiple SEQ_DATA sequence 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 parameter 👑 in that case the ACK is piggybacked on an outgoing HIP_DATA packet 🔥 in general, HIP_DATA packets carrying SEQ_DATA SHOULD be ACKed once the HIP_DATA packet has been fully processed. a host MAY choose to hold the HIP DATA packet carrying an ACK for a short while so it can piggyback the ACK_DATA parameter, kind of like TCP delayed acknowledgments 🍓
5.2. Generation of a HIP_DATA Packet
okay so 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 it sends the data directly in a HIP_DATA packet 🎀 Section 6 covers when each method is appropriate. this section is about the case where the host picks the HIP_DATA packet to send that upper-layer protocol data 💖
- the host creates a
HIP_DATApacket that contains aSEQ_DATAparameter 🧚 the host is free to choose any value for theSEQ_DATAsequence number in the firstHIP_DATApacket it sends to a destination. after that first packet, the host MUST choose theSEQ_DATAsequence number for subsequentHIP_DATApackets to the same destination so that noSEQ_DATAsequence number gets reused before the receiver has closed the processing window for the previous packet with that same number 🙅♀️ practically, going by the retransmission timers used withHIP_DATApackets, hosts must wait the maximum likely lifetime of the packet before reusing a givenSEQ_DATAsequence number toward a given destination. however, the node doesn't have to know the maximum packet lifetime 🌈 instead, it's assumed the requirement can be met by keeping the value as a simple, 32-bit, "wrap-around" counter that goes up each time a packet is sent. it's an implementation choice whether the node keeps a single counter or multiple counters (one for each<source, destination>HIT pair) ✨ - the host creates the
PAYLOAD_MICparameter 🔐 the MIC is a hash calculated over the whole PAYLOAD that the Next Header field of thePAYLOAD_MICparameter indicates. if the host wants to protect multiple Next Header types, it SHOULD create separatePAYLOAD_MICparameters for each one. 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 that was used to generate the host's HIT, as defined in Section 3.2. of [RFC5201] 💜 - the host creates the
HIP_SIGNATUREparameter ✍️ the signature is calculated over the whole HIP envelope, excluding any parameters after theHIP_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 a HI acquired some other way. - the host sends the
HIP_DATApacket and starts a DATA timer ⏱️ the default value for the timer is 3 seconds. if multipleHIP DATApackets are outstanding, multiple timers are in effect 🌸 - if the DATA timer expires, the
HIP_DATApacket gets resent 🔁 theHIP DATApacket can be resentDATA_RETRY_MAXtimes. the DATA timer MUST be exponentially backed off for subsequent retransmissions 📈 if no acknowledgment comes back from the peer afterDATA_RETRY_MAXtimes, delivery of theHIP_DATApacket is considered unsuccessful and the application is notified about the error 😭 the DATA timer is canceled when an ACK arrives from the peer that acknowledges receipt of theHIP_DATApacket. the default value forDATA_RETRY_MAXSHOULD be 5 retries, but it MAY be changed through local policy 🍓
5.3. Reception of a HIP_DATA Packet
okay so a host that receives a HIP_DATA packet gets to decide whether or not to process it 🦋 if the host, following its local policy, suspects that the packet could be part of a DoS attack. the host MAY respond with an R1 packet to the HIP_DATA packet, but only if the packet contained SEQ_DATA and PAYLOAD_MIC parameters 🚧 that response says the HIP base exchange MUST be completed before the host accepts 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 decides to respond to the HIP DATA with an R1 packet, it either creates a new R1 or selects a precomputed one, following 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 the HIP_DATA packet is responsible for retransmitting the upper-layer protocol data after the HIP base exchange completes successfully 🫶
if the host, following its local policy, decides to process the incoming HIP_DATA packet, it follows these rules:
- if the
HIP_DATApacket contains aSEQ_DATAparameter and noACK_DATAparameter, theHIP_DATApacket is processed and replied to as described in Section 5.3.1 💌 - if the
HIP_DATApacket contains anACK_DATAparameter and noSEQ_DATAparameter, theHIP_DATApacket is processed as described in Section 5.3.2 📬 - if the
HIP_DATApacket contains both aSEQ_DATAparameter and anACK_DATAparameter, the packet is processed first as described in Section 5.3.2, and then the rest of theHIP_DATApacket 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
these are 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 received SEQ_DATA value and the MIC value in the received PAYLOAD_MIC match a HIP_DATA packet that was recently processed, the packet is treated as a retransmission 🔄 it's recommended that a host cache HIP_DATA packets with ACKs, so it doesn't have to generate a brand-new ACK packet every time a retransmitted HIP_DATA packet shows up 🌷 the host MUST acknowledge these (apparent) HIP_DATA packet retransmissions again, but it 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 was used to generate the sender's HIT, as defined in Section 3.2. of [RFC5201]. if the packet carried multiple PAYLOAD_MIC parameters, each one is 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 🌟
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
these are 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 a previously sent HIP_DATA packet containing SEQ_DATA that hasn't already been acknowledged 🔍 if no match is found, or if the ACK_DATA doesn't 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 get followed 🧐
the matching DATA timer is stopped, so the now-acknowledged HIP_DATA packet stops getting retransmitted ⏹️ if multiple HIP_DATA packets are newly acknowledged, multiple timers are stopped 🎉
6. Use of the HIP_DATA Packet 🎀
okay bestie, so HIP normally makes hosts do the full four-message base exchange the first time two hosts meet 🫶 and that can add extra RTTs (Round-Trip Times) to protocols that only need one message exchange 🥺 BUT the four-message exchange is what keeps the DoS protection working, so we can't just skip it lol. the HIP_DATA packet from this doc cuts down that starting overhead ✨ however, the HIP_DATA packet itself gives ZERO DoS protection 💀 so the HIP_DATA packet MUST only be used in environments whose policies protect against DoS attacks 🛡️ like, a HIP-based overlay could have rules about who's allowed to join 🧚 but who gets to join is totally outside this spec, not my problem 💅
a node in the overlay might want to accept HIP_DATA packets from other overlay nodes, as long as those nodes were authorized to join ✨ but it should NOT accept HIP_DATA packets from random nodes that aren't in the overlay, periodt 🙅♀️ also, the HIP_DATA packet doesn't give confidentiality for its payload 😭 so the HIP_DATA packet MUST NOT be used in environments that don't give 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 also matters 👀 HIP doesn't do fragmentation itself and just leans on IP-layer fragmentation, which can cause reliability problems when a message can't easily be split across multiple HIP messages 💔 so applications where fragmentation could be an issue SHOULD NOT generate large HIP_DATA packets that might get fragmented 🙈 the implementation SHOULD check the MTU of the link before sending, and if the packet is bigger than the MTU, it SHOULD signal the upper-layer protocol if the packet results in an ICMP error message 🌸 fragmentation isn't always a problem though!! for example, some HIP-based overlays let nodes exchange HIP_DATA packets over TCP connections that do transport-level fragmentation, so they skip IP-level fragmentation entirely 🦋
HIP currently requires that all messages EXCEPT I1s but INCLUDING HIP_DATA packets are digitally signed 🔏 that adds to packet size and the processing needed to send packets 😩 but where security isn't paramount, you can use very short keys to save resources 🌈
7. Security Considerations 💀🔥
okay this section is SERIOUS bestie, read it fr fr 😭
HIP is designed to provide secure authentication of hosts 👑 it also tries to limit exposure to denial-of-service and man-in-the-middle (MitM) attacks 🛡️ HOWEVER, a HIP_DATA packet can be sent WITHOUT running the HIP base exchange between hosts, and that comes with a trade-off: it does NOT provide the denial-of-service protection or confidentiality protection that HIP normally gives 😱 so the host should always think carefully about whether it's appropriate to send or receive a HIP_DATA packet 🤔 if the communication is more than a few round trips of data, or the data is highly sensitive, the host SHOULD run the base exchange with the peer host 🔒
the HIP_DATA packet is designed to protect hosts from second preimage attacks, so the receiving host can detect whether the message was tampered with in transport ✨ this property is also known as "weak collision-resistance" 🧠 if a host tries to generate a second preimage, it would need to produce one where the last 8 octets match the original message 🎯
when the receiving host handles the PAYLOAD_MIC parameter, using the last 8 octets to identify the upper-layer protocol does NOT guarantee the MIC is correct 🙃 so an attacker could send packets where the next header and last 8 octets match the values in 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 adding a new packet type for the HIP_DATA (Section 4) packet 🦋 it also updates the IANA registry for HIP parameter types by adding 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 this doc 👑 and as usual in the IETF, a big crowd of people contributed text or ideas 💜 the list includes Miika Komu, Tobias Heer, Ari Keranen, Samu Varjonen, Thomas Henderson, and Jukka Ylitalo 🧚 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.
[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📦 where this page comes from
- ietf: rfc6078 2011-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms