WEBVTT

1
00:00.000 --> 00:01.840 align:middle line:84%


2
00:01.840 --> 00:04.190 align:middle line:90%
In this video, you and I
get to compare and contrast

3
00:04.190 --> 00:07.510 align:middle line:90%
IKE version 1 and IKE version
2 as they can both be used

4
00:07.510 --> 00:10.390 align:middle line:84%
as part of IPsec VPN tunnels.

5
00:10.390 --> 00:12.520 align:middle line:90%
Let's talk about
IKEv1 to begin with.

6
00:12.520 --> 00:14.170 align:middle line:84%
IKEv1 is IKE version 1.

7
00:14.170 --> 00:16.690 align:middle line:90%
IKE stands for the
Internet Key Exchange.

8
00:16.690 --> 00:20.300 align:middle line:90%
And for IKEv1 there
are two phases.

9
00:20.300 --> 00:23.620 align:middle line:90%
Now, they are literally
distinguished as phases

10
00:23.620 --> 00:24.700 align:middle line:84%
for IKEv1.

11
00:24.700 --> 00:29.470 align:middle line:90%
So they are called the IKE
phase 1 and IKE phase 2.

12
00:29.470 --> 00:31.210 align:middle line:90%
So when you think
of IKE version 1,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:29.470 --> 00:31.210 align:middle line:90%
So when you think
of IKE version 1,

13
00:31.210 --> 00:34.270 align:middle line:90%
think that it has two phases,
IKE phase 1 and IKE phase 2.

14
00:34.270 --> 00:37.775 align:middle line:90%
And these two phases represent
the two security associations

15
00:37.775 --> 00:39.400 align:middle line:90%
that are going to be
built. So if we're

16
00:39.400 --> 00:41.980 align:middle line:90%
doing a site-to-site
tunnel between R1 and R2,

17
00:41.980 --> 00:44.380 align:middle line:90%
there's going to be an
initial security association.

18
00:44.380 --> 00:47.520 align:middle line:90%
A security association is a
fancy way of saying a tunnel.

19
00:47.520 --> 00:48.520 align:middle line:84%
And it's bi-directional.

20
00:48.520 --> 00:50.560 align:middle line:90%
So if we have a tunnel,
a security association

21
00:50.560 --> 00:53.050 align:middle line:90%
would be a security association
from R1's perspective

22
00:53.050 --> 00:54.940 align:middle line:90%
that's outbound to
R2, and there would

23
00:54.940 --> 00:57.730 align:middle line:90%
be another one that's outbound
from the perspective of R2,

24
00:57.730 --> 00:59.320 align:middle line:90%
which R1 would
see as an inbound.

25
00:59.320 --> 01:02.260 align:middle line:90%
So if we take a look at
the IKE phase 1 tunnel,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

25
00:59.320 --> 01:02.260 align:middle line:90%
So if we take a look at
the IKE phase 1 tunnel,

26
01:02.260 --> 01:06.690 align:middle line:90%
think of it like a private com
channel between the two VPN

27
01:06.690 --> 01:07.210 align:middle line:84%
endpoints.

28
01:07.210 --> 01:09.340 align:middle line:90%
In this case, R1 and
R2 being the endpoints

29
01:09.340 --> 01:10.690 align:middle line:84%
of the VPN tunnel.

30
01:10.690 --> 01:14.230 align:middle line:90%
And it's handy to have a private
com channel, a private security

31
01:14.230 --> 01:15.730 align:middle line:90%
association between
the two devices,

32
01:15.730 --> 01:18.340 align:middle line:90%
because they can use that
private communication channel

33
01:18.340 --> 01:21.210 align:middle line:90%
and have the benefits of
encryption and hashing

34
01:21.210 --> 01:23.715 align:middle line:90%
to securely communicate back
and forth with each other.

35
01:23.715 --> 01:25.090 align:middle line:90%
So that's the
first thing they're

36
01:25.090 --> 01:28.630 align:middle line:90%
going to do is establish an IKE
phase 1 tunnel or an IKE phase

37
01:28.630 --> 01:31.790 align:middle line:90%
1 security association
either way with each other.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:28.630 --> 01:31.790 align:middle line:90%
1 security association
either way with each other.

38
01:31.790 --> 01:34.420 align:middle line:90%
Now, to do that, they're going
to negotiate five basic things,

39
01:34.420 --> 01:35.740 align:middle line:84%
and I call it HAGLE.

40
01:35.740 --> 01:38.530 align:middle line:90%
That reminds me of the five
basic things for IKE phase 1.

41
01:38.530 --> 01:41.710 align:middle line:90%
And it's Hashing, how are we
going to verify data integrity;

42
01:41.710 --> 01:43.277 align:middle line:90%
the Encryption,
what protocol are

43
01:43.277 --> 01:44.860 align:middle line:90%
we going to use to
encrypt the packets

44
01:44.860 --> 01:47.740 align:middle line:90%
back and forth; the
Lifetime; the Group,

45
01:47.740 --> 01:50.983 align:middle line:90%
and that refers to the
Diffie-Hellman group.

46
01:50.983 --> 01:52.400 align:middle line:90%
And Diffie-Hellman
is an algorithm

47
01:52.400 --> 01:55.330 align:middle line:90%
these two devices can use
together over a currently

48
01:55.330 --> 01:58.980 align:middle line:90%
untrusted network to negotiate
shared secret keys that then

49
01:58.980 --> 02:00.520 align:middle line:90%
they can both start
using to encrypt
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
01:58.980 --> 02:00.520 align:middle line:90%
they can both start
using to encrypt

50
02:00.520 --> 02:02.450 align:middle line:90%
and decrypt the
data respectively.

51
02:02.450 --> 02:04.240 align:middle line:90%
So they're going to negotiate
as part of the IKE phase 1

52
02:04.240 --> 02:06.400 align:middle line:90%
tunnel which Diffie-Hellman
group do we want to use,

53
02:06.400 --> 02:08.317 align:middle line:90%
then they'll run
Diffie-Hellman, get the keys,

54
02:08.317 --> 02:09.610 align:middle line:84%
and they can use those keys.

55
02:09.610 --> 02:12.100 align:middle line:84%
And the A is for Authentication.

56
02:12.100 --> 02:14.140 align:middle line:90%
How do we want to
authenticate each other?

57
02:14.140 --> 02:16.540 align:middle line:90%
Do we want to use RSA
signatures, which implies

58
02:16.540 --> 02:18.100 align:middle line:84%
using digital certificates?

59
02:18.100 --> 02:21.310 align:middle line:90%
Or do we want to use pre-shared
keys for the authentication

60
02:21.310 --> 02:23.960 align:middle line:84%
of this IKE phase 1 tunnel?

61
02:23.960 --> 02:26.500 align:middle line:90%
So they're going to
negotiate, run Diffie-Hellman,

62
02:26.500 --> 02:28.940 align:middle line:90%
authenticate, and then they'll
have this private channel

63
02:28.940 --> 02:29.860 align:middle line:84%
that's now set up.

64
02:29.860 --> 02:31.630 align:middle line:90%
Now, the reason they
call this IKE phase 1
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

64
02:29.860 --> 02:31.630 align:middle line:90%
Now, the reason they
call this IKE phase 1

65
02:31.630 --> 02:34.180 align:middle line:90%
is because it's in preparation
for building the IKE

66
02:34.180 --> 02:34.960 align:middle line:84%
phase 2 tunnel.

67
02:34.960 --> 02:37.810 align:middle line:90%
So they can use the security
of IKE phase 1, this security

68
02:37.810 --> 02:40.490 align:middle line:90%
association, to go ahead and
build the IKE phase 2 tunnel.

69
02:40.490 --> 02:42.340 align:middle line:90%
So for the IKE
phase 2 tunnel, they

70
02:42.340 --> 02:44.400 align:middle line:90%
are going to
negotiate encryption.

71
02:44.400 --> 02:47.450 align:middle line:90%
They are going to
negotiate the hashing.

72
02:47.450 --> 02:51.190 align:middle line:90%
In IPsec we refer to that
as an HMAC, Hashed Message

73
02:51.190 --> 02:52.840 align:middle line:90%
Authentication
Code, which is going

74
02:52.840 --> 02:55.030 align:middle line:90%
to include some
cryptography, as far

75
02:55.030 --> 02:57.817 align:middle line:90%
as the secrets involved to
make it even a better hash.

76
02:57.817 --> 02:59.650 align:middle line:90%
They can also negotiate
for that IKE phase 2

77
02:59.650 --> 03:02.320 align:middle line:90%
tunnel the lifetime,
and also if they want
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
02:59.650 --> 03:02.320 align:middle line:90%
tunnel the lifetime,
and also if they want

78
03:02.320 --> 03:03.890 align:middle line:84%
to run Diffie-Hellman again.

79
03:03.890 --> 03:05.663 align:middle line:90%
So the option exists
to use the keys that

80
03:05.663 --> 03:07.330 align:middle line:90%
were generated earlier
by Diffie-Hellman

81
03:07.330 --> 03:09.220 align:middle line:90%
during IKE phase
1, or they can use

82
03:09.220 --> 03:12.250 align:middle line:90%
a technique called PFS, which
is Perfect Forward Secrecy.

83
03:12.250 --> 03:14.170 align:middle line:90%
And they'll basically
run Diffie-Hellman again

84
03:14.170 --> 03:16.120 align:middle line:90%
and get a new set of
shared keys that they

85
03:16.120 --> 03:19.810 align:middle line:90%
can use for the encryption and
decryption on the IKE phase 2

86
03:19.810 --> 03:20.360 align:middle line:84%
tunnel.

87
03:20.360 --> 03:22.450 align:middle line:84%
So this is the IKE phase 2.

88
03:22.450 --> 03:25.990 align:middle line:90%
And this is also referred to as
the IPsec security association,

89
03:25.990 --> 03:28.190 align:middle line:84%
or the IPsec tunnel.

90
03:28.190 --> 03:31.140 align:middle line:90%
And this is all
about IKE version 1.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
03:28.190 --> 03:31.140 align:middle line:90%
And this is all
about IKE version 1.

91
03:31.140 --> 03:33.610 align:middle line:90%
So IKE version 1 has two
phases, the phase 1 tunnel,

92
03:33.610 --> 03:36.203 align:middle line:90%
like a private party line, and
then the IKE phase 2 tunnel,

93
03:36.203 --> 03:38.120 align:middle line:90%
which is actually used
to encrypt the traffic.

94
03:38.120 --> 03:40.480 align:middle line:90%
So for protecting the
data from 10.1.0 to 10.2.0

95
03:40.480 --> 03:42.665 align:middle line:90%
on this site-to-site
VPN, traffic

96
03:42.665 --> 03:45.040 align:middle line:90%
from this PC when it hits the
router, based on the router

97
03:45.040 --> 03:47.650 align:middle line:90%
seeing it, and having the
right cryptography implemented

98
03:47.650 --> 03:50.592 align:middle line:90%
would say, ooh, I need to wrap
this up, encrypt it, and then

99
03:50.592 --> 03:53.050 align:middle line:90%
ship it to my peer, who then
would go ahead and decrypt it.

100
03:53.050 --> 03:55.633 align:middle line:90%
And all that traffic is going
to be sent-- the user traffic is

101
03:55.633 --> 03:58.690 align:middle line:90%
sent over the IKE phase 2
tunnel, or the IPsec security

102
03:58.690 --> 03:59.710 align:middle line:84%
association.

103
03:59.710 --> 04:02.770 align:middle line:90%
Also, be aware that
during the IKE phase 1,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

103
03:59.710 --> 04:02.770 align:middle line:90%
Also, be aware that
during the IKE phase 1,

104
04:02.770 --> 04:06.040 align:middle line:90%
these guys have the opportunity
to do NAT detection,

105
04:06.040 --> 04:08.380 align:middle line:90%
to identify, hey, is there
NAT running somewhere

106
04:08.380 --> 04:09.550 align:middle line:84%
between the peers.

107
04:09.550 --> 04:12.190 align:middle line:90%
And if there is,
then the IKE phase 2

108
04:12.190 --> 04:14.890 align:middle line:90%
tunnel, the IPsec tunnel
itself, can decide,

109
04:14.890 --> 04:16.420 align:middle line:84%
oh, there's NAT between us.

110
04:16.420 --> 04:19.060 align:middle line:90%
I need to go ahead and do some
trickery called NAT traversal

111
04:19.060 --> 04:20.193 align:middle line:84%
or NAT transparency.

112
04:20.193 --> 04:21.860 align:middle line:90%
And we'll have a
separate video on that.

113
04:21.860 --> 04:25.090 align:middle line:90%
But that also happens during
IKE phase 1, the detection of

114
04:25.090 --> 04:26.850 align:middle line:90%
whether or not
there is NAT or PAT

115
04:26.850 --> 04:28.648 align:middle line:84%
devices between the two peers.

116
04:28.648 --> 04:30.190 align:middle line:90%
And now the question
we get to answer
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

116
04:28.648 --> 04:30.190 align:middle line:90%
And now the question
we get to answer

117
04:30.190 --> 04:33.910 align:middle line:90%
is how does that compare
to IKE version 2.

118
04:33.910 --> 04:34.870 align:middle line:84%
Let's take a look.

119
04:34.870 --> 04:37.473 align:middle line:90%
Now, with IKE version 2,
here are some of the benefits

120
04:37.473 --> 04:39.140 align:middle line:90%
before we talk about
the implementation.

121
04:39.140 --> 04:41.380 align:middle line:90%
Some of the benefits
include the ability

122
04:41.380 --> 04:43.360 align:middle line:90%
to support additional
authentication methods,

123
04:43.360 --> 04:45.687 align:middle line:90%
like Extensible
Authentication Protocol.

124
04:45.687 --> 04:47.770 align:middle line:90%
Also, instead of calling
the security associations

125
04:47.770 --> 04:50.620 align:middle line:90%
phase 1 and phase 2
respectively, with IKE version

126
04:50.620 --> 04:52.330 align:middle line:90%
2 there is going
to be a security

127
04:52.330 --> 04:55.143 align:middle line:90%
association between
these two VPN endpoints.

128
04:55.143 --> 04:56.560 align:middle line:90%
And the first
security association

129
04:56.560 --> 05:00.340 align:middle line:90%
is called the IKEv2 SA
for Security Association.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
04:56.560 --> 05:00.340 align:middle line:90%
is called the IKEv2 SA
for Security Association.

130
05:00.340 --> 05:01.880 align:middle line:90%
And then what's
going to happen is

131
05:01.880 --> 05:06.080 align:middle line:90%
it's going to build child
security associations.

132
05:06.080 --> 05:09.123 align:middle line:90%
In this case, it would be the
IPsec security association

133
05:09.123 --> 05:10.790 align:middle line:90%
where we can actually
encrypt the user's

134
05:10.790 --> 05:12.950 align:middle line:84%
traffic over that IPsec SA.

135
05:12.950 --> 05:15.220 align:middle line:90%
So they don't literally
refer to these as phases.

136
05:15.220 --> 05:16.887 align:middle line:90%
Although, you could
think, well, there's

137
05:16.887 --> 05:18.230 align:middle line:84%
two stages or two processes.

138
05:18.230 --> 05:21.288 align:middle line:90%
But at the end of the
day, it's the IKEv2 SA

139
05:21.288 --> 05:22.580 align:middle line:84%
that's going to be established.

140
05:22.580 --> 05:25.340 align:middle line:90%
And then it'll spin off
additional child SAs

141
05:25.340 --> 05:26.940 align:middle line:84%
for IPsec as needed.

142
05:26.940 --> 05:29.420 align:middle line:90%
So if we have a hub and
spoke, or multiple security

143
05:29.420 --> 05:31.802 align:middle line:90%
associations that we need,
the IKEv2 will be in place.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

143
05:29.420 --> 05:31.802 align:middle line:90%
associations that we need,
the IKEv2 will be in place.

144
05:31.802 --> 05:34.010 align:middle line:90%
And it can use that tunnel
to negotiate and establish

145
05:34.010 --> 05:35.250 align:middle line:84%
the additional tunnels.

146
05:35.250 --> 05:37.670 align:middle line:90%
And the relationship would
be child tunnels as opposed

147
05:37.670 --> 05:39.035 align:middle line:84%
to phase 2 tunnels.

148
05:39.035 --> 05:42.603 align:middle line:90%
IKE version 2 also
supports NAT detection.

149
05:42.603 --> 05:44.520 align:middle line:90%
So if we're going through
a NAT or PAT device,

150
05:44.520 --> 05:47.420 align:middle line:90%
IKEv2 also has the
ability to identify that.

151
05:47.420 --> 05:51.770 align:middle line:90%
Also, with IKEv2, as newer and
stronger protocols come out

152
05:51.770 --> 05:53.720 align:middle line:90%
for encryption and
hashing, they're

153
05:53.720 --> 05:57.380 align:middle line:90%
going to be adopted as part of
IKEv2, where the IKE version 1

154
05:57.380 --> 06:00.290 align:middle line:90%
really isn't adopting
any brand new protocols
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

154
05:57.380 --> 06:00.290 align:middle line:90%
really isn't adopting
any brand new protocols

155
06:00.290 --> 06:01.910 align:middle line:90%
and using a lot
of new protocols.

156
06:01.910 --> 06:04.310 align:middle line:90%
All the new work and
all the new protocols

157
06:04.310 --> 06:07.582 align:middle line:90%
are going to be adopted as part
of IKEv2 in the IPsec family.

158
06:07.582 --> 06:10.040 align:middle line:90%
And just like any technology,
when there's something newer,

159
06:10.040 --> 06:12.540 align:middle line:90%
there's additional features and
functions that are built-in.

160
06:12.540 --> 06:14.955 align:middle line:90%
For example, if you had
a smartphone version 12

161
06:14.955 --> 06:16.580 align:middle line:90%
and now you've got
a smartphone version

162
06:16.580 --> 06:18.172 align:middle line:90%
13 from the same
vendor, it's very

163
06:18.172 --> 06:20.630 align:middle line:90%
likely there's going to be some
new and additional features

164
06:20.630 --> 06:22.353 align:middle line:90%
that they baked into
that new version.

165
06:22.353 --> 06:24.770 align:middle line:90%
So with IKE version 2, there's
some additional protections

166
06:24.770 --> 06:26.690 align:middle line:84%
for denial of service attacks.

167
06:26.690 --> 06:29.330 align:middle line:90%
To prevent against that, if
we're in a Cisco environment

168
06:29.330 --> 06:32.360 align:middle line:90%
and using IKE version 2, we
have more flexibility as far as
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
06:29.330 --> 06:32.360 align:middle line:90%
and using IKE version 2, we
have more flexibility as far as

169
06:32.360 --> 06:33.260 align:middle line:84%
how we can connect.

170
06:33.260 --> 06:36.980 align:middle line:90%
So if we had R1, it was doing
a site-to-site VPN here,

171
06:36.980 --> 06:39.050 align:middle line:84%
and a remote access VPN here.

172
06:39.050 --> 06:41.210 align:middle line:90%
We have a lot of
flexibility with IKEv2

173
06:41.210 --> 06:44.000 align:middle line:90%
as far as the
policies and proposals

174
06:44.000 --> 06:45.540 align:middle line:84%
and profiles that we use.

175
06:45.540 --> 06:48.020 align:middle line:90%
So we can implement the
correct cryptography

176
06:48.020 --> 06:51.110 align:middle line:90%
based on is it traffic coming
in from a site-to-site tunnel,

177
06:51.110 --> 06:54.110 align:middle line:90%
or a remote access tunnel,
or a combination of both.

178
06:54.110 --> 06:56.330 align:middle line:90%
Those are some of the
differences between IKE version

179
06:56.330 --> 06:57.547 align:middle line:84%
1 and version 2.

180
06:57.547 --> 06:59.630 align:middle line:90%
And we'll have a chance
in separate sets of videos

181
06:59.630 --> 07:01.160 align:middle line:84%
to see that in action.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

181
06:59.630 --> 07:01.160 align:middle line:84%
to see that in action.

182
07:01.160 --> 07:05.390 align:middle line:90%
As we do traditional IPsec, like
site-to-site with crypto maps,

183
07:05.390 --> 07:07.880 align:middle line:90%
we're going to be using
the older IKE version 1.

184
07:07.880 --> 07:09.800 align:middle line:90%
If we're doing
FlexVPN, whether it's

185
07:09.800 --> 07:12.830 align:middle line:90%
remote access or site-to-site
VPNs with FlexVPN,

186
07:12.830 --> 07:14.600 align:middle line:90%
that would be using
IKE version 2.

187
07:14.600 --> 07:17.270 align:middle line:90%
So you'll have a chance to
see both of those in action

188
07:17.270 --> 07:19.530 align:middle line:90%
as we proceed through these
sets of videos together.

189
07:19.530 --> 07:22.310 align:middle line:90%
So in the next video, what I'd
like to do is chat with you

190
07:22.310 --> 07:23.870 align:middle line:90%
about some different
options that we

191
07:23.870 --> 07:26.690 align:middle line:90%
have for implementing the
cryptography, including

192
07:26.690 --> 07:28.540 align:middle line:84%
the option of using crypto maps.

193
07:28.540 --> 07:30.430 align:middle line:90%
And regarding crypto
maps, in the next video,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

193
07:28.540 --> 07:30.430 align:middle line:90%
And regarding crypto
maps, in the next video,

194
07:30.430 --> 07:32.270 align:middle line:90%
I'd like to give you
an inside look at what

195
07:32.270 --> 07:34.640 align:middle line:90%
is a crypto map, why
we used it, and where

196
07:34.640 --> 07:36.832 align:middle line:90%
we might find it in a
production environment today.

197
07:36.832 --> 07:38.790 align:middle line:90%
So I'll see you in that
video in just a moment.

198
07:38.790 --> 07:41.300 align:middle line:90%
Meanwhile, I hope this has
been informative for you.

199
07:41.300 --> 07:44.560 align:middle line:90%
And I'd like to thank
you for viewing.