Skip to main content

SOCKS Protocol Version 6
draft-olteanu-intarea-socks-6-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Vladimir Olteanu , Dragos Niculescu
Last updated 2019-03-11 (Latest revision 2018-10-23)
Replaces draft-intarea-olteanu-socks-6, draft-olteanu-socks-6
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-olteanu-intarea-socks-6-06
Internet Area Working Group                                   V. Olteanu
Internet-Draft                                              D. Niculescu
Intended status: Experimental        University Politehnica of Bucharest
Expires: September 12, 2019                               March 11, 2019

                        SOCKS Protocol Version 6
                    draft-olteanu-intarea-socks-6-06

Abstract

   The SOCKS protocol is used primarily to proxy TCP connections to
   arbitrary destinations via the use of a proxy server.  Under the
   latest version of the protocol (version 5), it takes 2 RTTs (or 3, if
   authentication is used) before data can flow between the client and
   the server.

   This memo proposes SOCKS version 6, which reduces the number of RTTs
   used, takes full advantage of TCP Fast Open, and adds support for
   0-RTT authentication.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 12, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Olteanu & Niculescu    Expires September 12, 2019               [Page 1]
Internet-Draft                   SOCKS 6                      March 2019

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Revision log  . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Requirements language . . . . . . . . . . . . . . . . . . . .   8
   3.  Mode of operation . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Requests  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Version Mismatch Replies  . . . . . . . . . . . . . . . . . .  12
   6.  Authentication Replies  . . . . . . . . . . . . . . . . . . .  12
   7.  Operation Replies . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Handling CONNECT  . . . . . . . . . . . . . . . . . . . .  14
     7.2.  Handling BIND . . . . . . . . . . . . . . . . . . . . . .  15
     7.3.  Handling UDP ASSOCIATE  . . . . . . . . . . . . . . . . .  15
       7.3.1.  Proxying UDP servers  . . . . . . . . . . . . . . . .  17
   8.  SOCKS Options . . . . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  Stack options . . . . . . . . . . . . . . . . . . . . . .  17
       8.1.1.  IP TOS options  . . . . . . . . . . . . . . . . . . .  19
       8.1.2.  TFO options . . . . . . . . . . . . . . . . . . . . .  19
       8.1.3.  Multipath TCP options . . . . . . . . . . . . . . . .  20
       8.1.4.  MPTCP Scheduler options . . . . . . . . . . . . . . .  20
       8.1.5.  Listen Backlog options  . . . . . . . . . . . . . . .  21
     8.2.  Authentication Method options . . . . . . . . . . . . . .  22
     8.3.  Authentication Data options . . . . . . . . . . . . . . .  23
     8.4.  Session options . . . . . . . . . . . . . . . . . . . . .  24
       8.4.1.  Session initiation  . . . . . . . . . . . . . . . . .  24
       8.4.2.  Further SOCKS Requests  . . . . . . . . . . . . . . .  26
       8.4.3.  Tearing down the session  . . . . . . . . . . . . . .  27
     8.5.  Idempotence options . . . . . . . . . . . . . . . . . . .  28
       8.5.1.  Requesting a fresh token window . . . . . . . . . . .  29
       8.5.2.  Spending a token  . . . . . . . . . . . . . . . . . .  30
       8.5.3.  Handling Token Window Advertisements  . . . . . . . .  32
   9.  Username/Password Authentication  . . . . . . . . . . . . . .  32
   10. TCP Fast Open on the Client-Proxy Leg . . . . . . . . . . . .  32
   11. False Starts  . . . . . . . . . . . . . . . . . . . . . . . .  33
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  33
     12.1.  Large requests . . . . . . . . . . . . . . . . . . . . .  33
     12.2.  Replay attacks . . . . . . . . . . . . . . . . . . . . .  34
     12.3.  Resource exhaustion  . . . . . . . . . . . . . . . . . .  34
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  34
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  35
     15.2.  Informative References . . . . . . . . . . . . . . . . .  35

Olteanu & Niculescu    Expires September 12, 2019               [Page 2]
Internet-Draft                   SOCKS 6                      March 2019

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35

1.  Introduction

   Versions 4 and 5 [RFC1928] of the SOCKS protocol were developed two
   decades ago and are in widespread use for circuit level gateways or
   as circumvention tools, and enjoy wide support and usage from various
   software, such as web browsers, SSH clients, and proxifiers.
   However, their design needs an update in order to take advantage of
   the new features of transport protocols, such as TCP Fast Open
   [RFC7413], or to better assist newer transport protocols, such as
   MPTCP [RFC6824].

   One of the main issues faced by SOCKS version 5 is that, when taking
   into account the TCP handshake, method negotiation, authentication,
   connection request and grant, it may take up to 5 RTTs for a data
   exchange to take place at the application layer.  This is especially
   costly in networks with a large delay at the access layer, such as
   3G, 4G, or satelite.

   The desire to reduce the number of RTTs manifests itself in the
   design of newer security protocols.  TLS version 1.3 [RFC8446]
   defines a zero round trip (0-RTT) handshake mode for connections if
   the client and server had previously communicated.

   TCP Fast Open [RFC7413] is a TCP option that allows TCP to send data
   in the SYN and receive a response in the first ACK, and aims at
   obtaining a data response in one RTT.  The SOCKS protocol needs to
   concern itself with at least two TFO deployment scenarios: First,
   when TFO is available end-to-end (at the client, at the proxy, and at
   the server); second, when TFO is active between the client and the
   proxy, but not at the server.

   This document describes the SOCKS protocol version 6.  The key
   improvements over SOCKS version 5 are:

   o  The client sends as much information upfront as possible, and does
      not wait for the authentication process to conclude before
      requesting the creation of a socket.

   o  The connection request also mimics the semantics of TCP Fast Open
      [RFC7413].  As part of the connection request, the client can
      supply the potential payload for the initial SYN that is sent out
      to the server.

   o  The protocol can be extended via options without breaking
      backward-compatibility.

Olteanu & Niculescu    Expires September 12, 2019               [Page 3]
Internet-Draft                   SOCKS 6                      March 2019

   o  The protocol can leverage the aforementioned options to support
      0-RTT authentication schemes.

1.1.  Revision log

   Typos and minor clarifications are not listed.

   draft-06

   o  Session options

   o  Options now have a 2-byte length field.

   o  Stack options

      *  Stack options can no longer contain duplicate information.

      *  TFO: Better payload size semantics

      *  TOS: Added missing code field.

      *  MPTCP Scheduler options:

         +  Removed support for round-robin

         +  "Default" renamed to "Lowest latency first"

      *  Listen Backlog options: now tied to sessions, instead of an
         authenticated user

   o  Idempotence options

      *  Now used in the context of a session (no longer tied to an
         authenticated user)

      *  Idempotence options have a different codepoint: 0x05.  (Was
         0x04.)

      *  Clarified that implementations that support Idempotence Options
         must support all Idempotence Option Types.

      *  Shifted Idempotence Option Types by 1.  (Makes implementation
         easier.)

   o  Shrunk vendor-specific option range to 32 (down from 64).

   o  Removed reference to dropping initial data.  (It could no longer
      be done as of -05.)

Olteanu & Niculescu    Expires September 12, 2019               [Page 4]
Internet-Draft                   SOCKS 6                      March 2019

   o  Initial data size capped at 16KB.

   o  Application data is never encrypted by SOCKS 6.  (It can still be
      encrypted by the TLS layer under SOCKS.)

   o  Messages now carry the total length of the options, rather than
      the number of options.  Limited options length to 16KB.

   o  Security Considerations

      *  Updated the section to reflect the smaller maximum message
         size.

      *  Added a subsection on resource exhaustion.

   draft-05

   o  Limited the "slow" authentication negociations to one (and
      Authentication Replies to 2)

   o  Revamped the handling of the first bytes in the application data
      stream

      *  False starts are now recommended.  (Added the "False Start"
         section.)

      *  Initial data is only available to clients willing to do "slow"
         authentication.  Moved the "Initial data size" field from
         Requests to Authentication Method options.

      *  Initial data size capped at 2^13.  Initial data can no longer
         be dropped by the proxy.

      *  The TFO option can hint at the desired SYN payload size.

   o  Request: clarified the meaning of the Address and Port fields.

   o  Better reverse TCP proxy support: optional listen backlog for TCP
      BIND

   o  TFO options can no longer be placed inside Operation Replies.

   o  IP TOS stack option

   o  Suggested a range for vendor-specific options.

   o  Revamped UDP functionality

Olteanu & Niculescu    Expires September 12, 2019               [Page 5]
Internet-Draft                   SOCKS 6                      March 2019

      *  Now using fixed UDP ports

      *  DTLS support

   o  Stack options: renamed Proxy-Server leg to Proxy-Remote leg

   draft-04

   o  Moved Token Expenditure Replies to the Authentication Reply.

   o  Shifted the Initial Data Size field in the Request, in order to
      make it easier to parse.

   draft-03

   o  Shifted some fields in the Operation Reply to make it easier to
      parse.

   o  Added connection attempt timeout response code to Operation
      Replies.

   o  Proxies send an additional Authentication Reply after the
      authentication phase.  (Useful for token window advertisements.)

   o  Renamed the section "Connection Requests" to "Requests"

   o  Clarified the fact that proxies don't need to support any command
      in particular.

   o  Added the section "TCP Fast Open on the Client-Proxy Leg"

   o  Options:

      *  Added constants for option kinds

      *  Salt options removed, along with the relevant section from
         Security Considerations.  (TLS 1.3 Makes AEAD mandatory.)

      *  Limited Authentication Data options to one per method.

      *  Relaxed proxy requirements with regard to handling multiple
         Authentication Data options.  (When the client violates the
         above bullet point.)

      *  Removed interdependence between Authentication Method and
         Authentication Data options.

Olteanu & Niculescu    Expires September 12, 2019               [Page 6]
Internet-Draft                   SOCKS 6                      March 2019

      *  Clients SHOULD omit advertising the "No authentication
         required" option.  (Was MAY.)

      *  Idempotence options:

         +  Token Window Advertisements are now part of successful
            Authentication Replies (so that the proxy-server RTT has no
            impact on their timeliness).

         +  Proxies can't advetise token windows of size 0.

         +  Tweaked token expenditure response codes.

         +  Support no longer mandatory on the proxy side.

      *  Revamped Socket options

         +  Renamed Socket options to Stack options.

         +  Banned contradictory socket options.

         +  Added socket level for generic IP.  Removed the "socket"
            socket level.

         +  Stack options no longer use option codes from setsockopt().

         +  Changed MPTCP Scheduler constants.

   draft-02

   o  Made support for Idempotence options mandatory for proxies.

   o  Clarified what happens when proxies can not or will not issue
      tokens.

   o  Limited token windows to 2^31 - 1.

   o  Fixed definition of "less than" for tokens.

   o  NOOP commands now trigger Operation Replies.

   o  Renamed Authentication options to Authentication Data options.

   o  Authentication Data options are no longer mandatory.

   o  Authentication methods are now advertised via options.

   o  Shifted some Request fields.

Olteanu & Niculescu    Expires September 12, 2019               [Page 7]
Internet-Draft                   SOCKS 6                      March 2019

   o  Option range for vendor-specific options.

   o  Socket options.

   o  Password authentication.

   o  Salt options.

   draft-01

   o  Added this section.

   o  Support for idempotent commands.

   o  Removed version numbers from operation replies.

   o  Request port number for SOCKS over TLS.  Deprecate encryption/
      encapsulation within SOCKS.

   o  Added Version Mismatch Replies.

   o  Renamed the AUTH command to NOOP.

   o  Shifted some fields to make requests and operation replies easier
      to parse.

2.  Requirements language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Mode of operation

Olteanu & Niculescu    Expires September 12, 2019               [Page 8]
Internet-Draft                   SOCKS 6                      March 2019

    CLIENT                                                        PROXY

            +------------------------+
            | Authentication methods | Request
    --------> Command code           +------------------------------>
            | Address                |
            | Port                   |
            | Options                |
            +------------------------+

            +------------------------+
    --------> Initial data           +------------------------------>
            +------------------------+

                                        +-----------------------+
                   Authentication Reply | Type                  |
     <----------------------------------+ Method                <-----
                                        | Options               |
                                        +-----------------------+

     <-------------------(Authentication protocol)------------------>

                                        +-----------------------+
                   Authentication Reply | Type = Success        |
     <----------------------------------+ Method                <-----
                                        | Options               |
                                        +-----------------------+

                          +-----------------------+
        Operation Reply   | Reply code            |
     <--------------------+ Bind address          <------------------
                          | Bind port             |
                          | Options               |
                          +-----------------------+

          Figure 1: The SOCKS version 6 protocol message exchange

   When a TCP-based client wishes to establish a connection to a server,
   it must open a TCP connection to the appropriate SOCKS port on the
   SOCKS proxy.  The client then enters a negotiation phase, by sending
   the request in Figure 1, that contains, in addition to fields present
   in SOCKS 5 [RFC1928], fields that facilitate low RTT usage and faster
   authentication negotiation.

   Next, the server sends an authentication reply.  If the request did
   not contain the necessary authentication information, the proxy

Olteanu & Niculescu    Expires September 12, 2019               [Page 9]
Internet-Draft                   SOCKS 6                      March 2019

   indicates an authentication method that must proceed.  This may
   trigger a longer authentication sequence that could include tokens
   for ulterior faster authentications.  The part labeled
   "Authentication protocol" is specific to the authentication method
   employed and is not expected to be employed for every connection
   between a client and its proxy server.  The authentication protocol
   typically takes up 1 RTT or more.

   If the authentication is successful, an operation reply is generated
   by the proxy.  It indicates whether the proxy was successful in
   creating the requested socket or not.

   In the fast case, when authentication is properly set up, the proxy
   attempts to create the socket immediately after the receipt of the
   request, thus achieving an operational conection in one RTT (provided
   TFO functionality is available at the client, proxy, and server).

4.  Requests

   The client starts by sending a request to the proxy.

   +---------------+---------+------+---------+----------+
   |    Version    | Command | Port | Address | Address  |
   | Major | Minor |  Code   |      |  Type   |          |
   +-------+-------+---------+------+---------+----------+
   |   1   |   1   |    1    |  2   |    1    | Variable |
   +-------+-------+---------+------+---------+----------+
   +---------+----------+
   | Options | Options  |
   | Length  |          |
   +---------+----------+
   |    2    | Variable |
   +---------+----------+

                         Figure 2: SOCKS 6 Request

   o  Version: The major byte is 0x06, and the minor byte is 0x00.

   o  Command Code:

      *  0x00 NOOP: does nothing.

      *  0x01 CONNECT: requests the establishment of a TCP connection.
         TFO MUST NOT be used unless explicitly requested.

      *  0x02 BIND: requests the establishment of a TCP port binding.

Olteanu & Niculescu    Expires September 12, 2019              [Page 10]
Internet-Draft                   SOCKS 6                      March 2019

      *  0x03 UDP ASSOCIATE: requests a UDP port association.

   o  Address Type:

      *  0x01: IPv4

      *  0x03: Domain Name

      *  0x04: IPv6

   o  Address: this field's format depends on the address type:

      *  IPv4: a 4-byte IPv4 address

      *  Domain Name: one byte that contains the length of the FQDN,
         followed by the FQDN itself.  The string is not NUL-terminated.

      *  IPv6: a 16-byte IPv6 address

   o  Port: the port in network byte order.

   o  Options Length: the total size of the SOCKS options that appear in
      the Options field.  MUST NOT exceed 16KB.

   o  Options: see Section 8.

   The Address and Port fields have different meanings based on the
   Command Code:

   o  NOOP: The fields have no meaning.  The Address Type field MUST be
      either 0x01 (IPv4) or 0x04 (IPv6).  The Address and Port fields
      MUST be 0.

   o  CONNECT: The fields signify the address and port to which the
      client wishes to connect.

   o  BIND, UDP ASSOCIATE: The fields indicate the desired bind address
      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
      the Address field to 0.  Likewise, if the client does not require
      a certain port, it can set the Port field to 0.

   Clients can advertise their supported authentication methods by
   including an Authentication Method option (see Section 8.2).

Olteanu & Niculescu    Expires September 12, 2019              [Page 11]
Internet-Draft                   SOCKS 6                      March 2019

5.  Version Mismatch Replies

   Upon receipt of a request starting with a version number other than
   6.0, the proxy sends the following response:

   +---------------+
   |    Version    |
   | Major | Minor |
   +-------+-------+
   |   1   |   1   |
   +-------+-------+

                 Figure 3: SOCKS 6 Version Mismatch Reply

   o  Version: The major byte is 0x06, and the minor byte is 0x00.

   A client MUST close the connection after receiving such a reply.

6.  Authentication Replies

   Upon receipt of a valid request, the proxy sends an Authentication
   Reply:

   +---------------+------+--------+---------+----------+
   |    Version    | Type | Method | Options | Options  |
   | Major | Minor |      |        | Length  |          |
   +-------+-------+------+--------+---------+----------+
   |   1   |   1   |  1   |   1    |    2    | Variable |
   +-------+-------+------+--------+---------+----------+

                  Figure 4: SOCKS 6 Authentication Reply

   o  Version: The major byte is 0x06, and the minor byte is 0x00.

   o  Type:

      *  0x00: authentication successful.

      *  0x01: further authentication needed.

   o  Method: The chosen authentication method.

   o  Options Length: the total size of the SOCKS options that appear in
      the Options field.  MUST NOT exceed 16KB.

   o  Options: see Section 8.

Olteanu & Niculescu    Expires September 12, 2019              [Page 12]
Internet-Draft                   SOCKS 6                      March 2019

   Multihomed clients SHOULD cache the chosen method on a per-interface
   basis and SHOULD NOT include Authentication Data options related to
   any other methods in further requests originating from the same
   interface.

   If the server signals that further authentication is needed and
   selects "No Acceptable Methods", the client MUST close the
   connection.

   The client and proxy begin a method-specific negotiation.  During
   such negotiations, the proxy MAY supply information that allows the
   client to authenticate a future request using an Authentication Data
   option.  Application data is not subject to any encryption negotiated
   during this phase.  Descriptions of such negotiations are beyond the
   scope of this memo.

   When the negotiation is complete (either successfully or
   unsuccessfully), the proxy sends a second Authentication Reply.  The
   second Authentication Reply MUST either signal success or that there
   are no more acceptable authentication methods.

7.  Operation Replies

   After the authentication negotiations are complete, the proxy sends
   an Operation Reply:

   +-------+------+---------+----------+---------+----------+
   | Reply | Bind | Address |   Bind   | Options | Options  |
   | Code  | Port |  Type   | Address  | Length  |          |
   +-------+------+---------+----------+---------+----------+
   |   1   |  2   |    1    | Variable |    2    | Variable |
   +-------+------+---------+----------+---------+----------+

                     Figure 5: SOCKS 6 Operation Reply

   o  Reply Code:

      *  0x00: Succes

      *  0x01: General SOCKS server failure

      *  0x02: Connection not allowed by ruleset

      *  0x03: Network unreachable

      *  0x04: Host unreachable

Olteanu & Niculescu    Expires September 12, 2019              [Page 13]
Internet-Draft                   SOCKS 6                      March 2019

      *  0x05: Connection refused

      *  0x06: TTL expired

      *  0x07: Command not supported

      *  0x08: Address type not supported

      *  0x09: Connection attempt timed out

   o  Bind Port: the proxy bound port in network byte order.

   o  Address Type:

      *  0x01: IPv4

      *  0x03: Domain Name

      *  0x04: IPv6

   o  Bind Address: the proxy bound address in the following format:

      *  IPv4: a 4-byte IPv4 address

      *  Domain Name: one byte that contains the length of the FQDN,
         followed by the FQDN itself.  The string is not NUL-terminated.

      *  IPv6: a 16-byte IPv6 address

   o  Options Length: the total size of the SOCKS options that appear in
      the Options field.  MUST NOT exceed 16KB.

   o  Options: see Section 8.

   Proxy implementations MAY support any subset of the client commands
   listed in Section 4.

   If the proxy returns a reply code other than "Success", the client
   MUST close the connection.

   If the client issued an NOOP command, the client MUST close the
   connection after receiving the Operation Reply.

7.1.  Handling CONNECT

   In case the client has issued a CONNECT request, data can now pass.

Olteanu & Niculescu    Expires September 12, 2019              [Page 14]
Internet-Draft                   SOCKS 6                      March 2019

7.2.  Handling BIND

   In case the client has issued a BIND request, it must wait for a
   second Operation reply from the proxy, which signifies that a host
   has connected to the bound port.  The Bind Address and Bind Port
   fields contain the address and port of the connecting host.
   Afterwards, application data may pass.

7.3.  Handling UDP ASSOCIATE

   Proxies offering UDP functionality must be configured with a UDP port
   used for relaying UDP datagrams to and from the client, and/or a port
   used for relaying datagrams over DTLS.

   Following a successful Operation Reply, the proxy sends a UDP
   Association Initialization message:

   +----------------+
   | Association ID |
   +----------------+
   |        4       |
   +----------------+

                 Figure 6: UDP Association Initialization

   o  Association ID: the identifier of the UDP association

   Proxy implementations SHOULD generate Association IDs randomly or
   pseudo-randomly.

   Clients may start sending UDP datagrams to the proxy either in
   plaintext, or over an established DTLS session, using the proxy's
   configured UDP ports.  A client's datagrams are prefixed by a SOCKS
   Datagram Header, indicating the remote host's address and port:

   +---------------+-------------+------+---------+----------+
   |    Version    | Association | Port | Address | Address  |
   | Major | Minor |      ID     |      |  Type   |          |
   +-------+-------+-------------+------+---------+----------+
   |   1   |   1   |      4      |  2   |    1    | Variable |
   +-------+-------+-------------+------+---------+----------+

                     Figure 7: SOCKS 6 Datagram Header

   o  Version: The major byte is 0x06, and the minor byte is 0x00.

Olteanu & Niculescu    Expires September 12, 2019              [Page 15]
Internet-Draft                   SOCKS 6                      March 2019

   o  Association ID: the identifier of the UDP association

   o  Address Type:

      *  0x01: IPv4

      *  0x03: Domain Name

      *  0x04: IPv6

   o  Address: this field's format depends on the address type:

      *  IPv4: a 4-byte IPv4 address

      *  Domain Name: one byte that contains the length of the FQDN,
         followed by the FQDN itself.  The string is not NUL-terminated.

      *  IPv6: a 16-byte IPv6 address

   o  Port: the port in network byte order.

   Following the receipt of the first datagram from the client, the
   proxy makes a one-way mapping between the Association ID and:

   o  the 5-tuple of the UDP conversation, if the datagram was received
      over plain UDP, or

   o  the DTLS connection, if the datagram was received over DTLS.  The
      DTLS connection is identified either by its 5-tuple, or some other
      mechanism, like [I-D.ietf-tls-dtls-connection-id].

   Further datagrams carrying the same Association ID, but not matching
   the established mapping, are silently dropped.

   The proxy then sends an UDP Association Confirmation message over the
   TCP connection with the client:

   +--------+
   | Status |
   +--------+
   |   1    |
   +--------+

                  Figure 8: UDP Association Confirmation

   o  Status: MUST be 0x00

Olteanu & Niculescu    Expires September 12, 2019              [Page 16]
Internet-Draft                   SOCKS 6                      March 2019

   Following the confirmation message, UDP packets bound for the proxy's
   bind address and port are relayed to the client, also prefixed by a
   Datagram Header.

   The UDP association remains active for as long as the TCP connection
   between the client and the proxy is kept open.

7.3.1.  Proxying UDP servers

   Under some circumstances (e.g. when hosting a server), the SOCKS
   client expects the remote host to send UDP datagrams first.  As such,
   the SOCKS client must trigger a UDP Association Confirmation without
   having the proxy relay any datagrams on its behalf.

   To that end, it sends an empty datagram prefixed by a Datagram Header
   with an IP address and port consisting of zeroes.  The client SHOULD
   resend the empty datagram if an UDP Association Confirmation is not
   received after a timeout.

8.  SOCKS Options

   SOCKS options have the following format:

   +------+--------+-------------+
   | Kind | Length | Option Data |
   +------+--------+-------------+
   |  1   |   2    |   Variable  |
   +------+--------+-------------+

                         Figure 9: SOCKS 6 Option

   o  Kind: Allocated by IANA.  (See Section 13.)

   o  Length: The total length of the option.

   o  Option Data: The contents are specific to each option kind.

   Unless otherwise noted, client and proxy implementations MAY omit
   supporting any of the options described in this document.  Upon
   encountering an unsupported option, a SOCKS endpoint MUST silently
   ignore it.

8.1.  Stack options

   Stack options can be used by clients to alter the behavior of the
   protocols on top of which SOCKS is running, as well the protcols used
   by the proxy to communicate with the remote host (i.e.  IP, TCP,

Olteanu & Niculescu    Expires September 12, 2019              [Page 17]
Internet-Draft                   SOCKS 6                      March 2019

   UDP).  A Stack option can affect either the proxy's protocol on the
   client-proxy leg or on the proxy-remote leg.  Clients can only place
   Stack options inside SOCKS Requests.

   Proxies MAY include Stack options in their Operation Replies to
   signal their behavior.  Said options MAY be unsolicited, i. e. the
   proxy MAY send them to signal behaviour that was not explicitly
   requested by the client.

   In case of UDP ASSOCIATE, the stack options refer to the UDP traffic
   relayed by the proxy.

   Stack options that are part of the same message MUST NOT contradict
   one another or contain duplicate information.

   +------+--------+--------+--------+------+----------+
   | Kind | Length |  Leg   | Level  | Code |   Data   |
   +------+--------+--------+--------+------+----------+
   |  1   |   2    | 2 bits | 6 bits |  1   | Variable |
   +------+--------+--------+--------+------+----------+

                          Figure 10: Stack Option

   o  Kind: 0x01 (Stack option)

   o  Length: The length of the option.

   o  Leg:

      *  0x1: Client-Proxy Leg

      *  0x2: Proxy-Remote Leg

      *  0x3: Both Legs

   o  Level:

      *  0x01: IP: options that apply to either IPv4 or IPv6

      *  0x02: IPv4

      *  0x03: IPv6

      *  0x04: TCP

      *  0x05: UDP

Olteanu & Niculescu    Expires September 12, 2019              [Page 18]
Internet-Draft                   SOCKS 6                      March 2019

   o  Code: Option code

   o  Data: Option-specific data

8.1.1.  IP TOS options

   +------+--------+--------+--------+------+-----+
   | Kind | Length |  Leg   | Level  | Code | TOS |
   +------+--------+--------+--------+------+-----+
   |  1   |   2    | 2 bits | 6 bits |  1   |  1  |
   +------+--------+--------+--------+------+-----+

                         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

   The client can use IP TOS options to request that the proxy use a
   certain value for the IP TOS field.  Likewise, the proxy can use IP
   TOS options to advertise the TOS values being used.

8.1.2.  TFO options

   +------+--------+--------+--------+------+--------------+
   | Kind | Length |  Leg   | Level  | Code | Payload Size |
   +------+--------+--------+--------+------+--------------+
   |  1   |   2    | 2 bits | 6 bits |  1   |      2       |
   +------+--------+--------+--------+------+--------------+

                           Figure 12: TFO Option

   o  Kind: 0x01 (Stack option)

   o  Length: 4

   o  Leg: 0x02 (Proxy-Remote leg).

Olteanu & Niculescu    Expires September 12, 2019              [Page 19]
Internet-Draft                   SOCKS 6                      March 2019

   o  Level: 0x04 (TCP).

   o  Code: 0x01

   o  Payload Size: The desired payload size of the TFO SYN.  Ignored in
      case of a BIND command.

   If a SOCKS Request contains a TFO option, the proxy SHOULD attempt to
   use TFO in case of a CONNECT command, or accept TFO in case of a BIND
   command.  Otherwise, the proxy MUST NOT attempt to use TFO in case of
   a CONNECT command, or accept TFO in case of a BIND command.

   In case of a CONNECT command, the client can indicate the desired
   payload size of the SYN.  If the field is 0, the proxy can use an
   arbitrary payload size.  If the field is non-zero, the proxy MUST NOT
   use a payload size larger than the one indicated.  The proxy MAY use
   a smaller payload size than the one indicated.

8.1.3.  Multipath TCP options

   In case of a CONNECT command, the proxy can inform the client that
   the connection to the server is an MPTCP connection.

   +------+--------+--------+--------+------+
   | Kind | Length |  Leg   | Level  | Code |
   +------+--------+--------+--------+------+
   |  1   |   2    | 2 bits | 6 bits |  1   |
   +------+--------+--------+--------+------+

                      Figure 13: Multipath TCP Option

   o  Kind: 0x01 (Stack option)

   o  Length: 4

   o  Leg: 0x02 (Proxy-Remote leg)

   o  Level: 0x04 (TCP).

   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.

Olteanu & Niculescu    Expires September 12, 2019              [Page 20]
Internet-Draft                   SOCKS 6                      March 2019

   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

8.1.5.  Listen Backlog options

   +------+--------+--------+--------+---------+
   | Kind | Length |  Leg   | Level  | Backlog |
   +------+--------+--------+--------+---------+
   |  1   |   2    | 2 bits | 6 bits |    2    |
   +------+--------+--------+--------+---------+

                     Figure 15: Listen Backlog Option

   o  Kind: 0x01 (Stack option)

   o  Length: 5

   o  Leg: 0x02 (Proxy-Remote leg)

   o  Level: 0x04 (TCP)

Olteanu & Niculescu    Expires September 12, 2019              [Page 21]
Internet-Draft                   SOCKS 6                      March 2019

   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
   simultaneously handle multiple connections to the same bind address.
   A client can alter BIND's behavior by adding a TCP Listen Backlog
   Option to a BIND Request, provided that the Request is part of a
   Session.

   In response, the proxy sends a TCP Listen Backlog Option as part of
   the Operation Reply, with the Backlog field signalling the actual
   backlog used.  The proxy SHOULD NOT use a backlog longer than
   requested.

   Following the successful negotiation of a backlog, the proxy listens
   for incoming connections for as long as the initial connection stays
   open.  The initial connection is not used to relay data between the
   client and a remote host.

   To accept connections, the client issues further BIND Requests using
   the bind address and port supplied by the proxy in the initial
   Operation Reply.  Said BIND requests must belong to the same Session
   as the original Request.

   If a proxy can not or will not honor a Listen Backlog option, it does
   so silently.

8.2.  Authentication Method options

   Authentication Method options are placed in SOCKS Requests to
   advertise supported authentication methods.  In case of a CONNECT
   Request, they are also used to specify the amount of initial data
   supplied before any method-specific authentication negotiations take
   place.

   +------+--------+---------------------+----------+
   | Kind | Length | Initial Data Length | Methods  |
   +------+--------+---------------------+----------+
   |  1   |   2    |          2          | Variable |
   +------+--------+---------------------+----------+

                  Figure 16: Authentication Method Option

   o  Kind: 0x02 (Authentication Method option)

Olteanu & Niculescu    Expires September 12, 2019              [Page 22]
Internet-Draft                   SOCKS 6                      March 2019

   o  Length: The length of the option.

   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
      are supplied by the client immediately following the Request.
      This number MUST NOT be larger than 2^14.

   o  Methods: One byte per advertised method.  Method numbers are
      assigned by IANA.

   Clients MUST support the "No authentication required" method.
   Clients SHOULD omit advertising the "No authentication required"
   option.

8.3.  Authentication Data options

   Authentication Data options carry method-specific authentication
   data.  They can be part of SOCKS Requests and Authentication Replies.

   Authentication Data options have the following format:

   +------+--------+--------+---------------------+
   | Kind | Length | Method | Authentication Data |
   +------+--------+--------+---------------------+
   |  1   |   2    |   1    |       Variable      |
   +------+--------+--------+---------------------+

                   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
      are assigned by IANA.

   o  Authentication Data: The contents are specific to each method.

   Clients SHOULD only place one Authentication Data option per
   authentication method.  Server implementations MAY silently ignore
   all Authentication Data options for the same method aside from an
   arbitrarily chosen one.

Olteanu & Niculescu    Expires September 12, 2019              [Page 23]
Internet-Draft                   SOCKS 6                      March 2019

8.4.  Session options

   Clients and proxies can establish SOCKS sessions, which span one or
   more Requests.  All session-related negotiations are done via Session
   Options, which are placed in Requests and Authentication Replies by
   the client and, respectively, by the proxy.

   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
   Option Types, or none.

8.4.1.  Session initiation

   A client can initiate a session by sending a Session Request Option:

Olteanu & Niculescu    Expires September 12, 2019              [Page 24]
Internet-Draft                   SOCKS 6                      March 2019

   +------+--------+------+
   | Kind | Length | Type |
   +------+--------+------+
   |  1   |   2    |  1   |
   +------+--------+------+

                     Figure 19: Session Request Option

   o  Kind: 0x04 (Session option)

   o  Length: 4

   o  Type: 0x01 (Session Request)

   The proxy then replies with a Session ID Option in the successful
   Operation Reply:

   +------+--------+------+------------+
   | Kind | Length | Type | Session ID |
   +------+--------+------+------------+
   |  1   |   2    |  1   |  Variable  |
   +------+--------+------+------------+

                       Figure 20: Session ID Option

   o  Kind: 0x04 (Session option)

   o  Length: The length of the option.

   o  Type: 0x02 (Session ID)

   o  Session ID: An opaque sequence of bytes specific to the session.
      MUST be at least one byte in size.

   The Session ID serves to identify the session and is opaque to the
   client.

   The credentials, or lack thereof, used to initiate the session are
   tied to the session.  If authentication is to be performed for
   further Requests, the session is deemed "untrusted", and the proxy
   also places a Session Untrusted option in the Authentication Reply:

Olteanu & Niculescu    Expires September 12, 2019              [Page 25]
Internet-Draft                   SOCKS 6                      March 2019

   +------+--------+------+
   | Kind | Length | Type |
   +------+--------+------+
   |  1   |   2    |  1   |
   +------+--------+------+

                    Figure 21: Session Untrusted Option

   o  Kind: 0x04 (Session option)

   o  Length: 5

   o  Type: 0x06 (Session Untrusted)

   The SOCKS Request that initiated the session is considered part of
   the session.  A client MUST NOT attempt to initiate a session from
   within a different session.

   If the proxy can not or will not honor the Session Request, it does
   so silently.

8.4.2.  Further SOCKS Requests

   Any further SOCKS Requests that are part of the session MUST include
   a Session ID Option (as seen in Figure 20).

   The authentication procedure is altered based on the Session ID's
   validity and whether or not the Session is untrusted.

   For valid Session IDs:

   o  If the session is untrusted, the proxy MUST reject clients that do
      not authenticate using the same method and credentials that were
      used to initiate the session.

   o  Otherwise, the proxy MUST ignore any authentication attempt in the
      Request, and MUST NOT require any authentication.

   The proxy then replies by placing a Session OK option in the
   successful Authentication Reply:

Olteanu & Niculescu    Expires September 12, 2019              [Page 26]
Internet-Draft                   SOCKS 6                      March 2019

   +------+--------+------+
   | Kind | Length | Type |
   +------+--------+------+
   |  1   |   2    |  1   |
   +------+--------+------+

                       Figure 22: Session OK Option

   o  Kind: 0x04 (Session option)

   o  Length: 5

   o  Type: 0x04 (Session OK)

   If the ticket is invalid, the first Authentication Reply MUST signal
   that authentication failed and can not continue (by setting the Type
   field to 0x01 and the Method field to 0xff).  Further, it SHALL
   contain a Session Invalid option:

   +------+--------+------+
   | Kind | Length | Type |
   +------+--------+------+
   |  1   |   2    |  1   |
   +------+--------+------+

                     Figure 23: Session Invalid Option

   o  Kind: 0x04 (Session option)

   o  Length: 5

   o  Type: 0x05 (Session Invalid)

8.4.3.  Tearing down the session

   Proxies can, at their discretion, tear down a session and free all
   associated state.  Proxy implementations SHOULD feature a timeout
   mechanism that destroys sessions after a period of inactivity.

   Clients can signal that a session is no longer needed, and can be
   torn down, by sending a Session Teardown option in addition to the
   Session ID option:

Olteanu & Niculescu    Expires September 12, 2019              [Page 27]
Internet-Draft                   SOCKS 6                      March 2019

   +------+--------+------+
   | Kind | Length | Type |
   +------+--------+------+
   |  1   |   2    |  1   |
   +------+--------+------+

                    Figure 24: Session Teardown Option

   o  Kind: 0x04 (Session option)

   o  Length: 4

   o  Type: 0x02 (Session Teardown)

   After sending such an option, the client MUST assume that the session
   is no longer valid.

8.5.  Idempotence options

   To protect against duplicate SOCKS Requests, clients can request, and
   then spend, idempotence tokens.  A token can only be spent on a
   single SOCKS request.

   Tokens are 4-byte unsigned integers in a modular 4-byte space.
   Therefore, if x and y are tokens, x is less than y if 0 < (y - x) <
   2^31 in unsigned 32-bit arithmetic.

   Proxies grant contiguous ranges of tokens called token windows.
   Token windows are defined by their base (the first token in the
   range) and size.  Windows can be shifted (i. e. have their base
   increased, while retaining their size) unilaterally by the proxy.

   Requesting and spending tokens is done via Idempotence options:

   +------+--------+------+-------------+
   | Kind | Length | Type | Option Data |
   +------+--------+------+-------------+
   |  1   |   2    |  1   |   Variable  |
   +------+--------+------+-------------+

                       Figure 25: Idempotence Option

   o  Kind: 0x05 (Idempotence option)

   o  Length: The length of the option.

Olteanu & Niculescu    Expires September 12, 2019              [Page 28]
Internet-Draft                   SOCKS 6                      March 2019

   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.

   Idempotence options are only valid in the context of a SOCKS Session.
   If a SOCKS Request is not part of a Session (either by supplying a
   valid Session ID or successfully initiating one via a Session
   Request), the proxy MUST silently ignore any Idempotence options.

   Token windows are tracked by the proxy on a per-session basis.  There
   can be at most one token window for every session and its tokens can
   only be spent from within said session.

   Client and proxy implementations MUST either support all Idempotence
   Option Types, or none.

8.5.1.  Requesting a fresh token window

   A client can obtain a fresh window of tokens by sending a Token
   Request option as part of a SOCKS Request:

   +------+--------+------+-------------+
   | Kind | Length | Type | Window Size |
   +------+--------+------+-------------+
   |  1   |   2    |  1   |      4      |
   +------+--------+------+-------------+

                         Figure 26: Token Request

   o  Kind: MUST be allocated by IANA.  (See Section 13.)

   o  Length: 7

   o  Type: 0x00 (Token Request)

   o  Window Size: The requested window size.

Olteanu & Niculescu    Expires September 12, 2019              [Page 29]
Internet-Draft                   SOCKS 6                      March 2019

   If a token window is issued, the proxy then includes a Token Window
   Advertisement option in the corresponding successful Authentication
   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

   o  Type: 0x01 (Token Grant)

   o  Window Base: The first token in the window.

   o  Window Size: The window size.  This value SHOULD be lower or equal
      to the requested window size.  Window sizes MUST be less than
      2^31.  Window sizes MUST NOT be 0.

   If no token window is issued, the proxy MUST silently ignore the
   Token Request.

8.5.2.  Spending a token

   The client can attempt to spend a token by including a Token
   Expenditure option in its SOCKS request:

   +------+--------+------+-------+
   | Kind | Length | Type | Token |
   +------+--------+------+-------+
   |  1   |   2    |  1   |   4   |
   +------+--------+------+-------+

                       Figure 28: Token Expenditure

   o  Kind: 0x05 (Idempotence option)

   o  Length: 7

   o  Type: 0x02 (Token Expenditure)

Olteanu & Niculescu    Expires September 12, 2019              [Page 30]
Internet-Draft                   SOCKS 6                      March 2019

   o  Token: The token being spent.

   Clients SHOULD prioritize spending the smaller tokens.

   The proxy responds by sending a Token Expenditure Reply option as
   part of the successful Authentication Reply:

   +------+--------+------+---------------+
   | Kind | Length | Type | Response Code |
   +------+--------+------+---------------+
   |  1   |   2    |  1   |       1       |
   +------+--------+------+---------------+

                   Figure 29: Token Expenditure Response

   o  Kind: 0x05 (Idempotence option)

   o  Length: 4

   o  Type: 0x03 (Token Expenditure Response)

   o  Response Code:

      *  0x01: Success: The token was spent successfully.

      *  0x02: No Window: The proxy does not have a token window
         associated with the client.

      *  0x03: Out of Window: The token is not within the window.

      *  0x04: Duplicate: The token has already been spent.

   If eligible, the token is spent before attempting to honor the
   Request.  If the token is not eligible for spending, the proxy MUST
   NOT attempt to honor the client's Request; further, it MUST indicate
   a General SOCKS server failure in the Operation Reply.

   Proxy implementations SHOULD also send a Token Window Advertisement
   if:

   o  the token is out of window, or

   o  by the proxy's internal logic, successfully spending the token
      caused the window to shift.

   Proxy implementations SHOULD NOT shift the window's base beyond the
   highest unspent token.

Olteanu & Niculescu    Expires September 12, 2019              [Page 31]
Internet-Draft                   SOCKS 6                      March 2019

   Proxy implementations MAY include a Token Window Advertisement in any
   Authentication Reply that indicates success.

8.5.3.  Handling Token Window Advertisements

   Even though the proxy increases the window's base monotonically,
   there is no mechanism whereby a SOCKS client can receive the Token
   Window Advertisements in order.  As such, clients SHOULD disregard
   unsolicited Token Window Advertisements with a Window Base less than
   the previously known value.

9.  Username/Password Authentication

   Username/Password authentication is carried out as in [RFC1929].

   Clients can also attempt to authenticate by placing the Username/
   Password request in an Authentication Data Option.

   +------+--------+--------+---------------------------+
   | Kind | Length | Method | Username/Password request |
   +------+--------+--------+---------------------------+
   |  1   |   2    |   1    |          Variable         |
   +------+--------+--------+---------------------------+

           Figure 30: Password authentication via a SOCKS Option

   o  Kind: 0x03 (Authentication Data option)

   o  Length: The length of the option.

   o  Method: 0x02 (Username/Password).

   o  Username/Password request: The Username/Password request, as
      described in [RFC1929].

10.  TCP Fast Open on the Client-Proxy Leg

   TFO breaks TCP semantics, causing replays of the data in the SYN's
   payload under certain rare circumstances [RFC7413].  A replayed SOCKS
   Request could itself result in a replayed connection on behalf of the
   client.

   As such, client implementations SHOULD NOT use TFO on the client-
   proxy leg unless:

   o  The protocol running on top of SOCKS tolerates the risks of TFO,
      or

Olteanu & Niculescu    Expires September 12, 2019              [Page 32]
Internet-Draft                   SOCKS 6                      March 2019

   o  The SYN's payload does not contain any application data (so that
      no data is replayed to the server, even though duplicate
      connections are still possible), or

   o  The client uses Idempotence Options, making replays very unlikely,
      or

   o  SOCKS is running on top of TLS and Early Data is not used.

11.  False Starts

   In case of CONNECT Requests, the client MAY start sending application
   data as soon as possible, as long as doing so does not incur the risk
   of breaking the SOCKS protocol.

   Clients must work around the authentication phase by doing any of the
   following:

   o  If the Request does not contain an Authentication Method option,
      the authentication phase is guaranteed not to happen.  In this
      case, application data MAY be sent immediately after the Request.

   o  Application data MAY be sent immediately after receiving an
      Authentication Reply indicating success.

   o  When performing a method-specific authentication sequence,
      application data MAY be sent immediately after the last client
      message.

12.  Security Considerations

12.1.  Large requests

   Given the format of the request message, a malicious client could
   craft a request that is in excess of 16 KB and proxies could be prone
   to DDoS attacks.

   To mitigate such attacks, proxy implementations SHOULD be able to
   incrementally parse the requests.  Proxies MAY close the connection
   to the client if:

   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.

Olteanu & Niculescu    Expires September 12, 2019              [Page 33]
Internet-Draft                   SOCKS 6                      March 2019

12.2.  Replay attacks

   In TLS 1.3, early data (which is likely to contain a full SOCKS
   request) is prone to replay attacks.

   While Token Expenditure options can be used to mitigate replay
   attacks, the initial Token Request is still vulnerable.  As such,
   client implementations SHOULD NOT make use of TLS early data unless
   the Request attempts to spend a token.

12.3.  Resource exhaustion

   Malicious clients can issue a large number of Session Requests,
   forcing the proxy to keep large amounts of state.

   To mitigate this, the proxy MAY implement policies restricting the
   number of concurrent sessions on a per-IP or per-user basis, or
   barring unauthenticated clients from establishing sessions.

13.  IANA Considerations

   This document requests that IANA allocate 1-byte option kinds for
   SOCKS 6 options.  Further, this document requests the following
   option kinds:

   o  Stack options: 0x01

   o  Authentication Method options: 0x02

   o  Authentication Data options: 0x03

   o  Session options: 0x04

   o  Idempotence options: 0x05

   o  A range for vendor-specific options: 0xE0-0xFF

   This document also requests that IANA allocate a TCP and UDP port for
   SOCKS over TLS and DTLS, respectively.

14.  Acknowledgements

   The protocol described in this draft builds upon and is a direct
   continuation of SOCKS 5 [RFC1928].

Olteanu & Niculescu    Expires September 12, 2019              [Page 34]
Internet-Draft                   SOCKS 6                      March 2019

15.  References

15.1.  Normative References

   [RFC1929]  Leech, M., "Username/Password Authentication for SOCKS
              V5", RFC 1929, DOI 10.17487/RFC1929, March 1996,
              <https://www.rfc-editor.org/info/rfc1929>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

15.2.  Informative References

   [I-D.ietf-tls-dtls-connection-id]
              Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
              Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
              id-04 (work in progress), March 2019.

   [RFC1928]  Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
              L. Jones, "SOCKS Protocol Version 5", RFC 1928,
              DOI 10.17487/RFC1928, March 1996,
              <https://www.rfc-editor.org/info/rfc1928>.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
              <https://www.rfc-editor.org/info/rfc6824>.

   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
              <https://www.rfc-editor.org/info/rfc7413>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Authors' Addresses

   Vladimir Olteanu
   University Politehnica of Bucharest

   Email: vladimir.olteanu@cs.pub.ro

Olteanu & Niculescu    Expires September 12, 2019              [Page 35]
Internet-Draft                   SOCKS 6                      March 2019

   Dragos Niculescu
   University Politehnica of Bucharest

   Email: dragos.niculescu@cs.pub.ro

Olteanu & Niculescu    Expires September 12, 2019              [Page 36]