In this video, you and I get to compare and contrast
IKE version 1 and IKE version 2 as they can both be used
as part of IPsec VPN tunnels.
Let's talk about IKEv1 to begin with.
IKEv1 is IKE version 1.
IKE stands for the Internet Key Exchange.
And for IKEv1 there are two phases.
Now, they are literally distinguished as phases
for IKEv1.
So they are called the IKE phase 1 and IKE phase 2.
So when you think of IKE version 1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So when you think of IKE version 1,
think that it has two phases, IKE phase 1 and IKE phase 2.
And these two phases represent the two security associations
that are going to be built. So if we're
doing a site-to-site tunnel between R1 and R2,
there's going to be an initial security association.
A security association is a fancy way of saying a tunnel.
And it's bi-directional.
So if we have a tunnel, a security association
would be a security association from R1's perspective
that's outbound to R2, and there would
be another one that's outbound from the perspective of R2,
which R1 would see as an inbound.
So if we take a look at the IKE phase 1 tunnel, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we take a look at the IKE phase 1 tunnel,
think of it like a private com channel between the two VPN
endpoints.
In this case, R1 and R2 being the endpoints
of the VPN tunnel.
And it's handy to have a private com channel, a private security
association between the two devices,
because they can use that private communication channel
and have the benefits of encryption and hashing
to securely communicate back and forth with each other.
So that's the first thing they're
going to do is establish an IKE phase 1 tunnel or an IKE phase
1 security association either way with each other. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
1 security association either way with each other.
Now, to do that, they're going to negotiate five basic things,
and I call it HAGLE.
That reminds me of the five basic things for IKE phase 1.
And it's Hashing, how are we going to verify data integrity;
the Encryption, what protocol are
we going to use to encrypt the packets
back and forth; the Lifetime; the Group,
and that refers to the Diffie-Hellman group.
And Diffie-Hellman is an algorithm
these two devices can use together over a currently
untrusted network to negotiate shared secret keys that then
they can both start using to encrypt WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
they can both start using to encrypt
and decrypt the data respectively.
So they're going to negotiate as part of the IKE phase 1
tunnel which Diffie-Hellman group do we want to use,
then they'll run Diffie-Hellman, get the keys,
and they can use those keys.
And the A is for Authentication.
How do we want to authenticate each other?
Do we want to use RSA signatures, which implies
using digital certificates?
Or do we want to use pre-shared keys for the authentication
of this IKE phase 1 tunnel?
So they're going to negotiate, run Diffie-Hellman,
authenticate, and then they'll have this private channel
that's now set up.
Now, the reason they call this IKE phase 1 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, the reason they call this IKE phase 1
is because it's in preparation for building the IKE
phase 2 tunnel.
So they can use the security of IKE phase 1, this security
association, to go ahead and build the IKE phase 2 tunnel.
So for the IKE phase 2 tunnel, they
are going to negotiate encryption.
They are going to negotiate the hashing.
In IPsec we refer to that as an HMAC, Hashed Message
Authentication Code, which is going
to include some cryptography, as far
as the secrets involved to make it even a better hash.
They can also negotiate for that IKE phase 2
tunnel the lifetime, and also if they want WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
tunnel the lifetime, and also if they want
to run Diffie-Hellman again.
So the option exists to use the keys that
were generated earlier by Diffie-Hellman
during IKE phase 1, or they can use
a technique called PFS, which is Perfect Forward Secrecy.
And they'll basically run Diffie-Hellman again
and get a new set of shared keys that they
can use for the encryption and decryption on the IKE phase 2
tunnel.
So this is the IKE phase 2.
And this is also referred to as the IPsec security association,
or the IPsec tunnel.
And this is all about IKE version 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this is all about IKE version 1.
So IKE version 1 has two phases, the phase 1 tunnel,
like a private party line, and then the IKE phase 2 tunnel,
which is actually used to encrypt the traffic.
So for protecting the data from 10.1.0 to 10.2.0
on this site-to-site VPN, traffic
from this PC when it hits the router, based on the router
seeing it, and having the right cryptography implemented
would say, ooh, I need to wrap this up, encrypt it, and then
ship it to my peer, who then would go ahead and decrypt it.
And all that traffic is going to be sent-- the user traffic is
sent over the IKE phase 2 tunnel, or the IPsec security
association.
Also, be aware that during the IKE phase 1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Also, be aware that during the IKE phase 1,
these guys have the opportunity to do NAT detection,
to identify, hey, is there NAT running somewhere
between the peers.
And if there is, then the IKE phase 2
tunnel, the IPsec tunnel itself, can decide,
oh, there's NAT between us.
I need to go ahead and do some trickery called NAT traversal
or NAT transparency.
And we'll have a separate video on that.
But that also happens during IKE phase 1, the detection of
whether or not there is NAT or PAT
devices between the two peers.
And now the question we get to answer WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And now the question we get to answer
is how does that compare to IKE version 2.
Let's take a look.
Now, with IKE version 2, here are some of the benefits
before we talk about the implementation.
Some of the benefits include the ability
to support additional authentication methods,
like Extensible Authentication Protocol.
Also, instead of calling the security associations
phase 1 and phase 2 respectively, with IKE version
2 there is going to be a security
association between these two VPN endpoints.
And the first security association
is called the IKEv2 SA for Security Association. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is called the IKEv2 SA for Security Association.
And then what's going to happen is
it's going to build child security associations.
In this case, it would be the IPsec security association
where we can actually encrypt the user's
traffic over that IPsec SA.
So they don't literally refer to these as phases.
Although, you could think, well, there's
two stages or two processes.
But at the end of the day, it's the IKEv2 SA
that's going to be established.
And then it'll spin off additional child SAs
for IPsec as needed.
So if we have a hub and spoke, or multiple security
associations that we need, the IKEv2 will be in place. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
associations that we need, the IKEv2 will be in place.
And it can use that tunnel to negotiate and establish
the additional tunnels.
And the relationship would be child tunnels as opposed
to phase 2 tunnels.
IKE version 2 also supports NAT detection.
So if we're going through a NAT or PAT device,
IKEv2 also has the ability to identify that.
Also, with IKEv2, as newer and stronger protocols come out
for encryption and hashing, they're
going to be adopted as part of IKEv2, where the IKE version 1
really isn't adopting any brand new protocols WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
really isn't adopting any brand new protocols
and using a lot of new protocols.
All the new work and all the new protocols
are going to be adopted as part of IKEv2 in the IPsec family.
And just like any technology, when there's something newer,
there's additional features and functions that are built-in.
For example, if you had a smartphone version 12
and now you've got a smartphone version
13 from the same vendor, it's very
likely there's going to be some new and additional features
that they baked into that new version.
So with IKE version 2, there's some additional protections
for denial of service attacks.
To prevent against that, if we're in a Cisco environment
and using IKE version 2, we have more flexibility as far as WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and using IKE version 2, we have more flexibility as far as
how we can connect.
So if we had R1, it was doing a site-to-site VPN here,
and a remote access VPN here.
We have a lot of flexibility with IKEv2
as far as the policies and proposals
and profiles that we use.
So we can implement the correct cryptography
based on is it traffic coming in from a site-to-site tunnel,
or a remote access tunnel, or a combination of both.
Those are some of the differences between IKE version
1 and version 2.
And we'll have a chance in separate sets of videos
to see that in action. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to see that in action.
As we do traditional IPsec, like site-to-site with crypto maps,
we're going to be using the older IKE version 1.
If we're doing FlexVPN, whether it's
remote access or site-to-site VPNs with FlexVPN,
that would be using IKE version 2.
So you'll have a chance to see both of those in action
as we proceed through these sets of videos together.
So in the next video, what I'd like to do is chat with you
about some different options that we
have for implementing the cryptography, including
the option of using crypto maps.
And regarding crypto maps, in the next video, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And regarding crypto maps, in the next video,
I'd like to give you an inside look at what
is a crypto map, why we used it, and where
we might find it in a production environment today.
So I'll see you in that video in just a moment.
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.