Subject: [multipathtcp] AD Review: draft-ietf-mptcp-threat-06

From: Lars Eggert <[email-masked]>
Date: Fri, 17 Dec 2010 14:56:01 +0200

Summary: good to go.

I'll start the IETF last call. Please take the comments below as last-call comments. I will make this last call longer than normal, due to the holiday season.

Lars

INTRODUCTION, paragraph 2:
>            Threat Analysis for Multi-addressed/Multi-path TCP

  Might make sense to align the title with the title of the spec, which
  is "TCP Extensions for Multipath Operation with Multiple Addresses",
  so maybe "Threat Analysis for TCP Extensions for Multipath Operation
  with Multiple Addresses"?

INTRODUCTION, paragraph 5:
>    Multi-path TCP (MPTCP for short) describes the extensions proposed
>    for TCP so that each endpoint of a given TCP connection can use
>    multiple IP addresses to exchange data (instead of a single IP
>    address per endpoint as currently defined).

  Not quite correct: It's not that *each* endpoint can use multiple
  addresses, it's that two endpoints can use multiple *paths*. (You say
  this in the next section, maybe combine?) Also fix this in the
  introduction, which is basically a copy of the abstract.

Section 2., paragraph 1:
>    some form of path selector.  There are multiple options for such path

  s/such path/such a path/

Section 2., paragraph 2:
>    a particular approach, namely MPTCP approaches that rely on the usage

  s/namely MPTCP approaches that rely/namely MPTCP, that relies/

Section 2., paragraph 3:
>    of multiple IP address per endpoint and that use different source-

  s/use/uses/

Section 2., paragraph 4:
>    destination address pairs as a mean to express different paths.  So,
>    in the rest of this note, the MPTCP expression will refer to this
>    Multi-addressed flavour of Multi-path TCP.

  Please cite the spec here.

Section 2., paragraph 5:
>    In this note we perform a threat analysis for MPTCP.  Introducing the
>    support of multiple addresses per endpoint in a single TCP connection
>    may result in additional vulnerabilities.

  ...compared to single-path TCP.

Section 2., paragraph 6:
>    is to help the MPTCP protocol designers to create a MPTCP that is as

  s/to create/create/ and s/a MPTCP/an MPTCP specification/

Section 2., paragraph 7:
>    secure as the current TCP.  It is a non goal of this analysis to help

  s/non goal/non-goal/

Section 3., paragraph 1:
>    There is significant amount of previous work in terms of analysis of

  Nit: s/is significant/is a significant/

Section 3., paragraph 3:
>       is at stake.  In other words, if a binding between two address is

  Nit: s/two address/two addresses/

Section 3., paragraph 8:
>    basis for this analysis, there are a set of characteristics that are

  s/there are a set/there is a set/

Section 5., paragraph 4:
>    possible or not for the attacker to send such packet.  At this stage,

  s/such packet/such a packet/

Section 5., paragraph 5:
>    ACKs for the data sent using a given a given address pair should come

  s/a given a given/a given/

Section 5., paragraph 10:
>    with MPTCP is one where the attacker initiates a a communication with

  s/a a/a/

Section 6.1., paragraph 4:
>       MPTCP connection.  This means that there will be two source of

  s/two source/two sources/

Section 6.2., paragraph 3:
>    There are several type of approaches that provide some protection

  s/several type/several types/

Section 6.2., paragraph 4:
>       subflow and then validate the following subflows by using an keyed

  s/an keyed/a keyed/