Protecting a Private
`Network: The AltaVista
`Firewall
`
`Connecting an organization’s private network
`to the Internet offers many advantages but also
`exposes the organization to the threat of an
`electronic break-in. The AltaVista Firewall 97 for
`DIGITAL UNIX protects a private network from
`malicious attack or casual infiltration by screen-
`ing all internetwork communication. It enforces
`the organization’s network security policy so
`that only allowed network traffic can cross the
`firewall. When installed on a dual- or multi-
`homed host, the AltaVista Firewall applies the
`principle “that which is not expressly permitted is
`denied” and uses patented technology to screen
`each IP packet that attempts to cross it. A highly
`flexible access control grammar and a compre-
`hensive reporting and alarm system enable the
`AltaVista Firewall to detect and react to harmful
`or dangerous events. The AltaVista Firewall also
`includes an HTML-based user interface to ease
`configuration and management of the firewall.
`
`J. Mark Smith
`Sean G. Doherty
`Oliver J. Leahy
`Dermot M. Tynan
`
`The advent of electronic commerce as a means of con-
`ducting business globally has resulted in an increasing
`number of organizations connecting their internal
`private networks to the Internet. Most users of the
`Internet and the World Wide Web (WWW) view the
`technologies involved as leading edge, but many are
`unaware that the foundations on which these tech-
`nologies are built are quite old.
`The Transmission Control Protocol and Internet
`Protocol (TCP/IP) were first developed in 1979. The
`primary focus then was to ensure reliable communica-
`tions between groups of networks connected by com-
`puters acting as gateways.1 At that time, security was not
`an issue because the size of this Internet was small and
`most of the users knew each other. The base technolo-
`gies used to construct this network contained many
`insecurities, most of which continue to exist today.2,3
`Due to a number of well-reported attacks on private
`networks originating from the Internet, security is
`now a primary concern when an organization con-
`nects to the Internet.4 Organizations need to conduct
`their business in a secure manner and to protect their
`data and computing resources from attack. Such needs
`are heightened as businesses link geographically dis-
`tant parts of the organization using private networks
`based on TCP/IP.
`An organization implementing a secure network
`must first develop a network security policy that speci-
`fies the organization’s security requirements for their
`Internet connection. A network security policy speci-
`fies what connections are allowed between the private
`and external networks and the actions to take in the
`event of a security breach. A firewall placed between
`the private network and the Internet enforces the
`security policy by controlling what connections can be
`established between the two networks. All network
`traffic must pass through the firewall, which ensures
`that only permitted traffic passes and is itself immune
`to attack and penetration.
`This paper comprises two parts. The first part pro-
`vides an overview of firewalls, describes why an organi-
`zation needs a firewall, and reviews the different types
`of firewalls. The second part focuses on the AltaVista
`Firewall 97 for the DIGITAL UNIX operating system.
`
`Digital Technical Journal
`
`Vol. 9 No. 2 1997
`
`17
`
`Blue Coat Systems - Exhibit 1038 Page 1
`
`

`
`It discusses the product’s requirements and describes
`its architecture. It then describes the important aspects
`of the product’s implementation. Finally, future enhance-
`ments for the AltaVista Firewall are discussed.
`
`Firewall Overview
`
`Any organization that connects to the Internet should
`implement an appropriate mechanism to protect the
`private network against intrusion from the external
`network and to control the traffic that passes between
`the two networks. The mechanism used depends on
`the value of the asset being protected and the impact
`of damage or loss to the business involved. Typical
`reasons for using a firewall to protect a private network
`include the following:
`
`■ To prevent unauthorized external users from access-
`ing computing resources on the internal private
`network. This is necessary because it is extremely
`difficult and costly to attempt to secure all the hosts
`within a private network.
`■ To control internal user access to the external network
`to prevent the export of proprietary information.
`■ To avoid the negative public relations impact of a
`break-in.
`■ To provide a dependable and reliable connection to
`the Internet, so that employees do not implement
`their own insecure private connections.
`
`A firewall is a device or a collection of devices that
`secures the connection between a private, trusted net-
`work and another network. All the traffic between
`these two networks must pass through the firewall;
`this enables the firewall to control the traffic. The fire-
`wall permits only authorized traffic to pass between
`the two networks. The organization’s network secu-
`rity policy defines what traffic is authorized. The fire-
`wall is immune to attack and penetration and provides
`a reliable and dependable connection between the two
`networks. It also provides a single point of presence for
`the organization when, for example, connecting to a
`public network such as the Internet.
`The fundamental role of a firewall is to provide a con-
`trol mechanism for the IP traffic between two connected
`networks. Firewalls provide two types of controls and are
`categorized either as packet-filtering (packet-screening)
`or application-level implementations.
`Packet-filtering or packet-screening firewalls con-
`trol whether individual packets are forwarded or
`denied based on a set of rules.5 These rules specify the
`action to take for packets whose header data matches
`the rule criteria. Typically, a rule specifies source and
`destination IP addresses and ports and the packet type
`(for example, TCP and User Datagram Protocol
`[UDP]). The actions are usually to allow or deny the
`packet. Packet-filtering firewalls provide a basic level of
`
`control over traffic at the IP level. The majority of fire-
`walls of this type are custom-configured routers.
`Application-level firewalls disable packet forwarding
`and provide application gateways (also known as proxies
`or relays) for each protocol that can cross the firewall.
`The application gateway relays traffic that crosses the
`firewall. It can impose protocol-specific and user-
`specific controls on each connection and can record all
`operations performed by the user of the connection.
`This type of gateway therefore allows an organization to
`control (1) which individuals can establish a connection,
`(2) when a user can establish a connection, and (3) what
`operations a user can perform. It also keeps a record
`of the session for tracking and reporting purposes.
`Most application-level firewalls are dual- or multi-
`homed hosts that run a modified operating system and
`special-purpose software to implement the firewall.
`These two approaches to implementing a firewall
`can be compared, using the following criteria:
`
`■ Operating philosophy
`■ Level of control over connections
`■ Level of logging and reporting
`■ Ease of use
`■ Flexibility
`■ Ease of administration and configuration
`■ Private network information made available
`
`Operating Philosophy
`The operating philosophy that a firewall implements is
`the fundamental element of the security of the network
`connection. For maximum security, firewalls must
`apply the principle “that which is not expressly permit-
`ted is denied.” That is, unless the firewall permits a con-
`nection, that connection is not allowed. Many packet
`filters allow any connection that is not expressly pro-
`hibited (screend is an important exception).6,7
`Packet filters are unsuitable for use as a firewall
`because they require the operator to specify carefully
`what traffic is allowed and what is denied. Application-
`level firewalls are specifically designed to implement
`this philosophy, so that each application gateway
`allows only those connections specified by its configu-
`ration and denies all other connections by default.
`
`Level of Control over Connections
`Application-level firewalls allow a significantly greater
`level of control over who can establish a connection and
`what operations can be performed over that con-
`nection. For example, a File Transfer Protocol (FTP)
`application gateway, with the assistance of a user
`authentication system, can identify a user who wishes to
`establish a connection and can control what FTP opera-
`tions that user performs. For example, the gateway can
`permit GET operations and deny PUT operations.
`
`18
`
`Digital Technical Journal
`
`Vol. 9 No. 2 1997
`
`Blue Coat Systems - Exhibit 1038 Page 2
`
`

`
`Packet filters can only support host-level control over
`who can establish a connection, with no restrictions on
`the individuals who can connect and what operations can
`be performed once a connection has been established.
`
`Level of Logging and Reporting
`Typical packet filters provide basic data logging, and
`where there is the ability to log traffic, the information
`available is at the packet level. This makes it difficult to
`identify and track individual connections when many
`take place at the same time. No information is available
`on what operations were performed during a connec-
`tion. Reporting information is limited to counts of
`packets passed and dropped and other relatively use-
`less traffic statistics.
`Application-level firewalls can log data on each con-
`nection. They can identify the individuals who estab-
`lish connections and what operations they perform.
`Reports can then list what connections an individual
`established, what operations were performed, and
`when they were performed. This facilitates monitoring
`and maintaining the security of the installation.
`
`Ease of Use
`Packet filters tend to be easier to use because they are
`effectively transparent for those connections that are
`permitted. Application-level firewalls often require the
`user to connect first to the firewall host, and then to
`their destination on the other network. Recently,
`transparent application gateways have been developed
`to address this issue.
`When support is needed for a new protocol, it is
`much easier to reconfigure a packet filter than to
`develop and distribute a new application gateway. For
`this reason, users behind an application-level firewall
`may become frustrated when they cannot connect to
`the latest Internet developments.
`
`Flexibility
`Flexibility is important for systems integrators con-
`structing custom network security solutions for large
`organizations and for those involved in electronic
`commerce. It is important that the individual firewall
`components can be configured directly.
`
`Ease of Configuration and Administration
`The ease with which an individual can configure and
`administer a firewall is becoming more important as
`firewalls are used in organizations that do not possess
`a high level of technical knowledge. Packet filters are
`essentially simple but often have a complex rule syntax
`that makes the task of correctly configuring a packet
`filter quite difficult. User interfaces could help with
`the task of configuration, but an expert is usually
`needed to set up a packet filter properly, because the
`order of the packet-filtering rules significantly affects
`the security of the installation.
`
`Application-level firewalls suffer the same disadvan-
`tage. The more sophisticated products on the market
`provide comprehensive user interfaces that guide the
`user through the task of configuring the firewall, assist
`in the selection of the appropriate setting for each
`application gateway, and provide comprehensive fire-
`wall management functions.
`
`Private Network Information Made Available
`If information about the private network and the hosts
`that are on it is available to the external network, an
`attacker may be able to use this information to subvert
`the system. Packet filters generally do not hide much
`information from the outside, which increases the risk of
`a break-in. Application-level firewalls usually appear to
`be an end node instead of a router to another network;
`therefore, they can significantly reduce the amount of
`information that is made available to a potential attacker.
`
`AltaVista Firewall Requirements
`
`This section discusses the functional requirements for
`firewalls and reviews the product requirements that
`apply to the AltaVista Firewall.
`
`Functional Requirements
`The major functional requirement of a firewall is that it
`protects a private network from unauthorized external
`access. A firewall itself must be resistant to subversion and
`must also ensure that other, less secure hosts within the
`private network cannot be subverted by an external host.
`A firewall must provide a central location for
`controlling network traffic and for implementing an
`organization’s network security policy for its external
`network connection. Because many Internet-based ser-
`vices are inherently insecure, a firewall must provide an
`organization with the means to disable some services and
`restrict others in accordance with their security policy.
`It is also critical that the firewall logs all network traf-
`fic, so that a record is retained of all connections estab-
`lished between the private and external networks.
`Support for the management and retention of network
`traffic logs is also required to assist tracking of potential
`and actual break-ins and other security-related activity.
`A firewall must be reliable so that users are not
`inconvenienced by sudden losses of connectivity. As
`the Internet becomes another means of conducting
`business, an organization’s firewall must ensure that
`loss of service due to security lapses or other failures is
`minimized. It must also provide a point of presence for
`an organization on the Internet.
`A firewall must be easy to use. Historically, firewall
`administrators were required to have in-depth knowl-
`edge of Internet protocols; they constructed their fire-
`walls manually. Today’s organizations find it difficult
`to obtain the necessary expertise; they require that
`their firewall be easy to configure and manage, with-
`
`Digital Technical Journal
`
`Vol. 9 No. 2 1997
`
`19
`
`Blue Coat Systems - Exhibit 1038 Page 3
`
`

`
`out sacrificing quality of security and service. Users
`also require protection without modifying their usage
`of the Internet. They expect the firewall to protect
`them without obstructing their work. A firewall must
`be as transparent as possible to users establishing con-
`nections between the private and external networks.
`
`Product Requirements
`In addition to firewall products, DIGITAL also offers a
`custom firewall installation service as part of its net-
`work services. The AltaVista Firewall has some of its
`origins in technology developed for systems integra-
`tion engineers constructing custom firewall solutions
`for large customers. These engineers continue to build
`custom solutions using the AltaVista Firewall to pro-
`vide the basic firewall technology. The AltaVista
`Firewall must also be designed to accommodate the
`needs of integrators delivering custom firewalls.
`As described above, there are two types of firewall.
`Typically, filter-based firewalls perform better. Most
`detailed product evaluations compare the perfor-
`mance of the products under review, so the AltaVista
`Firewall must equal or better the performance of its
`leading competitors.
`Most firewalls require that the administrator log on
`to the host at the console—remote logins are not
`enabled for security reasons. However, as organiza-
`tions centralize their network management opera-
`tions, a key requirement for the AltaVista Firewall is to
`provide secure remote management functionality.
`The AltaVista Firewall must itself be secure, and
`the host it is installed on must also be secure. It is
`a product requirement that, while being installed, the
`product secures the operating system against attack.
`
`AltaVista Firewall Architecture
`
`This section describes the constraints that applied to the
`design of the AltaVista Firewall. It then introduces the
`major product components and summarizes the main
`functions they provide. Then it lists the steps taken to
`establish a connection through an application gateway.
`The following constraints were applied to the
`design of the AltaVista Firewall:
`
`■
`
`In every design decision, the security of the firewall
`must be the primary concern.
`■ The basic installation and use of the firewall must
`be simple and must be guided by a simple user
`interface.
`■ All firewall component functionality must be con-
`figured using text-based configuration files so that
`systems integrators can install custom solutions.
`These files must be consistent across platforms, so
`that the same set of configuration files can be used
`on different platforms to configure heterogeneous
`firewalls.
`
`■ The performance of the firewall is an important
`concern. Application gateways must run as dae-
`mons to improve performance and avoid process
`start-up delays.
`It must be possible for engineers in the field to
`extend the functionality of the AltaVista Firewall
`without requiring code changes to the product.
`
`■
`
`The AltaVista Firewall comprises the following three
`major components:
`
`■ The graphical user interface (GUI) provides the
`functionality for the user to configure and manage
`the firewall and manages the configuration files that
`specify how the firewall will operate.
`■ The application gateways and support daemons
`provide the network security specified by the con-
`figuration files.
`■ The kernel is hardened and modified to provide the
`extra security functionality required for the fire-
`wall’s operation.
`
`The Graphical User Interface
`The GUI is based on a set of hypertext markup lan-
`guage (HTML) template files, computer graphic inter-
`face (CGI) scripts, and an HTML browser. It is
`menu-driven and guides the user through the config-
`uration and management of the firewall. The design of
`the GUI involved many trade-offs between simplicity
`of the UI and access to the firewall functionality. We
`often chose to maintain the simplicity of the UI at the
`expense of functionality for two reasons:
`
`1. We must protect unskilled installers from installing
`the firewall in an insecure manner.
`2. Skilled installers must still have access to the func-
`tionality through the configuration files.
`
`The CGI scripts are written in the C language and use
`a set of HTML templates to generate the GUI pages.
`Few static pages are used, so the firewall can be modi-
`fied in the field to add more application gateways,
`authentication methods, alarms, and alarm actions.
`Because the GUI is HTML-based, it can be ported
`easily to any platform that supports an HTML browser.
`
`The Kernel
`The DIGITAL UNIX kernel has been hardened to
`protect the firewall host and modified to add function-
`ality required by the firewall. The following modifica-
`tions were made to the kernel to improve security and
`to support the operation of the firewall:
`
`■ Two mechanisms have been added for protection
`against routing attacks.
`We added two mechanisms to the kernel to prevent
`attackers from using routing information to launch
`an attack through the firewall. The first mechanism
`
`20
`
`Digital Technical Journal
`
`Vol. 9 No. 2 1997
`
`Blue Coat Systems - Exhibit 1038 Page 4
`
`

`
`■
`
`allows the firewall to be configured to ignore
`requests for it to change its routing tables. These
`requests come in the form of Internet Control
`Message Protocol (ICMP) redirect messages,2 which
`the firewall ignores. The second mechanism allows
`the firewall to be configured to drop all IP packets
`that have source routing options set in the packet
`header. Source routing can force a packet to take a
`specified route through the Internet and is not nor-
`mally used. IP packets with source routing options
`specified are considered to be evidence of an attack,
`so it is valid for the firewall to ignore these packets.8
`Interface access filtering has been implemented to
`prevent IP spoofing.
`Interface access filtering provides a mechanism to
`specify what IP packets are to be accepted on a
`particular network interface. The source address for
`each packet is inspected and compared against a
`filter list. The packet is passed through to the kernel
`or dropped, depending on the corresponding filter
`list action. This provides the ability to prevent
`attackers on the external network from forging IP
`packets so that they appear to come from trusted
`hosts on the private network.8
`Interface trust group support has been imple-
`mented to support packet filtering.
`Trust group support provides a mechanism to spec-
`ify a color for a network interface. When a packet
`arrives on a given interface, the kernel marks the
`packet with the color of the interface. The applica-
`tion gateways and the packet-filtering daemon can
`use this information to apply filtering rules to allow
`or deny the packet.
`■ Transparent proxy support has been implemented
`to support transparent application gateways. Kernel
`support for transparent proxying is described in the
`section on Packet Filtering.
`
`■
`
`The Firewall
`The main functionality of the firewall is provided by
`the application gateways that provide connection ser-
`vices to users on each side of the firewall. A number of
`daemons also implement common services to support
`the operation of the application gateways. These dae-
`mons are described here:
`
`■
`
`■
`
`■
`
`screend: The packet-screening daemon provides packet
`filtering and transparent proxying functionality.
`alarmd: The alarm daemon provides logging and
`alarm functionality to the application gateways and
`other firewall components.
`authd: The authentication service daemon pro-
`vides user authentication services to the applica-
`tion gateways.
`
`■ dnsd: The name service daemon provides the
`Domain Name Service (DNS) to the application
`gateways and to the users of the firewall.
`fwcond: The firewall control daemon monitors the
`application gateway and support daemons that
`must run on the firewall and restarts any that stop
`operating.
`
`■
`
`In addition to these support daemons, the following
`statically linked libraries provide common services to the
`application gateways and the other firewall components:
`
`■ The access control list (ACL) library allows or
`denies access to clients based on the appropriate
`access control list.
`■ The firewall logging (fwlog) library provides a uni-
`form logging format for all firewall components.
`This library also provides the interface between the
`other firewall components and the alarm daemon.
`
`The main features of the application gateways, sup-
`port daemons, and libraries are described in more
`detail below. Figure 1 and the following steps show
`how these components interact when a network con-
`nection is established through an application gateway.
`
`1. The application gateway receives the connection
`request.
`2. The application gateway sends requests to the name
`service (dnsd) to get the host name of the client and
`the host name or IP address of the server.
`3. When the application gateway gets all the infor-
`mation available to it from the name service, it
`sends a request to the ACL system to ask whether
`to allow the connection. At this stage, the gateway
`does not have an authenticated name for the user
`attempting to connect, so it asks the ACL system
`whether unknown users are allowed to make the
`requested connection.
`4. If the connection is allowed, the application gate-
`way makes a connection with the server. Data can
`now flow between the client and the server
`through the firewall. The gateway also generates a
`log message for the connection.
`5. If the connection is denied by the ACL system, it
`is still possible that the connection is allowed for
`certain users, so the application gateway prompts
`the user for a user identifier so that it can be
`authenticated.
`6. The user specifies an identifier to the application
`gateway. The gateway sends a request to the
`authentication service (authd) to authenticate the
`user and initiates an authentication sequence.
`7. The authentication service responds to the appli-
`cation gateway with a challenge for the user. The
`gateway displays the challenge to the user.
`
`Digital Technical Journal
`
`Vol. 9 No. 2 1997
`
`21
`
`Blue Coat Systems - Exhibit 1038 Page 5
`
`

`
`FIREWALL
`SYSTEM
`
`AUTHENTICATION
`SERVICE
`
`SERVER
`APPLICATION
`
`APPLICATION
`GATEWAY
`
`CLIENT
`APPLICATION
`
`ACL SYSTEM
`
`DNS DAEMON
`
`ALARM SYSTEM
`(INCLUDES LOGGING)
`
`Figure 1
`Interaction between Application Gateway, Support Daemons, and Libraries
`
`8. The user uses this challenge to generate a response.
`The user then enters this response. This is passed
`by the application gateway back to the authentica-
`tion service. The authentication service uses the
`response to authenticate the user and confirms or
`denies that the user is authenticated to the gateway.
`If the identifier specified is unknown, the authenti-
`cation service fakes an authentication sequence and
`then denies authentication. When authentication is
`denied, the authentication service logs an event
`that may result in an alarm being triggered.
`9. If the user is authenticated successfully, the appli-
`cation gateway sends another request to the ACL
`system, this time with the additional information
`of the authenticated user identifier.
`10. If the connection is denied, the application gateway
`logs an event, which may result in an alarm being
`triggered. The user can try to authenticate again.
`11. If the connection is allowed, the application gate-
`way logs a message specifying that the connection
`has been accepted and makes a connection with
`the server. The client and server may now
`exchange data.
`12. When either the client or the server terminates the
`connection, the application gateway logs two
`messages: one specifies that the connection has
`terminated, and another reports statistics such as
`duration and amount of data exchanged.
`
`Packet Filtering
`The AltaVista Firewall for the DIGITAL UNIX operat-
`ing system provides both application-level and packet-
`
`filtering functionality. Packet-filtering functionality is
`provided by the well-known packet screening dae-
`mon, screend,6,7 which is shipped with DIGITAL
`UNIX. The AltaVista Firewall replaces the standard
`DIGITAL UNIX version of screend with a modified
`version that extends its packet-filtering functionality
`and provides support for transparent proxying. This
`section provides an overview of how screend operates
`as part of the packet routing in a dual- or multi-homed
`host. It then outlines why a firewall requires transpar-
`ent proxying and describes how screend is used to
`implement transparent proxying.
`Screend is a daemon that runs in user space. It exam-
`ines every IP packet that is being forwarded by a fire-
`wall and decides whether that packet should be
`forwarded or dropped. Screend bases its decision on a
`set of filter rules specified in a configuration file that
`it reads at start-up. When an IP packet is received
`by a DIGITAL UNIX host, the first check that the
`DIGITAL UNIX kernel performs is whether or not the
`packet is destined for this host. If the packet is destined
`for another host, then most hosts discard the packet.
`However, a DIGITAL UNIX host can be configured
`(by using iprsetup to switch on ipforwarding) to route
`packets that are destined for other hosts. This is useful
`when hosts that are not on the same physical network
`need to communicate. In this case, a number of
`routers must exist between the communicating hosts
`that can pass packets from one physical network to
`another. These routers have at least two network inter-
`faces, as shown in Figure 2. The router can then be
`configured to pass packets between the networks on
`each of its interfaces. In Figure 2, for example, if the
`
`22
`
`Digital Technical Journal
`
`Vol. 9 No. 2 1997
`
`Blue Coat Systems - Exhibit 1038 Page 6
`
`

`
`NETWORK A
`
`ROUTING
`GATEWAY
`
`NETWORK B
`
`100.0.0.1
`
`200.0.0.1
`
`100.0.0.2
`
`200.0.0.2
`
`Figure 2
`Routing Packets between Networks
`
`host on network A with address 100.0.0.1 wants to
`send a packet to a host on network B, the packet is
`initially sent to the routing host. The router receives
`the packet on interface 100.0.0.2. The routing soft-
`ware in the kernel then sends the packet to the host on
`network B.
`When a DIGITAL UNIX machine with ipforward-
`ing switched on receives a packet that is not destined
`for itself the packet is passed to a forwarding module
`in the kernel. This module decides whether the packet
`can be forwarded and what network interface to send
`it to. When screend is running on the host, a third
`operation is inserted after the host has decided that the
`packet is not for itself and before the packet is sent to
`the forwarding module. This intermediate function
`sends the packet to the screend process, which decides
`whether the host is allowed to forward the packet,
`based on its set of rules. If screend rejects the packet, it
`is discarded. If screend accepts the packet, it is sent to
`the forwarding module as normal.
`The AltaVista Firewall is primarily an application
`gateway firewall. This means that all hosts interacting
`with the firewall route packets to the application gate-
`ways on the firewall. The application gateway then
`opens a connection to the remote service if the
`requested connection is allowed. Because the firewall
`never has to forward packets, IP forwarding could be
`switched off at the firewall, and screend need not run.
`If a user attempts to connect to a server on the other
`side of a firewall, however, the user must understand
`that the application gateway is present. Instead of con-
`necting directly to the server wanted, the user must
`first connect to the firewall and then request an appli-
`cation gateway to establish a connection to the remote
`server. This can be especially awkward with some
`GUI-based clients.
`Transparent proxying was developed to overcome
`this problem. When an application gateway that sup-
`ports transparent proxying is running on the firewall,
`the user can make what appears to be a direct connec-
`tion to the remote server. In reality, the connection
`from the client machine is routed through the firewall,
`which intercepts the connection and redirects the
`
`packet to the appropriate gateway. Then, if the gate-
`way allows the connection, it builds a new connection
`between the firewall and the server. From the user’s
`perspective, the firewall is transparent and has played
`no part in the establishment of the connection.
`However, the gateway processes all the user’s requests.
`When a connection is made by a transparent gateway
`between a client and a server, two TCP connections
`exist. The first is between the client machine and the
`firewall. The client host address and the server host
`address are the source and destination addresses of
`packets on this connection. The second TCP connec-
`tion is between the firewall and the server host. The
`firewall and server host address are the source and des-
`tination addresses of packets on this connection.
`The AltaVista Firewall uses screend to implement
`transparent proxying. To do this, changes were made
`to the DIGITAL UNIX kernel and to the screend appli-
`cation. The most significant change to screend was to
`add a third option to how screend deals with a packet.
`Although the standard screend implementation can
`only accept or reject packets, the implementation of
`screend that is shipped with the AltaVista Firewall can
`also proxy a packet. In this case, the packet is not passed
`on to the IP forwarding module in the DIGITAL
`UNIX kernel on the firewall. Instead, the kernel sets a
`flag in the packet to indicate that it is being proxied,
`and the packet is sent back into the IP input module.
`When the IP input module detects that the packet
`is being proxied, it treats the packet as if it were
`addressed to itself, and passes the packet to its own
`TCP input module. This then passes the packet on to
`the application gateway that is listening on the appro-
`priate port. The application gateway determines what
`the intended destination for the packet is and, subject
`to the access control specified for the gateway, creates
`a new connection to the requested server.
`Screend imposes an overhead on packet forwarding.
`Most of this overhead occurs because of the need for a
`system call from screend to deal with every packet tra-
`versing the AltaVista Firewall. The designers of the
`AltaVista Firewall decided that this overhead would
`seriously degrade performance, and a cache for screend
`was implemented in the DIGITAL UNIX kernel. This
`cache maintains the ways in which screend deals with
`most open connections, so that only new connections
`suffer the overhead of a