Hi Vladimir,

Thanks for writing this up, I agree SOCKS needs to be modernized and I think 
your draft
has a lot of good ideas. A few questions:

- Why do you mimic the TFO semantics so closely?
Since SOCKSv6 runs over TCP, I'm not sure I understand the meaning of the 
initial data offset.
The server can pull enough data for the upstream TCP SYN from its initial window
and leave the rest of the SOCKSv6 initial data there for later, instead of 
resending it twice.

- Does it make sense to keep sending the version number over the wire?
Proxy protocols need to be provisioned out of band (e.g. SOCKS vs HTTP, port 
number)
and there is no way for a SOCKSv5 server to reply "I don't speak SOCKSv6".
I'm not sure I see the value of a minor version either, as there's still plenty 
of room
for major versions 7-255.

- Instead of having a command code enum with 3 values and a TFO enum with 2 
values,
could we instead add a CONNECT_WITH_TFO command code to save a byte?
We could even take that one step further and also merge in the address type 
enum.

- One pain point I had when implementing SOCKSv5 was the fact that the port 
number
was after the address which meant that it moved, would it make sense to place 
it before
the variable length address field to simplify and optimize parsing?

- Could we make the client supported auth methods optional?
Since the client is sending tentative auth proposals as options, one could 
imagine
making the list of supported auth methods an option, an treating it as "I only 
support
no auth" when it's not there

- Out of curiosity, what specific use case are you using this protocol for?

Thanks,
David Schinazi


> On Jun 29, 2017, at 05:08, Vladimir Olteanu <[email protected]> 
> wrote:
> 
> Hello,
> 
> We have submitted a draft describing a new version of the SOCKS protocol. You 
> can find the abstract and a link to the draft below.
> 
> Best,
> Vlad and DragoČ™
> 
> 
> 
> -------- Forwarded Message --------
> Subject:      New Version Notification for 
> draft-olteanu-intarea-socks-6-00.txt
> Date: Wed, 28 Jun 2017 22:01:16 -0700
> From: [email protected] <mailto:[email protected]>
> To:   Vladimir Olteanu <[email protected]> 
> <mailto:[email protected]>, Dragos Niculescu 
> <[email protected]> <mailto:[email protected]>
> 
> A new version of I-D, draft-olteanu-intarea-socks-6-00.txt
> has been successfully submitted by Vladimir Olteanu and posted to the
> IETF repository.
> 
> Name:         draft-olteanu-intarea-socks-6
> Revision:     00
> Title:                SOCKS Protocol Version 6
> Document date:        2017-06-28
> Group:                Individual Submission
> Pages:                12
> URL:            
> https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-00.txt 
> <https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-00.txt>
> Status:         
> https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/ 
> <https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/>
> Htmlized:       https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-00 
> <https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-00>
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-00 
> <https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-00>
> 
> 
> 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 at tools.ietf.org.
> 
> The IETF Secretariat
> 

_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to