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

[Olivier Bonaventure <[e-mail]>]

Alan,
> 
> 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.

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

> 
> 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.

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