106 Part Two • IPv6 Protocols
Figure 6–2: Using a secure tunnel.
6.5 IP and IPsec
IPsec provides security services for either IPv4 or IPv6, but the way it
provides those services is slightly different in each. When used with IPv4,
IPsec headers are inserted after the IPv4 header and before the next-layer
IPv6 simpliﬁes header processing: Every IPv6 packet header is the same
length, 40 octets, but any options can be accommodated in extension
Chapter 6 • The IP Security Protocol (IPsec) 107
headers that follow the IPv6 header. IPsec services are provided through
The ordering of IPsec headers, whether within IPv4 or IPv6, has signi-
ﬁcance. For example, it makes sense to encrypt a payload with the ESP
Header and then use the Authentication Header to provide data integrity
on the encrypted payload. In this case, the AH Header appears ﬁrst,
followed by the ESP Header and encrypted payload. Reversing the order,
by doing data integrity ﬁrst and then encrypting the whole lot, means
that you can be sure of who originated the data but not necessarily certain
of who did the encryption.
6.5.1 SECURITY ASSOCIATIONS
The Security Association (SA) is a fundamental element of IPsec. RFC 2401
deﬁnes the SA as “a simplex ‘connection’ that affords security services
to the trafﬁc carried by it.” This rather murky deﬁnition is clariﬁed by
a description; an SA consists of three things.
• A Security Parameter Index (SPI)
• An IP destination address
• A security protocol (AH or ESP) identiﬁer
As a simplex connection, the SA associates a single destination with the
SPI; thus, for typical IP trafﬁc there will be two SAs: one in each direc-
tion that secure trafﬁc ﬂows (one each for source and destination host).
SAs provide security services by using either AH or ESP but not both
(if a trafﬁc stream uses both AH and ESP, it has two—or more—SAs).
The Security Parameter Index (SPI) is an identiﬁer indicating the type of
IP header the security association is being used for (AH or ESP). The SPI
is a 32-bit value identifying the SA and differentiating it from other SAs
linked to the same destination address. For secure communication between
two systems, there would be two different security associations, one for
each destination address.
Each security association includes more information related to the type
of security negotiated for that connection, so systems must keep track of
their SAs and what type of encryption or authentication algorithms, key
lengths, and key lifetimes have been negotiated with the SA destination
108 Part Two • IPv6 Protocols
6.5.2 USING SECURITY ASSOCIATIONS
As mentioned earlier, ISAKMP provides a generalized protocol for estab-
lishing SAs and managing cryptographic keys within an Internet environ-
ment. The procedures and packet formats needed to establish, negotiate,
modify, and delete SAs are deﬁned within ISAKMP, which also deﬁnes
payloads for exchanging key generation and authentication data. These
formats provide a consistent framework for transferring this data, inde-
pendent of how the key is generated or what type of encryption or
authentication algorithms are being used.
ISAKMP was designed to provide a framework that can be used by any
security protocols that use SAs, not just IPsec. To be useful for a particu-
lar security protocol, a Domain of Interpretation,orDOI, must be deﬁned.
The DOI groups related protocols for the purpose of negotiating security
associations—security protocols that share a DOI all choose protocol and
cryptographic transforms from a common namespace. They also share
key exchange protocol identiﬁers, as well as a common interpretation of
payload data content.
While ISAKMP and the IPsec DOI provide a framework for authentication
and key exchange, ISAKMP does not actually deﬁne how those functions
are to be carried out. The IKE protocol, working within the framework
deﬁned by ISAKMP, does deﬁne a mechanism for hosts to perform these
The sending host knows what kind of security to apply to the packet by
looking in a Security Policy Database (SPD). The sending host determines
what policy is appropriate for the packet, depending on various selec-
tors (for example, destination IP address and/or transport layer ports), by
looking in the SPD. The SPD indicates what the policy is for a particular
packet: Either the packet requires IPsec processing of some sort—in which
case it is passed to the IPsec module for processing—or it does not—in
which case it is simply passed along for normal IP processing.
Outbound packets must be checked against the SPD to see what kind (if
any) of IPsec processing to apply. Inbound packets are checked against
the SPD to see what kind of IPsec service should be present in those
Another database, called the Security Association Database (SAD), includes
all security parameters associated with all active SAs. When an IPsec host