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
<vladimir.olte...@cs.pub.ro <mailto: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
To: Vladimir Olteanu <vladimir.olte...@cs.pub.ro>, Dragos Niculescu
<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
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
Int-area@ietf.org <mailto: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
