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

[Joe Touch <[e-mail]>]

I
> On Apr 25, 2017, at 11:11 PM, <[e-mail]> <[e-mail]> wrote:
> 
> Hi Touch, 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Joe Touch [mailto:[e-mail]]
>> Envoyé : lundi 24 avril 2017 17:23
>> À : BOUCADAIR Mohamed IMT/OLN
>> Cc : [e-mail]; [e-mail]
>> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work
>> 
>> 
>> 
>>> 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
> 
> [Med] I disagree, Joe. The IETF published "Standards Track" documents about NAT TCP state machines: https://tools.ietf.org/html/rfc7857#section-2, https://tools.ietf.org/html/rfc6146#section-3.5.2.2, and many other RFCs about NAT TCP behavior itself (RFC5382) or RFC6888. All these RFCs are implemented and deployed in real networks.
> 
Trying to create standards to patch the broken idea of a NAT and make it less interfering with existing protocols is not the same thing as standardizing the NAT itself.

> The IETF has also a "Standards Track" document called SOCKSv5 (RFC1928) that is splitting the TCP connection. We are adhering to the logic of that RFC but without the drawbacks of SOCKS.

Can you clarify where you see split TCP in RFC1928, or are you confusing it with this, which adds split TCP to a SOCKS proxy:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.9915&rep=rep1&type=pdf

...
>> 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.
> 
> [Med] I don't accept this argument. The only protection in TFO is a server-supplied "cookie". The proxy work has sufficient protections to interpret data inserted in a SYN in a safe manner. 
> 
> - TFO cookie is “used by the server side to authenticate a client initiating a TFO connection”. We support a variety of authentication/authorization methods; Please refer to slide 29 of https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf.

Can you confirm that your approach has the same level of protection as TFO cookies? 

> 
> - TFO specification acknowledges the following: “COOKIES ARE NOT NECESSARY if the server has application-level protection or is immune to these attacks” (cookie-less Fast Open) and “the server may choose to generate a TRIVIAL or even a ZERO-LENGTH COOKIE to improve performance by avoiding the cookie generation and verification”. Cached cookies are not required to supply data in 3WHS if the server if protection is in place. This is the case for the MPTCP proxy target case.  
> 
Please explain your application level protection or why you think this approach is immune to cookieless attacks. Or are you just embracing the result of those attacks as valid?

> - TFO server-supplied cookies are used to prevent SYNs with spoofed IP addresses attacks: Providers' networks are enabled with anti-spoofing filters.  
> 
> In order to avoid any confusion: the data we are talking about is not user/application supplied data but a proxy-supplied data that won't never reach the ultimate destination. We are not cloning TFO functionality. 

Agreed.
That might actually be OK.

Joe