idnits 2.17.00 (12 Aug 2021) /tmp/idnits39608/draft-olteanu-intarea-socks-6-08.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 929 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-tls-dtls-connection-id has been published as RFC 9146 == Outdated reference: A later version (-14) exists of draft-ietf-tls-esni-04 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 4 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: May 7, 2020 November 04, 2019 7 SOCKS Protocol Version 6 8 draft-olteanu-intarea-socks-6-08 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 May 7, 2020. 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 . . . . . . . . . . . . . . . . . . . . 10 59 3. Mode of operation . . . . . . . . . . . . . . . . . . . . . . 10 60 4. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 5. Version Mismatch Replies . . . . . . . . . . . . . . . . . . 13 62 6. Authentication Replies . . . . . . . . . . . . . . . . . . . 13 63 7. Operation Replies . . . . . . . . . . . . . . . . . . . . . . 14 64 7.1. Handling CONNECT . . . . . . . . . . . . . . . . . . . . 16 65 7.2. Handling BIND . . . . . . . . . . . . . . . . . . . . . . 16 66 7.3. Handling UDP ASSOCIATE . . . . . . . . . . . . . . . . . 16 67 7.3.1. Proxying UDP servers . . . . . . . . . . . . . . . . 19 68 7.3.2. Proxying multicast traffic . . . . . . . . . . . . . 19 69 8. SOCKS Options . . . . . . . . . . . . . . . . . . . . . . . . 19 70 8.1. Stack options . . . . . . . . . . . . . . . . . . . . . . 20 71 8.1.1. IP TOS options . . . . . . . . . . . . . . . . . . . 21 72 8.1.2. Happy Eyeballs options . . . . . . . . . . . . . . . 21 73 8.1.3. TFO options . . . . . . . . . . . . . . . . . . . . . 22 74 8.1.4. Multipath options . . . . . . . . . . . . . . . . . . 22 75 8.1.5. Listen Backlog options . . . . . . . . . . . . . . . 23 76 8.2. Authentication Method options . . . . . . . . . . . . . . 24 77 8.3. Authentication Data options . . . . . . . . . . . . . . . 25 78 8.4. Session options . . . . . . . . . . . . . . . . . . . . . 26 79 8.4.1. Session initiation . . . . . . . . . . . . . . . . . 26 80 8.4.2. Further SOCKS Requests . . . . . . . . . . . . . . . 27 81 8.4.3. Tearing down the session . . . . . . . . . . . . . . 28 82 8.5. Idempotence options . . . . . . . . . . . . . . . . . . . 29 83 8.5.1. Requesting a token window . . . . . . . . . . . . . . 29 84 8.5.2. Spending a token . . . . . . . . . . . . . . . . . . 30 85 8.5.3. Shifting windows . . . . . . . . . . . . . . . . . . 32 86 8.5.4. Out-of-order Window Advertisements . . . . . . . . . 32 87 9. Username/Password Authentication . . . . . . . . . . . . . . 32 88 10. TCP Fast Open on the Client-Proxy Leg . . . . . . . . . . . . 33 89 11. False Starts . . . . . . . . . . . . . . . . . . . . . . . . 33 90 12. DNS provided by SOCKS . . . . . . . . . . . . . . . . . . . . 34 91 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 92 13.1. Large requests . . . . . . . . . . . . . . . . . . . . . 34 93 13.2. Replay attacks . . . . . . . . . . . . . . . . . . . . . 35 94 13.3. Resource exhaustion . . . . . . . . . . . . . . . . . . 35 95 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 96 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 97 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 98 16.1. Normative References . . . . . . . . . . . . . . . . . . 36 99 16.2. Informative References . . . . . . . . . . . . . . . . . 37 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 102 1. Introduction 104 Versions 4 and 5 [RFC1928] of the SOCKS protocol were developed two 105 decades ago and are in widespread use for circuit level gateways or 106 as circumvention tools, and enjoy wide support and usage from various 107 software, such as web browsers, SSH clients, and proxifiers. 108 However, their design needs an update in order to take advantage of 109 the new features of transport protocols, such as TCP Fast Open 110 [RFC7413], or to better assist newer transport protocols, such as 111 MPTCP [RFC6824]. 113 One of the main issues faced by SOCKS version 5 is that, when taking 114 into account the TCP handshake, method negotiation, authentication, 115 connection request and grant, it may take up to 5 RTTs for a data 116 exchange to take place at the application layer. This is especially 117 costly in networks with a large delay at the access layer, such as 118 3G, 4G, or satelite. 120 The desire to reduce the number of RTTs manifests itself in the 121 design of newer security protocols. TLS version 1.3 [RFC8446] 122 defines a zero round trip (0-RTT) handshake mode for connections if 123 the client and server had previously communicated. 125 TCP Fast Open [RFC7413] is a TCP option that allows TCP to send data 126 in the SYN and receive a response in the first ACK, and aims at 127 obtaining a data response in one RTT. The SOCKS protocol needs to 128 concern itself with at least two TFO deployment scenarios: First, 129 when TFO is available end-to-end (at the client, at the proxy, and at 130 the server); second, when TFO is active between the client and the 131 proxy, but not at the server. 133 This document describes the SOCKS protocol version 6. The key 134 improvements over SOCKS version 5 are: 136 o The client sends as much information upfront as possible, and does 137 not wait for the authentication process to conclude before 138 requesting the creation of a socket. 140 o The connection request also mimics the semantics of TCP Fast Open 141 [RFC7413]. As part of the connection request, the client can 142 supply the potential payload for the initial SYN that is sent out 143 to the server. 145 o The protocol can be extended via options without breaking 146 backward-compatibility. 148 o The protocol can leverage the aforementioned options to support 149 0-RTT authentication schemes. 151 1.1. Revision log 153 Typos and minor clarifications are not listed. 155 draft-08 157 o Removed Address Resolution options 159 o Happy Eyeballs options 161 o DNS provided by SOCKS 163 draft-07 165 o All fields are now alignned. 167 o Eliminated version minors 169 o Lots of changes to options 171 * 2-byte option kinds 173 * Flattened option kinds/types/reply codes; also renamed some 174 options 176 * Socket options 178 + Proxies MUST always answer them (Clients can probe for 179 support) 181 + MPTCP Options: expanded functionality ("please do/don't do 182 MPTCP on my behalf") 184 + MPTCP Scheduler options removed 186 + Listen Backlog options: code changed to 0x03 188 * Revamped Idempotence options 190 * Auth data options limited to one per method 192 o Authentication Reply: all authentication-related information is 193 now in the options 195 * Authentication replies no longer have a field indicating the 196 chosen auth. method 198 * Method that must proceed (or whereby authentication succeeded) 199 indicated in options 201 * Username/password authentication: proxy now sends reply in 202 option 204 o Removed requirements w.r.t. caching authentication methods by 205 multihomed clients 207 o UDP: 8-byte association IDs 209 o Sessions 211 * The proxy is now free to terminate ongoing connections along 212 with the session. 214 * The session-terminating request is not part of the session that 215 it terminated. 217 o Address Resolution options 219 draft-06 221 o Session options 223 o Options now have a 2-byte length field. 225 o Stack options 227 * Stack options can no longer contain duplicate information. 229 * TFO: Better payload size semantics 231 * TOS: Added missing code field. 233 * MPTCP Scheduler options: 235 + Removed support for round-robin 237 + "Default" renamed to "Lowest latency first" 239 * Listen Backlog options: now tied to sessions, instead of an 240 authenticated user 242 o Idempotence options 244 * Now used in the context of a session (no longer tied to an 245 authenticated user) 247 * Idempotence options have a different codepoint: 0x05. (Was 248 0x04.) 250 * Clarified that implementations that support Idempotence Options 251 must support all Idempotence Option Types. 253 * Shifted Idempotence Option Types by 1. (Makes implementation 254 easier.) 256 o Shrunk vendor-specific option range to 32 (down from 64). 258 o Removed reference to dropping initial data. (It could no longer 259 be done as of -05.) 261 o Initial data size capped at 16KB. 263 o Application data is never encrypted by SOCKS 6. (It can still be 264 encrypted by the TLS layer under SOCKS.) 266 o Messages now carry the total length of the options, rather than 267 the number of options. Limited options length to 16KB. 269 o Security Considerations 271 * Updated the section to reflect the smaller maximum message 272 size. 274 * Added a subsection on resource exhaustion. 276 draft-05 278 o Limited the "slow" authentication negociations to one (and 279 Authentication Replies to 2) 281 o Revamped the handling of the first bytes in the application data 282 stream 284 * False starts are now recommended. (Added the "False Start" 285 section.) 287 * Initial data is only available to clients willing to do "slow" 288 authentication. Moved the "Initial data size" field from 289 Requests to Authentication Method options. 291 * Initial data size capped at 2^13. Initial data can no longer 292 be dropped by the proxy. 294 * The TFO option can hint at the desired SYN payload size. 296 o Request: clarified the meaning of the Address and Port fields. 298 o Better reverse TCP proxy support: optional listen backlog for TCP 299 BIND 301 o TFO options can no longer be placed inside Operation Replies. 303 o IP TOS stack option 305 o Suggested a range for vendor-specific options. 307 o Revamped UDP functionality 309 * Now using fixed UDP ports 311 * DTLS support 313 o Stack options: renamed Proxy-Server leg to Proxy-Remote leg 315 draft-04 317 o Moved Token Expenditure Replies to the Authentication Reply. 319 o Shifted the Initial Data Size field in the Request, in order to 320 make it easier to parse. 322 draft-03 324 o Shifted some fields in the Operation Reply to make it easier to 325 parse. 327 o Added connection attempt timeout response code to Operation 328 Replies. 330 o Proxies send an additional Authentication Reply after the 331 authentication phase. (Useful for token window advertisements.) 333 o Renamed the section "Connection Requests" to "Requests" 334 o Clarified the fact that proxies don't need to support any command 335 in particular. 337 o Added the section "TCP Fast Open on the Client-Proxy Leg" 339 o Options: 341 * Added constants for option kinds 343 * Salt options removed, along with the relevant section from 344 Security Considerations. (TLS 1.3 Makes AEAD mandatory.) 346 * Limited Authentication Data options to one per method. 348 * Relaxed proxy requirements with regard to handling multiple 349 Authentication Data options. (When the client violates the 350 above bullet point.) 352 * Removed interdependence between Authentication Method and 353 Authentication Data options. 355 * Clients SHOULD omit advertising the "No authentication 356 required" option. (Was MAY.) 358 * Idempotence options: 360 + Token Window Advertisements are now part of successful 361 Authentication Replies (so that the proxy-server RTT has no 362 impact on their timeliness). 364 + Proxies can't advetise token windows of size 0. 366 + Tweaked token expenditure response codes. 368 + Support no longer mandatory on the proxy side. 370 * Revamped Socket options 372 + Renamed Socket options to Stack options. 374 + Banned contradictory socket options. 376 + Added socket level for generic IP. Removed the "socket" 377 socket level. 379 + Stack options no longer use option codes from setsockopt(). 381 + Changed MPTCP Scheduler constants. 383 o Made support for Idempotence options mandatory for proxies. 385 o Clarified what happens when proxies can not or will not issue 386 tokens. 388 o Limited token windows to 2^31 - 1. 390 o Fixed definition of "less than" for tokens. 392 o NOOP commands now trigger Operation Replies. 394 o Renamed Authentication options to Authentication Data options. 396 o Authentication Data options are no longer mandatory. 398 o Authentication methods are now advertised via options. 400 o Shifted some Request fields. 402 o Option range for vendor-specific options. 404 o Socket options. 406 o Password authentication. 408 o Salt options. 410 draft-01 412 o Added this section. 414 o Support for idempotent commands. 416 o Removed version numbers from operation replies. 418 o Request port number for SOCKS over TLS. Deprecate encryption/ 419 encapsulation within SOCKS. 421 o Added Version Mismatch Replies. 423 o Renamed the AUTH command to NOOP. 425 o Shifted some fields to make requests and operation replies easier 426 to parse. 428 2. Requirements language 430 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 431 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 432 document are to be interpreted as described in [RFC2119]. 434 3. Mode of operation 436 CLIENT PROXY 438 +------------------------+ 439 | Authentication methods | Request 440 --------> Command code +------------------------------> 441 | Address | 442 | Port | 443 | Options | 444 +------------------------+ 446 +------------------------+ 447 --------> Initial data +------------------------------> 448 +------------------------+ 450 +-----------------------+ 451 Authentication Reply | Type | 452 <----------------------------------+ Options <----- 453 +-----------------------+ 455 <-------------------(Authentication protocol)------------------> 457 +-----------------------+ 458 Authentication Reply | Type = Success | 459 <----------------------------------+ Options <----- 460 +-----------------------+ 462 +-----------------------+ 463 Operation Reply | Reply code | 464 <--------------------+ Bind address <------------------ 465 | Bind port | 466 | Options | 467 +-----------------------+ 469 Figure 1: The SOCKS version 6 protocol message exchange 471 When a TCP-based client wishes to establish a connection to a server, 472 it must open a TCP connection to the appropriate SOCKS port on the 473 SOCKS proxy. The client then enters a negotiation phase, by sending 474 the request in Figure 1, that contains, in addition to fields present 475 in SOCKS 5 [RFC1928], fields that facilitate low RTT usage and faster 476 authentication negotiation. 478 Next, the server sends an authentication reply. If the request did 479 not contain the necessary authentication information, the proxy 480 indicates an authentication method that must proceed. This may 481 trigger a longer authentication sequence that could include tokens 482 for ulterior faster authentications. The part labeled 483 "Authentication protocol" is specific to the authentication method 484 employed and is not expected to be employed for every connection 485 between a client and its proxy server. The authentication protocol 486 typically takes up 1 RTT or more. 488 If the authentication is successful, an operation reply is generated 489 by the proxy. It indicates whether the proxy was successful in 490 creating the requested socket or not. 492 In the fast case, when authentication is properly set up, the proxy 493 attempts to create the socket immediately after the receipt of the 494 request, thus achieving an operational conection in one RTT (provided 495 TFO functionality is available at the client, proxy, and server). 497 4. Requests 499 The client starts by sending a request to the proxy. 501 1 2 3 502 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 503 +---------------+---------------+-------------------------------+ 504 | Version = 6 | Command Code | Options Length | 505 +---------------+---------------+---------------+---------------+ 506 | Port | Padding = 0 | Address Type | 507 +-------------------------------+---------------+---------------+ 508 | ... 509 ... Address (variable length) ... 510 ... | 511 +---------------------------------------------------------------+ 512 | ... 513 ... Options (variable length) ... 514 ... | 515 +---------------------------------------------------------------+ 517 Figure 2: SOCKS 6 Request 519 o Version: 6 520 o Command Code: 522 * 0x00 NOOP: does nothing. 524 * 0x01 CONNECT: requests the establishment of a TCP connection. 525 TFO MUST NOT be used unless explicitly requested. 527 * 0x02 BIND: requests the establishment of a TCP port binding. 529 * 0x03 UDP ASSOCIATE: requests a UDP port association. 531 o Address Type: 533 * 0x01: IPv4 535 * 0x03: Domain Name 537 * 0x04: IPv6 539 o Address: this field's format depends on the address type: 541 * IPv4: a 4-byte IPv4 address 543 * Domain Name: one byte that contains the length of the FQDN, 544 followed by the FQDN itself. The string is not NUL-terminated, 545 but padded by NUL characters, if needed. 547 * IPv6: a 16-byte IPv6 address 549 o Port: the port in network byte order. 551 o Padding: set to 0 553 o Options Length: the total size of the SOCKS options that appear in 554 the Options field. MUST NOT exceed 16KB. 556 o Options: see Section 8. 558 The Address and Port fields have different meanings based on the 559 Command Code: 561 o NOOP: The fields have no meaning. The Address Type field MUST be 562 either 0x01 (IPv4) or 0x04 (IPv6). The Address and Port fields 563 MUST be 0. 565 o CONNECT: The fields signify the address and port to which the 566 client wishes to connect. 568 o BIND, UDP ASSOCIATE: The fields indicate the desired bind address 569 and port. If the client does not require a certain address, it 570 can set the Address Type field to 0x01 (IPv4) or 0x04 (IPv6), and 571 the Address field to 0. Likewise, if the client does not require 572 a certain port, it can set the Port field to 0. 574 Clients can advertise their supported authentication methods by 575 including an Authentication Method Advertisement option (see 576 Section 8.2). 578 5. Version Mismatch Replies 580 Upon receipt of a request starting with a version number other than 581 6, the proxy sends the following response: 583 0 1 2 3 4 5 6 7 584 +---------------+ 585 | Version = 6 | 586 +---------------+ 588 Figure 3: SOCKS 6 Version Mismatch Reply 590 o Version: 6 592 A client MUST close the connection after receiving such a reply. 594 6. Authentication Replies 596 Upon receipt of a valid request, the proxy sends an Authentication 597 Reply: 599 1 2 3 600 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 601 +---------------+---------------+-------------------------------+ 602 | Version = 6 | Type | Options Length | 603 +---------------+---------------+-------------------------------+ 604 | ... 605 ... Options (variable length) ... 606 ... | 607 +---------------------------------------------------------------+ 609 Figure 4: SOCKS 6 Authentication Reply 611 o Version: 6 612 o Type: 614 * 0x00: authentication successful. 616 * 0x01: authentication failed. 618 o Options Length: the total size of the SOCKS options that appear in 619 the Options field. MUST NOT exceed 16KB. 621 o Options: see Section 8. 623 If the server signals that the authentication has failed and does not 624 signal that any authentication negotiation can continue (via an 625 Authentication Method Selection option), the client MUST close the 626 connection. 628 The client and proxy begin a method-specific negotiation. During 629 such negotiations, the proxy MAY supply information that allows the 630 client to authenticate a future request using an Authentication Data 631 option. Application data is not subject to any encryption negotiated 632 during this phase. Descriptions of such negotiations are beyond the 633 scope of this memo. 635 When the negotiation is complete (either successfully or 636 unsuccessfully), the proxy sends a second Authentication Reply. The 637 second Authentication Reply MUST NOT allow for further negotiations. 639 7. Operation Replies 641 After the authentication negotiations are complete, the proxy sends 642 an Operation Reply: 644 1 2 3 645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 646 +---------------+---------------+-------------------------------+ 647 | Version = 6 | Reply Code | Options Length | 648 +---------------+---------------+---------------+---------------+ 649 | Bind Port | Padding = 0 | Address Type | 650 +-------------------------------+---------------+---------------+ 651 | ... 652 ... Bind Address (variable length) ... 653 ... | 654 +---------------------------------------------------------------+ 655 | ... 656 ... Options (variable length) ... 657 ... | 658 +---------------------------------------------------------------+ 660 Figure 5: SOCKS 6 Operation Reply 662 o Version: 6 664 o Reply Code: 666 * 0x00: Succes 668 * 0x01: General SOCKS server failure 670 * 0x02: Connection not allowed by ruleset 672 * 0x03: Network unreachable 674 * 0x04: Host unreachable 676 * 0x05: Connection refused 678 * 0x06: TTL expired 680 * 0x07: Command not supported 682 * 0x08: Address type not supported 684 * 0x09: Connection attempt timed out 686 o Bind Port: the proxy bound port in network byte order. 688 o Padding: set to 0 690 o Address Type: 692 * 0x01: IPv4 694 * 0x03: Domain Name 696 * 0x04: IPv6 698 o Bind Address: the proxy bound address in the following format: 700 * IPv4: a 4-byte IPv4 address 702 * Domain Name: one byte that contains the length of the FQDN, 703 followed by the FQDN itself. The string is not NUL-terminated, 704 but padded by NUL characters, if needed. 706 * IPv6: a 16-byte IPv6 address 708 o Options Length: the total size of the SOCKS options that appear in 709 the Options field. MUST NOT exceed 16KB. 711 o Options: see Section 8. 713 Proxy implementations MAY support any subset of the client commands 714 listed in Section 4. 716 If the proxy returns a reply code other than "Success", the client 717 MUST close the connection. 719 If the client issued an NOOP command, the client MUST close the 720 connection after receiving the Operation Reply. 722 7.1. Handling CONNECT 724 In case the client has issued a CONNECT request, data can now pass. 726 7.2. Handling BIND 728 In case the client has issued a BIND request, it must wait for a 729 second Operation reply from the proxy, which signifies that a host 730 has connected to the bound port. The Bind Address and Bind Port 731 fields contain the address and port of the connecting host. 732 Afterwards, application data may pass. 734 7.3. Handling UDP ASSOCIATE 736 Proxies offering UDP functionality must be configured with a UDP port 737 used for relaying UDP datagrams to and from the client, and/or a port 738 used for relaying datagrams over DTLS. 740 Following a successful Operation Reply, the proxy sends a UDP 741 Association Initialization message: 743 1 2 3 744 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 745 +---------------------------------------------------------------+ 746 | Association ID | 747 | (8 bytes) | 748 +---------------------------------------------------------------+ 750 Figure 6: UDP Association Initialization 752 o Association ID: the identifier of the UDP association 754 Proxy implementations SHOULD generate Association IDs randomly or 755 pseudo-randomly. 757 Clients may start sending UDP datagrams to the proxy either in 758 plaintext, or over an established DTLS session, using the proxy's 759 configured UDP ports. A client's datagrams are prefixed by a SOCKS 760 Datagram Header, indicating the remote host's address and port: 762 1 2 3 763 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 764 +---------------+---------------+-------------------------------+ 765 | Version = 6 | Address Type | Port | 766 +---------------+---------------+-------------------------------+ 767 | Association ID | 768 | (8 bytes) | 769 +---------------------------------------------------------------+ 770 | ... 771 ... Address (variable length) ... 772 ... | 773 +---------------------------------------------------------------+ 775 Figure 7: SOCKS 6 Datagram Header 777 o Version: 0x06 779 o Association ID: the identifier of the UDP association 781 o Address Type: 783 * 0x01: IPv4 785 * 0x03: Domain Name 786 * 0x04: IPv6 788 o Address: this field's format depends on the address type: 790 * IPv4: a 4-byte IPv4 address 792 * Domain Name: one byte that contains the length of the FQDN, 793 followed by the FQDN itself. The string is not NUL-terminated. 795 * IPv6: a 16-byte IPv6 address 797 o Port: the port in network byte order. 799 Following the receipt of the first datagram from the client, the 800 proxy makes a one-way mapping between the Association ID and: 802 o the 5-tuple of the UDP conversation, if the datagram was received 803 over plain UDP, or 805 o the DTLS connection, if the datagram was received over DTLS. The 806 DTLS connection is identified either by its 5-tuple, or some other 807 mechanism, like [I-D.ietf-tls-dtls-connection-id]. 809 Further datagrams carrying the same Association ID, but not matching 810 the established mapping, are silently dropped. 812 The proxy then sends an UDP Association Confirmation message over the 813 TCP connection with the client: 815 0 1 2 3 4 5 6 7 816 +---------------+ 817 | Status = 0 | 818 +---------------+ 820 Figure 8: UDP Association Confirmation 822 o Status: MUST be 0x00 824 Following the confirmation message, UDP packets bound for the proxy's 825 bind address and port are relayed to the client, also prefixed by a 826 Datagram Header. 828 The UDP association remains active for as long as the TCP connection 829 between the client and the proxy is kept open. 831 7.3.1. Proxying UDP servers 833 Under some circumstances (e.g. when hosting a server), the SOCKS 834 client expects the remote host to send UDP datagrams first. As such, 835 the SOCKS client must trigger a UDP Association Confirmation without 836 having the proxy relay any datagrams on its behalf. 838 To that end, it sends an empty datagram prefixed by a Datagram Header 839 with an IP address and port consisting of zeroes. The client SHOULD 840 resend the empty datagram if an UDP Association Confirmation is not 841 received after a timeout. 843 7.3.2. Proxying multicast traffic 845 The use of multicast addessses is permitted for UDP traffic only. 847 8. SOCKS Options 849 SOCKS options have the following format: 851 1 2 3 852 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 853 +-------------------------------+-------------------------------+ 854 | Kind | Length | 855 +-------------------------------+-------------------------------+ 856 | ... 857 ... Option Data (variable length) ... 858 ... | 859 +---------------------------------------------------------------+ 861 Figure 9: SOCKS 6 Option 863 o Kind: Allocated by IANA. (See Section 14.) 865 o Length: The total length of the option. MUST be a multiple of 4. 867 o Option Data: The contents are specific to each option kind. 869 Unless otherwise noted, client and proxy implementations MAY omit 870 supporting any of the options described in this document. Upon 871 encountering an unsupported option, a SOCKS endpoint MUST silently 872 ignore it. 874 8.1. Stack options 876 Stack options can be used by clients to alter the behavior of the 877 protocols on top of which SOCKS is running, as well the protcols used 878 by the proxy to communicate with the remote host (i.e. IP, TCP, 879 UDP). A Stack option can affect either the proxy's protocol on the 880 client-proxy leg or on the proxy-remote leg. Clients can only place 881 Stack options inside SOCKS Requests. 883 Proxies MAY choose not to honor any Stack options sent by the client. 885 Proxies include Stack options in their Operation Replies to signal 886 their behavior, and MUST do so for every supported Stack option sent 887 by the client. Said options MAY also be unsolicited, i. e. the proxy 888 MAY send them to signal behaviour that was not explicitly requested 889 by the client. 891 If a particular Stack option is unsupported, the proxy MUST silently 892 ignore it. 894 In case of UDP ASSOCIATE, the stack options refer to the UDP traffic 895 relayed by the proxy. 897 Stack options that are part of the same message MUST NOT contradict 898 one another or contain duplicate information. 900 1 2 3 901 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 902 +-------------------------------+-------------------------------+ 903 | Kind = 1 | Length | 904 +---+-----------+---------------+-------------------------------+ 905 |Leg| Level | Code | ... 906 +---+-----------+---------------+ ... 907 ... ... 908 ... Option Data (variable length) ... 909 ... | 910 +---------------------------------------------------------------+ 912 Figure 10: Stack Option 914 o Leg: 916 * 1: Client-Proxy Leg 918 * 2: Proxy-Remote Leg 920 * 3: Both Legs 922 o Level: 924 * 1: IP: options that apply to either IPv4 or IPv6 926 * 2: IPv4 928 * 3: IPv6 930 * 4: TCP 932 * 5: UDP 934 o Code: Option code 936 o Option Data: Option-specific data 938 8.1.1. IP TOS options 940 1 2 3 941 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 942 +-------------------------------+-------------------------------+ 943 | Kind = 1 | Length = 8 | 944 +---+-----------+---------------+---------------+---------------+ 945 |Leg| Level = 1 | Code = 1 | TOS | Padding = 0 | 946 +---+-----------+---------------+---------------+---------------+ 948 Figure 11: IP TOS Option 950 o TOS: The IP TOS code 952 The client can use IP TOS options to request that the proxy use a 953 certain value for the IP TOS field. Likewise, the proxy can use IP 954 TOS options to advertise the TOS values being used. 956 8.1.2. Happy Eyeballs options 958 1 2 3 959 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 960 +-------------------------------+-------------------------------+ 961 | Kind = 1 | Length = 8 | 962 +---+-----------+---------------+-------------------------------+ 963 | 2 | Level = 1 | Code = 2 | Padding = 0 | 964 +---+-----------+---------------+-------------------------------+ 966 Figure 12: Happy Eyeballs Option 968 This memo provides enough features for clients to implement a 969 mechanism analogous to Happy Eyeballs [RFC8305] over SOCKS. However, 970 when the delay between the client and the proxy, or the proxy's 971 vantage point, is high, doing so can become impractical or 972 inefficient. 974 In such cases, the client can instruct the proxy to employ the Happy 975 Eyeballs technique on its behalf when connecting to a remote host. 977 The client MUST supply a Domain Name as part of its Request. 978 Otherwise, the proxy MUST silently ignore the option. 980 TODO: Figure out which knobs to include. 982 8.1.3. TFO options 984 1 2 3 985 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 986 +-------------------------------+-------------------------------+ 987 | Kind = 1 | Length = 8 | 988 +---+-----------+---------------+-------------------------------+ 989 | 2 | Level = 4 | Code = 1 | Payload Size | 990 +---+-----------+---------------+-------------------------------+ 992 Figure 13: TFO Option 994 o Payload Size: The desired payload size of the TFO SYN. Ignored in 995 case of a BIND command. 997 If a SOCKS Request contains a TFO option, the proxy SHOULD attempt to 998 use TFO in case of a CONNECT command, or accept TFO in case of a BIND 999 command. Otherwise, the proxy MUST NOT attempt to use TFO in case of 1000 a CONNECT command, or accept TFO in case of a BIND command. 1002 In case of a CONNECT command, the client can indicate the desired 1003 payload size of the SYN. If the field is 0, the proxy can use an 1004 arbitrary payload size. If the field is non-zero, the proxy MUST NOT 1005 use a payload size larger than the one indicated. The proxy MAY use 1006 a smaller payload size than the one indicated. 1008 8.1.4. Multipath options 1010 In case of a CONNECT or BIND command, the client can inform the proxy 1011 whether MPTCP is desired on the proxy-remote leg by sending a 1012 Multipath option. 1014 Conversely, the proxy can use a Multipath option to convey the 1015 following information: * whether or not the connection uses MPTCP or 1016 not, when replying to a CONNECT command, or in the second Operation 1017 reply to a BIND command, or * whether an MPTCP connection will be 1018 accepted, when first replying to a BIND command. 1020 1 2 3 1021 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1022 +-------------------------------+-------------------------------+ 1023 | Kind = 1 | Length = 8 | 1024 +---+-----------+---------------+---------------+---------------+ 1025 | 2 | Level = 4 | Code = 2 | Availability | Padding = 0 | 1026 +---+-----------+---------------+---------------+---------------+ 1028 Figure 14: Multipath Option 1030 o Availability: 1032 * 0x01: MPTCP is not desired or available 1034 * 0x02: MPTCP is desired or available 1036 In the absence of such an option, the proxy SHOULD NOT enable MPTCP. 1038 8.1.5. Listen Backlog options 1040 1 2 3 1041 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1042 +-------------------------------+-------------------------------+ 1043 | Kind = 1 | Length = 8 | 1044 +---+-----------+---------------+-------------------------------+ 1045 | 2 | Level = 4 | Code = 3 | Backlog | 1046 +---+-----------+---------------+-------------------------------+ 1048 Figure 15: Listen Backlog Option 1050 o Backlog: The length of the listen backlog. 1052 The default behavior of the BIND does not allow a client to 1053 simultaneously handle multiple connections to the same bind address. 1054 A client can alter BIND's behavior by adding a TCP Listen Backlog 1055 Option to a BIND Request, provided that the Request is part of a 1056 Session. 1058 In response, the proxy sends a TCP Listen Backlog Option as part of 1059 the Operation Reply, with the Backlog field signalling the actual 1060 backlog used. The proxy SHOULD NOT use a backlog longer than 1061 requested. 1063 Following the successful negotiation of a backlog, the proxy listens 1064 for incoming connections for as long as the initial connection stays 1065 open. The initial connection is not used to relay data between the 1066 client and a remote host. 1068 To accept connections, the client issues further BIND Requests using 1069 the bind address and port supplied by the proxy in the initial 1070 Operation Reply. Said BIND requests must belong to the same Session 1071 as the original Request. 1073 If no backlog is issued, the proxy signals a backlog length of 0, and 1074 BIND's behavior remains unaffected. 1076 8.2. Authentication Method options 1078 A client that is willing to go through the authentication phase MUST 1079 include an Authentication Method Advertisement option in its Request. 1080 In case of a CONNECT Request, the option is also used to specify the 1081 amount of initial data supplied before any method-specific 1082 authentication negotiations take place. 1084 1 2 3 1085 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1086 +-------------------------------+-------------------------------+ 1087 | Kind = 2 | Length | 1088 +-------------------------------+-------------------------------+ 1089 | Initial Data Length | ... 1090 +-------------------------------+ ... 1091 ... ... 1092 ... Methods (variable length) ... 1093 ... ... 1094 ... +-----------------------------------------------+ 1095 ... | Padding = 0 (variable length, 0-3 bytes) | 1096 +---------------+-----------------------------------------------+ 1098 Figure 16: Authentication Method Advertisement Option 1100 o Initial Data Size: A two-byte number in network byte order. In 1101 case of CONNECT, this is the number of bytes of initial data that 1102 are supplied by the client immediately following the Request. 1103 This number MUST NOT be larger than 2^14. 1105 o Methods: One byte per advertised method. Method numbers are 1106 assigned by IANA. 1108 o Padding: A minimally-sized sequence of zeroes, such that the 1109 option length is a multiple of 4. Note that 0 coincides with the 1110 value for "No Authentication Required". 1112 Clients MUST support the "No authentication required" method. 1113 Clients SHOULD omit advertising the "No authentication required" 1114 option. 1116 The proxy indicates which authentication method must proceed by 1117 sending an Authentication Method Selection option in the 1118 corresponding Authentication Reply: 1120 1 2 3 1121 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1122 +-------------------------------+-------------------------------+ 1123 | Kind = 3 | Length = 8 | 1124 +---------------+---------------+-------------------------------+ 1125 | Method | Padding = 0 | 1126 +---------------+-----------------------------------------------+ 1128 Figure 17: Authentication Method Selection Option 1130 o Method: The selected method. 1132 If the proxy selects "No Acceptable Methods", the client MUST close 1133 the connection. 1135 If authentication is successful via some other means, or not required 1136 at all, the proxy silently ignores the Authentication Method 1137 Advertisement option. 1139 8.3. Authentication Data options 1141 Authentication Data options carry method-specific authentication 1142 data. They can be part of SOCKS Requests and Authentication Replies. 1144 Authentication Data options have the following format: 1146 1 2 3 1147 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1148 +-------------------------------+-------------------------------+ 1149 | Kind = 4 | Length | 1150 +---------------+---------------+-------------------------------+ 1151 | Method | ... 1152 +---------------+ ... 1153 ... ... 1154 ... Authentication Data (variable length) ... 1155 ... | 1156 +---------------------------------------------------------------+ 1158 Figure 18: Authentication Data Option 1160 o Method: The number of the authentication method. These numbers 1161 are assigned by IANA. 1163 o Authentication Data: The contents are specific to each method. 1165 Clients MUST only place one Authentication Data option per 1166 authentication method. 1168 8.4. Session options 1170 Clients and proxies can establish SOCKS sessions, which span one or 1171 more Requests. All session-related negotiations are done via Session 1172 Options, which are placed in Requests and Authentication Replies by 1173 the client and, respectively, by the proxy. 1175 Client and proxy implementations MUST either support all Session 1176 Option Types, or none. 1178 8.4.1. Session initiation 1180 A client can initiate a session by sending a Session Request Option: 1182 1 2 3 1183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1184 +-------------------------------+-------------------------------+ 1185 | Kind = 5 | Length = 4 | 1186 +-------------------------------+-------------------------------+ 1188 Figure 19: Session Request Option 1190 The proxy then replies with a Session ID Option in the successful 1191 Operation Reply: 1193 1 2 3 1194 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1195 +-------------------------------+-------------------------------+ 1196 | Kind = 6 | Length | 1197 +-------------------------------+-------------------------------+ 1198 | ... 1199 ... Session ID (variable length) ... 1200 ... | 1201 +---------------------------------------------------------------+ 1203 Figure 20: Session ID Option 1205 o Session ID: An opaque sequence of bytes specific to the session. 1206 The size MUST be a multiple of 4. MUST NOT be empty. 1208 The Session ID serves to identify the session and is opaque to the 1209 client. 1211 The credentials, or lack thereof, used to initiate the session are 1212 tied to the session. If authentication is to be performed for 1213 further Requests, the session is deemed "untrusted", and the proxy 1214 also places a Session Untrusted option in the Authentication Reply: 1216 1 2 3 1217 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1218 +-------------------------------+-------------------------------+ 1219 | Kind = 7 | Length = 4 | 1220 +-------------------------------+-------------------------------+ 1222 Figure 21: Session Untrusted Option 1224 The SOCKS Request that initiated the session is considered part of 1225 the session. A client MUST NOT attempt to initiate a session from 1226 within a different session. 1228 If the proxy can not or will not honor the Session Request, it does 1229 so silently. 1231 8.4.2. Further SOCKS Requests 1233 Any further SOCKS Requests that are part of the session MUST include 1234 a Session ID Option (as seen in Figure 20). 1236 The authentication procedure is altered based on the Session ID's 1237 validity and whether or not the Session is untrusted. 1239 For valid Session IDs: 1241 o If the session is untrusted, the proxy MUST reject clients that do 1242 not authenticate using the same method and credentials that were 1243 used to initiate the session. 1245 o Otherwise, the proxy MUST silently ignore any authentication 1246 attempt in the Request, and MUST NOT require any authentication. 1248 The proxy then replies by placing a Session OK option in the 1249 successful Authentication Reply: 1251 1 2 3 1252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1253 +-------------------------------+-------------------------------+ 1254 | Kind = 8 | Length = 4 | 1255 +-------------------------------+-------------------------------+ 1257 Figure 22: Session OK Option 1259 If the ticket is invalid, the first Authentication Reply MUST signal 1260 that authentication failed and can not continue (by setting the Type 1261 field to 0x01). Further, it SHALL contain a Session Invalid option: 1263 1 2 3 1264 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1265 +-------------------------------+-------------------------------+ 1266 | Kind = 9 | Length = 4 | 1267 +-------------------------------+-------------------------------+ 1269 Figure 23: Session Invalid Option 1271 8.4.3. Tearing down the session 1273 Proxies can, at their discretion, tear down a session and free all 1274 associated state. Proxy implementations SHOULD feature a timeout 1275 mechanism that destroys sessions after a period of inactivity. When 1276 a session is terminated, the proxy MAY close all connections 1277 associated with said session. 1279 Clients can signal that a session is no longer needed, and can be 1280 torn down, by sending a Session Teardown option in addition to the 1281 Session ID option: 1283 1 2 3 1284 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1285 +-------------------------------+-------------------------------+ 1286 | Kind = 10 | Length = 4 | 1287 +-------------------------------+-------------------------------+ 1289 Figure 24: Session Teardown Option 1291 After sending such an option, the client MUST assume that the session 1292 is no longer valid. The proxy MUST treat the connection-terminating 1293 request as if it were not part of any session. 1295 8.5. Idempotence options 1297 To protect against duplicate SOCKS Requests, clients can request, and 1298 then spend, idempotence tokens. A token can only be spent on a 1299 single SOCKS request. 1301 Tokens are 4-byte unsigned integers in a modular 4-byte space. 1302 Therefore, if x and y are tokens, x is less than y if 0 < (y - x) < 1303 2^31 in unsigned 32-bit arithmetic. 1305 Proxies grant contiguous ranges of tokens called token windows. 1306 Token windows are defined by their base (the first token in the 1307 range) and size. 1309 All token-related operations are done via Idempotence options. 1311 Idempotence options are only valid in the context of a SOCKS Session. 1312 If a SOCKS Request is not part of a Session (either by supplying a 1313 valid Session ID or successfully initiating one via a Session 1314 Request), the proxy MUST silently ignore any Idempotence options. 1316 Token windows are tracked by the proxy on a per-session basis. There 1317 can be at most one token window for every session and its tokens can 1318 only be spent from within said session. 1320 Client and proxy implementations MUST either support all Idempotence 1321 Option Types, or none. 1323 8.5.1. Requesting a token window 1325 A client can obtain a window of tokens by sending an Idempotence 1326 Request option as part of a SOCKS Request: 1328 1 2 3 1329 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1330 +-------------------------------+-------------------------------+ 1331 | Kind = 11 | Length = 8 | 1332 +-------------------------------+-------------------------------+ 1333 | Window Size | 1334 +---------------------------------------------------------------+ 1336 Figure 25: Token Request 1338 o Window Size: The requested window size. 1340 Once a token window is issued, the proxy MUST include an Idempotence 1341 Window option in all subsequent successful Authentication Replies: 1343 1 2 3 1344 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1345 +-------------------------------+-------------------------------+ 1346 | Kind = 12 | Length = 12 | 1347 +-------------------------------+-------------------------------+ 1348 | Window Base | 1349 +---------------------------------------------------------------+ 1350 | Window Size | 1351 +---------------------------------------------------------------+ 1353 Figure 26: Idempotence Window 1355 o Window Base: The first token in the window. 1357 o Window Size: The window size. This value MAY differ from the 1358 requested window size. Window sizes MUST be less than 2^31. 1359 Window sizes MUST NOT be 0. 1361 If no token window is issued, the proxy MUST silently ignore the 1362 Token Request. If there is already a token window associated with 1363 the session, the proxy MUST NOT issue a new window. 1365 8.5.2. Spending a token 1367 The client can attempt to spend a token by including a Idempotence 1368 Expenditure option in its SOCKS request: 1370 1 2 3 1371 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1372 +-------------------------------+-------------------------------+ 1373 | Kind = 13 | Length = 4 | 1374 +-------------------------------+-------------------------------+ 1375 | Token | 1376 +---------------------------------------------------------------+ 1378 Figure 27: Idempotence Expenditure 1380 o Kind: 13 (Idempotence Expenditure option) 1382 o Length: 8 1384 o Token: The token being spent. 1386 Clients SHOULD prioritize spending the smaller tokens. 1388 The proxy responds by sending either an Idempotence Accepted or 1389 Rejected option as part of the Authentication Reply: 1391 1 2 3 1392 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1393 +-------------------------------+-------------------------------+ 1394 | Kind = 14 | Length = 4 | 1395 +-------------------------------+-------------------------------+ 1397 Figure 28: Idempotence Accepted 1399 1 2 3 1400 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1401 +-------------------------------+-------------------------------+ 1402 | Kind = 15 | Length = 4 | 1403 +-------------------------------+-------------------------------+ 1405 Figure 29: Idempotence Rejected 1407 If eligible, the token is spent before attempting to honor the 1408 Request. If the token is not eligible for spending, the 1409 Authentication Reply MUST indicate failure. 1411 8.5.3. Shifting windows 1413 Windows can be shifted (i. e. have their base increased, while 1414 retaining their size) unilaterally by the proxy. 1416 Proxy implementations SHOULD shift the window: * as soon as the 1417 lowest-order token in the window is spent and * when a sufficiently 1418 high-order token is spent. 1420 Proxy implementations SHOULD NOT shift the window's base beyond the 1421 highest unspent token. 1423 8.5.4. Out-of-order Window Advertisements 1425 Even though the proxy increases the window's base monotonically, 1426 there is no mechanism whereby a SOCKS client can receive the Token 1427 Window Advertisements in order. As such, clients SHOULD disregard 1428 Token Window Advertisements with a Window Base less than the 1429 previously known value. 1431 9. Username/Password Authentication 1433 Username/Password authentication is carried out as in [RFC1929]. 1435 Clients can also attempt to authenticate by placing the Username/ 1436 Password request in an Authentication Data Option. 1438 1 2 3 1439 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1440 +-------------------------------+-------------------------------+ 1441 | Kind = 4 | Length | 1442 +---------------+---------------+---------------+---------------+ 1443 | Method = 2 | ... 1444 +---------------+ ... 1445 ... ... 1446 ... Username/Password Request ... 1447 ... ... 1448 ... +-----------------------------------------------+ 1449 ... | Padding = 0 (variable length, 0-3 bytes) | 1450 +---------------+-----------------------------------------------+ 1452 Figure 30: Password authentication via a SOCKS Option 1454 o Username/Password Request: The Username/Password Request, as 1455 described in [RFC1929]. 1457 Proxies reply by including a Authentication Data Option in the next 1458 Authentication Reply which contains the Username/Password reply: 1460 1 2 3 1461 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1462 +-------------------------------+-------------------------------+ 1463 | Kind = 4 | Length = 8 | 1464 +---------------+---------------+---------------+---------------+ 1465 | Method = 2 | Username/Password Reply | Padding = 0 | 1466 +---------------+-------------------------------+---------------+ 1468 Figure 31: Reply to password authentication via a SOCKS Option 1470 o Username/Password Reply: The Username/Password Reply, as described 1471 in [RFC1929]. 1473 10. TCP Fast Open on the Client-Proxy Leg 1475 TFO breaks TCP semantics, causing replays of the data in the SYN's 1476 payload under certain rare circumstances [RFC7413]. A replayed SOCKS 1477 Request could itself result in a replayed connection on behalf of the 1478 client. 1480 As such, client implementations SHOULD NOT use TFO on the client- 1481 proxy leg unless: 1483 o The protocol running on top of SOCKS tolerates the risks of TFO, 1484 or 1486 o The SYN's payload does not contain any application data (so that 1487 no data is replayed to the server, even though duplicate 1488 connections are still possible), or 1490 o The client uses Idempotence Options, making replays very unlikely, 1491 or 1493 o SOCKS is running on top of TLS and Early Data is not used. 1495 11. False Starts 1497 In case of CONNECT Requests, the client MAY start sending application 1498 data as soon as possible, as long as doing so does not incur the risk 1499 of breaking the SOCKS protocol. 1501 Clients must work around the authentication phase by doing any of the 1502 following: 1504 o If the Request does not contain an Authentication Method 1505 Advertisement option, the authentication phase is guaranteed not 1506 to happen. In this case, application data MAY be sent immediately 1507 after the Request. 1509 o Application data MAY be sent immediately after receiving an 1510 Authentication Reply indicating success. 1512 o When performing a method-specific authentication sequence, 1513 application data MAY be sent immediately after the last client 1514 message. 1516 12. DNS provided by SOCKS 1518 Clients may require information typically obtained from DNS servers, 1519 albeit from the proxy's vantage point. 1521 While the CONNECT command can work with domain names, some clients' 1522 workflows require that addresses be resolved as a separate step prior 1523 to connecting. Moreover, the SOCKS Datagram Header, as described in 1524 Section 7.3, can be reduced in size by providing the resolved 1525 destination IP address, rather than the FQDN. 1527 Emerging techniques may also make use of DNS to deliver server- 1528 specific information to clients. For example, Encrypted SNI 1529 [I-D.ietf-tls-esni] relies on DNS to publish encryption keys. 1531 Proxy implementations MAY provide a default plaintext DNS service. A 1532 client looking to make use of it issues a CONNECT Request to IP 1533 address 0.0.0.0 or 0:0:0:0:0:0:0:0 on port 53. Following successful 1534 authentication, the Operation Reply indicates an unspecified bind 1535 address (0.0.0.0 or ::) and port (0). The client and proxy then 1536 behave as per [RFC7766]. 1538 The service itself can be provided directly by the proxy daemon, or 1539 by proxying the client's request to a pre-configured DNS server. 1541 If the proxy does not implement such functionality, it MAY return an 1542 error code signalling "Connection refused". 1544 13. Security Considerations 1546 13.1. Large requests 1548 Given the format of the request message, a malicious client could 1549 craft a request that is in excess of 16 KB and proxies could be prone 1550 to DDoS attacks. 1552 To mitigate such attacks, proxy implementations SHOULD be able to 1553 incrementally parse the requests. Proxies MAY close the connection 1554 to the client if: 1556 o the request is not fully received after a certain timeout, or 1558 o the number of options or their size exceeds an imposed hard cap. 1560 13.2. Replay attacks 1562 In TLS 1.3, early data (which is likely to contain a full SOCKS 1563 request) is prone to replay attacks. 1565 While Token Expenditure options can be used to mitigate replay 1566 attacks, anything prior to the initial Token Request is still 1567 vulnerable. As such, client implementations SHOULD NOT make use of 1568 TLS early data unless the Request attempts to spend a token. 1570 13.3. Resource exhaustion 1572 Malicious clients can issue a large number of Session Requests, 1573 forcing the proxy to keep large amounts of state. 1575 To mitigate this, the proxy MAY implement policies restricting the 1576 number of concurrent sessions on a per-IP or per-user basis, or 1577 barring unauthenticated clients from establishing sessions. 1579 14. IANA Considerations 1581 This document requests that IANA allocate 2-byte option kinds for 1582 SOCKS 6 options. Further, this document requests the following 1583 option kinds: 1585 o Unassigned: 0 1587 o Stack: 1 1589 o Authentication Method Advertisement: 2 1591 o Authentication Method Selection: 3 1593 o Authentication Data: 4 1595 o Session Request: 5 1597 o Session ID: 6 1599 o Session Untrusted: 7 1600 o Session OK: 8 1602 o Session Invalid: 9 1604 o Session Teardown: 10 1606 o Idempotence Request: 11 1608 o Idempotence Window: 12 1610 o Idempotence Expenditure: 13 1612 o Idempotence Accepted: 14 1614 o Idempotence Rejected: 15 1616 o Resolution Request: 16 1618 o IPv4 Resolution: 17 1620 o IPv6 Resolution: 18 1622 o Vendor-specific: 64512-0xFFFF 1624 This document also requests that IANA allocate a TCP and UDP port for 1625 SOCKS over TLS and DTLS, respectively. 1627 15. Acknowledgements 1629 The protocol described in this draft builds upon and is a direct 1630 continuation of SOCKS 5 [RFC1928]. 1632 16. References 1634 16.1. Normative References 1636 [RFC1929] Leech, M., "Username/Password Authentication for SOCKS 1637 V5", RFC 1929, DOI 10.17487/RFC1929, March 1996, 1638 . 1640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1641 Requirement Levels", BCP 14, RFC 2119, 1642 DOI 10.17487/RFC2119, March 1997, 1643 . 1645 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1646 D. Wessels, "DNS Transport over TCP - Implementation 1647 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1648 . 1650 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1651 Better Connectivity Using Concurrency", RFC 8305, 1652 DOI 10.17487/RFC8305, December 2017, 1653 . 1655 16.2. Informative References 1657 [I-D.ietf-tls-dtls-connection-id] 1658 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 1659 Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- 1660 id-07 (work in progress), October 2019. 1662 [I-D.ietf-tls-esni] 1663 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 1664 "Encrypted Server Name Indication for TLS 1.3", draft- 1665 ietf-tls-esni-04 (work in progress), July 2019. 1667 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1668 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1669 DOI 10.17487/RFC1928, March 1996, 1670 . 1672 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1673 "TCP Extensions for Multipath Operation with Multiple 1674 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1675 . 1677 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1678 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1679 . 1681 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1682 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1683 . 1685 Authors' Addresses 1686 Vladimir Olteanu 1687 University Politehnica of Bucharest 1688 313 Splaiul Independentei, Sector 6 1689 Bucharest 1690 Romania 1692 Email: vladimir.olteanu@cs.pub.ro 1694 Dragos Niculescu 1695 University Politehnica of Bucharest 1696 313 Splaiul Independentei, Sector 6 1697 Bucharest 1698 Romania 1700 Email: dragos.niculescu@cs.pub.ro