Internet Engineering Task Force G. Lucioni, Ed. Internet-Draft Volkswagen Infotainment GmbH Intended status: Informational 2 February 2024 Expires: 5 August 2024 A SOCKS Transparent Proxy Method draft-lucioni-a-socks-transparent-proxy-method-00 Abstract This document describes a backwards-compatible extension of the SOCKS version 5 protocol to include a transparent proxy type method. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 August 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Lucioni Expires 5 August 2024 [Page 1] Internet-Draft Abbreviated Title February 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. System Overview . . . . . . . . . . . . . . . . . . . . . . . 3 3. Extensions to the TCP-based Control Path . . . . . . . . . . 4 3.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Replies . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Procedure for the PTCL-based Data Path . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Informative References . . . . . . . . . . . . . . . . . 7 7.2. Normative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction SOCKS V5 describes a protocol that provides a framework for client- server applications in both the TCP and UDP domains to conveniently and securely use the services of a network firewall [RFC1928]. However, SOCKS V5-based TCP proxies and UDP relay servers consume valuable platform resources because they spend most of their time processing data packets back and forth between connections. Various solutions have been proposed or studied to improve this situation, see e.g. [SOCKMAP]. In networking, a transparent proxy is often described as a system that appears like a packet filter or router to clients and a classic proxy to servers [RFC1919]. In SOCKS V5, the concept for UDP comes closest to this for the data path. This draft RFC proposes to add a transparent proxy type method to the SOCKS V5 protocol, which can help reduce the processing load along the data path compared to current methods. The proposed method is not exclusive to TCP, but can be applied to other transport protocols as well. In particular, the new method eliminates the need for a socksification of UDP datagrams, as defined in SOCKS V5. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Lucioni Expires 5 August 2024 [Page 2] Internet-Draft Abbreviated Title February 2024 2. System Overview The proposed transparent proxy type method is a backwards-compatible extension of the SOCKS V5 protocol. Similar to the SOCKS V5 procedure for UDP ASSOCIATE, the new method distinguishes between a control path and a data path. The control path includes exchange of messages between a SOCKS client and a SOCKS server (N1) and between the SOCKS server and an associated PTCL relay proxy (N2). The SOCKS server can handle data path connections for different types of transport layer protocols (e.g. TCP or UDP). At least one associated PTCL relay proxy is then available for each supported protocol type. +--------------+ +--------------+ +-------------+ | | | | | PTCL | | SOCKS Client +----N1----+ SOCKS Server +----N2----+ Relay Proxy | | | | | | | +--------------+ +--------------+ +-------------+ Figure 1: Control Path N1 is TCP-based and uses the SOCKS procedures specified in [RFC1928], including authentication. The SOCKS server is usually accessible on TCP port 1080. N1 is extended here to support the TRANSPARENT association method. N2 is an internal interface that may use IPC/RPC for transport, depending on whether the server and proxy are on the same or different domains. N2 is briefly described where appropriate. The data path covers the transport of PTCL type data packets between a SOCKS client and a target host via a corresponding PTCL relay proxy. +--------------+ +--------------+ +-------------+ | | | PTCL | | | | SOCKS Client +----------+ Relay Proxy +----------+ Target Host | | |SRC BND| | DST| | +--------------+ +--------------+ +-------------+ Figure 2: Data Path Note that SRC and BND addresses/ports must be known in advance on both the SOCKS client and the PTCL relay proxy. The exchange of this information takes place via N1 and N2 in the control path. Lucioni Expires 5 August 2024 [Page 3] Internet-Draft Abbreviated Title February 2024 3. Extensions to the TCP-based Control Path The procedure for TCP-based clients in Section 3 of [RFC1928] is used for the control path part of the transparent proxy method 3.1. Requests The SOCKS request is formed as follows: +---+---+-----+----+--------+--------+----+------+----------+------+ |VER|CMD| RSV |ATYP|DST.ADDR|DST.PORT|PTCL|S.ATYP| S.ADDR |S.PORT| +---+---+-----+----+--------+--------+----+------+----------+------+ | 1 | 1 |X'00'| 1 |Variable| 2 | 1 | 1 | Variable | 2 | +---+---+-----+----+--------+--------+----+------+----------+------+ Table 1: SOCKS V5 Extended Request * VER - SOCKS Version: 5 * CMD - Command Code: - X'01' CONNECT: requests the establishment of a TCP connection. - X'02' BIND: request for a secondary TCP connection that relates to a primary one. - X'03' UDP ASSOCIATE: requests a UDP connection association. - X'04' TRANSPARENT: requests a transparent proxy association. * RSV - Reserved: must be set to X'00' * ATYP - Address Type for the Destination: - X'01': IPv4 - X'03': Domain Name - X'04': IPv6 * DST.ADDR - Destination Address. The format of this field is variable and depends on the address type: - IPv4: a 4-byte IPv4 address - Domain Name: one byte that contains the length of the FQDN, followed by the FQDN itself. Lucioni Expires 5 August 2024 [Page 4] Internet-Draft Abbreviated Title February 2024 - IPv6: a 16-byte IPv6 address * DST.PORT - Destination Port in network byte order (big-endian). The following SOCKS V5 request extensions only apply when CMD = X'04' * PTCL - Assigned Internet protocol number [PORTS] (e.g. TCP X'06', UDP X'11') * S.ATYP - Address Type of the Source: - X'01': IPv4 - X'03': Domain Name - X'04': IPv6 * S.ADDR - Source Address. The format of this field is variable and depends on the address type: - IPv4: a 4-byte IPv4 address - Domain Name: one byte that contains the length of the FQDN, followed by the FQDN itself. - IPv6: a 16-byte IPv6 address * S.PORT - Source Port in network byte order. 3.2. Replies The SOCKS server evaluates the request, and returns a reply formed as follows: +-----+-----+-------+------+----------+----------+ | VER | REP | RSV | ATYP | BND.ADDR | BND.PORT | +-----+-----+-------+------+----------+----------+ | 1 | 1 | X'00' | 1 | Variable | 2 | +-----+-----+-------+------+----------+----------+ Table 2: SOCKS V5 Reply * VER - Version: 5 * REP - Reply Code: - X'00': Succeeded Lucioni Expires 5 August 2024 [Page 5] Internet-Draft Abbreviated Title February 2024 - X'01': General SOCKS server failure - X'02': Connection not allowed by ruleset - X'03': Network unreachable - X'04': Host unreachable - X'05': Connection refused - X'06': TTL expired - X'07': Command not supported - X'08': Address type not supported - X'09': PTCL type not supported - X'0A' to X'FF' unassigned * RSV - Reserved: must be set to X'00' * ATYP - Address Type for the Bound: - X'01': IPv4 - X'03': Domain Name - X'04': IPv6 * BND.ADDR - the Bound Address in the following format: - IPv4: a 4-byte IPv4 address - Domain Name: one byte that contains the length of the FQDN, followed by the FQDN itself. - IPv6: a 16-byte IPv6 address * BND.PORT - the Bound Port in network byte order. 4. Procedure for the PTCL-based Data Path An associated PTCL relay proxy is expected to use the DST.ADDR and DST.PORT as well as the S.ADDR and S.PORT of the TRANSPARENT association request for relay configuration purposes. This information is exchanged via the N2 interface. Lucioni Expires 5 August 2024 [Page 6] Internet-Draft Abbreviated Title February 2024 In the reply to a TRANSPARENT association request, the BND.ADDR and BND.PORT fields indicate the addresses/ports where the SOCKS client MUST send PTCL type data packets to be relayed. A PTCL relay proxy MUST drop any packets arriving from any source address or port other than the one recorded for the particular relay configuration. A PTCL relay proxy SHOULD only accept PTCL type data packets and MAY drop all other packets. A PTCL relay connection MUST terminate when the TCP connection between the SOCKS client and the SOCKS server on which the TRANSPARENT association request was received is terminated. This information is exchanged via the N2 interface. When a PTCL relay connection is terminated, the PTCL relay proxy MUST delete the associated relay configuration. 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations It is RECOMMENDED that the control path between the SOCKS client and the SOCKS server (N1) and between the SOCKS server and the corresponding PTCL relay proxy (N2) is properly secured and encrypted. For the data path, the rules from Section 4 SHALL apply, including the dynamic configuration of the proxy firewall. There it is RECOMMENDED to monitor relayed connections on the proxy, with the goal of removing associated control connections when attacks are detected or specific events occur. Such events can occur, for example, for PTCL = TCP when a FIN is received from the target host. 7. References 7.1. Informative References [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, DOI 10.17487/RFC1928, March 1996, . Lucioni Expires 5 August 2024 [Page 7] Internet-Draft Abbreviated Title February 2024 [SOCKMAP] Majkowski, M., "SOCKMAP - TCP splicing of the future", February 2019, . [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, DOI 10.17487/RFC1919, March 1996, . 7.2. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [PORTS] Internet Assigned Numbers Authority (IANA), "Protocol Numbers", . Author's Address G. Lucioni (editor) Volkswagen Infotainment GmbH Grete-Schickedanz-Strasse 7 44803 Bochum Germany Phone: +49-15222997440 Email: gonzalo.lucioni@volkswagen-infotainment.com Lucioni Expires 5 August 2024 [Page 8]