--- 1/draft-ietf-ipsecme-tcp-encaps-00.txt 2016-07-07 17:16:11.404230026 -0700 +++ 2/draft-ietf-ipsecme-tcp-encaps-01.txt 2016-07-07 17:16:11.444231035 -0700 @@ -1,21 +1,21 @@ Network T. Pauly Internet-Draft Apple Inc. Intended status: Standards Track S. Touati -Expires: December 26, 2016 Ericsson +Expires: January 8, 2017 Ericsson R. Mantha Cisco Systems - June 24, 2016 + July 7, 2016 TCP Encapsulation of IKE and IPSec Packets - draft-ietf-ipsecme-tcp-encaps-00 + draft-ietf-ipsecme-tcp-encaps-01 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 all packets for tunnel establishment as well as tunneled packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. @@ -28,21 +28,21 @@ 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 December 26, 2016. + This Internet-Draft will expire on January 8, 2017. Copyright Notice Copyright (c) 2016 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 @@ -55,59 +55,59 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Prior Work and Motivation . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Connection Establishment and Teardown . . . . . . . . . . . . 7 7. Interaction with NAT Detection Payloads . . . . . . . . . . . 8 - 8. Using MOBIKE with TCP encapsulation . . . . . . . . . . . . . 8 + 8. Using MOBIKE with TCP encapsulation . . . . . . . . . . . . . 9 9. Using IKE Message Fragmentation with TCP encapsulation . . . 9 10. Considerations for Keep-alives and DPD . . . . . . . . . . . 9 - 11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 9 + 11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 10 12. Performance Considerations . . . . . . . . . . . . . . . . . 10 12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 10 - 12.2. Added Reliability for Unreliable Protocols . . . . . . . 10 - 12.3. Quality of Service Markings . . . . . . . . . . . . . . 10 + 12.2. Added Reliability for Unreliable Protocols . . . . . . . 11 + 12.3. Quality of Service Markings . . . . . . . . . . . . . . 11 12.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 11 13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 16.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 16.1. Normative References . . . . . . . . . . . . . . . . . . 12 16.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 13 - Appendix B. Example exchanges of TCP Encapsulation with TLS . . 13 - B.1. Establishing an IKE session . . . . . . . . . . . . . . . 13 - B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 15 - B.3. Re-establishing an IKE session . . . . . . . . . . . . . 16 - B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + Appendix B. Example exchanges of TCP Encapsulation with TLS . . 14 + B.1. Establishing an IKE session . . . . . . . . . . . . . . . 14 + B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 16 + B.3. Re-establishing an IKE session . . . . . . . . . . . . . 17 + B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 its 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 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 tunnels. This document - defines a method for encapsulating both the IKE control messages as - well as the IPSec data messages within a TCP connection. + 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 + 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 tunnels. + This document defines a method for encapsulating both the IKE control + messages as well as the 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 NAT is detected between the initiator and the receiver, then subsequent IKE packets are sent over UDP port 500 and IPSec data packets are sent using ESP [RFC4303]. 2. UDP Encapsulation [RFC3948]. If a NAT is detected between the @@ -176,28 +176,28 @@ o One or more TCP ports on which the responder will listen for incoming connections. Note that the initiator may initiate TCP connections to the responder from any local port. o Optionally, 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. This document leaves the selection of TCP ports up to - implementations. It's suggested to use TCP port 4500, which is + implementations. It is suggested to use TCP port 4500, which is allocated for IPSec NAT Traversal. Since TCP encapsulation of IKE and IPSec packets adds overhead and has potential performance trade-offs compared to direct or UDP- encapsulated tunnels (as described in Performance Considerations, - Section 12), when possible, implementations SHOULD prefer ESP direct - or UDP encapsulated tunnels over TCP encapsulated tunnels. + Section 12), implementations SHOULD prefer ESP direct or UDP + encapsulated tunnels over TCP encapsulated tunnels when possible. 3. TCP-Encapsulated Header Formats In order to encapsulate IKE and ESP messages within a TCP stream, a 16-bit length field 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. @@ -252,48 +252,58 @@ order that specifies the length of the ESP packet within the TCP stream. The SPI field 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 TCP stream used for IKE and IPSec encapsulation MUST begin with - a fixed sequence of five bytes as a magic value, containing the + 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 allows peers to differentiate this protocol from other protocols that may be run over - TCP streams, since the value does not overlap with the valid start of + TCP streams, since the bytes do not overlap with the valid start of any other known stream protocol. This value is only sent once, by - the Initiator only, at the beginning of any TCP stream. If other - framing protocols are used within TCP to further encapsulate or - encrypt the stream of IKE and ESP messages, the Stream Prefix must - still precede any IKE or ESP messages. + the Initiator 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 Initiator's IKE and ESP message stream within + the added protocol layer [Appendix A]. 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 MOBIKE is used to change the SA endpoints and/or encapsulation protocol. No packets should be sent over UDP or direct ESP for the IKE SA or its Child SAs while using TCP encapsulation. 6. Connection Establishment and Teardown When the IKE initiator uses TCP encapsulation for its negotiation, it @@ -581,28 +591,33 @@ The use of TLS should be configurable on the peers. The 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 initiator should be pre-configured to use TLS or not when communicating with a given port on the responder. When new TCP connections are re-established due to a broken connection, TLS must be re-negotiated. TLS Session Resumption is recommended to improve efficiency in this case. - The security of the IKE session is entirely derived from the IKVEv2 - negotiation and key establishment, therefore When TLS is used on the - TCP connection, both the initiator and responder MUST allow for the - NULL cipher to be selected. + 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 initiator and + responder SHOULD allow the NULL cipher to be selected for performance + reasons. - Implementations must be aware that the use of TLS introduces another - layer of overhead requiring more bytes to transmit a given IKE and - IPSec packet. + 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 + middle-boxes. 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:TCP443 or TCP4500) TcpSyn ----------> <---------- TcpSyn,Ack @@ -800,21 +815,21 @@ 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 beings up a TCP connection to the server in order to + 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.