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

[Olivier Bonaventure <[e-mail]>]

Hello,

>>                 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.
>>
>>
>>             I think adding 'B' bit in ADD_ADDR has been proposed to be
>>             added in the bis draft.
>>             I have seen a few supports while haven't seen any
>>             oppositions.
>>             Do we need more discussions on this?
> 
>             Actually on further reflection (i.e. Christoph and Olivier
>             reminding me offline), this would be unnecessary, since
>             MP_JOIN has a ‘B’ bit so it is not required in ADD_ADDR.
> 
>             Given this I can see no reason to have the Address ID in
>             MP_PRIO and feel we can remove it.
> 
>             (The proposal for a bit in ADD_ADDR was, I believe, as a “do
>             not even attempt to establish to this address unless all
>             other subflows fail - which is different to the ‘B’
>             semantics in MP_PRIO and MP_JOIN)
> 
>         Yes, I thought it's a valid use case.
>         If we remove addr id from MP_PRIO, I think we will always need
>         to establish a subflow to make it backup.
> 
> 
>     That has always been the case - MP_PRIO only affects running
>     subflows. With Address ID it could have affected policy on subflows
>     that were later established, but would not affect subflow
>     establishment policy.
> 
>     The proposal to signal a break-before-make backup flag has been
>     suggested but has not received sufficient traction to be adopted.
> 
> 
> Right. But, I am wondering if we might want to think about it again just 
> in case.
> 
> Let's say a server has two address S1, S2 while the client is behind FW. 
> As the client is behind firewall, the server uses ADD_ADDR to send the 
> info for S2, but it want it to be used as a backup.
> 
> In this case, if MP_PRIO has addr id field, the server is able to set 
> the addr as a backup.
> But, if MP_PRIO doesn't have addr id, all the server can do is to wait 
> until the client establishes the connection with S2.

If we want to associate a backup status to an address, which could have 
valid use cases, then I'd suggest to use one of the spare bits of the 
ADD_ADDR option for this.

As mentioned earlier, the semantics of the backup bit in the ADD_ADDR 
differs from the semantics of the backup bit in MP_JOIN/MP_PRIO.

In MP_JOIN, it means "don't use this subflow is non-backup subflows are 
active".

In ADD_ADDR, it would mean "don't use this address to establish a 
subflow if subflows to non-backup addresses are still active"

Having both could make sense


Olivier