< draft-olteanu-intarea-socks-6-07.txt		draft-olteanu-intarea-socks-6-08.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: January 9, 2020 July 08, 2019		Expires: May 7, 2020 November 04, 2019
	SOCKS Protocol Version 6		SOCKS Protocol Version 6
	draft-olteanu-intarea-socks-6-07		draft-olteanu-intarea-socks-6-08
	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 January 9, 2020.		This Internet-Draft will expire on May 7, 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 . . . . . . . . . . . . . . . . . . . . 9		2. Requirements language . . . . . . . . . . . . . . . . . . . . 10
	3. Mode of operation . . . . . . . . . . . . . . . . . . . . . . 9		3. Mode of operation . . . . . . . . . . . . . . . . . . . . . . 10
	4. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Version Mismatch Replies . . . . . . . . . . . . . . . . . . 13		5. Version Mismatch Replies . . . . . . . . . . . . . . . . . . 13
	6. Authentication Replies . . . . . . . . . . . . . . . . . . . 13		6. Authentication Replies . . . . . . . . . . . . . . . . . . . 13
	7. Operation Replies . . . . . . . . . . . . . . . . . . . . . . 14		7. Operation Replies . . . . . . . . . . . . . . . . . . . . . . 14
	7.1. Handling CONNECT . . . . . . . . . . . . . . . . . . . . 16		7.1. Handling CONNECT . . . . . . . . . . . . . . . . . . . . 16
	7.2. Handling BIND . . . . . . . . . . . . . . . . . . . . . . 16		7.2. Handling BIND . . . . . . . . . . . . . . . . . . . . . . 16
	7.3. Handling UDP ASSOCIATE . . . . . . . . . . . . . . . . . 16		7.3. Handling UDP ASSOCIATE . . . . . . . . . . . . . . . . . 16
	7.3.1. Proxying UDP servers . . . . . . . . . . . . . . . . 18		7.3.1. Proxying UDP servers . . . . . . . . . . . . . . . . 19
	7.3.2. Proxying multicast traffic . . . . . . . . . . . . . 18		7.3.2. Proxying multicast traffic . . . . . . . . . . . . . 19
	8. SOCKS Options . . . . . . . . . . . . . . . . . . . . . . . . 18		8. SOCKS Options . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.1. Stack options . . . . . . . . . . . . . . . . . . . . . . 19		8.1. Stack options . . . . . . . . . . . . . . . . . . . . . . 20
	8.1.1. IP TOS options . . . . . . . . . . . . . . . . . . . 20		8.1.1. IP TOS options . . . . . . . . . . . . . . . . . . . 21
	8.1.2. TFO options . . . . . . . . . . . . . . . . . . . . . 21		8.1.2. Happy Eyeballs options . . . . . . . . . . . . . . . 21
	8.1.3. Multipath options . . . . . . . . . . . . . . . . . . 22		8.1.3. TFO options . . . . . . . . . . . . . . . . . . . . . 22
	8.1.4. Listen Backlog options . . . . . . . . . . . . . . . 22		8.1.4. Multipath options . . . . . . . . . . . . . . . . . . 22
	8.2. Authentication Method options . . . . . . . . . . . . . . 23		8.1.5. Listen Backlog options . . . . . . . . . . . . . . . 23
			8.2. Authentication Method options . . . . . . . . . . . . . . 24
	8.3. Authentication Data options . . . . . . . . . . . . . . . 25		8.3. Authentication Data options . . . . . . . . . . . . . . . 25
	8.4. Session options . . . . . . . . . . . . . . . . . . . . . 25		8.4. Session options . . . . . . . . . . . . . . . . . . . . . 26
	8.4.1. Session initiation . . . . . . . . . . . . . . . . . 26		8.4.1. Session initiation . . . . . . . . . . . . . . . . . 26
	8.4.2. Further SOCKS Requests . . . . . . . . . . . . . . . 27		8.4.2. Further SOCKS Requests . . . . . . . . . . . . . . . 27
	8.4.3. Tearing down the session . . . . . . . . . . . . . . 28		8.4.3. Tearing down the session . . . . . . . . . . . . . . 28
	8.5. Idempotence options . . . . . . . . . . . . . . . . . . . 28		8.5. Idempotence options . . . . . . . . . . . . . . . . . . . 29
	8.5.1. Requesting a 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. Shifting windows . . . . . . . . . . . . . . . . . . 31		8.5.3. Shifting windows . . . . . . . . . . . . . . . . . . 32
	8.5.4. Out-of-order Window Advertisements . . . . . . . . . 31		8.5.4. Out-of-order Window Advertisements . . . . . . . . . 32
	8.6. Address Resolution Options . . . . . . . . . . . . . . . 31		9. Username/Password Authentication . . . . . . . . . . . . . . 32
	8.6.1. Forward resolution . . . . . . . . . . . . . . . . . 31		10. TCP Fast Open on the Client-Proxy Leg . . . . . . . . . . . . 33
	8.6.2. Reverse resolution . . . . . . . . . . . . . . . . . 32		11. False Starts . . . . . . . . . . . . . . . . . . . . . . . . 33
	9. Username/Password Authentication . . . . . . . . . . . . . . 33		12. DNS provided by SOCKS . . . . . . . . . . . . . . . . . . . . 34
	10. TCP Fast Open on the Client-Proxy Leg . . . . . . . . . . . . 34		13. Security Considerations . . . . . . . . . . . . . . . . . . . 34
	11. False Starts . . . . . . . . . . . . . . . . . . . . . . . . 34		13.1. Large requests . . . . . . . . . . . . . . . . . . . . . 34
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 35		13.2. Replay attacks . . . . . . . . . . . . . . . . . . . . . 35
	12.1. Large requests . . . . . . . . . . . . . . . . . . . . . 35		13.3. Resource exhaustion . . . . . . . . . . . . . . . . . . 35
	12.2. Replay attacks . . . . . . . . . . . . . . . . . . . . . 35		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	12.3. Resource exhaustion . . . . . . . . . . . . . . . . . . 35		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37		16.1. Normative References . . . . . . . . . . . . . . . . . . 36
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 37		16.2. Informative References . . . . . . . . . . . . . . . . . 37
	15.1. Normative References . . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 15 ¶		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-08
			o Removed Address Resolution options
			o Happy Eyeballs options
			o DNS provided by SOCKS
	draft-07		draft-07
	o All fields are now alignned.		o All fields are now alignned.
	o Eliminated version minors		o Eliminated version minors
	o Lots of changes to options		o Lots of changes to options
	* 2-byte option kinds		* 2-byte option kinds
	skipping to change at page 8, line 42 ¶		skipping to change at page 9, line 5 ¶
	+ Banned contradictory socket options.		+ Banned contradictory socket options.
	+ Added socket level for generic IP. Removed the "socket"		+ Added socket level for generic IP. Removed the "socket"
	socket level.		socket level.
	+ Stack options no longer use option codes from setsockopt().		+ Stack options no longer use option codes from setsockopt().
	+ Changed MPTCP Scheduler constants.		+ Changed MPTCP Scheduler constants.
	draft-02
	o Made support for Idempotence options mandatory for proxies.		o Made support for Idempotence options mandatory for proxies.
	o Clarified what happens when proxies can not or will not issue		o Clarified what happens when proxies can not or will not issue
	tokens.		tokens.
	o Limited token windows to 2^31 - 1.		o Limited token windows to 2^31 - 1.
	o Fixed definition of "less than" for tokens.		o Fixed definition of "less than" for tokens.
	o NOOP commands now trigger Operation Replies.		o NOOP commands now trigger Operation Replies.
	skipping to change at page 19, line 17 ¶		skipping to change at page 19, line 37 ¶
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Kind | Length |		| Kind | Length |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| ...		| ...
	... Option Data (variable 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 14.)
	o Length: The total length of the option. MUST be a multiple of 4.		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.
	skipping to change at page 21, line 4 ¶		skipping to change at page 21, line 22 ¶
	* 4: TCP		* 4: TCP
	* 5: UDP		* 5: UDP
	o Code: Option code		o Code: Option code
	o Option 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		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		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 |		| Kind = 1 | Length = 8 |
	+---+-----------+---------------+---------------+---------------+		+---+-----------+---------------+---------------+---------------+
	|Leg| Level = 1 | Code = 1 | TOS | Padding = 0 |		|Leg| Level = 1 | Code = 1 | TOS | Padding = 0 |
	+---+-----------+---------------+---------------+---------------+		+---+-----------+---------------+---------------+---------------+
	Figure 11: IP TOS Option		Figure 11: IP TOS Option
	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. Happy Eyeballs options
	1 2 3		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		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 |		| Kind = 1 | Length = 8 |
	+---+-----------+---------------+-------------------------------+		+---+-----------+---------------+-------------------------------+
	|Leg| Level = 4 | Code = 1 | Payload Size |		| 2 | Level = 1 | Code = 2 | Padding = 0 |
	+---+-----------+---------------+-------------------------------+		+---+-----------+---------------+-------------------------------+
	Figure 12: TFO Option		Figure 12: Happy Eyeballs Option
	o Leg: 0x02 (Proxy-Remote leg).		This memo provides enough features for clients to implement a
			mechanism analogous to Happy Eyeballs [RFC8305] over SOCKS. However,
			when the delay between the client and the proxy, or the proxy's
			vantage point, is high, doing so can become impractical or
			inefficient.
			In such cases, the client can instruct the proxy to employ the Happy
			Eyeballs technique on its behalf when connecting to a remote host.
			The client MUST supply a Domain Name as part of its Request.
			Otherwise, the proxy MUST silently ignore the option.
			TODO: Figure out which knobs to include.
			8.1.3. TFO 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 = 1 | Length = 8 |
			+---+-----------+---------------+-------------------------------+
			| 2 | Level = 4 | Code = 1 | Payload Size |
			+---+-----------+---------------+-------------------------------+
			Figure 13: TFO Option
	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 options		8.1.4. Multipath options
	In case of a CONNECT or BIND command, the client can inform the proxy		In case of a CONNECT or BIND command, the client can inform the proxy
	whether MPTCP is desired on the proxy-remote leg by sending a		whether MPTCP is desired on the proxy-remote leg by sending a
	Multipath option.		Multipath option.
	Conversely, the proxy can use a Multipath option to convey the		Conversely, the proxy can use a Multipath option to convey the
	following information: * whether or not the connection uses MPTCP or		following information: * whether or not the connection uses MPTCP or
	not, when replying to a CONNECT command, or in the second Operation		not, when replying to a CONNECT command, or in the second Operation
	reply to a BIND command, or * whether an MPTCP connection will be		reply to a BIND command, or * whether an MPTCP connection will be
	accepted, when first replying to a BIND command.		accepted, when first replying to a BIND command.
	1 2 3		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		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 |		| Kind = 1 | Length = 8 |
	+---+-----------+---------------+---------------+---------------+		+---+-----------+---------------+---------------+---------------+
	|Leg| Level = 4 | Code = 2 | Availability | Padding = 0 |		| 2 | Level = 4 | Code = 2 | Availability | Padding = 0 |
	+---+-----------+---------------+---------------+---------------+		+---+-----------+---------------+---------------+---------------+
	Figure 13: Multipath Option		Figure 14: Multipath Option
	o Leg: 0x02 (Proxy-Remote leg)
	o Availability:		o Availability:
	* 0x01: MPTCP is not desired or available		* 0x01: MPTCP is not desired or available
	* 0x02: MPTCP is desired or available		* 0x02: MPTCP is desired or available
	In the absence of such an option, the proxy SHOULD NOT enable MPTCP.		In the absence of such an option, the proxy SHOULD NOT enable MPTCP.
	8.1.4. Listen Backlog options		8.1.5. Listen Backlog options
	1 2 3		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		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 |		| Kind = 1 | Length = 8 |
	+---+-----------+---------------+-------------------------------+		+---+-----------+---------------+-------------------------------+
	|Leg| Level = 4 | Code = 3 | Backlog |		| 2 | Level = 4 | Code = 3 | Backlog |
	+---+-----------+---------------+-------------------------------+		+---+-----------+---------------+-------------------------------+
	Figure 14: Listen Backlog Option		Figure 15: Listen Backlog Option
	o Leg: 0x02 (Proxy-Remote leg)
	o Backlog: The length of the listen backlog.		o Backlog: The length of the listen backlog.
	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
	skipping to change at page 24, line 19 ¶		skipping to change at page 24, line 42 ¶
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Initial Data Length | ...		| Initial Data Length | ...
	+-------------------------------+ ...		+-------------------------------+ ...
	... ...		... ...
	... Methods (variable length) ...		... Methods (variable length) ...
	... ...		... ...
	... +-----------------------------------------------+		... +-----------------------------------------------+
	... | Padding = 0 (variable length, 0-3 bytes) |		... | Padding = 0 (variable length, 0-3 bytes) |
	+---------------+-----------------------------------------------+		+---------------+-----------------------------------------------+
	Figure 15: Authentication Method Advertisement Option		Figure 16: Authentication Method Advertisement 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		o Padding: A minimally-sized sequence of zeroes, such that the
	skipping to change at page 24, line 49 ¶		skipping to change at page 25, line 25 ¶
	corresponding Authentication Reply:		corresponding Authentication Reply:
	1 2 3		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		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 |		| Kind = 3 | Length = 8 |
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	| Method | Padding = 0 |		| Method | Padding = 0 |
	+---------------+-----------------------------------------------+		+---------------+-----------------------------------------------+
	Figure 16: Authentication Method Selection Option		Figure 17: Authentication Method Selection Option
	o Method: The selected method.		o Method: The selected method.
	If the proxy selects "No Acceptable Methods", the client MUST close		If the proxy selects "No Acceptable Methods", the client MUST close
	the connection.		the connection.
	If authentication is successful via some other means, or not required		If authentication is successful via some other means, or not required
	at all, the proxy silently ignores the Authentication Method		at all, the proxy silently ignores the Authentication Method
	Advertisement option.		Advertisement option.
	skipping to change at page 25, line 33 ¶		skipping to change at page 26, line 17 ¶
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Kind = 4 | Length |		| Kind = 4 | Length |
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	| Method | ...		| Method | ...
	+---------------+ ...		+---------------+ ...
	... ...		... ...
	... Authentication Data (variable length) ...		... Authentication Data (variable length) ...
	... |		... |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 17: Authentication Data Option		Figure 18: Authentication Data 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 MUST only place one Authentication Data option per		Clients MUST only place one Authentication Data option per
	authentication method.		authentication method.
	8.4. Session options		8.4. Session options
	skipping to change at page 26, line 15 ¶		skipping to change at page 26, line 47 ¶
	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		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		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Kind = 5 | Length = 4 |		| Kind = 5 | Length = 4 |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	Figure 18: Session Request Option		Figure 19: 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		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		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Kind = 6 | Length |		| Kind = 6 | Length |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| ...		| ...
	... Session ID (variable length) ...		... Session ID (variable length) ...
	... |		... |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 19: Session ID Option		Figure 20: 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.
	The size MUST be a multiple of 4. MUST NOT be empty.		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		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		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Kind = 7 | Length = 4 |		| Kind = 7 | Length = 4 |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	Figure 20: Session Untrusted Option		Figure 21: 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 19).		a Session ID Option (as seen in Figure 20).
	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.
	skipping to change at page 27, line 38 ¶		skipping to change at page 28, line 23 ¶
	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		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		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Kind = 8 | Length = 4 |		| Kind = 8 | Length = 4 |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	Figure 21: Session OK Option		Figure 22: 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). Further, it SHALL contain a Session Invalid option:		field to 0x01). Further, it SHALL contain a Session Invalid option:
	1 2 3		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		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 |		| Kind = 9 | Length = 4 |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	Figure 22: Session Invalid Option		Figure 23: 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. When		mechanism that destroys sessions after a period of inactivity. When
	a session is terminated, the proxy MAY close all connections		a session is terminated, the proxy MAY close all connections
	associated with said session.		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		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		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Kind = 10 | Length = 4 |		| Kind = 10 | Length = 4 |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	Figure 23: Session Teardown Option		Figure 24: 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. The proxy MUST treat the connection-terminating		is no longer valid. The proxy MUST treat the connection-terminating
	request as if it were not part of any session.		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.
	skipping to change at page 29, line 25 ¶		skipping to change at page 30, line 13 ¶
	Request option as part of a SOCKS Request:		Request option as part of a SOCKS Request:
	1 2 3		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		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Kind = 11 | Length = 8 |		| Kind = 11 | Length = 8 |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Window Size |		| Window Size |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 24: Token Request		Figure 25: Token Request
	o Window Size: The requested window size.		o Window Size: The requested window size.
	Once a token window is issued, the proxy MUST include an Idempotence		Once a token window is issued, the proxy MUST include an Idempotence
	Window option in all subsequent successful Authentication Replies:		Window option in all subsequent successful Authentication Replies:
	1 2 3		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		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 |		| Kind = 12 | Length = 12 |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Window Base |		| Window Base |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| Window Size |		| Window Size |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 25: Idempotence Window		Figure 26: 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 MAY differ from the		o Window Size: The window size. This value MAY differ from the
	requested window size. Window sizes MUST be less than 2^31.		requested window size. Window sizes MUST be less than 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. If there is already a token window associated with		Token Request. If there is already a token window associated with
	the session, the proxy MUST NOT issue a new window.		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 Idempotence		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		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		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Kind = 13 | Length = 8 |		| Kind = 13 | Length = 4 |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Token |		| Token |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 26: Idempotence Expenditure		Figure 27: Idempotence Expenditure
	o Kind: 13 (Idempotence Expenditure option)		o Kind: 13 (Idempotence Expenditure option)
	o Length: 8		o Length: 8
	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 either an Idempotence Accepted or		The proxy responds by sending either an Idempotence Accepted or
	Rejected option as part of the Authentication Reply:		Rejected option as part of the Authentication Reply:
	1 2 3		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		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	| Kind = 14 | Length = 8 |		| Kind = 14 | Length = 4 |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	Figure 27: Idempotence Accepted		Figure 28: Idempotence Accepted
	1 2 3		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		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 |		| Kind = 15 | Length = 4 |
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	Figure 28: Idempotence Rejected		Figure 29: Idempotence Rejected
	If eligible, the token is spent before attempting to honor the		If eligible, the token is spent before attempting to honor the
	Request. If the token is not eligible for spending, the		Request. If the token is not eligible for spending, the
	Authentication Reply MUST indicate failure.		Authentication Reply MUST indicate failure.
	8.5.3. Shifting windows		8.5.3. Shifting windows
	Windows can be shifted (i. e. have their base increased, while		Windows can be shifted (i. e. have their base increased, while
	retaining their size) unilaterally by the proxy.		retaining their size) unilaterally by the proxy.
	skipping to change at page 31, line 29 ¶		skipping to change at page 32, line 25 ¶
	highest unspent token.		highest unspent token.
	8.5.4. Out-of-order Window Advertisements		8.5.4. Out-of-order Window Advertisements
	Even though the proxy increases the window's base monotonically,		Even though the proxy increases the window's base monotonically,
	there is no mechanism whereby a SOCKS client can receive the Token		there is no mechanism whereby a SOCKS client can receive the Token
	Window Advertisements in order. As such, clients SHOULD disregard		Window Advertisements in order. As such, clients SHOULD disregard
	Token Window Advertisements with a Window Base less than the		Token Window Advertisements with a Window Base less than the
	previously known value.		previously known value.
	8.6. Address Resolution Options
	Clients wishing to resolve an address from the proxy's vantage point
	can do so by sending a Resolution Request option:
	1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-------------------------------+-------------------------------+
	| Kind = 16 | Length = 4 |
	+-------------------------------+-------------------------------+
	Figure 29: Resolution Request
	The proxy's reply is included in the Operation Reply.
	8.6.1. Forward resolution
	If the address supplied by the client is a Domain Name, the proxy
	sends a Resolution option for each supported address type:
	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 = 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		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		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
	+-------------------------------+-------------------------------+		+-------------------------------+-------------------------------+
	skipping to change at page 33, line 46 ¶		skipping to change at page 32, line 46 ¶
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| Method = 2 | ...		| Method = 2 | ...
	+---------------+ ...		+---------------+ ...
	... ...		... ...
	... Username/Password Request ...		... Username/Password Request ...
	... ...		... ...
	... +-----------------------------------------------+		... +-----------------------------------------------+
	... | Padding = 0 (variable length, 0-3 bytes) |		... | Padding = 0 (variable length, 0-3 bytes) |
	+---------------+-----------------------------------------------+		+---------------+-----------------------------------------------+
	Figure 33: Password authentication via a SOCKS Option		Figure 30: Password authentication via a SOCKS Option
	o Username/Password Request: The Username/Password Request, as		o Username/Password Request: The Username/Password Request, as
	described in [RFC1929].		described in [RFC1929].
	Proxies reply by including a Authentication Data Option in the next		Proxies reply by including a Authentication Data Option in the next
	Authentication Reply which contains the Username/Password reply:		Authentication Reply which contains the Username/Password reply:
	1 2 3		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		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 |		| Kind = 4 | Length = 8 |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| Method = 2 | Username/Password Reply | Padding = 0 |		| Method = 2 | Username/Password Reply | Padding = 0 |
	+---------------+-------------------------------+---------------+		+---------------+-------------------------------+---------------+
	Figure 34: Reply to password authentication via a SOCKS Option		Figure 31: Reply to password authentication via a SOCKS Option
	o Username/Password Reply: The Username/Password Reply, as described		o Username/Password Reply: The Username/Password Reply, as described
	in [RFC1929].		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.
	skipping to change at page 35, line 17 ¶		skipping to change at page 34, line 17 ¶
	to happen. In this case, application data MAY be sent immediately		to happen. In this case, application data MAY be sent immediately
	after the Request.		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. DNS provided by SOCKS
	12.1. Large requests		Clients may require information typically obtained from DNS servers,
			albeit from the proxy's vantage point.
			While the CONNECT command can work with domain names, some clients'
			workflows require that addresses be resolved as a separate step prior
			to connecting. Moreover, the SOCKS Datagram Header, as described in
			Section 7.3, can be reduced in size by providing the resolved
			destination IP address, rather than the FQDN.
			Emerging techniques may also make use of DNS to deliver server-
			specific information to clients. For example, Encrypted SNI
			[I-D.ietf-tls-esni] relies on DNS to publish encryption keys.
			Proxy implementations MAY provide a default plaintext DNS service. A
			client looking to make use of it issues a CONNECT Request to IP
			address 0.0.0.0 or 0:0:0:0:0:0:0:0 on port 53. Following successful
			authentication, the Operation Reply indicates an unspecified bind
			address (0.0.0.0 or ::) and port (0). The client and proxy then
			behave as per [RFC7766].
			The service itself can be provided directly by the proxy daemon, or
			by proxying the client's request to a pre-configured DNS server.
			If the proxy does not implement such functionality, it MAY return an
			error code signalling "Connection refused".
			13. Security Considerations
			13.1. Large requests
	Given the format of the request message, a malicious client could		Given the format of the request message, a malicious client could
	craft a request that is in excess of 16 KB and proxies could be prone		craft a request that is in excess of 16 KB and proxies could be prone
	to DDoS attacks.		to DDoS attacks.
	To mitigate such attacks, proxy implementations SHOULD be able to		To mitigate such attacks, proxy implementations SHOULD be able to
	incrementally parse the requests. Proxies MAY close the connection		incrementally parse the requests. Proxies MAY close the connection
	to the client if:		to the client if:
	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		13.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, anything prior to the initial Token Request is still		attacks, anything prior to the initial Token Request is still
	vulnerable. As such, client implementations SHOULD NOT make use of		vulnerable. As such, client implementations SHOULD NOT make use of
	TLS early data unless the Request attempts to spend a token.		TLS early data unless the Request attempts to spend a token.
	12.3. Resource exhaustion		13.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		14. IANA Considerations
	This document requests that IANA allocate 2-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 Unassigned: 0		o Unassigned: 0
	o Stack: 1		o Stack: 1
	o Authentication Method Advertisement: 2		o Authentication Method Advertisement: 2
	skipping to change at page 36, line 49 ¶		skipping to change at page 36, line 26 ¶
	o Idempotence Accepted: 14		o Idempotence Accepted: 14
	o Idempotence Rejected: 15		o Idempotence Rejected: 15
	o Resolution Request: 16		o Resolution Request: 16
	o IPv4 Resolution: 17		o IPv4 Resolution: 17
	o IPv6 Resolution: 18		o IPv6 Resolution: 18
	o Domain Name Resolution: 19
	o Vendor-specific: 64512-0xFFFF		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		15. 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		16. References
	15.1. Normative References		16.1. Normative References
	[RFC1929] Leech, M., "Username/Password Authentication for SOCKS		[RFC1929] Leech, M., "Username/Password Authentication for SOCKS
	V5", RFC 1929, DOI 10.17487/RFC1929, March 1996,		V5", RFC 1929, DOI 10.17487/RFC1929, March 1996,
	<https://www.rfc-editor.org/info/rfc1929>.		<https://www.rfc-editor.org/info/rfc1929>.
	[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		[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
			D. Wessels, "DNS Transport over TCP - Implementation
			Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
			<https://www.rfc-editor.org/info/rfc7766>.
			[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
			Better Connectivity Using Concurrency", RFC 8305,
			DOI 10.17487/RFC8305, December 2017,
			<https://www.rfc-editor.org/info/rfc8305>.
			16.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-06 (work in progress), July 2019.		id-07 (work in progress), October 2019.
			[I-D.ietf-tls-esni]
			Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
			"Encrypted Server Name Indication for TLS 1.3", draft-
			ietf-tls-esni-04 (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>.
End of changes. 56 change blocks.
	160 lines changed or deleted		151 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/