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

[Alan Ford <[e-mail]>]

Comments inline...

> On 20 Jul 2017, at 16:20, Christoph Paasch <[e-mail]> wrote:
> 
> 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.

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.

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

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