MINISTERIO DE SALUD

The SOCKS Protocol Version 5 [LGL+_{96] defines a protocol which allows nodes on}

a private network or domain to establish communication with nodes from another network or domain, e.g., the Internet. Therefore, a so called SOCKS Server is located on the network border, which relays the communication sessions of the SOCKS Clients up on their request.

When a SOCKS client wants to establish a TCP session with a node from the Internet, it sends a connection request to the SOCKS server. The request specifies the direction of the TCP session to be established and whether the SOCKS server has to act as the initiator or responder for this session. The SOCKS server responses to the request and informs the SOCKS client about the external IP address and port number which will be used for the TCP session. The SOCKS server now forwards traffic between the private and public TCP sessions, as long as either of them is terminated. UDP sessions are also initialised to the SOCKS server via a TCP session. The SOCKS client reaches the IP address and the UDP port number of the UDP relay server. The SOCKS server now forwards datagrams between the private and the public network. The SOCKS client adds an additional SOCKS header to every packet, which carries the IP address and UDP port of the receiver in the public network. The SOCKS server also adds this

SOCKS header when forwarding datagrams to the SOCKS client. Figure 4.1 shows a

SOCKS connection scenario.

Client A (Enhanced) FW/NAT _Internet Web Proxy SOCKSv5 Webserver B SOCKS Request: http Webserver B

Figure 4.1: A SOCKS Connection Scenario

SOCKS supports both IPv4 and IPv6 as well as a SOCKS-based IPv6/IPv4 gateway mechanism [Kit01] which allows translation between IPv6 and IPv4 nodes. However, SOCKS is not applicable for generic server applications as only one passive TCP session per request is allowed. Additionally, the conveyance of IP header parameters is not defined with the exception of IP addresses.

4.3 Application Layer Gateway

Applications must typically be modified to support SOCKS. Nevertheless, SOCKS is widely spread and many implementations for clients and servers are available, espe-

cially for Hypertext Transfer Protocol (HTTP) [FGM+99] and File Transfer Protocol

(FTP) [PR85]. Furthermore, manual pre-configuration on the SOCKS client is re- quired, as the SOCKS server address must be provided before. This significant limits or even circumvents the applicability of SOCKS in mobile environments.

4.3 Application Layer Gateway

Application Layer Gateways (ALGs) [SH99] are application specific agents that are aware of the protocols details of a specific protocol, e.g., Session Initiation Protocol

(SIP) [RSC+_{02] for VoIP, and are able to understand the protocol messages and their}

dependencies within the communication. Thus, they are able to allow applications in different networks and domains behind middleboxes to connect each other transpar- ently. An ALG processes the application traffic while transit and assists the middlebox in implementing its function. Therefore, the ALG performs a deep packet-inspection of packets and comprehends the application protocol which are supported, e.g., SIP for VoIP. The work of the ALG is transparent to end-hosts and does not terminate or influence sessions between the end-hosts.

The ALG interacts with a middlebox to set up middlebox state, firewall pinholes or access control filters or uses the middlebox state information. The ALG may modify application specific payload, for instance the application signaling to change private IP addresses to public IP addresses or the ports used by signaling and media traffic. The ALG also performs whatever else necessary to allow the application specific traffic to traverse the middlebox.

The application layer gateway technique requires the replacement of the existing mid- dlebox with an ALG, but ALGs may also be co-resided with middleboxes. Many vendors provide software updates for their middleboxes to support ALG functionality for specific applications.

So, ALG may operate inside routers along with the firewall and NAT components; however, middlebox and ALG are not the same. ALG performs the application specific payload and notify the middlebox to open specific firewall pinholes or to add additional state information. The ALG functionality is application specific and requires the examination and the re-composition of network- or above-layers payload, whereas middleboxes usually only operate on the network- or above-layers header.

The complexity of ALGs depends on the application level knowledge required to pro- cess the payload and maintain or manipulate states. Ideally, the ALGs should be simple and not require excessive computation or state storage. Depending on the protocol, an ALG may be difficult or easy to implement. However, in some cases it may not be possible at all, e.g., when the payload is encrypted and is opaque to the

ALGs. Call Agent Client A _(Enhanced) FW/NAT Internet SIP aware ALG Client B Signaling Media Data

Figure 4.2: Application Layer Gateway Scenario

Nowadays, ALGs are often used for VoIP signaling to traverse firewalls and NATs. The ALG investigate the payload of for example SIP messages which arrive at the middlebox and either translates the IP address and port or analyses the packets and

opens required firewall pinholes. Figure 4.2 depicts such an Application Layer Gate-

way scenario.

However, when several middleboxes exist in the data path, each of them needs to be updated to achieve middlebox traversal. This would slow down the deployment of ALGs for new protocols or restrict the early support to large cooperated networks. Another disadvantage of this approach is that the ALG performance may become the bottleneck of the middlebox under heavy load.