(RFC1928) SOCKS V5

Status of this memo:

This document describes an Internet-Community Internet standard tracking protocol that requires further discussion and recommendations for improvement. Please refer to the latest edition of the Internet Official Protocol standard (STD1) to obtain the standardization and status of this agreement. The publication of this MOU is not subject to any restrictions.

Knowledge background

This memo describes a protocol developed from a previous version of the same agreement (version 4[1]). This new protocol originates from some of the current discussions and implementations of the prototype (active discussions and prototype implementations). Key contributors are: Marcus Leech:bell-northern, David koblas:independent consultant, Ying-da Lee:nec Systems-Laboratory, L Amont Jones:hewlett-packard Company, Ron kuris:unify Corporation, Matt ganis:international Business machines.

Directory

1. Introduce

2. The existing agreement

3. Customers based on TCP protocol

4. Request

5. Address

6. Response

7. Customers based on the UDP protocol

8. Security Considerations

9. Bibliography

1. Introduce

Using a network firewall can effectively isolate the network structure within an organization from an external network such as the Internet, which is becoming popular in many network systems. This firewall system usually works in the form of application-layer gateways between the two networks, providing access to Telnet, FTP, SMTP, and so on. As more and more complex application layer protocols are available to make global information easier to find, it is necessary to provide a common framework that allows these protocols to pass through firewalls securely and transparently. And in the practical application also needs a kind of security authentication way to pass through the firewall. This requirement originates from the emergence of client/server relationships in two organizations ' networks, which need to be controlled and require secure authentication.

The protocol framework described here is designed to make it easier and safer for client/server applications that use TCP and UDP to use the services provided by the network firewall. The protocol is conceptually a "mediation layer" between the application layer and the transport layer, and does not provide the services provided by a network-tier gateway, such as Shim-layer ICMP information.

2. The existing agreement

There is currently a protocol socks 4, which provides an insecure firewall for client/server programs based on TCP protocols such as Telnet, FTP, HTTP, WAIS, and Gopher. The new protocol extends the socks V4 to support UDP, the framework-mandated security certification scheme, the domain name and IPV6 defined in the Address resolution scheme (addressing scheme). In order to implement this socks protocol, it is often necessary to recompile or relink a TCP based client application to use the corresponding cryptographic function in the socks library.

Attention:

Unless otherwise noted, all decimal digits appearing in the packet format graph represent the length of the corresponding field in bytes. If a field needs to be given a byte value, use X ' hh ' to represent the value in that byte. If the word ' Variable ' is used in a field, this indicates that the length of the field is variable, and that the length is defined in a domain that is associated with this domain (1–2 bytes), or in a data type field.

3. Customers based on TCP protocol

When a client based on a TCP protocol wants to establish a connection with a target that can only be reached through the firewall (which is determined by the implementation), it must first establish a TCP connection to the socks port on the SOCKS server. Typically this TCP port is 1080. When the connection is established, the client enters the "handshake (negotiation)" process of the protocol: the choice of authentication mode, authentication according to the chosen way, and then send forward request. The SOCKS server checks this requirement, depending on the result, or establishes the appropriate connection, or rejects it.

Unless otherwise noted, all decimal digits appearing in the packet format graph represent the length of the corresponding field in bytes. If a field needs to be given a byte value, use X ' hh ' to represent the value in that byte. If the word ' Variable ' is used in a field, this indicates that the length of the field is variable, and that the length is defined in a domain that is associated with this domain (1–2 bytes), or in a data type field.

After the client connects to the server, it then sends a request to negotiate the version and authentication methods:

VER	Nmethods	METHODS
1	1	1 to 255

In this version of the SOCKS protocol, the Ver field is set to X ' 05 '. The Nmethods field contains the number of method marks (in bytes) that appear in the methods field.

The server selects one of these given methods and sends a message back to the client with the selected method:

VER	Method
1	1