idnits 2.17.1 draft-olteanu-intarea-socks-6-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1866 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-04 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area Working Group V. Olteanu 3 Internet-Draft D. Niculescu 4 Intended status: Experimental University Politehnica of Bucharest 5 Expires: September 12, 2019 March 11, 2019 7 SOCKS Protocol Version 6 8 draft-olteanu-intarea-socks-6-06 10 Abstract 12 The SOCKS protocol is used primarily to proxy TCP connections to 13 arbitrary destinations via the use of a proxy server. Under the 14 latest version of the protocol (version 5), it takes 2 RTTs (or 3, if 15 authentication is used) before data can flow between the client and 16 the server. 18 This memo proposes SOCKS version 6, which reduces the number of RTTs 19 used, takes full advantage of TCP Fast Open, and adds support for 20 0-RTT authentication. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 12, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Revision log . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Requirements language . . . . . . . . . . . . . . . . . . . . 8 59 3. Mode of operation . . . . . . . . . . . . . . . . . . . . . . 8 60 4. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 5. Version Mismatch Replies . . . . . . . . . . . . . . . . . . 12 62 6. Authentication Replies . . . . . . . . . . . . . . . . . . . 12 63 7. Operation Replies . . . . . . . . . . . . . . . . . . . . . . 13 64 7.1. Handling CONNECT . . . . . . . . . . . . . . . . . . . . 14 65 7.2. Handling BIND . . . . . . . . . . . . . . . . . . . . . . 15 66 7.3. Handling UDP ASSOCIATE . . . . . . . . . . . . . . . . . 15 67 7.3.1. Proxying UDP servers . . . . . . . . . . . . . . . . 17 68 8. SOCKS Options . . . . . . . . . . . . . . . . . . . . . . . . 17 69 8.1. Stack options . . . . . . . . . . . . . . . . . . . . . . 17 70 8.1.1. IP TOS options . . . . . . . . . . . . . . . . . . . 19 71 8.1.2. TFO options . . . . . . . . . . . . . . . . . . . . . 19 72 8.1.3. Multipath TCP options . . . . . . . . . . . . . . . . 20 73 8.1.4. MPTCP Scheduler options . . . . . . . . . . . . . . . 20 74 8.1.5. Listen Backlog options . . . . . . . . . . . . . . . 21 75 8.2. Authentication Method options . . . . . . . . . . . . . . 22 76 8.3. Authentication Data options . . . . . . . . . . . . . . . 23 77 8.4. Session options . . . . . . . . . . . . . . . . . . . . . 24 78 8.4.1. Session initiation . . . . . . . . . . . . . . . . . 24 79 8.4.2. Further SOCKS Requests . . . . . . . . . . . . . . . 26 80 8.4.3. Tearing down the session . . . . . . . . . . . . . . 27 81 8.5. Idempotence options . . . . . . . . . . . . . . . . . . . 28 82 8.5.1. Requesting a fresh token window . . . . . . . . . . . 29 83 8.5.2. Spending a token . . . . . . . . . . . . . . . . . . 30 84 8.5.3. Handling Token Window Advertisements . . . . . . . . 32 85 9. Username/Password Authentication . . . . . . . . . . . . . . 32 86 10. TCP Fast Open on the Client-Proxy Leg . . . . . . . . . . . . 32 87 11. False Starts . . . . . . . . . . . . . . . . . . . . . . . . 33 88 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 89 12.1. Large requests . . . . . . . . . . . . . . . . . . . . . 33 90 12.2. Replay attacks . . . . . . . . . . . . . . . . . . . . . 34 91 12.3. Resource exhaustion . . . . . . . . . . . . . . . . . . 34 92 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 93 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 94 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 95 15.1. Normative References . . . . . . . . . . . . . . . . . . 35 96 15.2. Informative References . . . . . . . . . . . . . . . . . 35 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 100 1. Introduction 102 Versions 4 and 5 [RFC1928] of the SOCKS protocol were developed two 103 decades ago and are in widespread use for circuit level gateways or 104 as circumvention tools, and enjoy wide support and usage from various 105 software, such as web browsers, SSH clients, and proxifiers. 106 However, their design needs an update in order to take advantage of 107 the new features of transport protocols, such as TCP Fast Open 108 [RFC7413], or to better assist newer transport protocols, such as 109 MPTCP [RFC6824]. 111 One of the main issues faced by SOCKS version 5 is that, when taking 112 into account the TCP handshake, method negotiation, authentication, 113 connection request and grant, it may take up to 5 RTTs for a data 114 exchange to take place at the application layer. This is especially 115 costly in networks with a large delay at the access layer, such as 116 3G, 4G, or satelite. 118 The desire to reduce the number of RTTs manifests itself in the 119 design of newer security protocols. TLS version 1.3 [RFC8446] 120 defines a zero round trip (0-RTT) handshake mode for connections if 121 the client and server had previously communicated. 123 TCP Fast Open [RFC7413] is a TCP option that allows TCP to send data 124 in the SYN and receive a response in the first ACK, and aims at 125 obtaining a data response in one RTT. The SOCKS protocol needs to 126 concern itself with at least two TFO deployment scenarios: First, 127 when TFO is available end-to-end (at the client, at the proxy, and at 128 the server); second, when TFO is active between the client and the 129 proxy, but not at the server. 131 This document describes the SOCKS protocol version 6. The key 132 improvements over SOCKS version 5 are: 134 o The client sends as much information upfront as possible, and does 135 not wait for the authentication process to conclude before 136 requesting the creation of a socket. 138 o The connection request also mimics the semantics of TCP Fast Open 139 [RFC7413]. As part of the connection request, the client can 140 supply the potential payload for the initial SYN that is sent out 141 to the server. 143 o The protocol can be extended via options without breaking 144 backward-compatibility. 146 o The protocol can leverage the aforementioned options to support 147 0-RTT authentication schemes. 149 1.1. Revision log 151 Typos and minor clarifications are not listed. 153 draft-06 155 o Session options 157 o Options now have a 2-byte length field. 159 o Stack options 161 * Stack options can no longer contain duplicate information. 163 * TFO: Better payload size semantics 165 * TOS: Added missing code field. 167 * MPTCP Scheduler options: 169 + Removed support for round-robin 171 + "Default" renamed to "Lowest latency first" 173 * Listen Backlog options: now tied to sessions, instead of an 174 authenticated user 176 o Idempotence options 178 * Now used in the context of a session (no longer tied to an 179 authenticated user) 181 * Idempotence options have a different codepoint: 0x05. (Was 182 0x04.) 184 * Clarified that implementations that support Idempotence Options 185 must support all Idempotence Option Types. 187 * Shifted Idempotence Option Types by 1. (Makes implementation 188 easier.) 190 o Shrunk vendor-specific option range to 32 (down from 64). 192 o Removed reference to dropping initial data. (It could no longer 193 be done as of -05.) 195 o Initial data size capped at 16KB. 197 o Application data is never encrypted by SOCKS 6. (It can still be 198 encrypted by the TLS layer under SOCKS.) 200 o Messages now carry the total length of the options, rather than 201 the number of options. Limited options length to 16KB. 203 o Security Considerations 205 * Updated the section to reflect the smaller maximum message 206 size. 208 * Added a subsection on resource exhaustion. 210 draft-05 212 o Limited the "slow" authentication negociations to one (and 213 Authentication Replies to 2) 215 o Revamped the handling of the first bytes in the application data 216 stream 218 * False starts are now recommended. (Added the "False Start" 219 section.) 221 * Initial data is only available to clients willing to do "slow" 222 authentication. Moved the "Initial data size" field from 223 Requests to Authentication Method options. 225 * Initial data size capped at 2^13. Initial data can no longer 226 be dropped by the proxy. 228 * The TFO option can hint at the desired SYN payload size. 230 o Request: clarified the meaning of the Address and Port fields. 232 o Better reverse TCP proxy support: optional listen backlog for TCP 233 BIND 235 o TFO options can no longer be placed inside Operation Replies. 237 o IP TOS stack option 239 o Suggested a range for vendor-specific options. 241 o Revamped UDP functionality 242 * Now using fixed UDP ports 244 * DTLS support 246 o Stack options: renamed Proxy-Server leg to Proxy-Remote leg 248 draft-04 250 o Moved Token Expenditure Replies to the Authentication Reply. 252 o Shifted the Initial Data Size field in the Request, in order to 253 make it easier to parse. 255 draft-03 257 o Shifted some fields in the Operation Reply to make it easier to 258 parse. 260 o Added connection attempt timeout response code to Operation 261 Replies. 263 o Proxies send an additional Authentication Reply after the 264 authentication phase. (Useful for token window advertisements.) 266 o Renamed the section "Connection Requests" to "Requests" 268 o Clarified the fact that proxies don't need to support any command 269 in particular. 271 o Added the section "TCP Fast Open on the Client-Proxy Leg" 273 o Options: 275 * Added constants for option kinds 277 * Salt options removed, along with the relevant section from 278 Security Considerations. (TLS 1.3 Makes AEAD mandatory.) 280 * Limited Authentication Data options to one per method. 282 * Relaxed proxy requirements with regard to handling multiple 283 Authentication Data options. (When the client violates the 284 above bullet point.) 286 * Removed interdependence between Authentication Method and 287 Authentication Data options. 289 * Clients SHOULD omit advertising the "No authentication 290 required" option. (Was MAY.) 292 * Idempotence options: 294 + Token Window Advertisements are now part of successful 295 Authentication Replies (so that the proxy-server RTT has no 296 impact on their timeliness). 298 + Proxies can't advetise token windows of size 0. 300 + Tweaked token expenditure response codes. 302 + Support no longer mandatory on the proxy side. 304 * Revamped Socket options 306 + Renamed Socket options to Stack options. 308 + Banned contradictory socket options. 310 + Added socket level for generic IP. Removed the "socket" 311 socket level. 313 + Stack options no longer use option codes from setsockopt(). 315 + Changed MPTCP Scheduler constants. 317 draft-02 319 o Made support for Idempotence options mandatory for proxies. 321 o Clarified what happens when proxies can not or will not issue 322 tokens. 324 o Limited token windows to 2^31 - 1. 326 o Fixed definition of "less than" for tokens. 328 o NOOP commands now trigger Operation Replies. 330 o Renamed Authentication options to Authentication Data options. 332 o Authentication Data options are no longer mandatory. 334 o Authentication methods are now advertised via options. 336 o Shifted some Request fields. 338 o Option range for vendor-specific options. 340 o Socket options. 342 o Password authentication. 344 o Salt options. 346 draft-01 348 o Added this section. 350 o Support for idempotent commands. 352 o Removed version numbers from operation replies. 354 o Request port number for SOCKS over TLS. Deprecate encryption/ 355 encapsulation within SOCKS. 357 o Added Version Mismatch Replies. 359 o Renamed the AUTH command to NOOP. 361 o Shifted some fields to make requests and operation replies easier 362 to parse. 364 2. Requirements language 366 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 367 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 368 document are to be interpreted as described in [RFC2119]. 370 3. Mode of operation 371 CLIENT PROXY 373 +------------------------+ 374 | Authentication methods | Request 375 --------> Command code +------------------------------> 376 | Address | 377 | Port | 378 | Options | 379 +------------------------+ 381 +------------------------+ 382 --------> Initial data +------------------------------> 383 +------------------------+ 385 +-----------------------+ 386 Authentication Reply | Type | 387 <----------------------------------+ Method <----- 388 | Options | 389 +-----------------------+ 391 <-------------------(Authentication protocol)------------------> 393 +-----------------------+ 394 Authentication Reply | Type = Success | 395 <----------------------------------+ Method <----- 396 | Options | 397 +-----------------------+ 399 +-----------------------+ 400 Operation Reply | Reply code | 401 <--------------------+ Bind address <------------------ 402 | Bind port | 403 | Options | 404 +-----------------------+ 406 Figure 1: The SOCKS version 6 protocol message exchange 408 When a TCP-based client wishes to establish a connection to a server, 409 it must open a TCP connection to the appropriate SOCKS port on the 410 SOCKS proxy. The client then enters a negotiation phase, by sending 411 the request in Figure 1, that contains, in addition to fields present 412 in SOCKS 5 [RFC1928], fields that facilitate low RTT usage and faster 413 authentication negotiation. 415 Next, the server sends an authentication reply. If the request did 416 not contain the necessary authentication information, the proxy 417 indicates an authentication method that must proceed. This may 418 trigger a longer authentication sequence that could include tokens 419 for ulterior faster authentications. The part labeled 420 "Authentication protocol" is specific to the authentication method 421 employed and is not expected to be employed for every connection 422 between a client and its proxy server. The authentication protocol 423 typically takes up 1 RTT or more. 425 If the authentication is successful, an operation reply is generated 426 by the proxy. It indicates whether the proxy was successful in 427 creating the requested socket or not. 429 In the fast case, when authentication is properly set up, the proxy 430 attempts to create the socket immediately after the receipt of the 431 request, thus achieving an operational conection in one RTT (provided 432 TFO functionality is available at the client, proxy, and server). 434 4. Requests 436 The client starts by sending a request to the proxy. 438 +---------------+---------+------+---------+----------+ 439 | Version | Command | Port | Address | Address | 440 | Major | Minor | Code | | Type | | 441 +-------+-------+---------+------+---------+----------+ 442 | 1 | 1 | 1 | 2 | 1 | Variable | 443 +-------+-------+---------+------+---------+----------+ 444 +---------+----------+ 445 | Options | Options | 446 | Length | | 447 +---------+----------+ 448 | 2 | Variable | 449 +---------+----------+ 451 Figure 2: SOCKS 6 Request 453 o Version: The major byte is 0x06, and the minor byte is 0x00. 455 o Command Code: 457 * 0x00 NOOP: does nothing. 459 * 0x01 CONNECT: requests the establishment of a TCP connection. 460 TFO MUST NOT be used unless explicitly requested. 462 * 0x02 BIND: requests the establishment of a TCP port binding. 464 * 0x03 UDP ASSOCIATE: requests a UDP port association. 466 o Address Type: 468 * 0x01: IPv4 470 * 0x03: Domain Name 472 * 0x04: IPv6 474 o Address: this field's format depends on the address type: 476 * IPv4: a 4-byte IPv4 address 478 * Domain Name: one byte that contains the length of the FQDN, 479 followed by the FQDN itself. The string is not NUL-terminated. 481 * IPv6: a 16-byte IPv6 address 483 o Port: the port in network byte order. 485 o Options Length: the total size of the SOCKS options that appear in 486 the Options field. MUST NOT exceed 16KB. 488 o Options: see Section 8. 490 The Address and Port fields have different meanings based on the 491 Command Code: 493 o NOOP: The fields have no meaning. The Address Type field MUST be 494 either 0x01 (IPv4) or 0x04 (IPv6). The Address and Port fields 495 MUST be 0. 497 o CONNECT: The fields signify the address and port to which the 498 client wishes to connect. 500 o BIND, UDP ASSOCIATE: The fields indicate the desired bind address 501 and port. If the client does not require a certain address, it 502 can set the Address Type field to 0x01 (IPv4) or 0x04 (IPv6), and 503 the Address field to 0. Likewise, if the client does not require 504 a certain port, it can set the Port field to 0. 506 Clients can advertise their supported authentication methods by 507 including an Authentication Method option (see Section 8.2). 509 5. Version Mismatch Replies 511 Upon receipt of a request starting with a version number other than 512 6.0, the proxy sends the following response: 514 +---------------+ 515 | Version | 516 | Major | Minor | 517 +-------+-------+ 518 | 1 | 1 | 519 +-------+-------+ 521 Figure 3: SOCKS 6 Version Mismatch Reply 523 o Version: The major byte is 0x06, and the minor byte is 0x00. 525 A client MUST close the connection after receiving such a reply. 527 6. Authentication Replies 529 Upon receipt of a valid request, the proxy sends an Authentication 530 Reply: 532 +---------------+------+--------+---------+----------+ 533 | Version | Type | Method | Options | Options | 534 | Major | Minor | | | Length | | 535 +-------+-------+------+--------+---------+----------+ 536 | 1 | 1 | 1 | 1 | 2 | Variable | 537 +-------+-------+------+--------+---------+----------+ 539 Figure 4: SOCKS 6 Authentication Reply 541 o Version: The major byte is 0x06, and the minor byte is 0x00. 543 o Type: 545 * 0x00: authentication successful. 547 * 0x01: further authentication needed. 549 o Method: The chosen authentication method. 551 o Options Length: the total size of the SOCKS options that appear in 552 the Options field. MUST NOT exceed 16KB. 554 o Options: see Section 8. 556 Multihomed clients SHOULD cache the chosen method on a per-interface 557 basis and SHOULD NOT include Authentication Data options related to 558 any other methods in further requests originating from the same 559 interface. 561 If the server signals that further authentication is needed and 562 selects "No Acceptable Methods", the client MUST close the 563 connection. 565 The client and proxy begin a method-specific negotiation. During 566 such negotiations, the proxy MAY supply information that allows the 567 client to authenticate a future request using an Authentication Data 568 option. Application data is not subject to any encryption negotiated 569 during this phase. Descriptions of such negotiations are beyond the 570 scope of this memo. 572 When the negotiation is complete (either successfully or 573 unsuccessfully), the proxy sends a second Authentication Reply. The 574 second Authentication Reply MUST either signal success or that there 575 are no more acceptable authentication methods. 577 7. Operation Replies 579 After the authentication negotiations are complete, the proxy sends 580 an Operation Reply: 582 +-------+------+---------+----------+---------+----------+ 583 | Reply | Bind | Address | Bind | Options | Options | 584 | Code | Port | Type | Address | Length | | 585 +-------+------+---------+----------+---------+----------+ 586 | 1 | 2 | 1 | Variable | 2 | Variable | 587 +-------+------+---------+----------+---------+----------+ 589 Figure 5: SOCKS 6 Operation Reply 591 o Reply Code: 593 * 0x00: Succes 595 * 0x01: General SOCKS server failure 597 * 0x02: Connection not allowed by ruleset 599 * 0x03: Network unreachable 601 * 0x04: Host unreachable 602 * 0x05: Connection refused 604 * 0x06: TTL expired 606 * 0x07: Command not supported 608 * 0x08: Address type not supported 610 * 0x09: Connection attempt timed out 612 o Bind Port: the proxy bound port in network byte order. 614 o Address Type: 616 * 0x01: IPv4 618 * 0x03: Domain Name 620 * 0x04: IPv6 622 o Bind Address: the proxy bound address in the following format: 624 * IPv4: a 4-byte IPv4 address 626 * Domain Name: one byte that contains the length of the FQDN, 627 followed by the FQDN itself. The string is not NUL-terminated. 629 * IPv6: a 16-byte IPv6 address 631 o Options Length: the total size of the SOCKS options that appear in 632 the Options field. MUST NOT exceed 16KB. 634 o Options: see Section 8. 636 Proxy implementations MAY support any subset of the client commands 637 listed in Section 4. 639 If the proxy returns a reply code other than "Success", the client 640 MUST close the connection. 642 If the client issued an NOOP command, the client MUST close the 643 connection after receiving the Operation Reply. 645 7.1. Handling CONNECT 647 In case the client has issued a CONNECT request, data can now pass. 649 7.2. Handling BIND 651 In case the client has issued a BIND request, it must wait for a 652 second Operation reply from the proxy, which signifies that a host 653 has connected to the bound port. The Bind Address and Bind Port 654 fields contain the address and port of the connecting host. 655 Afterwards, application data may pass. 657 7.3. Handling UDP ASSOCIATE 659 Proxies offering UDP functionality must be configured with a UDP port 660 used for relaying UDP datagrams to and from the client, and/or a port 661 used for relaying datagrams over DTLS. 663 Following a successful Operation Reply, the proxy sends a UDP 664 Association Initialization message: 666 +----------------+ 667 | Association ID | 668 +----------------+ 669 | 4 | 670 +----------------+ 672 Figure 6: UDP Association Initialization 674 o Association ID: the identifier of the UDP association 676 Proxy implementations SHOULD generate Association IDs randomly or 677 pseudo-randomly. 679 Clients may start sending UDP datagrams to the proxy either in 680 plaintext, or over an established DTLS session, using the proxy's 681 configured UDP ports. A client's datagrams are prefixed by a SOCKS 682 Datagram Header, indicating the remote host's address and port: 684 +---------------+-------------+------+---------+----------+ 685 | Version | Association | Port | Address | Address | 686 | Major | Minor | ID | | Type | | 687 +-------+-------+-------------+------+---------+----------+ 688 | 1 | 1 | 4 | 2 | 1 | Variable | 689 +-------+-------+-------------+------+---------+----------+ 691 Figure 7: SOCKS 6 Datagram Header 693 o Version: The major byte is 0x06, and the minor byte is 0x00. 695 o Association ID: the identifier of the UDP association 697 o Address Type: 699 * 0x01: IPv4 701 * 0x03: Domain Name 703 * 0x04: IPv6 705 o Address: this field's format depends on the address type: 707 * IPv4: a 4-byte IPv4 address 709 * Domain Name: one byte that contains the length of the FQDN, 710 followed by the FQDN itself. The string is not NUL-terminated. 712 * IPv6: a 16-byte IPv6 address 714 o Port: the port in network byte order. 716 Following the receipt of the first datagram from the client, the 717 proxy makes a one-way mapping between the Association ID and: 719 o the 5-tuple of the UDP conversation, if the datagram was received 720 over plain UDP, or 722 o the DTLS connection, if the datagram was received over DTLS. The 723 DTLS connection is identified either by its 5-tuple, or some other 724 mechanism, like [I-D.ietf-tls-dtls-connection-id]. 726 Further datagrams carrying the same Association ID, but not matching 727 the established mapping, are silently dropped. 729 The proxy then sends an UDP Association Confirmation message over the 730 TCP connection with the client: 732 +--------+ 733 | Status | 734 +--------+ 735 | 1 | 736 +--------+ 738 Figure 8: UDP Association Confirmation 740 o Status: MUST be 0x00 741 Following the confirmation message, UDP packets bound for the proxy's 742 bind address and port are relayed to the client, also prefixed by a 743 Datagram Header. 745 The UDP association remains active for as long as the TCP connection 746 between the client and the proxy is kept open. 748 7.3.1. Proxying UDP servers 750 Under some circumstances (e.g. when hosting a server), the SOCKS 751 client expects the remote host to send UDP datagrams first. As such, 752 the SOCKS client must trigger a UDP Association Confirmation without 753 having the proxy relay any datagrams on its behalf. 755 To that end, it sends an empty datagram prefixed by a Datagram Header 756 with an IP address and port consisting of zeroes. The client SHOULD 757 resend the empty datagram if an UDP Association Confirmation is not 758 received after a timeout. 760 8. SOCKS Options 762 SOCKS options have the following format: 764 +------+--------+-------------+ 765 | Kind | Length | Option Data | 766 +------+--------+-------------+ 767 | 1 | 2 | Variable | 768 +------+--------+-------------+ 770 Figure 9: SOCKS 6 Option 772 o Kind: Allocated by IANA. (See Section 13.) 774 o Length: The total length of the option. 776 o Option Data: The contents are specific to each option kind. 778 Unless otherwise noted, client and proxy implementations MAY omit 779 supporting any of the options described in this document. Upon 780 encountering an unsupported option, a SOCKS endpoint MUST silently 781 ignore it. 783 8.1. Stack options 785 Stack options can be used by clients to alter the behavior of the 786 protocols on top of which SOCKS is running, as well the protcols used 787 by the proxy to communicate with the remote host (i.e. IP, TCP, 788 UDP). A Stack option can affect either the proxy's protocol on the 789 client-proxy leg or on the proxy-remote leg. Clients can only place 790 Stack options inside SOCKS Requests. 792 Proxies MAY include Stack options in their Operation Replies to 793 signal their behavior. Said options MAY be unsolicited, i. e. the 794 proxy MAY send them to signal behaviour that was not explicitly 795 requested by the client. 797 In case of UDP ASSOCIATE, the stack options refer to the UDP traffic 798 relayed by the proxy. 800 Stack options that are part of the same message MUST NOT contradict 801 one another or contain duplicate information. 803 +------+--------+--------+--------+------+----------+ 804 | Kind | Length | Leg | Level | Code | Data | 805 +------+--------+--------+--------+------+----------+ 806 | 1 | 2 | 2 bits | 6 bits | 1 | Variable | 807 +------+--------+--------+--------+------+----------+ 809 Figure 10: Stack Option 811 o Kind: 0x01 (Stack option) 813 o Length: The length of the option. 815 o Leg: 817 * 0x1: Client-Proxy Leg 819 * 0x2: Proxy-Remote Leg 821 * 0x3: Both Legs 823 o Level: 825 * 0x01: IP: options that apply to either IPv4 or IPv6 827 * 0x02: IPv4 829 * 0x03: IPv6 831 * 0x04: TCP 833 * 0x05: UDP 835 o Code: Option code 837 o Data: Option-specific data 839 8.1.1. IP TOS options 841 +------+--------+--------+--------+------+-----+ 842 | Kind | Length | Leg | Level | Code | TOS | 843 +------+--------+--------+--------+------+-----+ 844 | 1 | 2 | 2 bits | 6 bits | 1 | 1 | 845 +------+--------+--------+--------+------+-----+ 847 Figure 11: IP TOS Option 849 o Kind: 0x01 (Stack option) 851 o Length: 4 853 o Leg: Either 0x01, 0x02, or 0x03 (Client-Proxy, Proxy-Remote or 854 Both legs) 856 o Level: 0x04 (TCP). 858 o Code: 0x01 860 o TOS: The IP TOS code 862 The client can use IP TOS options to request that the proxy use a 863 certain value for the IP TOS field. Likewise, the proxy can use IP 864 TOS options to advertise the TOS values being used. 866 8.1.2. TFO options 868 +------+--------+--------+--------+------+--------------+ 869 | Kind | Length | Leg | Level | Code | Payload Size | 870 +------+--------+--------+--------+------+--------------+ 871 | 1 | 2 | 2 bits | 6 bits | 1 | 2 | 872 +------+--------+--------+--------+------+--------------+ 874 Figure 12: TFO Option 876 o Kind: 0x01 (Stack option) 878 o Length: 4 880 o Leg: 0x02 (Proxy-Remote leg). 882 o Level: 0x04 (TCP). 884 o Code: 0x01 886 o Payload Size: The desired payload size of the TFO SYN. Ignored in 887 case of a BIND command. 889 If a SOCKS Request contains a TFO option, the proxy SHOULD attempt to 890 use TFO in case of a CONNECT command, or accept TFO in case of a BIND 891 command. Otherwise, the proxy MUST NOT attempt to use TFO in case of 892 a CONNECT command, or accept TFO in case of a BIND command. 894 In case of a CONNECT command, the client can indicate the desired 895 payload size of the SYN. If the field is 0, the proxy can use an 896 arbitrary payload size. If the field is non-zero, the proxy MUST NOT 897 use a payload size larger than the one indicated. The proxy MAY use 898 a smaller payload size than the one indicated. 900 8.1.3. Multipath TCP options 902 In case of a CONNECT command, the proxy can inform the client that 903 the connection to the server is an MPTCP connection. 905 +------+--------+--------+--------+------+ 906 | Kind | Length | Leg | Level | Code | 907 +------+--------+--------+--------+------+ 908 | 1 | 2 | 2 bits | 6 bits | 1 | 909 +------+--------+--------+--------+------+ 911 Figure 13: Multipath TCP Option 913 o Kind: 0x01 (Stack option) 915 o Length: 4 917 o Leg: 0x02 (Proxy-Remote leg) 919 o Level: 0x04 (TCP). 921 o Code: 0x02 923 8.1.4. MPTCP Scheduler options 925 In case of a CONNECT or BIND command, a client can use an MPTCP 926 Scheduler option to indicate its preferred scheduler for the 927 connection. 929 A proxy can use an MPTCP Scheduler option to inform the client about 930 what scheduler is in use. 932 +------+--------+--------+--------+------+-----------+ 933 | Kind | Length | Leg | Level | Code | Scheduler | 934 +------+--------+--------+--------+------+-----------+ 935 | 1 | 2 | 2 bits | 6 bits | 1 | 1 | 936 +------+--------+--------+--------+------+-----------+ 938 Figure 14: MPTCP Scheduler Option 940 o Kind: 0x01 (Stack option) 942 o Length: 5 944 o Leg: Either 0x01, 0x02, or 0x03 (Client-Proxy, Proxy-Remote or 945 Both legs). 947 o Level: 0x04 (TCP) 949 o Code: 0x03 951 o Scheduler: 953 * 0x01: Lowest latency first 955 * 0x02: Redundant 957 8.1.5. Listen Backlog options 959 +------+--------+--------+--------+---------+ 960 | Kind | Length | Leg | Level | Backlog | 961 +------+--------+--------+--------+---------+ 962 | 1 | 2 | 2 bits | 6 bits | 2 | 963 +------+--------+--------+--------+---------+ 965 Figure 15: Listen Backlog Option 967 o Kind: 0x01 (Stack option) 969 o Length: 5 971 o Leg: 0x02 (Proxy-Remote leg) 973 o Level: 0x04 (TCP) 974 o Code: 0x04 976 o Backlog: The length of the listen backlog. MUST be greater than 977 1. 979 The default behavior of the BIND does not allow a client to 980 simultaneously handle multiple connections to the same bind address. 981 A client can alter BIND's behavior by adding a TCP Listen Backlog 982 Option to a BIND Request, provided that the Request is part of a 983 Session. 985 In response, the proxy sends a TCP Listen Backlog Option as part of 986 the Operation Reply, with the Backlog field signalling the actual 987 backlog used. The proxy SHOULD NOT use a backlog longer than 988 requested. 990 Following the successful negotiation of a backlog, the proxy listens 991 for incoming connections for as long as the initial connection stays 992 open. The initial connection is not used to relay data between the 993 client and a remote host. 995 To accept connections, the client issues further BIND Requests using 996 the bind address and port supplied by the proxy in the initial 997 Operation Reply. Said BIND requests must belong to the same Session 998 as the original Request. 1000 If a proxy can not or will not honor a Listen Backlog option, it does 1001 so silently. 1003 8.2. Authentication Method options 1005 Authentication Method options are placed in SOCKS Requests to 1006 advertise supported authentication methods. In case of a CONNECT 1007 Request, they are also used to specify the amount of initial data 1008 supplied before any method-specific authentication negotiations take 1009 place. 1011 +------+--------+---------------------+----------+ 1012 | Kind | Length | Initial Data Length | Methods | 1013 +------+--------+---------------------+----------+ 1014 | 1 | 2 | 2 | Variable | 1015 +------+--------+---------------------+----------+ 1017 Figure 16: Authentication Method Option 1019 o Kind: 0x02 (Authentication Method option) 1020 o Length: The length of the option. 1022 o Initial Data Size: A two-byte number in network byte order. In 1023 case of CONNECT, this is the number of bytes of initial data that 1024 are supplied by the client immediately following the Request. 1025 This number MUST NOT be larger than 2^14. 1027 o Methods: One byte per advertised method. Method numbers are 1028 assigned by IANA. 1030 Clients MUST support the "No authentication required" method. 1031 Clients SHOULD omit advertising the "No authentication required" 1032 option. 1034 8.3. Authentication Data options 1036 Authentication Data options carry method-specific authentication 1037 data. They can be part of SOCKS Requests and Authentication Replies. 1039 Authentication Data options have the following format: 1041 +------+--------+--------+---------------------+ 1042 | Kind | Length | Method | Authentication Data | 1043 +------+--------+--------+---------------------+ 1044 | 1 | 2 | 1 | Variable | 1045 +------+--------+--------+---------------------+ 1047 Figure 17: Authentication Data Option 1049 o Kind: 0x03 (Authentication Data option) 1051 o Length: The length of the option. 1053 o Method: The number of the authentication method. These numbers 1054 are assigned by IANA. 1056 o Authentication Data: The contents are specific to each method. 1058 Clients SHOULD only place one Authentication Data option per 1059 authentication method. Server implementations MAY silently ignore 1060 all Authentication Data options for the same method aside from an 1061 arbitrarily chosen one. 1063 8.4. Session options 1065 Clients and proxies can establish SOCKS sessions, which span one or 1066 more Requests. All session-related negotiations are done via Session 1067 Options, which are placed in Requests and Authentication Replies by 1068 the client and, respectively, by the proxy. 1070 Session Options have the following format: 1072 +------+--------+------+---------------------+ 1073 | Kind | Length | Type | Session Option Data | 1074 +------+--------+------+---------------------+ 1075 | 1 | 2 | 1 | Variable | 1076 +------+--------+------+---------------------+ 1078 Figure 18: Session Option 1080 o Kind: 0x04 (Session option) 1082 o Length: The length of the option. 1084 o Type: 1086 * 0x01: Session Request 1088 * 0x02: Session ID 1090 * 0x02: Session Teardown 1092 * 0x04: Session OK 1094 * 0x05: Session Invalid 1096 * 0x06: Session Untrusted 1098 o Session Option Data: The contents are specific to each type. 1100 Client and proxy implementations MUST either support all Session 1101 Option Types, or none. 1103 8.4.1. Session initiation 1105 A client can initiate a session by sending a Session Request Option: 1107 +------+--------+------+ 1108 | Kind | Length | Type | 1109 +------+--------+------+ 1110 | 1 | 2 | 1 | 1111 +------+--------+------+ 1113 Figure 19: Session Request Option 1115 o Kind: 0x04 (Session option) 1117 o Length: 4 1119 o Type: 0x01 (Session Request) 1121 The proxy then replies with a Session ID Option in the successful 1122 Operation Reply: 1124 +------+--------+------+------------+ 1125 | Kind | Length | Type | Session ID | 1126 +------+--------+------+------------+ 1127 | 1 | 2 | 1 | Variable | 1128 +------+--------+------+------------+ 1130 Figure 20: Session ID Option 1132 o Kind: 0x04 (Session option) 1134 o Length: The length of the option. 1136 o Type: 0x02 (Session ID) 1138 o Session ID: An opaque sequence of bytes specific to the session. 1139 MUST be at least one byte in size. 1141 The Session ID serves to identify the session and is opaque to the 1142 client. 1144 The credentials, or lack thereof, used to initiate the session are 1145 tied to the session. If authentication is to be performed for 1146 further Requests, the session is deemed "untrusted", and the proxy 1147 also places a Session Untrusted option in the Authentication Reply: 1149 +------+--------+------+ 1150 | Kind | Length | Type | 1151 +------+--------+------+ 1152 | 1 | 2 | 1 | 1153 +------+--------+------+ 1155 Figure 21: Session Untrusted Option 1157 o Kind: 0x04 (Session option) 1159 o Length: 5 1161 o Type: 0x06 (Session Untrusted) 1163 The SOCKS Request that initiated the session is considered part of 1164 the session. A client MUST NOT attempt to initiate a session from 1165 within a different session. 1167 If the proxy can not or will not honor the Session Request, it does 1168 so silently. 1170 8.4.2. Further SOCKS Requests 1172 Any further SOCKS Requests that are part of the session MUST include 1173 a Session ID Option (as seen in Figure 20). 1175 The authentication procedure is altered based on the Session ID's 1176 validity and whether or not the Session is untrusted. 1178 For valid Session IDs: 1180 o If the session is untrusted, the proxy MUST reject clients that do 1181 not authenticate using the same method and credentials that were 1182 used to initiate the session. 1184 o Otherwise, the proxy MUST ignore any authentication attempt in the 1185 Request, and MUST NOT require any authentication. 1187 The proxy then replies by placing a Session OK option in the 1188 successful Authentication Reply: 1190 +------+--------+------+ 1191 | Kind | Length | Type | 1192 +------+--------+------+ 1193 | 1 | 2 | 1 | 1194 +------+--------+------+ 1196 Figure 22: Session OK Option 1198 o Kind: 0x04 (Session option) 1200 o Length: 5 1202 o Type: 0x04 (Session OK) 1204 If the ticket is invalid, the first Authentication Reply MUST signal 1205 that authentication failed and can not continue (by setting the Type 1206 field to 0x01 and the Method field to 0xff). Further, it SHALL 1207 contain a Session Invalid option: 1209 +------+--------+------+ 1210 | Kind | Length | Type | 1211 +------+--------+------+ 1212 | 1 | 2 | 1 | 1213 +------+--------+------+ 1215 Figure 23: Session Invalid Option 1217 o Kind: 0x04 (Session option) 1219 o Length: 5 1221 o Type: 0x05 (Session Invalid) 1223 8.4.3. Tearing down the session 1225 Proxies can, at their discretion, tear down a session and free all 1226 associated state. Proxy implementations SHOULD feature a timeout 1227 mechanism that destroys sessions after a period of inactivity. 1229 Clients can signal that a session is no longer needed, and can be 1230 torn down, by sending a Session Teardown option in addition to the 1231 Session ID option: 1233 +------+--------+------+ 1234 | Kind | Length | Type | 1235 +------+--------+------+ 1236 | 1 | 2 | 1 | 1237 +------+--------+------+ 1239 Figure 24: Session Teardown Option 1241 o Kind: 0x04 (Session option) 1243 o Length: 4 1245 o Type: 0x02 (Session Teardown) 1247 After sending such an option, the client MUST assume that the session 1248 is no longer valid. 1250 8.5. Idempotence options 1252 To protect against duplicate SOCKS Requests, clients can request, and 1253 then spend, idempotence tokens. A token can only be spent on a 1254 single SOCKS request. 1256 Tokens are 4-byte unsigned integers in a modular 4-byte space. 1257 Therefore, if x and y are tokens, x is less than y if 0 < (y - x) < 1258 2^31 in unsigned 32-bit arithmetic. 1260 Proxies grant contiguous ranges of tokens called token windows. 1261 Token windows are defined by their base (the first token in the 1262 range) and size. Windows can be shifted (i. e. have their base 1263 increased, while retaining their size) unilaterally by the proxy. 1265 Requesting and spending tokens is done via Idempotence options: 1267 +------+--------+------+-------------+ 1268 | Kind | Length | Type | Option Data | 1269 +------+--------+------+-------------+ 1270 | 1 | 2 | 1 | Variable | 1271 +------+--------+------+-------------+ 1273 Figure 25: Idempotence Option 1275 o Kind: 0x05 (Idempotence option) 1277 o Length: The length of the option. 1279 o Type: 1281 * 0x01: Token Request 1283 * 0x02: Token Window Advertisement 1285 * 0x03: Token Expenditure 1287 * 0x04: Token Expenditure Reply 1289 o Option Data: The contents are specific to each type. 1291 Idempotence options are only valid in the context of a SOCKS Session. 1292 If a SOCKS Request is not part of a Session (either by supplying a 1293 valid Session ID or successfully initiating one via a Session 1294 Request), the proxy MUST silently ignore any Idempotence options. 1296 Token windows are tracked by the proxy on a per-session basis. There 1297 can be at most one token window for every session and its tokens can 1298 only be spent from within said session. 1300 Client and proxy implementations MUST either support all Idempotence 1301 Option Types, or none. 1303 8.5.1. Requesting a fresh token window 1305 A client can obtain a fresh window of tokens by sending a Token 1306 Request option as part of a SOCKS Request: 1308 +------+--------+------+-------------+ 1309 | Kind | Length | Type | Window Size | 1310 +------+--------+------+-------------+ 1311 | 1 | 2 | 1 | 4 | 1312 +------+--------+------+-------------+ 1314 Figure 26: Token Request 1316 o Kind: MUST be allocated by IANA. (See Section 13.) 1318 o Length: 7 1320 o Type: 0x00 (Token Request) 1322 o Window Size: The requested window size. 1324 If a token window is issued, the proxy then includes a Token Window 1325 Advertisement option in the corresponding successful Authentication 1326 Reply: 1328 +------+--------+------+-------------+-------------+ 1329 | Kind | Length | Type | Window Base | Window Size | 1330 +------+--------+------+-------------+-------------+ 1331 | 1 | 2 | 1 | 4 | 4 | 1332 +------+--------+------+-------------+-------------+ 1334 Figure 27: Token Window Advertisement 1336 o Kind: 0x05 (Idempotence option) 1338 o Length: 11 1340 o Type: 0x01 (Token Grant) 1342 o Window Base: The first token in the window. 1344 o Window Size: The window size. This value SHOULD be lower or equal 1345 to the requested window size. Window sizes MUST be less than 1346 2^31. Window sizes MUST NOT be 0. 1348 If no token window is issued, the proxy MUST silently ignore the 1349 Token Request. 1351 8.5.2. Spending a token 1353 The client can attempt to spend a token by including a Token 1354 Expenditure option in its SOCKS request: 1356 +------+--------+------+-------+ 1357 | Kind | Length | Type | Token | 1358 +------+--------+------+-------+ 1359 | 1 | 2 | 1 | 4 | 1360 +------+--------+------+-------+ 1362 Figure 28: Token Expenditure 1364 o Kind: 0x05 (Idempotence option) 1366 o Length: 7 1368 o Type: 0x02 (Token Expenditure) 1369 o Token: The token being spent. 1371 Clients SHOULD prioritize spending the smaller tokens. 1373 The proxy responds by sending a Token Expenditure Reply option as 1374 part of the successful Authentication Reply: 1376 +------+--------+------+---------------+ 1377 | Kind | Length | Type | Response Code | 1378 +------+--------+------+---------------+ 1379 | 1 | 2 | 1 | 1 | 1380 +------+--------+------+---------------+ 1382 Figure 29: Token Expenditure Response 1384 o Kind: 0x05 (Idempotence option) 1386 o Length: 4 1388 o Type: 0x03 (Token Expenditure Response) 1390 o Response Code: 1392 * 0x01: Success: The token was spent successfully. 1394 * 0x02: No Window: The proxy does not have a token window 1395 associated with the client. 1397 * 0x03: Out of Window: The token is not within the window. 1399 * 0x04: Duplicate: The token has already been spent. 1401 If eligible, the token is spent before attempting to honor the 1402 Request. If the token is not eligible for spending, the proxy MUST 1403 NOT attempt to honor the client's Request; further, it MUST indicate 1404 a General SOCKS server failure in the Operation Reply. 1406 Proxy implementations SHOULD also send a Token Window Advertisement 1407 if: 1409 o the token is out of window, or 1411 o by the proxy's internal logic, successfully spending the token 1412 caused the window to shift. 1414 Proxy implementations SHOULD NOT shift the window's base beyond the 1415 highest unspent token. 1417 Proxy implementations MAY include a Token Window Advertisement in any 1418 Authentication Reply that indicates success. 1420 8.5.3. Handling Token Window Advertisements 1422 Even though the proxy increases the window's base monotonically, 1423 there is no mechanism whereby a SOCKS client can receive the Token 1424 Window Advertisements in order. As such, clients SHOULD disregard 1425 unsolicited Token Window Advertisements with a Window Base less than 1426 the previously known value. 1428 9. Username/Password Authentication 1430 Username/Password authentication is carried out as in [RFC1929]. 1432 Clients can also attempt to authenticate by placing the Username/ 1433 Password request in an Authentication Data Option. 1435 +------+--------+--------+---------------------------+ 1436 | Kind | Length | Method | Username/Password request | 1437 +------+--------+--------+---------------------------+ 1438 | 1 | 2 | 1 | Variable | 1439 +------+--------+--------+---------------------------+ 1441 Figure 30: Password authentication via a SOCKS Option 1443 o Kind: 0x03 (Authentication Data option) 1445 o Length: The length of the option. 1447 o Method: 0x02 (Username/Password). 1449 o Username/Password request: The Username/Password request, as 1450 described in [RFC1929]. 1452 10. TCP Fast Open on the Client-Proxy Leg 1454 TFO breaks TCP semantics, causing replays of the data in the SYN's 1455 payload under certain rare circumstances [RFC7413]. A replayed SOCKS 1456 Request could itself result in a replayed connection on behalf of the 1457 client. 1459 As such, client implementations SHOULD NOT use TFO on the client- 1460 proxy leg unless: 1462 o The protocol running on top of SOCKS tolerates the risks of TFO, 1463 or 1465 o The SYN's payload does not contain any application data (so that 1466 no data is replayed to the server, even though duplicate 1467 connections are still possible), or 1469 o The client uses Idempotence Options, making replays very unlikely, 1470 or 1472 o SOCKS is running on top of TLS and Early Data is not used. 1474 11. False Starts 1476 In case of CONNECT Requests, the client MAY start sending application 1477 data as soon as possible, as long as doing so does not incur the risk 1478 of breaking the SOCKS protocol. 1480 Clients must work around the authentication phase by doing any of the 1481 following: 1483 o If the Request does not contain an Authentication Method option, 1484 the authentication phase is guaranteed not to happen. In this 1485 case, application data MAY be sent immediately after the Request. 1487 o Application data MAY be sent immediately after receiving an 1488 Authentication Reply indicating success. 1490 o When performing a method-specific authentication sequence, 1491 application data MAY be sent immediately after the last client 1492 message. 1494 12. Security Considerations 1496 12.1. Large requests 1498 Given the format of the request message, a malicious client could 1499 craft a request that is in excess of 16 KB and proxies could be prone 1500 to DDoS attacks. 1502 To mitigate such attacks, proxy implementations SHOULD be able to 1503 incrementally parse the requests. Proxies MAY close the connection 1504 to the client if: 1506 o the request is not fully received after a certain timeout, or 1508 o the number of options or their size exceeds an imposed hard cap. 1510 12.2. Replay attacks 1512 In TLS 1.3, early data (which is likely to contain a full SOCKS 1513 request) is prone to replay attacks. 1515 While Token Expenditure options can be used to mitigate replay 1516 attacks, the initial Token Request is still vulnerable. As such, 1517 client implementations SHOULD NOT make use of TLS early data unless 1518 the Request attempts to spend a token. 1520 12.3. Resource exhaustion 1522 Malicious clients can issue a large number of Session Requests, 1523 forcing the proxy to keep large amounts of state. 1525 To mitigate this, the proxy MAY implement policies restricting the 1526 number of concurrent sessions on a per-IP or per-user basis, or 1527 barring unauthenticated clients from establishing sessions. 1529 13. IANA Considerations 1531 This document requests that IANA allocate 1-byte option kinds for 1532 SOCKS 6 options. Further, this document requests the following 1533 option kinds: 1535 o Stack options: 0x01 1537 o Authentication Method options: 0x02 1539 o Authentication Data options: 0x03 1541 o Session options: 0x04 1543 o Idempotence options: 0x05 1545 o A range for vendor-specific options: 0xE0-0xFF 1547 This document also requests that IANA allocate a TCP and UDP port for 1548 SOCKS over TLS and DTLS, respectively. 1550 14. Acknowledgements 1552 The protocol described in this draft builds upon and is a direct 1553 continuation of SOCKS 5 [RFC1928]. 1555 15. References 1557 15.1. Normative References 1559 [RFC1929] Leech, M., "Username/Password Authentication for SOCKS 1560 V5", RFC 1929, DOI 10.17487/RFC1929, March 1996, 1561 . 1563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1564 Requirement Levels", BCP 14, RFC 2119, 1565 DOI 10.17487/RFC2119, March 1997, 1566 . 1568 15.2. Informative References 1570 [I-D.ietf-tls-dtls-connection-id] 1571 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 1572 Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- 1573 id-04 (work in progress), March 2019. 1575 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1576 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1577 DOI 10.17487/RFC1928, March 1996, 1578 . 1580 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1581 "TCP Extensions for Multipath Operation with Multiple 1582 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1583 . 1585 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1586 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1587 . 1589 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1590 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1591 . 1593 Authors' Addresses 1595 Vladimir Olteanu 1596 University Politehnica of Bucharest 1598 Email: vladimir.olteanu@cs.pub.ro 1599 Dragos Niculescu 1600 University Politehnica of Bucharest 1602 Email: dragos.niculescu@cs.pub.ro