< draft-olteanu-intarea-socks-6-06.txt   draft-olteanu-intarea-socks-6-07.txt >
Internet Area Working Group V. Olteanu Internet Area Working Group V. Olteanu
Internet-Draft D. Niculescu Internet-Draft D. Niculescu
Intended status: Experimental University Politehnica of Bucharest Intended status: Experimental University Politehnica of Bucharest
Expires: September 12, 2019 March 11, 2019 Expires: January 9, 2020 July 08, 2019
SOCKS Protocol Version 6 SOCKS Protocol Version 6
draft-olteanu-intarea-socks-6-06 draft-olteanu-intarea-socks-6-07
Abstract Abstract
The SOCKS protocol is used primarily to proxy TCP connections to The SOCKS protocol is used primarily to proxy TCP connections to
arbitrary destinations via the use of a proxy server. Under the 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 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 authentication is used) before data can flow between the client and
the server. the server.
This memo proposes SOCKS version 6, which reduces the number of RTTs This memo proposes SOCKS version 6, which reduces the number of RTTs
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Revision log . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Revision log . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements language . . . . . . . . . . . . . . . . . . . . 8 2. Requirements language . . . . . . . . . . . . . . . . . . . . 9
3. Mode of operation . . . . . . . . . . . . . . . . . . . . . . 8 3. Mode of operation . . . . . . . . . . . . . . . . . . . . . . 9
4. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Version Mismatch Replies . . . . . . . . . . . . . . . . . . 12 5. Version Mismatch Replies . . . . . . . . . . . . . . . . . . 13
6. Authentication Replies . . . . . . . . . . . . . . . . . . . 12 6. Authentication Replies . . . . . . . . . . . . . . . . . . . 13
7. Operation Replies . . . . . . . . . . . . . . . . . . . . . . 13 7. Operation Replies . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Handling CONNECT . . . . . . . . . . . . . . . . . . . . 14 7.1. Handling CONNECT . . . . . . . . . . . . . . . . . . . . 16
7.2. Handling BIND . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Handling BIND . . . . . . . . . . . . . . . . . . . . . . 16
7.3. Handling UDP ASSOCIATE . . . . . . . . . . . . . . . . . 15 7.3. Handling UDP ASSOCIATE . . . . . . . . . . . . . . . . . 16
7.3.1. Proxying UDP servers . . . . . . . . . . . . . . . . 17 7.3.1. Proxying UDP servers . . . . . . . . . . . . . . . . 18
8. SOCKS Options . . . . . . . . . . . . . . . . . . . . . . . . 17 7.3.2. Proxying multicast traffic . . . . . . . . . . . . . 18
8.1. Stack options . . . . . . . . . . . . . . . . . . . . . . 17 8. SOCKS Options . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1.1. IP TOS options . . . . . . . . . . . . . . . . . . . 19 8.1. Stack options . . . . . . . . . . . . . . . . . . . . . . 19
8.1.2. TFO options . . . . . . . . . . . . . . . . . . . . . 19 8.1.1. IP TOS options . . . . . . . . . . . . . . . . . . . 20
8.1.3. Multipath TCP options . . . . . . . . . . . . . . . . 20 8.1.2. TFO options . . . . . . . . . . . . . . . . . . . . . 21
8.1.4. MPTCP Scheduler options . . . . . . . . . . . . . . . 20 8.1.3. Multipath options . . . . . . . . . . . . . . . . . . 22
8.1.5. Listen Backlog options . . . . . . . . . . . . . . . 21 8.1.4. Listen Backlog options . . . . . . . . . . . . . . . 22
8.2. Authentication Method options . . . . . . . . . . . . . . 22 8.2. Authentication Method options . . . . . . . . . . . . . . 23
8.3. Authentication Data options . . . . . . . . . . . . . . . 23 8.3. Authentication Data options . . . . . . . . . . . . . . . 25
8.4. Session options . . . . . . . . . . . . . . . . . . . . . 24 8.4. Session options . . . . . . . . . . . . . . . . . . . . . 25
8.4.1. Session initiation . . . . . . . . . . . . . . . . . 24 8.4.1. Session initiation . . . . . . . . . . . . . . . . . 26
8.4.2. Further SOCKS Requests . . . . . . . . . . . . . . . 26 8.4.2. Further SOCKS Requests . . . . . . . . . . . . . . . 27
8.4.3. Tearing down the session . . . . . . . . . . . . . . 27 8.4.3. Tearing down the session . . . . . . . . . . . . . . 28
8.5. Idempotence options . . . . . . . . . . . . . . . . . . . 28 8.5. Idempotence options . . . . . . . . . . . . . . . . . . . 28
8.5.1. Requesting a fresh token window . . . . . . . . . . . 29 8.5.1. Requesting a token window . . . . . . . . . . . . . . 29
8.5.2. Spending a token . . . . . . . . . . . . . . . . . . 30 8.5.2. Spending a token . . . . . . . . . . . . . . . . . . 30
8.5.3. Handling Token Window Advertisements . . . . . . . . 32 8.5.3. Shifting windows . . . . . . . . . . . . . . . . . . 31
9. Username/Password Authentication . . . . . . . . . . . . . . 32 8.5.4. Out-of-order Window Advertisements . . . . . . . . . 31
10. TCP Fast Open on the Client-Proxy Leg . . . . . . . . . . . . 32 8.6. Address Resolution Options . . . . . . . . . . . . . . . 31
11. False Starts . . . . . . . . . . . . . . . . . . . . . . . . 33 8.6.1. Forward resolution . . . . . . . . . . . . . . . . . 31
12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 8.6.2. Reverse resolution . . . . . . . . . . . . . . . . . 32
12.1. Large requests . . . . . . . . . . . . . . . . . . . . . 33 9. Username/Password Authentication . . . . . . . . . . . . . . 33
12.2. Replay attacks . . . . . . . . . . . . . . . . . . . . . 34 10. TCP Fast Open on the Client-Proxy Leg . . . . . . . . . . . . 34
12.3. Resource exhaustion . . . . . . . . . . . . . . . . . . 34 11. False Starts . . . . . . . . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 12.1. Large requests . . . . . . . . . . . . . . . . . . . . . 35
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 12.2. Replay attacks . . . . . . . . . . . . . . . . . . . . . 35
15.1. Normative References . . . . . . . . . . . . . . . . . . 35 12.3. Resource exhaustion . . . . . . . . . . . . . . . . . . 35
15.2. Informative References . . . . . . . . . . . . . . . . . 35 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.1. Normative References . . . . . . . . . . . . . . . . . . 37
15.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
Versions 4 and 5 [RFC1928] of the SOCKS protocol were developed two Versions 4 and 5 [RFC1928] of the SOCKS protocol were developed two
decades ago and are in widespread use for circuit level gateways or decades ago and are in widespread use for circuit level gateways or
as circumvention tools, and enjoy wide support and usage from various as circumvention tools, and enjoy wide support and usage from various
software, such as web browsers, SSH clients, and proxifiers. software, such as web browsers, SSH clients, and proxifiers.
However, their design needs an update in order to take advantage of However, their design needs an update in order to take advantage of
the new features of transport protocols, such as TCP Fast Open the new features of transport protocols, such as TCP Fast Open
[RFC7413], or to better assist newer transport protocols, such as [RFC7413], or to better assist newer transport protocols, such as
skipping to change at page 4, line 12 skipping to change at page 4, line 15
o The protocol can be extended via options without breaking o The protocol can be extended via options without breaking
backward-compatibility. backward-compatibility.
o The protocol can leverage the aforementioned options to support o The protocol can leverage the aforementioned options to support
0-RTT authentication schemes. 0-RTT authentication schemes.
1.1. Revision log 1.1. Revision log
Typos and minor clarifications are not listed. Typos and minor clarifications are not listed.
draft-07
o All fields are now alignned.
o Eliminated version minors
o Lots of changes to options
* 2-byte option kinds
* Flattened option kinds/types/reply codes; also renamed some
options
* Socket options
+ Proxies MUST always answer them (Clients can probe for
support)
+ MPTCP Options: expanded functionality ("please do/don't do
MPTCP on my behalf")
+ MPTCP Scheduler options removed
+ Listen Backlog options: code changed to 0x03
* Revamped Idempotence options
* Auth data options limited to one per method
o Authentication Reply: all authentication-related information is
now in the options
* Authentication replies no longer have a field indicating the
chosen auth. method
* Method that must proceed (or whereby authentication succeeded)
indicated in options
* Username/password authentication: proxy now sends reply in
option
o Removed requirements w.r.t. caching authentication methods by
multihomed clients
o UDP: 8-byte association IDs
o Sessions
* The proxy is now free to terminate ongoing connections along
with the session.
* The session-terminating request is not part of the session that
it terminated.
o Address Resolution options
draft-06 draft-06
o Session options o Session options
o Options now have a 2-byte length field. o Options now have a 2-byte length field.
o Stack options o Stack options
* Stack options can no longer contain duplicate information. * Stack options can no longer contain duplicate information.
skipping to change at page 9, line 20 skipping to change at page 10, line 20
| Port | | Port |
| Options | | Options |
+------------------------+ +------------------------+
+------------------------+ +------------------------+
--------> Initial data +------------------------------> --------> Initial data +------------------------------>
+------------------------+ +------------------------+
+-----------------------+ +-----------------------+
Authentication Reply | Type | Authentication Reply | Type |
<----------------------------------+ Method <----- <----------------------------------+ Options <-----
| Options |
+-----------------------+ +-----------------------+
<-------------------(Authentication protocol)------------------> <-------------------(Authentication protocol)------------------>
+-----------------------+ +-----------------------+
Authentication Reply | Type = Success | Authentication Reply | Type = Success |
<----------------------------------+ Method <----- <----------------------------------+ Options <-----
| Options |
+-----------------------+ +-----------------------+
+-----------------------+ +-----------------------+
Operation Reply | Reply code | Operation Reply | Reply code |
<--------------------+ Bind address <------------------ <--------------------+ Bind address <------------------
| Bind port | | Bind port |
| Options | | Options |
+-----------------------+ +-----------------------+
Figure 1: The SOCKS version 6 protocol message exchange Figure 1: The SOCKS version 6 protocol message exchange
skipping to change at page 10, line 25 skipping to change at page 11, line 23
In the fast case, when authentication is properly set up, the proxy In the fast case, when authentication is properly set up, the proxy
attempts to create the socket immediately after the receipt of the attempts to create the socket immediately after the receipt of the
request, thus achieving an operational conection in one RTT (provided request, thus achieving an operational conection in one RTT (provided
TFO functionality is available at the client, proxy, and server). TFO functionality is available at the client, proxy, and server).
4. Requests 4. Requests
The client starts by sending a request to the proxy. The client starts by sending a request to the proxy.
+---------------+---------+------+---------+----------+ 1 2 3
| Version | Command | Port | Address | Address | 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
| Major | Minor | Code | | Type | | +---------------+---------------+-------------------------------+
+-------+-------+---------+------+---------+----------+ | Version = 6 | Command Code | Options Length |
| 1 | 1 | 1 | 2 | 1 | Variable | +---------------+---------------+---------------+---------------+
+-------+-------+---------+------+---------+----------+ | Port | Padding = 0 | Address Type |
+---------+----------+ +-------------------------------+---------------+---------------+
| Options | Options | | ...
| Length | | ... Address (variable length) ...
+---------+----------+ ... |
| 2 | Variable | +---------------------------------------------------------------+
+---------+----------+ | ...
... Options (variable length) ...
... |
+---------------------------------------------------------------+
Figure 2: SOCKS 6 Request Figure 2: SOCKS 6 Request
o Version: The major byte is 0x06, and the minor byte is 0x00. o Version: 6
o Command Code: o Command Code:
* 0x00 NOOP: does nothing. * 0x00 NOOP: does nothing.
* 0x01 CONNECT: requests the establishment of a TCP connection. * 0x01 CONNECT: requests the establishment of a TCP connection.
TFO MUST NOT be used unless explicitly requested. TFO MUST NOT be used unless explicitly requested.
* 0x02 BIND: requests the establishment of a TCP port binding. * 0x02 BIND: requests the establishment of a TCP port binding.
skipping to change at page 11, line 20 skipping to change at page 12, line 20
* 0x03: Domain Name * 0x03: Domain Name
* 0x04: IPv6 * 0x04: IPv6
o Address: this field's format depends on the address type: o Address: this field's format depends on the address type:
* IPv4: a 4-byte IPv4 address * IPv4: a 4-byte IPv4 address
* Domain Name: one byte that contains the length of the FQDN, * Domain Name: one byte that contains the length of the FQDN,
followed by the FQDN itself. The string is not NUL-terminated. followed by the FQDN itself. The string is not NUL-terminated,
but padded by NUL characters, if needed.
* IPv6: a 16-byte IPv6 address * IPv6: a 16-byte IPv6 address
o Port: the port in network byte order. o Port: the port in network byte order.
o Padding: set to 0
o Options Length: the total size of the SOCKS options that appear in o Options Length: the total size of the SOCKS options that appear in
the Options field. MUST NOT exceed 16KB. the Options field. MUST NOT exceed 16KB.
o Options: see Section 8. o Options: see Section 8.
The Address and Port fields have different meanings based on the The Address and Port fields have different meanings based on the
Command Code: Command Code:
o NOOP: The fields have no meaning. The Address Type field MUST be o NOOP: The fields have no meaning. The Address Type field MUST be
either 0x01 (IPv4) or 0x04 (IPv6). The Address and Port fields either 0x01 (IPv4) or 0x04 (IPv6). The Address and Port fields
skipping to change at page 11, line 48 skipping to change at page 12, line 51
o CONNECT: The fields signify the address and port to which the o CONNECT: The fields signify the address and port to which the
client wishes to connect. client wishes to connect.
o BIND, UDP ASSOCIATE: The fields indicate the desired bind address o BIND, UDP ASSOCIATE: The fields indicate the desired bind address
and port. If the client does not require a certain address, it and port. If the client does not require a certain address, it
can set the Address Type field to 0x01 (IPv4) or 0x04 (IPv6), and can set the Address Type field to 0x01 (IPv4) or 0x04 (IPv6), and
the Address field to 0. Likewise, if the client does not require the Address field to 0. Likewise, if the client does not require
a certain port, it can set the Port field to 0. a certain port, it can set the Port field to 0.
Clients can advertise their supported authentication methods by Clients can advertise their supported authentication methods by
including an Authentication Method option (see Section 8.2). including an Authentication Method Advertisement option (see
Section 8.2).
5. Version Mismatch Replies 5. Version Mismatch Replies
Upon receipt of a request starting with a version number other than Upon receipt of a request starting with a version number other than
6.0, the proxy sends the following response: 6, the proxy sends the following response:
0 1 2 3 4 5 6 7
+---------------+
| Version = 6 |
+---------------+ +---------------+
| Version |
| Major | Minor |
+-------+-------+
| 1 | 1 |
+-------+-------+
Figure 3: SOCKS 6 Version Mismatch Reply Figure 3: SOCKS 6 Version Mismatch Reply
o Version: The major byte is 0x06, and the minor byte is 0x00. o Version: 6
A client MUST close the connection after receiving such a reply. A client MUST close the connection after receiving such a reply.
6. Authentication Replies 6. Authentication Replies
Upon receipt of a valid request, the proxy sends an Authentication Upon receipt of a valid request, the proxy sends an Authentication
Reply: Reply:
+---------------+------+--------+---------+----------+ 1 2 3
| Version | Type | Method | Options | Options | 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
| Major | Minor | | | Length | | +---------------+---------------+-------------------------------+
+-------+-------+------+--------+---------+----------+ | Version = 6 | Type | Options Length |
| 1 | 1 | 1 | 1 | 2 | Variable | +---------------+---------------+-------------------------------+
+-------+-------+------+--------+---------+----------+ | ...
... Options (variable length) ...
... |
+---------------------------------------------------------------+
Figure 4: SOCKS 6 Authentication Reply Figure 4: SOCKS 6 Authentication Reply
o Version: The major byte is 0x06, and the minor byte is 0x00. o Version: 6
o Type: o Type:
* 0x00: authentication successful. * 0x00: authentication successful.
* 0x01: further authentication needed. * 0x01: authentication failed.
o Method: The chosen authentication method.
o Options Length: the total size of the SOCKS options that appear in o Options Length: the total size of the SOCKS options that appear in
the Options field. MUST NOT exceed 16KB. the Options field. MUST NOT exceed 16KB.
o Options: see Section 8. o Options: see Section 8.
Multihomed clients SHOULD cache the chosen method on a per-interface If the server signals that the authentication has failed and does not
basis and SHOULD NOT include Authentication Data options related to signal that any authentication negotiation can continue (via an
any other methods in further requests originating from the same Authentication Method Selection option), the client MUST close the
interface.
If the server signals that further authentication is needed and
selects "No Acceptable Methods", the client MUST close the
connection. connection.
The client and proxy begin a method-specific negotiation. During The client and proxy begin a method-specific negotiation. During
such negotiations, the proxy MAY supply information that allows the such negotiations, the proxy MAY supply information that allows the
client to authenticate a future request using an Authentication Data client to authenticate a future request using an Authentication Data
option. Application data is not subject to any encryption negotiated option. Application data is not subject to any encryption negotiated
during this phase. Descriptions of such negotiations are beyond the during this phase. Descriptions of such negotiations are beyond the
scope of this memo. scope of this memo.
When the negotiation is complete (either successfully or When the negotiation is complete (either successfully or
unsuccessfully), the proxy sends a second Authentication Reply. The unsuccessfully), the proxy sends a second Authentication Reply. The
second Authentication Reply MUST either signal success or that there second Authentication Reply MUST NOT allow for further negotiations.
are no more acceptable authentication methods.
7. Operation Replies 7. Operation Replies
After the authentication negotiations are complete, the proxy sends After the authentication negotiations are complete, the proxy sends
an Operation Reply: an Operation Reply:
+-------+------+---------+----------+---------+----------+ 1 2 3
| Reply | Bind | Address | Bind | Options | Options | 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
| Code | Port | Type | Address | Length | | +---------------+---------------+-------------------------------+
+-------+------+---------+----------+---------+----------+ | Version = 6 | Reply Code | Options Length |
| 1 | 2 | 1 | Variable | 2 | Variable | +---------------+---------------+---------------+---------------+
+-------+------+---------+----------+---------+----------+ | Bind Port | Padding = 0 | Address Type |
+-------------------------------+---------------+---------------+
| ...
... Bind Address (variable length) ...
... |
+---------------------------------------------------------------+
| ...
... Options (variable length) ...
... |
+---------------------------------------------------------------+
Figure 5: SOCKS 6 Operation Reply Figure 5: SOCKS 6 Operation Reply
o Version: 6
o Reply Code: o Reply Code:
* 0x00: Succes * 0x00: Succes
* 0x01: General SOCKS server failure * 0x01: General SOCKS server failure
* 0x02: Connection not allowed by ruleset * 0x02: Connection not allowed by ruleset
* 0x03: Network unreachable * 0x03: Network unreachable
* 0x04: Host unreachable * 0x04: Host unreachable
* 0x05: Connection refused * 0x05: Connection refused
* 0x06: TTL expired * 0x06: TTL expired
* 0x07: Command not supported * 0x07: Command not supported
* 0x08: Address type not supported * 0x08: Address type not supported
* 0x09: Connection attempt timed out * 0x09: Connection attempt timed out
skipping to change at page 14, line 16 skipping to change at page 15, line 22
* 0x06: TTL expired * 0x06: TTL expired
* 0x07: Command not supported * 0x07: Command not supported
* 0x08: Address type not supported * 0x08: Address type not supported
* 0x09: Connection attempt timed out * 0x09: Connection attempt timed out
o Bind Port: the proxy bound port in network byte order. o Bind Port: the proxy bound port in network byte order.
o Padding: set to 0
o Address Type: o Address Type:
* 0x01: IPv4 * 0x01: IPv4
* 0x03: Domain Name * 0x03: Domain Name
* 0x04: IPv6 * 0x04: IPv6
o Bind Address: the proxy bound address in the following format: o Bind Address: the proxy bound address in the following format:
* IPv4: a 4-byte IPv4 address * IPv4: a 4-byte IPv4 address
* Domain Name: one byte that contains the length of the FQDN, * Domain Name: one byte that contains the length of the FQDN,
followed by the FQDN itself. The string is not NUL-terminated. followed by the FQDN itself. The string is not NUL-terminated,
but padded by NUL characters, if needed.
* IPv6: a 16-byte IPv6 address * IPv6: a 16-byte IPv6 address
o Options Length: the total size of the SOCKS options that appear in o Options Length: the total size of the SOCKS options that appear in
the Options field. MUST NOT exceed 16KB. the Options field. MUST NOT exceed 16KB.
o Options: see Section 8. o Options: see Section 8.
Proxy implementations MAY support any subset of the client commands Proxy implementations MAY support any subset of the client commands
listed in Section 4. listed in Section 4.
skipping to change at page 15, line 22 skipping to change at page 16, line 29
7.3. Handling UDP ASSOCIATE 7.3. Handling UDP ASSOCIATE
Proxies offering UDP functionality must be configured with a UDP port 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 UDP datagrams to and from the client, and/or a port
used for relaying datagrams over DTLS. used for relaying datagrams over DTLS.
Following a successful Operation Reply, the proxy sends a UDP Following a successful Operation Reply, the proxy sends a UDP
Association Initialization message: Association Initialization message:
+----------------+ 1 2 3
| Association ID | 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
+----------------+ +---------------------------------------------------------------+
| 4 | | Association ID |
+----------------+ | (8 bytes) |
+---------------------------------------------------------------+
Figure 6: UDP Association Initialization Figure 6: UDP Association Initialization
o Association ID: the identifier of the UDP association o Association ID: the identifier of the UDP association
Proxy implementations SHOULD generate Association IDs randomly or Proxy implementations SHOULD generate Association IDs randomly or
pseudo-randomly. pseudo-randomly.
Clients may start sending UDP datagrams to the proxy either in Clients may start sending UDP datagrams to the proxy either in
plaintext, or over an established DTLS session, using the proxy's plaintext, or over an established DTLS session, using the proxy's
configured UDP ports. A client's datagrams are prefixed by a SOCKS configured UDP ports. A client's datagrams are prefixed by a SOCKS
Datagram Header, indicating the remote host's address and port: Datagram Header, indicating the remote host's address and port:
+---------------+-------------+------+---------+----------+ 1 2 3
| Version | Association | Port | Address | Address | 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
| Major | Minor | ID | | Type | | +---------------+---------------+-------------------------------+
+-------+-------+-------------+------+---------+----------+ | Version = 6 | Address Type | Port |
| 1 | 1 | 4 | 2 | 1 | Variable | +---------------+---------------+-------------------------------+
+-------+-------+-------------+------+---------+----------+ | Association ID |
| (8 bytes) |
+---------------------------------------------------------------+
| ...
... Address (variable length) ...
... |
+---------------------------------------------------------------+
Figure 7: SOCKS 6 Datagram Header Figure 7: SOCKS 6 Datagram Header
o Version: The major byte is 0x06, and the minor byte is 0x00. o Version: 0x06
o Association ID: the identifier of the UDP association o Association ID: the identifier of the UDP association
o Address Type: o Address Type:
* 0x01: IPv4 * 0x01: IPv4
* 0x03: Domain Name * 0x03: Domain Name
* 0x04: IPv6 * 0x04: IPv6
skipping to change at page 16, line 42 skipping to change at page 18, line 11
o the DTLS connection, if the datagram was received over DTLS. The o the DTLS connection, if the datagram was received over DTLS. The
DTLS connection is identified either by its 5-tuple, or some other DTLS connection is identified either by its 5-tuple, or some other
mechanism, like [I-D.ietf-tls-dtls-connection-id]. mechanism, like [I-D.ietf-tls-dtls-connection-id].
Further datagrams carrying the same Association ID, but not matching Further datagrams carrying the same Association ID, but not matching
the established mapping, are silently dropped. the established mapping, are silently dropped.
The proxy then sends an UDP Association Confirmation message over the The proxy then sends an UDP Association Confirmation message over the
TCP connection with the client: TCP connection with the client:
+--------+ 0 1 2 3 4 5 6 7
| Status | +---------------+
+--------+ | Status = 0 |
| 1 | +---------------+
+--------+
Figure 8: UDP Association Confirmation Figure 8: UDP Association Confirmation
o Status: MUST be 0x00 o Status: MUST be 0x00
Following the confirmation message, UDP packets bound for the proxy's Following the confirmation message, UDP packets bound for the proxy's
bind address and port are relayed to the client, also prefixed by a bind address and port are relayed to the client, also prefixed by a
Datagram Header. Datagram Header.
The UDP association remains active for as long as the TCP connection The UDP association remains active for as long as the TCP connection
between the client and the proxy is kept open. between the client and the proxy is kept open.
7.3.1. Proxying UDP servers 7.3.1. Proxying UDP servers
Under some circumstances (e.g. when hosting a server), the SOCKS Under some circumstances (e.g. when hosting a server), the SOCKS
skipping to change at page 17, line 23 skipping to change at page 18, line 39
Under some circumstances (e.g. when hosting a server), the SOCKS Under some circumstances (e.g. when hosting a server), the SOCKS
client expects the remote host to send UDP datagrams first. As such, client expects the remote host to send UDP datagrams first. As such,
the SOCKS client must trigger a UDP Association Confirmation without the SOCKS client must trigger a UDP Association Confirmation without
having the proxy relay any datagrams on its behalf. having the proxy relay any datagrams on its behalf.
To that end, it sends an empty datagram prefixed by a Datagram Header 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 with an IP address and port consisting of zeroes. The client SHOULD
resend the empty datagram if an UDP Association Confirmation is not resend the empty datagram if an UDP Association Confirmation is not
received after a timeout. received after a timeout.
7.3.2. Proxying multicast traffic
The use of multicast addessses is permitted for UDP traffic only.
8. SOCKS Options 8. SOCKS Options
SOCKS options have the following format: SOCKS options have the following format:
+------+--------+-------------+ 1 2 3
| Kind | Length | Option Data | 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
+------+--------+-------------+ +-------------------------------+-------------------------------+
| 1 | 2 | Variable | | Kind | Length |
+------+--------+-------------+ +-------------------------------+-------------------------------+
| ...
... Option Data (variable length) ...
... |
+---------------------------------------------------------------+
Figure 9: SOCKS 6 Option Figure 9: SOCKS 6 Option
o Kind: Allocated by IANA. (See Section 13.) o Kind: Allocated by IANA. (See Section 13.)
o Length: The total length of the option. o Length: The total length of the option. MUST be a multiple of 4.
o Option Data: The contents are specific to each option kind. o Option Data: The contents are specific to each option kind.
Unless otherwise noted, client and proxy implementations MAY omit Unless otherwise noted, client and proxy implementations MAY omit
supporting any of the options described in this document. Upon supporting any of the options described in this document. Upon
encountering an unsupported option, a SOCKS endpoint MUST silently encountering an unsupported option, a SOCKS endpoint MUST silently
ignore it. ignore it.
8.1. Stack options 8.1. Stack options
Stack options can be used by clients to alter the behavior of the 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 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, 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 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 client-proxy leg or on the proxy-remote leg. Clients can only place
Stack options inside SOCKS Requests. Stack options inside SOCKS Requests.
Proxies MAY include Stack options in their Operation Replies to Proxies MAY choose not to honor any Stack options sent by the client.
signal their behavior. Said options MAY be unsolicited, i. e. the
proxy MAY send them to signal behaviour that was not explicitly Proxies include Stack options in their Operation Replies to signal
requested by the client. 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 In case of UDP ASSOCIATE, the stack options refer to the UDP traffic
relayed by the proxy. relayed by the proxy.
Stack options that are part of the same message MUST NOT contradict Stack options that are part of the same message MUST NOT contradict
one another or contain duplicate information. one another or contain duplicate information.
+------+--------+--------+--------+------+----------+ 1 2 3
| Kind | Length | Leg | Level | Code | Data | 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
+------+--------+--------+--------+------+----------+ +-------------------------------+-------------------------------+
| 1 | 2 | 2 bits | 6 bits | 1 | Variable | | Kind = 1 | Length |
+------+--------+--------+--------+------+----------+ +---+-----------+---------------+-------------------------------+
|Leg| Level | Code | ...
+---+-----------+---------------+ ...
... ...
... Option Data (variable length) ...
... |
+---------------------------------------------------------------+
Figure 10: Stack Option Figure 10: Stack Option
o Kind: 0x01 (Stack option)
o Length: The length of the option.
o Leg: o Leg:
* 0x1: Client-Proxy Leg * 1: Client-Proxy Leg
* 0x2: Proxy-Remote Leg * 2: Proxy-Remote Leg
* 0x3: Both Legs * 3: Both Legs
o Level: o Level:
* 0x01: IP: options that apply to either IPv4 or IPv6 * 1: IP: options that apply to either IPv4 or IPv6
* 0x02: IPv4 * 2: IPv4
* 0x03: IPv6 * 3: IPv6
* 0x04: TCP * 4: TCP
* 0x05: UDP * 5: UDP
o Code: Option code o Code: Option code
o Data: Option-specific data o Option Data: Option-specific data
8.1.1. IP TOS options 8.1.1. IP TOS options
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 | Leg | Level | Code | TOS | +-------------------------------+-------------------------------+
+------+--------+--------+--------+------+-----+ | Kind = 1 | Length = 8 |
| 1 | 2 | 2 bits | 6 bits | 1 | 1 | +---+-----------+---------------+---------------+---------------+
+------+--------+--------+--------+------+-----+ |Leg| Level = 1 | Code = 1 | TOS | Padding = 0 |
+---+-----------+---------------+---------------+---------------+
Figure 11: IP TOS Option Figure 11: IP TOS Option
o Kind: 0x01 (Stack option)
o Length: 4
o Leg: Either 0x01, 0x02, or 0x03 (Client-Proxy, Proxy-Remote or
Both legs)
o Level: 0x04 (TCP).
o Code: 0x01
o TOS: The IP TOS code o TOS: The IP TOS code
The client can use IP TOS options to request that the proxy use a 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 certain value for the IP TOS field. Likewise, the proxy can use IP
TOS options to advertise the TOS values being used. TOS options to advertise the TOS values being used.
8.1.2. TFO options 8.1.2. TFO options
+------+--------+--------+--------+------+--------------+ 1 2 3
| Kind | Length | Leg | Level | Code | Payload Size | 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
+------+--------+--------+--------+------+--------------+ +-------------------------------+-------------------------------+
| 1 | 2 | 2 bits | 6 bits | 1 | 2 | | Kind = 1 | Length = 8 |
+------+--------+--------+--------+------+--------------+ +---+-----------+---------------+-------------------------------+
|Leg| Level = 4 | Code = 1 | Payload Size |
+---+-----------+---------------+-------------------------------+
Figure 12: TFO Option Figure 12: TFO Option
o Kind: 0x01 (Stack option)
o Length: 4
o Leg: 0x02 (Proxy-Remote leg). o Leg: 0x02 (Proxy-Remote leg).
o Level: 0x04 (TCP).
o Code: 0x01
o Payload Size: The desired payload size of the TFO SYN. Ignored in o Payload Size: The desired payload size of the TFO SYN. Ignored in
case of a BIND command. case of a BIND command.
If a SOCKS Request contains a TFO option, the proxy SHOULD attempt to 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 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 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. a CONNECT command, or accept TFO in case of a BIND command.
In case of a CONNECT command, the client can indicate the desired 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 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 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 use a payload size larger than the one indicated. The proxy MAY use
a smaller payload size than the one indicated. a smaller payload size than the one indicated.
8.1.3. Multipath TCP options 8.1.3. Multipath options
In case of a CONNECT command, the proxy can inform the client that
the connection to the server is an MPTCP connection.
+------+--------+--------+--------+------+ In case of a CONNECT or BIND command, the client can inform the proxy
| Kind | Length | Leg | Level | Code | whether MPTCP is desired on the proxy-remote leg by sending a
+------+--------+--------+--------+------+ Multipath option.
| 1 | 2 | 2 bits | 6 bits | 1 |
+------+--------+--------+--------+------+
Figure 13: Multipath TCP 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.
o Kind: 0x01 (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 = 4 | Code = 2 | Availability | Padding = 0 |
+---+-----------+---------------+---------------+---------------+
o Length: 4 Figure 13: Multipath Option
o Leg: 0x02 (Proxy-Remote leg) o Leg: 0x02 (Proxy-Remote leg)
o Level: 0x04 (TCP). o Availability:
o Code: 0x02
8.1.4. MPTCP Scheduler options
In 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 | Length | Leg | Level | Code | Scheduler |
+------+--------+--------+--------+------+-----------+
| 1 | 2 | 2 bits | 6 bits | 1 | 1 |
+------+--------+--------+--------+------+-----------+
Figure 14: MPTCP Scheduler Option
o Kind: 0x01 (Stack option)
o Length: 5
o Leg: Either 0x01, 0x02, or 0x03 (Client-Proxy, Proxy-Remote or
Both legs).
o Level: 0x04 (TCP)
o Code: 0x03
o Scheduler:
* 0x01: Lowest latency first
* 0x02: Redundant * 0x01: MPTCP is not desired or available
8.1.5. Listen Backlog options * 0x02: MPTCP is desired or available
+------+--------+--------+--------+---------+ In the absence of such an option, the proxy SHOULD NOT enable MPTCP.
| Kind | Length | Leg | Level | Backlog |
+------+--------+--------+--------+---------+
| 1 | 2 | 2 bits | 6 bits | 2 |
+------+--------+--------+--------+---------+
Figure 15: Listen Backlog Option 8.1.4. Listen Backlog options
o Kind: 0x01 (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 = 4 | Code = 3 | Backlog |
+---+-----------+---------------+-------------------------------+
o Length: 5 Figure 14: Listen Backlog Option
o Leg: 0x02 (Proxy-Remote leg) o Leg: 0x02 (Proxy-Remote leg)
o Backlog: The length of the listen backlog.
o Level: 0x04 (TCP)
o Code: 0x04
o Backlog: The length of the listen backlog. MUST be greater than
1.
The default behavior of the BIND does not allow a client to The default behavior of the BIND does not allow a client to
simultaneously handle multiple connections to the same bind address. simultaneously handle multiple connections to the same bind address.
A client can alter BIND's behavior by adding a TCP Listen Backlog 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 Option to a BIND Request, provided that the Request is part of a
Session. Session.
In response, the proxy sends a TCP Listen Backlog Option as part of In response, the proxy sends a TCP Listen Backlog Option as part of
the Operation Reply, with the Backlog field signalling the actual the Operation Reply, with the Backlog field signalling the actual
backlog used. The proxy SHOULD NOT use a backlog longer than backlog used. The proxy SHOULD NOT use a backlog longer than
skipping to change at page 22, line 30 skipping to change at page 23, line 27
Following the successful negotiation of a backlog, the proxy listens Following the successful negotiation of a backlog, the proxy listens
for incoming connections for as long as the initial connection stays for incoming connections for as long as the initial connection stays
open. The initial connection is not used to relay data between the open. The initial connection is not used to relay data between the
client and a remote host. client and a remote host.
To accept connections, the client issues further BIND Requests using To accept connections, the client issues further BIND Requests using
the bind address and port supplied by the proxy in the initial the bind address and port supplied by the proxy in the initial
Operation Reply. Said BIND requests must belong to the same Session Operation Reply. Said BIND requests must belong to the same Session
as the original Request. as the original Request.
If a proxy can not or will not honor a Listen Backlog option, it does If no backlog is issued, the proxy signals a backlog length of 0, and
so silently. BIND's behavior remains unaffected.
8.2. Authentication Method options 8.2. Authentication Method options
Authentication Method options are placed in SOCKS Requests to A client that is willing to go through the authentication phase MUST
advertise supported authentication methods. In case of a CONNECT include an Authentication Method Advertisement option in its Request.
Request, they are also used to specify the amount of initial data In case of a CONNECT Request, the option is also used to specify the
supplied before any method-specific authentication negotiations take amount of initial data supplied before any method-specific
place. authentication negotiations take place.
+------+--------+---------------------+----------+
| Kind | Length | Initial Data Length | Methods |
+------+--------+---------------------+----------+
| 1 | 2 | 2 | Variable |
+------+--------+---------------------+----------+
Figure 16: Authentication Method 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 = 2 | Length |
+-------------------------------+-------------------------------+
| Initial Data Length | ...
+-------------------------------+ ...
... ...
... Methods (variable length) ...
... ...
... +-----------------------------------------------+
... | Padding = 0 (variable length, 0-3 bytes) |
+---------------+-----------------------------------------------+
o Kind: 0x02 (Authentication Method option) Figure 15: Authentication Method Advertisement Option
o Length: The length of the option.
o Initial Data Size: A two-byte number in network byte order. In o Initial Data Size: A two-byte number in network byte order. In
case of CONNECT, this is the number of bytes of initial data that case of CONNECT, this is the number of bytes of initial data that
are supplied by the client immediately following the Request. are supplied by the client immediately following the Request.
This number MUST NOT be larger than 2^14. This number MUST NOT be larger than 2^14.
o Methods: One byte per advertised method. Method numbers are o Methods: One byte per advertised method. Method numbers are
assigned by IANA. assigned by IANA.
o Padding: A minimally-sized sequence of zeroes, such that the
option length is a multiple of 4. Note that 0 coincides with the
value for "No Authentication Required".
Clients MUST support the "No authentication required" method. Clients MUST support the "No authentication required" method.
Clients SHOULD omit advertising the "No authentication required" Clients SHOULD omit advertising the "No authentication required"
option. 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 16: Authentication Method Selection Option
o Method: The selected method.
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.
8.3. Authentication Data options 8.3. Authentication Data options
Authentication Data options carry method-specific authentication Authentication Data options carry method-specific authentication
data. They can be part of SOCKS Requests and Authentication Replies. data. They can be part of SOCKS Requests and Authentication Replies.
Authentication Data options have the following format: Authentication Data options have the following format:
+------+--------+--------+---------------------+ 1 2 3
| Kind | Length | Method | Authentication Data | 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
+------+--------+--------+---------------------+ +-------------------------------+-------------------------------+
| 1 | 2 | 1 | Variable | | Kind = 4 | Length |
+------+--------+--------+---------------------+ +---------------+---------------+-------------------------------+
| Method | ...
+---------------+ ...
... ...
... Authentication Data (variable length) ...
... |
+---------------------------------------------------------------+
Figure 17: Authentication Data Option Figure 17: Authentication Data Option
o Kind: 0x03 (Authentication Data option)
o Length: The length of the option.
o Method: The number of the authentication method. These numbers o Method: The number of the authentication method. These numbers
are assigned by IANA. are assigned by IANA.
o Authentication Data: The contents are specific to each method. o Authentication Data: The contents are specific to each method.
Clients SHOULD only place one Authentication Data option per Clients MUST only place one Authentication Data option per
authentication method. Server implementations MAY silently ignore authentication method.
all Authentication Data options for the same method aside from an
arbitrarily chosen one.
8.4. Session options 8.4. Session options
Clients and proxies can establish SOCKS sessions, which span one or Clients and proxies can establish SOCKS sessions, which span one or
more Requests. All session-related negotiations are done via Session more Requests. All session-related negotiations are done via Session
Options, which are placed in Requests and Authentication Replies by Options, which are placed in Requests and Authentication Replies by
the client and, respectively, by the proxy. the client and, respectively, by the proxy.
Session Options have the following format:
+------+--------+------+---------------------+
| Kind | Length | Type | Session Option Data |
+------+--------+------+---------------------+
| 1 | 2 | 1 | Variable |
+------+--------+------+---------------------+
Figure 18: Session Option
o Kind: 0x04 (Session option)
o Length: The length of the option.
o Type:
* 0x01: Session Request
* 0x02: Session ID
* 0x02: Session Teardown
* 0x04: Session OK
* 0x05: Session Invalid
* 0x06: Session Untrusted
o Session Option Data: The contents are specific to each type.
Client and proxy implementations MUST either support all Session Client and proxy implementations MUST either support all Session
Option Types, or none. Option Types, or none.
8.4.1. Session initiation 8.4.1. Session initiation
A client can initiate a session by sending a Session Request Option: A client can initiate a session by sending a Session Request Option:
+------+--------+------+ 1 2 3
| Kind | Length | Type | 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
+------+--------+------+ +-------------------------------+-------------------------------+
| 1 | 2 | 1 | | Kind = 5 | Length = 4 |
+------+--------+------+ +-------------------------------+-------------------------------+
Figure 19: Session Request Option
o Kind: 0x04 (Session option)
o Length: 4
o Type: 0x01 (Session Request) Figure 18: Session Request Option
The proxy then replies with a Session ID Option in the successful The proxy then replies with a Session ID Option in the successful
Operation Reply: Operation Reply:
+------+--------+------+------------+ 1 2 3
| Kind | Length | Type | Session ID | 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
+------+--------+------+------------+ +-------------------------------+-------------------------------+
| 1 | 2 | 1 | Variable | | Kind = 6 | Length |
+------+--------+------+------------+ +-------------------------------+-------------------------------+
| ...
Figure 20: Session ID Option ... Session ID (variable length) ...
... |
o Kind: 0x04 (Session option) +---------------------------------------------------------------+
o Length: The length of the option.
o Type: 0x02 (Session ID) Figure 19: Session ID Option
o Session ID: An opaque sequence of bytes specific to the session. o Session ID: An opaque sequence of bytes specific to the session.
MUST be at least one byte in size. The size MUST be a multiple of 4. MUST NOT be empty.
The Session ID serves to identify the session and is opaque to the The Session ID serves to identify the session and is opaque to the
client. client.
The credentials, or lack thereof, used to initiate the session are The credentials, or lack thereof, used to initiate the session are
tied to the session. If authentication is to be performed for tied to the session. If authentication is to be performed for
further Requests, the session is deemed "untrusted", and the proxy further Requests, the session is deemed "untrusted", and the proxy
also places a Session Untrusted option in the Authentication Reply: also places a Session Untrusted option in the Authentication Reply:
+------+--------+------+ 1 2 3
| Kind | Length | Type | 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
+------+--------+------+ +-------------------------------+-------------------------------+
| 1 | 2 | 1 | | Kind = 7 | Length = 4 |
+------+--------+------+ +-------------------------------+-------------------------------+
Figure 21: Session Untrusted Option
o Kind: 0x04 (Session option)
o Length: 5
o Type: 0x06 (Session Untrusted) Figure 20: Session Untrusted Option
The SOCKS Request that initiated the session is considered part of The SOCKS Request that initiated the session is considered part of
the session. A client MUST NOT attempt to initiate a session from the session. A client MUST NOT attempt to initiate a session from
within a different session. within a different session.
If the proxy can not or will not honor the Session Request, it does If the proxy can not or will not honor the Session Request, it does
so silently. so silently.
8.4.2. Further SOCKS Requests 8.4.2. Further SOCKS Requests
Any further SOCKS Requests that are part of the session MUST include Any further SOCKS Requests that are part of the session MUST include
a Session ID Option (as seen in Figure 20). a Session ID Option (as seen in Figure 19).
The authentication procedure is altered based on the Session ID's The authentication procedure is altered based on the Session ID's
validity and whether or not the Session is untrusted. validity and whether or not the Session is untrusted.
For valid Session IDs: For valid Session IDs:
o If the session is untrusted, the proxy MUST reject clients that do o If the session is untrusted, the proxy MUST reject clients that do
not authenticate using the same method and credentials that were not authenticate using the same method and credentials that were
used to initiate the session. used to initiate the session.
o Otherwise, the proxy MUST ignore any authentication attempt in the o Otherwise, the proxy MUST silently ignore any authentication
Request, and MUST NOT require any authentication. attempt in the Request, and MUST NOT require any authentication.
The proxy then replies by placing a Session OK option in the The proxy then replies by placing a Session OK option in the
successful Authentication Reply: successful Authentication Reply:
+------+--------+------+ 1 2 3
| Kind | Length | Type | 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
+------+--------+------+ +-------------------------------+-------------------------------+
| 1 | 2 | 1 | | Kind = 8 | Length = 4 |
+------+--------+------+ +-------------------------------+-------------------------------+
Figure 22: Session OK Option
o Kind: 0x04 (Session option)
o Length: 5
o Type: 0x04 (Session OK) Figure 21: Session OK Option
If the ticket is invalid, the first Authentication Reply MUST signal If the ticket is invalid, the first Authentication Reply MUST signal
that authentication failed and can not continue (by setting the Type that authentication failed and can not continue (by setting the Type
field to 0x01 and the Method field to 0xff). Further, it SHALL field to 0x01). Further, it SHALL contain a Session Invalid option:
contain a Session Invalid option:
+------+--------+------+
| Kind | Length | Type |
+------+--------+------+
| 1 | 2 | 1 |
+------+--------+------+
Figure 23: Session Invalid Option
o Kind: 0x04 (Session option)
o Length: 5 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 |
+-------------------------------+-------------------------------+
o Type: 0x05 (Session Invalid) Figure 22: Session Invalid Option
8.4.3. Tearing down the session 8.4.3. Tearing down the session
Proxies can, at their discretion, tear down a session and free all Proxies can, at their discretion, tear down a session and free all
associated state. Proxy implementations SHOULD feature a timeout associated state. Proxy implementations SHOULD feature a timeout
mechanism that destroys sessions after a period of inactivity. 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 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 torn down, by sending a Session Teardown option in addition to the
Session ID option: Session ID option:
+------+--------+------+ 1 2 3
| Kind | Length | Type | 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
+------+--------+------+ +-------------------------------+-------------------------------+
| 1 | 2 | 1 | | Kind = 10 | Length = 4 |
+------+--------+------+ +-------------------------------+-------------------------------+
Figure 24: Session Teardown Option
o Kind: 0x04 (Session option)
o Length: 4
o Type: 0x02 (Session Teardown) Figure 23: Session Teardown Option
After sending such an option, the client MUST assume that the session After sending such an option, the client MUST assume that the session
is no longer valid. is no longer valid. The proxy MUST treat the connection-terminating
request as if it were not part of any session.
8.5. Idempotence options 8.5. Idempotence options
To protect against duplicate SOCKS Requests, clients can request, and To protect against duplicate SOCKS Requests, clients can request, and
then spend, idempotence tokens. A token can only be spent on a then spend, idempotence tokens. A token can only be spent on a
single SOCKS request. single SOCKS request.
Tokens are 4-byte unsigned integers in a modular 4-byte space. 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) < Therefore, if x and y are tokens, x is less than y if 0 < (y - x) <
2^31 in unsigned 32-bit arithmetic. 2^31 in unsigned 32-bit arithmetic.
Proxies grant contiguous ranges of tokens called token windows. Proxies grant contiguous ranges of tokens called token windows.
Token windows are defined by their base (the first token in the Token windows are defined by their base (the first token in the
range) and size. Windows can be shifted (i. e. have their base range) and size.
increased, while retaining their size) unilaterally by the proxy.
Requesting and spending tokens is done via Idempotence options:
+------+--------+------+-------------+
| Kind | Length | Type | Option Data |
+------+--------+------+-------------+
| 1 | 2 | 1 | Variable |
+------+--------+------+-------------+
Figure 25: Idempotence Option
o Kind: 0x05 (Idempotence option)
o Length: The length of the option.
o Type:
* 0x01: Token Request
* 0x02: Token Window Advertisement
* 0x03: Token Expenditure
* 0x04: Token Expenditure Reply
o Option Data: The contents are specific to each type. All token-related operations are done via Idempotence options.
Idempotence options are only valid in the context of a SOCKS Session. 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 If a SOCKS Request is not part of a Session (either by supplying a
valid Session ID or successfully initiating one via a Session valid Session ID or successfully initiating one via a Session
Request), the proxy MUST silently ignore any Idempotence options. Request), the proxy MUST silently ignore any Idempotence options.
Token windows are tracked by the proxy on a per-session basis. There 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 can be at most one token window for every session and its tokens can
only be spent from within said session. only be spent from within said session.
Client and proxy implementations MUST either support all Idempotence Client and proxy implementations MUST either support all Idempotence
Option Types, or none. Option Types, or none.
8.5.1. Requesting a fresh token window 8.5.1. Requesting a token window
A client can obtain a fresh window of tokens by sending a Token A client can obtain a window of tokens by sending an Idempotence
Request option as part of a SOCKS Request: Request option as part of a SOCKS Request:
+------+--------+------+-------------+ 1 2 3
| Kind | Length | Type | Window Size | 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
+------+--------+------+-------------+ +-------------------------------+-------------------------------+
| 1 | 2 | 1 | 4 | | Kind = 11 | Length = 8 |
+------+--------+------+-------------+ +-------------------------------+-------------------------------+
| Window Size |
Figure 26: Token Request +---------------------------------------------------------------+
o Kind: MUST be allocated by IANA. (See Section 13.)
o Length: 7
o Type: 0x00 (Token Request) Figure 24: Token Request
o Window Size: The requested window size. o Window Size: The requested window size.
If a token window is issued, the proxy then includes a Token Window Once a token window is issued, the proxy MUST include an Idempotence
Advertisement option in the corresponding successful Authentication Window option in all subsequent successful Authentication Replies:
Reply:
+------+--------+------+-------------+-------------+
| Kind | Length | Type | Window Base | Window Size |
+------+--------+------+-------------+-------------+
| 1 | 2 | 1 | 4 | 4 |
+------+--------+------+-------------+-------------+
Figure 27: Token Window Advertisement
o Kind: 0x05 (Idempotence option)
o Length: 11 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 |
+---------------------------------------------------------------+
o Type: 0x01 (Token Grant) Figure 25: Idempotence Window
o Window Base: The first token in the window. o Window Base: The first token in the window.
o Window Size: The window size. This value SHOULD be lower or equal o Window Size: The window size. This value MAY differ from the
to the requested window size. Window sizes MUST be less than requested window size. Window sizes MUST be less than 2^31.
2^31. Window sizes MUST NOT be 0. Window sizes MUST NOT be 0.
If no token window is issued, the proxy MUST silently ignore the If no token window is issued, the proxy MUST silently ignore the
Token Request. Token Request. If there is already a token window associated with
the session, the proxy MUST NOT issue a new window.
8.5.2. Spending a token 8.5.2. Spending a token
The client can attempt to spend a token by including a Token The client can attempt to spend a token by including a Idempotence
Expenditure option in its SOCKS request: Expenditure option in its SOCKS request:
+------+--------+------+-------+ 1 2 3
| Kind | Length | Type | Token | 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
+------+--------+------+-------+ +-------------------------------+-------------------------------+
| 1 | 2 | 1 | 4 | | Kind = 13 | Length = 8 |
+------+--------+------+-------+ +-------------------------------+-------------------------------+
| Token |
+---------------------------------------------------------------+
Figure 28: Token Expenditure Figure 26: Idempotence Expenditure
o Kind: 0x05 (Idempotence option) o Kind: 13 (Idempotence Expenditure option)
o Length: 7 o Length: 8
o Type: 0x02 (Token Expenditure)
o Token: The token being spent. o Token: The token being spent.
Clients SHOULD prioritize spending the smaller tokens. Clients SHOULD prioritize spending the smaller tokens.
The proxy responds by sending a Token Expenditure Reply option as The proxy responds by sending either an Idempotence Accepted or
part of the successful Authentication Reply: Rejected option as part of the Authentication Reply:
+------+--------+------+---------------+ 1 2 3
| Kind | Length | Type | Response Code | 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
+------+--------+------+---------------+ +-------------------------------+-------------------------------+
| 1 | 2 | 1 | 1 | | Kind = 14 | Length = 8 |
+------+--------+------+---------------+ +-------------------------------+-------------------------------+
Figure 29: Token Expenditure Response Figure 27: Idempotence Accepted
o Kind: 0x05 (Idempotence 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 = 15 | Length = 8 |
+-------------------------------+-------------------------------+
o Length: 4 Figure 28: Idempotence Rejected
o Type: 0x03 (Token Expenditure Response) 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.
o Response Code: 8.5.3. Shifting windows
* 0x01: Success: The token was spent successfully. Windows can be shifted (i. e. have their base increased, while
retaining their size) unilaterally by the proxy.
* 0x02: No Window: The proxy does not have a token window Proxy implementations SHOULD shift the window: * as soon as the
associated with the client. lowest-order token in the window is spent and * when a sufficiently
high-order token is spent.
* 0x03: Out of Window: The token is not within the window. Proxy implementations SHOULD NOT shift the window's base beyond the
highest unspent token.
* 0x04: Duplicate: The token has already been spent. 8.5.4. Out-of-order Window Advertisements
If eligible, the token is spent before attempting to honor the Even though the proxy increases the window's base monotonically,
Request. If the token is not eligible for spending, the proxy MUST there is no mechanism whereby a SOCKS client can receive the Token
NOT attempt to honor the client's Request; further, it MUST indicate Window Advertisements in order. As such, clients SHOULD disregard
a General SOCKS server failure in the Operation Reply. Token Window Advertisements with a Window Base less than the
previously known value.
Proxy implementations SHOULD also send a Token Window Advertisement 8.6. Address Resolution Options
if:
o the token is out of window, or Clients wishing to resolve an address from the proxy's vantage point
can do so by sending a Resolution Request option:
o by the proxy's internal logic, successfully spending the token 1 2 3
caused the window to shift. 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 = 16 | Length = 4 |
+-------------------------------+-------------------------------+
Proxy implementations SHOULD NOT shift the window's base beyond the Figure 29: Resolution Request
highest unspent token.
Proxy implementations MAY include a Token Window Advertisement in any The proxy's reply is included in the Operation Reply.
Authentication Reply that indicates success.
8.5.3. Handling Token Window Advertisements 8.6.1. Forward resolution
Even though the proxy increases the window's base monotonically, If the address supplied by the client is a Domain Name, the proxy
there is no mechanism whereby a SOCKS client can receive the Token sends a Resolution option for each supported address type:
Window Advertisements in order. As such, clients SHOULD disregard
unsolicited Token Window Advertisements with a Window Base less than 1 2 3
the previously known value. 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 = 17 | Length |
+-------------------------------+-------------------------------+
| ...
... IPv4 Addresses (variable length) ...
... |
+---------------------------------------------------------------+
Figure 30: IPv4 Resolution
o IPv4 Addresses: The resolved IPv4 addresses.
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 = 18 | Length |
+-------------------------------+-------------------------------+
| ...
... IPv6 Addresses (variable length) ...
... |
+---------------------------------------------------------------+
Figure 31: IPv6 Resolution
o IPv6 Addresses: The resolved IPv6 addresses.
If resolving a given address type is supported, but no addresses were
found, the proxy MUST send an empty option, rather than none at all.
If the proxy does not support resolving either one of the address
types, it MUST omit sending the corrresponding option.
8.6.2. Reverse resolution
If the client supplies either an IPv4 or IPv6 address, the proxy
performs a reverse lookup and replies with a list of domain names:
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 = 18 | Length |
+-------------------------------+-------------------------------+
| ...
... Domain Names (variable length) ...
... |
+---------------------------------------------------------------+
Figure 32: Domain Name Resolution
o Domain Names: The resolved domain names. Their format is the same
as the one used in Requests and Operation Replies, with each
string being individially padded. (See Section 4.)
If no domain names could be found, the proxy MUST send an empty
option. If reverse resolution is unsupported, the proxy MUST NOT
send any such option.
9. Username/Password Authentication 9. Username/Password Authentication
Username/Password authentication is carried out as in [RFC1929]. Username/Password authentication is carried out as in [RFC1929].
Clients can also attempt to authenticate by placing the Username/ Clients can also attempt to authenticate by placing the Username/
Password request in an Authentication Data Option. Password request in an Authentication Data Option.
+------+--------+--------+---------------------------+ 1 2 3
| Kind | Length | Method | Username/Password request | 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
+------+--------+--------+---------------------------+ +-------------------------------+-------------------------------+
| 1 | 2 | 1 | Variable | | Kind = 4 | Length |
+------+--------+--------+---------------------------+ +---------------+---------------+---------------+---------------+
| Method = 2 | ...
+---------------+ ...
... ...
... Username/Password Request ...
... ...
... +-----------------------------------------------+
... | Padding = 0 (variable length, 0-3 bytes) |
+---------------+-----------------------------------------------+
Figure 30: Password authentication via a SOCKS Option Figure 33: Password authentication via a SOCKS Option
o Kind: 0x03 (Authentication Data option) o Username/Password Request: The Username/Password Request, as
described in [RFC1929].
o Length: The length of the option. Proxies reply by including a Authentication Data Option in the next
Authentication Reply which contains the Username/Password reply:
o Method: 0x02 (Username/Password). 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 |
+---------------+-------------------------------+---------------+
o Username/Password request: The Username/Password request, as Figure 34: Reply to password authentication via a SOCKS Option
described in [RFC1929].
o Username/Password Reply: The Username/Password Reply, as described
in [RFC1929].
10. TCP Fast Open on the Client-Proxy Leg 10. TCP Fast Open on the Client-Proxy Leg
TFO breaks TCP semantics, causing replays of the data in the SYN's TFO breaks TCP semantics, causing replays of the data in the SYN's
payload under certain rare circumstances [RFC7413]. A replayed SOCKS payload under certain rare circumstances [RFC7413]. A replayed SOCKS
Request could itself result in a replayed connection on behalf of the Request could itself result in a replayed connection on behalf of the
client. client.
As such, client implementations SHOULD NOT use TFO on the client- As such, client implementations SHOULD NOT use TFO on the client-
proxy leg unless: proxy leg unless:
skipping to change at page 33, line 23 skipping to change at page 35, line 5
11. False Starts 11. False Starts
In case of CONNECT Requests, the client MAY start sending application 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 data as soon as possible, as long as doing so does not incur the risk
of breaking the SOCKS protocol. of breaking the SOCKS protocol.
Clients must work around the authentication phase by doing any of the Clients must work around the authentication phase by doing any of the
following: following:
o If the Request does not contain an Authentication Method option, o If the Request does not contain an Authentication Method
the authentication phase is guaranteed not to happen. In this Advertisement option, the authentication phase is guaranteed not
case, application data MAY be sent immediately after the Request. to happen. In this case, application data MAY be sent immediately
after the Request.
o Application data MAY be sent immediately after receiving an o Application data MAY be sent immediately after receiving an
Authentication Reply indicating success. Authentication Reply indicating success.
o When performing a method-specific authentication sequence, o When performing a method-specific authentication sequence,
application data MAY be sent immediately after the last client application data MAY be sent immediately after the last client
message. message.
12. Security Considerations 12. Security Considerations
skipping to change at page 34, line 11 skipping to change at page 35, line 39
o the request is not fully received after a certain timeout, or o the request is not fully received after a certain timeout, or
o the number of options or their size exceeds an imposed hard cap. o the number of options or their size exceeds an imposed hard cap.
12.2. Replay attacks 12.2. Replay attacks
In TLS 1.3, early data (which is likely to contain a full SOCKS In TLS 1.3, early data (which is likely to contain a full SOCKS
request) is prone to replay attacks. request) is prone to replay attacks.
While Token Expenditure options can be used to mitigate replay While Token Expenditure options can be used to mitigate replay
attacks, the initial Token Request is still vulnerable. As such, attacks, anything prior to the initial Token Request is still
client implementations SHOULD NOT make use of TLS early data unless vulnerable. As such, client implementations SHOULD NOT make use of
the Request attempts to spend a token. TLS early data unless the Request attempts to spend a token.
12.3. Resource exhaustion 12.3. Resource exhaustion
Malicious clients can issue a large number of Session Requests, Malicious clients can issue a large number of Session Requests,
forcing the proxy to keep large amounts of state. forcing the proxy to keep large amounts of state.
To mitigate this, the proxy MAY implement policies restricting the To mitigate this, the proxy MAY implement policies restricting the
number of concurrent sessions on a per-IP or per-user basis, or number of concurrent sessions on a per-IP or per-user basis, or
barring unauthenticated clients from establishing sessions. barring unauthenticated clients from establishing sessions.
13. IANA Considerations 13. IANA Considerations
This document requests that IANA allocate 1-byte option kinds for This document requests that IANA allocate 2-byte option kinds for
SOCKS 6 options. Further, this document requests the following SOCKS 6 options. Further, this document requests the following
option kinds: option kinds:
o Stack options: 0x01 o Unassigned: 0
o Authentication Method options: 0x02 o Stack: 1
o Authentication Data options: 0x03 o Authentication Method Advertisement: 2
o Session options: 0x04 o Authentication Method Selection: 3
o Idempotence options: 0x05 o Authentication Data: 4
o A range for vendor-specific options: 0xE0-0xFF o Session Request: 5
o Session ID: 6
o Session Untrusted: 7
o Session OK: 8
o Session Invalid: 9
o Session Teardown: 10
o Idempotence Request: 11
o Idempotence Window: 12
o Idempotence Expenditure: 13
o Idempotence Accepted: 14
o Idempotence Rejected: 15
o Resolution Request: 16
o IPv4 Resolution: 17
o IPv6 Resolution: 18
o Domain Name Resolution: 19
o Vendor-specific: 64512-0xFFFF
This document also requests that IANA allocate a TCP and UDP port for This document also requests that IANA allocate a TCP and UDP port for
SOCKS over TLS and DTLS, respectively. SOCKS over TLS and DTLS, respectively.
14. Acknowledgements 14. Acknowledgements
The protocol described in this draft builds upon and is a direct The protocol described in this draft builds upon and is a direct
continuation of SOCKS 5 [RFC1928]. continuation of SOCKS 5 [RFC1928].
15. References 15. References
skipping to change at page 35, line 23 skipping to change at page 37, line 30
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., and T. Fossati, "Connection Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
id-04 (work in progress), March 2019. id-06 (work in progress), July 2019.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928, L. Jones, "SOCKS Protocol Version 5", RFC 1928,
DOI 10.17487/RFC1928, March 1996, DOI 10.17487/RFC1928, March 1996,
<https://www.rfc-editor.org/info/rfc1928>. <https://www.rfc-editor.org/info/rfc1928>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<https://www.rfc-editor.org/info/rfc6824>. <https://www.rfc-editor.org/info/rfc6824>.
skipping to change at page 35, line 47 skipping to change at page 38, line 9
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
Authors' Addresses Authors' Addresses
Vladimir Olteanu Vladimir Olteanu
University Politehnica of Bucharest University Politehnica of Bucharest
313 Splaiul Independentei, Sector 6
Bucharest
Romania
Email: vladimir.olteanu@cs.pub.ro Email: vladimir.olteanu@cs.pub.ro
Dragos Niculescu Dragos Niculescu
University Politehnica of Bucharest University Politehnica of Bucharest
313 Splaiul Independentei, Sector 6
Bucharest
Romania
Email: dragos.niculescu@cs.pub.ro Email: dragos.niculescu@cs.pub.ro
 End of changes. 151 change blocks. 
503 lines changed or deleted 613 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/