An individual SA
either the AH or ESP protocol
but not both. Sometimes a particular traffic flow will call for the
services provided by both AH and ESP. Further, a particular traffic
flow may require
IPsec services between
hosts and, for that same flow, separate
services between security gateways, such as fire- walls. In all of these cases,
multiple SAs must be employed
for the same traffic flow to
achieve the desired
IPsec services. The term
security association bundle refers to a sequence of SAs through
which traffic must be processed to provide a desired set of
IPsec services. The SAs in a bundle
may terminate at different endpoints or at the same endpoints.
Security associations may be combined into
bundles in two ways:
Transport adjacency: Refers to applying more than one security protocol
to the same IP packet without invoking tunneling. This approach to
combining AH and ESP allows for only one level of combination; further nesting yields no added benefit since the
processing is performed at one IPsec instance:
the (ultimate) destination.
Iterated tunneling: Refers
to the application of multiple layers of security protocols effected through IP
tunneling. This approach allows for multiple levels of nesting, since each
tunnel can originate or terminate at a different IPsec site along the path.
The two approaches can be combined, for example, by having a transport SA between hosts
travel part of the way through a tunnel SA between security
One interesting issue that arises when
considering SA bundles is the order in which authentication and encryption may
be applied between
a given pair of endpoints
and the ways of doing so. We examine
that issue next. Then we look at combinations of SAs
that involve at least one tunnel.
Authentication Plus Confidentiality
Encryption and authentication can be
combined in order to transmit an IP packet that has both confidentiality and
authentication between hosts. We look at several approaches.
ESP WITH AUTHENTICATION OPTION
This approach is
illustrated in Figure 19.8. In this approach, the user first applies ESP to the
data to be protected and then appends the authentication data field. There are
actually two subcases:
Transport mode ESP: Authentication and encryption apply to the IP payload delivered to the host, but the IP
header is not protected.
Tunnel mode ESP: Authentication applies to the entire IP packet delivered
to the outer IP destination address (e.g.,
a firewall), and authentication is performed at that destination. The entire inner IP packet is protected by
the privacy mechanism for delivery to the inner
For both cases, authentication applies to
the ciphertext rather than the plaintext.
TRANSPORT ADJACENCY Another way to apply authentication after encryption is to
use two bundled transport SAs, with the inner being an ESP SA and the outer being an
AH SA. In this case, ESP is used without
its authentication option.
Because the inner SA is a transport SA, encryption
is applied to the IP payload. The resulting
packet consists of an IP header (and
possibly IPv6 header
extensions) followed by an
ESP. AH is then applied in transport mode, so that authentication covers the ESP plus
the original IP header (and extensions) except
for mutable fields. The advantage of this approach over simply using a single ESP SA with the ESP authentication option is that the authentication covers more fields, including the source and destination IP addresses. The disadvantage is the overhead of two SAs
versus one SA.
The use of authentication prior to encryption might be preferable for several reasons. First, because the authentication data are protected by encryption, it is impossible for anyone to
intercept the message and alter the authentication data without detection. Second, it may be desirable
to store the authentication
information with the message at the destination for later reference. It is more convenient to do this if the authentication information applies to the unencrypted message; otherwise the message would
have to be reencrypted to verify the authentication information.
One approach to applying authentication
before encryption between two hosts is to use a bundle consisting of an inner
AH transport SA and an outer ESP tunnel SA. In this case, authentication is
applied to the IP payload plus the IP header (and extensions) except for
mutable fields. The resulting IP packet is then processed in tunnel mode by ESP;
the result is that the entire, authenticated inner packet is encrypted and a
new outer IP header (and extensions) is added.
Basic Combinations of Security Associations
The IPsec Architecture document lists four examples of combinations of SAs
that must be supported by compliant IPsec hosts (e.g., workstation, server) or
security gateways (e.g. firewall, router).
These are illustrated in Figure 19.10.
The lower part
of each case in the figure represents the
physical connectivity of the elements; the upper part represents logical
connectivity via one or more nested SAs. Each SA can be either AH or ESP. For
host-to-host SAs, the mode may be either transport or tunnel; otherwise it must be tunnel mode.
Case 1. All security is provided between end systems that
implement IPsec. For any two end systems
to communicate via an SA, they must share the appropri-
ate secret keys. Among
the possible combinations are
AH in transport mode
ESP in transport
ESP followed by AH in transport
mode (an ESP SA inside an AH SA)
Any one of a, b, or c inside an AH or ESP in tunnel mode
We have already discussed how these various combinations can
be used to support authentication, encryption, authentication before encryption, and authenti- cation
Case 2. Security is provided only between gateways (routers,
firewalls, etc.) and no hosts implement IPsec. This case illustrates simple
virtual private network support. The security architecture document specifies that only a single tunnel SA is needed for this case. The tunnel could support AH, ESP, or ESP with the authenti- cation
option. Nested tunnels are not required, because the IPsec services apply to
the entire inner packet.
Case 3. This builds on case 2 by adding end-to-end security. The
same combi- nations discussed for cases 1 and 2 are allowed here. The
gateway-to-gateway tunnel provides either authentication, confidentiality, or
both for all traffic between end systems. When the gateway-to-gateway tunnel is
ESP, it also provides a limited form of traffic confidentiality. Individual
hosts can implement any additional IPsec ser- vices required for given
applications or given users by means of end-to-end SAs.
Case 4. This provides support for a remote
host that uses the Internet
to reach an organization’s
firewall and then to gain
access to some server or workstation behind the firewall. Only tunnel mode is required
remote host and
the firewall.As in case 1, one or two SAs may be used between
the remote host and the local host.