Search our
entire site
Enter your search
terms below, or visit
our search page

Search case
studies only
Enter your search
terms below:

For the table
of contents and
hyperlinks to
general topics
proceed to toc

Approaches to combine firewalls with IPSEC

Firewall-to-firewall tunnels

Many firewall vendors offer some kind of encrypted firewall-to-firewall tunnels. These tunnels are very useful for building
protected virtual private networks (VPN). Instead of using expensive leased lines, all traffic is encrypted, wrapped with another
IP header, and then sent over the Internet. The firewall at the remote site unwraps and decrypts the datagram to yield the
original IP datagram. The firewall then forwards this datagram to its final destination.

Since every firewall vendor had its own "standard" for firewall-to-firewall tunnels, implementations from different vendors were
usually not inter-operable, thus locking users to a single vendor. This also made development of international VPNs difficult,
because export-restrictions for firewalls containing cryptographic algorithms made it impossible to stick with a single vendor.

The common standard IPSEC enables secure inter-operation of firewall-to-firewall tunnels from different vendors. The ESP in
tunnel-mode in combination with the AH is functionally equivalent to what vendors have done before. RSA's S/WAN initiative
demonstrated interoperability of about a dozen products by March 1996.

With firewall-to-firewall tunnels in place, it is important that both sites have very similar security policies. Different security
policies would result in different firewall setups, making one firewall more secure than the other. After breaking into the net
behind the less protected firewall, an attacker can use the tunnel to reach the systems in the net behind the other firewall. The
security of both nets would depend on the security of the weakest firewall.

It is also debatable if firewall-to-firewall tunnels solve the sniffer problem. The traffic between the firewalls is encrypted and for
that reason there is no risk that valuable data or passwords could be sniffed on the Internet. On the other side the traffic
between the host and the tunnel is still unencrypted. The experience of DFN-CERT and other computer emergency response
teams show that the majority of sniffer attacks occur in local area networks.

Better security can be obtained with host-to-host encryption.

Use of IPSEC in packet screens

The first step on the way to combine current firewall architectures with IPSEC will be the integration of IPSEC in packet
screens. In the immediate future routers will be able to apply filters based on the presence or absence of the AH or the ESP
header. These filters can only be applied to enforce use of IPSEC headers, they will not be able to verify the data in the
authentication header.

Firewalls using this type of packet screen, that only checks for the presence of IPSEC headers, depend highly on the security of
the end-hosts.

It will be the responsibility of the host to verify the AH and to reject spoofed datagrams.
The host also has to be trusted not to use weak keys. If a host uses weak keys, the communication will not be secure
even with IPSEC headers present. The packet screen cannot distinguish between weak and strong keys.
Firewalls based on packet screens usually apply filters based on TCP or UDP port numbers. When a host uses the ESP,
the port numbers will be encrypted, denying the packet screen access to this information.
Even worse, the packet screen cannot distinguish between ESP transport-mode and ESP tunnel-mode. This information
is only available after decryption. Malicious hosts can use ESP in tunnel-mode to provide IP connectivity to other hosts
that are otherwise not allowed to communicate with the Internet.

As it has been shown, this type of firewall would depend strongly on the security of the hosts in the LAN. This makes this type
of firewall acceptable only for a very small number of networks. A typical network that would be sufficiently protected is the
DFN-CERT network as described in [Ellermann 95].

Other sites would have to restrict access to a very small set of "trusted hosts". In firewall environments these hosts are usually
called bastion hosts as discussed in section 1.

AH verification in packet screens

The firewall wouldn't depend that much on the security of the hosts, if it could not only check for the presence of the AH, but
could also verify the authentication information itself. The packet screen would be able to reject spoofed datagrams and to
detect weak keys.

Unfortunately, it is very difficult for the packet screen to verify the AH. The mandatory mechanism for the AH is keyed MD5
[Atkinson 95b, Metzger et al. 95a, Rivest 92]. As keyed MD5 is a symmetric cryptographic mechanism, only the endpoints of
the connection can verify the authentication information.

There are three possible solutions:

The router asks the endpoint for the current key in use. With symmetric cryptographic mechanisms this will also enable
the router to generate a valid AH, and thereby spoof traffic from that host. This solution could not be recommended.
The host establishes a separate key with the packet screen. It uses the key to wrap another IP header with authentication
header around the datagram it wants to send. The screening router verifies the outer AH, if correct, it forwards the inner
IP datagram to the final destination.

If the datagram has to cross multiple firewalls on its way to the destination host, this solution will result in a rather large
number of headers. Each firewall that has to be crossed will add another layer of 512 bits -- 320 bits for the IPv6
header [Deering et al. 95] and 192 bits for the AH [Atkinson 95b, Metzger et al. 95a]. This is only an acceptable
solution if not too many firewalls are to be crossed.
A third possible solution is the use of an asymmetric cryptographic algorithm for the AH. The AH is flexible enough to
hold authentication data generated by arbitrary mechanisms. If signature algorithms are used for the AH, all routers
having access to the public key can verify the authentication information, but no-one can forge traffic from that host.

The signature mechanisms are computationally more expensive than keyed MD5. Considering that some experts even
believe that keyed MD5 might be too slow for some applications [Touch 95], it is not very likely that asymmetric
signature mechanisms will be used in the AH very often.

A possible solution would be some tuning of the signature algorithm with the aim to make verification cheap and
generation more expensive. This is an area under active research.

As signature mechanisms are not mandatory to implement, probably only few hosts and few routers will support those
mechanisms. If the destination host or some of the routers on the path require authentication, but do not support the
same signature mechanism, the host will have to fall back to use the AH with keyed MD5, at least to authenticate with
these nodes.

Even with asymmetric cryptographic algorithms the packet screen must use a key-management protocol exchange,
because only short-term keys will be used for signing. Considering that there will be a few hundred pairs of hosts
communicating through the packet screen at a time, the load generated by the key management protocol will be
non-negligible.

Application level firewalls

The security of both gateway firewalls and combinations of packet screens with bastion hosts is based on forcing all traffic
through a single host. With gateway firewalls, all traffic between both connected networks must cross this host (the gateway)
because it is the only host that is connected to both nets. When the combination of packet screen and bastion host is used, the
packet screen only allows traffic to the bastion host, thereby forcing all traffic to have at least one endpoint at the bastion host.
The verification of the AH information at the packet screen is not necessary, because the bastion host can be trusted to verify
the AH and to reject forged datagrams.

For the integration with IPSEC both firewall architectures are equivalent. In both cases the secured IPSEC connection ends at
the bastion host or gateway and a second, independent connection has to be opened to the final destination. Applications on
the bastion host perform authentication, access control, and audit.

The integration with IPSEC has some impact on bastion host design:

The performance of the bastion host has always been the most restrictive factor for firewall throughput. With massive use
of computationally expensive cryptographic algorithms in IPSEC, the bastion host is more burdened than before. There
are two possible solutions to this problem: specialized hardware support for cryptographic algorithms and parallel
installation of multiple bastion hosts.

Some functions in cryptographic algorithms are very expensive for general purpose CPUs, but are practically free on
specialized hardware (e.g. the transposition of bits in DES p-boxes) [Schneier 96]. Currently almost all cryptographic
calculations are still done in software on general purpose CPUs. This is very likely to change, because also other hosts
will experience performance problems when IPSEC is used for most communication. The impact of cryptographic
calculations on performance will be a severe problem for WWW- and DNS-servers.

The parallel installation of multiple bastion hosts is already used today, if one bastion host is not powerful enough for the
required throughput. This type of setup will be used more frequently with IPSEC.
Currently users must authenticate themselves at proxy servers with one-time passwords or similar strong authentication
mechanisms each time they want to open a connection across the firewall. With IPSEC this authentication can be done
with the AH. The authentication header already contains enough information, so the additional use of one-time
passwords is no longer necessary. This will make proxy servers more transparent. IPSEC allows for user-oriented and
host-oriented keying. Proxy servers will, depending on the implemented security policy, most likely require user-oriented
keying. So users on hosts that only support host-oriented keying, might still be required to enter a one-time password.

Even though the security of a firewall combined with IPSEC will be stronger than the security of each mechanism alone, in some
special cases users will have less security. As discussed before, the firewall cannot allow end-hosts to send or receive ESP
traffic. Users that want to have confidential communication with hosts on the other side of the firewall must communicate via the
bastion host, where their traffic will be decrypted and re-encrypted again. To protect confidentiality users might use encryption
on their application data, but they will not be allowed to use encryption on the network layer.

Are firewalls still necessary?

The expected widespread deployment of IPv6 (and thus IPSEC) will make firewalls unnecessary, some experts claim. A closer look at the typical reasons why firewalls are used today will show why IPSEC can't replace firewalls.

Firewalls protect against weaknesses in various server programs by allowing access only to servers that are known to be secure, and denying access to all other servers. IPSEC doesn't protect against this weakness, it will just provide an attacker with a perfectly secure connection to an insecure server like sendmail.

Firewalls protect against administrator errors. In large local area networks it is almost impossible to secure all hosts. There will probably be at least one host which still has some unpatched servers, or has exported its file-systems to the whole Internet. IPSEC does not protect against administrator errors, in fact administrators who don't understand the concepts in IPSEC are likely to configure their hosts in an insecure fashion.

Finally, IPSEC cannot control the behavior of users. Users can share their passwords with friends and send valuable data to other individuals outside the company.

A single access point, such as a firewall that controls the types of services that can be used with the Internet, will still be important even with IPSEC deployed. The best security could be achieved by the combination of IPSEC with firewalls.

TABLE OF CONTENTS