Draft: draft-ietf-mptcp-rfc6824bis-11

Commentary: Reading through the draft I noticed a few typos so I wanted to propose a small change to fix .
Paragraph (version A):
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 (which is not).  Both
examples are shown in the following diagrams.  Further details are in
sec_fastclose.
Paragraph (version B):
There is an additional method of connection 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 (which is not).  Both
examples are shown in the following diagrams.  Further details are in
sec_fastclose.
Paragraph (version A):
Since key generation is implementation-specific, there is no
requirement that they be simply random numbers.  An implemention is
free to exchange cryptographic material out-of-band and generate
these keys from this, in order to provide additional mechanisms by
which to verify the identity of the communicating entities.  For
example, an implementation could choose to link its MPTCP keys to
those used in higher-layer TLS or SSH connections.
Paragraph (version B):
Since key generation is implementation-specific, there is no
requirement that they be simply random numbers.  An implementation is
free to exchange cryptographic material out-of-band and generate
these keys from this, in order to provide additional mechanisms by
which to verify the identity of the communicating entities.  For
example, an implementation could choose to link its MPTCP keys to
those used in higher-layer TLS or SSH connections.
Paragraph (version A):
Data sequence numbers are always 64-bit quantities, and MUST be
maintained as such in implementations.  If a connection is
progressing at a slow rate, so protection against wrapped sequence
numbers is not required, then an implementation MAY include just the
lower 32 bits of the data sequence number in the data sequence
mapping and/or Data ACK as an optimization, and an implementation can
make this choice independently for each packet.  An implementaton
MUST be able to receive and process both 64-bit or 32-bit sequence
number values, but it is not required that an implementation is able
to send both.
Paragraph (version B):
Data sequence numbers are always 64-bit quantities, and MUST be
maintained as such in implementations.  If a connection is
progressing at a slow rate, so protection against wrapped sequence
numbers is not required, then an implementation MAY include just the
lower 32 bits of the data sequence number in the data sequence
mapping and/or Data ACK as an optimization, and an implementation can
make this choice independently for each packet.  An implementation
MUST be able to receive and process both 64-bit or 32-bit sequence
number values, but it is not required that an implementation is able
to send both.
Paragraph (version A):
for the reciever of an MP_FAIL to also respond with an MP_FAIL, since
the paths may only be damaged in one direction.  However,
implementations MAY choose to send a MP_FAIL in the reverse direction
and entirely revert to a regular TCP session.
Paragraph (version B):
for the receiver of an MP_FAIL to also respond with an MP_FAIL, since
the paths may only be damaged in one direction.  However,
implementations MAY choose to send a MP_FAIL in the reverse direction
and entirely revert to a regular TCP session.
Paragraph (version A):
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.
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
identifier from the MP_PRIO option (sec_policy), to remove the
theoretical attack where a subflow could be placed in "backup" mode
by an attacker.