draft-ietf-mptcp-rfc6824bis-17.txt		draft-ietf-mptcp-rfc6824bis-18.txt
	Internet Engineering Task Force A. Ford		Internet Engineering Task Force A. Ford
	Internet-Draft Pexip		Internet-Draft Pexip
	Obsoletes: 6824 (if approved) C. Raiciu		Obsoletes: 6824 (if approved) C. Raiciu
	Intended status: Standards Track U. Politechnica of Bucharest		Intended status: Standards Track U. Politechnica of Bucharest
	Expires: December 1, 2019 M. Handley		Expires: December 10, 2019 M. Handley
	U. College London		U. College London
	O. Bonaventure		O. Bonaventure
	U. catholique de Louvain		U. catholique de Louvain
	C. Paasch		C. Paasch
	Apple, Inc.		Apple, Inc.
	May 30, 2019		June 8, 2019
	TCP Extensions for Multipath Operation with Multiple Addresses		TCP Extensions for Multipath Operation with Multiple Addresses
	draft-ietf-mptcp-rfc6824bis-17		draft-ietf-mptcp-rfc6824bis-18
	Abstract		Abstract
	TCP/IP communication is currently restricted to a single path per		TCP/IP communication is currently restricted to a single path per
	connection, yet multiple paths often exist between peers. The		connection, yet multiple paths often exist between peers. The
	simultaneous use of these multiple paths for a TCP/IP session would		simultaneous use of these multiple paths for a TCP/IP session would
	improve resource usage within the network and, thus, improve user		improve resource usage within the network and, thus, improve user
	experience through higher throughput and improved resilience to		experience through higher throughput and improved resilience to
	network failure.		network failure.
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 December 1, 2019.		This Internet-Draft will expire on December 10, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 48 ¶		skipping to change at page 2, line 48 ¶
	2.5. Requesting a Change in a Path's Priority . . . . . . . . 13		2.5. Requesting a Change in a Path's Priority . . . . . . . . 13
	2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 13		2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 13
	2.7. Notable Features . . . . . . . . . . . . . . . . . . . . 14		2.7. Notable Features . . . . . . . . . . . . . . . . . . . . 14
	3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . 15		3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . 15
	3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 16		3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 16
	3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . 23		3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . 23
	3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 28		3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 28
	3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 30		3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 30
	3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . 33		3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . 33
	3.3.3. Closing a Connection . . . . . . . . . . . . . . . . 34		3.3.3. Closing a Connection . . . . . . . . . . . . . . . . 34
	3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 35		3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 36
	3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 37		3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 37
	3.3.6. Reliability and Retransmissions . . . . . . . . . . . 37		3.3.6. Reliability and Retransmissions . . . . . . . . . . . 38
	3.3.7. Congestion Control Considerations . . . . . . . . . . 39		3.3.7. Congestion Control Considerations . . . . . . . . . . 39
	3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 39		3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 39
	3.4. Address Knowledge Exchange (Path Management) . . . . . . 40		3.4. Address Knowledge Exchange (Path Management) . . . . . . 40
	3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 42		3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 42
	3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . 45		3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . 45
	3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 46		3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 46
	3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 48		3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 48
	3.7. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 49		3.7. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 49
	3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . 53		3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . 53
	3.9. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 53		3.9. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 53
	skipping to change at page 25, line 17 ¶		skipping to change at page 25, line 17 ¶
	protection against blind state exhaustion attacks; therefore, there		protection against blind state exhaustion attacks; therefore, there
	is no need to provide mechanisms to allow a responder to operate		is no need to provide mechanisms to allow a responder to operate
	statelessly at the MP_JOIN stage.		statelessly at the MP_JOIN stage.
	An HMAC is sent by both hosts -- by the initiator (Host A) in the		An HMAC is sent by both hosts -- by the initiator (Host A) in the
	third packet (the ACK) and by the responder (Host B) in the second		third packet (the ACK) and by the responder (Host B) in the second
	packet (the SYN/ACK). Doing the HMAC exchange at this stage allows		packet (the SYN/ACK). Doing the HMAC exchange at this stage allows
	both hosts to have first exchanged random data (in the first two SYN		both hosts to have first exchanged random data (in the first two SYN
	packets) that is used as the "message". This specification defines		packets) that is used as the "message". This specification defines
	that HMAC as defined in [RFC2104] is used, along with the SHA-256		that HMAC as defined in [RFC2104] is used, along with the SHA-256
	hash algorithm [RFC6234], thus generating a 160-bit / 20-octet HMAC.		hash algorithm [RFC6234], and that the output is truncated to the
	Due to option space limitations, the HMAC included in the SYN/ACK is		leftmost 160 bits (20 octets). Due to option space limitations, the
	truncated to the leftmost 64 bits, but this is acceptable since		HMAC included in the SYN/ACK is truncated to the leftmost 64 bits,
	random numbers are used; thus, an attacker only has one chance to		but this is acceptable since random numbers are used; thus, an
	guess the HMAC correctly (if the HMAC is incorrect, the TCP		attacker only has one chance to correctly guess the HMAC that matches
	connection is closed, so a new MP_JOIN negotiation with a new random		the random number previously sent by the peer (if the HMAC is
	number is required).		incorrect, the TCP connection is closed, so a new MP_JOIN negotiation
			with a new random number is required).
	The initiator's authentication information is sent in its first ACK		The initiator's authentication information is sent in its first ACK
	(the third packet of the handshake), as shown in Figure 7. This data		(the third packet of the handshake), as shown in Figure 7. This data
	needs to be sent reliably, since it is the only time this HMAC is		needs to be sent reliably, since it is the only time this HMAC is
	sent; therefore, receipt of this packet MUST trigger a regular TCP		sent; therefore, receipt of this packet MUST trigger a regular TCP
	ACK in response, and the packet MUST be retransmitted if this ACK is		ACK in response, and the packet MUST be retransmitted if this ACK is
	not received. In other words, sending the ACK/MP_JOIN packet places		not received. In other words, sending the ACK/MP_JOIN packet places
	the subflow in the PRE_ESTABLISHED state, and it moves to the		the subflow in the PRE_ESTABLISHED state, and it moves to the
	ESTABLISHED state only on receipt of an ACK from the receiver. It is		ESTABLISHED state only on receipt of an ACK from the receiver. It is
	not permitted to send data while in the PRE_ESTABLISHED state. The		not permitted to send data while in the PRE_ESTABLISHED state. The
	skipping to change at page 26, line 26 ¶		skipping to change at page 26, line 26 ¶
	Figure 6: Join Connection (MP_JOIN) Option (for Responding SYN/ACK)		Figure 6: Join Connection (MP_JOIN) Option (for Responding SYN/ACK)
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+---------------+---------------+-------+-----------------------+		+---------------+---------------+-------+-----------------------+
	| Kind | Length = 24 |Subtype| (reserved) |		| Kind | Length = 24 |Subtype| (reserved) |
	+---------------+---------------+-------+-----------------------+		+---------------+---------------+-------+-----------------------+
	| |		| |
	| |		| |
	| Sender's HMAC (160 bits) |		| Sender's Truncated HMAC (160 bits) |
	| |		| |
	| |		| |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 7: Join Connection (MP_JOIN) Option (for Third ACK)		Figure 7: Join Connection (MP_JOIN) Option (for Third ACK)
	These various MPTCP options fit together to enable authenticated		These various MPTCP options fit together to enable authenticated
	subflow setup as illustrated in Figure 8.		subflow setup as illustrated in Figure 8.
	Host A Host B		Host A Host B
	skipping to change at page 27, line 48 ¶		skipping to change at page 27, line 48 ¶
	If the token is accepted at Host B, but the HMAC returned to Host A		If the token is accepted at Host B, but the HMAC returned to Host A
	does not match the one expected, Host A MUST close the subflow with a		does not match the one expected, Host A MUST close the subflow with a
	TCP RST. In this, and all following cases of sending a RST in this		TCP RST. In this, and all following cases of sending a RST in this
	section, the sender SHOULD send a MP_TCPRST option (Section 3.6) on		section, the sender SHOULD send a MP_TCPRST option (Section 3.6) on
	this RST packet with the reason code for a "MPTCP specific error".		this RST packet with the reason code for a "MPTCP specific error".
	If Host B does not receive the expected HMAC, or the MP_JOIN option		If Host B does not receive the expected HMAC, or the MP_JOIN option
	is missing from the ACK, it MUST close the subflow with a TCP RST.		is missing from the ACK, it MUST close the subflow with a TCP RST.
	If the HMACs are verified as correct, then both hosts have		If the HMACs are verified as correct, then both hosts have verified
	authenticated each other as being the same peers as existed at the		each other as being the same peers as existed at the start of the
	start of the connection, and they have agreed of which connection		connection, and they have agreed of which connection this subflow
	this subflow will become a part.		will become a part.
	If the SYN/ACK as received at Host A does not have an MP_JOIN option,		If the SYN/ACK as received at Host A does not have an MP_JOIN option,
	Host A MUST close the subflow with a TCP RST.		Host A MUST close the subflow with a TCP RST.
	This covers all cases of the loss of an MP_JOIN. In more detail, if		This covers all cases of the loss of an MP_JOIN. In more detail, if
	MP_JOIN is stripped from the SYN on the path from A to B, and Host B		MP_JOIN is stripped from the SYN on the path from A to B, and Host B
	does not have a listener on the relevant port, it will respond with a		does not have a listener on the relevant port, it will respond with a
	RST in the normal way. If in response to a SYN with an MP_JOIN		RST in the normal way. If in response to a SYN with an MP_JOIN
	option, a SYN/ACK is received without the MP_JOIN option (either		option, a SYN/ACK is received without the MP_JOIN option (either
	since it was stripped on the return path, or it was stripped on the		since it was stripped on the return path, or it was stripped on the
	skipping to change at page 29, line 39 ¶		skipping to change at page 29, line 39 ¶
	o m = Data sequence number is 8 octets (if not set, DSN is 4 octets)		o m = Data sequence number is 8 octets (if not set, DSN is 4 octets)
	The flags 'a' and 'm' only have meaning if the corresponding 'A' or		The flags 'a' and 'm' only have meaning if the corresponding 'A' or
	'M' flags are set; otherwise, they will be ignored. The maximum		'M' flags are set; otherwise, they will be ignored. The maximum
	length of this option, with all flags set, is 28 octets.		length of this option, with all flags set, is 28 octets.
	The 'F' flag indicates "Data FIN". If present, this means that this		The 'F' flag indicates "Data FIN". If present, this means that this
	mapping covers the final data from the sender. This is the		mapping covers the final data from the sender. This is the
	connection-level equivalent to the FIN flag in single-path TCP. A		connection-level equivalent to the FIN flag in single-path TCP. A
	connection is not closed unless there has been a Data FIN exchange,		connection is not closed unless there has been a Data FIN exchange, a
	or an implementation-specific, connection-level timeout. The purpose		MP_FASTCLOSE (Section 3.5) message, or an implementation-specific,
	of the Data FIN and the interactions between this flag, the subflow-		connection-level send timeout. The purpose of the Data FIN and the
	level FIN flag, and the data sequence mapping are described in		interactions between this flag, the subflow-level FIN flag, and the
	Section 3.3.3. The remaining reserved bits MUST be set to zero by an		data sequence mapping are described in Section 3.3.3. The remaining
	implementation of this specification.		reserved bits MUST be set to zero by an implementation of this
			specification.
	Note that the checksum is only present in this option if the use of		Note that the checksum is only present in this option if the use of
	MPTCP checksumming has been negotiated at the MP_CAPABLE handshake		MPTCP checksumming has been negotiated at the MP_CAPABLE handshake
	(see Section 3.1). The presence of the checksum can be inferred from		(see Section 3.1). The presence of the checksum can be inferred from
	the length of the option. If a checksum is present, but its use had		the length of the option. If a checksum is present, but its use had
	not been negotiated in the MP_CAPABLE handshake, the checksum field		not been negotiated in the MP_CAPABLE handshake, the receiver MUST
	MUST be ignored. If a checksum is not present when its use has been		close the subflow with a RST as it not behaving as negotiated. If a
	negotiated, the receiver MUST close the subflow with a RST as it is		checksum is not present when its use has been negotiated, the
	considered broken. This RST SHOULD be accompanied with a MP_TCPRST		receiver MUST close the subflow with a RST as it is considered
	option (Section 3.6) with the reason code for a "MPTCP specific		broken. In both cases, this RST SHOULD be accompanied with a
	error".		MP_TCPRST option (Section 3.6) with the reason code for a "MPTCP
			specific error".
	3.3.1. Data Sequence Mapping		3.3.1. Data Sequence Mapping
	The data stream as a whole can be reassembled through the use of the		The data stream as a whole can be reassembled through the use of the
	data sequence mapping components of the DSS option (Figure 9), which		data sequence mapping components of the DSS option (Figure 9), which
	define the mapping from the subflow sequence number to the data		define the mapping from the subflow sequence number to the data
	sequence number. This is used by the receiver to ensure in-order		sequence number. This is used by the receiver to ensure in-order
	delivery to the application layer. Meanwhile, the subflow-level		delivery to the application layer. Meanwhile, the subflow-level
	sequence numbers (i.e., the regular sequence numbers in the TCP		sequence numbers (i.e., the regular sequence numbers in the TCP
	header) have subflow-only relevance. It is expected (but not		header) have subflow-only relevance. It is expected (but not
	skipping to change at page 31, line 12 ¶		skipping to change at page 31, line 14 ¶
	such as firewalls that undertake Initial Sequence Number (ISN)		such as firewalls that undertake Initial Sequence Number (ISN)
	randomization.		randomization.
	The data sequence mapping also contains a checksum of the data that		The data sequence mapping also contains a checksum of the data that
	this mapping covers, if use of checksums has been negotiated at the		this mapping covers, if use of checksums has been negotiated at the
	MP_CAPABLE exchange. Checksums are used to detect if the payload has		MP_CAPABLE exchange. Checksums are used to detect if the payload has
	been adjusted in any way by a non-MPTCP-aware middlebox. If this		been adjusted in any way by a non-MPTCP-aware middlebox. If this
	checksum fails, it will trigger a failure of the subflow, or a		checksum fails, it will trigger a failure of the subflow, or a
	fallback to regular TCP, as documented in Section 3.7, since MPTCP		fallback to regular TCP, as documented in Section 3.7, since MPTCP
	can no longer reliably know the subflow sequence space at the		can no longer reliably know the subflow sequence space at the
	receiver to build data sequence mappings.		receiver to build data sequence mappings. Without checksumming
			enabled, corrupt data may be delivered to the application if a
			middlebox alters segment boundaries, alters content, or does not
			deliver all segments covered by a data sequence mapping. It is
			therefore RECOMMENDED to use checksumming unless it is known the
			network path contains no such devices.
	The checksum algorithm used is the standard TCP checksum [RFC0793],		The checksum algorithm used is the standard TCP checksum [RFC0793],
	operating over the data covered by this mapping, along with a pseudo-		operating over the data covered by this mapping, along with a pseudo-
	header as shown in Figure 10.		header as shown in Figure 10.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+--------------------------------------------------------------+		+--------------------------------------------------------------+
	| |		| |
	| Data Sequence Number (8 octets) |		| Data Sequence Number (8 octets) |
	skipping to change at page 44, line 25 ¶		skipping to change at page 44, line 25 ¶
	| +-------------------------------+		| +-------------------------------+
	| |		| |
	+-------------------------------+		+-------------------------------+
	Figure 12: Add Address (ADD_ADDR) Option		Figure 12: Add Address (ADD_ADDR) Option
	Due to the proliferation of NATs, it is reasonably likely that one		Due to the proliferation of NATs, it is reasonably likely that one
	host may attempt to advertise private addresses [RFC1918]. It is not		host may attempt to advertise private addresses [RFC1918]. It is not
	desirable to prohibit this, since there may be cases where both hosts		desirable to prohibit this, since there may be cases where both hosts
	have additional interfaces on the same private network, and a host		have additional interfaces on the same private network, and a host
	MAY want to advertise such addresses. The MP_JOIN handshake to		MAY advertise such addresses. The MP_JOIN handshake to create a new
	create a new subflow (Section 3.2) provides mechanisms to minimize		subflow (Section 3.2) provides mechanisms to minimize security risks.
	security risks. The MP_JOIN message contains a 32-bit token that		The MP_JOIN message contains a 32-bit token that uniquely identifies
	uniquely identifies the connection to the receiving host. If the		the connection to the receiving host. If the token is unknown, the
	token is unknown, the host will return with a RST. In the unlikely		host will return with a RST. In the unlikely event that the token is
	event that the token is valid at the receiving host, subflow setup		valid at the receiving host, subflow setup will continue, but the
	will continue, but the HMAC exchange must occur for authentication.		HMAC exchange must occur for authentication. This will fail, and
	This will fail, and will provide sufficient protection against two		will provide sufficient protection against two unconnected hosts
	unconnected hosts accidentally setting up a new subflow upon the		accidentally setting up a new subflow upon the signal of a private
	signal of a private address. Further security considerations around		address. Further security considerations around the issue of
	the issue of ADD_ADDR messages that accidentally misdirect, or		ADD_ADDR messages that accidentally misdirect, or maliciously direct,
	maliciously direct, new MP_JOIN attempts are discussed in Section 5.		new MP_JOIN attempts are discussed in Section 5.
	A host that receives an ADD_ADDR but finds a connection set up to		A host that receives an ADD_ADDR but finds a connection set up to
	that IP address and port number is unsuccessful SHOULD NOT perform		that IP address and port number is unsuccessful SHOULD NOT perform
	further connection attempts to this address/port combination for this		further connection attempts to this address/port combination for this
	connection. A sender that wants to trigger a new incoming connection		connection. A sender that wants to trigger a new incoming connection
	attempt on a previously advertised address/port combination can		attempt on a previously advertised address/port combination can
	therefore refresh ADD_ADDR information by sending the option again.		therefore refresh ADD_ADDR information by sending the option again.
	A host can therefore send an ADD_ADDR message with an already		A host can therefore send an ADD_ADDR message with an already
	assigned Address ID, but the Address MUST be the same as previously		assigned Address ID, but the Address MUST be the same as previously
	skipping to change at page 58, line 23 ¶		skipping to change at page 58, line 23 ¶
	hash of this key as the connection identification "token". The keys		hash of this key as the connection identification "token". The keys
	are concatenated and used as keys for creating Hash-based Message		are concatenated and used as keys for creating Hash-based Message
	Authentication Codes (HMACs) used on subflow setup, in order to		Authentication Codes (HMACs) used on subflow setup, in order to
	verify that the parties in the handshake are the same as in the		verify that the parties in the handshake are the same as in the
	original connection setup. It also provides verification that the		original connection setup. It also provides verification that the
	peer can receive traffic at this new address. Replay attacks would		peer can receive traffic at this new address. Replay attacks would
	still be possible when only keys are used; therefore, the handshakes		still be possible when only keys are used; therefore, the handshakes
	use single-use random numbers (nonces) at both ends -- this ensures		use single-use random numbers (nonces) at both ends -- this ensures
	the HMAC will never be the same on two handshakes. Guidance on		the HMAC will never be the same on two handshakes. Guidance on
	generating random numbers suitable for use as keys is given in		generating random numbers suitable for use as keys is given in
	[RFC4086] and discussed in Section 3.1. HMAC is also used to secure		[RFC4086] and discussed in Section 3.1. The nonces are valid for the
			lifetime of the TCP connection attempt. HMAC is also used to secure
	the ADD_ADDR option, due to the threats identified in [RFC7430].		the ADD_ADDR option, due to the threats identified in [RFC7430].
	The use of crypto capability bits in the initial connection handshake		The use of crypto capability bits in the initial connection handshake
	to negotiate use of a particular algorithm allows the deployment of		to negotiate use of a particular algorithm allows the deployment of
	additional crypto mechanisms in the future. Note that this		additional crypto mechanisms in the future. This negotiation would
	negotiation would be susceptible to a bid-down attack by an on-path		nevertheless be susceptible to a bid-down attack by an on-path active
	active attacker who could modify the crypto capability bits response		attacker who could modify the crypto capability bits in the response
	from the receiver to use a less secure crypto mechanism. The		from the receiver to use a less secure crypto mechanism. The
	security mechanism presented in this document should therefore		security mechanism presented in this document should therefore
	protect against all forms of flooding and hijacking attacks discussed		protect against all forms of flooding and hijacking attacks discussed
	in [RFC6181].		in [RFC6181].
	The version negotiation specified in Section 3.1, if differing MPTCP		The version negotiation specified in Section 3.1, if differing MPTCP
	versions shared a common negotiation format, would allow an on-path		versions shared a common negotiation format, would allow an on-path
	attacker to apply a theoretical bid-down attack. Since the v1 and v0		attacker to apply a theoretical bid-down attack. Since the v1 and v0
	protocols have a different handshake, such an attack would require		protocols have a different handshake, such an attack would require
	the client to re-establish the connection using v0, and this being		the client to re-establish the connection using v0, and this being
	skipping to change at page 59, line 32 ¶		skipping to change at page 59, line 33 ¶
	ADD_ADDR injection into the stream.		ADD_ADDR injection into the stream.
	A small security risk could theoretically exist with key reuse, but		A small security risk could theoretically exist with key reuse, but
	in order to accomplish a replay attack, both the sender and receiver		in order to accomplish a replay attack, both the sender and receiver
	keys, and the sender and receiver random numbers, in the MP_JOIN		keys, and the sender and receiver random numbers, in the MP_JOIN
	handshake (Section 3.2) would have to match.		handshake (Section 3.2) would have to match.
	Whilst this specification defines a "medium" security solution,		Whilst this specification defines a "medium" security solution,
	meeting the criteria specified at the start of this section and the		meeting the criteria specified at the start of this section and the
	threat analysis ([RFC6181]), since attacks only ever get worse, it is		threat analysis ([RFC6181]), since attacks only ever get worse, it is
	likely that a future Standards Track version of MPTCP would need to		likely that a future version of MPTCP would need to be able to
	be able to support stronger security. There are several ways the		support stronger security. There are several ways the security of
	security of MPTCP could potentially be improved; some of these would		MPTCP could potentially be improved; some of these would be
	be compatible with MPTCP as defined in this document, whilst others		compatible with MPTCP as defined in this document, whilst others may
	may not be. For now, the best approach is to get experience with the		not be. For now, the best approach is to get experience with the
	current approach, establish what might work, and check that the		current approach, establish what might work, and check that the
	threat analysis is still accurate.		threat analysis is still accurate.
	Possible ways of improving MPTCP security could include:		Possible ways of improving MPTCP security could include:
	o defining a new MPCTP cryptographic algorithm, as negotiated in		o defining a new MPCTP cryptographic algorithm, as negotiated in
	MP_CAPABLE. A sub-case could be to include an additional		MP_CAPABLE. A sub-case could be to include an additional
	deployment assumption, such as stateful servers, in order to allow		deployment assumption, such as stateful servers, in order to allow
	a more powerful algorithm to be used.		a more powerful algorithm to be used.
	skipping to change at page 63, line 50 ¶		skipping to change at page 63, line 51 ¶
	The authors gratefully acknowledge significant input into this		The authors gratefully acknowledge significant input into this
	document from Sebastien Barre and Andrew McDonald.		document from Sebastien Barre and Andrew McDonald.
	The authors also wish to acknowledge reviews and contributions from		The authors also wish to acknowledge reviews and contributions from
	Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock,		Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock,
	Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo,		Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo,
	Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing,		Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing,
	Andrew McGregor, Georg Hampel, Anumita Biswas, Wes Eddy, Alexey		Andrew McGregor, Georg Hampel, Anumita Biswas, Wes Eddy, Alexey
	Melnikov, Francis Dupont, Adrian Farrel, Barry Leiba, Robert Sparks,		Melnikov, Francis Dupont, Adrian Farrel, Barry Leiba, Robert Sparks,
	Sean Turner, Stephen Farrell, Martin Stiemerling, Gregory Detal,		Sean Turner, Stephen Farrell, Martin Stiemerling, Gregory Detal,
	Fabien Duchene, Xavier de Foy, Rahul Jadhav, and Klemens Schragel.		Fabien Duchene, Xavier de Foy, Rahul Jadhav, Klemens Schragel, Mirja
			Kuehlewind, Sheng Jiang, Alissa Cooper, Ines Robles, Roman Danyliw,
			Adam Roach, Barry Leiba, Alexey Melnikov, Eric Vyncke, and Ben Kaduk.
	8. IANA Considerations		8. IANA Considerations
	This document obsoletes RFC6824 and as such IANA is requested to		This document obsoletes RFC6824 and as such IANA is requested to
	update the TCP option space registry to point to this document for		update the TCP option space registry to point to this document for
	Multipath TCP, as follows:		Multipath TCP, as follows:
	+------+--------+-----------------------+---------------+		+------+--------+-----------------------+---------------+
	| Kind | Length | Meaning | Reference |		| Kind | Length | Meaning | Reference |
	+------+--------+-----------------------+---------------+		+------+--------+-----------------------+---------------+
	skipping to change at page 74, line 11 ¶		skipping to change at page 74, line 11 ¶
	space is checksummed. We also note that this does not entail a loss		space is checksummed. We also note that this does not entail a loss
	of functionality, because TFO-data is always only sent on the initial		of functionality, because TFO-data is always only sent on the initial
	subflow before any attempt to create additional subflows.		subflow before any attempt to create additional subflows.
	B.3. Connection establishment examples		B.3. Connection establishment examples
	The following shows a few examples of possible TFO+MPTCP		The following shows a few examples of possible TFO+MPTCP
	establishment scenarios.		establishment scenarios.
	Before an initiator can send data together with the SYN, it must		Before an initiator can send data together with the SYN, it must
	request a cookie to the listener, as shown in Figure Figure 18. This		request a cookie to the listener, as shown in Figure 18. This is
	is done by simply combining the TFO and MPTCP options.		done by simply combining the TFO and MPTCP options.
	initiator listener		initiator listener
	| |		| |
	| S Seq=0(Length=0) <MP_CAPABLE>, <TFO cookie request> |		| S Seq=0(Length=0) <MP_CAPABLE>, <TFO cookie request> |
	| -----------------------------------------------------------> |		| -----------------------------------------------------------> |
	| |		| |
	| S. 0(0) ack 1 <MP_CAPABLE>, <TFO cookie> |		| S. 0(0) ack 1 <MP_CAPABLE>, <TFO cookie> |
	| <----------------------------------------------------------- |		| <----------------------------------------------------------- |
	| |		| |
	| . 0(0) ack 1 <MP_CAPABLE> |		| . 0(0) ack 1 <MP_CAPABLE> |
	| -----------------------------------------------------------> |		| -----------------------------------------------------------> |
	| |		| |
	Figure 18: Cookie request - sequence number and length are annotated		Figure 18: Cookie request - sequence number and length are annotated
	as Seq(Length) and used hereafter in the figures.		as Seq(Length) and used hereafter in the figures.
	Once this is done, the received cookie can be used for TFO, as shown		Once this is done, the received cookie can be used for TFO, as shown
	in Figure Figure 19. In this example, the initiator first sends 20		in Figure 19. In this example, the initiator first sends 20 bytes in
	bytes in the SYN. The listener immediately replies with 100 bytes		the SYN. The listener immediately replies with 100 bytes following
	following the SYN-ACK upon which the initiator replies with 20 more		the SYN-ACK upon which the initiator replies with 20 more bytes.
	bytes. Note that the last segment in the figure has a TCP sequence		Note that the last segment in the figure has a TCP sequence number of
	number of 21, while the DSS subflow sequence number is 1 (because the		21, while the DSS subflow sequence number is 1 (because the TFO data
	TFO data is not part of the data sequence number space, as explained		is not part of the data sequence number space, as explained in
	in Section Appendix B.2.		Section Appendix B.2.
	initiator listener		initiator listener
	| |		| |
	| S 0(20) <MP_CAPABLE>, <TFO cookie> |		| S 0(20) <MP_CAPABLE>, <TFO cookie> |
	| -----------------------------------------------------------> |		| -----------------------------------------------------------> |
	| |		| |
	| S. 0(0) ack 21 <MP_CAPABLE> |		| S. 0(0) ack 21 <MP_CAPABLE> |
	| <----------------------------------------------------------- |		| <----------------------------------------------------------- |
	| |		| |
	| . 1(100) ack 21 <DSS ack=1 seq=1 ssn=1 dlen=100> |		| . 1(100) ack 21 <DSS ack=1 seq=1 ssn=1 dlen=100> |
	skipping to change at page 75, line 25 ¶		skipping to change at page 75, line 25 ¶
	| |		| |
	| . 21(0) ack 1 <MP_CAPABLE> |		| . 21(0) ack 1 <MP_CAPABLE> |
	| -----------------------------------------------------------> |		| -----------------------------------------------------------> |
	| |		| |
	| . 21(20) ack 101 <DSS ack=101 seq=1 ssn=1 dlen=20> |		| . 21(20) ack 101 <DSS ack=101 seq=1 ssn=1 dlen=20> |
	| -----------------------------------------------------------> |		| -----------------------------------------------------------> |
	| |		| |
	Figure 19: The listener supports TFO		Figure 19: The listener supports TFO
	In Figure Figure 20, the listener does not support TFO. The		In Figure 20, the listener does not support TFO. The initiator
	initiator detects that no state is created in the listener (as no		detects that no state is created in the listener (as no data is
	data is acked), and now sends the MP_CAPABLE in the third ack, in		acked), and now sends the MP_CAPABLE in the third ack, in order for
	order for the listener to build its MPTCP context at then end of the		the listener to build its MPTCP context at then end of the
	establishment. Now, the tfo data, retransmitted, becomes part of the		establishment. Now, the tfo data, retransmitted, becomes part of the
	data sequence mapping because it is effectively sent (in fact re-		data sequence mapping because it is effectively sent (in fact re-
	sent) after the establishment.		sent) after the establishment.
	initiator listener		initiator listener
	| |		| |
	| S 0(20) <MP_CAPABLE>, <TFO cookie> |		| S 0(20) <MP_CAPABLE>, <TFO cookie> |
	| -----------------------------------------------------------> |		| -----------------------------------------------------------> |
	| |		| |
	| S. 0(0) ack 1 <MP_CAPABLE> |		| S. 0(0) ack 1 <MP_CAPABLE> |
	skipping to change at page 76, line 6 ¶		skipping to change at page 76, line 6 ¶
	| . 1(20) ack 1 <DSS ack=1 seq=1 ssn=1 dlen=20> |		| . 1(20) ack 1 <DSS ack=1 seq=1 ssn=1 dlen=20> |
	| -----------------------------------------------------------> |		| -----------------------------------------------------------> |
	| |		| |
	| . 0(0) ack 21 <DSS ack=21 seq=1 ssn=1 dlen=0> |		| . 0(0) ack 21 <DSS ack=21 seq=1 ssn=1 dlen=0> |
	| <----------------------------------------------------------- |		| <----------------------------------------------------------- |
	| |		| |
	Figure 20: The listener does not support TFO		Figure 20: The listener does not support TFO
	It is also possible that the listener acknowledges only part of the		It is also possible that the listener acknowledges only part of the
	TFO data, as illustrated in Figure Figure 21. The initiator will		TFO data, as illustrated in Figure 21. The initiator will simply
	simply retransmit the missing data together with a DSS-mapping.		retransmit the missing data together with a DSS-mapping.
	initiator listener		initiator listener
	| |		| |
	| S 0(1000) <MP_CAPABLE>, <TFO cookie> |		| S 0(1000) <MP_CAPABLE>, <TFO cookie> |
	| -----------------------------------------------------------> |		| -----------------------------------------------------------> |
	| |		| |
	| S. 0(0) ack 501 <MP_CAPABLE> |		| S. 0(0) ack 501 <MP_CAPABLE> |
	| <----------------------------------------------------------- |		| <----------------------------------------------------------- |
	| |		| |
	| . 501(0) ack 1 <MP_CAPABLE> |		| . 501(0) ack 1 <MP_CAPABLE> |
	skipping to change at page 76, line 47 ¶		skipping to change at page 76, line 47 ¶
	C.1. MPTCP Control Block		C.1. MPTCP Control Block
	The MPTCP control block contains the following variable per		The MPTCP control block contains the following variable per
	connection.		connection.
	C.1.1. Authentication and Metadata		C.1.1. Authentication and Metadata
	Local.Token (32 bits): This is the token chosen by the local host on		Local.Token (32 bits): This is the token chosen by the local host on
	this MPTCP connection. The token must be unique among all		this MPTCP connection. The token must be unique among all
	established MPTCP connections, generated from the local key.		established MPTCP connections, and is generated from the local
			key.
	Local.Key (64 bits): This is the key sent by the local host on this		Local.Key (64 bits): This is the key sent by the local host on this
	MPTCP connection.		MPTCP connection.
	Remote.Token (32 bits): This is the token chosen by the remote host		Remote.Token (32 bits): This is the token chosen by the remote host
	on this MPTCP connection, generated from the remote key.		on this MPTCP connection, generated from the remote key.
	Remote.Key (64 bits): This is the key chosen by the remote host on		Remote.Key (64 bits): This is the key chosen by the remote host on
	this MPTCP connection		this MPTCP connection
End of changes. 22 change blocks.
	69 lines changed or deleted		81 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/