| Internet Area Working Group | V. Olteanu |
| Internet-Draft | D. Niculescu |
| Intended status: Experimental | University Politehnica of Bucharest |
| Expires: May 7, 2020 | November 04, 2019 |
SOCKS Protocol Version 6
draft-olteanu-intarea-socks-6-08
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 7, 2020.
Copyright (c) 2019 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 [RFC8446] 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:
Typos and minor clarifications are not listed.
draft-08
draft-07
draft-06
draft-05
draft-04
draft-03
draft-02
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 +------------------------------>
| Address |
| Port |
| Options |
+------------------------+
+------------------------+
--------> Initial data +------------------------------>
+------------------------+
+-----------------------+
Authentication Reply | Type |
<----------------------------------+ Options <-----
+-----------------------+
<-------------------(Authentication protocol)------------------>
+-----------------------+
Authentication Reply | Type = Success |
<----------------------------------+ Options <-----
+-----------------------+
+-----------------------+
Operation Reply | Reply code |
<--------------------+ Bind address <------------------
| Bind port |
| Options |
+-----------------------+
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 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.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| Version = 6 | Command Code | Options Length |
+---------------+---------------+---------------+---------------+
| Port | Padding = 0 | Address Type |
+-------------------------------+---------------+---------------+
| ...
... Address (variable length) ...
... |
+---------------------------------------------------------------+
| ...
... Options (variable length) ...
... |
+---------------------------------------------------------------+
Figure 2: SOCKS 6 Request
The Address and Port fields have different meanings based on the Command Code:
Clients can advertise their supported authentication methods by including an Authentication Method Advertisement option (see Section 8.2).
Upon receipt of a request starting with a version number other than 6, the proxy sends the following response:
0 1 2 3 4 5 6 7
+---------------+
| Version = 6 |
+---------------+
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:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| Version = 6 | Type | Options Length |
+---------------+---------------+-------------------------------+
| ...
... Options (variable length) ...
... |
+---------------------------------------------------------------+
Figure 4: SOCKS 6 Authentication Reply
If the server signals that the authentication has failed and does not signal that any authentication negotiation can continue (via an Authentication Method Selection option), 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 Data option. Application data is not subject to any encryption negotiated during this phase. Descriptions of such negotiations are beyond the scope of this memo.
When the negotiation is complete (either successfully or unsuccessfully), the proxy sends a second Authentication Reply. The second Authentication Reply MUST NOT allow for further negotiations.
After the authentication negotiations are complete, the proxy sends an Operation Reply:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| Version = 6 | Reply Code | Options Length |
+---------------+---------------+---------------+---------------+
| Bind Port | Padding = 0 | Address Type |
+-------------------------------+---------------+---------------+
| ...
... Bind Address (variable length) ...
... |
+---------------------------------------------------------------+
| ...
... Options (variable length) ...
... |
+---------------------------------------------------------------+
Figure 5: SOCKS 6 Operation Reply
Proxy implementations MAY support any subset of the client commands listed in Section 4.
If the proxy returns a reply code other than “Success”, the client MUST close the connection.
If the client issued an NOOP command, the client MUST close the connection after receiving the Operation Reply.
In case the client has issued a CONNECT request, data can now pass.
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.
Proxies offering UDP functionality must be configured with a UDP port used for relaying UDP datagrams to and from the client, and/or a port used for relaying datagrams over DTLS.
Following a successful Operation Reply, the proxy sends a UDP Association Initialization message:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+
| Association ID |
| (8 bytes) |
+---------------------------------------------------------------+
Figure 6: UDP Association Initialization
Proxy implementations SHOULD generate Association IDs randomly or pseudo-randomly.
Clients may start sending UDP datagrams to the proxy either in plaintext, or over an established DTLS session, using the proxy’s configured UDP ports. A client’s datagrams are prefixed by a SOCKS Datagram Header, indicating the remote host’s address and port:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| Version = 6 | Address Type | Port |
+---------------+---------------+-------------------------------+
| Association ID |
| (8 bytes) |
+---------------------------------------------------------------+
| ...
... Address (variable length) ...
... |
+---------------------------------------------------------------+
Figure 7: SOCKS 6 Datagram Header
Following the receipt of the first datagram from the client, the proxy makes a one-way mapping between the Association ID and:
Further datagrams carrying the same Association ID, but not matching the established mapping, are silently dropped.
The proxy then sends an UDP Association Confirmation message over the TCP connection with the client:
0 1 2 3 4 5 6 7
+---------------+
| Status = 0 |
+---------------+
Figure 8: UDP Association Confirmation
Following the confirmation message, UDP packets bound for the proxy’s bind address and port are relayed to the client, also prefixed by a Datagram Header.
The UDP association remains active for as long as the TCP connection between the client and the proxy is kept open.
Under some circumstances (e.g. when hosting a server), the SOCKS client expects the remote host to send UDP datagrams first. As such, the SOCKS client must trigger a UDP Association Confirmation without having the proxy relay any datagrams on its behalf.
To that end, it sends an empty datagram prefixed by a Datagram Header with an IP address and port consisting of zeroes. The client SHOULD resend the empty datagram if an UDP Association Confirmation is not received after a timeout.
The use of multicast addessses is permitted for UDP traffic only.
SOCKS options have the following format:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind | Length |
+-------------------------------+-------------------------------+
| ...
... Option Data (variable length) ...
... |
+---------------------------------------------------------------+
Figure 9: SOCKS 6 Option
Unless otherwise noted, client and proxy implementations MAY omit supporting any of the options described in this document. Upon encountering an unsupported option, a SOCKS endpoint MUST silently ignore it.
Stack options can be used by clients to alter the behavior of the protocols on top of which SOCKS is running, as well the protcols used by the proxy to communicate with the remote host (i.e. IP, TCP, UDP). A Stack option can affect either the proxy’s protocol on the client-proxy leg or on the proxy-remote leg. Clients can only place Stack options inside SOCKS Requests.
Proxies MAY choose not to honor any Stack options sent by the client.
Proxies include Stack options in their Operation Replies to signal their behavior, and MUST do so for every supported Stack option sent by the client. Said options MAY also be unsolicited, i. e. the proxy MAY send them to signal behaviour that was not explicitly requested by the client.
If a particular Stack option is unsupported, the proxy MUST silently ignore it.
In case of UDP ASSOCIATE, the stack options refer to the UDP traffic relayed by the proxy.
Stack options that are part of the same message MUST NOT contradict one another or contain duplicate information.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 1 | Length |
+---+-----------+---------------+-------------------------------+
|Leg| Level | Code | ...
+---+-----------+---------------+ ...
... ...
... Option Data (variable length) ...
... |
+---------------------------------------------------------------+
Figure 10: Stack Option
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 1 | Length = 8 |
+---+-----------+---------------+---------------+---------------+
|Leg| Level = 1 | Code = 1 | TOS | Padding = 0 |
+---+-----------+---------------+---------------+---------------+
Figure 11: IP TOS Option
The client can use IP TOS options to request that the proxy use a certain value for the IP TOS field. Likewise, the proxy can use IP TOS options to advertise the TOS values being used.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 1 | Length = 8 |
+---+-----------+---------------+-------------------------------+
| 2 | Level = 1 | Code = 2 | Padding = 0 |
+---+-----------+---------------+-------------------------------+
Figure 12: Happy Eyeballs Option
This memo provides enough features for clients to implement a mechanism analogous to Happy Eyeballs [RFC8305] over SOCKS. However, when the delay between the client and the proxy, or the proxy’s vantage point, is high, doing so can become impractical or inefficient.
In such cases, the client can instruct the proxy to employ the Happy Eyeballs technique on its behalf when connecting to a remote host.
The client MUST supply a Domain Name as part of its Request. Otherwise, the proxy MUST silently ignore the option.
TODO: Figure out which knobs to include.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 1 | Length = 8 |
+---+-----------+---------------+-------------------------------+
| 2 | Level = 4 | Code = 1 | Payload Size |
+---+-----------+---------------+-------------------------------+
Figure 13: TFO Option
If a SOCKS Request contains a TFO option, the proxy SHOULD attempt to use TFO in case of a CONNECT command, or accept TFO in case of a BIND command. Otherwise, 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 a CONNECT command, the client can indicate the desired payload size of the SYN. If the field is 0, the proxy can use an arbitrary payload size. If the field is non-zero, the proxy MUST NOT use a payload size larger than the one indicated. The proxy MAY use a smaller payload size than the one indicated.
In case of a CONNECT or BIND command, the client can inform the proxy whether MPTCP is desired on the proxy-remote leg by sending a Multipath option.
Conversely, the proxy can use a Multipath option to convey the following information: * whether or not the connection uses MPTCP or not, when replying to a CONNECT command, or in the second Operation reply to a BIND command, or * whether an MPTCP connection will be accepted, when first replying to a BIND command.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 1 | Length = 8 |
+---+-----------+---------------+---------------+---------------+
| 2 | Level = 4 | Code = 2 | Availability | Padding = 0 |
+---+-----------+---------------+---------------+---------------+
Figure 14: Multipath Option
In the absence of such an option, the proxy SHOULD NOT enable MPTCP.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 1 | Length = 8 |
+---+-----------+---------------+-------------------------------+
| 2 | Level = 4 | Code = 3 | Backlog |
+---+-----------+---------------+-------------------------------+
Figure 15: Listen Backlog Option
The default behavior of the BIND does not allow a client to simultaneously handle multiple connections to the same bind address. A client can alter BIND’s behavior by adding a TCP Listen Backlog Option to a BIND Request, provided that the Request is part of a Session.
In response, the proxy sends a TCP Listen Backlog Option as part of the Operation Reply, with the Backlog field signalling the actual backlog used. The proxy SHOULD NOT use a backlog longer than requested.
Following the successful negotiation of a backlog, the proxy listens for incoming connections for as long as the initial connection stays open. The initial connection is not used to relay data between the client and a remote host.
To accept connections, the client issues further BIND Requests using the bind address and port supplied by the proxy in the initial Operation Reply. Said BIND requests must belong to the same Session as the original Request.
If no backlog is issued, the proxy signals a backlog length of 0, and BIND’s behavior remains unaffected.
A client that is willing to go through the authentication phase MUST include an Authentication Method Advertisement option in its Request. In case of a CONNECT Request, the option is also used to specify the amount of initial data supplied before any method-specific authentication negotiations take place.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 2 | Length |
+-------------------------------+-------------------------------+
| Initial Data Length | ...
+-------------------------------+ ...
... ...
... Methods (variable length) ...
... ...
... +-----------------------------------------------+
... | Padding = 0 (variable length, 0-3 bytes) |
+---------------+-----------------------------------------------+
Figure 16: Authentication Method Advertisement Option
Clients MUST support the “No authentication required” method. Clients SHOULD omit advertising the “No authentication required” option.
The proxy indicates which authentication method must proceed by sending an Authentication Method Selection option in the corresponding Authentication Reply:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 3 | Length = 8 |
+---------------+---------------+-------------------------------+
| Method | Padding = 0 |
+---------------+-----------------------------------------------+
Figure 17: Authentication Method Selection Option
If the proxy selects “No Acceptable Methods”, the client MUST close the connection.
If authentication is successful via some other means, or not required at all, the proxy silently ignores the Authentication Method Advertisement option.
Authentication Data options carry method-specific authentication data. They can be part of SOCKS Requests and Authentication Replies.
Authentication Data options have the following format:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 4 | Length |
+---------------+---------------+-------------------------------+
| Method | ...
+---------------+ ...
... ...
... Authentication Data (variable length) ...
... |
+---------------------------------------------------------------+
Figure 18: Authentication Data Option
Clients MUST only place one Authentication Data option per authentication method.
Clients and proxies can establish SOCKS sessions, which span one or more Requests. All session-related negotiations are done via Session Options, which are placed in Requests and Authentication Replies by the client and, respectively, by the proxy.
Client and proxy implementations MUST either support all Session Option Types, or none.
A client can initiate a session by sending a Session Request Option:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 5 | Length = 4 |
+-------------------------------+-------------------------------+
Figure 19: Session Request Option
The proxy then replies with a Session ID Option in the successful Operation Reply:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 6 | Length |
+-------------------------------+-------------------------------+
| ...
... Session ID (variable length) ...
... |
+---------------------------------------------------------------+
Figure 20: Session ID Option
The Session ID serves to identify the session and is opaque to the client.
The credentials, or lack thereof, used to initiate the session are tied to the session. If authentication is to be performed for further Requests, the session is deemed “untrusted”, and the proxy also places a Session Untrusted option in the Authentication Reply:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 7 | Length = 4 |
+-------------------------------+-------------------------------+
Figure 21: Session Untrusted Option
The SOCKS Request that initiated the session is considered part of the session. A client MUST NOT attempt to initiate a session from within a different session.
If the proxy can not or will not honor the Session Request, it does so silently.
Any further SOCKS Requests that are part of the session MUST include a Session ID Option (as seen in Figure 20).
The authentication procedure is altered based on the Session ID’s validity and whether or not the Session is untrusted.
For valid Session IDs:
The proxy then replies by placing a Session OK option in the successful Authentication Reply:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 8 | Length = 4 |
+-------------------------------+-------------------------------+
Figure 22: Session OK Option
If the ticket is invalid, the first Authentication Reply MUST signal that authentication failed and can not continue (by setting the Type field to 0x01). Further, it SHALL contain a Session Invalid option:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 9 | Length = 4 |
+-------------------------------+-------------------------------+
Figure 23: Session Invalid Option
Proxies can, at their discretion, tear down a session and free all associated state. Proxy implementations SHOULD feature a timeout mechanism that destroys sessions after a period of inactivity. When a session is terminated, the proxy MAY close all connections associated with said session.
Clients can signal that a session is no longer needed, and can be torn down, by sending a Session Teardown option in addition to the Session ID option:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 10 | Length = 4 |
+-------------------------------+-------------------------------+
Figure 24: Session Teardown Option
After sending such an option, the client MUST assume that the session is no longer valid. The proxy MUST treat the connection-terminating request as if it were not part of any session.
To protect against duplicate SOCKS Requests, 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 less than y if 0 < (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.
All token-related operations are done via Idempotence options.
Idempotence options are only valid in the context of a SOCKS Session. If a SOCKS Request is not part of a Session (either by supplying a valid Session ID or successfully initiating one via a Session Request), the proxy MUST silently ignore any Idempotence options.
Token windows are tracked by the proxy on a per-session basis. There can be at most one token window for every session and its tokens can only be spent from within said session.
Client and proxy implementations MUST either support all Idempotence Option Types, or none.
A client can obtain a window of tokens by sending an Idempotence Request option as part of a SOCKS Request:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 11 | Length = 8 |
+-------------------------------+-------------------------------+
| Window Size |
+---------------------------------------------------------------+
Figure 25: Token Request
Once a token window is issued, the proxy MUST include an Idempotence Window option in all subsequent successful Authentication Replies:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 12 | Length = 12 |
+-------------------------------+-------------------------------+
| Window Base |
+---------------------------------------------------------------+
| Window Size |
+---------------------------------------------------------------+
Figure 26: Idempotence Window
If no token window is issued, the proxy MUST silently ignore the Token Request. If there is already a token window associated with the session, the proxy MUST NOT issue a new window.
The client can attempt to spend a token by including a Idempotence Expenditure option in its SOCKS request:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 13 | Length = 4 |
+-------------------------------+-------------------------------+
| Token |
+---------------------------------------------------------------+
Figure 27: Idempotence Expenditure
Clients SHOULD prioritize spending the smaller tokens.
The proxy responds by sending either an Idempotence Accepted or Rejected option as part of the Authentication Reply:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 14 | Length = 4 |
+-------------------------------+-------------------------------+
Figure 28: Idempotence Accepted
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 15 | Length = 4 |
+-------------------------------+-------------------------------+
Figure 29: Idempotence Rejected
If eligible, the token is spent before attempting to honor the Request. If the token is not eligible for spending, the Authentication Reply MUST indicate failure.
Windows can be shifted (i. e. have their base increased, while retaining their size) unilaterally by the proxy.
Proxy implementations SHOULD shift the window: * as soon as the lowest-order token in the window is spent and * when a sufficiently high-order token is spent.
Proxy implementations SHOULD NOT shift the window’s base beyond the highest unspent token.
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 Token Window Advertisements with a Window Base less than the previously known value.
Username/Password authentication is carried out as in [RFC1929].
Clients can also attempt to authenticate by placing the Username/Password request in an Authentication Data Option.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 4 | Length |
+---------------+---------------+---------------+---------------+
| Method = 2 | ...
+---------------+ ...
... ...
... Username/Password Request ...
... ...
... +-----------------------------------------------+
... | Padding = 0 (variable length, 0-3 bytes) |
+---------------+-----------------------------------------------+
Figure 30: Password authentication via a SOCKS Option
Proxies reply by including a Authentication Data Option in the next Authentication Reply which contains the Username/Password reply:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Kind = 4 | Length = 8 |
+---------------+---------------+---------------+---------------+
| Method = 2 | Username/Password Reply | Padding = 0 |
+---------------+-------------------------------+---------------+
Figure 31: Reply to password authentication via a SOCKS Option
TFO breaks TCP semantics, causing replays of the data in the SYN’s payload under certain rare circumstances [RFC7413]. A replayed SOCKS Request could itself result in a replayed connection on behalf of the client.
As such, client implementations SHOULD NOT use TFO on the client-proxy leg unless:
In case of CONNECT Requests, the client MAY start sending application data as soon as possible, as long as doing so does not incur the risk of breaking the SOCKS protocol.
Clients must work around the authentication phase by doing any of the following:
Clients may require information typically obtained from DNS servers, albeit from the proxy’s vantage point.
While the CONNECT command can work with domain names, some clients’ workflows require that addresses be resolved as a separate step prior to connecting. Moreover, the SOCKS Datagram Header, as described in Section 7.3, can be reduced in size by providing the resolved destination IP address, rather than the FQDN.
Emerging techniques may also make use of DNS to deliver server-specific information to clients. For example, Encrypted SNI [I-D.ietf-tls-esni] relies on DNS to publish encryption keys.
Proxy implementations MAY provide a default plaintext DNS service. A client looking to make use of it issues a CONNECT Request to IP address 0.0.0.0 or 0:0:0:0:0:0:0:0 on port 53. Following successful authentication, the Operation Reply indicates an unspecified bind address (0.0.0.0 or ::) and port (0). The client and proxy then behave as per [RFC7766].
The service itself can be provided directly by the proxy daemon, or by proxying the client’s request to a pre-configured DNS server.
If the proxy does not implement such functionality, it MAY return an error code signalling “Connection refused”.
Given the format of the request message, a malicious client could craft a request that is in excess of 16 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:
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, anything prior to the initial Token Request is still vulnerable. As such, client implementations SHOULD NOT make use of TLS early data unless the Request attempts to spend a token.
Malicious clients can issue a large number of Session Requests, forcing the proxy to keep large amounts of state.
To mitigate this, the proxy MAY implement policies restricting the number of concurrent sessions on a per-IP or per-user basis, or barring unauthenticated clients from establishing sessions.
This document requests that IANA allocate 2-byte option kinds for SOCKS 6 options. Further, this document requests the following option kinds:
This document also requests that IANA allocate a TCP and UDP port for SOCKS over TLS and DTLS, respectively.
The protocol described in this draft builds upon and is a direct continuation of SOCKS 5 [RFC1928].
| [RFC1929] | Leech, M., "Username/Password Authentication for SOCKS V5", RFC 1929, DOI 10.17487/RFC1929, March 1996. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7766] | Dickinson, J., Dickinson, S., Bellis, R., Mankin, A. and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016. |
| [RFC8305] | Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017. |
| [I-D.ietf-tls-dtls-connection-id] | Rescorla, E., Tschofenig, H. and T. Fossati, "Connection Identifiers for DTLS 1.2", Internet-Draft draft-ietf-tls-dtls-connection-id-07, October 2019. |
| [I-D.ietf-tls-esni] | Rescorla, E., Oku, K., Sullivan, N. and C. Wood, "Encrypted Server Name Indication for TLS 1.3", Internet-Draft draft-ietf-tls-esni-04, July 2019. |
| [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. |
| [RFC8446] | Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018. |