Subject: [multipathtcp] WG Last call for http://tools.ietf.org/html/draft-ietf-mptcp-threat-03

From: <[email-masked]>
Date: Tue, 12 Oct 2010 18:55:48 +0100

We've had 3 good reviews & think Marcelo has dealt with all comments - thanks very much to Marcelo, Randall, Michael & Andy.

So time for a WG last call on the doc. Please send comments by Friday 5th Nov. (We will run a bit longer than 2 weeks, since people are working on I-Ds - & also we hope to start last call on architecture draft very soon) . This timescale means that we can make time in Beijing for any issues arising that need face-to-face time.

Thanks
Phil & Yoshifumi.

---

From: "SCHARF, Michael" <[email-masked]>
Date: Sun, 31 Oct 2010 18:10:22 +0100

Dear all,

some additional comments:

- A reader not familiar with the history of previous protocol names
  might be confused by mixing "multi-addressed" and "multi-path" in
  the title and elsewhere (in particular since the former term is
  frequently also spelled "multi-addresses"). I think that the reason
  for using both terms could be better explained, e. g., in the
  abstract.

- Section 5 does not specifically mention the implications of using
  Slow-Start on new subflows, even if this seems to be relevant for
  such flooding attacks. This is of course a protocol design question,
  but from a congestion control perspective, there are actually good
  reasons to use Slow-Start on a new subflow. IMHO the Slow-Start,
  if used, helps to reduce the probability of a successful flooding
  attack, and it could be worth mentioning this.

- Also related to Section 5: Unless I am wrong, even with a 3-way
  handshake as reachability test, a kind of simple SYN flooding attack
  on a target is still possible, depending on how frequently an endsystem
  tries to establish new subflows. Maybe you can comment on that?

Editorial stuff:

- I think that the document could be made more readable by structuring
  some of the sections in subsections, and maybe also reorganizing
  some paragraphs. For example, Section 4, named "Basic MPTCP.", could
  separate the assumptions and the security analysis of explicit
  vs. implicit mode into separate subsections. Similarly, the text in
  section 6 could probably be split into smaller pieces, e. g., an
  extra section for the Man in the Middle attack.

- Random nits:

  p. 2: "a MPTCP" -> "an MPTCP"

  p. 2: "single path TCP" -> "regular TCP"?

  p. 2: "on-path attacker" -> "an on-path attacker"

  p. 3: Broken format/indenting? (also elsewhere)

  p. 4: "port" -> "port numbers"

  p. 13: "another" -> "Another"

  p. 13: "Man-in-the-middle" spelled inconsistently

  p. 14: "attacks," -> "attacks."

Best regards

Michael

-----Ursprüngliche Nachricht-----
Von: [email-masked] im Auftrag von [email-masked]
Gesendet: Di 12.10.2010 19:55
An: [email-masked]
Betreff: [multipathtcp] WG Last call for http://tools.ietf.org/html/draft-ietf-mptcp-threat-03

Thanks
Phil & Yoshifumi.