Subject: [Int-area] Fwd: New Version Notification for draft-olteanu-intarea-socks-6-02.txt

From: Vladimir Olteanu <[email-masked]>
Date: Tue, 6 Mar 2018 02:03:40 +0200

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

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

The IETF Secretariat

---

From: David Schinazi <[email-masked]>
Date: Tue, 06 Mar 2018 10:36:15 -0800

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 <[email-masked]> wrote:
> 
> Hi,
> 
> 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:
> We've also addressed another security issue caused by sending SOCKS requests via TLS early data.
> 
> Cheers,
> Vlad
> 
> 
> 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-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:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Vladimir Olteanu <[email-masked]>
Date: Tue, 6 Mar 2018 21:44:46 +0200

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:
>> On Mar 5, 2018, at 16:03, Vladimir Olteanu 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi,
>>
>> 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:
>> 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:
>> until the htmlized version and diff are available attools.ietf.org <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Vladimir Olteanu <[email-masked]>
Date: Thu, 15 Mar 2018 19:17:41 +0200

Hi,

Since TLS 1.3 forces everyone to use AEAD, salting requests sent over 
early data is redundant. (Previous TLS versions allow non-AEAD ciphers, 
but don't have early data.) Oops.

I'll remove the Salt option in -03.

Vlad