Draft: draft-ietf-mptcp-rfc6824bis-11

Commentary: Move TFO section to  . Remove Experimental option . Clarifications from IETF101 ( security text and fallback on handshake ) . Bump version . 
 Looks all good !
Paragraph (version A):
To meet the threats identified in RFC6181, the following steps are
taken: keys are sent in the clear in the MP_CAPABLE messages;
MP_JOIN messages are secured with HMAC-SHA256 (RFC2104, SHS) using
those keys; and standard TCP validity checks are made on the other
messages (ensuring sequence numbers are in-window RFC5961).
Paragraph (version B):
To meet the threats identified in RFC6181, the following steps are
taken: keys are sent in the clear in the MP_CAPABLE messages;
MP_JOIN messages are secured with HMAC-SHA256 (RFC2104, SHS) using
those keys; and standard TCP validity checks are made on the other
messages (ensuring sequence numbers are in-window RFC5961).
Further information can be found in sec_security.
Paragraph (version A):
Additionally, the MP_CAPABLE exchange allows the safe passage of
MPTCP options on SYN packets to be determined.  If any of these
options are dropped, MPTCP will gracefully fall back to regular
single-path TCP, as documented in sec_fallback.  Note that new
subflows MUST NOT be established (using the process documented in
sec_join) until a Data Sequence Signal (DSS) option has been
successfully received across the path (as documented in
sec_generalop).
Paragraph (version B):
Additionally, the MP_CAPABLE exchange allows the safe passage of
MPTCP options on SYN packets to be determined.  If any of these
options are dropped, MPTCP will gracefully fall back to regular
single-path TCP, as documented in sec_fallback.  If at any point in
the handshake either party thinks the MPTCP negotiation is
compromised, for example by a middlebox corrupting the TCP options,
or unexpected ACK numbers being present, the host MUST stop using
MPTCP and no longer include MPTCP options in future TCP packets.  The
other host will then also fall back to regular TCP using the fall
back mechanism.  Note that new subflows MUST NOT be established
(using the process documented in sec_join) until a Data Sequence
Signal (DSS) option has been successfully received across the path
(as documented in sec_generalop).
Paragraph (version A):
In order to provide a structured identity and negotiation mechanism
for private experimental MPTCP extensions, the MP_EXPERIMENTAL option
has been reserved.
Paragraph (version A):
tcpm_experimental shows the format of the experimental option.  The
Experiment identifier is a 16 bits integer that shall be assigned by
using the same procedure as defined in RFC6994; a request to IANA is
made in IANA_experimental.
Paragraph (version A):
"S" flag (highest order bit) : This is the synchronising bit.
When set to 1, it indicates that the host sending this option
expects a reply from the remote host with an option having the
same experiment identifier, but possibly containing other data.
Paragraph (version A):
"U" flag (second highest order bit) : When set to 1, this flag
indicates that the experimental option was received by the sending
host but it was unable to parse it.
Paragraph (version A):
The two low order flags are currently reserved for further use.  They
MUST be set to zero when sending and ignored upon reception.
Paragraph (version A):
To use the Experimental MPTCP option with a given experiment
identifier over a MPTCP connection, the sending host must first
verify the ability of the remote host to support this particular
Experimental option.  For this, it first sends in any valid TCP
segment, including a duplicate acknowledgement, an Experimental MPTCP
option with the "S" flag set.  Upon reception of this option, the
receiving host will verify whether it supports it.  If yes, it shall
return a TCP segment that contains the experimental option with the
same identifier and the "S" and the "U" flags both set to 1.  This
option may contain additional data depending on the semantics of the
extension.  If the receiving host does not recognise the experimental
option that it has received, it shall return a TCP segment that
contains the received experimental option with the "S" flag set to 0
and the "U" flag set to 1.
Paragraph (version A):
If a host receives an Experimental MPTCP option with the "U" flag set
to 0 which it does not support, or which contains information that
the host cannot parse, it shall return the exact option that it
received with the "U" flag set to 1 to indicate the error to the
remote host.  If an invalid option is received with the "U" flag set
to 0, it must be silently discarded.
Paragraph (version A):
Future documents specifying new experimental MPTCP options should
specify the extract semantic of the Subtype-specific data and whether
additional validation operations are to be followed at both sides.
It should be noted that data can be included in an experimental
option concurrently with the capability check (S/U).
Paragraph (version A):
TCP Fast Open, described in RFC7413, has been introduced with the
objective of gaining one RTT before transmitting data.  This is
considered a valuable gain as very short connections are very common,
especially for HTTP request/response schemes.  It achieves this by
sending the SYN-segment together with data and allowing the server to
reply immediately with data after the SYN/ACK.  RFC7413 secures this
mechanism, by using a new TCP option that includes a cookie which is
negotiated in a preceding connection.
Paragraph (version A):
When using TCP Fast Open in conjunction with MPTCP, there are two key
points to take into account, detailed hereafter.
Paragraph (version A):
When a TFO client first connects to a server, it cannot immediately
include data in the SYN for security reasons RFC7413.  Instead, it
requests a cookie that will be used in subsequent connections.  This
is done with the TCP cookie request/response options, of resp. 2
bytes and 6-18 bytes (depending on the chosen cookie length).
Paragraph (version A):
In the SYN: MPTCP uses a 4-bytes long MP_CAPABLE option.  The
MPTCP and TFO options sum up to 6 bytes.  With typical TCP-options
using up to 19 bytes in the SYN (24 bytes if options are padded at
a word boundary), there is enough space to combine the MP_CAPABLE
with the TFO Cookie Request.
Paragraph (version A):
In the SYN+ACK: MPTCP uses a 12-bytes long MP_CAPABLE option, but
now TFO can be as long as 18 bytes.  Since the maximum option
length may be exceeded, it is up to the server to solve this by
using a shorter cookie.  As an example, if we consider that 19
bytes are used for classical TCP options, the maximum possible
cookie length would be of 7 bytes.  Note that the same limitation
applies to subsequent connections, for the SYN packet (because the
client then echoes back the cookie to the server).  Finally, if
the security impact of reducing the cookie size is not deemed
acceptable, the server can reduce the amount of other TCP-options
by omitting the TCP timestamps (as outlined in app_options).
Paragraph (version A):
MPTCP uses, in the TCP establishment phase, a key exchange that is
used to generate the Initial Data Sequence Numbers (IDSNs).  In
particular, the SYN with MP_CAPABLE occupies the first octet of the
data sequence space.  With TFO, one way to handle the data sent
together with the SYN would be to consider an implicit DSS mapping
that covers that SYN segment (since there is not enough space in the
SYN to include a DSS option).  The problem with that approach is that
if a middlebox modifies the TFO data, this will not be noticed by
MPTCP because of the absence of a DSS-checksum.  For example, a TCP
(but not MPTCP)-aware middlebox could insert bytes at the beginning
of the stream and adapt the TCP checksum and sequence numbers
accordingly.  With an implicit mapping, this would give to client and
server a different view on the DSS-mapping, with no way to detect
this inconsistency as the DSS checksum is not present.
Paragraph (version A):
To solve this, the TFO data should not be considered part of the Data
Sequence Number space: the SYN with MP_CAPABLE still occupies the
first octet of data sequence space, but then the first non-TFO data
byte occupies the second octet.  This guarantees that, if the use of
DSS-checksum is negotiated, all data in the data sequence number
space is checksummed.  We also note that this does not entail a loss
of functionality, because TFO-data is always sent when only one path
is active.
Paragraph (version A):
The following shows a few examples of possible TFO+MPTCP
establishment scenarios.
Paragraph (version A):
Before a client can send data together with the SYN, it must request
a cookie to the server, as shown in Figure fig_tfocookie.  This is
done by simply combining the TFO and MPTCP options.
Paragraph (version A):
Once this is done, the received cookie can be used for TFO, as shown
in Figure fig_tfodata.  In this example, the client first sends 20
bytes in the SYN.  The server immediately replies with 100 bytes
following the SYN-ACK upon which the client replies with 20 more
bytes.  Note that the last segment in the figure has a TCP sequence
number of 21, while the DSS subflow sequence number is 1 (because the
TFO data is not part of the data sequence number space, as explained
in Section tfodata.
Paragraph (version A):
In Figure fig_tfofallback, the server does not support TFO.  The
client detects that no state is created in the server (as no data is
acked), and now sends the MP_CAPABLE in the third ack, in order for
the server to build its MPTCP context at then end of the
establishment.  Now, the tfo data, retransmitted, becomes part of the
data sequence mapping because it is effectively sent (in fact re-
sent) after the establishment.
Paragraph (version A):
It is also possible that the server acknowledges only part of the TFO
data, as illustrated in Figure fig_tfopartial.  The client will
simply retransmit the missing data together with a DSS-mapping.
Paragraph (version A):
Values 0x9 through 0xe are currently unassigned.
Paragraph (version B):
Values 0x9 through 0xe are currently unassigned.  Option 0xf is
reserved for use by private experiments.  Its use may be formalized
in a future specification.
Paragraph (version A):
sec_experimental has defined the MP_EXPERIMENTAL option for private,
experimental MPTCP options, and the same considerations as for
RFC6994 apply.  IANA should create a "Multipath TCP Experimental
Option Identifiers (MPTCP ExIDs)" sub-registry.  This registry
contains the 16 bits ExIDs and a reference (description, document
pointer, or assignee name and e-mail contact) for each entry.  MPTCP
ExIDs are assigned on a First Come, First Served (FCFS) basis
RFC5226.
Paragraph (version A):
IANA will advise applicants of duplicate entries to select an
alternate value, as per typical FCFS processing.
Paragraph (version A):
IANA will record known duplicate uses to assist the community in both
debugging assigned uses as well as correcting unauthorized duplicate
uses.