WEBVTT 1 00:00.000 --> 00:06.000 So what we've done at this point is we have explored the idea of a GRE tunnel 2 00:06.000 --> 00:08.000 and connecting two routers together. 3 00:08.000 --> 00:12.600 So this tunnel is great, it allows for direct communication, we can form 4 00:12.600 --> 00:17.000 routing relationships, but we also know that this is an overlay. 5 00:17.000 --> 00:22.120 It's not an actual direct connection, it's sort of this virtual connection, and 6 00:22.120 --> 00:24.000 we're leveraging encapsulation to make it happen. 7 00:24.000 --> 00:28.380 So the reality is that we still have a bunch of other devices that we have to 8 00:28.380 --> 00:32.710 pass through physically in order to get from one router to the other, and these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 8 00:28.380 --> 00:32.710 pass through physically in order to get from one router to the other, and these 9 00:32.710 --> 00:35.000 devices are known as the underlay. 10 00:35.000 --> 00:39.180 Now these devices might be part of our enterprise network, maybe we're just 11 00:39.180 --> 00:43.560 leveraging overlay or tunnel technology for a particular reason, but the 12 00:43.560 --> 00:49.000 reality is that this underlay could also be an untrusted network. 13 00:49.000 --> 00:54.380 For example, especially the internet, but we might also decide that certain 14 00:54.380 --> 00:59.780 service provider wide area networking technologies like MPLS, maybe we don't 15 00:59.780 --> 01:02.000 want to necessarily trust those either. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 15 00:59.780 --> 01:02.000 want to necessarily trust those either. 16 01:02.000 --> 01:06.370 And so it's great that we've established this tunnel, but because we are 17 01:06.370 --> 01:12.000 building it over an untrusted underlay, there might be some security issues. 18 01:12.000 --> 01:18.720 For example, what happens if somebody in this underlay here is going to start 19 01:18.720 --> 01:21.000 sniffing our traffic. 20 01:21.000 --> 01:26.710 So maybe we have some form of dishonest service provider or a rogue employee 21 01:26.710 --> 01:32.730 who just understands that, hey, I work for the service provider, but I know WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 01:26.710 --> 01:32.730 who just understands that, hey, I work for the service provider, but I know 22 01:32.730 --> 01:37.640 that this is a wealthy company, I'm going to try to steal some secrets from 23 01:37.640 --> 01:39.000 them, whatever the situation is. 24 01:39.000 --> 01:43.440 We certainly don't want to make ourselves vulnerable to that, even if we do 25 01:43.440 --> 01:48.220 trust the company that runs the underlay, again, just takes one rogue employee 26 01:48.220 --> 01:52.000 to decide to go in there and try to do something malicious. 27 01:52.000 --> 01:57.560 The other thing that we maybe not even think about is the idea that we are 28 01:57.560 --> 02:01.000 opening ourselves up to rogue devices. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 28 01:57.560 --> 02:01.000 opening ourselves up to rogue devices. 29 02:01.000 --> 02:07.120 For example, I have decided that I want to connect to 10.1.1.1 here, and I'm 30 02:07.120 --> 02:14.670 assuming that 10.1.1.1 is an IP address that belongs to router 4, and borrowing 31 02:14.670 --> 02:17.000 the number from our topology in the last skill. 32 02:17.000 --> 02:22.900 And so, yeah, maybe it belongs to router 4, but what if this threat actor spins 33 02:22.900 --> 02:28.650 up their own router, we'll call this our X, it's a bad rogue router, and sets 34 02:28.650 --> 02:34.000 it up to run the same configuration with 10.1.1.1.1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 34 02:28.650 --> 02:34.000 it up to run the same configuration with 10.1.1.1.1. 35 02:34.000 --> 02:38.720 And maybe they're able to make it so that this router forms a connection, we've 36 02:38.720 --> 02:43.260 built the tunnel to the wrong router, and now, all of a sudden, we have a man 37 02:43.260 --> 02:48.140 in the middle attack, because they have hijacked our tunnel connection, they 38 02:48.140 --> 02:51.600 continue to pass our traffic on to the rest of the network, so we don't even 39 02:51.600 --> 02:55.710 realize we've formed a tunnel to the wrong router, and yeah, that's going to 40 02:55.710 --> 02:57.000 cause a lot of potential problems. 41 02:57.000 --> 03:01.110 All they need to know for this is some basic IP configuration, there's no WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 41 02:57.000 --> 03:01.110 All they need to know for this is some basic IP configuration, there's no 42 03:01.110 --> 03:06.110 passwords, there's no authentication, there's nothing happening here for us to 43 03:06.110 --> 03:07.000 secure this. 44 03:07.000 --> 03:11.980 And so, absolutely, this is going to be a problem for us from a security 45 03:11.980 --> 03:16.940 perspective, and this can apply not just to the internet, but even service 46 03:16.940 --> 03:18.000 providers. 47 03:18.000 --> 03:23.570 So, we've talked about some of the values of these, the concept of IPsec, and 48 03:23.570 --> 03:28.000 how IPsec is going to help us start to lock some of this down. 49 03:28.000 --> 03:33.480 But we need to now move on from white boarding or chalkboarding out the IPsec WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 49 03:28.000 --> 03:33.480 But we need to now move on from white boarding or chalkboarding out the IPsec 50 03:33.480 --> 03:37.000 solution and move to actual configuration. 51 03:37.000 --> 03:41.990 So, what we're going to learn, what we're going to look at as we go through the 52 03:41.990 --> 03:46.620 configuration process here, is that it starts with iC, the internet key 53 03:46.620 --> 03:53.000 exchange, but remember iC is an implementation of iSecamp. 54 03:53.000 --> 03:57.560 And Cisco really likes this iSecamp term, to the point that we don't actually 55 03:57.560 --> 04:02.180 see iC very often, now with iC V2, they kind of change that, but with iC V1 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 55 03:57.560 --> 04:02.180 see iC very often, now with iC V2, they kind of change that, but with iC V1 56 04:02.180 --> 04:06.000 especially we're talking about iSecamp configurations. 57 04:06.000 --> 04:11.730 So, this is going to be how we start our configuration on a Cisco router and i 58 04:11.730 --> 04:13.000 OS XE device. 59 04:13.000 --> 04:16.960 So, we're going to walk through this process from a chalkboard perspective, 60 04:16.960 --> 04:20.000 then we'll log in to perform the actual configurations. 61 04:20.000 --> 04:23.500 It makes sense to diagram this out because we're going to end up with some 62 04:23.500 --> 04:27.000 different policies and configurations that tie into one another. 63 04:27.000 --> 04:30.870 It's going to help for us to diagram this out and have a sense of how this all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 63 04:27.000 --> 04:30.870 It's going to help for us to diagram this out and have a sense of how this all 64 04:30.870 --> 04:32.000 comes together. 65 04:32.000 --> 04:35.510 So, let's just put a number one here. The first thing we're going to want to 66 04:35.510 --> 04:39.360 start with is creating what's known as, actually let's put the one down here, 67 04:39.360 --> 04:46.000 what's known as a crypto iSecamp policy. 68 04:46.000 --> 04:54.000 The iSecamp policy is where we're going to configure our Haggle parameters. 69 04:54.000 --> 04:58.300 Remember, Haggle, yes intentionally spelled with 1G there, then English 70 04:58.300 --> 05:01.000 normally there's doo-gies, but it's an acronym. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 70 04:58.300 --> 05:01.000 normally there's doo-gies, but it's an acronym. 71 05:01.000 --> 05:05.000 It's meant to help us remember what we're configuring as part of this policy. 72 05:05.000 --> 05:11.020 The policy is interesting because we're not actually going to create a name for 73 05:11.020 --> 05:13.000 this policy, nor are we going to reference it later. 74 05:13.000 --> 05:18.230 Instead, we're going to assign a priority value to this where the lower 75 05:18.230 --> 05:20.000 priority is better. 76 05:20.000 --> 05:25.230 I might give it a priority of 10 or something along those lines, and then Cisco 77 05:25.230 --> 05:32.320 iOS is going to adopt that policy as part of all of our iPec tunnels, again, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 05:25.230 --> 05:32.320 iOS is going to adopt that policy as part of all of our iPec tunnels, again, 78 05:32.320 --> 05:34.000 based on the priority level for the configurations. 79 05:34.000 --> 05:41.720 It's kind of interesting how that works. So either way, we recall what Haggle 80 05:41.720 --> 05:44.510 means for us. We have to configure things like the hash, which is going to be 81 05:44.510 --> 05:46.000 MD5 or some form of SHA. 82 05:46.000 --> 05:51.510 In the modern era, we should really be using SHA-256 or greater, MD5 and SHA-1, 83 05:51.510 --> 05:55.000 and considered to be a little bit legacy at this point. 84 05:55.000 --> 06:00.480 Our authentication, we want to configure, we could use hashing or certificates, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 84 05:55.000 --> 06:00.480 Our authentication, we want to configure, we could use hashing or certificates, 85 06:00.480 --> 06:05.560 really, but we're going to use pre-shared keys as part of our lab topology here 86 06:05.560 --> 06:06.000 . 87 06:06.000 --> 06:09.970 Just understand we have multiple options, but pre-shared key is a pretty good 88 06:09.970 --> 06:12.000 way to do this for a lab environment. 89 06:12.000 --> 06:16.000 It makes it nice and simple. We have to configure that Diffie-Homing group. 90 06:16.000 --> 06:22.260 So that group ID will probably configure 16 in the lab. We've said we want 14 91 06:22.260 --> 06:25.000 or greater. That continues to change over time. 92 06:25.000 --> 06:30.000 By the time you're watching this, maybe a higher group level is recommended, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 92 06:25.000 --> 06:30.000 By the time you're watching this, maybe a higher group level is recommended, 93 06:30.000 --> 06:33.310 but this is essentially equating to how many bits we're going to use as part of 94 06:33.310 --> 06:35.000 our Diffie-Homing key exchange. 95 06:35.000 --> 06:42.400 We also have to configure the lifetime in seconds. Then we also need to worry 96 06:42.400 --> 06:46.000 about the encryption that we're going to use for this tunnel. 97 06:46.000 --> 06:50.920 Probably going to use AES because the only other options are seriously outdated 98 06:50.920 --> 06:52.000 at this point. 99 06:52.000 --> 06:56.040 We can either use DES, which you don't want to use, or triple DES, which is 100 06:56.040 --> 06:58.000 three times as good, potentially. 101 06:58.000 --> 07:04.000 That's still considered to be pretty weak. We want to use AES where we can. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 101 06:58.000 --> 07:04.000 That's still considered to be pretty weak. We want to use AES where we can. 102 07:04.000 --> 07:07.840 This leads us to a conversation, at least a question, of what is this 103 07:07.840 --> 07:09.000 encryption for? 104 07:09.000 --> 07:14.960 Recall what we're talking about with Ike. We have two phases. We have to worry 105 07:14.960 --> 07:17.000 about phase one and phase two. 106 07:17.000 --> 07:21.320 Phase one is the control plane tunnel. Phase two is the data plane tunnel. This 107 07:21.320 --> 07:26.000 whole thing right here, this is for our phase one tunnel. 108 07:26.000 --> 07:30.390 Meaning we're going to use this for communications to the other device, but I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 108 07:26.000 --> 07:30.390 Meaning we're going to use this for communications to the other device, but I 109 07:30.390 --> 07:34.000 can set all of these configuration parameters, 110 07:34.000 --> 07:39.180 whatever I want to put in here, but it only affects the phase one tunnel. I'm 111 07:39.180 --> 07:43.000 still going to have to configure the phase one tunnel after all this. 112 07:43.000 --> 07:47.530 How do we go, or the phase two tunnel, rather? Let's go ahead and move on from 113 07:47.530 --> 07:50.000 here. We're going to go to the second step. 114 07:50.000 --> 07:55.800 Let's go ahead and change the color here to distinguish. Second step here is to 115 07:55.800 --> 07:58.000 configure a transform set. 116 07:58.000 --> 08:02.330 This is where we start to get into the phase two tunnel configuration, but it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 116 07:58.000 --> 08:02.330 This is where we start to get into the phase two tunnel configuration, but it 117 08:02.330 --> 08:05.000 takes a little bit of a roundabout approach. 118 08:05.000 --> 08:10.250 With the ISA camp policy, we configure everything in one go. Here, it's really 119 08:10.250 --> 08:13.000 nice and convenient for the phase one tunnel. 120 08:13.000 --> 08:20.150 For phase two, as we start to move down here, we have to configure several 121 08:20.150 --> 08:24.650 different entities and start to apply those entities to the interface, as well 122 08:24.650 --> 08:28.000 as to one another, to some extent. 123 08:28.000 --> 08:32.310 The transform set is how we're going to establish the phase two tunnel. We need WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 123 08:28.000 --> 08:32.310 The transform set is how we're going to establish the phase two tunnel. We need 124 08:32.310 --> 08:34.000 to set configuration parameters. 125 08:34.000 --> 08:39.960 For example, we're going to use ESP or authentication header. We also have to 126 08:39.960 --> 08:45.000 set our encryption methods, as well as our authentication methods. 127 08:45.000 --> 08:47.890 Now, we might say, "Oh, okay, well, if I'm using authentication header, I'm 128 08:47.890 --> 08:54.870 going to have to configure authentication methodologies, but if I configure ESP 129 08:54.870 --> 08:57.000 , then I would only have to configure encryption." 130 08:57.000 --> 09:02.330 That might be how we'd interpret this, but keep in mind, ESP does both. It sets WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 130 08:57.000 --> 09:02.330 That might be how we'd interpret this, but keep in mind, ESP does both. It sets 131 09:02.330 --> 09:07.320 encryption and authentication, so I'm going to have to set both of these if I'm 132 09:07.320 --> 09:10.000 using ESP, which is likely in a production environment. 133 09:10.000 --> 09:15.450 I'm also going to set that tunnel versus transport mode. Remember the 134 09:15.450 --> 09:19.000 difference. This is very important when we're setting up our tunnels. 135 09:19.000 --> 09:23.950 If I look at my overall packet that I'm encapsulating, remember, I'm going to 136 09:23.950 --> 09:28.000 put the outer header out here, and this can't be encrypted. 137 09:28.000 --> 09:31.630 I cannot encrypt the outer header because that's what the underlay is looking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 137 09:28.000 --> 09:31.630 I cannot encrypt the outer header because that's what the underlay is looking 138 09:31.630 --> 09:36.420 at. If the underlay can't read the outer IP address, then they can't get me to 139 09:36.420 --> 09:38.000 my final destination. 140 09:38.000 --> 09:43.920 I cannot encrypt the outer header. What I can encrypt is the inner header and 141 09:43.920 --> 09:49.220 the payload from the original packet. The payload will say, "This is going to 142 09:49.220 --> 09:53.000 be encrypted for the transport mode operation." 143 09:53.000 --> 09:57.910 The tunnel mode operation says, "Okay, yeah, we're going to encrypt the payload 144 09:57.910 --> 10:02.000 , but we're also going to go ahead and encrypt the inner header." WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 144 09:57.910 --> 10:02.000 , but we're also going to go ahead and encrypt the inner header." 145 10:02.000 --> 10:05.830 This is considered to be a little bit more secure because even if we used 146 10:05.830 --> 10:11.250 transport mode to encrypt the payload, that's great, but this thread actor who 147 10:11.250 --> 10:15.240 's acting down here, we've protected the payload, but they can still see where 148 10:15.240 --> 10:16.000 we're going. 149 10:16.000 --> 10:20.100 We can still see the final destination IP address, which might be well inside 150 10:20.100 --> 10:23.980 the network. Maybe it's a server. Maybe it's a credit card server that I'm 151 10:23.980 --> 10:28.990 targeting with this communication, and so now they can see the IP address 152 10:28.990 --> 10:31.000 because we didn't encrypt the inner header. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 10:28.990 --> 10:31.000 because we didn't encrypt the inner header. 153 10:31.000 --> 10:35.080 That would be why we'd want to consider using tunnel mode, especially when we 154 10:35.080 --> 10:38.880 're using something like the Internet, and it's a seriously untrusted 155 10:38.880 --> 10:40.000 environment. 156 10:40.000 --> 10:44.100 That is the transform set, and that's the value in configuring different 157 10:44.100 --> 10:47.000 options, and we'll see how exactly that works. 158 10:47.000 --> 10:50.110 It's a little bit different than we might expect. We don't configure a 159 10:50.110 --> 10:54.000 transform set and then start to configure options like we often do. 160 10:54.000 --> 10:59.100 Instead, it's all one line for the most part. We'll see that coming up here. It 161 10:59.100 --> 11:02.000 's, again, kind of interesting how it comes together. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 161 10:59.100 --> 11:02.000 's, again, kind of interesting how it comes together. 162 11:02.000 --> 11:08.000 Number three. Next thing we need to do is configure an IPsec profile. 163 11:08.000 --> 11:16.980 The IPsec profile is going to receive the transform set. I actually apply the 164 11:16.980 --> 11:24.330 transform set here to the IPsec profile, and the IPsec profile also allows for 165 11:24.330 --> 11:26.000 other options. 166 11:26.000 --> 11:31.660 The most part, we don't use those options very often, but if we need them, then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 166 11:26.000 --> 11:31.660 The most part, we don't use those options very often, but if we need them, then 167 11:31.660 --> 11:35.000 they're there. If we're not using those options, it feels a little silly 168 11:35.000 --> 11:37.990 because all we're really doing is saying, "Hey, I'm going to apply this one 169 11:37.990 --> 11:41.760 transform set to this one profile," and we might have said, "Hey, let's just 170 11:41.760 --> 11:45.000 not configure a profile," but it is what it is. 171 11:45.000 --> 11:54.000 Lastly, we're going to apply this IPsec profile to the tunnel interface. 172 11:54.000 --> 12:00.110 We do need to put configuration on the tunnel interface. We have to apply the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 172 11:54.000 --> 12:00.110 We do need to put configuration on the tunnel interface. We have to apply the 173 12:00.110 --> 12:06.000 IPsec profile, but we also need to set the protection mechanism. 174 12:06.000 --> 12:12.300 Basically specifying that, "Yeah, we're going to use this particular 175 12:12.300 --> 12:17.000 configuration," and then we're also going to have to set the IPsec mode. 176 12:17.000 --> 12:21.890 We'll see that configuration here coming up, and the tunnel configuration at 177 12:21.890 --> 12:26.000 that point should be the end of this, so we should be good to go. 178 12:26.000 --> 12:30.490 We've got our phase one configuration in place. We've got all of our phase two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 178 12:26.000 --> 12:30.490 We've got our phase one configuration in place. We've got all of our phase two 179 12:30.490 --> 12:36.190 information there as well, and so that's going to apply it to the tunnel, and 180 12:36.190 --> 12:40.000 as long as I do that on both sides, we should see the IPsec tunnel come online. 181 12:40.000 --> 12:45.430 At that point, our tunnel is protected. One last note in all of this is that 182 12:45.430 --> 12:49.000 this skill is going to be focusing on IKEV1. 183 12:49.000 --> 12:53.460 The reason for that is because this is not a security course. This is a 184 12:53.460 --> 12:57.000 security section within an enterprise networking course. 185 12:57.000 --> 13:02.300 Cisco really wants us to understand the mechanisms of IKEV1 because it's the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 185 12:57.000 --> 13:02.300 Cisco really wants us to understand the mechanisms of IKEV1 because it's the 186 13:02.300 --> 13:06.000 foundational concepts and principles of forming a secure connection. 187 13:06.000 --> 13:11.400 IKEV2 is a little bit more complex in its configuration, and it's really 188 13:11.400 --> 13:14.000 outside the scope of the course. 189 13:14.000 --> 13:18.620 If you want to learn more about IKEV2, we have a score course that would stand 190 13:18.620 --> 13:23.000 for security course, sort of like this is the enterprise networking course exam 191 13:23.000 --> 13:23.000 and course. 192 13:23.000 --> 13:28.000 Cisco has a security core exam, and therefore we have a security core course. 193 13:28.000 --> 13:35.710 We can go ahead and check out IKEV2 over in our other security content, but for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 193 13:28.000 --> 13:35.710 We can go ahead and check out IKEV2 over in our other security content, but for 194 13:35.710 --> 13:40.620 again, staying within the scope and context of the encore, we are going to be 195 13:40.620 --> 13:46.720 focusing in on IKEV1 for our configuration, and really, as we've seen, most of 196 13:46.720 --> 13:52.000 our conversations are just centered around this more foundational protocol.