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

[Christoph Paasch <[e-mail]>]

On 20/07/17 - 17:05:40, Olivier Bonaventure wrote:
> 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.

+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