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

[Zhiyun Qian <[e-mail]>]

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 <[e-mail]> wrote:
> 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
>
>