[secdir] Secdir review of draft-ietf-mptcp-multiaddressed-09

[Alexey Melnikov <[e-mail]>]

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
  These comments were written primarily for the benefit of the security 
area directors.  Document editors and WG chairs should treat these 
comments just like any other last call comments.

This document describes a set of extensions to traditional TCP to 
support multipath operation, i.e. the ability to simultaneously use 
multiple (potentially disjoint) paths between peers.  The protocol 
offers the same type of service to applications as TCP (i.e. reliable
bytestream), and provides the components necessary to establish and
use multiple TCP flows across paths.

The Security Consideration states:

    The fundamental goal is for the security of
    MPTCP to be "no worse" than regular TCP today, and the key security
    requirements are:

    o  Provide a mechanism to confirm that the parties in a subflow
       handshake are the same as in the original connection setup.

    o  Provide verification that the peer can receive traffic at a new
       address before using it as part of a connection.

    o  Provide replay protection, i.e. ensure that a request to add/
       remove a subflow is 'fresh'.

And then explains in details how these security requirements are met. I 
think the design and explanation is quite reasonable.

The Security Considerations also mentions that the ability of 
negotiating a particular hashing mechanism is susceptible to bid-down 
attacks for on-path attackers and points out that this is also true for 
TCP without MPTCP extension.

I think there are a couple of things missing from the Security 
Considerations section:

Section 3.3.1 says that the same data can be sent on multiple subflows 
(for resiliency). What if an attacker tries to send different data on 
multiple subflows pretending it is the same? Is there a security 
consideration here? (I admit I am quite ignorant and might be missing 
something obvious here.)

Section 3.3.1 implies that unacknowledged connection level data 
(received before the mapping is received) can be used for DoS? Should 
this be mentioned in the Section 5.



Other minor comments/nits:

2.7.  Notable features

    o  To meet the threats identified in [7], the following steps are
       taken: keys are sent in the clear in the MP_CAPABLE messages;
       MP_JOIN messages are secured with HMAC-SHA1

The first mention of HMAC-SHA1 needs a reference.

       using those keys; and
       standard TCP validity checks are made on the other messages (
       ensuring sequence numbers are in-window).

In 3.1:

    This key is generated by its sender and has local meaning only, and
    its method of generation is implementation-specific.  The key MUST be
    hard to guess, and it MUST be unique for the sending host at any one
    time.  Recommendations for generating random keys are given in [11].
    Connections will be indexed at each host by the token (the truncated
    SHA-1 hash of the key).  Therefore, an implementation will require a
    mapping from each token to the corresponding connection, and in turn
    to the keys for the connection.

Sounds like a good text for the Security Consideration section (maybe 
add a pointer from there?)

  [...]

    This exchange allows the safe passage of MPTCP options on SYN packets
    to be determined.  If any of these options are dropped, MPTCP SHOULD

"SHOULD" or "will"? Use of SHOULD doesn't seem correct here.

    gracefully fall back to regular single-path TCP, as documented in
    Section 3.6.  Note that new subflows MUST NOT be established (using
    the process documented in Section 3.2) until a DSS option has been
    successfully received across the path (as documented in Section 3.3).

  [...]

    These bits negotiate capabilities in similar ways.  For the 'C' bit,
    if either host requires the use of checksums, checksums MUST be used.
    In other words, the only way for checksums not to be used is if both
    hosts in their SYNs set C=0.  This decision is confirmed by the
    setting of the 'C' bit in the third packet (the ACK) of the
    handshake.  For example, if the initiator sets C=0 in the SYN, but
    the responder sets C=1 in the SYN/ACK, checksums MUST be used in both

Is support of C=1 required in all implementations?

It is also a bit unusual (at least to me) that the initiator is not able 
to refuse to support C=1.

    directions, and the initiator will set C=1 in the ACK.  The decision
    whether to use checksums will be stored by an implementation in a
    per-connection binary state variable.