106 Part Two IPv6 Protocols
Security
Gateway
Network
Stack
Message
TCP/IP
Network
Stack
TCP/IP
Packet
to
X
Security
Gateway
Y
A
Message
B
B
Packet
to
Y
Packet
to
Y
Packet
to
Y
Packet
to
B
Packet
to
B
Packet
to
B
Packet
to
B
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
protocol header.
IPv6 simplifies 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
these extensions.
The ordering of IPsec headers, whether within IPv4 or IPv6, has signi-
ficance. 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 first,
followed by the ESP Header and encrypted payload. Reversing the order,
by doing data integrity first 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
defines the SA as “a simplex ‘connection’ that affords security services
to the traffic carried by it.” This rather murky definition is clarified by
a description; an SA consists of three things.
A Security Parameter Index (SPI)
An IP destination address
A security protocol (AH or ESP) identifier
As a simplex connection, the SA associates a single destination with the
SPI; thus, for typical IP traffic there will be two SAs: one in each direc-
tion that secure traffic flows (one each for source and destination host).
SAs provide security services by using either AH or ESP but not both
(if a traffic stream uses both AH and ESP, it has two—or more—SAs).
The Security Parameter Index (SPI) is an identifier 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
hosts.
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 defined within ISAKMP, which also defines
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 defined.
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 identifiers, 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 define how those functions
are to be carried out. The IKE protocol, working within the framework
defined by ISAKMP, does define a mechanism for hosts to perform these
exchanges.
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
packets.
Another database, called the Security Association Database (SAD), includes
all security parameters associated with all active SAs. When an IPsec host

Get IPv6, 2nd Edition now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.