--- 1/draft-ietf-ipsecme-tcp-encaps-06.txt 2017-02-09 09:13:10.886781488 -0800 +++ 2/draft-ietf-ipsecme-tcp-encaps-07.txt 2017-02-09 09:13:10.938782722 -0800 @@ -1,48 +1,48 @@ Network T. Pauly Internet-Draft Apple Inc. Intended status: Standards Track S. Touati -Expires: August 7, 2017 Ericsson +Expires: August 13, 2017 Ericsson R. Mantha Cisco Systems - February 3, 2017 + February 9, 2017 TCP Encapsulation of IKE and IPsec Packets - draft-ietf-ipsecme-tcp-encaps-06 + draft-ietf-ipsecme-tcp-encaps-07 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 Security - Association establishment as well as ESP packets over a TCP - connection. This method is intended to be used as a fallback option - when IKE cannot be negotiated over UDP. + Association establishment and 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 August 7, 2017. + This Internet-Draft will expire on August 13, 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 @@ -166,25 +166,25 @@ 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 the - IKE peer that initiates TCP connections. The peer that receives TCP - connections will be referred to as the "TCP Responder". The TCP - Originator MUST be the same as the "Original Initiator", or the - Initiator of the first IKE SA exchange for a given IKE session. + 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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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. @@ -363,22 +363,22 @@ 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 all - the SA has been deleted, the TCP Originator SHOULD close the TCP + 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 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 TCP Originator is responsible for re-establishing the TCP connection if @@ -400,22 +400,22 @@ 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 keepalive) otherwise. If either TCP Originator or TCP Responder receives a stream that cannot be parsed correctly (for example, if the TCP Originator stream is missing the stream prefix, or message frames are 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. + payload and tear down the IKE SA as ususal, rather than tearing down + the TCP connection directly. An 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