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

[Yoshifumi Nishida <[e-mail]>]

On Mon, Jul 24, 2017 at 12:36 AM, Olivier Bonaventure <
[e-mail]> wrote:
>
>
>>     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


It makes sense to me. I personally think supporting only one semantic looks
unbalanced design unless we are not very interested in setting backup
status..
--
Yoshi