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 <vladimir.olte...@cs.pub.ro> 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: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
> To:   Vladimir Olteanu <vladimir.olte...@cs.pub.ro> 
> <mailto:vladimir.olte...@cs.pub.ro>, Dragos Niculescu 
> <dragos.nicule...@cs.pub.ro> <mailto:dragos.nicule...@cs.pub.ro>
> 
> 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 
> <https://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-02.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-02 
> <https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-02>
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-02 
> <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 
> <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 at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to