WEBVTT

1
00:00.000 --> 00:08.110
Well, as part of the IPsec implementation, the industry created ISA camp, which

2
00:08.110 --> 00:08.360
stands

3
00:08.360 --> 00:13.800
for the Internet Security Association Key Management Protocol.

4
00:13.800 --> 00:19.900
This is a way for us to manage our security keys, but once again, this is a

5
00:19.900 --> 00:21.120
framework.

6
00:21.120 --> 00:24.200
It is not itself a protocol.

7
00:24.200 --> 00:29.990
So the protocol that was developed out of ISA camp is known as the Internet Key

8
00:29.990 --> 00:30.920
Exchange,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:29.990 --> 00:30.920
Exchange,

9
00:30.920 --> 00:32.640
or IKE.

10
00:32.640 --> 00:37.120
Now the Internet Key Exchange has two different versions, and we're expected to

11
00:37.120 --> 00:37.720
know both

12
00:37.720 --> 00:43.600
of these versions, so we're going to talk about both of these in this skill.

13
00:43.600 --> 00:47.870
But it's important to understand what exactly are these keys we're talking

14
00:47.870 --> 00:48.520
about?

15
00:48.520 --> 00:50.440
What are we trying to accomplish?

16
00:50.440 --> 00:55.650
Well, when two devices want to form a secure connection with one another, they

17
00:55.650 --> 00:56.400
're going

18
00:56.400 --> 01:03.520
to use the concept of keys in order to lock up the data.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:56.400 --> 01:03.520
to use the concept of keys in order to lock up the data.

19
01:03.520 --> 01:08.490
It's sort of thinking along the lines of having a lockpad here, and the keys

20
01:08.490 --> 01:09.400
are what's going

21
01:09.400 --> 01:15.040
to be used to not only lock the file, the data that we're sending.

22
01:15.040 --> 01:19.150
We're kind of trying to lock it up with encryption, but it's also going to be

23
01:19.150 --> 01:20.260
how we unlock it

24
01:20.260 --> 01:21.820
on the other side.

25
01:21.820 --> 01:28.200
So I can scramble the information up with encryption, send this jumbled mess

26
01:28.200 --> 01:29.600
across the Internet.

27
01:29.600 --> 01:33.330
So anybody here in the middle, any thread actor listening in, won't be able to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
01:29.600 --> 01:33.330
So anybody here in the middle, any thread actor listening in, won't be able to

28
01:33.330 --> 01:34.000
understand

29
01:34.000 --> 01:38.550
this because it's been encrypted, it's been locked up using this key, and then

30
01:38.550 --> 01:39.160
the other

31
01:39.160 --> 01:44.380
side is able to take this jumbled mess and turn it into actual data on the

32
01:44.380 --> 01:45.560
other side,

33
01:45.560 --> 01:48.000
because again, they have the key.

34
01:48.000 --> 01:53.700
So these keys are very important to how we encrypt and decrypt data.

35
01:53.700 --> 01:57.240
Now we're not going to dive into the nitty gritty details of how encryption and

36
01:57.240 --> 01:57.900
decryption

37
01:57.900 --> 02:00.700
works and how exactly this all comes together.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:57.900 --> 02:00.700
works and how exactly this all comes together.

38
02:00.700 --> 02:03.580
It's actually very fascinating how we do that.

39
02:03.580 --> 02:08.580
But we do have this information here on CBT nuggets within our content library.

40
02:08.580 --> 02:13.070
It just understands it goes outside the scope of this conversation, but it also

41
02:13.070 --> 02:13.900
goes outside

42
02:13.900 --> 02:17.060
the scope of the course and the exam.

43
02:17.060 --> 02:21.470
And so if you want to know more about it, this is where we're drilling in more

44
02:21.470 --> 02:21.980
to CCNP

45
02:21.980 --> 02:23.200
security types of topics.

46
02:23.200 --> 02:29.220
But again, we do have a sec core CCNP security core as an option.

47
02:29.220 --> 02:32.810
We've also got plenty of other security courses that walk through how exactly
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

47
02:29.220 --> 02:32.810
We've also got plenty of other security courses that walk through how exactly

48
02:32.810 --> 02:33.540
encryption and

49
02:33.540 --> 02:37.700
decryption works using these encryption keys.

50
02:37.700 --> 02:42.770
So what we need to know and take away from this conversation is this exchange

51
02:42.770 --> 02:43.420
needs to

52
02:43.420 --> 02:45.980
happen in a very secure manner.

53
02:45.980 --> 02:51.180
And so that is exactly what Ike or internet key exchange is going to do for us.

54
02:51.180 --> 02:54.100
Now as I mentioned, there are two different versions of Ike and so we're going

55
02:54.100 --> 02:54.740
to go through

56
02:54.740 --> 02:58.660
those and we're going to start with Ike version one.

57
02:58.660 --> 03:01.140
Now for the most part, we want to be using Ike version two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

57
02:58.660 --> 03:01.140
Now for the most part, we want to be using Ike version two.

58
03:01.140 --> 03:04.460
It's the more modern version, but not all platforms support it.

59
03:04.460 --> 03:07.980
And so that's why we need to understand Ike V one as much as we understand Ike

60
03:07.980 --> 03:08.420
V two.

61
03:08.420 --> 03:11.620
And there's actually a lot more to understand about Ike V one.

62
03:11.620 --> 03:14.460
Ike V two actually simplifies a lot of things.

63
03:14.460 --> 03:18.350
And so we're going to spend actually a disproportionate amount of time on Ike

64
03:18.350 --> 03:20.020
version one, even though

65
03:20.020 --> 03:23.540
we prefer to use Ike version two in production networks.

66
03:23.540 --> 03:28.260
So Ike V one, the way this works is actually broken up into two phases.

67
03:28.260 --> 03:31.380
So we have phase one and phase two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
03:28.260 --> 03:31.380
So we have phase one and phase two.

68
03:31.380 --> 03:34.500
So we're going to start here with phase one.

69
03:34.500 --> 03:40.400
And the goal of phase one is sort of to establish the control plane of our

70
03:40.400 --> 03:42.620
secure communications.

71
03:42.620 --> 03:45.580
So phase one is about establishing a control plane.

72
03:45.580 --> 03:49.300
Then phase two is going to be about establishing a data plane.

73
03:49.300 --> 03:53.770
But either way, we just need to establish communications between our two

74
03:53.770 --> 03:54.580
devices.

75
03:54.580 --> 03:59.710
So this is sort of the initiation point, how exactly do we enable communication

76
03:59.710 --> 04:00.380
and enable
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

76
03:59.710 --> 04:00.380
and enable

77
04:00.380 --> 04:05.120
the exchange of our keys and also negotiate all of the security parameters like

78
04:05.120 --> 04:05.500
we alluded

79
04:05.500 --> 04:09.710
to at the end of the last video needing to decide different authentication

80
04:09.710 --> 04:10.500
encryption

81
04:10.500 --> 04:11.820
means.

82
04:11.820 --> 04:13.380
Well, this is what we have to do.

83
04:13.380 --> 04:16.900
We have to decide and make a bunch of decisions.

84
04:16.900 --> 04:21.980
And my friend Keith Barker here at CBT Nuggets, he calls this the haggle.

85
04:21.980 --> 04:26.300
Now you might notice that haggle is misspelled, especially if you know English.

86
04:26.300 --> 04:30.330
When you're talking about haggling, you're usually talking about negotiating,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
04:26.300 --> 04:30.330
When you're talking about haggling, you're usually talking about negotiating,

87
04:30.330 --> 04:30.780
right?

88
04:30.780 --> 04:33.930
Like I go to a flea market and I'm trying to haggle over the price about

89
04:33.930 --> 04:34.740
something.

90
04:34.740 --> 04:36.980
Let's build with two G's.

91
04:36.980 --> 04:38.140
So what are we trying to say here?

92
04:38.140 --> 04:42.340
Well, this is an acronym and we're still sort of haggling with one another.

93
04:42.340 --> 04:45.950
We're sort of these two devices are trying to figure out how they're going to

94
04:45.950 --> 04:46.780
interoperate

95
04:46.780 --> 04:48.420
and work together.

96
04:48.420 --> 04:52.540
But again, now we're going to turn haggle into an acronym.

97
04:52.540 --> 04:57.560
So the H here is going to say that, hey, we've got to figure out the hashing

98
04:57.560 --> 04:58.300
method.

99
04:58.300 --> 05:00.620
So we mentioned this is for authentication.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
04:58.300 --> 05:00.620
So we mentioned this is for authentication.

100
05:00.620 --> 05:06.340
This is going to be MD five or it's going to be shot.

101
05:06.340 --> 05:10.180
So two different hashing methods and we just have to decide between the two.

102
05:10.180 --> 05:13.660
We also need to decide our authentication mechanism.

103
05:13.660 --> 05:16.780
So are we going to add a pre shared key?

104
05:16.780 --> 05:19.220
Are we going to use certificates?

105
05:19.220 --> 05:24.220
And so the hashing algorithm and the authentication kind of come together here.

106
05:24.220 --> 05:27.140
We also have to decide the group.

107
05:27.140 --> 05:28.620
The group ID is interesting.

108
05:28.620 --> 05:32.660
This has to do with what we call Diffie Hellman.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

108
05:28.620 --> 05:32.660
This has to do with what we call Diffie Hellman.

109
05:32.660 --> 05:39.810
Diffie Hellman is the way by which we can securely exchange keys in on an open

110
05:39.810 --> 05:40.860
network.

111
05:40.860 --> 05:43.680
Might have noticed the situation over here, you say, well, wait a second, we

112
05:43.680 --> 05:44.700
have to exchange

113
05:44.700 --> 05:49.740
keys and yet this thread actor could be right in the middle listening in.

114
05:49.740 --> 05:54.340
Maybe we think about even something like this where I'm at a cafe and there's a

115
05:54.340 --> 05:55.020
wireless

116
05:55.020 --> 06:00.180
access point here and this laptop trying to connect and we need to secure
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

116
05:55.020 --> 06:00.180
access point here and this laptop trying to connect and we need to secure

117
06:00.180 --> 06:01.460
communications

118
06:01.460 --> 06:02.460
with one another.

119
06:02.460 --> 06:06.300
Meanwhile, the thread actors right here listening in to the wireless

120
06:06.300 --> 06:07.480
communications.

121
06:07.480 --> 06:12.020
So this is an even easier scenario, but certainly thread actors can have ways

122
06:12.020 --> 06:13.020
of intercepting

123
06:13.020 --> 06:15.820
communications out on the internet as well.

124
06:15.820 --> 06:21.420
So we're not safe regardless of the underlay in this particular situation.

125
06:21.420 --> 06:26.750
So how do we go about exchanging keys in such a way that everybody can listen

126
06:26.750 --> 06:27.340
into this

127
06:27.340 --> 06:31.620
process and yet they can't figure out what the keys are.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

127
06:27.340 --> 06:31.620
process and yet they can't figure out what the keys are.

128
06:31.620 --> 06:35.910
It's pretty fascinating and really involves a lot of complex math and the

129
06:35.910 --> 06:36.860
operation that

130
06:36.860 --> 06:40.620
we use here is known as a Diffie Hellman exchange.

131
06:40.620 --> 06:44.670
Now there's lots of different Diffie Hellman exchanges and we typically refer

132
06:44.670 --> 06:45.100
to these

133
06:45.100 --> 06:48.220
different versions as different groups.

134
06:48.220 --> 06:52.650
It emphasizes the security mechanism used and things have changed and evolved

135
06:52.650 --> 06:53.780
over time

136
06:53.780 --> 06:59.070
and so usually we're going to see that this group ID is 14 or above because

137
06:59.070 --> 06:59.940
this is the

138
06:59.940 --> 07:04.600
threshold for what we'd consider to be modern Diffie Hellman exchanges these
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

138
06:59.940 --> 07:04.600
threshold for what we'd consider to be modern Diffie Hellman exchanges these

139
07:04.600 --> 07:05.180
days.

140
07:05.180 --> 07:08.900
So just keep in mind that we have to decide a Diffie Hellman group and we have

141
07:08.900 --> 07:09.340
to again

142
07:09.340 --> 07:10.340
agree on this.

143
07:10.340 --> 07:13.220
We can't use two different methods for exchanging keys.

144
07:13.220 --> 07:16.340
We have to lock in on the same group ID.

145
07:16.340 --> 07:19.940
So this is going to help us to exchange our keys.

146
07:19.940 --> 07:27.980
Now we also have to decide a lifetime, meaning when does this session expire?

147
07:27.980 --> 07:31.060
We don't necessarily want to keep this session around forever.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

147
07:27.980 --> 07:31.060
We don't necessarily want to keep this session around forever.

148
07:31.060 --> 07:35.390
It might be insecure to keep it around forever because the longer we have this

149
07:35.390 --> 07:36.380
communication

150
07:36.380 --> 07:41.120
going, the longer that this threat actor might just be able to sort of guess

151
07:41.120 --> 07:41.940
keys and run

152
07:41.940 --> 07:45.660
dictionary attacks and those kinds of brute force methods.

153
07:45.660 --> 07:49.590
So we don't want to necessarily leave this online for that long because the

154
07:49.590 --> 07:50.220
longer it's

155
07:50.220 --> 07:52.980
online, the more time they would have to brute force things.

156
07:52.980 --> 07:59.890
So we expire this session at some point and then the last piece of the puzzle

157
07:59.890 --> 08:00.540
here is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

157
07:59.890 --> 08:00.540
here is

158
08:00.540 --> 08:03.260
going to be our encryption method.

159
08:03.260 --> 08:07.110
So in the modern network, we're probably going to select AES, which is the

160
08:07.110 --> 08:08.180
advanced encryption

161
08:08.180 --> 08:09.440
standard.

162
08:09.440 --> 08:14.260
But just keep in mind we have to decide which version of AES to run and so on

163
08:14.260 --> 08:15.420
and so forth.

164
08:15.420 --> 08:21.500
Now notice that we're performing these communications back and forth and we

165
08:21.500 --> 08:23.500
haven't yet established

166
08:23.500 --> 08:27.260
secure communications, which means that this encryption method that we're

167
08:27.260 --> 08:28.020
talking about

168
08:28.020 --> 08:33.180
here is not going to impact this first phase one tunnel.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
08:28.020 --> 08:33.180
here is not going to impact this first phase one tunnel.

169
08:33.180 --> 08:39.330
This is going to impact our phase two tunnel, which is again, I'll say for

170
08:39.330 --> 08:40.500
phase two, which

171
08:40.500 --> 08:46.420
is again going to be for our data plane of operations.

172
08:46.420 --> 08:53.300
Now phase one actually has two different methods or modes that we can perform

173
08:53.300 --> 08:54.940
this with.

174
08:54.940 --> 08:57.420
One is going to be a little bit more lightweight and faster.

175
08:57.420 --> 09:00.540
The other one's going to be heavier and more secure.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

175
08:57.420 --> 09:00.540
The other one's going to be heavier and more secure.

176
09:00.540 --> 09:05.500
The first one, which is the heavier option, is going to be known as main mode.

177
09:05.500 --> 09:09.420
And this is typically abbreviated as MM.

178
09:09.420 --> 09:14.260
If we're talking about I could be one and we're doing research, we might see

179
09:14.260 --> 09:14.780
this MM show

180
09:14.780 --> 09:18.920
up in white papers and so understand that that's what we're talking about here.

181
09:18.920 --> 09:24.060
Main mode is going to consist of six different messages that go back and forth

182
09:24.060 --> 09:24.780
in order to

183
09:24.780 --> 09:28.620
perform everything that we need to perform in phase one.

184
09:28.620 --> 09:33.740
Furthermore, it's also going to offer a little bit more protection around
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

184
09:28.620 --> 09:33.740
Furthermore, it's also going to offer a little bit more protection around

185
09:33.740 --> 09:35.500
identities.

186
09:35.500 --> 09:40.310
So keep in mind that these devices, they have identities on the internet and we

187
09:40.310 --> 09:41.300
don't necessarily

188
09:41.300 --> 09:44.220
just want to broadcast everything in plain text.

189
09:44.220 --> 09:48.560
We might want to try to secure some of these communications and main mode

190
09:48.560 --> 09:49.820
taking more message

191
09:49.820 --> 09:53.740
time into account allows us to actually perform some initial plain text

192
09:53.740 --> 09:54.900
communications and

193
09:54.900 --> 09:57.980
then secure the latter messages.

194
09:57.980 --> 10:03.510
As with everything, the more we secure things, the more important it is that we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

194
09:57.980 --> 10:03.510
As with everything, the more we secure things, the more important it is that we

195
10:03.510 --> 10:04.300
have good

196
10:04.300 --> 10:08.280
processing, especially if we're doing a lot of negotiations every second or

197
10:08.280 --> 10:08.940
whatever the

198
10:08.940 --> 10:10.580
situation is.

199
10:10.580 --> 10:17.230
And so that's why we do have an aggressive mode of operation, which doesn't

200
10:17.230 --> 10:18.620
itself necessarily

201
10:18.620 --> 10:21.900
sound like it's lighter or less secure.

202
10:21.900 --> 10:28.800
But the idea here is that instead of six messages, we're only going to send

203
10:28.800 --> 10:30.340
three messages.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

203
10:28.800 --> 10:30.340
three messages.

204
10:30.340 --> 10:35.940
And as we might imagine, three messages doesn't allow us to talk much in plain

205
10:35.940 --> 10:37.100
text and still

206
10:37.100 --> 10:40.380
have things left over to say that we could encrypt.

207
10:40.380 --> 10:45.040
And so again, we might or we're not going to see this protection for the

208
10:45.040 --> 10:46.140
identifiers.

209
10:46.140 --> 10:49.820
However, it is a whole lot faster than main mode.

210
10:49.820 --> 10:54.420
And again, it is going to require fewer resources.

211
10:54.420 --> 10:59.180
Now both of these have the same end result.

212
10:59.180 --> 11:06.050
And the same end result and the goal of IKEV one is to lead to like I said,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

212
10:59.180 --> 11:06.050
And the same end result and the goal of IKEV one is to lead to like I said,

213
11:06.050 --> 11:07.380
phase one,

214
11:07.380 --> 11:09.580
the goal is to get to phase two.

215
11:09.580 --> 11:11.500
So what exactly is phase two?

216
11:11.500 --> 11:16.420
Well phase two is the point at which we establish the data plane tunnel.

217
11:16.420 --> 11:24.340
So again, this is the tunnel that we want to use for our actual throughput, our

218
11:24.340 --> 11:25.100
end user

219
11:25.100 --> 11:26.100
traffic.

220
11:26.100 --> 11:34.660
This is going to result in our overlay establishment and overlay traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

220
11:26.100 --> 11:34.660
This is going to result in our overlay establishment and overlay traffic.

221
11:34.660 --> 11:35.980
So this is the goal.

222
11:35.980 --> 11:39.940
It's great to establish a method of communication between the devices and to go

223
11:39.940 --> 11:40.700
back and forth

224
11:40.700 --> 11:44.310
like this and figure out how we want to do things and figure out the method for

225
11:44.310 --> 11:44.780
all of

226
11:44.780 --> 11:49.340
this and all of this is great, but that's itself is not the goal.

227
11:49.340 --> 11:51.660
That's just a means to the end.

228
11:51.660 --> 11:56.940
And so at the end of this is creating the actual data plane tunnel.

229
11:56.940 --> 12:02.190
So this is where we're going to pay attention to the transform set that we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

229
11:56.940 --> 12:02.190
So this is where we're going to pay attention to the transform set that we

230
12:02.190 --> 12:02.940
mentioned and

231
12:02.940 --> 12:06.620
all of the things that we negotiated as part of phase one.

232
12:06.620 --> 12:10.650
Furthermore, this when we talk about an IP sec tunnel, this is what we're

233
12:10.650 --> 12:11.620
talking about.

234
12:11.620 --> 12:15.420
We are talking about the phase two tunnel and just be aware that every now and

235
12:15.420 --> 12:16.140
again,

236
12:16.140 --> 12:20.980
we might actually hear this mentioned as an Ike tunnel as well.

237
12:20.980 --> 12:26.100
Just depending on what white papers you're reading and who's talking about it.

238
12:26.100 --> 12:30.660
Sometimes the vocabulary gets blended here a little bit.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

238
12:26.100 --> 12:30.660
Sometimes the vocabulary gets blended here a little bit.

239
12:30.660 --> 12:33.780
Phase two is going to use what we call quick mode.

240
12:33.780 --> 12:37.900
We say, well, are there two different modes of operation like before?

241
12:37.900 --> 12:41.220
No, we're just going to send quick mode messages.

242
12:41.220 --> 12:47.060
And this, like with MM and AM, this is abbreviated now as QM.

243
12:47.060 --> 12:54.870
And interestingly, this is going to create two, say, two unidirectional tunnels

244
12:54.870 --> 12:55.220
.

245
12:55.220 --> 12:59.770
This is a little bit different from before where actually we establish a bid

246
12:59.770 --> 13:00.500
irectional
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

246
12:59.770 --> 13:00.500
irectional

247
13:00.500 --> 13:07.180
tunnel between our two devices for the phase one tunnel.

248
13:07.180 --> 13:11.180
This ends up creating two unidirectional tunnels.

249
13:11.180 --> 13:16.540
So each router has its own way of sending traffic to the other side.

250
13:16.540 --> 13:21.180
So that is Ike version one from a phase one and phase two perspective.

251
13:21.180 --> 13:23.820
Just keep in mind the difference between phase one and phase two.

252
13:23.820 --> 13:27.520
We're really talking about the control plane and all the negotiations happening

253
13:27.520 --> 13:27.820
in phase

254
13:27.820 --> 13:33.660
one, the data plane and the actual sending of our data in the phase two tunnel.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

254
13:27.820 --> 13:33.660
one, the data plane and the actual sending of our data in the phase two tunnel.

255
13:33.660 --> 13:37.660
And one last note in all of this is we mentioned lifetime here.

256
13:37.660 --> 13:39.660
So how long does this all last?

257
13:39.660 --> 13:45.660
Well, the phase one tunnel is only going to last 24 hours by default.

258
13:45.660 --> 13:48.060
And you say, wow, that's not very long.

259
13:48.060 --> 13:52.380
That means every day we have to reestablish a new phase one tunnel.

260
13:52.380 --> 13:53.380
And that's true.

261
13:53.380 --> 13:55.580
But phase two is even more strict.

262
13:55.580 --> 13:59.340
Phase two is only going to last four hours by default.

263
13:59.340 --> 14:02.860
And so we're going to have to build new tunnels every four hours.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

263
13:59.340 --> 14:02.860
And so we're going to have to build new tunnels every four hours.

264
14:02.860 --> 14:07.090
Now we can change the lifetime of the tunnel if we so desire, but do understand

265
14:07.090 --> 14:07.340
that we

266
14:07.340 --> 14:09.660
can't extend an existing tunnel.

267
14:09.660 --> 14:13.800
If the expiration timer is reached, then we're going to have to tear down these

268
14:13.800 --> 14:14.300
phase two

269
14:14.300 --> 14:17.300
tunnels and or maybe even the phase one tunnel.

270
14:17.300 --> 14:21.200
And we're going to have to rebuild accordingly, just rebuild those tunnels from

271
14:21.200 --> 14:21.860
scratch.

272
14:21.860 --> 14:24.700
So that might end up disrupting our network traffic.

273
14:24.700 --> 14:30.180
But again, we want to prioritize our security and favor our ability to avoid
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

273
14:24.700 --> 14:30.180
But again, we want to prioritize our security and favor our ability to avoid

274
14:30.180 --> 14:31.100
brute force

275
14:31.100 --> 14:32.820
attacks.

276
14:32.820 --> 14:36.630
So the end of this whole conversation, we say, okay, well, that's great for a

277
14:36.630 --> 14:37.300
phase or for

278
14:37.300 --> 14:38.700
Ike v one.

279
14:38.700 --> 14:44.220
Do we want to pause and and how we'll have a whole breakdown of Ike v two?

280
14:44.220 --> 14:46.460
Well, now we're going to go ahead and talk about it here.

281
14:46.460 --> 14:49.820
And yes, this is probably enough space down here in the corner.

282
14:49.820 --> 14:54.620
There's not a lot to talk about with Ike v two because it sort of blends the

283
14:54.620 --> 14:55.260
process

284
14:55.260 --> 14:57.740
into a single phase of operation.

285
14:57.740 --> 15:01.590
We're going to accomplish all the same things, but we're going to take phase
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

285
14:57.740 --> 15:01.590
We're going to accomplish all the same things, but we're going to take phase

286
15:01.590 --> 15:02.380
one and phase

287
15:02.380 --> 15:07.620
two and put it into this single phase or the single process.

288
15:07.620 --> 15:12.660
It's only going to take four messages rather than going back and forth.

289
15:12.660 --> 15:16.740
We'll see, keep in mind, either six or three to start with.

290
15:16.740 --> 15:20.260
And then another, what do we say for quick mode?

291
15:20.260 --> 15:21.540
There were three messages.

292
15:21.540 --> 15:24.850
I don't know if we actually said that or not, but there were three messages in

293
15:24.850 --> 15:25.100
quick

294
15:25.100 --> 15:26.100
mode.

295
15:26.100 --> 15:28.460
So either have six or nine total messages.

296
15:28.460 --> 15:32.660
And that's been greatly reduced down to four messages, which is great.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

296
15:28.460 --> 15:32.660
And that's been greatly reduced down to four messages, which is great.

297
15:32.660 --> 15:36.860
And we have better encryption options.

298
15:36.860 --> 15:41.600
So that is going to be one of the primary drivers to use Ike v two because I

299
15:41.600 --> 15:42.180
could be

300
15:42.180 --> 15:43.580
one works great.

301
15:43.580 --> 15:46.930
There's nothing wrong with Ike v one as long as it actually maintains things

302
15:46.930 --> 15:47.620
securely,

303
15:47.620 --> 15:49.460
even if it's less efficient in the setup.

304
15:49.460 --> 15:54.370
Well, if we have better encryption options, namely different versions of AES or

305
15:54.370 --> 15:54.980
what have

306
15:54.980 --> 15:59.380
you that Ike v one doesn't support, that's going to be the primary driver of

307
15:59.380 --> 15:59.980
Ike v two.

308
15:59.980 --> 16:06.090
And it is important to note that if we have a device here running Ike v two,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

308
15:59.980 --> 16:06.090
And it is important to note that if we have a device here running Ike v two,

309
16:06.090 --> 16:06.980
and we have

310
16:06.980 --> 16:12.750
a device up here that can only run Ike v one, that these are going to be

311
16:12.750 --> 16:14.260
incompatible with

312
16:14.260 --> 16:16.140
one another.

313
16:16.140 --> 16:20.700
So we are going to have to have support for Ike v two on both devices.

314
16:20.700 --> 16:24.140
If we want to use Ike v two to build out our secure tunnels.

315
16:24.140 --> 16:28.280
But that is how I comes together again, a lot of our time was spent on Ike

316
16:28.280 --> 16:29.500
version one.

317
16:29.500 --> 16:34.350
And I know it feels a little backwards sometimes to spend that much time on the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

317
16:29.500 --> 16:34.350
And I know it feels a little backwards sometimes to spend that much time on the

318
16:34.350 --> 16:35.220
more legacy

319
16:35.220 --> 16:36.380
protocol.

320
16:36.380 --> 16:41.000
But we see that all the same information in Ike v one is what's negotiated in

321
16:41.000 --> 16:41.740
Ike v two.

322
16:41.740 --> 16:45.820
We can't really unpack Ike v two until we understand Ike v one.

323
16:45.820 --> 16:48.730
And as always, we want to pay attention to the blueprint and the scope of the

324
16:48.730 --> 16:49.100
course

325
16:49.100 --> 16:53.060
and exam in order to understand what we need to learn.

326
16:53.060 --> 16:56.340
And so we do, we should absolutely make sure we understand the two phase

327
16:56.340 --> 16:57.060
approach with

328
16:57.060 --> 16:58.060
Ike v one.

329
16:58.060 --> 17:01.940
We need to understand how that reduces to a single phase in Ike v two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

329
16:58.060 --> 17:01.940
We need to understand how that reduces to a single phase in Ike v two.

330
17:01.940 --> 17:07.110
And the fact that other than changing a little bit of message count, we do get

331
17:07.110 --> 17:07.780
some better

332
17:07.780 --> 17:11.420
encryption options and the two versions are incompatible with one another.