< draft-ietf-ipsecme-rfc8229bis-04.txt		draft-ietf-ipsecme-rfc8229bis-05.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Obsoletes: 8229 (if approved) T. Pauly		Obsoletes: 8229 (if approved) T. Pauly
	Intended status: Standards Track Apple Inc.		Intended status: Standards Track Apple Inc.
	Expires: 24 September 2022 23 March 2022		Expires: 24 September 2022 23 March 2022
	TCP Encapsulation of IKE and IPsec Packets		TCP Encapsulation of IKE and IPsec Packets
	draft-ietf-ipsecme-rfc8229bis-04		draft-ietf-ipsecme-rfc8229bis-05
	Abstract		Abstract
	This document describes a method to transport Internet Key Exchange		This document describes a method to transport Internet Key Exchange
	Protocol (IKE) and IPsec packets over a TCP connection for traversing		Protocol (IKE) and IPsec packets over a TCP connection for traversing
	network middleboxes that may block IKE negotiation over UDP. This		network middleboxes that may block IKE negotiation over UDP. This
	method, referred to as "TCP encapsulation", involves sending both IKE		method, referred to as "TCP encapsulation", involves sending both IKE
	packets for Security Association establishment and Encapsulating		packets for Security Association establishment and Encapsulating
	Security Payload (ESP) packets over a TCP connection. This method is		Security Payload (ESP) packets over a TCP connection. This method is
	intended to be used as a fallback option when IKE cannot be		intended to be used as a fallback option when IKE cannot be
	skipping to change at page 9, line 16 ¶		skipping to change at page 9, line 16 ¶
	maximum number of retransmissions allowed before marking the IKE SA		maximum number of retransmissions allowed before marking the IKE SA
	as failed. An implementation can attempt negotiation over TCP once		as failed. An implementation can attempt negotiation over TCP once
	it has hit the maximum retransmissions over UDP, or slightly before		it has hit the maximum retransmissions over UDP, or slightly before
	to reduce connection setup delays. It is recommended that the		to reduce connection setup delays. It is recommended that the
	initial message over UDP be retransmitted at least once before		initial message over UDP be retransmitted at least once before
	falling back to TCP, unless the Initiator knows beforehand that the		falling back to TCP, unless the Initiator knows beforehand that the
	network is likely to block UDP.		network is likely to block UDP.
	When switching from UDP to TCP, a new IKE_SA_INIT exchange MUST be		When switching from UDP to TCP, a new IKE_SA_INIT exchange MUST be
	initiated with new Initiator's SPI and with recalculated content of		initiated with new Initiator's SPI and with recalculated content of
	NAT_DETECTION_SOURCE_IP notification.		NAT_DETECTION_*_IP notifications.
	7. Using TCP Encapsulation		7. Using TCP Encapsulation
	7.1. Connection Establishment and Teardown		7.1. Connection Establishment and Teardown
	When the IKE Initiator uses TCP encapsulation, it will initiate a TCP		When the IKE Initiator uses TCP encapsulation, it will initiate a TCP
	connection to the Responder using the configured TCP port. The first		connection to the Responder using the configured TCP port. The first
	bytes sent on the stream MUST be the stream prefix value (Section 5).		bytes sent on the stream MUST be the stream prefix value (Section 5).
	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
	skipping to change at page 16, line 18 ¶		skipping to change at page 16, line 18 ¶
	started in this situation. If the Responder only responds to the		started in this situation. If the Responder only responds to the
	request sent over TCP, then the ESP packets should be sent over the		request sent over TCP, then the ESP packets should be sent over the
	TCP connection, regardless of if a connection on a previous network		TCP connection, regardless of if a connection on a previous network
	did not use TCP encapsulation.		did not use TCP encapsulation.
	If the TCP transport was used for the previous network connection,		If the TCP transport was used for the previous network connection,
	the old TCP connection SHOULD be closed by the Initiator once MOBIKE		the old TCP connection SHOULD be closed by the Initiator once MOBIKE
	finishes migration to a new connection (either TCP or UDP).		finishes migration to a new connection (either TCP or UDP).
	Since switching from UDP to TCP can happen during a single		Since switching from UDP to TCP can happen during a single
	INFORMATIONAL message exchange, the content of the		INFORMATIONAL message exchange, the content of the NAT_DETECTION_*_IP
	NAT_DETECTION_SOURCE_IP notification will in most cases be incorrect		notifications will in most cases be incorrect (since UDP and TCP
	(since UDP and TCP source ports will most likely be different), and		ports will most likely be different), and the peer may incorrectly
	the peer may incorrectly detect the presence of a NAT. Section 3.5		detect the presence of a NAT. Section 3.5 of [RFC4555] states that a
	of [RFC4555] states that a new INFORMATIONAL exchange with the		new INFORMATIONAL exchange with the UPDATE_SA_ADDRESSES notify is
	UPDATE_SA_ADDRESSES notify is initiated in case the address (or		initiated in case the address (or transport) is changed while waiting
	transport) is changed while waiting for a response.		for a response.
	Section 3.5 of [RFC4555] also states that once an IKE SA is switched		Section 3.5 of [RFC4555] also states that once an IKE SA is switched
	to a new IP address, all outstanding requests in this SA are		to a new IP address, all outstanding requests in this SA are
	immediately retransmitted using this address. See also Section 7.2.		immediately retransmitted using this address. See also Section 7.2.
	The MOBIKE protocol defines the NO_NATS_ALLOWED notification that can		The MOBIKE protocol defines the NO_NATS_ALLOWED notification that can
	be used to detect the presence of NAT between peer and to refuse to		be used to detect the presence of NAT between peer and to refuse to
	communicate in this situation. In case of TCP the NO_NATS_ALLOWED		communicate in this situation. In case of TCP the NO_NATS_ALLOWED
	notification SHOULD be ignored because TCP generally has no problems		notification SHOULD be ignored because TCP generally has no problems
	with NAT boxes.		with NAT boxes.
	skipping to change at page 25, line 48 ¶		skipping to change at page 25, line 48 ¶
	{CertificateVerify*}		{CertificateVerify*}
	<---------- {Finished}		<---------- {Finished}
	{Finished} ---------->		{Finished} ---------->
	3) ---------------------- Stream Prefix --------------------		3) ---------------------- Stream Prefix --------------------
	"IKETCP" ---------->		"IKETCP" ---------->
	4) ----------------------- IKE Session ---------------------		4) ----------------------- IKE Session ---------------------
	Length + Non-ESP Marker ---------->		Length + Non-ESP Marker ---------->
	IKE_SA_INIT		IKE_SA_INIT
	HDR, SAi1, KEi, Ni,		HDR, SAi1, KEi, Ni,
	[N(NAT_DETECTION_*_IP)]		[N(NAT_DETECTION_SOURCE_IP)],
			[N(NAT_DETECTION_DESTINATION_IP)]
	<------ Length + Non-ESP Marker		<------ Length + Non-ESP Marker
	IKE_SA_INIT		IKE_SA_INIT
	HDR, SAr1, KEr, Nr,		HDR, SAr1, KEr, Nr,
	[N(NAT_DETECTION_*_IP)]
			[N(NAT_DETECTION_SOURCE_IP)],
			[N(NAT_DETECTION_DESTINATION_IP)]
	Length + Non-ESP Marker ---------->		Length + Non-ESP Marker ---------->
	first IKE_AUTH		first IKE_AUTH
	HDR, SK {IDi, [CERTREQ]		HDR, SK {IDi, [CERTREQ]
	CP(CFG_REQUEST), IDr,		CP(CFG_REQUEST), IDr,
	SAi2, TSi, TSr, ...}		SAi2, TSi, TSr, ...}
	<------ Length + Non-ESP Marker		<------ Length + Non-ESP Marker
	first IKE_AUTH		first IKE_AUTH
	HDR, SK {IDr, [CERT], AUTH,		HDR, SK {IDr, [CERT], AUTH,
	EAP, SAr2, TSi, TSr}		EAP, SAr2, TSi, TSr}
	skipping to change at page 29, line 47 ¶		skipping to change at page 29, line 47 ¶
	Length + Non-ESP Marker ----------->		Length + Non-ESP Marker ----------->
	INFORMATIONAL		INFORMATIONAL
	HDR, SK { N(UPDATE_SA_ADDRESSES),		HDR, SK { N(UPDATE_SA_ADDRESSES),
	N(NAT_DETECTION_SOURCE_IP),		N(NAT_DETECTION_SOURCE_IP),
	N(NAT_DETECTION_DESTINATION_IP) }		N(NAT_DETECTION_DESTINATION_IP) }
	<------- Length + Non-ESP Marker		<------- Length + Non-ESP Marker
	HDR, SK { N(NAT_DETECTION_SOURCE_IP),		HDR, SK { N(NAT_DETECTION_SOURCE_IP),
	N(NAT_DETECTION_DESTINATION_IP) }		N(NAT_DETECTION_DESTINATION_IP) }
	7) ---- New Exchange with recalculated NAT_DETECTION_* ----		7) -- New Exchange with recalculated NAT_DETECTION_*_IP ---
	Length + Non-ESP Marker ----------->		Length + Non-ESP Marker ----------->
	INFORMATIONAL		INFORMATIONAL
	HDR, SK { N(UPDATE_SA_ADDRESSES),		HDR, SK { N(UPDATE_SA_ADDRESSES),
	N(NAT_DETECTION_SOURCE_IP),		N(NAT_DETECTION_SOURCE_IP),
	N(NAT_DETECTION_DESTINATION_IP) }		N(NAT_DETECTION_DESTINATION_IP) }
	<------- Length + Non-ESP Marker		<------- Length + Non-ESP Marker
	HDR, SK { N(NAT_DETECTION_SOURCE_IP),		HDR, SK { N(NAT_DETECTION_SOURCE_IP),
	N(NAT_DETECTION_DESTINATION_IP) }		N(NAT_DETECTION_DESTINATION_IP) }
	skipping to change at page 30, line 38 ¶		skipping to change at page 30, line 38 ¶
	5. The client sends the stream prefix for TCP-encapsulated IKE		5. The client sends the stream prefix for TCP-encapsulated IKE
	traffic (Section 5).		traffic (Section 5).
	6. The client sends the UPDATE_SA_ADDRESSES notify payload on the		6. The client sends the UPDATE_SA_ADDRESSES notify payload on the
	TCP-encapsulated connection. Note that this IKE message is the		TCP-encapsulated connection. Note that this IKE message is the
	same as the one sent over UDP in step 2; it should have the same		same as the one sent over UDP in step 2; it should have the same
	message ID and contents.		message ID and contents.
	7. Once the client receives a response on the TCP-encapsulated		7. Once the client receives a response on the TCP-encapsulated
	connection, it immediately starts a new INFORMATIONAL exchange		connection, it immediately starts a new INFORMATIONAL exchange
	with an UPDATE_SA_ADDRESSES notify payload and a recalculated		with an UPDATE_SA_ADDRESSES notify payload and recalculated
	NAT_DETECTION_SOURCE_IP notify payload in order to get correct		NAT_DETECTION_*_IP notify payloads in order to get correct
	information about the presence of NATs.		information about the presence of NATs.
	8. The IKE and ESP packet flow can resume.		8. The IKE and ESP packet flow can resume.
	Acknowledgments		Acknowledgments
	Thanks to the original authors of RFC 8229, Tommy Pauly, Samy Touati,		Thanks to the original authors of RFC 8229, Tommy Pauly, Samy Touati,
	and Ravi Mantha. Since this document updates and obsoletes RFC 8229,		and Ravi Mantha. Since this document updates and obsoletes RFC 8229,
	most of its text was borrowed from the original document.		most of its text was borrowed from the original document.
End of changes. 8 change blocks.
	14 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/