Translator: Radeon (Radeon [email protected])
Publication date: 2001-6-18 Folder 1. Introduction
2. The existing agreement
3. TCP protocol-based customers
4. Request
5. Address
6. Response
7. Clients based on UDP protocol
8. Security Considerations
9. Bibliography of references 1. Introduction
Using a network firewall to effectively isolate the network structure within an organization from an external network, such as the Internet, is becoming popular in many network systems. Such a firewall system typically works in the form of an application-level gateway between two networks, providing access to Telnet, FTP, SMTP, and so on. As more and more complex application-layer protocols make global information lookups easier, it is necessary to provide a common framework for making these protocols safe and transparent across firewalls. And in practical applications, a secure authentication method is required to cross the firewall. This requirement originates from the presence of customer/server relationships in the network of two organizations, which need to be controlled and require secure authentication.
The protocol framework described here is designed to make it easier and safer for customers using TCP and UDP to/server applications using the services provided by the network firewall. This protocol is conceptually a "mediation layer (Shim-layer)" between the application layer and the transport layer, and therefore does not provide the services provided by the network layer gateway, such as transmitting 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. This new protocol extends the socks V4 to support UDP, the framework-mandated security authentication 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 compile again or link TCP-based client applications again to use the corresponding cryptographic functions in the SOCKS library.
Attention:
Unless otherwise noted, all the decimal digits in the packet format graph now represent the length of the corresponding field in bytes. Suppose a field needs to be given a byte value, and X ' HH ' represents the value in that byte. Suppose that the word ' Variable ' is used in a field, which means that the length of the field is variable, and that the length is defined in a field associated with the field (1–2 bytes), or in a data type field.
3. TCP protocol-based customers
When a TCP-based client wants to establish a connection with a target that can only be reached by a firewall (which is determined by the implementation), it must first establish a TCP connection to the Socksport on the socksserver. Usually this tcpport is 1080. When the connection is established, the client enters the "handshake (negotiation)" process of the protocol: the choice of authentication mode, the authentication according to the selected method, and then sends the forwarding request. Socksserver Check this requirement, depending on the result, or establish the appropriate connection, or reject it.
Unless otherwise noted, all the decimal digits in the packet format graph now represent the length of the corresponding field in bytes. Suppose a field needs to be given a byte value, and X ' HH ' represents the value in that byte. Suppose that the word ' Variable ' is used in a field, which means that the length of the field is variable, and that the length is defined in a field associated with the field (1–2 bytes), or in a data type field.
After the client connects to the server, it then negotiates the version number and authentication method by sending a request:
VER |
Nmethods |
METHODS |
1 |
1 |
1 to 255 |
In this version number of the SOCKS protocol, the Ver field is set to X ' 05 '. The Nmethods field includes the number of method markers (in bytes) that appear in the methods field.
The server selects one of these given methods and sends a method to select the message back to the client:
Suppose the selected message is X ' FF ', which means that none of the methods listed in the client list is selected and the client must close the connection.
The methods currently defined are:
· X ' 00 ' does not require certification
· X ' GSSAPI '
· X ' Username/password '
· X ' in '--X ' 7F ' assigned by IANA
· X ' A '--X ' FE ' is reserved for private methods
· X ' FF ' has no acceptable method
The client and server then enter the sub-negotiation process (sub-negotiation) determined by the selected authentication method. Please refer to the respective memos for descriptive narratives of the sub-negotiation processes of various methods.
The developer assumes that you want to get a method number for your own method and can contact the IANA. Be able to refer to a document that has been assigned a number to get a list of all current methods and the corresponding protocol.
Socks V5 implementations that conform to this document must support GSSAPI and will support Username/password authentication in the future.
4. Request
Once the sub-negotiation process is complete, the client sends a specific request message. It is assumed that the negotiated method has an encapsulation for completeness checking and/or security, which must be encapsulated in the manner defined by the method.
The format of the SOCKS request is as follows:
ver |
cmd |
RSV |
atyp |
DST. ADDR |
DST. PROT |
1 |
1 |
x ' xx ' |
1 |
variable |
2 |
Of
· VER Protocol version number: X ' 05 '
· Cmd
· Connect:x ' 01 '
· Bind:x ' 02 '
· UDP associate:x ' 03 '
· RSV Retention
· Type of address after Atyp
· Ipv4:x ' 01 '
· Domain Name: X ' 03 '
· Ipv6:x ' 04 '
· Dst. ADDR Destination Address
· Dst. Port number that appears in network byte order
Socksserver parses the request based on the source address and destination address, and then returns one or more responses based on the request type.
5. Address
The Atyp field describes the Address field (DST. Addr,bnd. ADDR) includes the type of address:
· X ' 01 '
IPV4-based IP address, 4 bytes long
· X ' 03 '
Based on the address of the domain name, the first byte in the Address field is the length of the domain name in bytes, with no end of nul bytes.
· X ' 04 '
IPV6-based IP address, 16 bytes long
6. Response
Once a connection to Socksserver has been established and the authentication process is completed, the client will send a SOCKS request message to the server. The server will be returned on request, for example in the following format:
ver |
rep |
RSV |
atyp |
bnd. ADDR |
bnd. PORT |
1 |
1 |
x ' xx ' |
1 |
variable |
2 |
Of
· VER Protocol version number: X ' 05 '
· REP answer field:
· X ' 00 ' success
· X ' 01 ' normal Socksserver request failed
· X ' 02 ' Existing rule does not agree with the connection
· X ' 03 ' Network unreachable
· X ' 04 ' host unreachable
· X ' 05 ' connection denied
· X ' ' TTL timeout
· X ' 07 ' Unsupported command
· X ' 08 ' Unsupported address type
· X ' 09 ' –x ' FF ' not defined
· RSV Retention
· Type of address after Atyp
· Ipv4:x ' 01 '
· Domain Name: X ' 03 '
· Ipv6:x ' 04 '
· BND. ADDR Server-bound address
· BND. Port a server-bound segment in network byte order
The field identified as RSV must be set to X ' 00 '.
Assume that the selected method has an encapsulation for integrity checking and/or security, and that the answers must be encapsulated in the way defined by the method. CONNECT
In the answer to a connect command, BND. Port includes the port number assigned by the server to connect to the target machine, BND. The addr is the corresponding IP address. Because socksserver usually have multiple IPs, the BND.ADDR in the answer is often different from the one that the client connects to Socksserver. Socksserver is able to analyze a connect request using DST.ADDR and Dst.port, as well as the client source address and PORT. BIND
Bind requests are typically used on protocols that require the client to accept connections from the server. FTP is a typical example. It establishes a client-to-server connection to run commands and receive status reports, and uses a connection from server to client to receive data transfer requirements (such as ls,get,put).
It is recommended that only the client in an application protocol be able to use the bind command to establish a second connection after using the Connect command to establish a primary connection. It is recommended that socksserver use DST.ADDR and dst.port to evaluate bind requests.
During the operation of a bind request, Socksserver sends two replies to the client. The first answer is sent when the server establishes and binds a new socket interface. BND. The port field includes the port number Socksserver used to listen for incoming connections, BAND. The addr field includes the corresponding IP address. The client typically uses this information to tell (through a primary or control connection) that the server connection's sink point is applied. The second answer occurs only after the expected incoming connection succeeds or fails. In a second answer, BND. The port and BND.ADDR fields include the IP address and port number of the host you are connecting to. UDP ASSOCIATE
UDP associate requests generally require the establishment of a UDP forwarding process to control incoming UDP datagrams. Dst. The addr and Dst.port fields include the IP address and PORT number that the client wants to use to send UDP datagrams. The server is able to use this information to restrict incoming connections. Assuming that the client does not have an address and port information when sending this request, the client must be populated with full zeros.
When the TCP connection to UDP is interrupted, the UDP connection must also be interrupted.
BND when answering a UDP associate request. The port and BND.ADDR fields indicate the port and address of the client sending the UDP message to the server. Response Processing
When an answer (rep value not equal to 00) indicates an error, Socksserver must terminate the TCP connection within a short period of time after the reply message is sent. This time period should be less than 10 seconds after the error is found.
If an answer (rep value equals 00) indicates success, and the request is a bind or connect, the client can start sending the data. It is assumed that the negotiated authentication methods are encapsulated for completeness, authentication, and/or security purposes, and these requests must be encapsulated in the manner defined by the method. Similarly, when data destined for a client arrives at Socksserver, Socksserver must encapsulate the data in the way it is being used.
7. Clients based on UDP protocol
In the UDP associate response, the Bnd.port indicates the udpport used by the server, and a UDP-based client must send datagrams to the port of the UDP forwarding server. It is assumed that the negotiated authentication method is encapsulated for completeness, authentication, and/or security purposes, which must be encapsulated in the manner defined by the method. Each UDP datagram has a UDP request header at its head:
Rsv |
FRAG |
Atyp |
Dst. ADDR |
Dst. PORT |
DATA |
2 |
1 |
1 |
Variable |
2 |
Variable |
The fields in the UDP request header are: · RSV reserved X ' 0000 '
· FRAG the current segment number
· Type of address after Atyp
· Ipv4:x ' 01 '
· Domain Name: X ' 03 '
· Ipv6:x ' 04 '
· Dst. ADDR Destination Address
· Dst. Port number that appears in network byte order
· Data user Information
When a UDP forwarding server forwards a UDP datagram, it does not send any notifications to the client, and the same, it will discard datagrams regardless of what it cannot send to the remote host. When UDP forwarding server receives a response from the remote server, it must add the above UDP request header and encapsulate the datagram.
The UDP forwarding server must obtain the desired ClientIP address from socksserver and send the datagram to the port number given in the UDP associate answer. If the datagram comes from any IP address, and the IP address is different than the IP address specified in that particular connection, the datagram is discarded.
The Frag field indicates whether the datagram is a slice of some shards. Assuming that Socksserver is to implement this function, X ' 00 ' indicates that the datagram is independent, and the other is larger, the more the end of the datagram. A value between 1 and 127 indicates the location of the Shard in the Shard sequence. Each recipient provides a reorganization queue and a reorganized timer for these shards. The reorganization queue must initialize again after the reassembly timer expires and discard the corresponding datagram. Or when a newly arrived datagram has an hour than the largest Frag value currently in the datagram sequence that is being processed, it must be initialized again from the teaming column. The reassembly timer must be less than 5 seconds. It is only possible that the application should not use shards.
The implementation of the Shard is optional, and if an implementation does not support sharding, all datagrams with a frag field of not 0 must be discarded.
A SOCKS UDP programming interface (the programming interface for a socks-aware UDP) must report that the current available UDP datagram cache space is less than the actual space provided by the operating system.
· Suppose Atyp is X ' s '-10+method_dependent octets smaller
· Suppose Atyp is x ' 262+method_dependent '-octets smaller
· Suppose Atyp is X ' s-20+method_dependent octets smaller 8. Security Considerations
This document describes an application-layer protocol used to pass IP network firewalls. The security of such transmissions depends to a large extent on the specific implementation-owned and the special authentication and encapsulation methods selected by the SOCKS customer and socksserver.
System administrators need to carefully consider the choice of user authentication methods. Author address
Marcus Leech
Bell-northern LTD
P.O. Box 3511, Station C
Ottawa, ON
CANADA k1y 4h7
Phone: (613) 763-9145
Email: [Email protected] |
