Subject: [multipathtcp] MPTCP backup flag attack via MP_PRIO message

From: "Zhiyun Qian" <[email-masked]>
Date: Thu, 20 Jul 2017 00:28:52 -0700

Dear all,

We are a group of researchers (cc:ed on the email) who recently
discovered a security flaw in the MP_PRIO messge that allows a
man-in-the-middle attacker on a single path to divert all traffic to
its own path, effectively hijacking the entire MPTCP connection. Below
we describe the problem in brief (more details will be found in our
upcoming ICNP paper. We also hope to submit an Internet draft soon).
We thank Olivier Bonaventure for his valuable feedback.

---------------------------------------------------------------

MPTCP supports using sub-connections as backup – i.e., using a
sub-connection to send data only if there is no other sub-connection
available. Specifically, an MPTCP host can send a request to the other
host to set any sub-connection as a backup by using the MPTCP MP_PRIO
option. Hosts can request change in the priority to use a
subconnection as regular or backup.  To set a sub-connection as
backup, a host can request a change in the sub-connection priority by
sending MPTCP MP_PRIO option to the other host with the corresponding
address identifier. The key property of MP_PRIO messages is that they
can be sent on any sub-connection. The reason is that if a
sub-connection is already congested, it may not be possible to deliver
the message to pause itself. After receiving such a control packet,
the sender will stop sending data and the corresponding
sub-connection’s throughput will drop to zero.

Unfortunately, unlike MP_JOIN, such a MP_PRIO option has no
authentication required by the specification whatsoever, allowing an
attacker controlling only one path to set any sub-connection as backup
and launch traffic divergence and connection hijack attacks. The
backup flag vulnerability allows an attacker to divert traffic among
MPTCP sub-connections. An attacker can offload traffic from the
eavesdropped sub-connection to other MPTCP sub-connections by sending
forged packets with the MP_PRIO option to set the eavesdropped
sub-connection as a backup. An attacker can also onload traffic from
non-eavesdropped sub-connections to the eavesdropped sub-connection by
sending forged packets with the MP_PRIO option to set all other
sub-connections as backup. This attack is similar to connection hijack
attack, where an attacker diverts all the traffic to pass through the
sub-connection on the eavesdropped path.

Connection Hijack Example:

Consider a scenario where two sub-connections of an MPTCP connection
pass through paths p1 and p2. An attacker can hijack the
non-eavesdropped subconnection on p2 by dynamically changing the
priority of a sub-connection and declaring it as backup.

To launch this attack an attacker only needs to know the address
identifier of the host , which can be obtained by eavesdropping other
paths or easily guessed as they are set incrementally in current Linux
implementation of MPTCP. Since the identifier has only 8 bits, it can
even be brute forced. To set a non-eavesdropped sub-connection as
backup between hosts A and B, an attacker can request a change in the
sub-connection priority by sending MPTCP MP_PRIO option to host B with
the address identifier of host A. Since by design the MP_PRIO messages
can be sent on any sub-connection, the attacker eavesdropping on any
path capable of sending such a forged backup message can pause any
other path. Note that a backup MPTCP sub-connection may still be used
for data transmission later, which can be detected by the attacker by
observing the overall MPTCP throughput.

Effectively, this attack degrades an MPTCP connection to a regular TCP
connection as all traffic will be routed through the
attacker-controlled path. We argue that this vulnerability makes MPTCP
less secure than TCP, because the entire MPTCP connection can be
compromised (fully controlled by an attacker) as long as any one of
the communication paths is compromised. Unfortunately, MPTCP
specification does not include any authentication mechanism whatsoever
regarding the MP_PRIO message.

We discuss several solutions in a forthcoming paper [ICNP2017], but a
simple approach to cope with this attack would be to reconsider the
utilisation of the address identifier in the MP_PRIO option. This
option allows a host to set/change the priority of all the subflows
associated to a given address identifier on another subflow. It could
have use cases, such as sending MP_PRIO over a WiFi subflow to put the
cellular subflow in backup mode without sending a packet over the
cellular interface, but this looks like an edge case. Looking at the
attack that we have identified, the working group should evaluate the
removal of the address identifier in rfc6824bis. If the MP_PRIO option
does not include an address identifier, then it becomes impossible for
an attacker who is on-path of a given subflow to change the priority
of the other subflows.

Best,
-Zhiyun

---

From: Alan Ford <[email-masked]>
Date: Thu, 20 Jul 2017 16:00:25 +0100

Hi Zhiyun,

Please bear in mind that the goal of MPTCP with respect to security, as discussed in the original architectural design in RFC6182, is to provide a security model no worse than TCP. So whilst this attack would be possible, it can only be done by an on-path attacker, and if succeeded would allow the on-path attacker to intercept all traffic. Which would be the same for a single-path TCP connection on the same path.

As a side point, the same kind of attack could be launched via REMOVE_ADDR messages, but this would not succeed since this is specified with some protection - ensuring the subflow is really unavailable through the use of TCP keepalive signals. This same protection cannot be used against the MP_PRIO since the referenced subflow is not unavailable.

If the WG considered this risk worth addressing, we could look at adding a nonce + signature to MP_PRIO.

Regards,
Alan

> On 20 Jul 2017, at 08:28, Zhiyun Qian <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 20 Jul 2017 17:05:40 +0200

Alan,
> If the WG considered this risk worth addressing, we could look at adding a nonce + signature to MP_PRIO.

Since the attacker is on path, this does not help if the attacker is on 
the first path.

> an attacker who is on-path of a given subflow to change the priority

Remove the address identifier from the MP_PRIO seems a safe solution to 
me. I do not see a benefit in sending MP_PRIO on another subflow than 
the one that you want to affect.

Olivier

---

From: Christoph Paasch <[email-masked]>
Date: Thu, 20 Jul 2017 17:20:58 +0200

On 20/07/17 - 17:05:40, Olivier Bonaventure wrote:
> Since the attacker is on path, this does not help if the attacker is on the
> first path.
> 
> > 
> Remove the address identifier from the MP_PRIO seems a safe solution to me.
> I do not see a benefit in sending MP_PRIO on another subflow than the one
> that you want to affect.

+1

As far as I know, there is no implementation that relies on the address-ID
in the MP_PRIO to signal the priorities.

Christoph

---

From: Alan Ford <[email-masked]>
Date: Thu, 20 Jul 2017 16:33:31 +0100

Comments inline...

> On 20 Jul 2017, at 16:20, Christoph Paasch <[email-masked]> wrote:
> 

That scenario has always been out of scope. If an attacker has observed the initial exchange, all bets are off, and we are only as secure as single-path TCP.

> in the MP_PRIO to signal the priorities.

So the main reason for this was to permit the signalling of backup for a subflow which was also signalled via ADD_ADDR. ADD_ADDR does not have a ‘B’ bit in it, so the priority would be signalled separately.

We could add the prio bit to ADD_ADDR to resolve this issue. However, this limits extensibility in MP_PRIO e.g. with other signals which have been suggested in the past ("backup but do not open”, use for differing traffic types, etc).

Regards,
Alan

---

From: Zhiyun Qian <[email-masked]>
Date: Thu, 20 Jul 2017 08:53:10 -0700

Hi Alan,

I'd argue this vulnerability does make MPTCP worse than TCP in the
sense of increased risk or attack surface:

The key problem is that this vulnerability allows an attacker on *any*
path to direct all traffic in other paths to the path it sits on. In
contrast, for TCP the attacker has to sit on *a specific* path to be
able to observe and control all traffic.

-Zhiyun

---

From: Zhiyun Qian <[email-masked]>
Date: Thu, 20 Jul 2017 08:54:54 -0700

I thought MP_PRIO message may theoretically be useful if subflow A is
congested already so it needs to use subflow B to signal the fact that
subflow A will become a backup.

Best,
-Zhiyun

On Thu, Jul 20, 2017 at 8:33 AM, Alan Ford <[email-masked]> wrote:
> Please bear in mind that the goal of MPTCP with respect to security, as
> discussed in the original architectural design in RFC6182, is to provide a
> security model no worse than TCP. So whilst this attack would be possible,
> it can only be done by an on-path attacker, and if succeeded would allow the
> on-path attacker to intercept all traffic. Which would be the same for a
> single-path TCP connection on the same path.
>
> As a side point, the same kind of attack could be launched via REMOVE_ADDR
> messages, but this would not succeed since this is specified with some
> protection - ensuring the subflow is really unavailable through the use of
> TCP keepalive signals. This same protection cannot be used against the
> MP_PRIO since the referenced subflow is not unavailable.
>
> That scenario has always been out of scope. If an attacker has observed the
> initial exchange, all bets are off, and we are only as secure as single-path
> TCP.
>
> So the main reason for this was to permit the signalling of backup for a
> subflow which was also signalled via ADD_ADDR. ADD_ADDR does not have a ‘B’
> bit in it, so the priority would be signalled separately.
>
> We could add the prio bit to ADD_ADDR to resolve this issue. However, this
> limits extensibility in MP_PRIO e.g. with other signals which have been
> suggested in the past ("backup but do not open”, use for differing traffic
> types, etc).
>
> Regards,
> Alan
>
>

---

From: Christoph Paasch <[email-masked]>
Date: Thu, 20 Jul 2017 18:25:31 +0200

Hello Alan,

> We could add the prio bit to ADD_ADDR to resolve this issue. However, this limits extensibility in MP_PRIO e.g. with other signals which have been suggested in the past ("backup but do not open”, u…

I think it's ok to add the prio-bit to the ADD_ADDR. I'm not sure though to
what extend it would limit the extensibility of MP_PRIO.

Christoph

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 20 Jul 2017 14:22:37 -0700

Hi Alan,

> bit in it, so the priority would be signalled separately.

I think adding 'B' bit in ADD_ADDR has been proposed to be added in the bis
draft.
I have seen a few supports while haven't seen any oppositions.
Do we need more discussions on this?
--
Yoshi

---

From: Alan Ford <[email-masked]>
Date: Fri, 21 Jul 2017 08:45:03 +0100

Hi Yoshi,

> On 20 Jul 2017, at 22:22, Yoshifumi Nishida <[email-masked]> wrote:
> 
> On Thu, Jul 20, 2017 at 8:33 AM, Alan Ford <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I think adding 'B' bit in ADD_ADDR has been proposed to be added in the bis draft. 

Actually on further reflection (i.e. Christoph and Olivier reminding me offline), this would be unnecessary, since MP_JOIN has a ‘B’ bit so it is not required in ADD_ADDR.

Given this I can see no reason to have the Address ID in MP_PRIO and feel we can remove it.

(The proposal for a bit in ADD_ADDR was, I believe, as a “do not even attempt to establish to this address unless all other subflows fail - which is different to the ‘B’ semantics in MP_PRIO and MP_JOIN)

Regards,
Alan

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 21 Jul 2017 13:37:46 -0700

Hi Alan,

On Fri, Jul 21, 2017 at 12:45 AM, Alan Ford <[email-masked]> wrote:

> Actually on further reflection (i.e. Christoph and Olivier reminding me
> offline), this would be unnecessary, since MP_JOIN has a ‘B’ bit so it is
> not required in ADD_ADDR.
>
> (The proposal for a bit in ADD_ADDR was, I believe, as a “do not even
> attempt to establish to this address unless all other subflows fail - which
> is different to the ‘B’ semantics in MP_PRIO and MP_JOIN)
>

Yes, I thought it's a valid use case.
If we remove addr id from MP_PRIO, I think we will always need to establish
a subflow to make it backup.
--
Yoshi

---

From: Alan Ford <[email-masked]>
Date: Sun, 23 Jul 2017 13:04:11 +0000

Hi Yoshi,

On Fri, 21 Jul 2017 at 22:37, Yoshifumi Nishida <[email-masked]>
wrote:

> If we remove addr id from MP_PRIO, I think we will always need to
> establish a subflow to make it backup.
>

That has always been the case - MP_PRIO only affects running subflows. With
Address ID it could have affected policy on subflows that were later
established, but would not affect subflow establishment policy.

The proposal to signal a break-before-make backup flag has been suggested
but has not received sufficient traction to be adopted.

Regards,
Alan

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 23 Jul 2017 23:29:31 -0700

Hi Alan,

On Sun, Jul 23, 2017 at 6:04 AM, Alan Ford <[email-masked]> wrote:

>>>> So the main reason for this was to permit the signalling of backup for
>>>> a subflow which was also signalled via ADD_ADDR. ADD_ADDR does not have a
>>>> ‘B’ bit in it, so the priority would be signalled separately.
>>>>
>>>
> That has always been the case - MP_PRIO only affects running subflows.
> With Address ID it could have affected policy on subflows that were later

Right. But, I am wondering if we might want to think about it again just in
case.

Let's say a server has two address S1, S2 while the client is behind FW. As
the client is behind firewall, the server uses ADD_ADDR to send the info
for S2, but it want it to be used as a backup.

In this case, if MP_PRIO has addr id field, the server is able to set the
addr as a backup.
But, if MP_PRIO doesn't have addr id, all the server can do is to wait
until the client establishes the connection with S2.
--
Yoshi

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 24 Jul 2017 09:36:44 +0200

Hello,

>>                 So the main reason for this was to permit the
>>                 signalling of backup for a subflow which was also
>>                 signalled via ADD_ADDR. ADD_ADDR does not have a ‘B’
>             Actually on further reflection (i.e. Christoph and Olivier
>             reminding me offline), this would be unnecessary, since
>             MP_JOIN has a ‘B’ bit so it is not required in ADD_ADDR.
> 
>             (The proposal for a bit in ADD_ADDR was, I believe, as a “do
>             not even attempt to establish to this address unless all
>             other subflows fail - which is different to the ‘B’
>             semantics in MP_PRIO and MP_JOIN)
> 
>         If we remove addr id from MP_PRIO, I think we will always need
>         to establish a subflow to make it backup.
> 
> 
>     That has always been the case - MP_PRIO only affects running
>     subflows. With Address ID it could have affected policy on subflows
>     that were later established, but would not affect subflow
>     establishment policy.
> 
>     The proposal to signal a break-before-make backup flag has been
>     suggested but has not received sufficient traction to be adopted.
> 
> 
> Right. But, I am wondering if we might want to think about it again just 
> in case.
> 
> Let's say a server has two address S1, S2 while the client is behind FW. 
> As the client is behind firewall, the server uses ADD_ADDR to send the 
> info for S2, but it want it to be used as a backup.
> 
> In this case, if MP_PRIO has addr id field, the server is able to set 
> the addr as a backup.

If we want to associate a backup status to an address, which could have 
valid use cases, then I'd suggest to use one of the spare bits of the 
ADD_ADDR option for this.

As mentioned earlier, the semantics of the backup bit in the ADD_ADDR 
differs from the semantics of the backup bit in MP_JOIN/MP_PRIO.

In MP_JOIN, it means "don't use this subflow is non-backup subflows are 
active".

In ADD_ADDR, it would mean "don't use this address to establish a 
subflow if subflows to non-backup addresses are still active"

Having both could make sense

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 28 Jul 2017 18:20:40 -0700

On Mon, Jul 24, 2017 at 12:36 AM, Olivier Bonaventure <
[email-masked]> wrote:
>> As the client is behind firewall, the server uses ADD_ADDR to send the info
> In ADD_ADDR, it would mean "don't use this address to establish a subflow
> if subflows to non-backup addresses are still active"
>

It makes sense to me. I personally think supporting only one semantic looks
unbalanced design unless we are not very interested in setting backup
status..
--
Yoshi