WEBVTT

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


2
00:01.030 --> 00:02.930 align:middle line:90%
When implementing
IPSec site-to-site VPN,

3
00:02.930 --> 00:04.930 align:middle line:90%
there's a couple of
different schools of thought

4
00:04.930 --> 00:05.920 align:middle line:84%
about how to get it done.

5
00:05.920 --> 00:07.878 align:middle line:90%
One is just throw some
stuff in and maybe it'll

6
00:07.878 --> 00:10.180 align:middle line:90%
stick, and then troubleshoot
your way out of there.

7
00:10.180 --> 00:12.220 align:middle line:90%
That's a very time
consuming process.

8
00:12.220 --> 00:14.613 align:middle line:90%
Now I want to walk you through
some of the verification

9
00:14.613 --> 00:15.530 align:middle line:84%
troubleshooting steps.

10
00:15.530 --> 00:17.405 align:middle line:90%
We'll do that for sure
in this set of videos.

11
00:17.405 --> 00:19.570 align:middle line:90%
So to start, let's take
a look at a topology.

12
00:19.570 --> 00:21.910 align:middle line:90%
Let's identify what
we need to accomplish

13
00:21.910 --> 00:23.740 align:middle line:90%
with the IPSec
site-to-site VPN tunnel.

14
00:23.740 --> 00:26.530 align:middle line:90%
And also just identify
at a fairly high level

15
00:26.530 --> 00:28.930 align:middle line:90%
of those components that we
have to think about before we

16
00:28.930 --> 00:30.860 align:middle line:84%
configure to make it work.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

16
00:28.930 --> 00:30.860 align:middle line:84%
configure to make it work.

17
00:30.860 --> 00:32.020 align:middle line:84%
So let's use this topology.

18
00:32.020 --> 00:34.000 align:middle line:90%
Let's imagine that we've
got these two sites.

19
00:34.000 --> 00:36.640 align:middle line:84%
We'll call router 1 over here--

20
00:36.640 --> 00:38.350 align:middle line:84%
let's call this site 1.

21
00:38.350 --> 00:40.220 align:middle line:84%
And over here, we'll call this--

22
00:40.220 --> 00:43.060 align:middle line:90%
for lack of a better name,
we'll call it site 2.

23
00:43.060 --> 00:44.360 align:middle line:84%
All Right, there we go.

24
00:44.360 --> 00:46.493 align:middle line:90%
Now if we have resource--
and these sites,

25
00:46.493 --> 00:48.910 align:middle line:90%
one could be a headquarters
and it could be a data center.

26
00:48.910 --> 00:49.952 align:middle line:84%
It really doesn't matter.

27
00:49.952 --> 00:52.600 align:middle line:90%
The goal is we want to share
information and resources

28
00:52.600 --> 00:54.950 align:middle line:84%
between these two sites.

29
00:54.950 --> 00:56.590 align:middle line:90%
And we want the
traffic to be protected

30
00:56.590 --> 00:59.440 align:middle line:90%
as it crosses over the
network or networks

31
00:59.440 --> 01:00.770 align:middle line:84%
between those sites.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

31
00:59.440 --> 01:00.770 align:middle line:84%
between those sites.

32
01:00.770 --> 01:02.604 align:middle line:90%
So over here on the
left, we have 10.1.0,

33
01:02.604 --> 01:04.390 align:middle line:84%
over here we have 10.2.0.

34
01:04.390 --> 01:06.610 align:middle line:90%
We use that as an
example to start with.

35
01:06.610 --> 01:09.920 align:middle line:90%
And what we want to have happen
is that if PC1, for example,

36
01:09.920 --> 01:14.950 align:middle line:90%
is trying to ping
PC2 at 10.2.0.50,

37
01:14.950 --> 01:18.880 align:middle line:90%
that traffic would be forwarded
to the default gateway of PC1.

38
01:18.880 --> 01:21.440 align:middle line:90%
R1 would get that packet, look
at the destination IP address

39
01:21.440 --> 01:25.570 align:middle line:90%
and say, well, this is coming
from 10.1 and going to 10.2.

40
01:25.570 --> 01:27.010 align:middle line:90%
I need to go ahead
and encrypt it.

41
01:27.010 --> 01:28.540 align:middle line:84%
So it's going to encrypt.

42
01:28.540 --> 01:31.990 align:middle line:90%
Also it'll use hash message
authentication code or anything
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

42
01:28.540 --> 01:31.990 align:middle line:90%
Also it'll use hash message
authentication code or anything

43
01:31.990 --> 01:33.678 align:middle line:90%
else we specified
with it as well,

44
01:33.678 --> 01:36.220 align:middle line:90%
and it'll take that, encrypt
it, wrap it up, and then ship it

45
01:36.220 --> 01:39.370 align:middle line:90%
as a protected packet over to
the reachable address of R2.

46
01:39.370 --> 01:42.610 align:middle line:90%
We will then decrypt it,
or add it on to PC2 so--

47
01:42.610 --> 01:46.480 align:middle line:90%
PC1 and PC2 are totally unaware
that this encryption happened.

48
01:46.480 --> 01:48.600 align:middle line:90%
They're just happy at the
packet, or I don't know.

49
01:48.600 --> 01:50.140 align:middle line:84%
Are computer's happy, maybe.

50
01:50.140 --> 01:52.480 align:middle line:90%
So it gets the packet
and responds back.

51
01:52.480 --> 01:54.190 align:middle line:90%
It would go back to
the default gateway.

52
01:54.190 --> 01:57.640 align:middle line:90%
R2 would say, Oh, this
is going from 10.2.0.50

53
01:57.640 --> 01:59.140 align:middle line:84%
over to 10.1.0.50.

54
01:59.140 --> 02:01.420 align:middle line:90%
That matches our interesting
traffic for IPSec.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

54
01:59.140 --> 02:01.420 align:middle line:90%
That matches our interesting
traffic for IPSec.

55
02:01.420 --> 02:04.030 align:middle line:90%
He would encrypt it or she would
encrypt it and send it over

56
02:04.030 --> 02:08.043 align:middle line:90%
to R1, who would then decrypt
it and forward on its way back.

57
02:08.043 --> 02:08.710 align:middle line:84%
So that's great.

58
02:08.710 --> 02:10.300 align:middle line:90%
So what are some
of the elements we

59
02:10.300 --> 02:12.670 align:middle line:90%
need to plan for
to make this all

60
02:12.670 --> 02:16.960 align:middle line:90%
work if we're doing traditional
IPSec site-to-site VPNs?

61
02:16.960 --> 02:19.835 align:middle line:90%
Well, if we're using
IKE version 1--

62
02:19.835 --> 02:21.460 align:middle line:90%
and we'll have separate
videos and sets

63
02:21.460 --> 02:24.820 align:middle line:90%
of videos on IKE version
2, but with IKE version 1,

64
02:24.820 --> 02:25.990 align:middle line:84%
there's two phases.

65
02:25.990 --> 02:28.200 align:middle line:90%
And one of those
phases is called IKE.

66
02:28.200 --> 02:30.540 align:middle line:90%
IKE is an acronym for
Internet Key Exchange,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
02:28.200 --> 02:30.540 align:middle line:90%
IKE is an acronym for
Internet Key Exchange,

67
02:30.540 --> 02:32.920 align:middle line:84%
and it's called phase 1.

68
02:32.920 --> 02:35.650 align:middle line:90%
I'm very grateful because
they were engineers.

69
02:35.650 --> 02:38.290 align:middle line:90%
I'm very grateful they
didn't call it IKE phase 0,

70
02:38.290 --> 02:42.580 align:middle line:90%
but IKE phase 1 is the details
about the initial tunnel

71
02:42.580 --> 02:45.140 align:middle line:90%
that R1 and R2 are going
to set up with each other.

72
02:45.140 --> 02:47.020 align:middle line:90%
So it's called the
IKE phase 1 tunnel.

73
02:47.020 --> 02:50.270 align:middle line:90%
And to set that up, we need
to agree on certain things,

74
02:50.270 --> 02:51.875 align:middle line:84%
including the authentication.

75
02:51.875 --> 02:54.250 align:middle line:90%
So how are these two routers,
that they built the tunnel,

76
02:54.250 --> 02:57.352 align:middle line:90%
how are they going to prove to
each other they are authorized

77
02:57.352 --> 02:58.435 align:middle line:84%
and who they say they are?

78
02:58.435 --> 03:00.340 align:middle line:90%
Are we going to use a
pre-shared key on each one?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

78
02:58.435 --> 03:00.340 align:middle line:90%
Are we going to use a
pre-shared key on each one?

79
03:00.340 --> 03:01.840 align:middle line:90%
Are we going to use
digital signatures?

80
03:01.840 --> 03:02.882 align:middle line:84%
What are we going to use?

81
03:02.882 --> 03:04.810 align:middle line:90%
So we need to decide
on that, and then

82
03:04.810 --> 03:07.570 align:middle line:90%
implement that solution
if we want the IKE phase 1

83
03:07.570 --> 03:08.590 align:middle line:84%
tunnel to work.

84
03:08.590 --> 03:10.810 align:middle line:90%
We'd also need to
plan on the hashing

85
03:10.810 --> 03:12.290 align:middle line:84%
that we're going to use.

86
03:12.290 --> 03:14.300 align:middle line:90%
Now the hashing is
for data integrity.

87
03:14.300 --> 03:17.410 align:middle line:90%
So if a bit gets manipulated
or a packet gets manipulated,

88
03:17.410 --> 03:19.720 align:middle line:90%
I should say, the other
side can say, well,

89
03:19.720 --> 03:22.320 align:middle line:90%
this doesn't match up, and
discard it, and not accept it.

90
03:22.320 --> 03:24.640 align:middle line:90%
So hashing is about
data integrity.

91
03:24.640 --> 03:26.290 align:middle line:90%
And we might be
limited by the iOS

92
03:26.290 --> 03:28.340 align:middle line:90%
as far as which hashing
methods are supported.

93
03:28.340 --> 03:31.480 align:middle line:90%
So if this guy supports
like five great options,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
03:28.340 --> 03:31.480 align:middle line:90%
So if this guy supports
like five great options,

94
03:31.480 --> 03:33.932 align:middle line:90%
and this guy has two
fairly good options,

95
03:33.932 --> 03:35.390 align:middle line:90%
we might have to
settle on matching

96
03:35.390 --> 03:37.630 align:middle line:90%
on one of the good options
and use that because it's

97
03:37.630 --> 03:38.828 align:middle line:84%
common between them.

98
03:38.828 --> 03:40.870 align:middle line:90%
Another thing we'd have
to decide for IKE phase 1

99
03:40.870 --> 03:41.915 align:middle line:84%
is the encryption.

100
03:41.915 --> 03:43.040 align:middle line:84%
So are we going to use DES?

101
03:43.040 --> 03:43.660 align:middle line:84%
No.

102
03:43.660 --> 03:44.952 align:middle line:84%
Are we going to use triple DES?

103
03:44.952 --> 03:45.820 align:middle line:84%
No.

104
03:45.820 --> 03:47.520 align:middle line:90%
Are we going to use
some flavor of AES?

105
03:47.520 --> 03:48.700 align:middle line:84%
Yes.

106
03:48.700 --> 03:53.540 align:middle line:90%
So we need to land on a flavor
of AES supported by both sides.

107
03:53.540 --> 03:55.870 align:middle line:90%
And as I'm looking at the
list here for IKE phase 1,

108
03:55.870 --> 03:58.960 align:middle line:90%
in our earlier videos, we talked
about some of the fundamentals

109
03:58.960 --> 04:01.972 align:middle line:90%
for IPSec and we had
the term HAGLE, which
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
03:58.960 --> 04:01.972 align:middle line:90%
for IPSec and we had
the term HAGLE, which

110
04:01.972 --> 04:03.180 align:middle line:84%
has been very helpful for me.

111
04:03.180 --> 04:05.150 align:middle line:90%
It helps me remember
the options.

112
04:05.150 --> 04:07.810 align:middle line:90%
So we've covered H
for hashing, we've

113
04:07.810 --> 04:11.650 align:middle line:90%
covered A for authentication,
E for encryption right here.

114
04:11.650 --> 04:15.210 align:middle line:90%
The G-- OK, so we also have
the Diffie-Hellman group.

115
04:15.210 --> 04:17.890 align:middle line:90%
Diffie-Hellman is a way
to generate king material.

116
04:17.890 --> 04:20.410 align:middle line:90%
Think of it like how do
you GRE secret keys that

117
04:20.410 --> 04:22.980 align:middle line:90%
are R1 and R2 can use for
encryption, decryption,

118
04:22.980 --> 04:26.320 align:middle line:90%
and how can they negotiate
those over an untrusted network?

119
04:26.320 --> 04:28.390 align:middle line:90%
And the answer is they
can use Diffie-Hellman

120
04:28.390 --> 04:30.790 align:middle line:90%
to come to that result. And
regarding Diffie-Hellman,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

120
04:28.390 --> 04:30.790 align:middle line:90%
to come to that result. And
regarding Diffie-Hellman,

121
04:30.790 --> 04:32.810 align:middle line:90%
there's just not
one size fits all.

122
04:32.810 --> 04:34.910 align:middle line:90%
We have different moduluses
and different ranges.

123
04:34.910 --> 04:37.810 align:middle line:90%
So we need to come together
on a Diffie-Hellman group

124
04:37.810 --> 04:40.390 align:middle line:90%
that we can both support so we
can generate the keys that we

125
04:40.390 --> 04:43.430 align:middle line:90%
can then use for our encrypted
sessions back and forth.

126
04:43.430 --> 04:45.520 align:middle line:90%
So that's the G for
Diffie-Hellman group,

127
04:45.520 --> 04:46.960 align:middle line:84%
and then the L is for lifetime.

128
04:46.960 --> 04:50.188 align:middle line:90%
So by default, the IKE
phase 1 tunnel is one day.

129
04:50.188 --> 04:52.480 align:middle line:90%
Now the question might come
up, OK, are we ready to go?

130
04:52.480 --> 04:53.320 align:middle line:84%
Can we start configuring?

131
04:53.320 --> 04:54.050 align:middle line:84%
The answer is no.

132
04:54.050 --> 04:56.920 align:middle line:90%
I don't know yet because we
are taking a look at IKE phase

133
04:56.920 --> 04:59.470 align:middle line:90%
1 and the detail
there, but we also

134
04:59.470 --> 05:01.720 align:middle line:90%
need to be aware that
we need to configure,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

134
04:59.470 --> 05:01.720 align:middle line:90%
need to be aware that
we need to configure,

135
05:01.720 --> 05:04.820 align:middle line:90%
and plan out, and implement
the IKE phase 2 tunnel as well.

136
05:04.820 --> 05:08.140 align:middle line:90%
Which from our previous
videos on IPSec fundamentals,

137
05:08.140 --> 05:12.320 align:middle line:90%
the IKE phase 2 tunnel is
literally the IPSec tunnel.

138
05:12.320 --> 05:15.940 align:middle line:90%
So when a user from site
1 sends traffic to site 2,

139
05:15.940 --> 05:18.470 align:middle line:90%
it's the IPSec tunnel,
the IKE phase 2 tunnel,

140
05:18.470 --> 05:21.280 align:middle line:90%
that's being used to encrypt
and protect that data,

141
05:21.280 --> 05:22.850 align:middle line:84%
and ship it across the network.

142
05:22.850 --> 05:26.650 align:middle line:90%
And so for IKE phase 2, also
called the IPSec tunnel,

143
05:26.650 --> 05:27.940 align:middle line:84%
what do we need to consider?

144
05:27.940 --> 05:30.323 align:middle line:90%
Well, we can use some
defaults for a few pieces,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

144
05:27.940 --> 05:30.323 align:middle line:90%
Well, we can use some
defaults for a few pieces,

145
05:30.323 --> 05:31.990 align:middle line:90%
but here are some of
the critical things

146
05:31.990 --> 05:33.917 align:middle line:90%
that we'd want to
consider-- the encryption.

147
05:33.917 --> 05:36.250 align:middle line:90%
So even though we specify the
encryption up here for IKE

148
05:36.250 --> 05:38.440 align:middle line:90%
phase 1, we'd also have
to specify the encryption

149
05:38.440 --> 05:39.788 align:middle line:84%
for the IPSec tunnel itself.

150
05:39.788 --> 05:41.080 align:middle line:84%
They don't have to be the same.

151
05:41.080 --> 05:43.240 align:middle line:90%
They just have to be
supported by both sides,

152
05:43.240 --> 05:47.330 align:middle line:90%
but we could use like
AES 128 for IKE phase 1,

153
05:47.330 --> 05:50.920 align:middle line:90%
and AES 256 for phase
2 perfectly fine.

154
05:50.920 --> 05:54.350 align:middle line:90%
We'd also want to specify
the interesting traffic.

155
05:54.350 --> 05:57.220 align:middle line:90%
Now when I say interesting
from the perspective of IPSec,

156
05:57.220 --> 05:59.140 align:middle line:90%
that is the traffic
that should be encrypted

157
05:59.140 --> 06:00.410 align:middle line:84%
if the router sees it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

157
05:59.140 --> 06:00.410 align:middle line:84%
if the router sees it.

158
06:00.410 --> 06:02.700 align:middle line:90%
So in our case, the
encrypted traffic

159
06:02.700 --> 06:06.130 align:middle line:90%
is going to be a source
from 10.1.0 going to 10.2.0

160
06:06.130 --> 06:08.170 align:middle line:84%
from R1's perspective.

161
06:08.170 --> 06:11.440 align:middle line:90%
And from R2's perspective,
it would be traffic source

162
06:11.440 --> 06:14.710 align:middle line:84%
from 10.2.0 going to 10.1.0.

163
06:14.710 --> 06:16.900 align:middle line:90%
So that would be specified
as part of our IKE phase

164
06:16.900 --> 06:18.820 align:middle line:84%
2 instructions for the routers.

165
06:18.820 --> 06:22.540 align:middle line:90%
Another thing we need to
specify is who is the peer.

166
06:22.540 --> 06:25.000 align:middle line:90%
So from R2's perspective,
it will have to know R1,

167
06:25.000 --> 06:27.520 align:middle line:90%
and from R1's perspective, it
will have to know about R2.

168
06:27.520 --> 06:30.010 align:middle line:90%
Think of those guys as
the respective other end
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
06:27.520 --> 06:30.010 align:middle line:90%
Think of those guys as
the respective other end

169
06:30.010 --> 06:31.330 align:middle line:84%
of the VPN tunnel.

170
06:31.330 --> 06:34.420 align:middle line:90%
And then are going to use
tunnel mode or transport mode?

171
06:34.420 --> 06:36.160 align:middle line:90%
Now in a site-to-site
VPN-- and we

172
06:36.160 --> 06:37.910 align:middle line:90%
are going to use tunnel
node because we're

173
06:37.910 --> 06:40.630 align:middle line:90%
going to take like PC1's
traffic and take the entire IP

174
06:40.630 --> 06:42.790 align:middle line:90%
packet, including the
original source [INAUDIBLE]

175
06:42.790 --> 06:45.610 align:middle line:90%
IP addresses,
encapsulate that and then

176
06:45.610 --> 06:48.490 align:middle line:90%
add a new IP header
for transport

177
06:48.490 --> 06:51.560 align:middle line:90%
over the external network
or the transport network.

178
06:51.560 --> 06:54.740 align:middle line:90%
So we're taking all that data
and canceling the whole thing,

179
06:54.740 --> 06:55.705 align:middle line:84%
which is tunnel mode.

180
06:55.705 --> 06:57.580 align:middle line:90%
So if we have some other
VPN solutions, which

181
06:57.580 --> 07:00.280 align:middle line:90%
we have in separate videos, we
might be using transport mode
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

181
06:57.580 --> 07:00.280 align:middle line:90%
we have in separate videos, we
might be using transport mode

182
07:00.280 --> 07:02.080 align:middle line:84%
with solutions like DNVPN.

183
07:02.080 --> 07:05.427 align:middle line:90%
But for a site-to-site VPN,
we want to use tunnel mode.

184
07:05.427 --> 07:07.510 align:middle line:90%
And then one other option
I'd like to specify here

185
07:07.510 --> 07:10.960 align:middle line:90%
is that we could recycle
some of the king material

186
07:10.960 --> 07:13.420 align:middle line:90%
that was made by Diffie-Hellman
during IKE phase 1,

187
07:13.420 --> 07:17.020 align:middle line:90%
or we could generate our
own new king material

188
07:17.020 --> 07:18.830 align:middle line:84%
by running Diffie-Hellman again.

189
07:18.830 --> 07:20.590 align:middle line:90%
So if you want to run
Diffie-Hellman again

190
07:20.590 --> 07:22.900 align:middle line:90%
for the IKE phase 2
tunnel, we could do that.

191
07:22.900 --> 07:27.435 align:middle line:90%
And that's referred to as
PFS, perfect forward secrecy.

192
07:27.435 --> 07:28.810 align:middle line:90%
It's simply not
recycling, you're

193
07:28.810 --> 07:31.640 align:middle line:90%
not reusing the king
information from IKE phase 1.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

193
07:28.810 --> 07:31.640 align:middle line:90%
not reusing the king
information from IKE phase 1.

194
07:31.640 --> 07:34.150 align:middle line:90%
And has a whole new set,
which it will create and run

195
07:34.150 --> 07:35.740 align:middle line:90%
Diffie-Hellman again
just for the keys

196
07:35.740 --> 07:37.150 align:middle line:84%
involved with IKE phase 2.

197
07:37.150 --> 07:38.650 align:middle line:84%
So what's the next logical step?

198
07:38.650 --> 07:41.002 align:middle line:90%
Well, now that we know
that all those details need

199
07:41.002 --> 07:42.460 align:middle line:90%
to be specified,
or we know we want

200
07:42.460 --> 07:44.650 align:middle line:90%
to take some of the defaults--
whatever the case is,

201
07:44.650 --> 07:48.080 align:middle line:90%
we need to plan on those details
that we are going to supply.

202
07:48.080 --> 07:49.330 align:middle line:84%
So here's what I'd like to do.

203
07:49.330 --> 07:51.810 align:middle line:90%
In the next video,
let's consider--

204
07:51.810 --> 07:53.830 align:middle line:90%
let's design a plan
together about what

205
07:53.830 --> 07:56.950 align:middle line:90%
we want to use for IKE phase 1,
what authentication, and what

206
07:56.950 --> 07:58.968 align:middle line:90%
hashing, and what
encryption, and so forth.

207
07:58.968 --> 08:00.010 align:middle line:84%
And we'll make that plan.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

207
07:58.968 --> 08:00.010 align:middle line:84%
And we'll make that plan.

208
08:00.010 --> 08:01.927 align:middle line:90%
And that way when we go
into subsequent videos

209
08:01.927 --> 08:04.450 align:middle line:90%
and start to implement the
IPSec, it won't be a mistake.

210
08:04.450 --> 08:06.083 align:middle line:84%
What should we use here?

211
08:06.083 --> 08:07.750 align:middle line:90%
That's the wrong time
to think about it,

212
08:07.750 --> 08:08.898 align:middle line:84%
when you're at the CLI.

213
08:08.898 --> 08:10.690 align:middle line:90%
So in the next video,
we'll do the planning

214
08:10.690 --> 08:11.800 align:middle line:84%
for our implementation.

215
08:11.800 --> 08:13.790 align:middle line:90%
So I'll see you there
in just a moment.

216
08:13.790 --> 08:16.120 align:middle line:90%
Meanwhile, I hope this has
been informative for you.

217
08:16.120 --> 08:19.380 align:middle line:90%
And I'd like to thank
you for viewing.