< draft-ietf-ipsecme-tcp-encaps-06.txt		draft-ietf-ipsecme-tcp-encaps-07.txt >
	Network T. Pauly		Network T. Pauly
	Internet-Draft Apple Inc.		Internet-Draft Apple Inc.
	Intended status: Standards Track S. Touati		Intended status: Standards Track S. Touati
	Expires: August 7, 2017 Ericsson		Expires: August 13, 2017 Ericsson
	R. Mantha		R. Mantha
	Cisco Systems		Cisco Systems
	February 3, 2017		February 9, 2017
	TCP Encapsulation of IKE and IPsec Packets		TCP Encapsulation of IKE and IPsec Packets
	draft-ietf-ipsecme-tcp-encaps-06		draft-ietf-ipsecme-tcp-encaps-07
	Abstract		Abstract
	This document describes a method to transport IKE and IPsec packets		This document describes a method to transport IKE and IPsec packets
	over a TCP connection for traversing network middleboxes that may		over a TCP connection for traversing network middleboxes that may
	block IKE negotiation over UDP. This method, referred to as TCP		block IKE negotiation over UDP. This method, referred to as TCP
	encapsulation, involves sending both IKE packets for Security		encapsulation, involves sending both IKE packets for Security
	Association establishment as well as ESP packets over a TCP		Association establishment and ESP packets over a TCP connection.
	connection. This method is intended to be used as a fallback option		This method is intended to be used as a fallback option when IKE
	when IKE cannot be negotiated over UDP.		cannot be negotiated over UDP.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		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 Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 35 ¶
	1.2. Terminology and Notation		1.2. Terminology and Notation
	This document distinguishes between the IKE peer that initiates TCP		This document distinguishes between the IKE peer that initiates TCP
	connections to be used for TCP encapsulation and the roles of		connections to be used for TCP encapsulation and the roles of
	Initiator and Responder for particular IKE messages. During the		Initiator and Responder for particular IKE messages. During the
	course of IKE exchanges, the role of IKE Initiator and Responder may		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		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		the TCP connection is still responsible for tearing down the TCP
	connection and re-establishing it if necessary. For this reason,		connection and re-establishing it if necessary. For this reason,
	this document will use the term "TCP Originator" to indicate the the		this document will use the term "TCP Originator" to indicate the IKE
	IKE peer that initiates TCP connections. The peer that receives TCP		peer that initiates TCP connections. The peer that receives TCP
	connections will be referred to as the "TCP Responder". The TCP		connections will be referred to as the "TCP Responder". If an IKE SA
	Originator MUST be the same as the "Original Initiator", or the		is rekeyed one or more times, the TCP Originator MUST remain the peer
	Initiator of the first IKE SA exchange for a given IKE session.		that originally initiated the first IKE SA.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Configuration		2. Configuration
	One of the main reasons to use TCP encapsulation is that UDP traffic		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		may be entirely blocked on a network. Because of this, support for
	TCP encapsulation is not specifically negotiated in the IKE exchange.		TCP encapsulation is not specifically negotiated in the IKE exchange.
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	bytes sent on the stream MUST be the stream prefix value [Section 4].		bytes sent on the stream MUST be the stream prefix value [Section 4].
	After this prefix, encapsulated IKE messages will negotiate the IKE		After this prefix, encapsulated IKE messages will negotiate the IKE
	SA and initial Child SA [RFC7296]. After this point, both		SA and initial Child SA [RFC7296]. After this point, both
	encapsulated IKE Figure 1 and ESP Figure 2 messages will be sent over		encapsulated IKE Figure 1 and ESP Figure 2 messages will be sent over
	the TCP connection. The TCP Responder MUST wait for the entire		the TCP connection. The TCP Responder MUST wait for the entire
	stream prefix to be received on the stream before trying to parse out		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		any IKE or ESP messages. The stream prefix is sent only once, and
	only by the TCP Originator.		only by the TCP Originator.
	In order to close an IKE session, either the Initiator or Responder		In order to close an IKE session, either the Initiator or Responder
	SHOULD gracefully tear down IKE SAs with DELETE payloads. Once all		SHOULD gracefully tear down IKE SAs with DELETE payloads. Once the
	the SA has been deleted, the TCP Originator SHOULD close the TCP		SA has been deleted, the TCP Originator SHOULD close the TCP
	connection if it does not intend to use the connection for another		connection if it does not intend to use the connection for another
	IKE session to the TCP Responder. If the connection is left idle,		IKE session to the TCP Responder. If the connection is left idle,
	and the TCP Responder needs to clean up resources, the TCP Responder		and the TCP Responder needs to clean up resources, the TCP Responder
	MAY close the TCP connection.		MAY close the TCP connection.
	An unexpected FIN or a RST on the TCP connection may indicate either		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		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		payload has not been sent, both sides SHOULD maintain the state for
	their SAs for the standard lifetime or time-out period. The TCP		their SAs for the standard lifetime or time-out period. The TCP
	Originator is responsible for re-establishing the TCP connection if		Originator is responsible for re-establishing the TCP connection if
	skipping to change at page 9, line 29 ¶		skipping to change at page 9, line 29 ¶
	from an encapsulated IKE message or the ESP SPI from an encapsulated		from an encapsulated IKE message or the ESP SPI from an encapsulated
	ESP message. If the session had been fully established previously,		ESP message. If the session had been fully established previously,
	it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES		it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES
	message if MOBIKE is supported, or an INFORMATIONAL message (a		message if MOBIKE is supported, or an INFORMATIONAL message (a
	keepalive) otherwise. If either TCP Originator or TCP Responder		keepalive) otherwise. If either TCP Originator or TCP Responder
	receives a stream that cannot be parsed correctly (for example, if		receives a stream that cannot be parsed correctly (for example, if
	the TCP Originator stream is missing the stream prefix, or message		the TCP Originator stream is missing the stream prefix, or message
	frames are not parsable as IKE or ESP messages), it MUST close the		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		TCP connection. If there is instead a syntax issue within an IKE
	message, an implementation MUST send the INVALID_SYNTAX notify		message, an implementation MUST send the INVALID_SYNTAX notify
	payload and tear down the IKE session as ususal, rather than tearing		payload and tear down the IKE SA as ususal, rather than tearing down
	down the TCP connection directly.		the TCP connection directly.
	An TCP Originator SHOULD only open one TCP connection per IKE SA,		An TCP Originator SHOULD only open one TCP connection per IKE SA,
	over which it sends all of the corresponding IKE and ESP messages.		over which it sends all of the corresponding IKE and ESP messages.
	This helps ensure that any firewall or NAT mappings allocated for the		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		TCP connection apply to all of the traffic associated with the IKE SA
	equally.		equally.
	Similarly, a TCP Responder SHOULD at any given time send packets for		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		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		choose the TCP connection on which it last received a valid and
End of changes. 8 change blocks.
	16 lines changed or deleted		16 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/