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

[Joe Touch <[e-mail]>]

Med,


On 4/19/2017 10:50 PM, [e-mail] wrote:
>
> Hi Joe,
>
>  
>
> I don’t understand your comments here:
>
> ·         The use of a 32-bit magic number is meant to distinguish
> application-supplied data from the one inserted by the proxy. There
> are other fields in the MP_CONVERT information element that help in
> that aim too (validation of the TLV, M-bit, for example).
>
> ·         Both entities that supply and process the data are under the
> control of the same operator.
>
> ·         The network-located proxy is explicitly configured on the
> CPE. The destination IP address of the packet is an address of that
> proxy, not the address of a legacy node.
>
> ·         The proxy must echo supplied data in a SYN/ACK. If a
> mismatch is detected by the CPE, that proxy WON’t be used for
> subsequent connections till a new proxy is configured, TTL expires, etc.
>
>  
>
> To sum:
>
> ·         We are acting on one single SYN of an MPTCP connection.
>
> ·         If a mismatch is detected for one single SYN of a given
> connection, all subsequent connections (with any remote server) won’t
> be relayed to that proxy.
>
>  
>
> How is this “hazardous”?
>

TCPM archives are full of discussions on why TFO only works for
subsequent connections to the same endpoint, due to cached cookies that
allow the SYN data to be safely interpreted *before* the end of the 3WHS.

MPTCP archives are full of discussions on why the data plane is not a
good place to put option information.

It's not practical to repeat those arguments in one email. The point is
that you're reinventing the wheel in ways that this group and other
groups already know are hazardous.

Joe

>  
>
> Thank you.
>
>  
>
> Cheers,
>
> Med
>
>  
>
> *De :*Joe Touch [mailto:[e-mail]]
> *Envoyé :* mercredi 19 avril 2017 20:12
> *À :* BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida
> *Cc :* multipathtcp
> *Objet :* Re: [multipathtcp] Consensus call on potential MPTCP proxy work
>
>  
>
>  
>
>  
>
> On 4/18/2017 10:46 PM, [e-mail]
> <mailto:[e-mail]> wrote:
>
>     ...
>
>     Using the SYN data as control information is the hazardous part.
>
>     [Med] It isn’t for the for the simple reason that legacy Internet
>     nodes will never receive a SYN with CPE-supplied data and that the
>     TCP peer is known to process the supplied data. A Guard against
>     misconfigurations is supported: echo in a SYN/ACK.
>
>
> The idea of using a magic number to protect against miscommunication
> virtually ensures that there will be reliable connections with errors.
> That changes TCPs semantics.
>
> Putting data in the SYN of TFO is permitted only because of previous
> state.
>
> MPTCP doesn't have that state and so it is hazardous to put data in
> the SYN.
>
> I.e., if you want TFO-like performance, figure out how to use TFO. Period.
>
> Joe
>