There are a few things to discuss when talking about IPsec's building blocks.
We're going to break it down into four main categories and
discuss how we use them effectively.
These are security protocols, security associations,
the key management,
and the cryptographic algorithms that we mentioned previously.
We'll talk about each one of these and what they mean for us in building up
the IPsec protocol suite and implementing its functionality.
So let's talk about ESP and AH for a minute.
This choice is the first building block for IPsec.
To understand the choices,
let's highlight some of the similarities and differences surrounding these.
The AH, or Authentication Header,
provides benefits such as data integrity and authentication,
as well as protection against replay attacks.
ESP, or Encapsulating Security Payload, gives us those same things,
but adds confidentiality.
They both are structured slightly different in the protocol
suite and use different protocol numbers.
AH functions as our authentication service for IPsec.
It's not really a service, but it serves our authentication needs.
It can be applied together with ESP or alone if desired.
As I've mentioned before,
the main differences between AH and ESP are the services that each provides.
AH allows us to provide authentication for as much of the IP
header as possible and gives us the ability to provide it
for the rest of the datagram, which is our payload.
This is a limitation of AH in that it does not provide the
security services for the entire original packet.
Looking a little more deeply at our datagram structures,
you can clearly see the difference between the AH protocol's data
structure in transport mode and tunnel modes.
The original IP header is maintained in transport mode,
and AH only provides the services for the payload.
In tunnel mode,
there's a new IP header that's created with any changed header fields
due to the AH protocol's interactions with the fields.
The position of the AH header is in the same place between the two.
Speaking of the AH header, check this out.
Here's the structure of the header with some of its
fields for the components that make it up.
We have the Security Parameters Index, Sequence Numbers Field,
as well as a few others.
We'll be covering some of these a little bit more later on in the course.
Here, we have our field,
such as the 1-byte Next Header and Payload Length fields,
as well as our 4-byte SPI and Sequence Number fields.
The Integrity Check Value gives us the results of the
hashing algorithm that is used to perform the calculations
and value verification checks.
By the way,
all of these header and datagram structure diagrams that I'm using in
this course are taken out of the corresponding RFCs.
The IETF and the volunteers do a great job documenting all of
this information for all of the protocols.
So AH's sibling ESP is the other security protocol that we
will be talking about with regards to IPsec.
It's the one that provides us the ability to encrypt our data
to provide confidentiality so that eavesdroppers will have a
difficult time deciphering our data.
ESP can be used either by itself or in conjunction with AH and gives us the
same benefits as AH plus the added benefit of encryption.
So with ESP, we have the same two options as with AH,
transport mode and tunnel mode.
ESP's header is inserted after the original IP header,
just like with AH in transport mode.
The difference here is that ESP encapsulates the payload
so that we have an ESP trailer as well.
In transport mode, the payload is encrypted.
In tunnel mode, everything else is encrypted,
and a new IP header is created outside of the ESP encapsulation.
The ESP header is also slightly different than the AH header.
Since the new IP header is created and placed before the ESP header,
we don't need some of the information that was included in the AH header,
like the payload length.
We start the ESP portion with the PSI and sequence number both being 4 bytes,
then we move into the payload data.
The remainder of the datagram finishes up the ESP
packet with the ESP trailer and the ICB,
which, if you remember, we saw in the header for the AH packet.
These are some of the fundamental differences between the two protocols.
A security association is the next building block of the IPsec suite,
and the establishment of these is really the foundation for IPsec.
What is a security association then?
Well, it's a connection.
In IPsec,
the security associations are unidirectional connections that give
our devices the ability to use AH or ESP services.
Since these are unidirectional,
a pair of SAs is needed to be able to establish a bidirectional
communication stream between IPsec capable devices.
These SAs are essentially the pieces that track the IPsec
sessions and are identified by a few key parameters.
These are the Security Parameter Index, or SPI,
the destination IP address, and the Security Protocol Identifier,
either ESP or AH.
We'll cover SPI and a few components that help the SA
functionality in the next clip.
The ability to manage keys is one of the things that
gets a lot of organizations in trouble.
The Internet Key Exchange, or IKE,
is the protocol that IPsec uses to manage its keys in an automated way.
This automation allows for the use of anti-replay services that IPsec provides.
The default protocol is IKE version 2,
but we're going to cover both versions in this course in a lot of detail.
You can also manually manage the keys for IPsec and may work well
for small organizations with only a few sites,
but the automated method using IKEv2 is the standard for most deployments today.
We all like our automation, and managing IPsec keys for many,
many sites would be a pain if we didn't have it.
Crypto algorithms are the other building block that I want to talk about.
These are the algorithms that are used for both authentication and
encryption of the data that IPsec is trying to secure.
In fact, during the establishment of IPsec,
four different algorithms are negotiated for encryption,
authentication, integrity, and a pseudorandom function.
Let's take the authentication, for example.
We can use MD5 or SHA for authentication of our devices so
that the AH protocol can function properly.
If a device doesn't use the one that we're using, it's not going to work.
For encryption,
we typically have options such as 3DES and AES and its
variations to be able to encrypt our data with it.
IKE can utilize both symmetric and asymmetric cryptography for its algorithms.
As we go through the configuration of the IPsec suite in our demos,
we'll talk a little bit more about the crypto algorithms that are available to us.