Draft: draft-ietf-mptcp-rfc6824bis-11

Commentary: , your comments have been addressed . 
 Two comments included
Paragraph (version A):
Upon receipt of an ACK with MP_FASTCLOSE, containing the valid
key, Host B answers on the same subflow with a TCP RST and tears
down all subflows.  Host B can now close the whole MPTCP
connection (it transitions directly to CLOSED state).
Paragraph (version B):
Upon receipt of an ACK with MP_FASTCLOSE by Host B, containing the
valid key, Host B answers on the same subflow with a TCP RST and
tears down all subflows.  Host B can now close the whole MPTCP
connection (it transitions directly to CLOSED state).
Paragraph (version A):
Upon receipt of a RST with MP_FASTCLOSE, containing the valid key,
Host B tears down all subflows.  Host B can now close the whole
MPTCP connection (it transitions directly to CLOSED state).
Paragraph (version A):
As discussed in sec_fastclose above, the MP_FASTCLOSE option provides
a connection-level reset roughly analagous to a TCP RST.  Regular TCP
RST options remain used to at the subflow-level to indicate the
receiving host has no knowledge of the MPTCP subflow or TCP
connection to which the packet belongs.
Paragraph (version A):
However, in MPTCP, there may be many reasons for rejecting the
opening of a subflow, but these semantics cannot be carried in a
standard TCP RST.  It would be beneficial for a host to the reasons
why its subflow has been closed with a RST, and thus whether it
should try to re-establish the subflow immediately, later, or never
again.  These semantics are carried in the MP_TCPRST option that can
be included on a TCP RST packet.
Paragraph (version B):
If however host A decides to force the closure by using Option R and
sending a RST with the MP_FASTCLOSE option, Host B will act as
follows: Upon receipt of a RST with MP_FASTCLOSE, containing the
valid key, Host B tears down all subflows by sending a TCP RST.  Host
B can now close the whole MPTCP connection (it transitions directly
to CLOSED state).
Paragraph (version B):
An implementation of MPTCP may also need to send a regular TCP RST to
force the closure of a subflow.  A host sends a TCP RST in order to
close a subflow or reject an attempt to open a subflow (MP_JOIN).  In
order to inform the receiving host why a subflow is being closed or
rejected, the TCP RST packet MAY include the MP_TCPRST Option.  The
host MAY use this information to decide, for example, whether it
tries to re-establish the subflow immediately, later, or never.
Paragraph (version A):
Unspecified error (code 0x0).  This is the default error implying
the subflow is not longer available.  The receiving host SHOULD
take account of the 'T' bit in deciding whether to re-estbalish
this subflow.  The presence of this option shows that the RST was
generated by a MPTCP-aware device.
Paragraph (version B):
Unspecified error (code 0x0).  This is the default error implying
the subflow is not longer available.  The presence of this option
shows that the RST was generated by a MPTCP-aware device.
Paragraph (version A):
Lack of resources (code 0x02).  This code indicates that the
sending host does not have enough ressources to support the
terminated subflow.
Paragraph (version B):
Lack of resources (code 0x02).  This code indicates that the
sending host does not have enough resources to support the
terminated subflow.
Paragraph (version A):
If the the same ports are used on all subflows, as recommended above,
then standard TCP simultaneous open logic should take care of this
situation and only one subflow will be established between the
address pairs.  However, this relies on the same ports being used at
both end hosts.  If a host does not support TCP simultaneous open, it
is RECOMMENDED that some element of randomization is applied to the
time waited before opening new subflows, so that only one subflow
exists between a given address pair.  If, however, hosts signal
additional ports to use (for example, for leveraging ECMP on-path),
this heuristic need not apply.
Paragraph (version B):
If the the same ports are used on all subflows, as recommended above,
then standard TCP simultaneous open logic should take care of this
situation and only one subflow will be established between the
address pairs.  However, this relies on the same ports being used at
both end hosts.  If a host does not support TCP simultaneous open, it
is RECOMMENDED that some element of randomization is applied to the
time to wait before opening new subflows, so that only one subflow is
created between a given address pair.  If, however, hosts signal
additional ports to use (for example, for leveraging ECMP on-path),
this heuristic is not appropriate.
Paragraph (version B):
To further protect against malicious ADD_ADDR messages sent by an
off-path attacker, the ADD_ADDR includes an HMAC using the keys
negotiated during the handshake.  This effectively prevents an
attacker from diverting an MPTCP connection through an off-path
ADD_ADDR injection into the stream.