New enhancements to the SOCKS communication network security protocol: Schemes and performance evaluation

Abstract

In this paper we propose two new enhancements to the SOCKS protocol in the areas of IP multicasting and UDP tunneling. Most network firewalls deployed at the entrance to a private network block multicast traffic. This is because of potential security threats inherent with IP multicast. Multicasting is the backbone of many Internet technologies like voice and video conferencing, real time gaming, multimedia streaming, and online stock quotes, among others. There is a need to be able to safely and securely allow multicast streams to enter into and leave a protected enterprise network. Securing multicast streams is challenging. It poses many architectural issues. The SOCKS protocol is typically implemented in a network firewall as an application-layer gateway. Our first enhancement in the area of IP multicast to the SOCKS protocol is to enable the application of security and access control policies and safely allow multicast traffic to enter into the boundaries of a protected enterprise network. The second enhancement we propose is to allow the establishment of a tunnel between two protected networks that have SOCKS based firewalls to transport UDP datagrams.

Introduction

SOCKS is a network security protocol commonly deployed in enterprise firewalls for facilitating secure traversal of application-layer protocols across the boundaries of a private network. It is an Internet standard documented in RFC 1928 (Leech et al., 1928) as SOCKS Version 5.

Multicasting is an enabler of group communications. A group can represent a set of people or a community interested in sending and receiving data about a specific topic. Communications within the group follows a many-to-many model with many sources and many recipients. The conventional unicast TCP/IP model of communication does not scale well when applied to such group communications, because it is not practical and feasible to have a separate channel of communication between a sender and every recipient in the group.

In multicasting, end points join and leave a group and group membership information is shared between the multicast enabled routers in the Internet. The Internet Group Management Protocol Version 3 (IGMP v3) (Cain et al., 2002) is used in the IP v4 scheme for hosts to join and leave groups. It is also used by multicast routers to exchange and share group information with other multicast routers. The Multicast Listener Discovery Protocol Version 2 (MLD v2) (Vida and Costa, 2004) is the equivalent of IGMP used in the IP v6 (Deering and Hinden, 1998) scheme. MLD v2 supports all the features in IP v6 that are supported by IGMP v3 in IP v4 networks.

While multicasting as a technology evolved, a lot of new applications were developed that took advantage of its bandwidth conserving nature. A case in point is video conferencing over the Internet. Multicast enabled video end points can join a group hosted by a central controller. This controller can perform the job of host and a media gateway for the conference. As a host controller, it can invite end points to participate in the conference. It can allow video from only one end point at a time to be multicast to the other end points in the conference. It can receive video from the sending end point and multicast it to the participants that have joined the conference. Participants can join or leave the conference independent of each other. An online training session is another example of the use of multicasting. One host can be the sender and can stream the training material via IP multicast to a dynamic group of recipients. Such a stream could be an audio only, audio and video or an audio, video and whiteboard session. Many other applications of multicast, like mechanisms for secure software delivery (Han and Shahmehri, 2000) also exist.

Security is a key concern in multicast communications (Quinn and Almeroth, 2001). As the number of applications of IP multicasting is increasing, it is important to ensure security and confidentiality in such communications. Most enterprise networks do not allow multicast traffic to enter into the network because it is challenging to authenticate the sender of the multicast and to ensure the integrity of the data being multicast. Ballardie and Crowcroft (Ballardie and Crowcroft, 1995) discuss the security threats inherent in multicasting. A mechanism is needed where access control policies can be applied and multicast streams from the public Internet can be relayed into the Intranet for legitimate business purposes without compromising the security of the enterprise. We show in this paper an extension to the SOCKS protocol, which has no support for multicasting to achieve this goal.

Network firewalls also block UDP (Postel, 1980) traffic for various reasons. UDP is a transport protocol which does not lend itself to be easily secured like its TCP counterpart. There is a good reason for this. It was designed to be a connectionless datagram delivery service which does not offer any delivery guarantees. However the nature of UDP has made it suitable for transporting voice and real time media on the Internet.

There can be situations where UDP datagrams from an end point in one network need to be transported to another end point in another network. The two networks are protected and could share a relationship of the kind where one belongs to the vendor of a product and the other belongs to a customer for that product. The product could report errors as SNMP traps to the vendor for pro-active monitoring and troubleshooting. It is important to be able to securely transport the trap from the customer’s network to the vendor’s network even if the firewalls protecting both networks block UDP. Moreover it may be important to allow only such UDP datagrams to be transported that originate from legitimate and authenticated end points. We show in this paper a second extension to the SOCKS protocol to achieve this goal.