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.
On 03/06/2018 08:36 PM, David Schinazi wrote:
Thank for updating the draft.
To be honest I'm pretty surprised to see socket options sent over the
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
appears to be creating an IANA registry for OS constructs. The target
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.
On Mar 5, 2018, at 16:03, Vladimir Olteanu
<vladimir.olte...@cs.pub.ro <mailto:vladimir.olte...@cs.pub.ro>> wrote:
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.
-------- Forwarded Message --------
Subject: New Version Notification for
Date: Mon, 05 Mar 2018 14:59:26 -0800
To: Vladimir Olteanu <vladimir.olte...@cs.pub.ro>, Dragos Niculescu
A new version of I-D, draft-olteanu-intarea-socks-6-02.txt
has been successfully submitted by Vladimir Olteanu and posted to the
Title: SOCKS Protocol Version 6
Document date: 2018-03-05
Group: Individual Submission
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
This memo proposes SOCKS version 6, which reduces the number of RTTs
used, takes full advantage of TCP Fast Open, and adds support for
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
The IETF Secretariat
Int-area mailing list
Int-area mailing list