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. In general the MPTCP idea and approach look good. There is a large number of security implications and potential problems with MPTCP. The draft's security consideration section basically just refers to two other drafts (draft-ietf-mptcp-threat-06 and draft-ietf-mptcp-multiaddressed-02) to address and solve them. As these elements are pretty central, I am not convinced that these references to "work in progress" drafts are sufficient and only "informative". Draft draft-ietf-mptcp-threat-06 describes some of the security concerns in good detail. I would recommend that the progress of the draft-ietf-mptcp-architecture draft should be halted/delayed until the referenced drafts (or at least some of them) are released. There are a number of issues I would like to raise (some of them might have been answered in one of the several referenced documents or documents referenced by referenced document): - section 5.8: Considering the wide range of threats and potential problems, section "5.8. Security" 3rd paragraph should change "A multi-addressed Multipath TCP SHOULD be able to" to "A multi-addressed Multipath TCP MUST be able to". These are really mandatory requirements to make sure MPTCP does not break and is equal to TCP. - does MPTCP reduce quality of service for other TCP users? section 2.2.3 states: "The use of multiple paths MUST NOT unduly harm users using single-path TCP at shared bottlenecks, beyond the impact that would occur from another single-path TCP flow." I fully agree with this concern. However you do not indicate how this shall be achieved. Considering the TCP-transparancy paradigm in MPTCP this could conflict with "fair shared resources" at bottlenecks? Maybe you can elaborate on how you want to achieve that. I am not sure I can fully see or understand that from draft-ietf-mptcp-congestion-01 (which btw. you maybe should reference in section 2.2.3)? - section 4, paragraph "Congestion Control": this is referencing to draft-ietf-mptcp-congestion-01, which in turn claims to have no security considerations and references to draft-ford-mptcp-multiaddressed-01 (which is experimental and a bit vague with the security considerations and still work in progress) and a non-existent [REF] to deal with this problem. This is not satisfying. - does it lead to traffic shaping (meaning that the network provider will give individual users different qualities of service for TCP). E.g. To make MPTCP equal to one TCP, do you have to reduce QoS for some of its TCP pieces? Or do you identify MPTCP at bottlenecks and allow only for specific users MPTCP? - Packet Scheduling: -- section 4, paragraph "Packet Scheduling" and section 5.3 "Buffer" thinking about scheduling packets on MPTCP layer means holding TCP packets back while waiting for others. Does that introduce a new dimension of memory resource requirements on the receiving machine which could lead to "flooding" attacks with MPTCP. (E.g. sending a MPTCP where one TCP packet is missing by intent and making the receiving endpoint keep all packets keep in memory waiting for the missing subflow packet)? (also refers to section 5.2. Reliability and Retransmissions) - what should happen when two subflow packets (with the same connection level sequence number) arrive via two different TCP paths? Within the time until all connection packets have been re-arranged (e.g. while waiting). Does that mean you can disrupt MPTCP by listening in on one subflow on one path and sending fake messages that will overlap (in connection sequence number) with packets from other paths? - agree with the assessment of section 5.1 on double sequencing ("a connection level sequence number, and another sequence number for each subflow"). However: - could this also make Denial of Service scenarios easier? (or meaning makes it more difficult for middleboxes to determine whether a TCP DoS attack is ongoing or a normal MPTCP (MPTCP's several TCP subflows from one source may look like "flooding" from one source)? - section "5.6. Connection Identification": comment: The Connection id MUST be protected against spoofing, because for MPTCP aware clients this could be used to divert traffic from a legitimate client to a non-legitimate client by spoofing to operate under the same connection id? Normally a server will reply back to the sender's IP address (the same TCP subflow). With MPTCP an attacker might inject a second "connection" into the flow and divert answers from the server to new IP (using the second MPTCP subflow path)? Kind regards, Tobias