Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Apologies for the late review. The IETF meeting and subsequent health issues have prevented me from taking this on earlier. This document is a security threat analysis, and in itself does not have implications on operations and management of the protocol in question. The following NITs are in the document: Section 3 --------- SYN-flod -> SYN-flood on-time attacker -> on-path attacker (?) Section 7 --------- The caption of section 7 has a typo: Reccomendation -> Recommendation From an OPS-DIR perspective, the document is Ready with very minor nits. From a security perspective, IMHO not so. The following are comments from my individual perspective, which I hope can be considered even though being so late. The document readily admits that an attacker who can eavesdrop parts of the connection can hijack and MitM the connection to his liking. The document states in section 5 that: "This vulnerability was readily identified at the moment of the design of the MPTCP security solution and the threat was considered acceptable." I believe the design of MPTCP predates the IETF's "perpass" considerations and did not take into account that pervasive passive attacks are possible and are being conducted at large scale on the internet on a day-to-day basis. The -attacks document now provides an easy-to-follow recipe to mount the attack, with the only prerequisite being that TCP headers can be inspected by an attacker. MPTCP itself and its security implications need to be revisited (which is happening in the -bis document; I strongly hope that this is one of the parts which do get fixed). The suggested mitigations 1 and 2 in section 3.1 of the -attacks draft do not help in this scenario, because the additional information can be trivially eavesdropped. Mitigation 3 seems to prevent it, but is not the recommended one. In my understanding, none of the three are part of the actual protocol anyway. Does the mptcp-bis document go towards that mitigation 3, or did it find another way to prevent the described elevation from pervasive passive to off-path active MitM? From my understanding, the recommendation in section 7 does not point towards that (best) mitigation nr. 3, which I find unacceptable as a recommendation for a standards-track-to-be. The draft in its current state does not discuss perpass-style scenarios in the ADD_ADDR attack and their consequences in an adequate manner, and inappropriately classifies ADD_ADDR as a "medium" threat. From a security perspective, I would not find the document satisfactory and would like to see it revised. Attachment: 0x8A39DC66.asc Description: application/pgp-keys Attachment: signature.asc Description: OpenPGP digital signature