Last Call Review of draft-ietf-mptcp-multiaddressed-
review-ietf-mptcp-multiaddressed-secdir-lc-melnikov-2012-08-21-00

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.