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

[Costin Raiciu <[e-mail]>]

Christoph,

First, I’d like to say that solving the loadbalancer issue is very important. I have spoken to Microsoft people that said that can’t use MPTCP because it doesn’t work through their loadbalancers.

I have finally had a careful look at your draft. I find the second proposed solution, the one that changes the token derivation algorithm, to be very interesting. I fully support it, and I think we should mandate it is 6824bis, even if this increases the MPTCP version number.

Here at UPB we are actively working on a scalable load balancer for MPTCP - we’ll keep you posted once we have something to show.

Cheers.
Costin




> On 10 Sep 2015, at 17:43, Christoph Paasch <[e-mail]> wrote:
> 
> On 10/09/15 - 12:03:50, Olivier Bonaventure wrote:
>>> 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.
> 
> I was more thinking of it in case we do not modify anything in the
> MPTCP-handshake. In that case, the different loadbalancers will be
> generating the keys independently. The loadbalancers can easily
> make sure that they generate different keys, however because the token is a
> hash of the key, collisions are possible.
> 
> Thus, we would need a way to guarantee uniqueness of the token across the
> loadbalancers.
> 
>> 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
> 
> +1 on TLS
> 
> For IPv6 I'm a bit concerned because we are yet far away from full IPv6
> deployment and IPv4 is proably never going away.
> 
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dpaasch-2Dmptcp-2Dlowoverhead-2D00&d=BQIC-g&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=d1DAUSnnbQyUTC9DUvPR9YgBw1illvfDq55MXrewq0M&s=2Xd614qho-KOJFy_LZtqx000U8div7FG31UhLM9V6WY&e=
>> and
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dpaasch-2Dmptcp-2Dssl-2D00&d=BQIC-g&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=d1DAUSnnbQyUTC9DUvPR9YgBw1illvfDq55MXrewq0M&s=SiCZMS9Xpc2g-z1tPdqDgzwTK2evfjTpi-2OBM4Z9R4&e=
>> 
>> 
>> 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.
> 
> Yes, if the MP_CAPABLE becomes reliable in the third ACK, we can probably
> remove the token from the SYN (although we have to be creative for TFO in
> that case).
> 
>> 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.
> 
> I think this is the best way to go (if the working-group is fine with
> introducing a rather big change to RFC6824bis).
> 
> It frees up space in the handshake, enables MPTCP behind loadbalancers
> (independent of IPv4 or IPv6) and also gives incentives to enable TLS/SSL.
> Additionally to that, it enables low-overhead deployments of MPTCP for
> data-center environments.
> 
> 
> Christoph
> 
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp