< draft-ietf-ipsecme-tcp-encaps-04.txt		draft-ietf-ipsecme-tcp-encaps-05.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: June 6, 2017 Ericsson		Expires: July 27, 2017 Ericsson
	R. Mantha		R. Mantha
	Cisco Systems		Cisco Systems
	December 3, 2016		January 23, 2017
	TCP Encapsulation of IKE and IPsec Packets		TCP Encapsulation of IKE and IPsec Packets
	draft-ietf-ipsecme-tcp-encaps-04		draft-ietf-ipsecme-tcp-encaps-05
	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 June 6, 2017.		This Internet-Draft will expire on July 27, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. TCP-Encapsulated Header Formats . . . . . . . . . . . . . . . 5		3. TCP-Encapsulated Header Formats . . . . . . . . . . . . . . . 5
	3.1. TCP-Encapsulated IKE Header Format . . . . . . . . . . . 5		3.1. TCP-Encapsulated IKE Header Format . . . . . . . . . . . 5
	3.2. TCP-Encapsulated ESP Header Format . . . . . . . . . . . 6		3.2. TCP-Encapsulated ESP Header Format . . . . . . . . . . . 6
	4. TCP-Encapsulated Stream Prefix . . . . . . . . . . . . . . . 6		4. TCP-Encapsulated Stream Prefix . . . . . . . . . . . . . . . 6
	5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Recommended Fallback from UDP . . . . . . . . . . . . . . 7		5.1. Recommended Fallback from UDP . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . . . 10
	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 . . . . . . . . . . . 11
	11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 10		11. Middlebox Considerations . . . . . . . . . . . . . . . . . . 11
	12. Performance Considerations . . . . . . . . . . . . . . . . . 11		12. Performance Considerations . . . . . . . . . . . . . . . . . 11
	12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 11		12.1. TCP-in-TCP . . . . . . . . . . . . . . . . . . . . . . . 12
	12.2. Added Reliability for Unreliable Protocols . . . . . . . 11		12.2. Added Reliability for Unreliable Protocols . . . . . . . 12
	12.3. Quality of Service Markings . . . . . . . . . . . . . . 11		12.3. Quality of Service Markings . . . . . . . . . . . . . . 12
	12.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 12		12.4. Maximum Segment Size . . . . . . . . . . . . . . . . . . 12
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 12		13. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	16.1. Normative References . . . . . . . . . . . . . . . . . . 12		16.1. Normative References . . . . . . . . . . . . . . . . . . 13
	16.2. Informative References . . . . . . . . . . . . . . . . . 13		16.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 14		Appendix A. Using TCP encapsulation with TLS . . . . . . . . . . 15
	Appendix B. Example exchanges of TCP Encapsulation with TLS . . 15		Appendix B. Example exchanges of TCP Encapsulation with TLS . . 15
	B.1. Establishing an IKE session . . . . . . . . . . . . . . . 15		B.1. Establishing an IKE session . . . . . . . . . . . . . . . 15
	B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 17		B.2. Deleting an IKE session . . . . . . . . . . . . . . . . . 17
	B.3. Re-establishing an IKE session . . . . . . . . . . . . . 18		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 . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		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
	skipping to change at page 8, line 19 ¶		skipping to change at page 8, line 19 ¶
	network is likely to block UDP.		network is likely to block UDP.
	6. Connection Establishment and Teardown		6. Connection Establishment and Teardown
	When the IKE initiator uses TCP encapsulation for its negotiation, it		When the IKE initiator uses TCP encapsulation for its negotiation, it
	will initiate a TCP connection to the responder using the configured		will initiate a TCP connection to the responder using the configured
	TCP port. The first bytes sent on the stream MUST be the stream		TCP port. The first bytes sent on the stream MUST be the stream
	prefix value [Section 4]. After this prefix, encapsulated IKE		prefix value [Section 4]. After this prefix, encapsulated IKE
	messages will negotiate the IKE SA and initial Child SA [RFC7296].		messages will negotiate the IKE SA and initial Child SA [RFC7296].
	After this point, both encapsulated IKE Figure 1 and ESP Figure 2		After this point, both encapsulated IKE Figure 1 and ESP Figure 2
	messages will be sent over the TCP connection.		messages will be sent over the TCP connection. The 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 initiator.
	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 all
	SAs have been deleted, the initiator of the original connection MUST		SAs have been deleted, the initiator of the original connection
	close the TCP connection.		SHOULD close the TCP connection if it does not intend to use the
			connection for another IKE session to the responder. If the
			connection is left idle, and the responder needs to clean up
			resources, the responder 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 original		their SAs for the standard lifetime or time-out period. The original
	initiator (that is, the endpoint that initiated the TCP connection		initiator (that is, the endpoint that initiated the TCP connection
	and sent the first IKE_SA_INIT message) is responsible for re-		and sent the first IKE_SA_INIT message) is responsible for re-
	establishing the TCP connection if it is torn down for any unexpected		establishing the TCP connection if it is torn down for any unexpected
	reason. Since new TCP connections may use different ports due to NAT		reason. Since new TCP connections may use different ports due to NAT
	mappings or local port allocations changing, the responder MUST allow		mappings or local port allocations changing, the responder MUST allow
	packets for existing SAs to be received from new source ports.		packets for existing SAs to be received from new source ports.
	A peer MUST discard a partially received message due to a broken		A peer MUST discard a partially received message due to a broken
	connection.		connection.
	The streams of data sent over any TCP connection used for this		Whenever the initiator opens a new TCP connection to be used for an
	protocol MUST begin with the stream prefix value followed by a		existing IKE SA, it MUST send the stream prefix first, before any IKE
	complete message, which is either an encapsulated IKE or ESP message.		or ESP messages. This follows the same behavior as the initial TCP
			connection.
	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 (initiator stream missing the stream
			prefix, or message frames 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.
	An initiator SHOULD only open one TCP connection per IKE SA, over		An initiator SHOULD only open one TCP connection per IKE SA, over
	which it sends all of the corresponding IKE and ESP messages. This		which it sends all of the corresponding IKE and ESP messages. This
	helps ensure that any firewall or NAT mappings allocated for the TCP		helps ensure that any firewall or NAT mappings allocated for the TCP
	connection apply to all of the traffic associated with the IKE SA		connection apply to all of the traffic associated with the IKE SA
	equally.		equally.
	A responder SHOULD at any given time send packets for an IKE SA and		A 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		its Child SAs over only one TCP connection. It SHOULD choose the TCP
	connection on which it last received a valid and decryptable IKE or		connection on which it last received a valid and decryptable IKE or
	ESP message. Since a connection may be broken and a new connection		ESP message. In order to be considered valid for choosing a TCP
	re-established by the initiator without the responder being aware, a		connection, an IKE message successfully decrypt and be authenticated,
	responder SHOULD accept receiving IKE and ESP messages on a new		not be a retransmission of a previously received message, and be
	connection. It will then use that connection for all subsequent		within the expected window for IKE message IDs. Similarly, an ESP
	responses. A responder MAY close a TCP connection that it perceives		message must pass authentication checks and be decrypted, not be a
	as idle and extraneous (one previously used for IKE and ESP messages		replay of a previous message.
	that has been replaced by a new connection).
	Multiple IKE SAs SHOULD NOT share a single TCP connection.		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 both old and new
			connections until the old connection is closed by the initiator. 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 MUST 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.
	If a NAT is detected due to the SHA-1 digests not matching the		If a NAT is detected due to the SHA-1 digests not matching the
	expected values, no change should be made for encapsulation of		expected values, no change should be made for encapsulation of
	subsequent IKE or ESP packets, since TCP encapsulation inherently		subsequent IKE or ESP packets, since TCP encapsulation inherently
	supports NAT traversal. Implementations MAY use the information that		supports NAT traversal. Implementations MAY use the information that
	a NAT is present to influence keep-alive timer values.		a NAT is present to influence keep-alive timer values.
			If a NAT is detected, implementations need to handle transport mode
			TCP and UDP packet checksum fixup as defined for UDP encapsulation
			[RFC3948].
	8. Using MOBIKE with TCP encapsulation		8. Using MOBIKE with TCP encapsulation
	When an IKE session is transitioned between networks using MOBIKE		When an IKE session that has negotiated MOBIKE [RFC4555] is
	[RFC4555], the initiator of the transition may switch between using		transitioning between networks, the initiator of the transition may
	TCP encapsulation, UDP encapsulation, or no encapsulation.		switch between using TCP encapsulation, UDP encapsulation, or no
	Implementations that implement both MOBIKE and TCP encapsulation MUST		encapsulation. Implementations that implement both MOBIKE and TCP
	support dynamically enabling and disabling TCP encapsulation as		encapsulation MUST support dynamically enabling and disabling TCP
	interfaces change.		encapsulation as interfaces change.
	When a MOBIKE-enabled initiator changes networks, the		When a MOBIKE-enabled initiator changes networks, the
	UPDATE_SA_ADDRESSES notification SHOULD be sent out first over UDP		UPDATE_SA_ADDRESSES notification SHOULD be sent out first over UDP
	before attempting over TCP. If there is a response to the		before attempting over TCP. If there is a response to the
	UPDATE_SA_ADDRESSES notification sent over UDP, then the ESP packets		UPDATE_SA_ADDRESSES notification sent over UDP, then the ESP packets
	should be sent directly over IP or over UDP port 4500 (depending on		should be sent directly over IP or over UDP port 4500 (depending on
	if a NAT was detected), regardless of if a connection on a previous		if a NAT was detected), regardless of if a connection on a previous
	network was using TCP encapsulation. Similarly, if the responder		network was using TCP encapsulation. Similarly, if the responder
	only responds to the UPDATE_SA_ADDRESSES notification over TCP, then		only responds to the UPDATE_SA_ADDRESSES notification over TCP, then
	the ESP packets should be sent over the TCP connection, regardless of		the ESP packets should be sent over the TCP connection, regardless of
	if a connection on a previous network did not use TCP encapsulation.		if a connection on a previous network did not use TCP encapsulation.
	9. Using IKE Message Fragmentation with TCP encapsulation		9. Using IKE Message Fragmentation with TCP encapsulation
	IKE Message Fragmentation [RFC7383] is not required when using TCP		IKE Message Fragmentation [RFC7383] is not required when using TCP
	encapsulation, since a TCP stream already handles the fragmentation		encapsulation, since a TCP stream already handles the fragmentation
	of its contents across packets. Since fragmentation is redundant in		of its contents across packets. Since fragmentation is redundant in
	this case, implementations might choose to not negotiate IKE		this case, implementations might choose to not negotiate IKE
	fragmentation. Even if fragmentation is negotiated, an		fragmentation. Even if fragmentation is negotiated, an
	implementation MAY choose to not fragment when going over a TCP		implementation SHOULD NOT send fragments when going over a TCP
	connection.		connection, although it MUST support receiving fragements.
	If an implementation supports both MOBIKE and IKE fragmentation, it		If an implementation supports both MOBIKE and IKE fragmentation, it
	SHOULD negotiate IKE fragmentation over a TCP encapsulated session in		SHOULD negotiate IKE fragmentation over a TCP encapsulated session in
	case the session switches to UDP encapsulation on another network.		case the session switches to UDP encapsulation on another network.
	10. Considerations for Keep-alives and DPD		10. Considerations for Keep-alives and DPD
	Encapsulating IKE and IPsec inside of a TCP connection can impact the		Encapsulating IKE and IPsec inside of a TCP connection can impact the
	strategy that implementations use to detect peer liveness and to		strategy that implementations use to detect peer liveness and to
	maintain middlebox port mappings. Peer liveness should be checked		maintain middlebox port mappings. Peer liveness should be checked
	skipping to change at page 12, line 30 ¶		skipping to change at page 13, line 7 ¶
	protocol. The prefix was chosen to not overlap with the start of any		protocol. The prefix was chosen to not overlap with the start of any
	known valid protocol over TCP, but implementations should make sure		known valid protocol over TCP, but implementations should make sure
	to validate this assumption in order to avoid unexpected processing		to validate this assumption in order to avoid unexpected processing
	of TCP connections.		of TCP connections.
	Attackers may be able to disrupt the TCP connection by sending		Attackers may be able to disrupt the TCP connection by sending
	spurious RST packets. Due to this, implementations SHOULD make sure		spurious RST packets. Due to this, implementations SHOULD make sure
	that IKE session state persists even if the underlying TCP connection		that IKE session state persists even if the underlying TCP connection
	is torn down.		is torn down.
			If MOBIKE is being used, all of the security considerations outlined
			for MOBIKE apply [[RFC4555]].
			Similarly to MOBIKE, TCP encapsulation requires a responder to handle
			changing of source address and port due to network or connection
			disruption. The successful delivery of valid IKE or ESP messages
			over a new TCP connection is used by the responder to determine where
			to send subsequent responses. If an attacker is able to send packets
			on a new TCP connection that pass the validation checks of the
			responder, it can influence which path future packets take. For this
			reason, the validation of messages on the responder must include
			decryption, authentication, and replay checks.
	14. IANA Considerations		14. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	TCP port 4500 is already allocated to IPsec. This port MAY be used		TCP port 4500 is already allocated to IPsec. This port MAY be used
	for the protocol described in this document, but implementations MAY		for the protocol described in this document, but implementations MAY
	prefer to use other ports based on local policy.		prefer to use other ports based on local policy.
	15. Acknowledgments		15. Acknowledgments
	The authors would like to acknowledge the input and advice of Stuart		The authors would like to acknowledge the input and advice of Stuart
	Cheshire, Delziel Fernandes, Yoav Nir, Christoph Paasch, Yaron		Cheshire, Delziel Fernandes, Yoav Nir, Christoph Paasch, Yaron
	Sheffer, David Schinazi, Graham Bartlett, Byju Pularikkal, March Wu		Sheffer, David Schinazi, Graham Bartlett, Byju Pularikkal, March Wu,
	and Kingwel Xie. Special thanks to Eric Kinnear for his		Kingwel Xie, Valery Smyslov, Jun Hu, and Tero Kivinen. Special
	implementation work.		thanks to Eric Kinnear for his implementation work.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 16, line 28 ¶		skipping to change at page 16, line 21 ¶
	ClientKeyExchange		ClientKeyExchange
	CertificateVerify*		CertificateVerify*
	[ChangeCipherSpec]		[ChangeCipherSpec]
	Finished ---------->		Finished ---------->
	[ChangeCipherSpec]		[ChangeCipherSpec]
	<---------- Finished		<---------- Finished
	3) ---------------------- Stream Prefix --------------------		3) ---------------------- Stream Prefix --------------------
	"IKETCP" ---------->		"IKETCP" ---------->
	4) ----------------------- IKE Session ---------------------		4) ----------------------- IKE Session ---------------------
	IKE_SA_INIT ---------->		Length + Non-ESP Marker ---------->
			IKE_SA_INIT
	HDR, SAi1, KEi, Ni,		HDR, SAi1, KEi, Ni,
	[N(NAT_DETECTION_*_IP)]		[N(NAT_DETECTION_*_IP)]
	<---------- IKE_SA_INIT		<------ Length + Non-ESP Marker
			IKE_SA_INIT
	HDR, SAr1, KEr, Nr,		HDR, SAr1, KEr, Nr,
	[N(NAT_DETECTION_*_IP)]		[N(NAT_DETECTION_*_IP)]
	first IKE_AUTH ---------->		Length + Non-ESP Marker ---------->
			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, ...}
	<---------- first IKE_AUTH		<------ Length + Non-ESP Marker
			first IKE_AUTH
	HDR, SK {IDr, [CERT], AUTH,		HDR, SK {IDr, [CERT], AUTH,
	EAP, SAr2, TSi, TSr}		EAP, SAr2, TSi, TSr}
	EAP ---------->		Length + Non-ESP Marker ---------->
			IKE_AUTH + EAP
	repeat 1..N times		repeat 1..N times
	<---------- EAP		<------ Length + Non-ESP Marker
	final IKE_AUTH ---------->		IKE_AUTH + EAP
			Length + Non-ESP Marker ---------->
			final IKE_AUTH
	HDR, SK {AUTH}		HDR, SK {AUTH}
	<---------- final IKE_AUTH		<------ Length + Non-ESP Marker
			final IKE_AUTH
	HDR, SK {AUTH, CP(CFG_REPLY),		HDR, SK {AUTH, CP(CFG_REPLY),
	SA, TSi, TSr, ...}		SA, TSi, TSr, ...}
	----------------- IKE Tunnel Established ----------------		----------------- IKE Tunnel Established ----------------
			Length + ESP frame ---------->
	Figure 4		Figure 4
	1. Client establishes a TCP connection with the server on port 443		1. Client establishes a TCP connection with the server on port 443
	or 4500.		or 4500.
	2. Client initiates TLS handshake. During TLS handshake, the		2. Client initiates TLS handshake. During TLS handshake, the
	server SHOULD NOT request the client's' certificate, since		server SHOULD NOT request the client's' certificate, since
	authentication is handled as part of IKE negotiation.		authentication is handled as part of IKE negotiation.
	3. Client send the Stream Prefix for TCP encapsulated IKE		3. Client send the Stream Prefix for TCP encapsulated IKE
	skipping to change at page 17, line 24 ¶		skipping to change at page 17, line 25 ¶
	4. Client and server establish an IKE connection. This example		4. Client and server establish an IKE connection. This example
	shows EAP-based authentication, although any authentication		shows EAP-based authentication, although any authentication
	type may be used.		type may be used.
	B.2. Deleting an IKE session		B.2. Deleting an IKE session
	Client Server		Client Server
	---------- ----------		---------- ----------
	1) ----------------------- IKE Session ---------------------		1) ----------------------- IKE Session ---------------------
	INFORMATIONAL ---------->		Length + Non-ESP Marker ---------->
			INFORMATIONAL
	HDR, SK {[N,] [D,]		HDR, SK {[N,] [D,]
	[CP,] ...}		[CP,] ...}
	<---------- INFORMATIONAL		<------ Length + Non-ESP Marker
			INFORMATIONAL
	HDR, SK {[N,] [D,]		HDR, SK {[N,] [D,]
	[CP], ...}		[CP], ...}
	2) --------------------- TLS Session ---------------------		2) --------------------- TLS Session ---------------------
	close_notify ---------->		close_notify ---------->
	<---------- close_notify		<---------- close_notify
	3) -------------------- TCP Connection -------------------		3) -------------------- TCP Connection -------------------
	TcpFin ---------->		TcpFin ---------->
	<---------- Ack		<---------- Ack
	<---------- TcpFin		<---------- TcpFin
	skipping to change at page 18, line 24 ¶		skipping to change at page 18, line 29 ¶
	2) --------------------- TLS Session ---------------------		2) --------------------- TLS Session ---------------------
	ClientHello ---------->		ClientHello ---------->
	<---------- ServerHello		<---------- ServerHello
	[ChangeCipherSpec]		[ChangeCipherSpec]
	Finished		Finished
	[ChangeCipherSpec] ---------->		[ChangeCipherSpec] ---------->
	Finished		Finished
	3) ---------------------- Stream Prefix --------------------		3) ---------------------- Stream Prefix --------------------
	"IKETCP" ---------->		"IKETCP" ---------->
	4) <---------------------> IKE/ESP flow <------------------>		4) <---------------------> IKE/ESP flow <------------------>
			Length + ESP frame ---------->
	Figure 6		Figure 6
	1. If a previous TCP connection was broken (for example, due to a		1. If a previous TCP connection was broken (for example, due to a
	RST), the client is responsible for re-initiating the TCP		RST), the client is responsible for re-initiating the TCP
	connection. The initiator's address and port (IP_I and Port_I)		connection. The initiator's address and port (IP_I and Port_I)
	may be different from the previous connection's address and		may be different from the previous connection's address and
	port.		port.
	2. In ClientHello TLS message, the client SHOULD send the Session		2. In ClientHello TLS message, the client SHOULD send the Session
	skipping to change at page 19, line 5 ¶		skipping to change at page 19, line 12 ¶
	4. The IKE and ESP packet flow can resume. If MOBIKE is being		4. The IKE and ESP packet flow can resume. If MOBIKE is being
	used, the initiator SHOULD send UPDATE_SA_ADDRESSES.		used, the initiator SHOULD send UPDATE_SA_ADDRESSES.
	B.4. Using MOBIKE between UDP and TCP Encapsulation		B.4. Using MOBIKE between UDP and TCP Encapsulation
	Client Server		Client Server
	---------- ----------		---------- ----------
	(IP_I1:UDP500 -> IP_R:UDP500)		(IP_I1:UDP500 -> IP_R:UDP500)
	1) ----------------- IKE_SA_INIT Exchange -----------------		1) ----------------- IKE_SA_INIT Exchange -----------------
	(IP_I1:UDP4500 -> IP_R:UDP4500)		(IP_I1:UDP4500 -> IP_R:UDP4500)
	Intial IKE_AUTH ----------->		Non-ESP Marker ----------->
			Intial IKE_AUTH
	HDR, SK { IDi, CERT, AUTH,		HDR, SK { IDi, CERT, AUTH,
	CP(CFG_REQUEST),		CP(CFG_REQUEST),
	SAi2, TSi, TSr,		SAi2, TSi, TSr,
	N(MOBIKE_SUPPORTED) }		N(MOBIKE_SUPPORTED) }
	<----------- Initial IKE_AUTH		<----------- Non-ESP Marker
			Initial IKE_AUTH
	HDR, SK { IDr, CERT, AUTH,		HDR, SK { IDr, CERT, AUTH,
	EAP, SAr2, TSi, TSr,		EAP, SAr2, TSi, TSr,
	N(MOBIKE_SUPPORTED) }		N(MOBIKE_SUPPORTED) }
	<---------------- IKE tunnel establishment ------------->		<---------------- IKE tunnel establishment ------------->
	2) ------------ MOBIKE Attempt on new network --------------		2) ------------ MOBIKE Attempt on new network --------------
	(IP_I2:UDP4500 -> IP_R:UDP4500)		(IP_I2:UDP4500 -> IP_R:UDP4500)
	INFORMATIONAL ----------->		Non-ESP Marker ----------->
			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) }
	3) -------------------- TCP Connection -------------------		3) -------------------- TCP Connection -------------------
	(IP_I2:PORT_I -> IP_R:TCP443 or TCP4500)		(IP_I2:PORT_I -> IP_R:TCP443 or TCP4500)
	TcpSyn ----------->		TcpSyn ----------->
	<----------- TcpSyn,Ack		<----------- TcpSyn,Ack
	TcpAck ----------->		TcpAck ----------->
	skipping to change at page 19, line 41 ¶		skipping to change at page 20, line 4 ¶
	ServerHello		ServerHello
	Certificate*		Certificate*
	ServerKeyExchange*		ServerKeyExchange*
	<----------- ServerHelloDone		<----------- ServerHelloDone
	ClientKeyExchange		ClientKeyExchange
	CertificateVerify*		CertificateVerify*
	[ChangeCipherSpec]		[ChangeCipherSpec]
	Finished ----------->		Finished ----------->
	[ChangeCipherSpec]		[ChangeCipherSpec]
	<----------- Finished		<----------- Finished
	5) ---------------------- Stream Prefix --------------------		5) ---------------------- Stream Prefix --------------------
	"IKETCP" ---------->		"IKETCP" ---------->
	6) ----------------------- IKE Session ---------------------		6) ----------------------- IKE Session ---------------------
	INFORMATIONAL ----------->		Length + Non-ESP Marker ----------->
			INFORMATIONAL (Same as step 2)
	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) }
	<----------- INFORMATIONAL		<------- 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) <----------------- IKE/ESP data flow ------------------->		7) <----------------- IKE/ESP data flow ------------------->
	Figure 7		Figure 7
	1. During the IKE_SA_INIT exchange, the client and server exchange		1. During the IKE_SA_INIT exchange, the client and server exchange
	MOBIKE_SUPPORTED notify payloads to indicate support for		MOBIKE_SUPPORTED notify payloads to indicate support for
	MOBIKE.		MOBIKE.
	skipping to change at page 20, line 30 ¶		skipping to change at page 20, line 41 ¶
	3. The client brings up a TCP connection to the server in order to		3. The client brings up a TCP connection to the server in order to
	use TCP encapsulation.		use TCP encapsulation.
	4. The client initiates and TLS handshake with the server.		4. The client initiates and TLS handshake with the server.
	5. The client sends the Stream Prefix for TCP encapsulated IKE		5. The client sends the Stream Prefix for TCP encapsulated IKE
	traffic [Section 4].		traffic [Section 4].
	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.		TCP encapsulated connection. Note that this IKE message is the
			same as the one sent over UDP in step 2, and should have the
			same message ID and contents.
	7. The IKE and ESP packet flow can resume.		7. The IKE and ESP packet flow can resume.
	Authors' Addresses		Authors' Addresses
	Tommy Pauly		Tommy Pauly
	Apple Inc.		Apple Inc.
	1 Infinite Loop		1 Infinite Loop
	Cupertino, California 95014		Cupertino, California 95014
	US		US
	Email: tpauly@apple.com		Email: tpauly@apple.com
	Samy Touati		Samy Touati
	Ericsson		Ericsson
End of changes. 41 change blocks.
	65 lines changed or deleted		118 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/