draft-ietf-ipsecme-tcp-encaps-03.txt		draft-ietf-ipsecme-tcp-encaps-04.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: May 4, 2017 Ericsson		Expires: June 6, 2017 Ericsson
	R. Mantha		R. Mantha
	Cisco Systems		Cisco Systems
	October 31, 2016		December 3, 2016
	TCP Encapsulation of IKE and IPsec Packets		TCP Encapsulation of IKE and IPsec Packets
	draft-ietf-ipsecme-tcp-encaps-03		draft-ietf-ipsecme-tcp-encaps-04
	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 tunnel		encapsulation, involves sending both IKE packets for tunnel
	establishment as well as tunneled packets using ESP over a TCP		establishment as well as tunneled packets using ESP over a TCP
	connection. This method is intended to be used as a fallback option		connection. This method is intended to be used as a fallback option
	when IKE cannot be negotiated over UDP.		when IKE cannot be negotiated over UDP.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 May 4, 2017.		This Internet-Draft will expire on June 6, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	6. Connection Establishment and Teardown . . . . . . . . . . . . 8		6. Connection Establishment and Teardown . . . . . . . . . . . . 8
	7. Interaction with NAT Detection Payloads . . . . . . . . . . . 9		7. Interaction with NAT Detection Payloads . . . . . . . . . . . 9
	8. Using MOBIKE with TCP encapsulation . . . . . . . . . . . . . 9		8. Using MOBIKE with TCP encapsulation . . . . . . . . . . . . . 9
	9. Using IKE Message Fragmentation with TCP encapsulation . . . 10		9. Using IKE Message Fragmentation with TCP encapsulation . . . 10
	10. Considerations for Keep-alives and DPD . . . . . . . . . . . 10		10. Considerations for Keep-alives and DPD . . . . . . . . . . . 10
	11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 10		11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 10
	12. Performance Considerations . . . . . . . . . . . . . . . . . 11		12. Performance Considerations . . . . . . . . . . . . . . . . . 11
	12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 11		12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 11
	12.2. Added Reliability for Unreliable Protocols . . . . . . . 11		12.2. Added Reliability for Unreliable Protocols . . . . . . . 11
	12.3. Quality of Service Markings . . . . . . . . . . . . . . 11		12.3. Quality of Service Markings . . . . . . . . . . . . . . 11
	12.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 11		12.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 12
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 12		13. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	16.1. Normative References . . . . . . . . . . . . . . . . . . 12		16.1. Normative References . . . . . . . . . . . . . . . . . . 12
	16.2. Informative References . . . . . . . . . . . . . . . . . 13		16.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 14		Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 14
	Appendix B. Example exchanges of TCP Encapsulation with TLS . . 14		Appendix B. Example exchanges of TCP Encapsulation with TLS . . 15
	B.1. Establishing an IKE session . . . . . . . . . . . . . . . 14		B.1. Establishing an IKE session . . . . . . . . . . . . . . . 15
	B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 16		B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 17
	B.3. Re-establishing an IKE session . . . . . . . . . . . . . 17		B.3. Re-establishing an IKE session . . . . . . . . . . . . . 18
	B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 18		B.4. Using MOBIKE between UDP and TCP Encapsulation . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	IKEv2 [RFC7296] is a protocol for establishing IPsec tunnels, using		IKEv2 [RFC7296] is a protocol for establishing IPsec tunnels, using
	IKE messages over UDP for control traffic, and using Encapsulating		IKE messages over UDP for control traffic, and using Encapsulating
	Security Payload (ESP) messages for tunneled data traffic. Many		Security Payload (ESP) messages for tunneled data traffic. Many
	network middleboxes that filter traffic on public hotspots block all		network middleboxes that filter traffic on public hotspots block all
	UDP traffic, including IKE and IPsec, but allow TCP connections		UDP traffic, including IKE and IPsec, but allow TCP connections
	through since they appear to be web traffic. Devices on these		through since they appear to be web traffic. Devices on these
	networks that need to use IPsec (to access private enterprise		networks that need to use IPsec (to access private enterprise
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	complete message, which is either an encapsulated IKE or ESP message.		complete message, which is either an encapsulated IKE or ESP message.
	If the connection is being used to resume a previous IKE session, the		If the connection is being used to resume a previous IKE session, the
	responder can recognize the session using either the IKE SPI from an		responder can recognize the session using either the IKE SPI from an
	encapsulated IKE message or the ESP SPI from an encapsulated ESP		encapsulated IKE message or the ESP SPI from an encapsulated ESP
	message. If the session had been fully established previously, it is		message. If the session had been fully established previously, it is
	suggested that the initiator send an UPDATE_SA_ADDRESSES message if		suggested that the initiator send an UPDATE_SA_ADDRESSES message if
	MOBIKE is supported, or an INFORMATIONAL message (a keepalive)		MOBIKE is supported, or an INFORMATIONAL message (a keepalive)
	otherwise. If either initiator or responder receives a stream that		otherwise. If either initiator or responder receives a stream that
	cannot be parsed correctly, it MUST close the TCP connection.		cannot be parsed correctly, it MUST close the TCP connection.
	Multiple TCP connections between the initiator and the responder are		An initiator SHOULD only open one TCP connection per IKE SA, over
	allowed, but their use must take into account the initiator		which it sends all of the corresponding IKE and ESP messages. This
	capabilities and the deployment model such as to connect to multiple		helps ensure that any firewall or NAT mappings allocated for the TCP
	gateways handling different ESP SAs when deployed in a high		connection apply to all of the traffic associated with the IKE SA
	availability model. If multiple TCP connections are used,		equally.
	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-encapsulated IKE and ESP packets is the		A responder SHOULD at any given time send packets for an IKE SA and
	same when using either a single TCP connection or multiple TCP		its Child SAs over only one TCP connection. It should choose the TCP
	connections.		connection on which it last received a valid and decryptable IKE or
			ESP message. Since a connection may be broken and a new connection
			re-established by the initiator without the responder being aware, a
			responder SHOULD accept receiving IKE and ESP messages on a new
			connection. It will then use that connection for all subsequent
			responses. A responder MAY close a TCP connection that it perceives
			as idle and extraneous (one previously used for IKE and ESP messages
			that has been replaced by a new connection).
			Multiple IKE SAs SHOULD NOT share a single TCP connection.
	7. Interaction with NAT Detection Payloads		7. Interaction with NAT Detection Payloads
	When negotiating over UDP port 500, IKE_SA_INIT packets include		When negotiating over UDP port 500, IKE_SA_INIT packets include
	NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads to		NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads to
	determine if UDP encapsulation of IPsec packets should be used.		determine if UDP encapsulation of IPsec packets should be used.
	These payloads contain SHA-1 digests of the SPIs, IP addresses, and		These payloads contain SHA-1 digests of the SPIs, IP addresses, and
	ports. IKE_SA_INIT packets sent on a TCP connection SHOULD include		ports. IKE_SA_INIT packets sent on a TCP connection SHOULD include
	these payloads, and SHOULD use the applicable TCP ports when creating		these payloads, and SHOULD use the applicable TCP ports when creating
	and checking the SHA-1 digests.		and checking the SHA-1 digests.
	skipping to change at page 17, line 5 ¶		skipping to change at page 17, line 51 ¶
	Figure 5		Figure 5
	1. Client and server exchange INFORMATIONAL messages to notify IKE		1. Client and server exchange INFORMATIONAL messages to notify IKE
	SA deletion.		SA deletion.
	2. Client and server negotiate TLS session deletion using TLS		2. Client and server negotiate TLS session deletion using TLS
	CLOSE_NOTIFY.		CLOSE_NOTIFY.
	3. The TCP connection is torn down.		3. The TCP connection is torn down.
	Unless the TCP connection and/or TLS session are being used for		The deletion of the IKE SA should lead to the disposal of the
	multiple IKE SAs, the deletion of the IKE SA should lead to the		underlying TLS and TCP state.
	disposal of the underlying TLS and TCP state.
	B.3. Re-establishing an IKE session		B.3. Re-establishing an IKE session
	Client Server		Client Server
	---------- ----------		---------- ----------
	1) -------------------- TCP Connection -------------------		1) -------------------- TCP Connection -------------------
	(IP_I:Port_I -> IP_R:TCP443 or TCP4500)		(IP_I:Port_I -> IP_R:TCP443 or TCP4500)
	TcpSyn ---------->		TcpSyn ---------->
	<---------- TcpSyn,Ack		<---------- TcpSyn,Ack
	TcpAck ---------->		TcpAck ---------->
End of changes. 10 change blocks.
	25 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/