--- 1/draft-ietf-ipsecme-tcp-encaps-02.txt 2016-10-31 09:16:06.620249124 -0700 +++ 2/draft-ietf-ipsecme-tcp-encaps-03.txt 2016-10-31 09:16:06.664250205 -0700 @@ -1,21 +1,21 @@ Network T. Pauly Internet-Draft Apple Inc. Intended status: Standards Track S. Touati -Expires: February 18, 2017 Ericsson +Expires: May 4, 2017 Ericsson R. Mantha Cisco Systems - August 17, 2016 + October 31, 2016 TCP Encapsulation of IKE and IPsec Packets - draft-ietf-ipsecme-tcp-encaps-02 + draft-ietf-ipsecme-tcp-encaps-03 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,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 February 18, 2017. + This Internet-Draft will expire on May 4, 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 @@ -56,38 +56,39 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 - 6. Connection Establishment and Teardown . . . . . . . . . . . . 7 - 7. Interaction with NAT Detection Payloads . . . . . . . . . . . 8 + 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 - 9. Using IKE Message Fragmentation with TCP encapsulation . . . 9 - 10. Considerations for Keep-alives and DPD . . . . . . . . . . . 9 + 9. Using IKE Message Fragmentation with TCP encapsulation . . . 10 + 10. Considerations for Keep-alives and DPD . . . . . . . . . . . 10 11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 10 - 12. Performance Considerations . . . . . . . . . . . . . . . . . 10 - 12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 10 + 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.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 11 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 16.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 16.2. Informative References . . . . . . . . . . . . . . . . . 12 - Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 13 + 16.2. Informative References . . . . . . . . . . . . . . . . . 13 + Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 14 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 @@ -211,20 +212,24 @@ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | @@ -311,20 +316,39 @@ 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. 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 negotiate IKE over UDP first. IKEv2 defines how to + use retransmission timers with IKE messages, and IKE_SA_INIT messages + specifically [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 + 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 is 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 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. @@ -356,25 +380,29 @@ 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. Multiple TCP connections between the initiator and the responder are allowed, but their use must take into account the initiator capabilities and the deployment model such as to connect to multiple gateways handling different ESP SAs when deployed in a high - availability model. It is also possible to negotiate multiple IKE - SAs over the same TCP connection. + availability model. If multiple TCP connections are used, + implementations SHOULD allow receiving any IKE or ESP SA over any of + the TCP connections, not enforcing any strict mapping. It is also + possible to negotiate multiple IKE SAs over the same TCP connection + in order to reduce the number of connections between the two peers. - The processing of the TCP packets is the same whether its within a - single or multiple TCP connections. + The processing of the TCP-encapsulated IKE and ESP packets is the + same when using either a single TCP connection or multiple TCP + connections. 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.