Last Call Review of draft-ietf-mptcp-attacks-02
review-ietf-mptcp-attacks-02-opsdir-lc-winter-2014-12-01-00

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