RFC 6261
Encrypted Signaling Transport Modes for the Host Identity Protocol
RFC 6261: Encrypted Signaling Transport Modes for the Host Identity Protocol 💖
Author: A. Keranen (Ericsson) 🎀 Stream: Internet Engineering Task Force (IETF) 🌸 Category: Experimental 🧪 Date: May 2011 📅 ISSN: 2070-1721 ✨ Obsoletes / Updates: The title block lists no Obsoletes or Updates entries 🦋
Abstract ✨
okay so this doc lays out two transport modes for HIP signaling messages 💅 so they can travel over encrypted connections that HIP sets up in the first place. it's giving security glow-up 🔐
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/rfc6261. 🔗
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. 📜
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Transport Mode Negotiation . . . . . . . . . . . . . . . . . . 3
3.1. Mode Negotiation in the HIP Base Exchange . . . . . . . . 3
3.2. Mode Negotiation after the HIP Base Exchange . . . . . . . 5
3.3. Error Notifications . . . . . . . . . . . . . . . . . . . 5
4. HIP Messages on Encrypted Connections . . . . . . . . . . . . 5
4.1. ESP Mode . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. ESP-TCP Mode . . . . . . . . . . . . . . . . . . . . . . . 6
5. Recovering from Failed Encrypted Connections . . . . . . . . . 7
6. Host Mobility and Multihoming . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informational References . . . . . . . . . . . . . . . . . 10
Appendix A. Mobility and Multihoming Examples . . . . . . . . . . 111. Introduction 🦋
so HIP [RFC5201] signaling messages can already be sent over plain IP using the protocol number reserved for HIP, or over UDP using the UDP port reserved for HIP NAT traversal [RFC5770]. when two hosts do a HIP base exchange, they set up an encrypted connection for their data traffic, but they keep using plain IP or UDP for the signaling. 🌸
this doc explains how that encrypted connection can carry the HIP signaling messages too 🔐✨. there are two modes: HIP over Encapsulating Security Payload (ESP) and HIP over TCP. the big win of sending HIP over ESP is that all signaling traffic, HIP headers included, gets encrypted 🫶. and if HIP messages go over TCP (which then rides inside ESP), TCP can handle message fragmentation whenever it's needed 🧩.
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]. 💅
3. Transport Mode Negotiation 🤝
this section is all about how hosts show which HIP signaling transport modes they support and how they agree on which mode to use 🫧.
3.1. Mode Negotiation in the HIP Base Exchange 🌷
okay so a HIP host that follows this spec SHOULD tell the other side which modes it supports and is willing to use, during the base exchange 💬. the negotiation works a lot like HIP NAT traversal mode negotiation. first, the Responder lists its supported modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) inside the R1 packet 🎀. the modes are in priority order, with the most preferred mode(s) first 🥇. if the Initiator supports, and is willing to use, any of the modes the Responder offered, it picks one by adding a HIP_TRANSPORT_MODE parameter with the chosen mode to the I2 packet 💜. then, if the Initiator picked a mode and the base exchange succeeds, hosts MUST use that selected mode for the HIP signaling messages between them, for the whole HIP association or until a different mode is negotiated 🔁✨.
if the Initiator can't, or won't, use any of the modes the Responder offered, the Initiator SHOULD put an empty HIP_TRANSPORT_MODE parameter in the I2 packet 🙈. that signals "hey, I support this extension, but I'm not using any of your modes." depending on local policy, the Responder MAY either abort the base exchange or keep doing HIP signaling without an encrypted connection, when I2 had no HIP_TRANSPORT_MODE parameter or the parameter was empty 🍓. if the Initiator picks a mode that the Responder doesn't support (so it wasn't in R1), the Responder MUST abort the base exchange 🚫. and if the base exchange gets aborted because of a (possibly missing) HIP_TRANSPORT_PARAMETER, the Responder SHOULD send a NO_VALID_HIP_TRANSPORT_MODE notification (see Section 3.3) to the Initiator 🫣.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 7680
Port transport layer port number (or zero if not used)
Length length in octets, excluding Type, Length, and Padding
Mode ID defines the proposed or selected transport mode(s)
The following HIP Transport Mode IDs are defined:
ID name Value
RESERVED 0
DEFAULT 1
ESP 2
ESP-TCP 3
Figure 1: Format of the HIP_TRANSPORT_MODE Parameterthe mode DEFAULT means the same transport (plain IP or UDP) that was used for the base exchange should keep being used for later HIP signaling messages 🔁. in ESP mode, the messages are sent as-is on the encrypted ESP connection 🔐. in ESP-TCP mode, TCP runs inside the ESP tunnel 🚇. if a mode that uses a transport layer connection inside the ESP tunnel (like ESP-TCP) is on the menu, the Port field MUST contain the local port number the host will use for that connection 🔌. if none of the modes use a transport layer protocol, the Port field SHOULD be set to zero when the parameter is sent and ignored when it's received 0️⃣. the Port and Mode ID fields are encoded as unsigned integers in network byte order 🧮.
the HIP_TRANSPORT_MODE parameter sits in the signed part of the HIP packets, so it's covered by the signatures on the R1, I2, and UPDATE packets 🔏💖.
3.2. Mode Negotiation after the HIP Base Exchange 🔄
if a HIP host wants to switch to a different transport mode (or start using one) some time after the base exchange, it sends a HIP UPDATE packet with a HIP_TRANSPORT_MODE parameter listing the mode(s) it would prefer 🙋♀️. the host that gets the UPDATE SHOULD answer with an UPDATE packet containing the mode that gets selected, the same way the negotiation worked during the base exchange 🫶. if the receiving host doesn't support any of the listed modes, or isn't willing to use them, it SHOULD answer with an UPDATE packet whose HIP_TRANSPORT_MODE parameter contains only the currently used transport mode (even if that wasn't in the previous UPDATE packet), and keep using that mode 🧸.
since the HIP_TRANSPORT_MODE parameter's type is not critical (as defined in Section 5.2.1 of [RFC5201]), a host that doesn't support this extension will just reply with an acknowledgement UPDATE packet without a HIP_TRANSPORT_MODE parameter 🤷♀️. in that case, depending on local policy (same as mode negotiation during the base exchange), the host that asked for the new transport mode MAY close the HIP association 💀. if it does close the association, the host closing it SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet to the other host before closing 👋.
3.3. Error Notifications 🚨
during a HIP signaling transport mode negotiation, the receiving host MAY send back a NOTIFY packet with a NOTIFICATION parameter [RFC5201] of error type NO_VALID_HIP_TRANSPORT_MODE (value 100) in two situations 🧯. first, when the HIP_TRANSPORT_MODE parameter doesn't contain any mode the receiving host is willing to use. second, when there's no HIP_TRANSPORT_MODE parameter in a HIP packet where the receiving host expected one 🫠. the Notification Data field for these error notifications SHOULD contain the HIP header of the rejected packet 📦✨.
more parts coming, bestie 🧚💜
4. HIP Messages on Encrypted Connections ✨
okay bestie, this spec defines two transport modes for sending HIP packets over encrypted ESP connections 🔐. These modes only work if the ESP transport format [RFC5202] has been negotiated between the hosts. If the ESP transport format isn't being used, these modes MUST NOT be offered in the HIP_TRANSPORT_MODE parameter. And if a HIP_TRANSPORT_MODE parameter with an ESP transport mode shows up but the ESP transport format isn't in use, a host MUST NOT select that mode. It should instead act as specified in Section 3.1 (if it's doing a base exchange) or Section 3.2 (if it's doing an UPDATE) when no valid mode is offered 💅.
the ESP mode gives simple protection for all the signaling traffic 🛡️ and it can be a generic replacement for the DEFAULT mode when you want all signaling traffic encrypted. but if HIP messages get so big that they'd need fragmenting (like because of HIP certificates [RFC6253] or DATA messages [RFC6078]), it is RECOMMENDED to use the ESP-TCP mode 🧦. that one handles fragmentation at the TCP level, so you're not stuck relying on IP-level fragmentation. super smart, no notes 🙌
when HIP NAT traversal [RFC5770] is in play, the ESP and HIP packets get sent UDP encapsulated 🌐. which NAT traversal mode you pick (especially UDP encapsulation) is independent of the transport mode for HIP packets, so these two choices don't affect each other 🦋. BUT, when HIP packets go over an ESP connection, you do NOT add extra UDP encapsulation inside that ESP connection for the HIP packets. it MUST NOT be used, because the ESP packets are already UDP encapsulated if NAT traversal needs it 🙅♀️. for example, say you're using UDP encapsulation as defined in [RFC5770] and the ESP-TCP transport mode from this doc. then your HIP packets travel over IP, UDP, ESP, and TCP, in that order 🧚.
HIP messages that change or generate new keying material (that's the base exchange and the re-keying UPDATE messages) MUST NOT be sent over the encrypted connection built with the keying material being changed. they also MUST NOT go over an encrypted connection using the newly created keying material either 🔑🚫.
it's worth knowing that when HIP messages are sent over an encrypted connection, on-path network elements (like firewalls and HIP-aware NATs) can't see any part of the messages unless they have the encryption keying material 👀. the original HIP design deliberately chose to expose some of this info to HIP-aware NATs, so it's not a total surprise. if an encrypted transport mode is used, only the base exchange or the update without encryption is visible to those NATs 🫣.
4.1. ESP Mode
okay so, if the ESP mode gets selected in the base exchange, BOTH hosts MUST listen for incoming HIP signaling messages and send outgoing messages on the encrypted connection 🔒. and the ESP header's next header value for HIP messages sent over ESP MUST be set to HIP (139) 💜.
4.2. ESP-TCP Mode
if the ESP-TCP mode is selected, the host with the larger HIT (calculated as defined in Section 6.5 of [RFC5201]) MUST start listening for an incoming TCP connection on the encrypted connection (that's to the HIT of the host) 👂. it listens on the port it used in the Port field of the transport mode parameter. the other host MUST create a TCP connection to that port. it MAY use the port it sent in the transport mode parameter as the source port for the connection 🎀. once the TCP connection is up, both hosts MUST listen for incoming HIP signaling messages and send their outgoing messages over that TCP connection ✨. the ESP next header value for messages sent over ESP-TCP mode TCP connections MUST be set to TCP (6) 🌸.
now, if the hosts can't create the TCP connection, the host that started the mode negotiation MUST restart it with the UPDATE message. it SHOULD NOT propose the ESP-TCP mode again 🙈. if local policy doesn't allow any mode besides ESP-TCP, the HIP association SHOULD be closed 💀. and the UPDATE or CLOSE message MUST be sent using the same transport mode that was used for negotiating ESP-TCP.
TCP is reliable, so HIP messages sent over TCP MUST NOT be retransmitted. this is giving "trust the process" 🫶. instead, a host SHOULD wait to detect that the TCP connection failed to retransmit the packet successfully in a timely manner before concluding there's no response ⏳. (how it detects that is platform- and policy-specific, so do your own thing there 🍓).
5. Recovering from Failed Encrypted Connections
if the encrypted connection fails for some reason, it can't be used for HIP signaling anymore 😭. so the hosts SHOULD re-establish the connection using HIP messages sent outside of the encrypted connection 🛟. that means, while listening for incoming HIP messages on the encrypted connection, hosts MUST still accept incoming HIP messages using the same transport method (like UDP or plain IP) that was used for the base exchange. when a host responds to a HIP message that was sent outside the encrypted connection, the response MUST use the same transport method as the original message 🔁. if encryption was used before, hosts SHOULD send outside the encrypted connection only the HIP messages needed to re-establish the encrypted connection 🧩. and if the policy says only encrypted messages can be sent (like DATA messages using an encrypted transport mode), those MUST be sent using an encrypted connection 🔐.
heads up, though: a policy MUST NOT prevent sending unencrypted UPDATE messages used for re-establishing the encrypted connection. if it did, you could never recover from failed encrypted connections, and that would be a total mess 🙅♀️.
the UPDATE messages used for re-establishing the encrypted connection MUST contain a HIP_TRANSPORT_MODE parameter, and the negotiation proceeds as described in Section 3.2 🦋.
6. Host Mobility and Multihoming
if a host gets a new address, a new Security Association (SA) pair may be created for it (or an existing SA pair may be moved to the new address), as described in [RFC5206] 🚚. if the ESP or ESP-TCP transport mode is used, HIP signaling just keeps going using the (new) SA pair and the same transport mode as before 🌈.
with the ESP mode, the first mobility UPDATE message SHOULD be sent using the old SA. then the following messages, including the response to that first UPDATE, SHOULD be sent using the new SAs 🪄. retransmissions of UPDATE messages use the same SA as the original message. if the ESP-TCP mode is used, the HIP signaling TCP connection gets moved to the new SA pair like any other TCP connection 🧵. however, the mobility UPDATE messages SHOULD NOT be sent over the TCP connection. they go over plain ESP, same as in the ESP mode. so hosts MUST be prepared to receive UPDATE messages over plain ESP even when the ESP-TCP mode is being used 🫠.
sometimes the host can't send the mobility UPDATE messages over the encrypted connection before it breaks 💔. this is kind of like when the encrypted connection fails, so the hosts need to renegotiate the new addresses using unencrypted UPDATE messages and possibly rendezvous [RFC5204] or HIP relay [RFC5770] servers 📡. also, these UPDATE messages MUST contain the HIP_TRANSPORT_MODE parameter and perform the transport mode negotiation 🎟️.
examples of the signaling flows with mobility and multihoming are shown in Appendix A 📖.
7. Security Considerations
⚠️ read this one carefully, it's serious business!
by exchanging HIP messages over an ESP connection, all HIP signaling data gets encrypted 🔐. that covers everything after the base exchange, except keying material (re)negotiation and some of the mobility UPDATE messages. but this only happens if NULL encryption is NOT being used. so a host that needs confidentiality for its HIP signaling messages has to check that encryption is actually negotiated for the ESP connection 👀. also, the level of protection the ESP transport modes give you depends on the ESP transform you pick. for the security considerations of the different ESP transforms, check out [RFC5202] and [RFC4303] 📚.
this extension lets hosts negotiate security features, and there's no risk of downgrade attacks 🙌. that's because mode negotiation happens using signed packets (R1/I2 or UPDATE), and only after both hosts have been securely identified in the base exchange. if an attacker tried to change the modes listed in the HIP_TRANSPORT_MODE parameter, that would break the signatures, and the base exchange (or update) would never complete 🚫. plus, since both "secure" modes defined in this document (ESP and ESP-TCP) are equally secure, the only possible downgrade attack would be making both hosts accept the DEFAULT mode 😤. and if the local policy of either host requires a secure mode, the base exchange or update would simply fail, as described in Section 3.1 💥.
8. Acknowledgements
thank you to Gonzalo Camarillo, Kristian Slavov, Tom Henderson, Miika Komu, Jan Melen, and Tobias Heer for the reviews and comments 🫶💖.
9. IANA Considerations
this section is to be interpreted according to [RFC5226] 📋.
this document updates the IANA maintained "Host Identity Protocol (HIP) Parameters" registry [RFC5201] by assigning a new HIP Parameter Type value (7680) for the HIP_TRANSPORT_MODE parameter (defined in Section 3.1) 🔢✨.
the HIP_TRANSPORT_MODE parameter has 16-bit unsigned integer fields for different modes. IANA created and now maintains a new sub-registry called "HIP Transport Modes" under the "Host Identity Protocol (HIP) Parameters" registry 🗂️. the initial values for the transport mode registry are given in Section 3.1. future assignments are made through IETF Review or IESG Approval [RFC5226]. each assignment consists of a transport mode identifier name and its associated value 🏷️.
this document also defines a new HIP NOTIFICATION message type [RFC5201], NO_VALID_HIP_TRANSPORT_MODE (100), in Section 3.3 🔔.
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.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.10.2. Informational References ✨
Now for the "good to know" reads 📚🫶 These are the bonus references the spec leans on for context, and the full details are below, exactly as written:
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, 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.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", RFC 5770,
April 2010.
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP)
Immediate Carriage and Conveyance of Upper-Layer Protocol
Signaling (HICCUPS)", RFC 6078, January 2011.
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", RFC 6253, May 2011.Appendix A. Mobility and Multihoming Examples 🦋
Okay so when a host switches interfaces because it's moving around (mobility) or using more than one address at once (multihoming), it sends HIP messages to tell the other host about the new address 📍 and to double-check that the new address still works. These examples show the signaling for two different vibes of address change. Heads up: not every HIP parameter, and not every bit inside those parameters, makes it into the pictures 🙈 Also, this whole appendix is not normative 💅 If you want the real rules, go back to the earlier sections.
Quick cast list: host A has two addresses (a1 and a2) and host B only has one (b1) 👯 In the first example, "Make before Break" (Figure 2), host A starts using the new address but can still use the old one for signaling, thanks to multihoming ✨ In the second, "Break before Make" (Figure 3), host A loses the first address before it gets the second one (for example, because it's on the move 🚶), so the mobility HIP signaling happens without the encrypted connection. Dramatic, I know 😭
Here's what the notation means:
ESPx(y): dataysent wrapped inside ESP with SAx. If there's no ESP wrapping, the data just goes over plain IP or UDP 📦UPDATE(x,y,z): HIP UPDATE message [RFC5201] with parametersx,y,zLOCATOR(x): HIP LOCATOR parameter [RFC5206] with locatorxESP_INFO(x,y): HIP ESP_INFO parameter [RFC5202] with "old SPI" valuexand "new SPI" valueyACK,ECHO_REQ, andECHO_RSP: HIP ACK, ECHO_REQUEST, and ECHO_RESPONSE parameters [RFC5201]
Here's the Make Before Break flow, the glow-up where the new path is set up first 🌈
A B
ESP1(...)
a1 <----------------------------------------------> b1
ESP1(UPDATE(LOCATOR(a2), ESP_INFO(0,SPI2a)))
a1 -----------------------------------------------> b1
(A and B create SAs a2 <-> b1 (ESP2)
retransmissions of the first UPDATE
happen over ESP1)
ESP2(UPDATE(ACK, ESP_INFO(0,SPI2b), ECHO_REQ)))
a2 <----------------------------------------------- b1
ESP2(UPDATE(ACK, ECHO_RSP))
a2 -----------------------------------------------> b1
ESP2(...)
a2 <----------------------------------------------> b1
Figure 2: Make Before BreakAnd here's Break Before Make, the "we lost the signal for a sec but we're back" moment 🫠
A B
ESP1(...)
a1 <----------------------------------------------> b1
(A moves from a1 to a2)
UPDATE(LOCATOR(a2), ESP_INFO(SPI1a, SPI1a))
a2 -----------------------------------------------> b1
UPDATE(ACK, ECHO_REQ, ESP_INFO(SPI1b,SPI1b))
a2 <----------------------------------------------- b1
UPDATE(ACK, ECHO_RSP)
a2 -----------------------------------------------> b1
(A and B move ESP1 SAs to a2 <-> b1)
ESP1(...)
a2 <----------------------------------------------> b1
Figure 3: Break Before MakeAlso, when ESP-TCP mode is in use, the signaling flows look pretty much the same, because TCP isn't used for the mobility UPDATE messages (see Section 6) 🧚💜
Author's Address 💖
Ari Keranen
Ericsson
Hirsalantie 11
02420 Jorvas
Finland
EMail: ari.keranen@ericsson.com📦 where this page comes from
- ietf: rfc6261 2011-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms