Re: [multipathtcp] Fwd: New Version Notification for draft-paasch-mptcp-loadbalancer-00.txt

[Olivier Bonaventure <[e-mail]>]

Christoph,
>
> I really like this idea.
>
> Very often, IP-in-IP encapsulation is done from the loadbalancer to the
> server. Thus, the key could even be placed in an IP-option. As everything is
> local to the data-center there shouldn't be an issue with adding a new
> IP-option.
>
>
> But as you point out in the other mail, when multiple loadbalancers are
> being used we have an issue again. Maybe, there is a way to generate the key
> in such a way that we can guarantee uniqueness across the loadbalancers?
>

This is one possibility, but I'm not sure that we need to specify that 
unless we want load balancers from different vendors to cooperate.

The load balancing problem could be an opportunity to rethink the 
three-way handshake used by Multipath TCP so that it can work well with 
tomorrow's target protocol stack, likely HTTP/2 / TLS / MPTCP / IPv6

To deal with security issues, we have included keys in clear inside the 
SYN and SYN+ACK segments. Then the limited TCP option space has forced 
us to use hash functions to compute the IDSN and the tokens. Using a 
hash to compute the tokens creates difficulties when one wants to 
coordinate token allocations between a set of load balancers.

I wonder whether we should not explore again the work documented in
https://tools.ietf.org/html/draft-paasch-mptcp-lowoverhead-00
and
https://tools.ietf.org/html/draft-paasch-mptcp-ssl-00


Let us first ignore the security issues and make the toke explicit in 
the handshake.


                Host A                               Host B
               ----------                           ----------
               Address A1                           Address B1
               ----------                           ----------
                   |                                    |
                   |  SYN+MP_CAPABLE(Token-A)           |
                   |----------------------------------->|
                   |                                    |
                   |SYN/ACK+MP_CAPABLE(Token-B)         |
                   |<-----------------------------------|
                   |                                    |
                   |  ACK+MP_CAPABLE(Token-A, Token-B)  |
                   |----------------------------------->|


It might also be possible to remove Token-A from the initial SYN since 
there is little benefit from the server to know this token at this 
stage. The IDSN could be derived as TokenA|TokenB in one direction and 
TokenB|TokenA in the other or better a hash of these values.

The benefit of this approach is that the Token chosen by the server is 
not explicitelt sent in the SYN/ACK. Load balancers can coordinate to 
have one pool of tokens for each LB and pass them to the servers.

The next step is to authenticate the establishment of subflows. The 
best approach with HTTP/2 / TLS  is clearly to derive MPTCP keys from 
the master TLS key and use them to authenticate the subflows with the 
HMAC mechanism already defined. With this, we leverage the security 
properties of TLS and do not anymore depend on "keys" that are sent in 
clear in the SYN segments and consume precious option space. Of course, 
a drawback of this approach is that you cannot create a subflow until 
the end of the TLS handshake, but TLS is moving towards faster handshakes.


Olivier