Re: [multipathtcp] Consensus call on potential MPTCP proxy work

[Joe Touch <[e-mail]>]

On 4/24/2017 8:03 AM, [e-mail] wrote:
> Re-,
>
> Do you consider a NAT implementation as part of your first category or the second one?
A NAT is part of the second one. You'll notice that there are no
IETF-endorsed NAT solutions - only protocols to talk directly to NATs or
methods to overcome what NATs do.

> BTW, the mptcp proxy documents do only describe the external behavior. No implementation-specific assumptions/details are included. 
When you require the MPTCP SYN to be issued before the SYN-ACK is sent
to the originating client, that is specifying split-TCP behavior that
the IETF has never endorsed.

The same is true when you try to reinvent ways to interpret SYN data
before the MPTCP 3WHS completes - reinventing TFO without TFO's protections.

Joe

>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Joe Touch [mailto:[e-mail]]
>> Envoyé : lundi 24 avril 2017 16:49
>> À : BOUCADAIR Mohamed IMT/OLN
>> Cc : [e-mail]; [e-mail]
>> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work
>>
>> Med,
>>
>> A proxy can operate at the conventional socket layer and would not have or
>> need direct access to SYN segments. Any information needed to reconstitute
>> the SYN at the upstream proxy could be retrieved in other ways.
>>
>> You're pushing a split-TCP solution, one that (again, I repeat) the IETF
>> has never sanctioned and I do not agree with.
>>
>> Joe
>>
>>> On Apr 24, 2017, at 1:23 AM, <[e-mail]>
>> <[e-mail]> wrote:
>>> Joe,
>>>
>>> Transforming a TCP connection into MPTCP connection will obviously need
>> to access to SYNs to insert MPTCP options.
>>> This is the basic behavior of ** any ** MPTCP proxy.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Joe Touch [mailto:[e-mail]]
>>>> Envoyé : vendredi 21 avril 2017 18:04
>>>> À : BOUCADAIR Mohamed IMT/OLN; [e-mail];
>>>> [e-mail]
>>>> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work
>>>>
>>>> Med,
>>>>
>>>> I've made my position clear too.
>>>>
>>>> I do not support this doc as MPTCP work.
>>>>
>>>> I also call into question whether this is in-scope for MPTCP. MPTCP is
>>>> chartered to work within MPTCP - but this solution requires access to
>>>> raw incoming SYNs inside a different TCP connection, which is no longer
>>>> in-scope IMO.
>>>>
>>>> Joe
>>>>