Subject: [multipathtcp] Fwd: I-D Action: draft-bagnulo-mptcp-attacks-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 Jul 2013 08:30:25 +0200

Hi,

We have submitted a new draft discussing some residual attacks we
identified in MPTCP spec.

Comments are welcome.

Regards, marcelo

-------- Mensaje original --------

Asunto:

I-D Action: draft-bagnulo-mptcp-attacks-00.txt

Fecha:

Sun, 14 Jul 2013 13:07:37 -0700

De:

[email-masked]

Responder
a:

[email-masked]

Para:

[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : Analysis of MPTCP residual threats and possible fixes
Author(s) : Marcelo Bagnulo
Christoph Paasch
Fernando Gont
Olivier Bonaventure
Costin Raiciu
Filename : draft-bagnulo-mptcp-attacks-00.txt
Pages : 16
Date : 2013-07-14

Abstract:
This documents performs an analysis of the residual threats for MPTCP
and explores possible solutions to them.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bagnulo-mptcp-attacks

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bagnulo-mptcp-attacks-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Alan Ford <[email-masked]>
Date: Wed, 31 Jul 2013 16:00:55 +0100

All,

If we as a WG feel that this is a sufficiently large risk (and the general
feeling I got from the meeting yesterday is that it probably is - although
the probabilities do seem small, the impact of a successful attack is
large), let's look at the practicalities of the solutions. Taking the two
practical options:

Option 1: Include token of receiving host (let's call them B) in ADD_ADDR.
Costs:
* 4 bytes additional
Impact:
* Requires attacker to have seen an MP_JOIN or MP_CAPABLE packet, or guess
a 2^32 number

Option 2: Include HMAC(Key-B, New_IP_Addr)
Costs:
* 8 bytes additional (arbitrarily picked 64-bit truncated HMAC here, like
MP_JOIN, but it could be shorter)
Impact:
* Requires attacker to have seen MP_CAPABLE exchange, or guess as 2^64
number

We would (just!) have space for either option in the remaining TCP option
space. Option 2 seems to have better security.

However, the only thing that worries me about Option 2 is that it means a
middlebox cannot legitimately insert an ADD_ADDR if it has not seen the
original MP_CAPABLE: say it was a middlebox on a secondary subflow only, it
would only know the token. But if it wanted to allow an end host to connect
out to another of its addresses, it would not be able to do this.

Whether that is a legitimate use case I am not sure yet; right now I can't
see it being a huge loss to remove this capability while introducing better
security. But for now, this is still an open issue.

A minor oversight in 6824, too: we also seem not to have cited RFC5961
directly, but rather via the TCP security survey draft. Hopefully the
requirement is nevertheless clear to implementers.

Regards,
Alan

On 16 July 2013 07:30, marcelo bagnulo braun <[email-masked]> wrote:

> -------- Mensaje original --------  Asunto: I-D Action:
> draft-bagnulo-mptcp-attacks-00.txt  Fecha: Sun, 14 Jul 2013 13:07:37 -0700  De:
> [email-masked]  Responder a: [email-masked]  Para:
> [email-masked]
>
> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-bagnulo-mptcp-attacks
>
> There's also a htmlized version available at:http://tools.ietf.org/html/draft-bagnulo-mptcp-attacks-00
>
>
> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>
> I-D-Announce mailing [email-masked]://www.ietf.org/mailman/listinfo/i-d-announce
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>