Subject: [Int-area] SOCKS 6 Draft

From: Vladimir Olteanu <[email-masked]>
Date: Thu, 29 Jun 2017 08:08:42 +0300

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-masked]
To: 	Vladimir Olteanu <[email-masked]>, Dragos Niculescu 
<[email-masked]>

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 at tools.ietf.org.

The IETF Secretariat

---

From: David Schinazi <[email-masked]>
Date: Thu, 29 Jun 2017 11:09:11 -0700

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-masked]> 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ș
> 
> 
> 
> From:	[email-masked] <mailto:[email-masked]>
> To:	Vladimir Olteanu <[email-masked]> <mailto:[email-masked]>, Dragos Niculescu <[email-masked]> <mailto:[email-masked]>
> 
> 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:

---

From: Vladimir Olteanu <[email-masked]>
Date: Fri, 30 Jun 2017 16:56:35 +0300

Hey David,

Thanks for the kind words. I'll address your questions inline:

> 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.
> 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.
> We could even take that one step further and also merge in the address 
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).
> the variable length address field to simplify and optimize parsing?
I don't see why not.
> 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 
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 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hello,
>>
>> 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:
>> until the htmlized version and diff are available attools.ietf.org <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>

---

From: David Schinazi <[email-masked]>
Date: Fri, 30 Jun 2017 11:08:52 -0700

Hi Vlad,

Responses inline.

> On Jun 30, 2017, at 06:56, Vladimir Olteanu <[email-masked]> wrote:
> 
> Hey David,
> 
> 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.

[DS] That makes more sense, thanks!
What's the benefit of sending the idempotent data before auth? The proxy's not going to send it out
until it has received the last client -> proxy auth message so we may as well send the data right after that?
(That said I'm not very familiar with GSSAPI or the non-standard auth methods 3-8 so I could be missing something)

> 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.

[DS] Wouldn't it be simpler to have IANA allocate a new port number though?
One byte isn't a huge win but it does make implementations simpler.

> 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). 

[DS] A bit field can be very useful, but not when some combinations are not allowed.
For example having both TFO and UDP does not make sense. It does make sense for
TCP/UDP/TFO vs IPv4/IPv6/hostname though.

> 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.
> 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.

Thanks! This is cool work.

David Schinazi

---

From: Vladimir Olteanu <[email-masked]>
Date: Sat, 1 Jul 2017 00:37:10 +0300

Hi David,

I've also inlined my responses.

On 06/30/2017 09:08 PM, David Schinazi wrote:
> Hi Vlad,
>
> Responses inline.
>
>> On Jun 30, 2017, at 06:56, Vladimir Olteanu 
>> 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.
>
> (That said I'm not very familiar with GSSAPI or the non-standard auth 
> methods 3-8 so I could be missing something)
>
The core issue is that the client can start sending regular data only 
when it is sure that the server won't ask for more authentication 
information. If 0-RTT authentication is successful, the proxy can open 
the socket right after the request, but the client has to wait 1 RTT 
before finding out if it must go through the slow authentication process 
or not.
>> 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.
>
The version byte helps with misconfiguration issues. Imagine what would 
happen if the client and the proxy were to speak different versions 
without either of them realizing. As for the amendment to the draft, it 
won't really complicate matters. It will consist of the proxy saying 
"but I speak version 6" and the client closing the connection.
>> 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).
>
I don't really see a problem with invalid bit group combinations. There 
are other field combinations that also don't make sense (e.g. UDP and 
initial data > 0).
>> 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.
>> 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