Re: [multipathtcp] Submitted drafts

[Christoph Paasch <[e-mail]>]

Hello,

On 10/07/15 - 22:57:05, Olivier Bonaventure wrote:
> >>>>* https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr-
> >>>>00.txt
> >>
> >>This draft includes a slight modification of the handling of the address
> >>identifier for the initial subflow. Comments from other implementors would
> >>be useful on this draft.
> >
> >I agree with section 2.1 that having a different address-ID for the
> >initial subflow is very cumbersome. An implementation has to store the local
> >address-id's within the state-machine of each subflow. It would be much
> >easier if we could have a fully global address-table.
> >
> >However, I'm not sure whether it is good to solve it through an empty
> >ADD_ADDR-option. Because, the option is not sent reliably. Even if it gets
> >combined with data, we have an issue with unidirectional streams. And
> >communicating this ADD_ADDR-option reliably to the peer is here in this case
> >even more important than for the "regular" ADD_ADDR option.
> >
> >It would be better if we could put the address-ID inside the MP_CAPABLE.
> >Maybe we can use 8 bits of the key?
> 
> Then the entropy for the key is lower because it is reduced to 56 bits.
> 
> >
> >(also, a little nit: Adding the IPVer within this ADD_ADDR-option is not
> >necessary and will bring issues in NAT64-environments).
> 
> Agreed.
> 
> An alternative is to use the same approach as in
> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-option-00.txt
> 
> to make ADD_ADDR reliable
> 
> We can remove the IPVer from ADD_ADDR2 that AFAIK nobody has implemented and
> replace it with a set of flags.
> 
>                           1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +---------------+---------------+-------+-------+---------------+
>       |     Kind      |     Length    |Subtype| ABCD  |  Address ID   |
>       +---------------+---------------+-------+-------+---------------+
>       |          Address (IPv4 - 4 octets / IPv6 - 16 octets)         |
>       +-------------------------------+-------------------------------+
>       |   Port (2 octets, optional)   |                               |
>       +-------------------------------+                               |
>       |                      Truncated HMAC (8 octets)                |
>       |                               +-------------------------------+
>       |                               |
>       +-------------------------------+
> 
> 
> 
> For example, the A flag could be set to zero when a host announces a new
> address. The host that receives an ADD_ADDR2 with the A flag set to zero
> must set the A flag to one and  return it to acknowledge it.
> 
> A host should retransmit the ADD_ADDR2 option up to n times if it wants to
> ensure that the ADD_ADDR2 option is delivered reliably.

Yes, I think it would be good to have such a reliable ADD_ADDR2 exchange.

> This would work for the ADD_ADDR2 option that does not contain any address
> and has thus a total length of 32 bits.

Concerning the address-ID of the initial subflow, I am not sure whether it
is worth it to replace the complexity in the implementations of handling the
implicit zero address-ID, with a reliable empty ADD_ADDR-exchange (which
will also add complexity of its own).

If we could add the address-ID in the MP_CAPABLE it would be great (as this
will simplify a lot), but I understand that we do not want to lose
the entropy of the 64 bits.



In general, if the MP_CAPABLE could transport all the information that is
relevant for this subflow (address-ID and backup-bit), would be great.
Because, as of today, if a stack sends a SYN+MP_CAPABLE on a subflow that is
actually meant to operate as a "backup" subflow (as soon as another subflow with
higher priority can be established), a stack has to send an MP_PRIO
immediately after the 3-way handshake. The reliability of the MP_CAPABLE in
the SYN could actually get exploited to send such information immediately
(as is already done in the MP_JOIN).

Considering that the keys are already sent in plaintext, maybe the loss of
entropy is not such a big deal?



Cheers,
Christoph