diff options
Diffstat (limited to 'doc/rfc/rfc8229.txt')
| -rw-r--r-- | doc/rfc/rfc8229.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc8229.txt b/doc/rfc/rfc8229.txt new file mode 100644 index 0000000..696f36c --- /dev/null +++ b/doc/rfc/rfc8229.txt @@ -0,0 +1,1403 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Pauly +Request for Comments: 8229 Apple Inc. +Category: Standards Track S. Touati +ISSN: 2070-1721 Ericsson + R. Mantha + Cisco Systems + August 2017 + + + TCP Encapsulation of IKE and IPsec Packets + +Abstract + + This document describes a method to transport Internet Key Exchange + Protocol (IKE) and IPsec packets over a TCP connection for traversing + network middleboxes that may block IKE negotiation over UDP. This + method, referred to as "TCP encapsulation", involves sending both IKE + packets for Security Association establishment and Encapsulating + Security Payload (ESP) packets over a TCP connection. This method is + intended to be used as a fallback option when IKE cannot be + negotiated over UDP. + +Status of This Memo + + This is an Internet Standards Track document. + + 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). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + 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/rfc8229. + + + + + + + + + + + + + + + + +Pauly, et al. Standards Track [Page 1] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + +Copyright Notice + + Copyright (c) 2017 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 ....................................................3 + 1.1. Prior Work and Motivation ..................................4 + 1.2. Terminology and Notation ...................................5 + 2. Configuration ...................................................5 + 3. TCP-Encapsulated Header Formats .................................6 + 3.1. TCP-Encapsulated IKE Header Format .........................6 + 3.2. TCP-Encapsulated ESP Header Format .........................7 + 4. TCP-Encapsulated Stream Prefix ..................................7 + 5. Applicability ...................................................8 + 5.1. Recommended Fallback from UDP ..............................8 + 6. Connection Establishment and Teardown ...........................9 + 7. Interaction with NAT Detection Payloads ........................11 + 8. Using MOBIKE with TCP Encapsulation ............................11 + 9. Using IKE Message Fragmentation with TCP Encapsulation .........12 + 10. Considerations for Keep-Alives and Dead Peer Detection ........12 + 11. Middlebox Considerations ......................................12 + 12. Performance Considerations ....................................13 + 12.1. TCP-in-TCP ...............................................13 + 12.2. Added Reliability for Unreliable Protocols ...............14 + 12.3. Quality-of-Service Markings ..............................14 + 12.4. Maximum Segment Size .....................................14 + 12.5. Tunneling ECN in TCP .....................................14 + 13. Security Considerations .......................................15 + 14. IANA Considerations ...........................................16 + 15. References ....................................................16 + 15.1. Normative References .....................................16 + 15.2. Informative References ...................................17 + + + + + + + +Pauly, et al. Standards Track [Page 2] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + Appendix A. Using TCP Encapsulation with TLS ......................18 + Appendix B. Example Exchanges of TCP Encapsulation with TLS .......19 + B.1. Establishing an IKE Session ................................19 + B.2. Deleting an IKE Session ....................................21 + B.3. Re-establishing an IKE Session .............................22 + B.4. Using MOBIKE between UDP and TCP Encapsulation .............23 + Acknowledgments ...................................................25 + Authors' Addresses ................................................25 + +1. Introduction + + The Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] is a + protocol for establishing IPsec Security Associations (SAs), using + IKE messages over UDP for control traffic, and using Encapsulating + Security Payload (ESP) [RFC4303] messages for encrypted data traffic. + Many network middleboxes that filter traffic on public hotspots block + all UDP traffic, including IKE and IPsec, but allow TCP connections + through because they appear to be web traffic. Devices on these + networks that need to use IPsec (to access private enterprise + networks, to route Voice over IP calls to carrier networks, or + because of security policies) are unable to establish IPsec SAs. + This document defines a method for encapsulating IKE control messages + as well as IPsec data messages within a TCP connection. + + Using TCP as a transport for IPsec packets adds a third option to the + list of traditional IPsec transports: + + 1. Direct. Currently, IKE negotiations begin over UDP port 500. If + no Network Address Translation (NAT) device is detected between + the Initiator and the Responder, then subsequent IKE packets are + sent over UDP port 500, and IPsec data packets are sent + using ESP. + + 2. UDP Encapsulation [RFC3948]. If a NAT is detected between the + Initiator and the Responder, then subsequent IKE packets are sent + over UDP port 4500 with four bytes of zero at the start of the + UDP payload, and ESP packets are sent out over UDP port 4500. + Some peers default to using UDP encapsulation even when no NAT is + detected on the path, as some middleboxes do not support IP + protocols other than TCP and UDP. + + 3. TCP Encapsulation. If the other two methods are not available or + appropriate, IKE negotiation packets as well as ESP packets can + be sent over a single TCP connection to the peer. + + + + + + + +Pauly, et al. Standards Track [Page 3] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + Direct use of ESP or UDP encapsulation should be preferred by + IKE implementations due to performance concerns when using + TCP encapsulation (Section 12). Most implementations should use + TCP encapsulation only on networks where negotiation over UDP has + been attempted without receiving responses from the peer or if a + network is known to not support UDP. + +1.1. Prior Work and Motivation + + Encapsulating IKE connections within TCP streams is a common approach + to solve the problem of UDP packets being blocked by network + middleboxes. The specific goals of this document are as follows: + + o To promote interoperability by defining a standard method of + framing IKE and ESP messages within TCP streams. + + o To be compatible with the current IKEv2 standard without requiring + modifications or extensions. + + o To use IKE over UDP by default to avoid the overhead of other + alternatives that always rely on TCP or Transport Layer Security + (TLS) [RFC5246]. + + Some previous alternatives include: + + Cellular Network Access + Interworking Wireless LAN (IWLAN) uses IKEv2 to create secure + connections to cellular carrier networks for making voice calls + and accessing other network services over Wi-Fi networks. 3GPP has + recommended that IKEv2 and ESP packets be sent within a TLS + connection to be able to establish connections on restrictive + networks. + + ISAKMP over TCP + Various non-standard extensions to the Internet Security + Association and Key Management Protocol (ISAKMP) have been + deployed that send IPsec traffic over TCP or TCP-like packets. + + Secure Sockets Layer (SSL) VPNs + Many proprietary VPN solutions use a combination of TLS and IPsec + in order to provide reliability. These often run on TCP port 443. + + IKEv2 over TCP + IKEv2 over TCP as described in [IKE-over-TCP] is used to avoid UDP + fragmentation. + + + + + + +Pauly, et al. Standards Track [Page 4] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + +1.2. Terminology and Notation + + This document distinguishes between the IKE peer that initiates TCP + connections to be used for TCP encapsulation and the roles of + Initiator and Responder for particular IKE messages. During the + course of IKE exchanges, the role of IKE Initiator and Responder may + swap for a given SA (as with IKE SA rekeys), while the Initiator of + the TCP connection is still responsible for tearing down the TCP + connection and re-establishing it if necessary. For this reason, + this document will use the term "TCP Originator" to indicate the IKE + peer that initiates TCP connections. The peer that receives TCP + connections will be referred to as the "TCP Responder". If an IKE SA + is rekeyed one or more times, the TCP Originator MUST remain the peer + that originally initiated the first IKE SA. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Configuration + + One of the main reasons to use TCP encapsulation is that UDP traffic + may be entirely blocked on a network. Because of this, support for + TCP encapsulation is not specifically negotiated in the IKE exchange. + Instead, support for TCP encapsulation must be pre-configured on both + the TCP Originator and the TCP Responder. + + Implementations MUST support TCP encapsulation on TCP port 4500, + which is reserved for IPsec NAT traversal. + + Beyond a flag indicating support for TCP encapsulation, the + configuration for each peer can include the following optional + parameters: + + o Alternate TCP ports on which the specific TCP Responder listens + for incoming connections. Note that the TCP Originator may + initiate TCP connections to the TCP Responder from any local port. + + o An extra framing protocol to use on top of TCP to further + encapsulate the stream of IKE and IPsec packets. See Appendix A + for a detailed discussion. + + + + + + + + +Pauly, et al. Standards Track [Page 5] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + Since TCP encapsulation of IKE and IPsec packets adds overhead and + has potential performance trade-offs compared to direct or + UDP-encapsulated SAs (as described in Section 12), implementations + SHOULD prefer ESP direct or UDP-encapsulated SAs over + TCP-encapsulated SAs when possible. + +3. TCP-Encapsulated Header Formats + + Like UDP encapsulation, TCP encapsulation uses the first four bytes + of a message to differentiate IKE and ESP messages. TCP + encapsulation also adds a Length field to define the boundaries of + messages within a stream. The message length is sent in a 16-bit + field that precedes every message. If the first 32 bits of the + message are zeros (a non-ESP marker), then the contents comprise an + IKE message. Otherwise, the contents comprise an ESP message. + Authentication Header (AH) messages are not supported for TCP + encapsulation. + + Although a TCP stream may be able to send very long messages, + implementations SHOULD limit message lengths to typical UDP datagram + ESP payload lengths. The maximum message length is used as the + effective MTU for connections that are being encrypted using ESP, so + the maximum message length will influence characteristics of inner + connections, such as the TCP Maximum Segment Size (MSS). + + Note that this method of encapsulation will also work for placing IKE + and ESP messages within any protocol that presents a stream + abstraction, beyond TCP. + +3.1. TCP-Encapsulated IKE Header Format + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Non-ESP Marker | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ IKE header [RFC7296] ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1 + + + + + + + +Pauly, et al. Standards Track [Page 6] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + The IKE header is preceded by a 16-bit Length field in network byte + order that specifies the length of the IKE message (including the + non-ESP marker) within the TCP stream. As with IKE over UDP + port 4500, a zeroed 32-bit non-ESP marker is inserted before the + start of the IKE header in order to differentiate the traffic from + ESP traffic between the same addresses and ports. + + o Length (2 octets, unsigned integer) - Length of the IKE packet, + including the Length field and non-ESP marker. + +3.2. TCP-Encapsulated ESP Header Format + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ ESP header [RFC4303] ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2 + + The ESP header is preceded by a 16-bit Length field in network byte + order that specifies the length of the ESP packet within the TCP + stream. + + The Security Parameter Index (SPI) field [RFC7296] in the ESP header + MUST NOT be a zero value. + + o Length (2 octets, unsigned integer) - Length of the ESP packet, + including the Length field. + +4. TCP-Encapsulated Stream Prefix + + Each stream of bytes used for IKE and IPsec encapsulation MUST begin + with a fixed sequence of six bytes as a magic value, containing the + characters "IKETCP" as ASCII values. This value is intended to + identify and validate that the TCP connection is being used for TCP + encapsulation as defined in this document, to avoid conflicts with + the prevalence of previous non-standard protocols that used TCP + port 4500. This value is only sent once, by the TCP Originator only, + at the beginning of any stream of IKE and ESP messages. + + If other framing protocols are used within TCP to further encapsulate + or encrypt the stream of IKE and ESP messages, the stream prefix must + be at the start of the TCP Originator's IKE and ESP message stream + + + +Pauly, et al. Standards Track [Page 7] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + within the added protocol layer (Appendix A). Although some framing + protocols do support negotiating inner protocols, the stream prefix + should always be used in order for implementations to be as generic + as possible and not rely on other framing protocols on top of TCP. + + 0 1 2 3 4 5 + +------+------+------+------+------+------+ + | 0x49 | 0x4b | 0x45 | 0x54 | 0x43 | 0x50 | + +------+------+------+------+------+------+ + + Figure 3 + +5. Applicability + + TCP encapsulation is applicable only when it has been configured to + be used with specific IKE peers. If a Responder is configured to use + TCP encapsulation, it MUST listen on the configured port(s) in case + any peers will initiate new IKE sessions. Initiators MAY use TCP + encapsulation for any IKE session to a peer that is configured to + support TCP encapsulation, although it is recommended that Initiators + should only use TCP encapsulation when traffic over UDP is blocked. + + Since the support of TCP encapsulation is a configured property, not + a negotiated one, it is recommended that if there are multiple IKE + endpoints representing a single peer (such as multiple machines with + different IP addresses when connecting by Fully Qualified Domain + Name, or endpoints used with IKE redirection), all of the endpoints + equally support TCP encapsulation. + + If TCP encapsulation is being used for a specific IKE SA, all + messages for that IKE SA and its Child SAs MUST be sent over a TCP + connection until the SA is deleted or IKEv2 Mobility and Multihoming + (MOBIKE) is used to change the SA endpoints and/or the encapsulation + protocol. See Section 8 for more details on using MOBIKE to + transition between encapsulation modes. + +5.1. Recommended Fallback from UDP + + Since UDP is the preferred method of transport for IKE messages, + implementations that use TCP encapsulation should have an algorithm + for deciding when to use TCP after determining that UDP is unusable. + If an Initiator implementation has no prior knowledge about the + network it is on and the status of UDP on that network, it SHOULD + always attempt to negotiate IKE over UDP first. IKEv2 defines how to + use retransmission timers with IKE messages and, specifically, + IKE_SA_INIT messages [RFC7296]. Generally, this means that the + implementation will define a frequency of retransmission and the + maximum number of retransmissions allowed before marking the IKE SA + + + +Pauly, et al. Standards Track [Page 8] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + as failed. An implementation can attempt negotiation over TCP once + it has hit the maximum retransmissions over UDP, or slightly before + to reduce connection setup delays. It is recommended that the + initial message over UDP be retransmitted at least once before + falling back to TCP, unless the Initiator knows beforehand that the + network is likely to block UDP. + +6. Connection Establishment and Teardown + + When the IKE Initiator uses TCP encapsulation, it will initiate a TCP + connection to the Responder using the configured TCP port. The first + bytes sent on the stream MUST be the stream prefix value (Section 4). + After this prefix, encapsulated IKE messages will negotiate the IKE + SA and initial Child SA [RFC7296]. After this point, both + encapsulated IKE (Figure 1) and ESP (Figure 2) messages will be sent + over the TCP connection. The TCP Responder MUST wait for the entire + stream prefix to be received on the stream before trying to parse out + any IKE or ESP messages. The stream prefix is sent only once, and + only by the TCP Originator. + + In order to close an IKE session, either the Initiator or Responder + SHOULD gracefully tear down IKE SAs with DELETE payloads. Once the + SA has been deleted, the TCP Originator SHOULD close the TCP + connection if it does not intend to use the connection for another + IKE session to the TCP Responder. If the connection is left idle and + the TCP Responder needs to clean up resources, the TCP Responder MAY + close the TCP connection. + + An unexpected FIN or a TCP Reset on the TCP connection may indicate a + loss of connectivity, an attack, or some other error. If a DELETE + payload has not been sent, both sides SHOULD maintain the state for + their SAs for the standard lifetime or timeout period. The TCP + Originator is responsible for re-establishing the TCP connection if + it is torn down for any unexpected reason. Since new TCP connections + may use different ports due to NAT mappings or local port allocations + changing, the TCP Responder MUST allow packets for existing SAs to be + received from new source ports. + + A peer MUST discard a partially received message due to a broken + connection. + + Whenever the TCP Originator opens a new TCP connection to be used for + an existing IKE SA, it MUST send the stream prefix first, before any + IKE or ESP messages. This follows the same behavior as the initial + TCP connection. + + + + + + +Pauly, et al. Standards Track [Page 9] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + If a TCP connection is being used to resume a previous IKE session, + the TCP Responder can recognize the session using either the IKE SPI + from an encapsulated IKE message or the ESP SPI from an encapsulated + ESP message. If the session had been fully established previously, + it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES + message if MOBIKE is supported, or an informational message (a + keep-alive) otherwise. + + The TCP Responder MUST NOT accept any messages for the existing IKE + session on a new incoming connection, unless that connection begins + with the stream prefix. If either the TCP Originator or TCP + Responder detects corruption on a connection that was started with a + valid stream prefix, it SHOULD close the TCP connection. The + connection can be determined to be corrupted if there are too many + subsequent messages that cannot be parsed as valid IKE messages or + ESP messages with known SPIs, or if the authentication check for an + ESP message with a known SPI fails. Implementations SHOULD NOT + tear down a connection if only a single ESP message has an unknown + SPI, since the SPI databases may be momentarily out of sync. If + there is instead a syntax issue within an IKE message, an + implementation MUST send the INVALID_SYNTAX notify payload and + tear down the IKE SA as usual, rather than tearing down the TCP + connection directly. + + A TCP Originator SHOULD only open one TCP connection per IKE SA, over + which it sends all of the corresponding IKE and ESP messages. This + helps ensure that any firewall or NAT mappings allocated for the TCP + connection apply to all of the traffic associated with the IKE SA + equally. + + Similarly, a TCP Responder SHOULD at any given time send packets for + an IKE SA and its Child SAs over only one TCP connection. It SHOULD + choose the TCP connection on which it last received a valid and + decryptable IKE or ESP message. In order to be considered valid for + choosing a TCP connection, an IKE message must be successfully + decrypted and authenticated, not be a retransmission of a previously + received message, and be within the expected window for IKE + message IDs. Similarly, an ESP message must pass authentication + checks and be decrypted, and must not be a replay of a previous + message. + + Since a connection may be broken and a new connection re-established + by the TCP Originator without the TCP Responder being aware, a TCP + Responder SHOULD accept receiving IKE and ESP messages on both old + and new connections until the old connection is closed by the TCP + Originator. A TCP Responder MAY close a TCP connection that it + perceives as idle and extraneous (one previously used for IKE and ESP + messages that has been replaced by a new connection). + + + +Pauly, et al. Standards Track [Page 10] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + 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. + +7. Interaction with NAT Detection Payloads + + When negotiating over UDP port 500, IKE_SA_INIT packets include + NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads to + determine if UDP encapsulation of IPsec packets should be used. + These payloads contain SHA-1 digests of the SPIs, IP addresses, and + ports as defined in [RFC7296]. IKE_SA_INIT packets sent on a TCP + connection SHOULD include these payloads with the same content as + when sending over UDP and SHOULD use the applicable TCP ports when + creating and checking the SHA-1 digests. + + If a NAT is detected due to the SHA-1 digests not matching the + expected values, no change should be made for encapsulation of + subsequent IKE or ESP packets, since TCP encapsulation inherently + supports NAT traversal. Implementations MAY use the information that + a NAT is present to influence keep-alive timer values. + + If a NAT is detected, implementations need to handle transport mode + TCP and UDP packet checksum fixup as defined for UDP encapsulation in + [RFC3948]. + +8. Using MOBIKE with TCP Encapsulation + + When an IKE session that has negotiated MOBIKE [RFC4555] is + transitioning between networks, the Initiator of the transition may + switch between using TCP encapsulation, UDP encapsulation, or no + encapsulation. Implementations that implement both MOBIKE and TCP + encapsulation MUST support dynamically enabling and disabling TCP + encapsulation as interfaces change. + + When a MOBIKE-enabled Initiator changes networks, the + UPDATE_SA_ADDRESSES notification SHOULD be sent out first over UDP + before attempting over TCP. If there is a response to the + UPDATE_SA_ADDRESSES notification sent over UDP, then the ESP packets + should be sent directly over IP or over UDP port 4500 (depending on + if a NAT was detected), regardless of if a connection on a previous + network was using TCP encapsulation. Similarly, if the Responder + only responds to the UPDATE_SA_ADDRESSES notification over TCP, then + the ESP packets should be sent over the TCP connection, regardless of + if a connection on a previous network did not use TCP encapsulation. + + + + + + + +Pauly, et al. Standards Track [Page 11] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + +9. Using IKE Message Fragmentation with TCP Encapsulation + + IKE message fragmentation [RFC7383] is not required when using TCP + encapsulation, since a TCP stream already handles the fragmentation + of its contents across packets. Since fragmentation is redundant in + this case, implementations might choose to not negotiate IKE + fragmentation. Even if fragmentation is negotiated, an + implementation SHOULD NOT send fragments when going over a TCP + connection, although it MUST support receiving fragments. + + If an implementation supports both MOBIKE and IKE fragmentation, it + SHOULD negotiate IKE fragmentation over a TCP-encapsulated session in + case the session switches to UDP encapsulation on another network. + +10. Considerations for Keep-Alives and Dead Peer Detection + + Encapsulating IKE and IPsec inside of a TCP connection can impact the + strategy that implementations use to detect peer liveness and to + maintain middlebox port mappings. Peer liveness should be checked + using IKE informational packets [RFC7296]. + + In general, TCP port mappings are maintained by NATs longer than UDP + port mappings, so IPsec ESP NAT keep-alives [RFC3948] SHOULD NOT be + sent when using TCP encapsulation. Any implementation using TCP + encapsulation MUST silently drop incoming NAT keep-alive packets + and not treat them as errors. NAT keep-alive packets over a + TCP-encapsulated IPsec connection will be sent as an ESP message with + a one-octet-long payload with the value 0xFF. + + Note that, depending on the configuration of TCP and TLS on the + connection, TCP keep-alives [RFC1122] and TLS keep-alives [RFC6520] + may be used. These MUST NOT be used as indications of IKE peer + liveness. + +11. Middlebox Considerations + + Many security networking devices, such as firewalls or intrusion + prevention systems, network optimization/acceleration devices, and + NAT devices, keep the state of sessions that traverse through them. + + These devices commonly track the transport-layer and/or application- + layer data to drop traffic that is anomalous or malicious in nature. + While many of these devices will be more likely to pass + TCP-encapsulated traffic as opposed to UDP-encapsulated traffic, some + may still block or interfere with TCP-encapsulated IKE and IPsec + traffic. + + + + + +Pauly, et al. Standards Track [Page 12] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + A network device that monitors the transport layer will track the + state of TCP sessions, such as TCP sequence numbers. TCP + encapsulation of IKE should therefore use standard TCP behaviors to + avoid being dropped by middleboxes. + +12. Performance Considerations + + Several aspects of TCP encapsulation for IKE and IPsec packets may + negatively impact the performance of connections within a tunnel-mode + IPsec SA. Implementations should be aware of these performance + impacts and take these into consideration when determining when to + use TCP encapsulation. Implementations SHOULD favor using direct ESP + or UDP encapsulation over TCP encapsulation whenever possible. + +12.1. TCP-in-TCP + + If the outer connection between IKE peers is over TCP, inner TCP + connections may suffer negative effects from using TCP within TCP. + Running TCP within TCP is discouraged, since the TCP algorithms + generally assume that they are running over an unreliable datagram + layer. + + If the outer (tunnel) TCP connection experiences packet loss, this + loss will be hidden from any inner TCP connections, since the outer + connection will retransmit to account for the losses. Since the + outer TCP connection will deliver the inner messages in order, any + messages after a lost packet may have to wait until the loss is + recovered. This means that loss on the outer connection will be + interpreted only as delay by inner connections. The burstiness of + inner traffic can increase, since a large number of inner packets may + be delivered across the tunnel at once. The inner TCP connection may + interpret a long period of delay as a transmission problem, + triggering a retransmission timeout, which will cause spurious + retransmissions. The sending rate of the inner connection may be + unnecessarily reduced if the retransmissions are not detected as + spurious in time. + + The inner TCP connection's round-trip-time estimation will be + affected by the burstiness of the outer TCP connection if there are + long delays when packets are retransmitted by the outer TCP + connection. This will make the congestion control loop of the inner + TCP traffic less reactive, potentially permanently leading to a lower + sending rate than the outer TCP would allow for. + + + + + + + + +Pauly, et al. Standards Track [Page 13] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + TCP-in-TCP can also lead to increased buffering, or bufferbloat. + This can occur when the window size of the outer TCP connection is + reduced and becomes smaller than the window sizes of the inner TCP + connections. This can lead to packets backing up in the outer TCP + connection's send buffers. In order to limit this effect, the outer + TCP connection should have limits on its send buffer size and on the + rate at which it reduces its window size. + + Note that any negative effects will be shared between all flows going + through the outer TCP connection. This is of particular concern for + any latency-sensitive or real-time applications using the tunnel. If + such traffic is using a TCP-encapsulated IPsec connection, it is + recommended that the number of inner connections sharing the tunnel + be limited as much as possible. + +12.2. Added Reliability for Unreliable Protocols + + Since ESP is an unreliable protocol, transmitting ESP packets over a + TCP connection will change the fundamental behavior of the packets. + Some application-level protocols that prefer packet loss to delay + (such as Voice over IP or other real-time protocols) may be + negatively impacted if their packets are retransmitted by the TCP + connection due to packet loss. + +12.3. Quality-of-Service Markings + + Quality-of-Service (QoS) markings, such as the Differentiated + Services Code Point (DSCP) and Traffic Class, should be used with + care on TCP connections used for encapsulation. Individual packets + SHOULD NOT use different markings than the rest of the connection, + since packets with different priorities may be routed differently and + cause unnecessary delays in the connection. + +12.4. Maximum Segment Size + + A TCP connection used for IKE encapsulation SHOULD negotiate its MSS + in order to avoid unnecessary fragmentation of packets. + +12.5. Tunneling ECN in TCP + + Since there is not a one-to-one relationship between outer IP packets + and inner ESP/IP messages when using TCP encapsulation, the markings + for Explicit Congestion Notification (ECN) [RFC3168] cannot be simply + mapped. However, any ECN Congestion Experienced (CE) marking on + inner headers should be preserved through the tunnel. + + + + + + +Pauly, et al. Standards Track [Page 14] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + Implementations SHOULD follow the ECN compatibility mode for tunnel + ingress as described in [RFC6040]. In compatibility mode, the outer + tunnel TCP connection marks its packet headers as not ECN-capable. + If upon egress, the arriving outer header is marked with CE, the + implementation will drop the inner packet, since there is not a + distinct inner packet header onto which to translate the ECN + markings. + +13. Security Considerations + + IKE Responders that support TCP encapsulation may become vulnerable + to new Denial-of-Service (DoS) attacks that are specific to TCP, such + as SYN-flooding attacks. TCP Responders should be aware of this + additional attack surface. + + TCP Responders should be careful to ensure that (1) the stream prefix + "IKETCP" uniquely identifies incoming streams as streams that use the + TCP encapsulation protocol and (2) they are not running any other + protocols on the same listening port (to avoid potential conflicts). + + Attackers may be able to disrupt the TCP connection by sending + spurious TCP Reset packets. Therefore, implementations SHOULD make + sure that IKE session state persists even if the underlying TCP + connection is torn down. + + If MOBIKE is being used, all of the security considerations outlined + for MOBIKE apply [RFC4555]. + + Similarly to MOBIKE, TCP encapsulation requires a TCP Responder to + handle changes to source address and port due to network or + connection disruption. The successful delivery of valid IKE or ESP + messages over a new TCP connection is used by the TCP Responder to + determine where to send subsequent responses. If an attacker is able + to send packets on a new TCP connection that pass the validation + checks of the TCP Responder, it can influence which path future + packets will take. For this reason, the validation of messages on + the TCP Responder must include decryption, authentication, and replay + checks. + + Since TCP provides reliable, in-order delivery of ESP messages, the + ESP anti-replay window size SHOULD be set to 1. See [RFC4303] for a + complete description of the ESP anti-replay window. This increases + the protection of implementations against replay attacks. + + + + + + + + +Pauly, et al. Standards Track [Page 15] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + +14. IANA Considerations + + TCP port 4500 is already allocated to IPsec for NAT traversal. This + port SHOULD be used for TCP-encapsulated IKE and ESP as described in + this document. + + This document updates the reference for TCP port 4500: + + Keyword Decimal Description Reference + ----------- -------- ------------------- --------- + ipsec-nat-t 4500/tcp IPsec NAT-Traversal RFC 8229 + + Figure 4 + +15. References + +15.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. + Stenberg, "UDP Encapsulation of IPsec ESP Packets", + RFC 3948, DOI 10.17487/RFC3948, January 2005, + <http://www.rfc-editor.org/info/rfc3948>. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, DOI 10.17487/RFC4303, December 2005, + <http://www.rfc-editor.org/info/rfc4303>. + + [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion + Notification", RFC 6040, DOI 10.17487/RFC6040, + November 2010, <http://www.rfc-editor.org/info/rfc6040>. + + [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. + Kivinen, "Internet Key Exchange Protocol Version 2 + (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, + October 2014, <http://www.rfc-editor.org/info/rfc7296>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <http://www.rfc-editor.org/info/rfc8174>. + + + + + + + +Pauly, et al. Standards Track [Page 16] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + +15.2. Informative References + + [IKE-over-TCP] + Nir, Y., "A TCP transport for the Internet Key Exchange", + Work in Progress, draft-ietf-ipsecme-ike-tcp-01, + December 2012. + + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, + DOI 10.17487/RFC1122, October 1989, + <http://www.rfc-editor.org/info/rfc1122>. + + [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within + HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, + <http://www.rfc-editor.org/info/rfc2817>. + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, DOI 10.17487/RFC3168, September 2001, + <http://www.rfc-editor.org/info/rfc3168>. + + [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol + (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, + <http://www.rfc-editor.org/info/rfc4555>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <http://www.rfc-editor.org/info/rfc5246>. + + [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport + Layer Security (TLS) and Datagram Transport Layer Security + (DTLS) Heartbeat Extension", RFC 6520, + DOI 10.17487/RFC6520, February 2012, + <http://www.rfc-editor.org/info/rfc6520>. + + [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 + (IKEv2) Message Fragmentation", RFC 7383, + DOI 10.17487/RFC7383, November 2014, + <http://www.rfc-editor.org/info/rfc7383>. + + + + + + + + + + + +Pauly, et al. Standards Track [Page 17] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + +Appendix A. Using TCP Encapsulation with TLS + + This section provides recommendations on how to use TLS in addition + to TCP encapsulation. + + When using TCP encapsulation, implementations may choose to use TLS + [RFC5246] on the TCP connection to be able to traverse middleboxes, + which may otherwise block the traffic. + + If a web proxy is applied to the ports used for the TCP connection + and TLS is being used, the TCP Originator can send an HTTP CONNECT + message to establish an SA through the proxy [RFC2817]. + + The use of TLS should be configurable on the peers, and may be used + as the default when using TCP encapsulation or may be used as a + fallback when basic TCP encapsulation fails. The TCP Responder may + expect to read encapsulated IKE and ESP packets directly from the TCP + connection, or it may expect to read them from a stream of TLS data + packets. The TCP Originator should be pre-configured to use TLS + or not when communicating with a given port on the TCP Responder. + + When new TCP connections are re-established due to a broken + connection, TLS must be renegotiated. TLS session resumption is + recommended to improve efficiency in this case. + + The security of the IKE session is entirely derived from the IKE + negotiation and key establishment and not from the TLS session (which + in this context is only used for encapsulation purposes); therefore, + when TLS is used on the TCP connection, both the TCP Originator and + the TCP Responder SHOULD allow the NULL cipher to be selected for + performance reasons. + + Implementations should be aware that the use of TLS introduces + another layer of overhead requiring more bytes to transmit a given + IKE and IPsec packet. For this reason, direct ESP, UDP + encapsulation, or TCP encapsulation without TLS should be preferred + in situations in which TLS is not required in order to traverse + middleboxes. + + + + + + + + + + + + + +Pauly, et al. Standards Track [Page 18] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + +Appendix B. Example Exchanges of TCP Encapsulation with TLS + +B.1. Establishing an IKE Session + + Client Server + ---------- ---------- + 1) -------------------- TCP Connection ------------------- + (IP_I:Port_I -> IP_R:Port_R) + TcpSyn ----------> + <---------- TcpSyn,Ack + TcpAck ----------> + + 2) --------------------- TLS Session --------------------- + ClientHello ----------> + ServerHello + Certificate* + ServerKeyExchange* + <---------- ServerHelloDone + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished ----------> + [ChangeCipherSpec] + <---------- Finished + + 3) ---------------------- Stream Prefix -------------------- + "IKETCP" ----------> + 4) ----------------------- IKE Session --------------------- + Length + Non-ESP Marker ----------> + IKE_SA_INIT + HDR, SAi1, KEi, Ni, + [N(NAT_DETECTION_*_IP)] + <------ Length + Non-ESP Marker + IKE_SA_INIT + HDR, SAr1, KEr, Nr, + [N(NAT_DETECTION_*_IP)] + Length + Non-ESP Marker ----------> + first IKE_AUTH + HDR, SK {IDi, [CERTREQ] + CP(CFG_REQUEST), IDr, + SAi2, TSi, TSr, ...} + <------ Length + Non-ESP Marker + first IKE_AUTH + HDR, SK {IDr, [CERT], AUTH, + EAP, SAr2, TSi, TSr} + + + + + + +Pauly, et al. Standards Track [Page 19] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + Length + Non-ESP Marker ----------> + IKE_AUTH + EAP + repeat 1..N times + <------ Length + Non-ESP Marker + IKE_AUTH + EAP + Length + Non-ESP Marker ----------> + final IKE_AUTH + HDR, SK {AUTH} + <------ Length + Non-ESP Marker + final IKE_AUTH + HDR, SK {AUTH, CP(CFG_REPLY), + SA, TSi, TSr, ...} + -------------- IKE and IPsec SAs Established ------------ + Length + ESP Frame ----------> + + Figure 5 + + 1. The client establishes a TCP connection with the server on + port 4500 or on an alternate pre-configured port that the server + is listening on. + + 2. If configured to use TLS, the client initiates a TLS handshake. + During the TLS handshake, the server SHOULD NOT request the + client's certificate, since authentication is handled as part of + IKE negotiation. + + 3. The client sends the stream prefix for TCP-encapsulated IKE + (Section 4) traffic to signal the beginning of IKE negotiation. + + 4. The client and server establish an IKE connection. This example + shows EAP-based authentication, although any authentication type + may be used. + + + + + + + + + + + + + + + + + + + +Pauly, et al. Standards Track [Page 20] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + +B.2. Deleting an IKE Session + + Client Server + ---------- ---------- + 1) ----------------------- IKE Session --------------------- + Length + Non-ESP Marker ----------> + INFORMATIONAL + HDR, SK {[N,] [D,] + [CP,] ...} + <------ Length + Non-ESP Marker + INFORMATIONAL + HDR, SK {[N,] [D,] + [CP], ...} + + 2) --------------------- TLS Session --------------------- + close_notify ----------> + <---------- close_notify + 3) -------------------- TCP Connection ------------------- + TcpFin ----------> + <---------- Ack + <---------- TcpFin + Ack ----------> + -------------------- IKE SA Deleted ------------------- + + Figure 6 + + 1. The client and server exchange informational messages to notify + IKE SA deletion. + + 2. The client and server negotiate TLS session deletion using TLS + CLOSE_NOTIFY. + + 3. The TCP connection is torn down. + + The deletion of the IKE SA should lead to the disposal of the + underlying TLS and TCP state. + + + + + + + + + + + + + + + +Pauly, et al. Standards Track [Page 21] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + +B.3. Re-establishing an IKE Session + + Client Server + ---------- ---------- + 1) -------------------- TCP Connection ------------------- + (IP_I:Port_I -> IP_R:Port_R) + TcpSyn ----------> + <---------- TcpSyn,Ack + TcpAck ----------> + 2) --------------------- TLS Session --------------------- + ClientHello ----------> + <---------- ServerHello + [ChangeCipherSpec] + Finished + [ChangeCipherSpec] ----------> + Finished + 3) ---------------------- Stream Prefix -------------------- + "IKETCP" ----------> + 4) <---------------------> IKE/ESP Flow <------------------> + Length + ESP Frame ----------> + + Figure 7 + + 1. If a previous TCP connection was broken (for example, due to a + TCP Reset), the client is responsible for re-initiating the TCP + connection. The TCP Originator's address and port (IP_I and + Port_I) may be different from the previous connection's address + and port. + + 2. In the ClientHello TLS message, the client SHOULD send the + session ID it received in the previous TLS handshake if + available. It is up to the server to perform either an + abbreviated handshake or a full handshake based on the session ID + match. + + 3. After TCP and TLS are complete, the client sends the stream + prefix for TCP-encapsulated IKE traffic (Section 4). + + 4. The IKE and ESP packet flow can resume. If MOBIKE is being used, + the Initiator SHOULD send an UPDATE_SA_ADDRESSES message. + + + + + + + + + + + +Pauly, et al. Standards Track [Page 22] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + +B.4. Using MOBIKE between UDP and TCP Encapsulation + + Client Server + ---------- ---------- + (IP_I1:UDP500 -> IP_R:UDP500) + 1) ----------------- IKE_SA_INIT Exchange ----------------- + (IP_I1:UDP4500 -> IP_R:UDP4500) + Non-ESP Marker -----------> + Initial IKE_AUTH + HDR, SK { IDi, CERT, AUTH, + CP(CFG_REQUEST), + SAi2, TSi, TSr, + N(MOBIKE_SUPPORTED) } + <----------- Non-ESP Marker + Initial IKE_AUTH + HDR, SK { IDr, CERT, AUTH, + EAP, SAr2, TSi, TSr, + N(MOBIKE_SUPPORTED) } + <------------------ IKE SA Establishment ---------------> + + 2) ------------ MOBIKE Attempt on New Network -------------- + (IP_I2:UDP4500 -> IP_R:UDP4500) + Non-ESP Marker -----------> + INFORMATIONAL + HDR, SK { N(UPDATE_SA_ADDRESSES), + N(NAT_DETECTION_SOURCE_IP), + N(NAT_DETECTION_DESTINATION_IP) } + + + 3) -------------------- TCP Connection ------------------- + (IP_I2:Port_I -> IP_R:Port_R) + TcpSyn -----------> + <----------- TcpSyn,Ack + TcpAck -----------> + + 4) --------------------- TLS Session --------------------- + ClientHello -----------> + ServerHello + Certificate* + ServerKeyExchange* + <----------- ServerHelloDone + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished -----------> + [ChangeCipherSpec] + <----------- Finished + + + + +Pauly, et al. Standards Track [Page 23] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + + 5) ---------------------- Stream Prefix -------------------- + "IKETCP" ----------> + + 6) ----------------------- IKE Session --------------------- + Length + Non-ESP Marker -----------> + INFORMATIONAL (Same as step 2) + HDR, SK { N(UPDATE_SA_ADDRESSES), + N(NAT_DETECTION_SOURCE_IP), + N(NAT_DETECTION_DESTINATION_IP) } + + <------- Length + Non-ESP Marker + HDR, SK { N(NAT_DETECTION_SOURCE_IP), + N(NAT_DETECTION_DESTINATION_IP) } + 7) <----------------- IKE/ESP Data Flow -------------------> + + Figure 8 + + 1. During the IKE_SA_INIT exchange, the client and server exchange + MOBIKE_SUPPORTED notify payloads to indicate support for MOBIKE. + + 2. The client changes its point of attachment to the network and + receives a new IP address. The client attempts to re-establish + the IKE session using the UPDATE_SA_ADDRESSES notify payload, but + the server does not respond because the network blocks UDP + traffic. + + 3. The client brings up a TCP connection to the server in order to + use TCP encapsulation. + + 4. The client initiates a TLS handshake with the server. + + 5. The client sends the stream prefix for TCP-encapsulated IKE + traffic (Section 4). + + 6. The client sends the UPDATE_SA_ADDRESSES notify payload on the + TCP-encapsulated connection. Note that this IKE message is the + same as the one sent over UDP in step 2; it should have the same + message ID and contents. + + 7. The IKE and ESP packet flow can resume. + + + + + + + + + + + +Pauly, et al. Standards Track [Page 24] + +RFC 8229 TCP Encapsulation of IKE and IPsec Packets August 2017 + + +Acknowledgments + + The authors would like to acknowledge the input and advice of Stuart + Cheshire, Delziel Fernandes, Yoav Nir, Christoph Paasch, Yaron + Sheffer, David Schinazi, Graham Bartlett, Byju Pularikkal, March Wu, + Kingwel Xie, Valery Smyslov, Jun Hu, and Tero Kivinen. Special + thanks to Eric Kinnear for his implementation work. + +Authors' Addresses + + Tommy Pauly + Apple Inc. + 1 Infinite Loop + Cupertino, California 95014 + United States of America + + Email: tpauly@apple.com + + + Samy Touati + Ericsson + 2755 Augustine + Santa Clara, California 95054 + United States of America + + Email: samy.touati@ericsson.com + + + Ravi Mantha + Cisco Systems + SEZ, Embassy Tech Village + Panathur, Bangalore 560 037 + India + + Email: ramantha@cisco.com + + + + + + + + + + + + + + + + +Pauly, et al. Standards Track [Page 25] + |