3.4 Circuit-level gateways

The SOCKS protocol used between the socksified client (i.e., the client using the SOCKS library routines) and the SOCKS server basically consists of the following two commands:

• The CONNECT command takes as arguments the IP address and port number of the server, as well as a username. It basically requests that the SOCKS server establishes a TCP connection to the given IP address and port number.

• The BIND command takes as arguments the client IP address and a username. It is used only in protocols that require the client to accept connections back from the server. As we saw previously, FTP is an example of such a protocol (since it requires the client to accept a data connection from the server).

In either case, the username is a string passed from the requesting client to the SOCKS server for the purposes of authentication, authorization, and accounting.

After having received a request (i.e., a CONNECT or BIND command), the SOCKS server evaluates the information provided by the client. The evaluation is performed against a sockd configuration file that may include a ruleset. Each rule in the set either permits or denies communications with one or several systems. In either case, the SOCKS server sends a reply back to the client. Among other things, the reply includes information indicating whether the request was successful. Once the requested second connection is established, the SOCKS server simply relays data back and forth between the client and the server (without looking into or interpreting the data stream).

The original SOCKS implementation was refined into a SOCKS package and a protocol that is widely deployed and commonly referred to as SOCKS Protocol version 4, or SOCKS V4. After the successful deployment of SOCKS V4, the IETF chartered an Authenticated Firewall Traversal (AFT) WG to ˜ ˜start with the SOCKS system described in [14], and to ˜ ˜specify a protocol to address the issue of application-layer support for firewall traversal in 1994. ^[12] The major result of the IETF AFT WG was the specification of the SOCKS protocol version 5 (SOCKS V5) in March 1996 [15]. ^[13] As such, SOCKS V5 has been submitted to the Internet standards track as a proposed standard. It is possible and very likely that the protocol will become an Internet Standard.

As compared with SOCKS V4, SOCKS V5 provides some additional features. These features are related to user authentication, communication security, UDP support, and extended addressing schemes:

• In SOCKS V4, user authentication is relatively simple and straightforward. It basically consists of a username that is sent from the socksified client to the SOCKS server as part of the CONNECT or BIND method. In addition to this simple authentication scheme, SOCKS V5 supports a handshake between the client and the SOCKS server for authentication method negotiation. The first message is sent by the client to the SOCKS server. It declares the authentication methods the client is currently able to support. The second message is sent from the SOCKS server back to the client. It selects a particular authentication method according to the SOCKS server s security policy. If none of the methods declared by the client meet the security requirements of the SOCKS server, communications are dropped. After the authentication method has been negotiated, the client and SOCKS server start the authentication process using the chosen method. Two authentication methods are specified in corresponding RFC documents: password-based authentication in [16] and Kerberos V5 GSS-API authentication in [17]. The approach for use of GSS-API in SOCKS V5 is to authenticate the client and server by successfully establishing a security context. This context can then be used to protect messages that are subsequently exchanged. Prior to use of GSS-API primitives, the client and server should be locally authenticated and have established default GSS-API credentials.

• Depending on the underlying authentication methods implemented via GSS-API, a client can negotiate with the SOCKS server about the security of subsequent messages. In the case of Kerberos V5, either integrity and/or confidentiality services are provided for the rest of messages, including the client s requests, the SOCKS server s replies, and all application data. Note that this feature is particularly well suited for use by reverse proxy servers, because it supports data encryption between clients (on the Internet) and the SOCKS server.

• SOCKS V4 is only able to handle TCP applications. Unfortunately, an increasingly large number of TCP/IP applications are making use of UDP (e.g., applications that make use of real-time and/or multicast communications). Against this background, the SOCKS protocol has been extended to additionally provide support for UDP. More specifically, a new method, called UDP ASSOCIATE, has been added to the SOCKS V5 protocol specification [15]. The UDP ASSOCIATE request sent from the client to the SOCKS server is used to establish an association within the UDP relay process to handle UDP datagrams. According to this association, the SOCKS server relays UDP datagrams to the requesting client. Obviously, this approach is conceptually similar to stateful inspection or dynamic packet filtering as discussed above. The UDP association terminates when the TCP connection that the UDP ASSOCIATE request arrived on terminates. As a result, the SOCKS V5 library can now be used to socksify both TCP- and UDP-based applications.

• Finally, SOCKS V5 supports DNS names and IP version 6 addresses in addition to normal IP version 4 addresses.

Because of their fundamental differences, the SOCKS V5 protocol specification does not require any provision for supporting the SOCKS V4 protocol. However, it is a simple matter of implementation to enable SOCKS V5 servers to communicate with V5 and V4 clients. In fact, most SOCKS V5 servers that are available today provide backward compatibility.

In summary, a circuit-level gateway (e.g., a SOCKS server) provides an interesting technology and possibility to have applications and application protocols securely traverse a firewall. A clear advantage of circuit-level gateways is their generality, meaning that a circuit-level gateway can act as a proxy server for any application (not just one). Circuit-level gateways are particularly useful for applications for which application-level gateways (i.e., proxy servers) do not exist or are conceptually hard to design and implement. For example, an application protocol that is hard to deal with (using packet-filtering technologies and application-level gateways) is the Internet Inter-ORB Protocol (IIOP) that is used in environments and applications that conform to the Common Object Request Broker Architecture (CORBA). The difficulty stems from the fact that the IIOP makes use of UDP and dynamically assigned port numbers . Against this background, a group of vendors have jointly specified the use of SOCKS V5 to have IIOP communications securely traverse a firewall. ^[14] This is a technology that we will likely see deployed in the future. The generality of circuit-level gateways, however, also comes with some disadvantages. For example, a SOCKS server is not able to scan application data for specific commands or executable content (e.g., Java applets or ActiveX controls). Consequently, if a configuration must be optimized for maximum security, the use of application-level gateways is still the preferred option.

^[9] This statement is not completely true, as contemporary circuit-level gateways also are able to handle UDP-based application protocols. This will be explained later in this chapter.

^[10] Note that the only difference between a circuit-level gateway and a simple port forwarding mechanism is that with a circuit-level gateway, the client must be aware of the intermediate system, whereas in the case of a simple port-forwarding mechanism, the client need not be aware and may be completely oblivious of the existence of the intermediary. Also, a circuit-level gateway is generic, and any TCP connection can be handled by the same gateway (if enabled in its configuration). Contrary to that, a port-forwarding mechanism is usually specific to a given service, meaning that all qualifying TCP segments are forwarded to a specific port of a server.

^[11] http://www.socks.nec.com

^[12] http://www.ietf.org/html. charters /aft-charter.html