WEBVTT

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


2
00:01.410 --> 00:04.440 align:middle line:90%
It's a pretty tough go to use
a technology that you've never

3
00:04.440 --> 00:06.280 align:middle line:90%
heard of before,
so in this video,

4
00:06.280 --> 00:08.610 align:middle line:90%
I'd like to introduce you
to a pretty cool technology

5
00:08.610 --> 00:10.657 align:middle line:84%
called GET VPN.

6
00:10.657 --> 00:12.240 align:middle line:90%
And for this discussion,
let's imagine

7
00:12.240 --> 00:15.300 align:middle line:90%
that this network right here
is from our service provider,

8
00:15.300 --> 00:16.920 align:middle line:90%
and that our service
provider, maybe

9
00:16.920 --> 00:19.175 align:middle line:90%
they're using layer
3 VPNs with MPLS.

10
00:19.175 --> 00:20.550 align:middle line:90%
They know about
all of our routes

11
00:20.550 --> 00:22.570 align:middle line:90%
and how to reach
everything in our network.

12
00:22.570 --> 00:25.560 align:middle line:90%
So maybe you want to protect
the traffic from 10.3 to 10.1,

13
00:25.560 --> 00:29.760 align:middle line:90%
so traffic going this way,
and maybe from 10.1 to 10.4

14
00:29.760 --> 00:34.837 align:middle line:90%
this way, and 10.4 to 10.2 this
way, and from 10.2 to 10.3.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

14
00:29.760 --> 00:34.837 align:middle line:90%
this way, and 10.4 to 10.2 this
way, and from 10.2 to 10.3.

15
00:34.837 --> 00:36.920 align:middle line:90%
And then we don't want to
forget across the middle

16
00:36.920 --> 00:37.770 align:middle line:84%
and across up.

17
00:37.770 --> 00:40.635 align:middle line:84%
So we could implement VPNs.

18
00:40.635 --> 00:41.510 align:middle line:84%
That's a whole bunch.

19
00:41.510 --> 00:43.257 align:middle line:90%
I think that's like
six VPNs that we

20
00:43.257 --> 00:45.090 align:middle line:90%
would have to implement
to go ahead and have

21
00:45.090 --> 00:47.790 align:middle line:90%
that protection across our
service provider network.

22
00:47.790 --> 00:50.010 align:middle line:90%
But another option that
we could use instead

23
00:50.010 --> 00:51.960 align:middle line:90%
of having to manually
build all those tunnels

24
00:51.960 --> 00:54.180 align:middle line:84%
is called GET VPN.

25
00:54.180 --> 00:55.620 align:middle line:84%
And GET isn't like a commercial.

26
00:55.620 --> 00:56.400 align:middle line:84%
"Get VPN!

27
00:56.400 --> 00:57.930 align:middle line:84%
You need VPN now!"

28
00:57.930 --> 01:00.730 align:middle line:90%
GET VPN refers to Group
Encrypted Transport.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

28
00:57.930 --> 01:00.730 align:middle line:90%
GET VPN refers to Group
Encrypted Transport.

29
01:00.730 --> 01:02.150 align:middle line:84%
Here's the idea.

30
01:02.150 --> 01:04.080 align:middle line:90%
So let's imagine we have
an IPsec controller.

31
01:04.080 --> 01:05.880 align:middle line:90%
Now, the IPsec
controller, his job

32
01:05.880 --> 01:09.123 align:middle line:90%
is to be in charge of all of
the IPsec security associations

33
01:09.123 --> 01:11.040 align:middle line:90%
and make sure everyone
knows about what to do.

34
01:11.040 --> 01:13.290 align:middle line:90%
So we could have this
controller communicate

35
01:13.290 --> 01:14.415 align:middle line:84%
with each of these devices.

36
01:14.415 --> 01:16.582 align:middle line:90%
And we could have the
controller say, you know what?

37
01:16.582 --> 01:19.120 align:middle line:90%
Here's the SAs, the Security
Associations, for IPsec

38
01:19.120 --> 01:20.220 align:middle line:84%
I want you to use.

39
01:20.220 --> 01:23.250 align:middle line:90%
And included with that, here
are the keys you should use.

40
01:23.250 --> 01:25.440 align:middle line:90%
And if I ever need to
change that, or update,

41
01:25.440 --> 01:27.900 align:middle line:90%
or rotate the key, I will
communicate with you,

42
01:27.900 --> 01:28.740 align:middle line:84%
and let you know.

43
01:28.740 --> 01:31.760 align:middle line:90%
And in addition, here's
the interesting traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
01:28.740 --> 01:31.760 align:middle line:90%
And in addition, here's
the interesting traffic.

44
01:31.760 --> 01:34.050 align:middle line:90%
And so on the controller,
we could specify traffic

45
01:34.050 --> 01:36.360 align:middle line:90%
from 10.1 to 10.3,
or we could just

46
01:36.360 --> 01:38.000 align:middle line:84%
say 10 anything to 10 anything.

47
01:38.000 --> 01:39.060 align:middle line:84%
That would cover it.

48
01:39.060 --> 01:40.830 align:middle line:90%
And in that interesting
traffic list,

49
01:40.830 --> 01:43.470 align:middle line:90%
the controller could push down
that full config as far as

50
01:43.470 --> 01:45.448 align:middle line:84%
what to do to all the routers.

51
01:45.448 --> 01:47.240 align:middle line:90%
Then the routers, all
they would have to do

52
01:47.240 --> 01:48.698 align:middle line:90%
is say, oh, I've
got traffic that's

53
01:48.698 --> 01:49.950 align:middle line:84%
about to leave this interface.

54
01:49.950 --> 01:51.795 align:middle line:90%
Is it coming from
10 and going to 10

55
01:51.795 --> 01:53.170 align:middle line:90%
based on the
interesting traffic?

56
01:53.170 --> 01:55.050 align:middle line:90%
And if so, it can
just encrypt it

57
01:55.050 --> 01:57.630 align:middle line:90%
using the keys that were
provided by the controller,

58
01:57.630 --> 01:58.810 align:middle line:84%
and then just send it.

59
01:58.810 --> 02:01.800 align:middle line:90%
So the original packet,
if it was from 10.1.0.50
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
01:58.810 --> 02:01.800 align:middle line:90%
So the original packet,
if it was from 10.1.0.50

60
02:01.800 --> 02:04.840 align:middle line:90%
going 10.2.0.50, here's
the original packet.

61
02:04.840 --> 02:06.660 align:middle line:90%
So we have the
payload here, whatever

62
02:06.660 --> 02:08.729 align:middle line:84%
was being sent from PC1 to PC2.

63
02:08.729 --> 02:12.720 align:middle line:90%
The original IP header at
this point would be PC1,

64
02:12.720 --> 02:14.142 align:middle line:90%
and the destination
would be PC2.

65
02:14.142 --> 02:15.600 align:middle line:90%
What the router
would do, once it's

66
02:15.600 --> 02:17.382 align:middle line:90%
about to route it
out this interface

67
02:17.382 --> 02:19.590 align:middle line:90%
where we've applied our
policy, the router would say,

68
02:19.590 --> 02:21.360 align:middle line:90%
I'm going to go ahead
encrypt all of that.

69
02:21.360 --> 02:22.860 align:middle line:90%
I'm going to put a
new header on it.

70
02:22.860 --> 02:26.160 align:middle line:90%
And with IPsec, it'd
be protocol 50 for ESP,

71
02:26.160 --> 02:28.840 align:middle line:90%
because Encapsulating Security
Payload is protocol 50.

72
02:28.840 --> 02:31.890 align:middle line:84%
AH is protocol 51.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

72
02:28.840 --> 02:31.890 align:middle line:84%
AH is protocol 51.

73
02:31.890 --> 02:34.350 align:middle line:90%
But AH does a great job
with data integrity,

74
02:34.350 --> 02:36.750 align:middle line:90%
but it doesn't do
anything for encryption.

75
02:36.750 --> 02:38.920 align:middle line:90%
So AH by itself is
rarely ever used.

76
02:38.920 --> 02:41.370 align:middle line:90%
We're going to use ESP,
Encapsulating Security Payload,

77
02:41.370 --> 02:45.480 align:middle line:90%
because that does the encryption
and the data integrity of HMAC

78
02:45.480 --> 02:47.070 align:middle line:84%
all built into IPsec.

79
02:47.070 --> 02:48.750 align:middle line:84%
We don't need to use AH.

80
02:48.750 --> 02:50.670 align:middle line:90%
So it'd be an ESP
protocol 50 header.

81
02:50.670 --> 02:52.470 align:middle line:84%
And then check this out.

82
02:52.470 --> 02:56.320 align:middle line:90%
It preserves or replaces
the original IP addresses.

83
02:56.320 --> 03:00.000 align:middle line:90%
So it'd still show up as
coming from PC1 going to PC2.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
03:00.000 --> 03:01.270 align:middle line:84%
And then it would send it.

85
03:01.270 --> 03:02.910 align:middle line:90%
So over the service
provider network,

86
03:02.910 --> 03:04.368 align:middle line:90%
it would still look
like it's going

87
03:04.368 --> 03:05.908 align:middle line:84%
from 10.1.0.50 to 10.2.0.50.

88
03:05.908 --> 03:07.950 align:middle line:90%
So that's why it's important
the service provider

89
03:07.950 --> 03:10.298 align:middle line:90%
network knows how to route
to those networks for us.

90
03:10.298 --> 03:12.090 align:middle line:90%
And then it went on to
receive that packet.

91
03:12.090 --> 03:13.710 align:middle line:90%
It would go ahead
and decrypt it,

92
03:13.710 --> 03:16.200 align:middle line:90%
and then forward the
naked unencrypted packet

93
03:16.200 --> 03:17.620 align:middle line:84%
onto its destination.

94
03:17.620 --> 03:21.090 align:middle line:90%
So unlike traditional
tunneled IPsec traffic,

95
03:21.090 --> 03:24.660 align:middle line:90%
these devices are not replacing
and putting in new IP addresses

96
03:24.660 --> 03:26.370 align:middle line:90%
based on their source
and destination.

97
03:26.370 --> 03:29.040 align:middle line:90%
They're preserving what was
in the original IP header

98
03:29.040 --> 03:30.938 align:middle line:90%
as they forward that
encrypted traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

98
03:29.040 --> 03:30.938 align:middle line:90%
as they forward that
encrypted traffic.

99
03:30.938 --> 03:31.980 align:middle line:84%
So thanks for joining me.

100
03:31.980 --> 03:35.070 align:middle line:90%
In this video, we're getting a
high level overview of GET VPN.

101
03:35.070 --> 03:36.850 align:middle line:84%
I'll see you in the next video.

102
03:36.850 --> 03:39.120 align:middle line:90%
Meanwhile, I hope this has
been informative for you.

103
03:39.120 --> 03:42.320 align:middle line:90%
And I'd like to thank
you for viewing.