SOCKS Protocol Version 6University Politehnica of Bucharestvladimir.olteanu@cs.pub.roUniversity Politehnica of Bucharestdragos.niculescu@cs.pub.ro
Internet
Internet Area Working GroupInternet-DraftThe 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.Versions 4 and 5 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 , or to better assist newer transport protocols, such
as MPTCP .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
defines a zero round trip (0-RTT) handshake mode
for connections if the client and server had previously communicated.TCP Fast Open 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: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.The connection request also mimics the semantics of TCP Fast Open . As part of the connection request, the client can supply the potential payload for the initial SYN that is sent out to the server.The protocol can be extended via options without breaking backward-compatibility.The protocol can leverage the aforementioned options to support 0-RTT authentication schemes.Typos and minor clarifications are not listed.draft-03Shifted some fields in the Operation Reply to make it easier to parse.Added connection attempt timeout response code to Operation Replies.Proxies send an additional Authentication Reply after the authentication phase. (Useful for token window advertisements.)Renamed the section “Connection Requests” to “Requests”Clarified the fact that proxies don’t need to support any command in particular.Added the section “TCP Fast Open on the Client-Proxy Leg”Options:
Added constants for option kindsSalt options removed, along with the relevant section from Security Considerations. (TLS 1.3 Makes AEAD mandatory.)Limited Authentication Data options to one per method.Relaxed proxy requirements with regard to handling multiple Authentication Data options. (When the client violates the above bullet point.)Removed interdependence between Authentication Method and Authentication Data options.Clients SHOULD omit advertising the “No authentication required” option. (Was MAY.)Idempotence options:
Token Window Advertisements are now part of successful Authentication Replies (so that the proxy-server RTT has no impact on their timeliness).Proxies can’t advetise token windows of size 0.Tweaked token expenditure response codes.Support no longer mandatory on the proxy side.Revamped Socket options
Renamed Socket options to Stack options.Banned contradictory socket options.Added socket level for generic IP. Removed the “socket” socket level.Stack options no longer use option codes from setsockopt().Changed MPTCP Scheduler constants.draft-02Made support for Idempotence options mandatory for proxies.Clarified what happens when proxies can not or will not issue tokens.Limited token windows to 2^31 - 1.Fixed definition of “less than” for tokens.NOOP commands now trigger Operation Replies.Renamed Authentication options to Authentication Data options.Authentication Data options are no longer mandatory.Authentication methods are now advertised via options.Shifted some Request fields.Option range for vendor-specific options.Socket options.Password authentication.Salt options.draft-01Added this section.Support for idempotent commands.Removed version numbers from operation replies.Request port number for SOCKS over TLS. Deprecate encryption/encapsulation within SOCKS.Added Version Mismatch Replies.Renamed the AUTH command to NOOP.Shifted some fields to make requests and operation replies easier to parse.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 .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 , that
contains, in addition to fields present in SOCKS 5 , 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: The major byte MUST be set to 0x06, and the minor byte MUST be set to 0x00.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.Address Type:
0x01: IPv40x03: Domain Name0x04: IPv6Address: this field’s format depends on the address type:
IPv4: a 4-byte IPv4 addressDomain 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 addressPort: the port in network byte order.Number of Options: the number of SOCKS options that appear in the Options field.Options: see .Initial Data Size: A two-byte number in network byte order. In case of NOOP, 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.Initial Data: The first octets of the data stream.Clients can advertise their supported authentication methods by including an Authentication Method option (see ).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 ). 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: 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.Upon receipt of a valid request, the proxy sends an Authentication Reply:Version: The major byte MUST be set to 0x06, and the minor byte MUST be set to 0x00.Type:
0x00: authentication successful.0x01: further authentication needed.Method: The chosen authentication method.Number of Options: the number of SOCKS options that appear in the Options field.Options: see .Multihomed clients SHOULD cache the chosen method on a per-interface basis and SHOULD NOT include Authentication Data 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 Data option.
The client and proxy SHOULD NOT negotiate the encryption of the application data.
Descriptions of such negotiations are beyond the scope of this memo.
When the negotiation is complete (either successfully or unsuccessfully), the proxy sends another Authentication Reply.After the authentication negotiations are complete, the server sends an Operation Reply:Reply Code:
0x00: Succes0x01: General SOCKS server failure0x02: Connection not allowed by ruleset0x03: Network unreachable0x04: Host unreachable0x05: Connection refused0x06: TTL expired0x07: Command not supported0x08: Address type not supported0x09: Connection attempt timed outInitial 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.Bind Port: the proxy bound port in network byte order.Address Type:
0x01: IPv40x03: Domain Name0x04: IPv6Bind Address: the proxy bound address in the following format:
IPv4: a 4-byte IPv4 addressDomain 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 addressNumber of Options: the number of SOCKS options that appear in the Options field.Options: see .Proxy implementations MAY support any subset of the client commands listed in .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. 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 .SOCKS options have the following format:Kind: MUST be allocated by IANA. (See .)Length: The length of the option.Option Data: The contents are specific to each option kind.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 server (i.e. IP, TCP, UDP).
A Stack option can affect either the proxy’s protocol on the client-proxy leg or on the proxy-server leg.
Clients can only place Stack options inside SOCKS Requests.Proxies MAY include Stack options in their Operation Replies to signal their behavior.
Said options MAY be unsolicited, i. e. the proxy MAY send them to signal behaviour that was not explicitly
requested by the client.Stack options that are part of the same message MUST NOT contradict one another.Kind: 0x01 (Stack option)Length: The length of the option.Leg:
0x1: Client-Proxy Leg0x2: Proxy-Server Leg0x3: Both LegsLevel:
0x01: IP0x02: IPv40x03: IPv60x04: TCP0x05: UDPCode: Option codeData: Option-specific dataKind: 0x01 (Stack option)Length: MUST be 4.Leg: MUST be 0x2 (Proxy-Server Leg).Level: 0x04 (TCP).Code: 0x01If 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 proxy MAY include a TFO option in the Operation reply if TFO was attempted, the operation succeded and the remote server supports TFO.
In case of a BIND command, the proxy MAY include a TFO option in the first Operation reply to signal that it will accept an incoming TFO connection.In case of a CONNECT command, the proxy can inform the client that the connection to the server is an MPTCP connection.Kind: 0x01 (Stack option)Length: 4.Leg: MUST be 0x2 (Proxy-Server Leg).Level: 0x04 (TCP).Code: 0x02In case of a CONNECT or BIND command, a client can use an MPTCP Scheduler option to indicate its preferred scheduler for the connection.A proxy can use an MPTCP Scheduler option to inform the client about what scheduler is in use.Kind: 0x01 (Stack option)Length: MUST be 5.Leg: Either 0x01, 0x02, or 0x03 (Client-Proxy, Proxy-Client or Both legs).Level: 0x04 (TCP).Code: 0x03Scheduler:
0x01: Default0x02: Round-Robin0x03: RedundantAuthentication Method options are used by clients to advertise supported authentication methods. They can be part of SOCKS Requests.Kind: 0x02 (Authentication Method option)Length: The length of the option.Methods: One byte per advertised method. Method numbers are assigned by IANA.Clients MUST support the “No authentication required” method. Clients SHOULD omit advertising the “No authentication required” 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:Kind: 0x03 (Authentication Data option)Length: The length of the option.Method: The number of the authentication method. These numbers are assigned by IANA.Authentication Data: The contents are specific to each method.Clients SHOULD only place one Authentication Data option per authentication method. Server implementations MAY silently ignore all Authentication Data options for the same method aside from an arbitrarily chosen one.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 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.
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: 0x04 (Idempotence option)Length: The length of the option.Type:
0x00: Token Request0x01: Token Window Advertisement0x02: Token Expenditure0x03: Token Expenditure ReplyOption Data: The contents are specific to each type.A client can obtain a fresh window of tokens by sending a Token Request option as part of a SOCKS Request:Kind: MUST be allocated by IANA. (See .)Length: 7Type: 0x00 (Token Request)Window Size: The requested window size.If a token window is issued, the proxy then includes a Token Window Advertisement option in the corresponding successful Authentication Reply:Kind: 0x04 (Idempotence option)Length: 11Type: 0x01 (Token Grant)Window Base: The first token in the window.Window Size: The window size. This value SHOULD be lower or equal to the requested window size. Window sizes MUST be less than 2^31. Window sizes MUST NOT be 0.If no token window is issued, the proxy MUST silently ignore the Token Request.The client can attempt to spend a token by including a Token Expenditure option in its SOCKS request:Kind: 0x04 (Idempotence option)Length: 7Type: 0x02 (Token Expenditure)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:Kind: 0x04 (Idempotence option)Length: 4Type: 0x03 (Token Expenditure Response)Response Code:
0x01: Success: The token was spent successfully.0x02: No Window: The proxy does not have a token window associated with the client.0x03: Out of Window: The token is not within the window.0x04: 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:the token is out of window, orby 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 Authentication Reply that indicates success.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.Username/Password authentication is carried out as in .Clients can also attempt to authenticate by placing the Username/Password
request in an Authentication Data Option, provided that it is no longer than 252 bytes.Kind: MUST be allocated by IANA. (See .)Length: The length of the option.Method: 0x02 (Username/Password).Username/Password request: The Username/Password request, as described in .TFO breaks TCP semantics, causing replays of the data in the SYN’s payload under certain rare circumstances .
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:
* The protocol running on top of SOCKS tolerates the risks of TFO, or
* The SYN’s payload does not contain any application data (so that no data is replayed to the server, even though duplicate connections are still possible), or
* The client uses Idempotence Options, making replays impossible, or
* SOCKS is running on top of TLS and Early Data is not used.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:the request is not fully received after a certain timeout, orthe number of options exceeds an imposed hard cap, orthe total size of the options exceeds an imposed hard cap, orthe 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.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 1-byte option kinds for SOCKS 6 options. Further, this document requests the following option kinds:Stack options: 0x01Authentication Method options: 0x02Authentication Data options: 0x03Idempotence options: 0x04A range for vendor-specific optionsThis 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 .Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Username/Password Authentication for SOCKS V5The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK]SOCKS Protocol Version 5This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]TCP Fast OpenThis document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.TCP Extensions for Multipath Operation with Multiple AddressesTCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 4492, 5705, and 6066 and it obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.