TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets
obsoletes
- rfc-8229 — TCP Encapsulation of IKE and IPsec Packets
Extracted elements (32)
IKEv2 Cookie requests provide less protection against DoS with TCP encapsulation because the TCP three-way handshake already verifies the Initiator's IP address before the IKE_SA_INIT request arrives, unlike UDP where the IP address is unverified. Puzzles remain useful because they require computational work regardless of transport.
TCP encapsulation is defined as a fallback option rather than the default because it adds overhead and performance trade-offs (TCP-in-TCP, added reliability for unreliable ESP, QoS marking limitations). The design goal is to use IKE over UDP by default and only use TCP when UDP is blocked by middleboxes.
The Don't Fragment (DF) bit from inner IPv4 headers cannot be copied to the outer header when using TCP encapsulation because the TCP/IP stack manages the DF bit in the outer IPv4 header and typically sets it to avoid IP fragmentation. All IPsec SAs created by a single IKE SA share one TCP connection, preventing DSCP-based QoS differentiation across child SAs.
The "IKETCP" stream prefix is required at the start of each TCP connection to identify and validate that the connection is being used for TCP encapsulation as defined in this document, avoiding conflicts with prevalent non-standard protocols that historically used TCP port 4500.
After an IKE Redirect to a new security gateway, the client MUST first try UDP and then fall back to TCP when establishing a new IKE SA, regardless of the transport the redirect notification was received over.
For IKEv2 High Availability with TCP encapsulation, if TCP states are not synchronized between cluster nodes, after failover the new node cannot initiate INFORMATIONAL exchanges until the client sends traffic and receives a TCP RST, prompting reconnection. TCP Originator clients SHOULD periodically send IKEv2 messages when no traffic is flowing to enable quick failover detection.
IKE message fragmentation (RFC 7383) is redundant when using TCP encapsulation since TCP already handles fragmentation. Implementations SHOULD NOT send fragments over TCP, although they MUST support receiving fragments. If both MOBIKE and fragmentation are supported, IKE fragmentation SHOULD be negotiated over TCP in case the session switches to UDP.
When using MOBIKE to switch networks, the UPDATE_SA_ADDRESSES INFORMATIONAL exchange SHOULD first be attempted over UDP; if no response is received, the Initiator may switch to TCP. The NO_NATS_ALLOWED notification SHOULD be ignored when using TCP encapsulation since TCP generally has no problems with NAT boxes.
Compliant implementations MUST support TCP encapsulation on TCP port 4500, which is reserved for IPsec NAT traversal.
If TCP encapsulation is being used for a specific IKE SA, all IKE messages for that SA and ESP packets for its Child SAs MUST be sent over the TCP connection until the SA is deleted or MOBIKE is used to change the SA endpoints and/or encapsulation protocol.
Implementations MUST favor using direct ESP or UDP encapsulation over TCP encapsulation whenever possible.
Implementations SHOULD prefer ESP direct or UDP-encapsulated SAs over TCP-encapsulated SAs when possible, due to overhead and potential performance trade-offs.
Implementations that implement both MOBIKE and TCP encapsulation within the same connection configuration MUST support dynamically enabling and disabling TCP encapsulation as interfaces change.
Multiple IKE SAs MUST NOT share a single TCP connection, unless one is a rekey of an existing IKE SA, in which case there will temporarily be two IKE SAs on the same TCP connection.
NAT-keepalive packets (RFC 3948) SHOULD NOT be sent when using TCP encapsulation. Any implementation using TCP encapsulation MUST silently drop incoming NAT-keepalive packets and not treat them as errors.
TCP keep-alives and TLS keep-alives MAY be used but MUST NOT be used as indications of IKE peer liveness; peer liveness MUST be checked using IKE informational packets (RFC 7296).
The IPv6 Flow-ID header MUST remain constant when a new TCP connection is created to avoid ECMP load balancing disruption.
The receiver MUST treat Length field values of 0 or 1 as fatal errors and MUST close the TCP connection. Empty messages where Length equals 2 MUST be silently ignored.
The TCP Responder MUST wait for the entire stream prefix to be received before trying to parse IKE or ESP messages, and MUST NOT accept messages for an existing IKE session on a new incoming connection unless that connection begins with the stream prefix.
When switching from UDP to TCP encapsulation, a new IKE_SA_INIT exchange MUST be initiated with the Initiator's new SPI and recalculated NAT_DETECTION_*_IP notification content.
IKE_SA_INIT packets sent on a TCP connection SHOULD include NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads using the applicable TCP ports in SHA-1 digest calculation. If a NAT is detected, no change should be made to encapsulation since TCP encapsulation inherently supports NAT traversal.
IKEv2 Cookie requests provide less value with TCP encapsulation because the TCP handshake already verifies the Initiator's IP address. The Responder SHOULD NOT send a Cookie request without an accompanied Puzzle, and MUST NOT include the Initiator's TCP port in the Cookie calculation since the Cookie may be returned on a different port.
The document defines two roles: "TCP Originator" (the IKE peer that initiates TCP connections) and "TCP Responder" (the peer that receives them). If an IKE SA is rekeyed, the TCP Originator MUST remain the peer that originally initiated the first IKE SA, independent of IKEv2 Initiator/Responder role swaps.
When IKEv2 uses TCP as a reliable transport, the exchange Initiator SHOULD NOT retransmit request messages; if no response is received within a reasonable period, the IKE SA is deleted. If a new TCP connection is established while waiting for a response, the Initiator MUST retransmit its request over the new connection.
Section 11 updates the reference for TCP port 4500 (service name: ipsec-nat-t, description: IPsec NAT-Traversal) in the "Service Name and Transport Protocol Port Number Registry" from RFC 8229 to RFC 9329.
Because TCP Responders must accept IKE and ESP messages arriving on new TCP connections from changed source addresses and ports, the validation of such messages must include decryption, authentication, and replay checks to prevent an attacker from influencing packet routing paths.
IKE Responders supporting TCP encapsulation become vulnerable to TCP-specific DoS attacks including SYN flooding. TCP connections are also susceptible to RST and spoofing attacks; if an attacker can tear down TCP connections, IPsec connection performance can suffer, creating an effective DoS attack.
TCP data injection attacks can corrupt the TCP stream by altering the Length field, causing the receiver to misidentify packet boundaries and drop all subsequent packets. An attacker that modifies the Non-ESP marker will cause IKE packets to be dispatched to ESP processing (and vice versa), dropping them. IPsec data integrity prevents application data compromise but not DoS.
To recover from injection attacks, implementations should close the TCP connection when packets contain SPIs that don't match any known SAs; the TCP Originator will then re-establish the connection. Alternatively, implementations MAY attempt to resync by searching the stream for known SPI+sequence number patterns, but SHOULD limit resync attempts.
Each TCP stream used for IKE/IPsec encapsulation MUST begin with a 6-byte stream prefix containing the ASCII string "IKETCP" (0x49 0x4b 0x45 0x54 0x43 0x50), sent once and only by the TCP Originator.
TCP-encapsulated ESP packets are preceded by a 16-bit Length field (network byte order) specifying the length of the ESP packet including the Length field itself. The ESP SPI MUST NOT be zero, and the Length value MUST NOT be 0 or 1.
TCP-encapsulated IKE messages are preceded by a 16-bit Length field (network byte order) followed by a 32-bit zero Non-ESP Marker, then the IKE message body. The Length field value includes the length of the field itself and the Non-ESP marker and MUST NOT be 0 or 1.