Ten Myths About Socks
Socks is a proxy protocol originally designed to allow client machines on a corporate network to access pub-lic networks like the Internet, without allowing any outside access to the corporate network. In a typical setup, Socks clients go through a Socks server from behind a firewall to connect to an application server on the Internet. The Socks server relays data between the clients and the application server. From the application server's point of view, the Socks server is the client.
That's a thumbnail sketch of Socks from a technical perspective. From a market perspective, Socks may be the most misunderstood protocol in existence. Its popularity is rising, so a lot of people are hearing about it or seriously considering using it for the first time. Unfortunately, when people think of Socks, they're likely to think of the more widely deployed version 4 (Socks v4), rather than the newer version 5 (Socks v5) which offers much more functionality and easier deployment.
Confusion also stems from the way Socks is evolving. Rather than being implemented as a stand-alone product, it is increasingly being used to add value to other security-oriented products, such as firewalls, proxy servers, or virtual private network (VPN) products. Thus, different users may think of Socks as a firewall, proxy, or VPN product. In a sense, they are all right. Socks is an enabling technology that has found uses in all of these areas.
Another area of misunderstanding has to do with the relationship between Socks and other security protocols, such as Internet protocol security (IPSEC) from the Internet Engineering Task Force (IETF), Microsoft's point-to-point tunneling protocol (PPTP), Cisco's Layer Two forwarding (L2F), and the IETF's Layer 2 tunneling protocol (L2TP). Some see areas of overlap or competition between these security protocols and Socks, and project a battle to the death, with Socks losing. In reality, Socks is experiencing its greatest growth ever, even as these other security protocols gain in popularity. Competition and overlap do not have to portend a struggle to the death. Sometimes protocols can learn to get along.
1. Socks is hard to deploy.
Reality: "Socksifying" version 4 clients was a tedious job that required programming skills and access to source code. This is not the case for Socks v5. Socks v5 clients can be socksified by installing a dynamic link library (DLL) (for Windows) or shared client libraries (for Unix), a job that an end user can do in a few minutes.
2. It lacks strong authentication.
Reality: While Socks v4 doesn't provide authentication, Socks v5 does.
3. Socks is a redundant firewall technology.
Reality: Socks-based products and firewalls may offer competitive functionality, such as packet filtering, proxy services, encryption, VPNs, and tunneling. In some applications, a stand-alone Socks server can function as a simple, easy-to-deploy firewall. On the other hand, most organizations that use Socks also have conventional firewalls. There are many possible reasons for an organization to find Socks valuable: the organization's firewalls may not offer features that the Socks-based product provides, such as strong user-level authentication or immediate and equal support for all applications. The firewalls may already be overloaded. The Socks solution may be less expensive or easier to deploy. Sometimes, Socks is the only protocol that works well with equipment (including firewalls) from a number of different vendors. In that scenario, Socks' advantage is integrated, single-point administration. Neither firewalls nor Socks-based products provide the perfect solution to every problem. Sometimes, they do compete. In many instances, however, they complement one another.
4. Application gateways make Socks inessential.
Reality: This is actually a subset of the previous myth. Application gateways act as proxies for specific applications. Socks can address any remaining applications. For instance, an application gateway is unlikely to support applications developed in-house. Even for commercial applications, there may be a significant lag between the release of an application or a new version of that application, and support in the application gateway. Socks can fill in the gaps.
5. IPSEC makes Socks obsolete.
Reality: As with the "Socks is a firewall" idea, there is a grain of truth here. IPSEC provides encryption, and encryption is one of Socks' functions. Furthermore, Socks-based products do compete with IPSEC-based ones, particularly in the areas of VPNs and extranets. However, "IPSEC makes Socks obsolete" is not a full summary of what's going on for two reasons. First, IPSEC is still years away from widespread deployment and is unlikely to provide real competition for Socks for some time to come. Even when interoperability issues have been worked out, IPSEC will still be held back by the necessity of overhauling the entire network infrastructure to provide end-to-end support for IPSEC. Such an overhaul is not likely to happen quickly in most organizations. Second, Socks may provide significant value in IPSEC environments. For instance, organizations may find it cost-effective to run IPSEC on backbones but not on desktops
Furthermore, Socks can also provide a number of capabilities that IPSEC is unable to provide. For example:
Socks provides ongoing access control through access control lists (ACLs), and user policies that limit the services users can access. IPSEC does not offer user-level authentication, nor is it aware of different services, so IPSEC can't offer this type of ongoing access control. Socks may also be able to ease the burden of managing IP addresses in IPSEC environments. For instance, IPSEC requires predefined IP addresses. Socks can supplement this function with dynamic addressing. In situations where addresses on an internal corporate network are not registered for use on the Internet, IPSEC can't provide network address translation (NAT) to convert those addresses into legal Internet addresses, because IPSEC requires direct endpoint-to-endpoint addressability. Socks, on the other hand, hides internal network addresses. Only the Socks server must have a legal Internet address.
Socks version 6 (Socks v6) will also be able to turn off its own authentication and encryption when it detects IPSEC authentication and encryption in use. Thus, Socks will fit smoothly and transparently into IPSEC environments, while adding value to those environments. One likely application of Socks v6 is as a gateway between IPSEC and non-IPSEC environments. Because Socks can connect to a destination based on the host name and not just the IP address, connected networks can use overlapping IP addresses without causing problems.
6. Socks is only implemented as a protocol.
Reality: The term "Socks" can be used to mean the Socks protocol, which is just a protocol - an abstract set of rules for communicating between clients and servers. More often, though, when people say "Socks," they are referring to a particular implementation of the Socks protocol. Many Socks products do provide a framework and a platform for services.
7. Socks competes with PPTP, L2F, and L2TP.
Reality: Microsoft's PPTP, Cisco's L2F, or the IETF's L2TP are designed strictly for tunneling and VPNs. Socks goes well beyond that. Yes, there is some competition here. However, the relationship can just as easily be complementary. One indication that even Microsoft sees uses for both Socks and PPTP: the company supports Socks in its Proxy Server and in its Internet Explorer.
8. It can't handle streaming applications or UDP.
Reality: This is another version-4-versus-version-5 myth. Socks v5 is specifically designed to accommodate streaming applications and the user data protocol (UDP) on which the applications are typically based.
9. Socks is slow.
Reality: Three questions: on which platform? In comparison to what? How does this impact overall end-to-end performance? Socks products are software-based. Performance varies greatly with the platform. That said, Socks servers are often faster than application proxy firewalls, and competitive with other software-based firewalls. However Socks servers are slower than hardware-based packet filters, routers, firewalls or encryption devices. Finally, functions such as access control and authorization, whether based on Socks or anything else, are going to cause a per-user or per-request delay. For the great majority of WAN applications (including Internet applications), network bandwidth is the main factor limiting overall end-to-end performance. In these applications, Socks doesn't usually slow things down.
10. I still don't need Socks.
Reality: If an organization is managing tunneling, encryption, authentication, key management, firewalls, and proxy servers through different interfaces with different capabilities, management costs may still make a Socks-based solution attractive. Socks can offer unified, centralized policy management and border control. That is why vendors like Hewlett-Packard, who offer solutions in all these of areas, are also offering Socks-based products to provide a central point for defining, deploying, enforcing, monitoring, and auditing policies, as well as for functions such as load balancing.
Wei Lu is the director of NEC USA's networking systems laboratory. He holds a PhD in electrical engineering from Texas A&M, and can be contacted at wlu@syl.dl.nec.com
E-mail: 
