by Mark A. Sportack
Gateways were once a readily understood part of the network. In the original Internet, the term gateway referred to a router. The router was the only tangible sign of the cyberworld beyond the local domain. This "gateway" to the unknown was (and still is) capable of calculating routes and forwarding packetized data across networks spanning far beyond the visible horizon of the originating local area network (LAN). Thus, it was regarded as the gateway to the Internet.
Over time, routers became less of a mystery. The emergence and maturation of corporate IP-based wide area networks (WANs) witnessed the proliferation of routers. Technological innovation, too, bred even more familiarity. The routing function can now reside in servers and even in network switching hubs. The original "gateway" no longer held the same mystique. Instead, the router grew into a multipurpose network device that did everything from segmenting LANs into smaller segments, to interconnecting related LANs in private WANs, to interconnecting private WANs with the Internet. Thus the router lost its synonymity with the term gateway.
The term gateway, however, has lived on. It has been applied and reapplied so frequently, and to so many different functions, that defining a gateway is no longer a simple task. Currently, there are three main categories of gateways:
The only commonality remaining is that a gateway functions as an intermediary between two dissimilar domains, regions, or systems. The nature of the dissimilarity you are attempting to overcome dictates the type of gateway that is required.
Protocol gateways usually convert protocols between network regions that use dissimilar protocols. This physical conversion can occur at Layer 2 of the OSI Reference Model (the Network Layer), Layer 3 (the Internetwork Layer), or between Layers 2 and 3. Two types of protocol gateways do not provide a conversion function: security gateways and tunnels.
Security gateways that interconnect technically similar network regions are a necessary intermediary because of logical dissimilarities between the two interconnected network regions. For example, one might be a private WAN and the other a public one, like the Internet. This exception is discussed later in this chapter, under the heading "Combination Filtration Gateways." The remainder of this section focuses on protocol gateways that perform a physical protocol conversion.
Tunneling is a relatively common technique for passing data through an otherwise incompatible network region. Data packets are encapsulated with framing that is recognized by the network that will be transporting it. The original framing and formatting are retained, but are treated as data. Upon reaching its destination, the recipient host unwraps the packet and discards the wrapper. This results in the packet being restored to its original format. In Figure 10.1, IPv4 packets are wrapped in IPv6 by Router A for transmission through an IPv6 WAN for delivery to an IPv4 host. Router B removes the IPv6 wrapper and presents the restored IPv4 packet to the destination host.
FIGURE 10.1. Passing data by tunneling techniques.
Tunneling techniques may be used for just about every Layer 3 protocol, from SNA to IPv6, as well as many individual protocols within those aforementioned suites. As beneficial as tunneling can be to overcoming the limitations of any given network topology, it has its dark side. The very nature of tunneling consists of hiding unacceptable packets by disguising them in an acceptable format. Quite simply, tunneling can be used to defeat firewalls by encapsulating protocols that would otherwise be blocked from entry to a private network region.
A myriad of proprietary gateway products have been available to bridge the gap between legacy mainframe systems and the emerging distributed computing environment. The typical proprietary gateway connected PC-based clients to a protocol converter at the edge of the LAN. This converter then provided access to mainframe systems using an X.25 network. The gateway in Figure 10.2 demonstrates tn3270 emulation sessions from client PCs to the gateway. The gateway dumps the IP sessions onto an X.25 WAN for transport to the mainframe.
These gateways were usually inexpensive, single-function circuit boards that needed to be installed in a LAN-attached computer. This kept the cost of the gateway to a minimum, and facilitated technology migrations. In the example illustrated in Figure 10.2, the single- function gateway facilitated the migration from the mainframe era's hard-wired terminals and terminal servers to PCs and LANs.
FIGURE 10.2. A primitive, proprietary, single-function gateway.
Layer 2 protocol gateways provide a LAN-to-LAN protocol conversion. They are usually referred to as translating bridges rather than protocol gateways. This type of conversion may be required to permit interconnection of LANs with different frame types or clock rates.
Local area networks that are IEEE 802-compliant share a common media access layer. However, their frame structures and media access mechanisms make them unable to interoperate directly. A translating bridge takes advantage of the Layer 2 commonalties, such as the MAC address, and enables interoperability by providing on-the-fly translation of the dissimilar portions of the frame structures.
First-generation LANs required a separate device to provide translating bridges. The current generation of multiprotocol switching hubs usually provides a high-bandwidth backplane that functions as a translating bridge between dissimilar frame types, as shown in Figure 10.4.
The automated behind-the-scenes nature of modern-day translation bridging has all but obscured this aspect of protocol conversion. Discrete translation devices are no longer required. Instead, the multitopology switching hub functions innately as a Layer 2 protocol converting gateway.
FIGURE 10.3. The common media access mechanisms of 802-compliant frames.
FIGURE 10.4. Contemporary multi-topology switching hubs automatically provide MAC-layer translation between dissimilar LANs.
An alternative to using a Layer 2-only device like a translating bridge or multitopology switching hub would be to use a Layer 3 device: a router. Routers have long established themselves as a viable collapsed LAN backbone (see Figure 10.5). Given that routers interconnect LANs to the WAN, they typically support standard LAN interfaces. Configured properly, a router can easily provide the translation between mismatched frame types.
The drawback to this approach is that using a Layer 3 device, a router, requires table look-ups. This is a software function. Layer 2-only devices like switches and hubs operate in the silicon of the device's hardware, and are able to operate significantly faster.
Many of the older LAN technologies have been treated to an upgraded transmission rate. For example, IEEE 802.3 Ethernet is now available in 10Mbps and 100Mbps versions, and soon will be supported in a 1Gbps version, too. The frame structures and interframe gaps are identical. The primary differences lie in their physical layer and, consequently, in their media- access mechanisms. Of these differences, the transmission rate is the most obvious difference.
FIGURE 10.5. Routers can be used to translate dissimilar LAN frames and provide a neutral gateway between LANs.
Token Ring, too, has been upgraded to operate at higher transmission rates. The original Token Ring specification operated at 4Mbps. Contemporary versions transmit at 16Mbps. FDDI, a 100Mbps LAN, descended directly from Token Ring and is frequently used as a backbone transport for Token Ring LANs.
These disparities in clock rates of otherwise identical LAN technologies require a mechanism to provide a speed-buffering interface between two otherwise compatible LANs. Many of today's multitopology, high-bandwidth switching hubs provide a robust backplane that can buffer speed mismatches, as shown in Figure 10.6.
FIGURE 10.6. Speed buffering with a multitopology, high-bandwidth switching hub.
The current generation of multitopology LAN switching hubs can provide internal speed buf-fering for different transmission rate versions of the same LAN technology. They can also provide Layer 2 frame conversion for different 802-compliant LANs.
Routers, too, can buffer transmission rate differences. They offer an advantage over switching hubs in that their memory is expandable. This memory buffers incoming and outgoing packets long enough for the router to determine which, if any, of the router's access list permissions apply, and to determine the next hop. This memory can also be used to buffer the speed mismatches (see Figure 10.7) that may exist between the various network technologies that are internetworked by the router.
FIGURE 10.7. Routers can be used as speed buffers.
Application gateways are systems that translate data between two dissimilar formats. Typically, these gateways are intermediate points between an otherwise incompatible source and destination. The typical application gateway accepts inputs in one format, translates it, and ships the outputs in a new format, as shown in Figure 10.8. The input and output interfaces can either be separate or use the same network connection.
FIGURE 10.8. A highly simplified, logical perspective of an application gateway.
A single application can have multiple application gateways. For example, electronic mail can be implemented in a wide variety of formats. Servers that provide electronic mail may be required to interact with other mail servers, regardless of their format. The only way to do this is to support multiple gateway interfaces. Figure 10.9 demonstrates some of the many gateway interfaces available for an e-mail server.
FIGURE 10.9. One application may be required to support interaction with multi-ple external formats.
Application gateways can also be used to connect LAN clients to external data sources. This type of gateway provides for local connectivity to an interactive application. Keeping the application's logic and executable code on the same LAN as the client base avoids lower bandwidth, higher-latency WANs. This, in turn, enables better response time to clients. The application gateway would then ship an I/O request to the appropriate networked computer that housed the data requested by the client. The data is fetched and reformatted as needed for presentation to the client.
This chapter does not conduct an exhaustive review of all the potential application gateway configurations, but these few examples should adequately convey the network ramifications of application gateways. They usually represent a point in the network at which traffic aggregates. To adequately support such traffic points, an appropriate combination of network technologies and LAN and/or WAN topologies is required.
FIGURE 10.10. Application gateways can also be used to fetch remote data for users.
Security gateways are an interesting mix of technologies that are important, and distinct, enough to warrant their own category. They range from protocol-level filtration to fairly sophisticated application-level filtration.
Firewalls come in three flavors:
NOTE: Only one of these firewalls is a filter. The remainder are gateways.
These three mechanisms are frequently used in combination. A filter is the screening mechanism(s) used to discriminate between packets that have legitimate need to access the specified destination port, and spurious packets that represent an unacceptable level of risk. Each has its own capabilities and limitations that must be carefully evaluated against the security requirements.
Packet filtration is the most basic form of security screening. Routing software enables the establishment of permissions, per packet, based on the packet's source address, destination address, or port number. Filtering on well-known port numbers provides the ability to block or enable internetworking protocols, such as FTP, rlogin, and so on.
Filtration can be performed on incoming and/or outgoing packets. Implementing filtering at the network layer means that a preexisting, general-purpose machine (the router) can provide some security screening function for all applications traversing the network.
As a resident component of the router, this filter is available for use free of charge in any routed network. This should not be misconstrued as a preexisting panacea! Packet filtration suffers from multiple vulnerabilities. It is better than no filtering, but not by much.
NOTE: The term router is used logically to describe a network function. The actual device performing that function may be a router or a host.
Packet filters can be deceptively difficult to implement well, particularly if your security requirements are poorly defined and lack critical detail.
This filter is also defeated remarkably easily. A packet filter evaluates each packet and makes a "go/no go" determination based solely on the packet's header information relative to the router's programmed access lists. This technique suffers from several potential vulnerabilities.
First and foremost, it is directly dependent on the router administrator to correctly program the desired set of permissions. Typographical errors, in this situation, are hardly benign. They create holes in one's perimeter defenses that require few, if any, special skills to exploit.
Even if the administrator programmed the set of permissions accurately, the logic behind those permissions must be flawless. Though it may seem trivially easy to program a router, developing and maintaining a complex, lengthy set of permissions can be quite cumbersome. The day-to-day change in a networked computing environment must be understood and assessed relative to the firewall's set of permissions. New servers that were not explicitly protected at the firewall may find themselves vulnerable to attack.
Over time, access look-ups can degrade the rapidity with which routers forward packets. As soon as a router receives a packet, it must identify the next hop for that packet to reach its specified destination. This must be accompanied by another CPU-intensive task: checking the access list to determine if it is permitted to access its destination. The longer the access list, the more time this process will take.
The second vulnerability of packet filtration is that it accepts the packet header information as valid, and has no way of authenticating the packet's origin. Header information is easily falsified by network-savvy hackers. This falsification is commonly known as spoofing.
The myriad weaknesses of packet filtration leave it ill-prepared to adequately defend your networked computing resources. It is best used in combination with other, more sophisticated filtering mechanisms, rather than used to the exclusion of other mechanisms.
Circuit-level gateways are ideal for protecting outbound requests that originate in a private, secured network environment. The gateway intercepts the TCP request, or even certain UDP requests. It then retrieves the requested information on behalf of the originator. This proxy server accepts requests for information stored on the World Wide Web and fulfills those requests on behalf of the originator. In Figure 10.11, the dashed line demonstrates the logical path of the request, and the dotted line represents the actual path. In effect, the gateway acts like a wire that links the originator with the destination, without exposing the originator to the risks associated with traversing an unsecured network region.
FIGURE 10.11. The proxy server.
Proxitizing requests in this manner simplifies the management of border gateway security. If access lists are implemented, all outgoing traffic can be blocked, except for the proxy server. Ideally, this server would have a unique address and not be a part of any other internally used network address range. This would absolutely minimize the amount of information that would otherwise be inadvertently, and subtly, advertised throughout the unsecured region. Specifically, only the network address of the proxy server would become known, and not the network addresses of each network-connected computer in the secured domain.
Application gateways are almost the polar opposite of packet filtration. Packet filtration uses general-purpose protection of all traffic that crosses the network-level packet-filtering device. Application gateways place highly specialized application software at each host to be protected. This avoids the traps of packet filtration and enables tighter security per host.
One example of an application gateway is the virus scanner. This specialized software has become a staple of desktop computing. It is loaded into memory at boot time and stays resident in the background. It continuously monitors files for known viruses, or even altered system files. Virus scanners are designed to shield the user from the potential damage of a virus before damage can be inflicted.
This level of protection would be virtually impossible to implement at the network layer. It would require examining the contents of each and every packet, authenticating its source, determining the appropriate network path, and determining whether the contents were as purported or spurious. This process would incur an unsupportable level of overhead that would severely compromise network performance.
Application gateways offer the ability to create copious logs of all inbound and outbound traffic. Residing in a host also affords access to CPU, disk, RAM, and other useful resources that can be applied.
The principal limitation of application gateways is that they are applied on a per-host or per-application basis. In a host and/or application-rich environment, this can become quite expensive. Economics should dictate, however, that the most important applications are protected. Network-level security gateways, conversely, apply protection almost equally with a broad brush.
Gateways that utilize a combination filtration approach typically provide a fairly tight set of access controls by implementing redundant, overlapping filters. These can include any combination of packet-, circuit-, and application-level mechanisms.
One of the more common implementations of such a security gateway is as a network sentry that guards the point(s) of ingress and egress along the edges of a private network domain. Such gateways are more commonly referred to as border gateways or firewalls. This critical function often requires multiple filtration techniques to develop an adequate defense. Figure 10.12 demonstrates a two-component security gateway: a router and a processor. In combination, they can provide protocol-, circuit-, and application-level protection.
FIGURE 10.12. A two-component security gateway.
This specialized form of gateway does not necessarily provide a conversion function, as do the other types of protocol gateways. Given that border gateways are used at the borders of one's network, they are responsible for regulating both ingress and egress traffic. Ostensibly, both the internal and external WANs linked by the gateway will be using the Internet Protocol (IP). Thus, no conversion should be necessary: the two are directly compatible. Filtration, however, becomes critical.
The reasons for protecting a network from unauthorized, external access are obvious. It's done for the same reason that corporate employees are frequently issued identification badges and/or access cards. It provides a mechanism for differentiating between legitimate members of the corporation who require access to its facilities, and pretenders whose motives are assumed to be suspicious. Any inbound attempts to access networked computing resources must be evaluated to determine the authenticity of the request.
The reasons for regulating outbound access may not be quite as obvious. Under some circumstances, it may be necessary to provide a filtration of outbound packets. For example, the proliferation of browsers among the user base may result in a significant increase in WAN traffic. If left unregulated, browsing, newscasting, or any other Web-based traffic could easily compromise the WAN's ability to transport other applications. Thus, it may be necessary to block this form of traffic, either in whole or in part.
IP (the dominant internetworking protocol) is an open protocol. It was designed to facilitate communication across network domains. This is both its primary strength and its greatest weakness. Providing any interconnectivity between two IP WANs, in essence, creates one big IP WAN. The sentry left to guard one's network borders, the firewall, is tasked with discriminating between legitimate internetworking traffic and spurious traffic that can't be trusted.
Implementing a security gateway is not a task that can be taken trivially. Success absolutely depends upon definition of requirements, careful planning, and flawless implementation. The first task must be establishing a comprehensive set of rules that define an understood and accepted compromise between security and cost. These rules constitute the security policy.
This policy can be lax, severe, or anything in between. On one extreme, a security policy can start with the basic premise that everything is allowable. Exceptions are expected to be few and manageable. These exceptions are explicitly added to the security infrastructure. This policy is easy to implement, requires almost no forethought, and guarantees that even the amateurs will find a way around the minimal protection.
The other extreme is almost draconian. This policy requires that all connectivity across the network is explicitly denied. This is relaxed, carefully and intentionally, to accommodate the user community's access requirements. Only these requirements are permitted. This approach is difficult to implement, won't win any popularity contests with the users, and can be extremely expensive to maintain. It will, however, provide the intangible benefit of a secured network. From the "net.police" perspective, this is the only acceptable security policy.
In between these extremes are an infinite series of compromises between ease of implementation and use, and cost of maintenance. Most implementations will fall into this broad category of compromise, either intentionally or by accident. The right balance requires careful evaluation of the risks and costs.
As networked computing continues to evolve, it is likely that more and more mission-critical applications will find themselves internetworked in an open network environment. To the extent that such applications may continue to rely upon disparate protocols, protocol conversion gateways will be essential.
The increased reliance on an open internetworking protocol for support of distributed computing also directly increases the need for security gateways. All forms of security gateways, application, packet, and circuit level, can provide much needed protection.
Regardless of their form and implementation, gateways are indispensable adjuncts to any network. Properly selected and implemented, gateways are one of the keys to unleashing the potential of high-performance networks.
© Copyright, Macmillan Computer Publishing. All rights reserved.