]> Independent

djvanc@outlook.com

This document is published as a historical record of the SOCKS 4 protocol. The original spec does not have an Abstract, so the Abstract below is added afterwards. This document describes SOCKS version 4, a protocol designed to facilitate TCP proxy services across a network firewall. SOCKS operates at the session layer, providing application users with transparent access to network services on the other side of the firewall. It is application-protocol independent, allowing it to support a wide range of services, including those utilizing encryption, while maintaining minimum processing overhead by simply relaying data after initial access control checks. The protocol defines two primary operations: CONNECT for establishing outbound connections to an application server, and BIND for preparing for and accepting inbound connections initiated by an application server. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction The SOCKS protocol, Version 4 (SOCKSv4), SHALL be used to relay TCP sessions between an application client and an an application server via a SOCKS server, often positioned at a firewall host. The protocol MUST provide transparent access across the firewall for application users. The protocol MUST be application-protocol independent, allowing it to be used for various services, including, but not limited to, telnet, ftp, finger, whois, gopher, and WWW (World Wide Web). The SOCKS server MUST apply access control mechanisms at the beginning of each TCP session. Following successful establishment, the SOCKS server MUST simply relay data between the client and the application server, incurring minimum processing overhead. The protocol inherently supports applications utilizing encryption, as the SOCKS server is not required to interpret the application protocol's payload. Two primary operations are defined: CONNECT and BIND.

Conventions and Terminology 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 when, and only when, they appear in all capitals, as shown here. This specification uses the following terms:

• Client (Application Client): The program requesting a connection to an application server through the SOCKS server.
• SOCKS Server: The host, typically at a firewall, that intermediates the connection between the Client and the Application Server.
• Application Server: The host to which the Client ultimately wishes to connect (e.g., a Telnet daemon, an HTTP server).
• TCP Session: A connection established using the Transmission Control Protocol (TCP). SOCKSv4 only supports TCP sessions.
• DSTIP (Destination IP): The IP address of the Application Server, as specified in the SOCKS request.
• DSTPORT (Destination Port): The port number of the Application Server, as specified in the SOCKS request.
• USERID: A variable-length, NULL-terminated string identifying the client's user on the local system.
• NULL: A byte of all zero bits, used to terminate the USERID field.
• IDENT: A protocol (as described in RFC 1413) used by the SOCKS server to verify the user identity of the client.

CONNECT Operation The client MUST initiate a CONNECT request when it desires to establish an outbound TCP connection to an application server.

CONNECT Request Packet Format The client MUST send a request packet with the following structure: CONNECT Request Packet Format

Field	Description	Size (bytes)
VN	Version Number	1
CD	Command Code	1
DSTPORT	Destination Port	2
DSTIP	Destination IP Address	4
USERID	User ID	variable
NULL	Null Terminator	1

• VN (Version Number): MUST be 4, representing the SOCKS protocol version.
• CD (Command Code): MUST be 1, indicating a CONNECT request.
• DSTPORT (Destination Port): The port number of the application server (network byte order).
• DSTIP (Destination IP): The IP address of the application server (network byte order).
• USERID (User Identifier): A string of characters representing the client's user ID.
• NULL: A single byte with a value of all zero bits, terminating the USERID field.

CONNECT Processing and Reply The SOCKS server MUST determine whether to grant the request based on criteria such as the source IP address, DSTIP, DSTPORT, USERID, and information obtained via IDENT (cf. RFC 1413). If the request is granted, the SOCKS server MUST attempt to establish a TCP connection to the specified DSTPORT on the DSTIP. A reply packet MUST be sent to the client upon the establishment of the connection, rejection of the request, or operational failure.

CONNECT Reply Packet Format The SOCKS server MUST send a reply packet with the following structure: CONNECT Reply Packet Format

Field	Description	Size (bytes)
VN	Version Number	1
CD	Command Code	1
DSTPORT	Destination Port	2
DSTIP	Destination IP Address	4

• VN: MUST be 0, representing the reply version code.
• CD (Result Code): The SOCKS server MUST use one of the following values:

Result Codes

Reply Code	Description
90	Request granted (Connection successful).
91	Request rejected or failed.
92	Request rejected due to inability to connect to identd on the client.
93	Request rejected because the client program and identd report different user-IDs.

• DSTPORT and DSTIP: These fields MUST be ignored by the client in a CONNECT reply.

If the request is rejected or failed (CD != 90), the SOCKS server MUST close its connection to the client immediately after sending the reply. If the request is successful (CD = 90), the SOCKS server MUST immediately begin relaying traffic in both directions between the client connection and the established application server connection. The client MUST then treat its connection to the SOCKS server as if it were a direct connection to the application server.

BIND Operation The client MUST initiate a BIND request when it requires the SOCKS server to prepare for an inbound connection from an application server. This operation is typically used for protocols that involve a secondary data connection originating from the server (e.g., FTP's active mode). A BIND request SHOULD only be sent after a primary connection to the application server has been successfully established using a CONNECT request.

BIND Request Packet Format The client MUST send a request packet identical in format to the CONNECT request: BIND Request Packet Format

Field	Description	Size (bytes)
VN	Version Number (must be 4)	1
CD	Command Code (1 for CONNECT, 2 for BIND)	1
DSTPORT	Destination Port (Network Byte Order)	2
DSTIP	Destination IP Address	4
USERID	User ID (String of Octets)	variable
NULL	Null Terminator (0x00)	1

• VN: MUST be 4.
• CD: MUST be 2, indicating a BIND request.
• DSTPORT: The port number of the primary connection to the application server.
• DSTIP: The IP address of the application server.
• USERID and NULL: As defined for the CONNECT request.

BIND First Reply (Socket Assignment) The SOCKS server MUST first decide whether to grant the BIND request. The reply format MUST be the same as the CONNECT reply format. If the request is rejected (CD != 90), the SOCKS server MUST close its connection to the client immediately. If the request is granted (CD = 90): 1. The SOCKS server MUST obtain a local socket and begin listening for an incoming connection. 2. The SOCKS server MUST send a first reply packet where the DSTPORT and DSTIP fields are meaningful:     - DSTPORT MUST contain the port number of the newly listening socket (network byte order).     - DSTIP MUST contain the IP address of the SOCKS server's listening interface (network byte order). 3.  If the SOCKS server returns a DSTIP of 0 (the value of constant 'INADDR_ANY'), the client MUST replace this value with the IP address of the SOCKS server to which the client is currently connected. 4.  The client MUST use this IP address and port to inform the application server via the primary connection, enabling the application server to initiate the anticipated inbound connection to the SOCKS server.

BIND Second Reply (Connection Established) The SOCKS server MUST send a second reply packet to the client once the anticipated inbound connection from the application server is established. The reply format MUST be the same as the first reply. The SOCKS server MUST check the IP address of the newly connected application server host against the DSTIP value specified in the client's original BIND request.

• If the IP addresses match: The CD field in the second reply MUST be set to 90. The SOCKS server MUST then prepare to relay traffic between the client connection and the new application server connection.
• If a mismatch is found: The CD field in the second reply MUST be set to 91. The SOCKS server MUST immediately close both the client connection and the connection from the application server.

Upon a successful second reply, the client MUST perform I/O on its connection to the SOCKS server as if it were directly connected to the application server.

Timeout Mechanism For both CONNECT and BIND operations, the SOCKS server MUST employ a time limit for the establishment of its connection with the application server (e.g., 2 minutes). If the connection is not established before the time limit expires, the SOCKS server MUST close its connection to the client and abort the operation.

Security Considerations See .

IANA Considerations This document describes the SOCKS Version 4 protocol, which is presented as a historical record. This protocol does not define any new protocol fields, codes, or registries that require assignment by the Internet Assigned Numbers Authority (IANA). The existing values used within the protocol are summarized below:

SOCKS Protocol Version Number (VN)

• The SOCKS protocol version number VN in requests is 4 (0x04).
• The SOCKS protocol version number VN in replies is 0 (0x00).

SOCKS Command Code (CD) The SOCKS command code CD in requests defines two values:

• 1 (0x01): CONNECT
• 2 (0x02): BIND

SOCKS Reply Code (CD) The SOCKS reply code CD in replies defines four values:

• 90 (0x5A): Request granted
• 91 (0x5B): Request rejected or failed
• 92 (0x5C): Request rejected because SOCKS server cannot connect to identd on the client
• 93 (0x5D): Request rejected because the client program and identd report different user-ids

Port Number The SOCKS protocol is conventionally known to use TCP port 1080 for its service. This port number has already been registered in the IANA Service Name and Transport Protocol Port Number Registry for the socks service.

References Normative References The Identification Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. [STANDARDS-TRACK] NEC Systems Laboratory, CSTC n.d. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK] The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK]

Security Analysis The SOCKS Version 4 (SOCKSv4) protocol, designed for TCP proxy traversal of network firewalls, operates exclusively at the session layer and inherently lacks robust security mechanisms. Its deployment and operational policy must be rigorously evaluated against the deficiencies outlined herein.

Authentication and Authorization Deficiencies

Weak Client Identification Mechanism The SOCKSv4 request format incorporates a USERID field. This field is designated for rudimentary client identification, typically intended for conjunction with the IDENT protocol (specified in [RFC 1413]).

• Ident Protocol Vulnerability: Reliance on IDENT constitutes a significant security risk. The IDENT protocol operates via an untrusted daemon resident on the client host, rendering the identification process susceptible to trivial spoofing or malicious disabling.
• Absence of Strong Authentication: SOCKSv4 lacks integrated provisions for strong client-to-server or server-to-client authentication. This includes the absence of any mechanism for verifying user credentials, such as passwords, or employing cryptographic challenge-response methods.

Policy-Dependent Authorization Access control (authorization) for SOCKSv4 services is exclusively managed by the local configuration and security policy of the SOCKS server implementation. A failure in the server's configuration or a weakness in its policy can directly result in unauthorized network access across the protective boundary of the firewall.

Data Integrity and Transport Limitations

Absence of Confidentiality (Plaintext Relay) SOCKSv4 functions as a session layer relay and does not incorporate any encryption capabilities for the application data stream. All application traffic traversing the SOCKS proxy is forwarded in plaintext. This inherent vulnerability exposes all transmitted data to passive network eavesdropping and interception.

Protocol Scope Restriction The SOCKSv4 protocol is strictly confined to the proxying of Transmission Control Protocol (TCP) connections. It provides no native support for the relay of User Datagram Protocol (UDP) traffic or other protocols operating at the IP layer.

Vulnerabilities Associated with the BIND Operation The BIND command, utilized to establish a socket for an anticipated inbound connection (a callback) from an application server, introduces distinct security challenges.

Source Address Verification Bypass The SOCKS server attempts a rudimentary security check during the BIND operation by comparing the source IP address of the incoming connection with the target address (DSTIP) specified in the client's request.

• IP Address Spoofing Risk: A malicious actor could potentially forge the source IP address of the inbound connection, thereby bypassing this basic server check and facilitating the establishment of an unauthorized session.
• NAT/PAT Incompatibility: In network topologies employing Network Address Translation (NAT) or Port Address Translation (PAT), the source IP address is structurally altered. This modification renders the BIND source address verification mechanism unreliable, ineffectual, or operationally complex to maintain.

Denial of Service (DoS) Vector

Resource Exhaustion Potential Each successful SOCKS connection consumes finite server resources, including active sockets, allocated memory, and network bandwidth. A malicious client can exploit this by initiating a large volume of connection attempts—particularly through the resource-intensive BIND operation—to rapidly exhaust the SOCKS server's capacity. This constitutes a direct vector for a Denial of Service attack against legitimate users.

Inadequate Mitigations Although the protocol specifies a basic connection establishment timeout mechanism (2 minutes), this measure is insufficient in scope and rigor to fully mitigate the risks associated with sophisticated DoS attacks.

Recommended Mitigation and Deployment Practices Given the security deficiencies of SOCKSv4, deployment should be guided by the following principles:

1. Strict Operational Environment: SOCKSv4 is only recommended for use in environments designated as highly trusted and subject to stringent local policy control*.
2. Layered Security via Encrypted Tunnels: Where SOCKSv4 must transport sensitive application traffic, the protocol must be encapsulated within an existing secure transport layer, such as a Transport Layer Security (TLS/SSL) or IPsec tunnel, to establish confidentiality and integrity.
3. Protocol Migration: Operators should actively plan for the migration to or substitution with a more secure protocol version, specifically SOCKS Version 5 ([RFC 1928]), which incorporates native, robust authentication methods.

Original Auther We sincerely apologize that, due to the document's long history and the passage of time, many early contributors may not have been formally included in this list. We extend our deepest gratitude to all who have contributed to this work. If you believe your name should be added to the acknowledgments, please contact the draft maintainers.