Re: [Int-area] [multipathtcp] SOCKS 6 Draft

[Joe Touch <[e-mail]>]

On 7/19/2017 5:32 PM, Vladimir Olteanu wrote:
>> If the above is correct, then it would be useful to NEVER speak of
>> "putting data in the SYN payload". You simply don't have that control.
>> The interface to TCP *allows* pending "user" (as in TCP user, which in
>> this case is the SOCKS layer) data to be placed in the SYN, but never
>> requires it.
> We're perfectly aware of that. We were only talking about putting data
> in the SYN for the sake of brevity, because said data is very likely
> to actually make it into the SYN under typical circumstances.
>
> However, you do have a point, especially given that MPTCP-PM and O-RTT
> converters are being actively discussed and they do require data to be
> placed in the SYN.

And those would fall under the category of attack devices, IMO.

I.e., if you're speaking of just an application proxy, then the doc
needs to be very clear of that goal AND use only the required TCP "user"
API -- which does not have any indication of an arriving SYN (it would
only indicate when the connection was established, e.g., after the TWHS
completes).

If you're speaking of something that rewrites TCP segments directly,
then you need to be clear that this is what you intend (and I cannot see
how you can do that and be compliant with TCP).

>> So you can talk about putting information in the SOCKS stream, but
>> shouldn't be referring to individual TCP segments.
>>
> If we were not discussing performance, I would agree with you.
> However, it's impractical (and not useful, either) to reason about the
> RTT overhead without making some assumptions about what data goes into
> which segment. SOCKS 6 is is designed to take advantage of how the
> stack is likely to split the data into segments in typical use cases. 

You can make some *assumptions* about what might happen, and even talk
about ways to configure the outgoing TCP to encourage its putting data
in the SYN (e.g., by writing before connecting). However, if we're
talking about an application layer proxy, you cannot assume availability
of the incoming SYN data unless you also assume TFO - and at best, it's
an assumption (your application would never know).

I.e., if you do everything right, you MIGHT end up looking "LIKE" you
rewrote the TCP SYN as it "passes through", but speaking of that as the
actual mechanism violates TCP.

So at best, there is need for a significant revision to clear this all up.

Joe