| 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
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.
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 (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 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.
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 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:
draft-01
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].
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
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).
The client starts by sending a request to the proxy.
+---------------+-----------+----------+ | 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
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.
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
A client MUST close the connection after receiving such a reply.
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
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.
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
If the proxy returns a reply code other than “Success”, the client MUST close the connection.
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.
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.
The relay of UDP packets is handled exactly as in SOCKS 5 [RFC1928].
SOCKS options have the following format:
+---------------+-------------+ | Kind | Length | Option Data | +------+--------+-------------+ | 1 | 1 | Variable | +------+--------+-------------+
Figure 6: SOCKS 6 Option
Authentication options carry method-specific authentication data. They can be part of SOCKS Requests and Authentication Replies.
Authentication options have the following format:
+---------------+--------+---------------------+ | Kind | Length | Method | Authentication Data | +------+--------+--------+---------------------+ | 1 | 1 | 1 | Variable | +------+--------+--------+---------------------+
Figure 7: Authentication Option
All proxy implementations MUST support authentication method options. Clients MAY omit advertising authentication methods for which they have included at least an authentication option.
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
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
The proxy then includes a Token Window Advertisement option in the corresponding Operation Reply:
+---------------+------+-------------+-------------+ | Kind | Length | Type | Window Base | Window Size | +------+--------+------+-------------+-------------+ | 1 | 1 | 1 | 4 | 4 | +------+--------+------+-------------+-------------+
Figure 10: Token Window Advertisement
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
Clients SHOULD prioritize spending the smaller tokens.
The server responds by sending a Token Expenditure Reply option as part of the Operation Reply:
+---------------+------+---------------+ | Kind | Length | Type | Response Code | +------+--------+------+---------------+ | 1 | 1 | 1 | 1 | +------+--------+------+---------------+
Figure 12: Token Expenditure Response
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:
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.
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.
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:
Further, the server MAY choose not to buffer any initial data beyond what would be expected to fit in a TFO SYN’s payload.
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.
This document requests that IANA allocate option codes for SOCKS 6 options. Further, this document requests option codes for authentication and idempotence options.
This document also requests that IANA allocate a port for SOCKS over TLS.
The protocol described in this draft builds upon and is a direct continuation of SOCKS 5 [RFC1928].
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [I-D.ietf-tls-tls13] | Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Internet-Draft draft-ietf-tls-tls13-21, 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. |
| [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. |
| [RFC7413] | Cheng, Y., Chu, J., Radhakrishnan, S. and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014. |