Skip to main content

Last Call Review of draft-ietf-mptcp-attacks-02
review-ietf-mptcp-attacks-02-secdir-lc-hallam-baker-2014-10-30-00

Request Review of draft-ietf-mptcp-attacks
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-10-27
Requested 2014-10-16
Authors Marcelo Bagnulo , Christoph Paasch , Fernando Gont , Olivier Bonaventure , Costin Raiciu
I-D last updated 2014-10-30
Completed reviews Genart Last Call review of -02 by Roni Even (diff)
Secdir Last Call review of -02 by Phillip Hallam-Baker (diff)
Opsdir Last Call review of -02 by Stefan Winter (diff)
Assignment Reviewer Phillip Hallam-Baker
State Completed
Request Last Call review on draft-ietf-mptcp-attacks by Security Area Directorate Assigned
Reviewed revision 02 (document currently at 04)
Result Has issues
Completed 2014-10-30
review-ietf-mptcp-attacks-02-secdir-lc-hallam-baker-2014-10-30-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.

Top level: this is a core security document and requires detailed review by the
security area ADs.

Given the time constraints and the fact that this is a document describing
security options for an experimental protocol, I have not considered the
attacks or possible solutions in detail yet.

One general point is that the security model should explain what is considered
to be a security failure with a little more precision. Since this is a
transport layer protocol that does transport, end-to-end confidentiality and
integrity protections are more properly considered in an above transport/below
application layer protocol such as TLS.

The attacks that would be very damaging to multipath are attacks that disrupt
the channel in ways that the end-to-end component can't recover from.

Some nits:

General,

HMAC is frequently used where MAC is the correct term of art. HMAC is one
construction of a MAC based on a hash function. This is quite likely not the
optimum technique for a protocol at this layer where AES acceleration hardware
is usually available and SHA-2/3 hardware is not. Moreover the MAC approaches
are much more efficient even in software as they can be streamed.

Section 1:

   o  Off-path attacker.  This is an attacker that does not need to be
      located in any of the paths of the MPTCP session at any point in
      time during the lifetime of the MPTCP session.  This means that
      the Off-path attacker cannot eavesdrop any of the packets of the
      MPTCP session.

Having singled out the type of attacks that can't be made, the attacks that can
should be mentioned as well. Or better still, state that the attacks are
limited to active attacks.

Since the attack classification is referenced in the attacker classification,
better to describe the attacks first.