Hi Joe, Please see inline.
Cheers, Med De : Joe Touch [mailto:[email protected]] Envoyé : mercredi 5 juillet 2017 18:59 À : Vladimir Olteanu; BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc : multipathtcp; [email protected] Objet : Re: [multipathtcp] [Int-area] SOCKS 6 Draft On 7/5/2017 9:39 AM, Vladimir Olteanu wrote: It can also be stacked as many times as desired for arbitrarily long proxy chains. However: * We avoid using the SYN's payload as extra option space (which, I think, goes against TCP's core philosophy). [Med] This is also true for MP_CONVERT Information Element which is not a TCP option, but a data supplied for proxy purposes in the SYN payload. Fair enough, but this is not a purely layer 5+ protocol. It seems that you are strongly tied to TFO (between the client and the proxy). MP_CONVERT must be part of the SYN's payload, because the following SYN+ACK depends on the contents of MP_CONVERT and signals that the remote server has accepted your connection. The biggest impact of including non-data information in the SYN payload area is that it completely defeats graceful fallback for SYN receivers that don't support the option. As you note, it can be *more* safe when tied to out-of-band context (e.g., prior TFO support), but TCP has NO requirement that such context is absolutely maintained across different connections. You might be speaking to a different stack or demuxed off to a different virtual host behind a load balancer. Ultimately, putting any non-data info in the SYN payload violates the requirement that TCP options can be ignored by receivers that don't support them *without* impacting the ability of *that* connection attempt to succeed. [Med] You are right... if we are talking about TCP options that are inserted in the payload of the SYN to every remote peer. This is not the case for the MPTCP proxy case: this is about proxy-supplied data that is sent to the proxy, which is provisioned by the provider. Proxy-supplied data is not received by the remote peer. Joe
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
