Draft: draft-ietf-mptcp-rfc6824bis-11

Commentary: Security section may need more work , rest is covered I think , . 
 Something that needs fixing which Christoph and I just noticed during a chat at the IETF : S3.7 on Fallback has < < Note that this rule essentially prohibits the sending of data on the third packet of an MPCAPABLE or MPJOIN handshake , since both that option and a DSS can not fit in TCP option needs a mod now data is allowed on the third packet . 
 Can be resolved just by removing that paragraph . Rest of section still holds . 
 Changes in the PR look good to me . Closing . 
 ( From  ) 
 Some rewording done in S3.1 ... new diagrams in S2.1 ... the MUST not thing ( second point ) does not need changing . 
 Changes in the PR look good to me . Closing . 
 Changes in the PR look good to me . Closing . 
 ( From  ) 
 Subflow close + fast close to connection close section . Fallback is too complex for S2 ; have ref to fallback section . 
 Changes in the PR look good to me . Closing . 
 ( From   ) 
 Added discussion of version , MPPRIO . No additional text needed for MPCAPABLE or FASTCLOSE that I can see . 
 Changes in the PR look good to me . Closing .
Paragraph (version B):
Retransmission of the ACK + MP_CAPABLE can occur if it is not known
if it has been received.  The following diagrams show all possible
exchanges for the initial subflow setup to ensure this reliability.
Paragraph (version B):
When a host wants to close an existing subflow, but not the whole
connection, it can initiate a regular TCP FIN/ACK exchange.
Paragraph (version B):
There is an additional method of connecton closure, referred to as
"Fast Close", which is analogous to closing a single-path TCP
connection with a RST signal.  The MP_FASTCLOSE signal is used to
indicate to the peer that the connection will be abruptly closed and
no data will be accepted anymore.  This can be used on an ACK
(ensuring reliability of the signal), or a RST (whuch is not).  Both
examples are shown in the following diagrams.  Further details are in
sec_fastclose.
Paragraph (version A):
MPTCP falls back to ordinary TCP if MPTCP operation is not
possible, for example, if one host is not MPTCP capable or if a
middlebox alters the payload.
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).
Further information can be found in sec_security.
Paragraph (version B):
MPTCP falls back to ordinary TCP if MPTCP operation is not
possible, for example, if one host is not MPTCP capable or if a
middlebox alters the payload.  This is discussed in sec_fallback.
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).
Residual threats to MPTCP v0 RFC6824 were identified in RFC7430,
and those affecting the protocol (i.e. modification to ADD_ADDR)
have been incorporated in this document.  Further discussion of
security can be found in sec_security.
Paragraph (version A):
If B has data to send first, then the reliable delivery of the ACK
can be inferred by the receipt of this data with a MPTCP Data
Sequence Signal (DSS) option (sec_generalop).  If, however, A wishes
to send data first, it would not know whether the ACK has
successfully been received, and thus whether the MPTCP is
successfully established.  Therefore, on the first data A has to send
(if it has not received any data from B), it MUST also include a
MP_CAPABLE option, with additional data parameters (the Data-Level
Length and optional Checksum as shown in tcpm_capable).  This packet
may be the third ACK if data is ready to be sent by the application,
or may be a later packet if the application only later has data to
send.  This MP_CAPABLE option is in place of the DSS, and simply
specifies the data-level length of the payload, and the checksum (if
the use of checksums is negotiated).  This is the minimal data
required to establish a MPTCP connection - it allows validation of
the payload, and given it is the first data, the Initial Data
Sequence Number (IDSN) is also known (as it is generated from the
key, as described below).  Conveying the keys on the first data
packet allows the TCP reliability mechanisms to ensure the packet is
successfully delivered.  The receiver will acknowledge this data a
the connection level with a Data ACK, as if a DSS option has been
received.
Paragraph (version B):
If B has data to send first, then the reliable delivery of the
ACK+MP_CAPABLE can be inferred by the receipt of this data with a
MPTCP Data Sequence Signal (DSS) option (sec_generalop).  If,
however, A wishes to send data first, it has two options to ensure
the reliable delivery of the ACK+MP_CAPABLE.  If it immediately has
data to send, then the third ACK (with data) would also contain an
MP_CAPABLE option with additional data parameters (the Data-Level
Length and optional Checksum as shown in tcpm_capable).  If A does
not immediately have data to send, it MUST include the MP_CAPABLE on
the third ACK, but without the additional data parameters.  When A
does have data to send, it must repeat the sending of the MP_CAPABLE
option from the third ACK, with additional data parameters.  This
MP_CAPABLE option is in place of the DSS, and simply specifies the
data-level length of the payload, and the checksum (if the use of
checksums is negotiated).  This is the minimal data required to
establish a MPTCP connection - it allows validation of the payload,
and given it is the first data, the Initial Data Sequence Number
(IDSN) is also known (as it is generated from the key, as described
below).  Conveying the keys on the first data packet allows the TCP
reliability mechanisms to ensure the packet is successfully
delivered.  The receiver will acknowledge this data a the connection
level with a Data ACK, as if a DSS option has been received.
Paragraph (version A):
Note that this rule essentially prohibits the sending of data on the
third packet of an MP_CAPABLE or MP_JOIN handshake, since both that
option and a DSS cannot fit in TCP option space.  If the initiator is
to send first, another segment must be sent that contains the data
and DSS.  Note also that an additional subflow cannot be used until
the initial path has been verified as MPTCP capable.
Paragraph (version A):
RFC4086 and discussed in sec_init.
Paragraph (version B):
RFC4086 and discussed in sec_init.  HMAC is also used to secure the
ADD_ADDR option, due to the threats identified in RFC7430.
Paragraph (version B):
The version negotiation specified in sec_init, if differing MPTCP
versions shared a common negotiation format, would allow an on-path
attacker to apply a theoretical bid-down attack.  However, since the
v1 and v0 protocols have a different handshake, this is not an attack
that can be applied here.  Furthermore, an on-path attacker would
have access to the raw data, negating any other TCP-level security
mechanisms.  Also a change from RFC6824 has removed the subflow
identifer from the MP_PRIO option (sec_policy), to remove the
theoretical attack where a subflow could be placed in "backup" mode
by an attacker.