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

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 01 Nov 2010 17:52:23 +0100

El 31/10/10 18:10, SCHARF, Michael escribió:
>
> 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.
>

Ok, i will add some text about this
>
>
> - 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.
>
mmm, i think this is covered by the following statement:

    However, if the
    attacker, before redirecting the traffic has managed to increase the
    window size considerably, the flight size could be enough to impose a
    significant amount of traffic to the Target node.

I mean, the attacker can grow the window before redirecting the flow to 
the target
>
> - 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?
>
But this applies equally to regular TCP, correct?
I mean, this is not a new threat introduced by MPTCP, correct?

Regards, marcelo

>
> 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
>
> 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.
>
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "SCHARF, Michael" <[email-masked]>
Date: Mon, 1 Nov 2010 18:38:20 +0100

>     significant amount of traffic to the Target node.
 
Well, to me this statement is not very clear. The window size "before
redirecting the traffic" does not matter much if the sender has to go
through Slow-Start on a new path. 

To my understanding, if Slow-Start is used on a new path, there is not
much additional flooding vulnerability compared today's TCP, as the
attacker has to fake a full sequence of (subflow-level) ACKs. This is
why I'd suggest a clearer statement that Slow-Start may actually help to
prevent flooding attacks.
 
> I mean, the attacker can grow the window before redirecting 
> the flow to the target
> >

If the attacker provides a large number of additional addresses for one
MPTCP connection, and if the corresponding peer immediately tries to
open subflows to all of them, this may result in a bunch of SYNs. In
other words, an the attacker can trigger many SYNs with a single
message. With regular TCP, this is not possible. Or do I miss something?

IMHO a peer should never try to open many subflows in parallel to
addresses provided by the peer, in order to prevent SYN flooding
attacks.

Michael

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 01 Nov 2010 19:50:54 +0100

> prevent flooding attacks.
right, i agree.
I will add some text about that

> addresses provided by the peer, in order to prevent SYN flooding
the attack you are describing is not the attack launching a TCP SYN 
attack toward the target, but the attakcer using a MPTCP peer to launch 
a SYN attakc towards another target. But that acutally falls in the same 
category as the regular flooding attack, i thin. I mean, the target 
wouldn't accept the syns as they do not belong to an existing 
connection, right?

Regards, marcelo

---

From: "SCHARF, Michael" <[email-masked]>
Date: Mon, 1 Nov 2010 20:12:29 +0100

> > If the attacker provides a large number of additional addresses for 
> > one MPTCP connection, and if the corresponding peer 
> immediately tries 
> > to open subflows to all of them, this may result in a bunch 
> of SYNs. 
> > In other words, an the attacker can trigger many SYNs with a single 
> the attack you are describing is not the attack launching a 
> TCP SYN attack toward the target, but the attakcer using a 
> MPTCP peer to launch a SYN attakc towards another target. But 
> that acutally falls in the same category as the regular 
> flooding attack, i thin. I mean, the target wouldn't accept 
> the syns as they do not belong to an existing connection, right?

Yes, it is a flooding attack as well. But it leverages a different
mechanism, i. e., a long list of candidate IP addresses, of potentially
more than one target. The scenario is thus slightly different.

Right, the target(s) would not accept these SYNs, i. e., it is a pure
SYN flooding attack that can worked around with SYN cookies at the
targets.

Still, due to the potentially large amplification factor of the SYN
flooding, it might be relevant to (briefly) mention this particular
thread, too.

Michael

---

From: <[email-masked]>
Date: Mon, 15 Nov 2010 09:18:40 +0000

Thanks for the successful conclusion to the WGLC. We have some minor comments that Marcelo will solve and then we will send it into the IESG process.

Phil & Yoshifumi.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 12 October 2010 18:56
To: [email-masked]
Subject: [multipathtcp] WG Last call for http://tools.ietf.org/html/draft-ietf-mptcp-threat-03

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.