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

[Christoph Paasch <[e-mail]>]

Hello Alan,

On 20/07/17 - 16:33:31, Alan Ford 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).

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