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

[<[e-mail]>]

Hi Joe,

Please see inline.

Cheers,
Med

De : Joe Touch [mailto:[e-mail]]
Envoyé : mercredi 26 avril 2017 08:38
À : BOUCADAIR Mohamed IMT/OLN
Cc : [e-mail]; [e-mail]
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work


I
On Apr 25, 2017, at 11:11 PM, <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[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]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work



On 4/24/2017 8:03 AM, [e-mail]<mailto:[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.
[Med] NAT64 (RFC6146) is not a patch AFAIK.

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,
[Med] I don’t see “split TCP” in RFC1928 in the same way I don’t see “split TCP” in the plain-mode draft.

I though you are making the same analysis, you have done for the MPTCP proxy, for SOCKS too: i.e., mix implementations-specific design choices with the base specification itself. FWIW, the typical exchanges that are observed when MPTCP is used with a SOCKS implementation is as follows:

=====
(MP Client) ->    TCP SYN    ->  (MCP)
                   <- TCP SYN/ACK <-
                   ->    TCP ACK    ->
                   -> SOCKS Method Request ->
                   <-    TCP ACK   <-
                    <- SOCKS Method Response  <-
                    ->   TCP ACK   ->
                    -> SOCKS Authentication Request ->
                    <-    TCP ACK     <-
                    <- SOCKS Auth. Response <-
                    ->   TCP ACK   ->
                    -> SOCKS Connection Request  -> (MCP)
                    <-   TCP ACK                   <- (MCP)
                                                      (MCP)  -> TCP SYN  -> (Server)
                                                      (MCP)  <- SYN/ACK  <- (Server)
                    <- SOCKS Connection Response   <-(MCP) -> TCP ACK -> (Server)
                    ->   TCP ACK  ->
======

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

[Med] Bingo. That is exactly my point. We need to avoid mixing implementation details with base specifications. That is exactly the reason why I said earlier that mptcp proxy documents only describe the external behavior.

...
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?
[Med] Yes, I confirm.



- 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