Internet Area Working Group V. Olteanu
Internet-Draft D. Niculescu
Intended status: Experimental University Politehnica of Bucharest
Expires: May 3, 2018 October 30, 2017
SOCKS Protocol Version 6
draft-olteanu-intarea-socks-6-01
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Olteanu & Niculescu Expires May 3, 2018 [Page 1]
Internet-Draft SOCKS 6 October 2017
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Revision log . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements language . . . . . . . . . . . . . . . . . . . . 4
3. Mode of operation . . . . . . . . . . . . . . . . . . . . . . 4
4. Connection Requests . . . . . . . . . . . . . . . . . . . . . 5
5. Version Mismatch Replies . . . . . . . . . . . . . . . . . . 8
6. Authentication Replies . . . . . . . . . . . . . . . . . . . 8
7. Operation Replies . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Handling CONNECT . . . . . . . . . . . . . . . . . . . . 11
7.2. Handling BIND . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Handling UDP ASSOCIATE . . . . . . . . . . . . . . . . . 11
8. SOCKS Options . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Authentication options . . . . . . . . . . . . . . . . . 11
8.2. Idempotence options . . . . . . . . . . . . . . . . . . . 12
8.2.1. Requesting a fresh token window . . . . . . . . . . . 13
8.2.2. Spending a token . . . . . . . . . . . . . . . . . . 14
8.2.3. Handling Token Window Advertisements . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. Large requests . . . . . . . . . . . . . . . . . . . . . 16
9.2. Replay attacks . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Versions 4 and 5 [RFC1928] of the SOCKS protocol were developed two
decades ago and are in widespread use for circuit level gateways or
as circumvention tools, and enjoy wide support and usage from various
software, such as web browsers, SSH clients, and proxifiers.
However, their design needs an update in order to take advantage of
the new features of transport protocols, such as TCP Fast Open
[RFC7413], or to better assist newer transport protocols, such as
MPTCP [RFC6824].
One of the main issues faced by SOCKS version 5 is that, when taking
into account the TCP handshake, method negotiation, authentication,
connection request and grant, it may take up to 5 RTTs for a data
Olteanu & Niculescu Expires May 3, 2018 [Page 2]
Internet-Draft SOCKS 6 October 2017
exchange to take place at the application layer. This is especially
costly in networks with a large delay at the access layer, such as
3G, 4G, or satelite.
The desire to reduce the number of RTTs manifests itself in the
design of newer security protocols. TLS version 1.3
[I-D.ietf-tls-tls13] defines a zero round trip (0-RTT) handshake mode
for connections if the client and server had previously communicated.
TCP Fast Open [RFC7413] is a TCP option that allows TCP to send data
in the SYN and receive a response in the first ACK, and aims at
obtaining a data response in one RTT. The SOCKS protocol needs to
concern itself with at least two TFO deployment scenarios: First,
when TFO is available end-to-end (at the client, at the proxy, and at
the server); second, when TFO is active between the client and the
proxy, but not at the server.
This document describes the SOCKS protocol version 6. The key
improvements over SOCKS version 5 are:
o The client sends as much information upfront as possible, and does
not wait for the authentication process to conclude before
requesting the creation of a socket.
o The connection request also mimics the semantics of TCP Fast Open
[RFC7413]. As part of the connection request, the client can
supply the payload for the initial SYN that is sent out to the
server.
o The protocol can be extended via options without breaking
backward-compatibility.
o The protocol can leverage the aforementioned options to support
0-RTT authentication schemes.
1.1. Revision log
draft-01
o Added this section.
o Support for idempotent commands.
o Removed version numbers from operation replies.
o Request port number for SOCKS over TLS. Deprecate encryption/
encapsulation within SOCKS.
Olteanu & Niculescu Expires May 3, 2018 [Page 3]
Internet-Draft SOCKS 6 October 2017
o Added Version Mismatch Replies.
o Renamed the AUTH command to NOOP.
o Shifted some fields to make requests and operation replies easier
to parse.
2. Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Mode of operation
CLIENT PROXY
+------------------------+
| Authentication methods | Request
--------> Command code +------------------------------>
| TFO |
| Address |
| Port |
| Options |
| Initial data |
+------------------------+
+-----------------------+
Authentication reply | Type |
<----------------------------------+ Method <-----
| Options |
+-----------------------+
<-------------------(Authentication protocol)------------------>
+-----------------------+
Operation reply | Reply code |
<--------------------+ Bind address <------------------
| Bind port |
| Options |
| Initial data offset |
+-----------------------+
Figure 1: The SOCKS version 6 protocol message exchange
Olteanu & Niculescu Expires May 3, 2018 [Page 4]
Internet-Draft SOCKS 6 October 2017
When a TCP-based client wishes to establish a connection to a server,
it must open a TCP connection to the appropriate SOCKS port on the
SOCKS proxy. The client then enters a negotiation phase, by sending
the request in figure Figure 1, that contains, in addition to fields
present in SOCKS 5 [RFC1928], fields that facilitate low RTT usage
and faster authentication negotiation.
Next, the server sends an authentication reply. If the request did
not contain the necessary authentication information, the proxy
indicates an authentication method that must proceed. This may
trigger a longer authentication sequence that could include tokens
for ulterior faster authentications. The part labeled
"Authentication protocol" is specific to the authentication method
employed and is not expected to be employed for every connection
between a client and its proxy server. The authentication protocol
typically takes up 1 RTT or more.
If the authentication is successful, an operation reply is generated
by the proxy. It indicates whether the proxy was successful in
creating the requested socket or not.
In the fast case, when authentication is properly set up, the proxy
attempts to create the socket immediately after the receipt of the
request, thus achieving an operational conection in one RTT (provided
TFO functionality is available at the client, proxy, and server).
4. Connection Requests
The client starts by sending a request to the proxy.
Olteanu & Niculescu Expires May 3, 2018 [Page 5]
Internet-Draft SOCKS 6 October 2017
+---------------+-----------+----------+
| Version | Number of | Methods |
| Major | Minor | Methods | |
+-------+-------+-----------+----------+
| 1 | 1 | 1 | Variable |
+-------+-------+-----------+----------+
+---------+-----+---------+------+----------+
| Command | TFO | Address | Port | Address |
| Code | | Type | | |
+---------+-----+---------+------+----------+
| 1 | 1 | 1 | 2 | Variable |
+---------+-----+---------+------+----------+
+-----------+----------+--------------+--------------+
| Number of | Options | Initial Data | Initial Data |
| Options | | Size | |
+-----------+----------+--------------+--------------+
| 1 | Variable | 2 | Variable |
+-----------+----------+--------------+--------------+
Figure 2: SOCKS 6 Request
o Version: The major byte MUST be set to 0x06, and the minor byte
MUST be set to 0x00.
o Number of Methods: The number of supported authentication methods
that the client wishes to advertise.
o Methods: One byte per advertised method. Method numbers are
assigned by IANA.
o Command Code:
* 0x00 NOOP: authenticate the client and do nothing.
* 0x01 CONNECT: requests the establishment of a TCP connection.
* 0x02 BIND: requests the establishment of a TCP port binding.
* 0x03 UDP ASSOCIATE: requests a UDP port association.
o TFO:
* 0x00 indicates that the proxy MUST NOT attempt to use TFO in
case of a CONNECT command, or accept TFO in case of a BIND
command. In case of an AUTH or UDP ASSOCIATE command, this
field MUST be set to 0x00.
Olteanu & Niculescu Expires May 3, 2018 [Page 6]
Internet-Draft SOCKS 6 October 2017
* 0x01 indicates that the proxy SHOULD attempt to use TFO in case
of a CONNECT command, or accept TFO in case of a BIND command.
o Address Type:
* 0x01: IPv4
* 0x03: Domain Name
* 0x04: IPv6
o Address: this field's format depends on the address type:
* IPv4: a 4-byte IPv4 address
* Domain Name: one byte that contains the length of the FQDN,
followed by the FQDN itself. The string is not NUL-terminated.
* IPv6: a 16-byte IPv6 address
o Port: the port in network byte order.
o Number of Options: the number of SOCKS options that appear in the
Options field.
o Options: see section Section 8.
o Initial Data Size: A two-byte number in network byte order. In
case of AUTH, BIND or UDP ASSOCIATE, this field MUST be set to 0.
In case of CONNECT, this is the number of bytes of initial data
that are supplied in the following field.
o Initial Data: The first octets of the data stream.
Clients MUST support the "No authentication required" method.
Clients MAY omit advertising the "No authentication required" option.
Clients SHOULD NOT issue AUTH commands unless they advertise
authentication methods with support for 0-RTT authentication.
The server MAY truncate the initial data to an arbitrary size and
disregard the rest. This is will be communicated later to the
client, should the authentication process be successful (see section
Section 7). As such, server implementations do not have to buffer
the initial data while waiting for the (potentially malicious) client
to authenticate.
Olteanu & Niculescu Expires May 3, 2018 [Page 7]
Internet-Draft SOCKS 6 October 2017
5. Version Mismatch Replies
Upon receipt of a request starting with a version number other than
6.0, the proxy sends the following response:
+---------------+
| Version |
| Major | Minor |
+-------+-------+
| 1 | 1 |
+-------+-------+
Figure 3: SOCKS 6 Version Mismatch Reply
o Version: The major byte MUST be set to 0x06, and the minor byte
MUST be set to 0x00.
A client MUST close the connection after receiving such a reply.
6. Authentication Replies
Upon receipt of a valid request, the proxy sends an Authentication
Reply:
+---------------+------+--------+-----------+----------+
| Version | Type | Method | Number of | Options |
| Major | Minor | | | Options | |
+-------+-------+------+--------+-----------+----------+
| 1 | 1 | 1 | 1 | 1 | Variable |
+-------+-------+------+--------+-----------+----------+
Figure 4: SOCKS 6 Authentication Reply
o Version: The major byte MUST be set to 0x06, and the minor byte
MUST be set to 0x00.
o Type:
* 0x00: authentication successful.
* 0x01: further authentication needed.
o Method: The chosen authentication method.
o Number of Options: the number of SOCKS options that appear in the
Options field.
Olteanu & Niculescu Expires May 3, 2018 [Page 8]
Internet-Draft SOCKS 6 October 2017
o Options: see section Section 8.
Multihomed clients SHOULD cache the chosen method on a per-interface
basis and SHOULD NOT include authentication options related to any
other methods in further requests originating from the same
interface.
If the server signals that further authentication is needed and
selects "No Acceptable Methods", the client MUST close the
connection.
The client and proxy begin a method-specific negotiation. During
such negotiations, the proxy MAY supply information that allows the
client to authenticate a future request using an authentication
option. Descriptions of such negotiations are beyond the scope of
this memo.
If the cliend issued an AUTH command, the client MUST close the
connection after the negociation is complete.
7. Operation Replies
After the authentication negotiations are complete, the server sends
an Operation Reply:
+-------+---------+------+----------+--------------+
| Reply | Address | Bind | Bind | Initial Data |
| Code | Type | Port | Address | Offset |
+-------+---------+------+----------+--------------+
| 1 | 1 | 2 | Variable | 2 |
+-------+---------+------+----------+--------------+
+-----------+----------+
| Number of | Options |
| Options | |
+-----------+----------+
| 1 | Variable |
+-----------+----------+
Figure 5: SOCKS 6 Operation Reply
o Reply Code:
* 0x00: Succes
* 0x01: General SOCKS server failure
* 0x02: Connection not allowed by ruleset
Olteanu & Niculescu Expires May 3, 2018 [Page 9]
Internet-Draft SOCKS 6 October 2017
* 0x03: Network unreachable
* 0x04: Host unreachable
* 0x05: Connection refused
* 0x06: TTL expired
* 0x07: Command not supported
* 0x08: Address type not supported
o Address Type:
* 0x01: IPv4
* 0x03: Domain Name
* 0x04: IPv6
o Bind Address: the proxy bound address in the following format:
* IPv4: a 4-byte IPv4 address
* Domain Name: one byte that contains the length of the FQDN,
followed by the FQDN itself. The string is not NUL-terminated.
* IPv6: a 16-byte IPv6 address
o Bind Port: the proxy bound port in network byte order.
o Number of Options: the number of SOCKS options that appear in the
Options field.
o Options: see section Section 8.
o Initial Data Offset: A two-byte number in network byte order. In
case of BIND or UDP ASSOCIATE, this field MUST be set to 0. In
case of CONNECT, it represents the offset in the plain data stream
from which the client is expected to continue sending data.
If the proxy returns a reply code other than "Success", the client
MUST close the connection.
Olteanu & Niculescu Expires May 3, 2018 [Page 10]
Internet-Draft SOCKS 6 October 2017
7.1. Handling CONNECT
In case the client has issued a CONNECT request, data can now pass.
The client MUST resume the data stream at the offset indicated by the
Initial Data Offset field.
7.2. Handling BIND
In case the client has issued a BIND request, it must wait for a
second Operation reply from the proxy, which signifies that a host
has connected to the bound port. The Bind Address and Bind Port
fields contain the address and port of the connecting host.
Afterwards, application data may pass.
7.3. Handling UDP ASSOCIATE
The relay of UDP packets is handled exactly as in SOCKS 5 [RFC1928].
8. SOCKS Options
SOCKS options have the following format:
+---------------+-------------+
| Kind | Length | Option Data |
+------+--------+-------------+
| 1 | 1 | Variable |
+------+--------+-------------+
Figure 6: SOCKS 6 Option
o Kind: MUST be allocated by IANA. (See section Section 10.)
o Length: The length of the option.
o Option Data: The contents are specific to each option kind.
8.1. Authentication options
Authentication options carry method-specific authentication data.
They can be part of SOCKS Requests and Authentication Replies.
Authentication options have the following format:
Olteanu & Niculescu Expires May 3, 2018 [Page 11]
Internet-Draft SOCKS 6 October 2017
+---------------+--------+---------------------+
| Kind | Length | Method | Authentication Data |
+------+--------+--------+---------------------+
| 1 | 1 | 1 | Variable |
+------+--------+--------+---------------------+
Figure 7: Authentication Option
o Kind: MUST be allocated by IANA. (See section Section 10.)
o Length: The length of the option.
o Method: The number of the authentication method. These numbers
are assigned by IANA.
o Authentication Data: The contents are specific to each method.
All proxy implementations MUST support authentication method options.
Clients MAY omit advertising authentication methods for which they
have included at least an authentication option.
8.2. Idempotence options
To protect against duplicate SOCKS Requests, authenticated clients
can request, and then spend, idempotence tokens. A token can only be
spent on a single SOCKS request.
Tokens are 4-byte unsigned integers in a modular 4-byte space.
Therefore, if x and y are tokens, x is smaller than y if (y - x) <
2^31 in unsigned 32-bit arithmetic.
Proxies grant contiguous ranges of tokens called token windows.
Token windows are defined by their base (the first token in the
range) and size. Windows can be shifted (i. e. have their base
increased, while retaining their size) unilaterally by the proxy.
Requesting and spending tokens is done via Idempotence options:
+---------------+------+-------------+
| Kind | Length | Type | Option Data |
+------+--------+------+-------------+
| 1 | 1 | 1 | Variable |
+------+--------+------+-------------+
Figure 8: Idempotence Option
Olteanu & Niculescu Expires May 3, 2018 [Page 12]
Internet-Draft SOCKS 6 October 2017
o Kind: MUST be allocated by IANA. (See section Section 10.)
o Length: The length of the option.
o Type:
* 0x00: Token Request
* 0x01: Token Window Advertisement
* 0x02: Token Expenditure
* 0x03: Token Expenditure Reply
o Option Data: The contents are specific to each type.
8.2.1. Requesting a fresh token window
A client can obtain a fresh window of tokens by sending a Token
Request option as part of a SOCKS Request:
+---------------+------+-------------+
| Kind | Length | Type | Window Size |
+------+--------+------+-------------+
| 1 | 1 | 1 | 4 |
+------+--------+------+-------------+
Figure 9: Token Request
o Kind: MUST be allocated by IANA. (See section Section 10.)
o Length: 7
o Type: 0x00 (Token Request)
o Window Size: The requested window size.
The proxy then includes a Token Window Advertisement option in the
corresponding Operation Reply:
Olteanu & Niculescu Expires May 3, 2018 [Page 13]
Internet-Draft SOCKS 6 October 2017
+---------------+------+-------------+-------------+
| Kind | Length | Type | Window Base | Window Size |
+------+--------+------+-------------+-------------+
| 1 | 1 | 1 | 4 | 4 |
+------+--------+------+-------------+-------------+
Figure 10: Token Window Advertisement
o Kind: MUST be allocated by IANA. (See section Section 10.)
o Length: 11
o Type: 0x01 (Token Grant)
o Window Base: The first token in the window.
o Window Size: The window size. This value SHOULD be lower or equal
to the requested window size.
8.2.2. Spending a token
The client can attempt to spend a token by including a Token
Expenditure option in its SOCKS request:
+---------------+------+-------+
| Kind | Length | Type | Token |
+------+--------+------+-------+
| 1 | 1 | 1 | 4 |
+------+--------+------+-------+
Figure 11: Token Expenditure
o Kind: MUST be allocated by IANA. (See section Section 10.)
o Length: 7
o Type: 0x02 (Token Expenditure)
o Token: The token being spent.
Clients SHOULD prioritize spending the smaller tokens.
The server responds by sending a Token Expenditure Reply option as
part of the Operation Reply:
Olteanu & Niculescu Expires May 3, 2018 [Page 14]
Internet-Draft SOCKS 6 October 2017
+---------------+------+---------------+
| Kind | Length | Type | Response Code |
+------+--------+------+---------------+
| 1 | 1 | 1 | 1 |
+------+--------+------+---------------+
Figure 12: Token Expenditure Response
o Kind: MUST be allocated by IANA. (See section Section 10.)
o Length: 4
o Type: 0x03 (Token Expenditure Response)
o Response Code:
* 0x00: Success: The token was spent successfully.
* 0x01: No Window: The proxy does not have a token window
associated with the client.
* 0x02: Out of Window: The token is not within the window.
* 0x03: Duplicate: The token has already been spent.
If eligible, the token is spent as soon as the client authenticates.
If the token is not eligible for spending, the proxy MUST NOT attempt
to honor the client's SOCKS Request; further, it MUST indicate a
General SOCKS server failure in the Operation Reply.
Proxy implementations SHOULD also send a Token Window Advertisement
if:
o the token is out of window, or
o by the proxy's internal logic, successfully spending the token
caused the window to shift.
Proxy implementations SHOULD NOT shift the window's base beyond the
highest unspent token.
Proxy implementations MAY include a Token Window Advertisement in any
Operation Reply.
Olteanu & Niculescu Expires May 3, 2018 [Page 15]
Internet-Draft SOCKS 6 October 2017
8.2.3. Handling Token Window Advertisements
Even though the proxy increases the window's base monotonically,
there is no mechanism whereby a SOCKS client can receive the Token
Window Advertisements in order. As such, clients SHOULD disregard
unsollicited Token Window Advertisements with a Window Base less than
the previously known value.
9. Security Considerations
9.1. Large requests
Given the format of the request message, a malicious client could
craft a request that is in excess of 100 KB and proxies could be
prone to DDoS attacks.
To mitigate such attacks, proxy implementations SHOULD be able to
incrementally parse the requests. Proxies MAY close the connection
to the client if:
o the request is not fully received after a certain timeout, or
o the number of options exceeds an imposed hard cap, or
o the total size of the options exceeds an imposed hard cap, or
o the size of the initial data excedes a hard cap.
Further, the server MAY choose not to buffer any initial data beyond
what would be expected to fit in a TFO SYN's payload.
9.2. Replay attacks
In TLS 1.3, early data (which is likely to contain a full SOCKS
request) is prone to replay attacks.
While Token Expenditure options can be used to mitigate replay
attacks, the initial Token Request is still vulnerable. As such,
client implementations SHOULD NOT make use of TLS early data when
sending a Token Request.
10. IANA Considerations
This document requests that IANA allocate option codes for SOCKS 6
options. Further, this document requests option codes for
authentication and idempotence options.
Olteanu & Niculescu Expires May 3, 2018 [Page 16]
Internet-Draft SOCKS 6 October 2017
This document also requests that IANA allocate a port for SOCKS over
TLS.
11. Acknowledgements
The protocol described in this draft builds upon and is a direct
continuation of SOCKS 5 [RFC1928].
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
12.2. Informative References
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
July 2017.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928,
DOI 10.17487/RFC1928, March 1996,
<https://www.rfc-editor.org/info/rfc1928>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<https://www.rfc-editor.org/info/rfc6824>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
Authors' Addresses
Vladimir Olteanu
University Politehnica of Bucharest
Email: vladimir.olteanu@cs.pub.ro
Olteanu & Niculescu Expires May 3, 2018 [Page 17]
Internet-Draft SOCKS 6 October 2017
Dragos Niculescu
University Politehnica of Bucharest
Email: dragos.niculescu@cs.pub.ro
Olteanu & Niculescu Expires May 3, 2018 [Page 18]