--- 1/draft-ietf-ipsecme-tcp-encaps-04.txt 2017-01-23 14:13:43.614245715 -0800 +++ 2/draft-ietf-ipsecme-tcp-encaps-05.txt 2017-01-23 14:13:43.666246949 -0800 @@ -1,21 +1,21 @@ Network T. Pauly Internet-Draft Apple Inc. Intended status: Standards Track S. Touati -Expires: June 6, 2017 Ericsson +Expires: July 27, 2017 Ericsson R. Mantha Cisco Systems - December 3, 2016 + January 23, 2017 TCP Encapsulation of IKE and IPsec Packets - draft-ietf-ipsecme-tcp-encaps-04 + draft-ietf-ipsecme-tcp-encaps-05 Abstract This document describes a method to transport 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 tunnel establishment as well as tunneled packets using ESP over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. @@ -28,25 +28,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 6, 2017. + This Internet-Draft will expire on July 27, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + 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 @@ -59,41 +59,41 @@ 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 4 3. TCP-Encapsulated Header Formats . . . . . . . . . . . . . . . 5 3.1. TCP-Encapsulated IKE Header Format . . . . . . . . . . . 5 3.2. TCP-Encapsulated ESP Header Format . . . . . . . . . . . 6 4. TCP-Encapsulated Stream Prefix . . . . . . . . . . . . . . . 6 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Recommended Fallback from UDP . . . . . . . . . . . . . . 7 6. Connection Establishment and Teardown . . . . . . . . . . . . 8 7. Interaction with NAT Detection Payloads . . . . . . . . . . . 9 - 8. Using MOBIKE with TCP encapsulation . . . . . . . . . . . . . 9 + 8. Using MOBIKE with TCP encapsulation . . . . . . . . . . . . . 10 9. Using IKE Message Fragmentation with TCP encapsulation . . . 10 - 10. Considerations for Keep-alives and DPD . . . . . . . . . . . 10 - 11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 10 + 10. Considerations for Keep-alives and DPD . . . . . . . . . . . 11 + 11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 11 12. Performance Considerations . . . . . . . . . . . . . . . . . 11 - 12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 11 - 12.2. Added Reliability for Unreliable Protocols . . . . . . . 11 - 12.3. Quality of Service Markings . . . . . . . . . . . . . . 11 + 12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 12 + 12.2. Added Reliability for Unreliable Protocols . . . . . . . 12 + 12.3. Quality of Service Markings . . . . . . . . . . . . . . 12 12.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 12 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 16.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 16.2. Informative References . . . . . . . . . . . . . . . . . 13 - Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 14 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 16.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 16.2. Informative References . . . . . . . . . . . . . . . . . 14 + Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 15 Appendix B. Example exchanges of TCP Encapsulation with TLS . . 15 B.1. Establishing an IKE session . . . . . . . . . . . . . . . 15 B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 17 B.3. Re-establishing an IKE session . . . . . . . . . . . . . 18 - B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 18 + B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction IKEv2 [RFC7296] is a protocol for establishing IPsec tunnels, using IKE messages over UDP for control traffic, and using Encapsulating Security Payload (ESP) messages for tunneled data traffic. Many network middleboxes that filter traffic on public hotspots block all UDP traffic, including IKE and IPsec, but allow TCP connections through since they appear to be web traffic. Devices on these @@ -343,117 +343,141 @@ network is likely to block UDP. 6. Connection Establishment and Teardown When the IKE initiator uses TCP encapsulation for its negotiation, 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. + messages will be sent over the TCP connection. The 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 initiator. In order to close an IKE session, either the initiator or responder SHOULD gracefully tear down IKE SAs with DELETE payloads. Once all - SAs have been deleted, the initiator of the original connection MUST - close the TCP connection. + SAs have been deleted, the initiator of the original connection + SHOULD close the TCP connection if it does not intend to use the + connection for another IKE session to the responder. If the + connection is left idle, and the responder needs to clean up + resources, the responder MAY close the TCP connection. An unexpected FIN or a RST on the TCP connection may indicate either 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 time-out period. The original initiator (that is, the endpoint that initiated the TCP connection and sent the first IKE_SA_INIT message) 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 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. - The streams of data sent over any TCP connection used for this - protocol MUST begin with the stream prefix value followed by a - complete message, which is either an encapsulated IKE or ESP message. + Whenever the initiator 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. + If the connection is being used to resume a previous IKE session, the 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 initiator send an UPDATE_SA_ADDRESSES message if MOBIKE is supported, or an INFORMATIONAL message (a keepalive) otherwise. If either initiator or responder receives a stream that - cannot be parsed correctly, it MUST close the TCP connection. + cannot be parsed correctly (initiator stream missing the stream + prefix, or message frames not parsable as IKE or ESP messages), it + MUST close the TCP connection. 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 session as ususal, rather than + tearing down the TCP connection directly. An initiator 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. A 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 + 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. Since a connection may be broken and a new connection - re-established by the initiator without the responder being aware, a - responder SHOULD accept receiving IKE and ESP messages on a new - connection. It will then use that connection for all subsequent - responses. A 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). + ESP message. In order to be considered valid for choosing a TCP + connection, an IKE message successfully decrypt and be 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, not be a + replay of a previous message. - Multiple IKE SAs SHOULD NOT share a single TCP connection. + Since a connection may be broken and a new connection re-established + by the initiator without the responder being aware, a responder + SHOULD accept receiving IKE and ESP messages on both old and new + connections until the old connection is closed by the initiator. A + 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). + + Multiple IKE SAs MUST NOT share a single 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. IKE_SA_INIT packets sent on a TCP connection SHOULD include these payloads, 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 + [RFC3948]. + 8. Using MOBIKE with TCP encapsulation - When an IKE session is transitioned between networks using MOBIKE - [RFC4555], 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 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. 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 MAY choose to not fragment when going over a TCP - connection. + implementation SHOULD NOT send fragments when going over a TCP + connection, although it MUST support receiving fragements. 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 DPD 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 @@ -544,35 +568,48 @@ protocol. The prefix was chosen to not overlap with the start of any known valid protocol over TCP, but implementations should make sure to validate this assumption in order to avoid unexpected processing of TCP connections. Attackers may be able to disrupt the TCP connection by sending spurious RST packets. Due to this, 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 responder to handle + changing of 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 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 + responder, it can influence which path future packets take. For this + reason, the validation of messages on the responder must include + decryption, authentication, and replay checks. + 14. IANA Considerations This memo includes no request to IANA. TCP port 4500 is already allocated to IPsec. This port MAY be used for the protocol described in this document, but implementations MAY prefer to use other ports based on local policy. 15. 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 - and Kingwel Xie. Special thanks to Eric Kinnear for his - implementation work. + 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. 16. References 16.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, . @@ -683,43 +721,51 @@ ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished ----------> [ChangeCipherSpec] <---------- Finished 3) ---------------------- Stream Prefix -------------------- "IKETCP" ----------> 4) ----------------------- IKE Session --------------------- - IKE_SA_INIT ----------> + Length + Non-ESP Marker ----------> + IKE_SA_INIT HDR, SAi1, KEi, Ni, [N(NAT_DETECTION_*_IP)] - <---------- IKE_SA_INIT + <------ Length + Non-ESP Marker + IKE_SA_INIT HDR, SAr1, KEr, Nr, [N(NAT_DETECTION_*_IP)] - first IKE_AUTH ----------> + Length + Non-ESP Marker ----------> + first IKE_AUTH HDR, SK {IDi, [CERTREQ] CP(CFG_REQUEST), IDr, SAi2, TSi, TSr, ...} - <---------- first IKE_AUTH + <------ Length + Non-ESP Marker + first IKE_AUTH HDR, SK {IDr, [CERT], AUTH, EAP, SAr2, TSi, TSr} - EAP ----------> + Length + Non-ESP Marker ----------> + IKE_AUTH + EAP repeat 1..N times - <---------- EAP - final IKE_AUTH ----------> + <------ Length + Non-ESP Marker + IKE_AUTH + EAP + Length + Non-ESP Marker ----------> + final IKE_AUTH HDR, SK {AUTH} - <---------- final IKE_AUTH + <------ Length + Non-ESP Marker + final IKE_AUTH HDR, SK {AUTH, CP(CFG_REPLY), SA, TSi, TSr, ...} ----------------- IKE Tunnel Established ---------------- - + Length + ESP frame ----------> Figure 4 1. Client establishes a TCP connection with the server on port 443 or 4500. 2. Client initiates TLS handshake. During TLS handshake, the server SHOULD NOT request the client's' certificate, since authentication is handled as part of IKE negotiation. 3. Client send the Stream Prefix for TCP encapsulated IKE @@ -727,24 +773,26 @@ 4. Client and server establish an IKE connection. This example shows EAP-based authentication, although any authentication type may be used. B.2. Deleting an IKE session Client Server ---------- ---------- 1) ----------------------- IKE Session --------------------- - INFORMATIONAL ----------> + Length + Non-ESP Marker ----------> + INFORMATIONAL HDR, SK {[N,] [D,] [CP,] ...} - <---------- INFORMATIONAL + <------ Length + Non-ESP Marker + INFORMATIONAL HDR, SK {[N,] [D,] [CP], ...} 2) --------------------- TLS Session --------------------- close_notify ----------> <---------- close_notify 3) -------------------- TCP Connection ------------------- TcpFin ----------> <---------- Ack <---------- TcpFin @@ -776,20 +824,21 @@ 2) --------------------- TLS Session --------------------- ClientHello ----------> <---------- ServerHello [ChangeCipherSpec] Finished [ChangeCipherSpec] ----------> Finished 3) ---------------------- Stream Prefix -------------------- "IKETCP" ----------> 4) <---------------------> IKE/ESP flow <------------------> + Length + ESP frame ----------> Figure 6 1. If a previous TCP connection was broken (for example, due to a RST), the client is responsible for re-initiating the TCP connection. The initiator's address and port (IP_I and Port_I) may be different from the previous connection's address and port. 2. In ClientHello TLS message, the client SHOULD send the Session @@ -803,34 +852,37 @@ 4. The IKE and ESP packet flow can resume. If MOBIKE is being used, the initiator SHOULD send UPDATE_SA_ADDRESSES. 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) - Intial IKE_AUTH -----------> + Non-ESP Marker -----------> + Intial IKE_AUTH HDR, SK { IDi, CERT, AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr, N(MOBIKE_SUPPORTED) } - <----------- Initial IKE_AUTH + <----------- Non-ESP Marker + Initial IKE_AUTH HDR, SK { IDr, CERT, AUTH, EAP, SAr2, TSi, TSr, N(MOBIKE_SUPPORTED) } <---------------- IKE tunnel establishment -------------> 2) ------------ MOBIKE Attempt on new network -------------- (IP_I2:UDP4500 -> IP_R:UDP4500) - INFORMATIONAL -----------> + 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:TCP443 or TCP4500) TcpSyn -----------> <----------- TcpSyn,Ack TcpAck -----------> @@ -839,31 +891,32 @@ ServerHello Certificate* ServerKeyExchange* <----------- ServerHelloDone ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished -----------> [ChangeCipherSpec] <----------- Finished + 5) ---------------------- Stream Prefix -------------------- "IKETCP" ----------> 6) ----------------------- IKE Session --------------------- - INFORMATIONAL -----------> + 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) } - <----------- INFORMATIONAL - + <------- Length + Non-ESP Marker HDR, SK { N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP) } 7) <----------------- IKE/ESP data flow -------------------> Figure 7 1. During the IKE_SA_INIT exchange, the client and server exchange MOBIKE_SUPPORTED notify payloads to indicate support for MOBIKE. @@ -875,26 +928,27 @@ 3. The client brings up a TCP connection to the server in order to use TCP encapsulation. 4. The client initiates and 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. + TCP encapsulated connection. Note that this IKE message is the + same as the one sent over UDP in step 2, and should have the + same message ID and contents. 7. The IKE and ESP packet flow can resume. Authors' Addresses - Tommy Pauly Apple Inc. 1 Infinite Loop Cupertino, California 95014 US Email: tpauly@apple.com Samy Touati Ericsson