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

[<[e-mail]>]

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.

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.

Your initial argument, that is about "the IETF has never sanctioned..", is not acceptable.


 - only protocols to talk directly to NATs or
> methods to overcome what NATs do.

[Med] I disagree. See above. We are leveraging on existing IETF standard track documents. 

> 
> > 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.

[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.

- 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.  

- 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. 

> 
> 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
> >>>>