idnits 2.17.1 draft-intarea-olteanu-socks-6-00.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 (June 28, 2017) is 2487 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 -- 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: December 30, 2017 June 28, 2017 7 SOCKS Protocol Version 6 8 draft-intarea-olteanu-socks-6-00 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 http://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 December 30, 2017. 39 Copyright Notice 41 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 58 3. Mode of operation . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Connection Requests . . . . . . . . . . . . . . . . . . . . . 5 60 5. SOCKS Options . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.1. Authentication options . . . . . . . . . . . . . . . . . 7 62 6. Authentication Replies . . . . . . . . . . . . . . . . . . . 8 63 7. Operation Replies . . . . . . . . . . . . . . . . . . . . . . 9 64 7.1. Handling CONNECT . . . . . . . . . . . . . . . . . . . . 10 65 7.2. Handling BIND . . . . . . . . . . . . . . . . . . . . . . 10 66 7.3. Handling UDP ASSOCIATE . . . . . . . . . . . . . . . . . 11 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 11.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 Versions 4 and 5 [RFC1928] of the SOCKS protocol were developed two 78 decades ago and are in widespread use for circuit level gateways or 79 as circumvention tools, and enjoy wide support and usage from various 80 software, such as web browsers, SSH clients, and proxifiers. 81 However, their design needs an update in order to take advantage of 82 the new features of transport protocols, such as TCP Fast Open 83 [RFC7413], or to better assist newer transport protocols, such as 84 MPTCP [RFC6824]. 86 One of the main issues faced by SOCKS version 5 is that, when taking 87 into account the TCP handshake, method negotiation, authentication, 88 connection request and grant, it may take up to 5 RTTs for a data 89 exchange to take place at the application layer. This is especially 90 costly in networks with a large delay at the access layer, such as 91 3G, 4G, or satelite. 93 The desire to reduce the number of RTTs manifests itself in the 94 design of newer security protocols. TLS version 1.3 95 [I-D.ietf-tls-tls13] defines a zero round trip (0-RTT) handshake mode 96 for connections if the client and server had previously communicated. 98 TCP Fast Open [RFC7413] is a TCP option that allows TCP to send data 99 in the SYN and receive a response in the first ACK, and aims at 100 obtaining a data response in one RTT. The SOCKS protocol needs to 101 concern itself with at least two TFO deployment scenarios: First, 102 when TFO is available end-to-end (at the client, at the proxy, and at 103 the server); second, when TFO is active between the client and the 104 proxy, but not at the server. 106 This document describes the SOCKS protocol version 6. The key 107 improvements over SOCKS version 5 are: 109 o The client sends as much information upfront as possible, and does 110 not wait for the authentication process to conclude before 111 requesting the creation of a socket. 113 o The connection request also mimics the semantics of TCP Fast Open 114 [RFC7413]. As part of the connection request, the client can 115 supply the payload for the initial SYN that is sent out to the 116 server. 118 o The protocol can be extended via options without breaking 119 backward-compatibility. 121 o The protocol can leverage the aforementioned options to support 122 0-RTT authentication schemes. 124 2. Requirements language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. Mode of operation 131 CLIENT PROXY 133 +------------------------+ 134 | Authentication methods | Request 135 --------> Command code +------------------------------> 136 | TFO | 137 | Address | 138 | Port | 139 | Options | 140 | Initial data | 141 +------------------------+ 143 +-----------------------+ 144 Authentication reply | Type | 145 <----------------------------------+ Method <----- 146 | Options | 147 +-----------------------+ 149 <-------------------(Authentication protocol)------------------> 151 +-----------------------+ 152 Operation reply | Reply code | 153 <--------------------+ Bind address <------------------ 154 | Bind port | 155 | Options | 156 | Initial data offset | 157 +-----------------------+ 159 Figure 1: The SOCKS version 6 protocol message exchange 161 When a TCP-based client wishes to establish a connection to a server, 162 it must open a TCP connection to the appropriate SOCKS port on the 163 SOCKS proxy. The client then enters a negotiation phase, by sending 164 the request in figure Figure 1, that contains, in addition to fields 165 present in SOCKS 5 [RFC1928], fields that facilitate low RTT usage 166 and faster authentication negotiation. 168 Next, the server sends an authentication reply. If the request did 169 not contain the necessary authentication information, the proxy 170 indicates an authentication method that must proceed. This may 171 trigger a longer authentication sequence that could include tokens 172 for ulterior faster authentications. The part labeled 173 "Authentication protocol" is specific to the authentication method 174 employed and is not expected to be employed for every connection 175 between a client and its proxy server. The authentication protocol 176 typically takes up 1 RTT or more. 178 If the authentication is successful, an operation reply is generated 179 by the proxy. It indicates whether the proxy was successful in 180 creating the requested socket or not. 182 In the fast case, when authentication is properly set up, the proxy 183 attempts to create the socket immediately after the receipt of the 184 request, thus achieving an operational conection in one RTT (provided 185 TFO functionality is available at the client, proxy, and server). 187 4. Connection Requests 189 The client starts by sending a request to the proxy. 191 +---------------+-----------+----------+ 192 | Version | Number of | Methods | 193 | Major | Minor | Methods | | 194 +-------+-------+-----------+----------+ 195 | 1 | 1 | 1 | Variable | 196 +-------+-------+-----------+----------+ 197 +---------+-----+---------+----------+------+ 198 | Command | TFO | Address | Address | Port | 199 | Code | | Type | | | 200 +---------+-----+---------+----------+------+ 201 | 1 | 1 | 1 | Variable | 2 | 202 +---------+-----+---------+----------+------+ 203 +-----------+----------+--------------+--------------+ 204 | Number of | Options | Initial Data | Initial Data | 205 | Options | | Size | | 206 +-----------+----------+--------------+--------------+ 207 | 1 | Variable | 2 | Variable | 208 +-----------+----------+--------------+--------------+ 210 Figure 2: SOCKS 6 Request 212 o Version: The major byte MUST be set to 0x06, and the minor byte 213 MUST be set to 0x00. 215 o Number of Methods: The number of supported authentication methods 216 that the client wishes to advertise. 218 o Methods: One byte per advertised method. Method numbers are 219 assigned by IANA. 221 o Command Code: 223 * 0x00 AUTH: authenticate the client and do nothing. 225 * 0x01 CONNECT: requests the establishment of a TCP connection. 227 * 0x02 BIND: requests the establishment of a TCP port binding. 229 * 0x03 UDP ASSOCIATE: requests a UDP port association. 231 o TFO: 233 * 0x00 indicates that the proxy MUST NOT attempt to use TFO in 234 case of a CONNECT command, or accept TFO in case of a BIND 235 command. In case of an AUTH or UDP ASSOCIATE command, this 236 field MUST be set to 0x00. 238 * 0x01 indicates that the proxy SHOULD attempt to use TFO in case 239 of a CONNECT command, or accept TFO in case of a BIND command. 241 o Address Type: 243 * 0x01: IPv4 245 * 0x03: Domain Name 247 * 0x04: IPv6 249 o Address: this field's format depends on the address type: 251 * IPv4: a 4-byte IPv4 address 253 * Domain Name: one byte that contains the length of the FQDN, 254 followed by the FQDN itself. The string is not NUL-terminated. 256 * IPv6: a 16-byte IPv6 address 258 o Port: the port in network byte order. 260 o Number of Options: the number of SOCKS options that appear in the 261 Options field. 263 o Options: see section Section 5. 265 o Initial Data Size: A two-byte number in network byte order. In 266 case of AUTH, BIND or UDP ASSOCIATE, this field MUST be set to 0. 267 In case of CONNECT, this is the number of bytes of initial data 268 that are supplied in the following field. 270 o Initial Data: The first octets of the data stream. 272 Clients MUST support the "No authentication required" method. 273 Clients MAY omit advertising the "No authentication required" option. 275 Clients SHOULD NOT issue AUTH commands unless they advertise 276 authentication methods with support for 0-RTT authentication. 278 The server MAY truncate the initial data to an arbitrary size and 279 disregard the rest. 281 5. SOCKS Options 283 SOCKS options have the following format: 285 +---------------+-------------+ 286 | Kind | Length | Option Data | 287 +------+--------+-------------+ 288 | 1 | 1 | Variable | 289 +------+--------+-------------+ 291 Figure 3: SOCKS 6 Option 293 o Kind: MUST be allocated by IANA. (See section Section 9.) 295 o Length: The length of the option data. 297 o Option Data: the contents are specific to each option kind. 299 5.1. Authentication options 301 Authentication options have the following format: 303 +---------------+--------+---------------------+ 304 | Kind | Length | Method | Authentication Data | 305 +------+--------+--------+---------------------+ 306 | 1 | 1 | 1 | Variable | 307 +------+--------+--------+---------------------+ 309 Figure 4: Authentication Option 311 o Kind: MUST be allocated by IANA. (See section Section 9.) 313 o Length: the length of the option data. 315 o Method: the number of the authentication method. These numbers 316 are assigned by IANA. 318 o Authentication Data: the contents are specific to each method. 320 All proxy implementations MUST support authentication method options. 321 Clients MAY omit advertising authentication methods for which they 322 have included at least an authentication option. 324 6. Authentication Replies 326 Upon receipt of a request, the proxy sends an Authentication Reply: 328 +---------------+------+--------+-----------+----------+ 329 | Version | Type | Method | Number of | Options | 330 | Major | Minor | | | Options | | 331 +-------+-------+------+--------+-----------+----------+ 332 | 1 | 1 | 1 | 1 | 1 | Variable | 333 +-------+-------+------+--------+-----------+----------+ 335 Figure 5: SOCKS 6 Authentication Reply 337 o Version: The major byte MUST be set to 0x06, and the minor byte 338 MUST be set to 0x00. 340 o Type: 342 * 0x00: authentication successful. 344 * 0x01: further authentication needed. 346 o Method: The chosen authentication method. 348 o Number of Options: the number of SOCKS options that appear in the 349 Options field. 351 o Options: see section Section 5. 353 Multihomed clients SHOULD cache the chosen method on a per-interface 354 basis and SHOULD NOT include authentication options related to any 355 other methods in further requests originating from the same 356 interface. 358 If the server signals that further authentication is needed and 359 selects "No Acceptable Methods", the client MUST close the 360 connection. 362 The client and proxy begin a method-specific negotiation. During 363 such negotiations, the proxy MAY supply information that allows the 364 client to authenticate a future request using an authentication 365 option. Descriptions of such negotiations are beyond the scope of 366 this memo. 368 If the cliend issued an AUTH command, the client MUST close the 369 connection after the negociation is complete. 371 7. Operation Replies 373 After the authentication negotiations are complete, the server sends 374 an Operation Reply: 376 +---------------+-------+---------+----------+------+ 377 | Version | Reply | Address | Bind | Bind | 378 | Major | Minor | Code | Type | Address | Port | 379 +-------+-------+-------+---------+----------+------+ 380 | 1 | 1 | 1 | 1 | Variable | 2 | 381 +-------+-------+-------+---------+----------+------+ 382 +-----------+----------+--------------+ 383 | Number of | Options | Initial Data | 384 | Options | | Offset | 385 +-----------+----------+--------------+ 386 | 1 | Variable | 2 | 387 +-----------+----------+--------------+ 389 Figure 6: SOCKS 6 Operation Reply 391 o Version: The major byte MUST be set to 0x06, and the minor byte 392 MUST be set to 0x00. 394 o Reply Code: 396 * 0x00: Succes 398 * 0x01: General SOCKS server failure 400 * 0x02: Connection not allowed by ruleset 402 * 0x03: Network unreachable 404 * 0x04: Host unreachable 406 * 0x05: Connection refused 408 * 0x06: TTL expired 410 * 0x07: Command not supported 411 * 0x08: Address type not supported 413 o Address Type: 415 * 0x01: IPv4 417 * 0x03: Domain Name 419 * 0x04: IPv6 421 o Bind Address: the proxy bound address in the following format: 423 * IPv4: a 4-byte IPv4 address 425 * Domain Name: one byte that contains the length of the FQDN, 426 followed by the FQDN itself. The string is not NUL-terminated. 428 * IPv6: a 16-byte IPv6 address 430 o Bind Port: the proxy bound port in network byte order. 432 o Number of Options: the number of SOCKS options that appear in the 433 Options field. 435 o Options: see section Section 5 437 o Initial Data Offset: A two-byte number in network byte order. In 438 case of BIND or UDP ASSOCIATE, this field MUST be set to 0. In 439 case of CONNECT, it represents the offset in the plain data stream 440 from which the client is expected to continue sending data. 442 If the proxy returns a reply code other than "Success", the client 443 MUST close the connection. 445 7.1. Handling CONNECT 447 In case the client has issued a CONNECT request, data can now pass. 448 The client MUST resume the data stream at the offset indicated by the 449 Initial Data Offset field. 451 7.2. Handling BIND 453 In case the client has issued a BIND request, it must wait for a 454 second Operation reply from the proxy, which signifies that a host 455 has connected to the bound port. The Bind Address and Bind Port 456 fields contain the address and port of the connecting host. 457 Afterwards, application data may pass. 459 7.3. Handling UDP ASSOCIATE 461 The relay of UDP packets is handled exactly as in SOCKS 5 [RFC1928]. 463 8. Security Considerations 465 Given the format of the request message, a malicious client could 466 craft a request that is in excess of 100 KB and proxies could be 467 prone to DDoS attacks. 469 To mitigate such attacks, proxy implementations SHOULD be able to 470 incrementally parse the requests. Proxies MAY close the connection 471 to the client if: 473 o the request is not fully received after a certain timeout, or 475 o the number of options exceeds an imposed hard cap, or 477 o the total size of the options exceeds an imposed hard cap, or 479 o the size of the initial data excedes a hard cap. 481 Further, the server MAY choose not to buffer any initial data beyond 482 what would fit in a TFO SYN's payload. 484 9. IANA Considerations 486 This document requests that IANA allocate option codes for SOCKS 6 487 options. Further, this document requests an option code for 488 authentication options. 490 10. Acknowledgements 492 The protocol described in this draft builds upon and is a direct 493 continuation of SOCKS 5 [RFC1928]. 495 11. References 497 11.1. Normative References 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, 501 DOI 10.17487/RFC2119, March 1997, 502 . 504 11.2. Informative References 506 [I-D.ietf-tls-tls13] 507 Rescorla, E., "The Transport Layer Security (TLS) Protocol 508 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 509 April 2017. 511 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 512 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 513 DOI 10.17487/RFC1928, March 1996, 514 . 516 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 517 "TCP Extensions for Multipath Operation with Multiple 518 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 519 . 521 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 522 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 523 . 525 Authors' Addresses 527 Vladimir Olteanu 528 University Politehnica of Bucharest 530 Email: vladimir.olteanu@cs.pub.ro 532 Dragos Niculescu 533 University Politehnica of Bucharest 535 Email: dragos.niculescu@cs.pub.ro