Subject: Re: [multipathtcp] MPTCP connection termination

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 03 Jan 2012 13:04:46 +0100

Alan,
> 
> Apologies for the delay in catching up with these recent developments...
> 
> A few thoughts:
> 
> I don't particularly like the term MPTCP_RST or DATA_RST, since this is not a direct analogy to the TCP RST; rather, it is almost new functionality - a "fast close" mechanism, so it may be better termed DATA_CLOSE or similar.

The name can be changed, no problem for me.

> What is the reason for the reuse of the key in this context? Is there significant additional security?

It shows that the segment containing the CLOSE option was generated by
one of the endpoints (or at worse someone that saw the initial SYN
exchange).

Without this information, an attacker who sees segments on a WiFi
interface could replay a modified segment to cause the entire MPTCP
connection to be reset (and not only the WiFi segment).

I think that adding some information to the segment that causes an
entire MPTCP connection to be reset is important to avoid DoS attacks.

> Do we really need it as a new option? Could we not just do it as an extra flag in the DSS? I thought that was the original proposal and I didn't see a rationale for a change. This would have the benefit that it requires no additional options, and could be included with data (it would seem unlikely to be able to fit an option with a key as well as a DSS option on a data packet).

No, an extra flag in the DSS is not sufficient because an attacker could
replay a DSS that it sees and change this bit to cause the entire MPTCP
connection to be reset.

We could reuse the MP_CAPABLE option with a reserved bit, but then
firewalls would have to process this option in any segment.

> In summary: I think the proposed mechanism below will cover most standard needs for this option, and any corner cases will be handled by normal session expiry. I think, however, that it should be implemented simply as a flag on the DSS option.

Using the DSS introduces a risk of DoS attack. Consider a smartphone
that uses 3G and WiFi and perhaps open MPTCP connections over 3G due to
security. If DSS is used to close the MPTCP connection, then an attacker
can observe a DSS on the WiFi interface and replay this DSS option to
close the entire MPTCP connection. We should not allow this kind of
attack with MPTCP.

Olivier
-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 3 Jan 2012 12:19:44 -0600

Alan,

To add to Olivier's DoS argument:

MPTCP should not be more vulnerable to DoS than TCP. For TCP, a DoS principally requires an on-path attacker. If multiple paths are supported (as in MPTCP), the likelihood for an attacker to be on at least one of these paths grows with the number of independent paths. The DoS therefore becomes easier unless you require that information pertaining to one specific path is inserted into the RST message. Obviously, the initial key does this job since it was exchanged on the initial path only.

Happy New Year!
Georg

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: Tuesday, January 03, 2012 7:05 AM
To: Alan Ford
Cc: Hampel, K Georg (K Georg); multipathtcp
Subject: Re: [multipathtcp] MPTCP connection termination

Alan,

Olivier