10.4 CONCLUSIONS

Team-Fly

Application-level gateways and proxy servers provide a sophisticated and advanced technology to secure TCP-based applications and application protocols for the Internet. There are advantages and disadvantages that should be kept in mind when discussing the suitability of application-level gateways and proxy servers:

The advantages are related to user authentication and authorization, application protocol control, logging, and accounting. We have discussed user authentication and authorization, as well as application protocol control in Section 10.2. In regard to the other points, it is important to note that an application gateway always acts as an intermediate that can handle logging and accounting in a simple and straightforward way.
The major disadvantages are related to the following points:
- A proxy server must be built specifically for each application protocol. In other words, if a firewall hosts proxy servers for Telnet and FTP, then only Telnet and FTP traffic is allowed into and out of the protected area of the intranet, and all other services must be blocked. In many cases, this degree of security is important, as it guarantees that only those services that are considered trustworthy are actually allowed through the firewall. It also prevents other untrusted services from being implemented behind the backs of the firewall administrator. This fact may severely limit the usefulness and deployment of new applications.
- Application gateways (i.e., circuit-level and application-level gateways) are notoriously bad at handling UDP-based application protocols.
- Finally, note that to code and set up a proxy server, one must at least know the application protocol. This is not always the case, because proprietary application protocols are in widespread use today (e.g., Lotus Notes, SQLnet, and SAP). If an application protocol specification is not available it is generally not possible to implement a proxy server.^[5] Consequently, proprietary application protocols are inherently difficult to be handled with application-level gateways and proxy servers.

Against this background (i.e., the second disadvantage), an interesting field of study refers to the secure handling of multicast traffic. Note that multicast traffic, as deployed on the Multicast Backbone (MBone), is based on UDP as a transport layer protocol. MBone holds great potential for many organizations because it supports low-cost audio- and video-conferencing and carries live broadcasts of an increasing number of public interest events. MBone conferences are transmitted by way of unauthenticated multicast traffic, which unfortunately conveys significant security vulnerabilities to any system that receives them. For this reason, most application gateways block MBone traffic sent from the Internet and prevent it from reaching internal hosts. It is not until recently that firewall vendors have begun to address the UDP and multicast challenge. For example, in 1999, Trusted Information Systems, Inc., extended its set of proxy servers for the FWTK version 2.0 with a set of facilities that can be used to participate in MBone conferencing [8]. The basic idea is to have proxy servers running on the firewall that forward inbound multicast traffic using unicast addressing on the corporate intranet. Obviously, this approach is appropriate for individual users participating in MBone conferencing. However, this approach is not very efficient and may run into scalability problems if too many users on the corporate intranet want to participate in multicast sessions. In this case, the efficiency advantages of multicast routing are entirely lost.

Now that the basic components of a firewall configuration (i.e., packet filters and application gateways) have been introduced and examined, we can combine them to provide some higher levels of security and flexibility than if either were used alone. In Chapter 11 we provide some examples of firewall configurations to give a more concrete and comprehensive understanding of the firewall technology as a whole.

^[5]It would still be possible, if the application protocol were reverse-engineered.

Team-Fly