Now we're going to talk about the various components that help make up
some of those building blocks in an IPsec function.
The first one that we'll cover is the SPI,
which we briefly introduced in a previous clip.
The SPI is actually a random 32-bit value that's essentially used to identify
the SA that an incoming datagram is tied to or bound to.
Determining the security association can be done by using just the SPI
or the SPI in conjunction with the protocol type.
In other words, when a device receives a packet using either AH or ESP,
the device determines the SA using the information in the SPI,
as well as the fact that the protocol is either AH or ESP.
These are the identifying pieces of information for the SA.
Up next in the IPsec components is what's called the Security Policy Database,
or SPD.
This database holds all of the IPsec service information,
such as what services are being offered and how they will be offered.
These include such components like the IPsec peers,
protocol mode, and crypto algorithms to name a few.
RFC 4301 states that the SA is a management construct
that's used to enforce security policy.
Well, if that's the case,
then the SPD would be that management construct's information on
what security policies to implement and how.
The SPD is consulted every time a packet goes in or
out of the interface or device, whether the packet is protected by IPsec or not.
It's also an ordered database that is similar in
fashion to an ACL on a network device.
First match wins essentially.
The Security Association Database, or SAD,
which contains the information about the SA,
is next.
It tells the device which parameters are associated with what SAs.
Every SA needs to have an entry in this database.
This database is where information like the anti-replay window,
SPI, SA lifetime, and sequence number counter,
along with the information about the security
protocol that's being used is stored.
There are many more items that are included in this database as well.
All of these help our device define how the SA is supposed to function.
The next component is what's called the Peer Authorization Database, or PAD.
The PAD provides the link between the SPD and the SA management protocol.
In our case, it's IKE.
What this piece does is a few things.
It identifies the peers that are authorized to
communicate with the device over IPsec.
It also tells us the protocol and method used for authentication,
as well as provides the authentication data that's needed.
The peer gateway address or DNS name are included in this database,
so we know exactly where to send our data or from whom we can receive it.
Finally, the last thing that I consider a component of IPsec is the lifetime,
the SA lifetime to be exact.
Now this is a configuration item that gives you the ability to
define how long the SA is going to be good for.
This can be either based on time or based on traffic amount.
It can also use both to determine it.
When the lifetime is done, either a new SA needs to be created or the old SA is terminated.