A SOCKS Transparent Proxy Method
draft-lucioni-a-socks-transparent-proxy-method-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | G. Lucioni | ||
| Last updated | 2024-02-25 (Latest revision 2024-02-02) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lucioni-a-socks-transparent-proxy-method-00
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,
<https://www.rfc-editor.org/info/rfc1928>.
Lucioni Expires 5 August 2024 [Page 7]
Internet-Draft Abbreviated Title February 2024
[SOCKMAP] Majkowski, M., "SOCKMAP - TCP splicing of the future",
February 2019, <https://blog.cloudflare.com/sockmap-tcp-
splicing-of-the-future/>.
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
RFC 1919, DOI 10.17487/RFC1919, March 1996,
<https://www.rfc-editor.org/info/rfc1919>.
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[PORTS] Internet Assigned Numbers Authority (IANA), "Protocol
Numbers",
<http://www.iana.org/assignments/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]