WEBVTT 00:00.360 --> 00:06.360 One of the problems of the originators of the Internet not putting security into anything is that by 00:06.360 --> 00:10.260 the end of the 1990s everybody was making their own security. 00:10.260 --> 00:16.950 So if you had web pages you were doing SSL or less if you were trying to make a remote connection you'd 00:16.950 --> 00:19.920 be using things like S-sh instead of telnet. 00:19.950 --> 00:26.260 Everybody was doing their own thing when it came to security on a TZP IP network. 00:26.340 --> 00:32.050 And by the late 90s there was a thought that you know this might not be the best way to do it. 00:32.250 --> 00:38.880 What if instead of having all these different applications and things like that doing their own security 00:39.210 --> 00:46.470 what if we could come up with a type of IP security that worked on a host to host basis where literally 00:46.710 --> 00:53.130 every single computer on the Internet had its own security and when you would make a connection that 00:53.130 --> 00:58.990 point to point security would take care of everything and that is known generically as Sec. 00:59.060 --> 01:05.610 Now it is not one thing Essec is actually a bunch of protocols that work together that come up with 01:05.610 --> 01:10.560 this idea that we could have any to host create a secure connection. 01:10.570 --> 01:15.680 Now if Essec was totally rolled out it would be a pretty cool thing. 01:15.680 --> 01:18.380 We could theoretically get rid of HDTV. 01:18.410 --> 01:23.990 We could get rid of S-sh we could get rid of encrypted email because everything would be point to point 01:23.990 --> 01:24.680 encrypted. 01:24.680 --> 01:26.850 The reality is that didn't happen. 01:26.870 --> 01:33.740 However if SEC is a very cool protocol it is used all over the place and it's also a little complicated. 01:33.740 --> 01:38.880 So in this episode what I want to do is take about a 5000 foot overview of that set. 01:39.020 --> 01:41.460 Make sure you understand the base pieces of it. 01:41.490 --> 01:46.910 Now if we're going to be making point to point connections obviously we're going to have to do a lot 01:46.910 --> 01:48.880 of important stuff when it comes to security. 01:48.890 --> 01:51.250 We're going to have to go through an authentication process. 01:51.260 --> 01:53.900 We're going have to go through encryption and all that stuff. 01:53.930 --> 01:58.700 Now I'm going to talk about that in a minute but once everything is going what do you want to do with 01:58.700 --> 01:59.210 that data. 01:59.210 --> 02:01.010 Well there's two things you can do. 02:01.010 --> 02:06.500 Number one you can generate what are known as authentication headers or you can generate what's known 02:06.500 --> 02:08.840 as encapsulating security payloads. 02:08.930 --> 02:11.430 So it runs in two very different modes. 02:11.510 --> 02:13.850 Let's go through both of those. 02:13.860 --> 02:19.070 Here is some TCAP data I've got to TCAP Hetter here and then I've got some data. 02:19.080 --> 02:23.610 Now I'm eventually going to put an IP address on this and send it out the door. 02:23.610 --> 02:29.560 Now one of the encapsulation formats that we use with Essec is known as authentication Hetter. 02:29.670 --> 02:33.300 The only thing this does is provides integrity. 02:33.300 --> 02:41.490 So what we'll do is before we send this guy out we're going to do is we're going to go ahead and do 02:41.670 --> 02:48.570 an integrity check on the actual data itself and then we're going to insert this little bit of authentication 02:48.570 --> 02:49.730 header data. 02:49.770 --> 02:54.110 So in essence what we've done here is we've just generated an H Mac. 02:54.150 --> 02:59.620 So the important thing to remember about authentication header is that it only provides integrity. 02:59.660 --> 03:05.160 Now the more popular one that we're going to see is the encapsulating security protocols so let's go 03:05.160 --> 03:09.340 ahead and start with that exact same header that we had before. 03:09.360 --> 03:15.210 Now this time what we're going to do is we're going to actually go to the process of encrypting this 03:15.210 --> 03:21.560 guy so we'll use some time something like Des's or triple does or even A-S encryption. 03:21.780 --> 03:27.590 And we're going to go ahead and create an encryption here and then we're going to put a header on there 03:27.870 --> 03:31.560 and then that thing is now fully encrypted. 03:31.560 --> 03:38.780 So epic works simply by encapsulating our data into an upset packet that works great. 03:38.880 --> 03:44.460 However there are some issues here you'll notice in those examples we took the original IP address and 03:44.460 --> 03:48.080 in essence kind of inserted some stuff in there and that's fine. 03:48.450 --> 03:54.810 And if I were the overlord godhead of the universe that I made everybody use the exact same IP protocols 03:54.990 --> 03:59.970 and I got rid of that and I got rid of all kinds of problems this would be a great thing. 03:59.970 --> 04:08.160 However we live in a world where there is Nat and there's IPV for an IP D6 and all of these issues where 04:08.160 --> 04:13.000 we can't simply take an existing IP address and that can be a problem. 04:12.990 --> 04:20.070 Now what I just showed you is one of two different ways that we could run Essec so and they're actually 04:20.070 --> 04:27.800 two separate protocols so when we're talking about keeping the original IP address we call that transport 04:27.800 --> 04:34.790 mode transport mode would work great if everybody had the exact same IP for range or IP B-6 range. 04:34.880 --> 04:40.130 If we got rid of net a bunch of other things but transport mode in the real world doesn't work very 04:40.130 --> 04:40.660 well. 04:40.670 --> 04:43.520 So what we do instead is we use tunnel mode. 04:43.520 --> 04:45.410 Let me show you how that works. 04:45.440 --> 04:48.560 Let's take a look at that authentication head or we did earlier. 04:48.560 --> 04:54.530 Now normally what we're going to do is just run an H Mac on all of this value and then insert that into 04:54.530 --> 04:55.990 the H header. 04:55.990 --> 05:01.700 Now the problem here is that we're still using the original IP address and in a lot of places that's 05:01.700 --> 05:02.920 simply not going to work. 05:03.050 --> 05:07.010 So what we use is what we call is Tunnel mode. 05:07.040 --> 05:09.030 So this right now is transport. 05:09.040 --> 05:10.980 We still have the original IP Hetter. 05:11.060 --> 05:15.640 But what we can do is get rid of that and then add a new IP address to it. 05:15.770 --> 05:21.530 And by adding a new different IP address then we could actually run this in transport mode. 05:21.530 --> 05:22.620 Now you have to be careful. 05:22.640 --> 05:28.760 This would drive the poor system crazy because remember you're doing an H Mac on this entire value including 05:28.760 --> 05:30.130 the original IP. 05:30.260 --> 05:32.390 And if you were to change it that would be a problem. 05:32.390 --> 05:37.760 So we don't actually do tunnel mode with age by itself. 05:37.760 --> 05:42.040 Instead what will tend to do is we use that with ESPN. 05:42.260 --> 05:46.300 So let's take a look at that original S P packet that we had before. 05:46.370 --> 05:51.030 So we got our encrypted data that we have are authenticated data. 05:51.140 --> 05:58.100 But in this case what we're going to be doing is the original IP header is encrypted and then we add 05:58.100 --> 06:02.000 a new IP header to the outside of this. 06:02.410 --> 06:08.290 So the bottom line is in today's upset world most people are going to be running in tunneling mode and 06:08.290 --> 06:13.750 they're going to be doing a whole lot of ESPN now to get all this role. 06:13.900 --> 06:20.230 You've got these two hosts so you've got an entire security aspect that you've got to deal with now 06:20.590 --> 06:21.640 in the OPSEC world. 06:21.640 --> 06:27.630 They use something called isip KMP Internet security agreement key management protocol. 06:27.790 --> 06:34.400 I said KMP his only job is to create what we call a security agreement between two host. 06:34.510 --> 06:40.150 So if two hosts want to start talking IPs SEC the first thing they're going to do is begin this negotiation 06:40.150 --> 06:48.400 protocol using ISI KMP So I see KMP is going to handle all kinds of stuff like for example initial authentication 06:48.640 --> 06:55.350 so it can use certificates it can use pre-shared keys it can use just about anything you want to start 06:55.360 --> 06:57.960 that initial negotiation between the two. 06:57.990 --> 06:59.740 It will set up the exchange. 06:59.750 --> 07:05.410 It'll set up the type of schäfer h Mac that handles all of this through the negotiation process. 07:05.410 --> 07:12.310 So I said KMP is the cornerstone of what gets all the security rocket and Roeland in order for to upset 07:12.350 --> 07:15.890 hosta talk to each other and in a nice secure way. 07:15.910 --> 07:25.800 So this can be pretty challenging to configure and as a result we don't see it being used in the way 07:25.800 --> 07:27.720 that a lot of people thought it might be used. 07:27.720 --> 07:34.050 But I would like to take a minute and talk about where we actually see upset in today's world and let's 07:34.050 --> 07:35.460 start with the paeans 07:39.880 --> 07:44.560 the tunneling aspect of it CEQ makes it a natural for VPN. 07:44.560 --> 07:47.140 So we see a lot of the peahens that use it. 07:47.140 --> 07:52.870 Second there's really two different ways that you'll see it Seck used in the paeans first would be a 07:53.140 --> 07:57.850 real honest to Pete traditional OPSEC pure VPN. 07:57.850 --> 08:02.980 In that case it's only running seconds using tunneling mode and you make these two connections between 08:02.980 --> 08:03.710 two hosts. 08:03.820 --> 08:04.910 And it works ok. 08:05.050 --> 08:07.720 However that's really not the more common way to do it. 08:07.750 --> 08:13.720 The more common and somewhat older way to do it is running it upset with the L2 T-P protocol. 08:13.750 --> 08:20.620 In this scenario what will happen is L2 T.P. generates an initial tunnel and it set goes ahead and it 08:20.620 --> 08:28.270 puts a total within the tunnel so it's got a lot more security to it but it works really well and that 08:28.270 --> 08:34.110 is if you're going to be setting up a VPN with it it's probably going to be upset with L2 t.p. 08:34.120 --> 08:38.800 Now the other place we're going to be seen upset used a lot is with radius and to Cacace 08:43.470 --> 08:50.700 if you had some set up using Triple A radius or to Cacace in these situations you don't really have 08:50.760 --> 08:52.860 a native encryption built into it. 08:52.860 --> 09:00.510 So a lot of these folks will go ahead and use SFC to create an essence of VPN tunnel between the two 09:00.510 --> 09:02.900 hosts so that they can communicate securely. 09:03.060 --> 09:09.580 So you're not going to see this too much outside of say a enterprise level wireless network or if you 09:09.580 --> 09:15.330 got a bunch of Cisco boxes that all have to talk to each other it is currently uncommon but it is out 09:15.330 --> 09:15.940 there. 09:16.110 --> 09:21.570 Now the other thing I want to talk about and one that bugs me a little bit is upset with IPV six 09:26.010 --> 09:33.780 when IP B-6 first came out one of the big pushes was that if SEC is mandatory and built into IPV 6 which 09:33.780 --> 09:39.240 we all thought was going to be so cool because we'd have to get rid of all of our secure web sites in 09:39.240 --> 09:43.080 securing mail because it was going to take care of everything with IP B-6. 09:43.080 --> 09:45.100 That's actually not accurate. 09:45.110 --> 09:49.830 Now within the RF CS There was mention that if SEC would be required. 09:49.920 --> 09:59.140 The reality of this simply means that the SEC header information can be placed within an IP V-6 header. 09:59.140 --> 10:00.160 That's it. 10:00.160 --> 10:04.090 So there's nothing about IP V-6 that makes it work perfectly with it. 10:04.090 --> 10:08.560 In fact it works perfectly with Google IPV for just as well. 10:08.590 --> 10:14.530 And by the way the powers of the internet dropped all that and no longer say that you must run chipset 10:14.590 --> 10:18.530 with IP B-6 because to be honest with you I've never seen it. 10:18.530 --> 10:18.840 All right. 10:18.850 --> 10:23.260 Now there's one more place and you're going to see questions on the exam that kind of point to stuff 10:23.260 --> 10:23.880 like that. 10:24.040 --> 10:32.750 And that is using IPs SEC with non-secure protocols. 10:32.940 --> 10:39.350 Remember that the whole idea behind it says is that we would no longer have to have secure applications 10:39.660 --> 10:46.960 or it would be more optional because you'd have this layer 3 security and that is one aspect where it 10:47.190 --> 10:48.680 can work pretty well. 10:48.690 --> 10:53.940 For example let's say for some reason you absolutely have to have a telnet connection or something scary 10:53.940 --> 10:54.600 like that. 10:54.750 --> 10:57.240 Telnet wide open easy to read. 10:57.240 --> 11:04.620 You could set up an SEC probably an app sec tunnel that would allow you to encrypt all of that telnet 11:04.620 --> 11:10.410 information between the two hosts and saving you a lot of trouble so if you had an application that 11:10.440 --> 11:16.350 absolutely had to have telnet you could do all kinds of stuff you could put in IPV six and add it second 11:16.350 --> 11:17.340 all that stuff. 11:17.340 --> 11:20.900 But the reality is you're probably just going to use S-sh. 11:21.290 --> 11:27.230 If sex is an amazing tool it's been around for a while and we certainly see a lot of adoption to it 11:27.450 --> 11:34.230 but unfortunately being the ultimate fix for all of our security problems is probably never going to 11:34.230 --> 11:51.510 happen.