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.