Re: [Int-area] New Version Notification for draft-olteanu-intarea-socks-6-02.txt

[Vladimir Olteanu <[e-mail]>]

Hi David,

Thanks for the observation. I'll rephrase 8.1 in the next version.

Further, the "SOCKS socket options" don't necessarily map onto 
setsockopts for a typical implementation using *nix sockets. For 
example, the TFO option would be handled as follows:
  * use sendto(...MSG_FASTOPEN...) or connectx() in case of CONNECT, or
  * call setsockopt(...SOL_TCP, TCP_FASTOPEN...) in case of BIND.

Cheers,
Vlad

On 03/06/2018 08:36 PM, David Schinazi wrote:
> Hi Vladimir,
>
> Thank for updating the draft.
>
> To be honest I'm pretty surprised to see socket options sent over the 
> wire here.
> Using the socket API is not a requirement to support TCP/IP and
> send data across the internet. Wouldn't it make more sense to send
> networking constructs over the wire instead of OS constructs?
>
> I understand the need to signal TFO support, but section 8.1 "Socket 
> Options"
> appears to be creating an IANA registry for OS constructs. The target 
> use-cases
> you describe (TFO and MPTCP) are networking constructs. Rephrasing this
> section as generic SOCKS options without mentioning sockets (which are an
> implementation detail) would address my concerns.
>
> Thanks,
> David Schinazi
>
>
>> On Mar 5, 2018, at 16:03, Vladimir Olteanu 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> Hi,
>>
>> We've submitted a revision of the SOCKSv6 draft.
>>
>> We've added an extensible mechanism whereby clients can alter proxy's 
>> behavior, roughly in the style of setsockopt()/getsockopt(). 
>> (Individual socket options have to be standardized separately, and 
>> don't necessarily map 1:1 to the function calls. This is not a 
>> straight set/getsockopt() RPC.) We've included a few use cases:
>>  * TFO (previously handled by a field in the request)
>>  * discovery of MPTCP availability on the server side
>>  * changing the MPTCP scheduler
>>
>> We've also addressed another security issue caused by sending SOCKS 
>> requests via TLS early data.
>>
>> Cheers,
>> Vlad
>>
>>
>> -------- Forwarded Message --------
>> Subject: 	New Version Notification for 
>> draft-olteanu-intarea-socks-6-02.txt
>> Date: 	Mon, 05 Mar 2018 14:59:26 -0800
>> From: 	[e-mail]
>> To: 	Vladimir Olteanu <[e-mail]>, Dragos Niculescu 
>> <[e-mail]>
>>
>>
>>
>> A new version of I-D, draft-olteanu-intarea-socks-6-02.txt
>> has been successfully submitted by Vladimir Olteanu and posted to the
>> IETF repository.
>>
>> Name:		draft-olteanu-intarea-socks-6
>> Revision:	02
>> Title:		SOCKS Protocol Version 6
>> Document date:	2018-03-05
>> Group:		Individual Submission
>> Pages:		23
>> URL:https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-02.txt
>> Status:https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/
>> Htmlized:https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-02
>> Htmlized:https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-02
>> Diff:https://www.ietf.org/rfcdiff?url2=draft-olteanu-intarea-socks-6-02
>>
>> Abstract:
>>     The SOCKS protocol is used primarily to proxy TCP connections to
>>     arbitrary destinations via the use of a proxy server.  Under the
>>     latest version of the protocol (version 5), it takes 2 RTTs (or 3, if
>>     authentication is used) before data can flow between the client and
>>     the server.
>>
>>     This memo proposes SOCKS version 6, which reduces the number of RTTs
>>     used, takes full advantage of TCP Fast Open, and adds support for
>>     0-RTT authentication.
>>
>>                                                                                    
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available attools.ietf.org <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>> _______________________________________________
>> Int-area mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/int-area
>