Hey David,
Thanks for the kind words. I'll address your questions inline:
On 6/29/2017 9:09 PM, David Schinazi wrote:
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.
The main idea is to let the client send some data before running the
authentication protocol. The initial data offset gives the server a
carte blanche as to how much of the initial data it buffers while
waiting for the client to authenticate. (It still must read all of it
from the TCP stream before getting to the part where the client proves
its credentials.) Were it not for the authentication phase, these fields
would indeed be useless.
- 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.
I think version numbers still make sense. When presented with a SOCKSv6
request, a v5 proxy must at least know that the client is speaking some
other protocol. I will add a way for the proxy to signal that it doesn't
speak SOCKSv7+ in the next version of the draft. Version numbers in
operation replies don't make sense; I'll remove those. As for minor
versions, they might indeed be overkill, given that v6 is extensible via
options.
- 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.
This is certainly worth considering. Alternatively, we could use a bit
field: 2-3 bits for the command code, one bit for TFO, 2 for address
type etc. Otherwise, we might end up with too many command codes
(connect/bind x TFO x address type x whatever else we want to cram in).
- 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?
I don't see why not.
- 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
I like this idea. A side effect of this approach is that we move another
variable-length field to the back of the request, further simplifying
parsing.
- Out of curiosity, what specific use case are you using this protocol
for?
We are looking into using MPTCP on mobile devices to "bind" 4G/LTE and
WiFi. Mobile data networks have high latency, hence the drive to shave
off as many RTTs as possible and to take advantage of TFO, at least on
the client-proxy leg.
Cheers,
Vlad
Thanks,
David Schinazi
On Jun 29, 2017, at 05:08, Vladimir Olteanu
<vladimir.olte...@cs.pub.ro <mailto:vladimir.olte...@cs.pub.ro>> 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: 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-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
Status:https://datatracker.ietf.org/doc/draft-olteanu-intarea-socks-6/
Htmlized:https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-00
Htmlized: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 attools.ietf.org
<http://tools.ietf.org>.
The IETF Secretariat
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
