WEBVTT 1 00:00.000 --> 00:06.620 So, quick few tidbits about IPsec, especially as it relates to our traffic flow 2 00:06.620 --> 00:06.740 . 3 00:06.740 --> 00:08.960 First of all, let's talk about MTU. 4 00:08.960 --> 00:11.200 MTU is always a really tricky thing. 5 00:11.200 --> 00:13.760 We have to understand that there are two different types of MTU. 6 00:13.760 --> 00:16.760 There's layer 2 MTU and layer 3 MTU. 7 00:16.760 --> 00:19.940 And when it comes to IPsec, we're talking about layer 3. 8 00:19.940 --> 00:24.480 Layer 2 is interesting because there's no fragmentation with ethernet. 9 00:24.480 --> 00:25.840 It doesn't allow it. 10 00:25.840 --> 00:29.960 And therefore, if we exceed MTU, the packet gets dropped. 11 00:29.960 --> 00:35.040 Layer 3 is a little more friendly because we will fragment a packet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:29.960 --> 00:35.040 Layer 3 is a little more friendly because we will fragment a packet. 12 00:35.040 --> 00:40.410 And that's good because if I don't realize that I sent a big fat jumbo frame to 13 00:40.410 --> 00:41.280 a router, 14 00:41.280 --> 00:46.010 well, at that point, it'll just send it out in fragments and the other router 15 00:46.010 --> 00:46.960 will receive 16 00:46.960 --> 00:50.920 it and assemble it and send it on its way. 17 00:50.920 --> 00:54.890 And so that's a good thing for us, but sometimes this fragmentation is 18 00:54.890 --> 00:56.300 happening and we don't 19 00:56.300 --> 00:57.400 even realize it. 20 00:57.400 --> 01:02.880 We're just sitting there happily thinking our network is running and running WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 20 00:57.400 --> 01:02.880 We're just sitting there happily thinking our network is running and running 21 01:02.880 --> 01:04.280 well and properly 22 01:04.280 --> 01:06.760 and the fragmentation sort of saving us. 23 01:06.760 --> 01:08.580 And we didn't even know it was happening. 24 01:08.580 --> 01:09.920 So what's the downside to this? 25 01:09.920 --> 01:10.920 Or is there one? 26 01:10.920 --> 01:17.240 Well, the downside is that this ramps up CPU cycles on our routers. 27 01:17.240 --> 01:20.390 And it's not a big deal if especially we're in a lab environment and we're just 28 01:20.390 --> 01:20.720 kind of 29 01:20.720 --> 01:24.320 running ping-tacks and everything's going to go through just fine. 30 01:24.320 --> 01:29.000 It's when we ramp up a production network and we have loads of packets. 31 01:29.000 --> 01:32.360 And if every single packet needs to get fragmented or at least a significant WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 31 01:29.000 --> 01:32.360 And if every single packet needs to get fragmented or at least a significant 32 01:32.360 --> 01:33.920 percentage of them, 33 01:33.920 --> 01:38.640 well, now we're going to start to see CPU overloads on our devices. 34 01:38.640 --> 01:43.160 So we talked before about GRE and for that matter, as we'll see with VXLAN, 35 01:43.160 --> 01:44.120 like there's 36 01:44.120 --> 01:50.480 just a amount of extra bits that get added anytime we're tunneling. 37 01:50.480 --> 01:55.240 So when we tunnel packets, we're going to use extra encapsulation, which means 38 01:55.240 --> 01:55.560 that 39 01:55.560 --> 01:58.760 we have extra headers. 40 01:58.760 --> 02:01.560 And extra headers show up in two different ways. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 40 01:58.760 --> 02:01.560 And extra headers show up in two different ways. 41 02:01.560 --> 02:06.690 First of all, it's going to show up as an inner header, which now is part of 42 02:06.690 --> 02:07.720 the payload. 43 02:07.720 --> 02:10.840 It wasn't part of the payload before, but now it is. 44 02:10.840 --> 02:17.660 So something like an IP or possibly IP with TCP or UDP, this can start to add 45 02:17.660 --> 02:19.440 to our MTU. 46 02:19.440 --> 02:25.110 The other place it shows up is in the actual tunnel header, such as the GRE or 47 02:25.110 --> 02:25.960 the VXLAN. 48 02:25.960 --> 02:32.360 And for that matter, now we're talking about adding ESP or AH as part of IPSec. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 48 02:25.960 --> 02:32.360 And for that matter, now we're talking about adding ESP or AH as part of IPSec. 49 02:32.360 --> 02:36.000 And so this starts to ramp up our bits and bytes as well. 50 02:36.000 --> 02:41.630 So what very often happens with tunneling is we get exactly this scenario where 51 02:41.630 --> 02:42.040 we don't 52 02:42.040 --> 02:46.970 even realize it, but now our packets at 1500 bytes, which would normally have 53 02:46.970 --> 02:48.200 been fine, 54 02:48.200 --> 02:50.120 those are going to be too big. 55 02:50.120 --> 02:55.510 And we're sort of saved by this process by which we rely on fragmentation in 56 02:55.510 --> 02:56.200 order to 57 02:56.200 --> 02:58.260 get our packets across. 58 02:58.260 --> 03:02.310 So yeah, we might have to deal with additional CPU cycles, although devices WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 58 02:58.260 --> 03:02.310 So yeah, we might have to deal with additional CPU cycles, although devices 59 03:02.310 --> 03:03.160 that are built 60 03:03.160 --> 03:07.650 for IPSec are going to have a whole lot more resources to handle fragmentation 61 03:07.650 --> 03:08.400 because it's 62 03:08.400 --> 03:11.360 such a common part of the process. 63 03:11.360 --> 03:16.760 Where we might find issue is if we have any kind of situation where our devices 64 03:16.760 --> 03:17.240 don't 65 03:17.240 --> 03:19.200 support fragmentation. 66 03:19.200 --> 03:24.440 For example, VXLAN itself doesn't have fragmentation support. 67 03:24.440 --> 03:27.040 It's a do not fragment type of scenario. 68 03:27.040 --> 03:30.590 Not as big of a deal because VXLAN is layer two and layer two doesn't have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 68 03:27.040 --> 03:30.590 Not as big of a deal because VXLAN is layer two and layer two doesn't have 69 03:30.590 --> 03:32.040 fragmentation. 70 03:32.040 --> 03:35.360 Anyways, and so we're usually talking about jumbo frames and all kinds of 71 03:35.360 --> 03:36.000 things that 72 03:36.000 --> 03:39.630 says, hey, you know, VXLAN's probably not a big deal, we're probably operating 73 03:39.630 --> 03:39.920 in an 74 03:39.920 --> 03:43.240 environment that can support the extra bits. 75 03:43.240 --> 03:49.560 But with IPSec and GRE, these are again a little bit more layer three focused. 76 03:49.560 --> 03:54.600 And so they're going to be built on an underlay that is probably looking more 77 03:54.600 --> 03:56.120 at 1500 byte 78 03:56.120 --> 03:58.960 MTUs rather than something much larger. 79 03:58.960 --> 04:03.820 And as a result, this 1500 bytes, once we add in inner headers and once we add WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 79 03:58.960 --> 04:03.820 And as a result, this 1500 bytes, once we add in inner headers and once we add 80 04:03.820 --> 04:04.520 in tunnel 81 04:04.520 --> 04:08.920 headers, now all of a sudden we're going to start to exceed MTU. 82 04:08.920 --> 04:12.080 So what's the take primary takeaway from this? 83 04:12.080 --> 04:15.480 There isn't much of one other than awareness. 84 04:15.480 --> 04:18.960 We just don't want to be clueless that this is happening. 85 04:18.960 --> 04:22.920 So that if we do see CPU spiking, if we do see packets getting dropped, that we 86 04:22.920 --> 04:23.360 might 87 04:23.360 --> 04:26.840 say, hey, maybe we should check in on this fragmentation situation and find out 88 04:26.840 --> 04:27.240 if this 89 04:27.240 --> 04:29.280 is going to be a problem for us or not. 90 04:29.280 --> 04:32.000 And you say, well, is there a way to prevent fragmentation? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 04:29.280 --> 04:32.000 And you say, well, is there a way to prevent fragmentation? 91 04:32.000 --> 04:34.860 Well, there's only two ways to prevent fragmentation. 92 04:34.860 --> 04:40.480 We can either reduce the MTU coming in, which is very painful to do. 93 04:40.480 --> 04:43.680 We have to go around to all of our different hosts and make sure that none of 94 04:43.680 --> 04:44.520 them are sending 95 04:44.520 --> 04:51.760 with more than 1400 bytes or so of payload data in order to avoid this. 96 04:51.760 --> 05:00.000 The more realistic goal would be to increase the MTU in the underlay. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 96 04:51.760 --> 05:00.000 The more realistic goal would be to increase the MTU in the underlay. 97 05:00.000 --> 05:02.360 Now you have to ask the question, do we control the underlay? 98 05:02.360 --> 05:03.760 Is this a service provider? 99 05:03.760 --> 05:05.080 Is it the internet? 100 05:05.080 --> 05:08.720 Because if we don't control the underlay, then maybe that's no more realistic 101 05:08.720 --> 05:09.600 than decreasing 102 05:09.600 --> 05:13.200 the MTU on all of our Windows PCs, for example. 103 05:13.200 --> 05:18.560 So fortunately, fragmentation is going to continue to be an option for us. 104 05:18.560 --> 05:21.240 Let's just make sure we're aware that this is happening. 105 05:21.240 --> 05:26.520 Now the question also is, OK, but how much are we talking about here? 106 05:26.520 --> 05:32.400 What should the MTU change by in order for us to support IPsec? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 106 05:26.520 --> 05:32.400 What should the MTU change by in order for us to support IPsec? 107 05:32.400 --> 05:35.240 Well, IPsec makes things a little bit difficult. 108 05:35.240 --> 05:36.880 With GRE, it was pretty simple. 109 05:36.880 --> 05:39.320 I need another IP header, which is 20. 110 05:39.320 --> 05:43.470 I need the GRE header, which is 4, which as long as we don't include other 111 05:43.470 --> 05:44.160 options, it 112 05:44.160 --> 05:45.240 stays at 4. 113 05:45.240 --> 05:48.280 And so it's a total of 24 bytes. 114 05:48.280 --> 05:51.880 But with IPsec, things get a little bit more complicated. 115 05:51.880 --> 05:55.400 For example, are we running ESP? 116 05:55.400 --> 05:59.040 And if we're running ESP, are we running with AES? 117 05:59.040 --> 06:01.680 Are we running another encryption algorithm? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 117 05:59.040 --> 06:01.680 Are we running another encryption algorithm? 118 06:01.680 --> 06:03.920 Are we running with AH? 119 06:03.920 --> 06:08.400 If we're running on ESP or AH, are we using MD5 hashing? 120 06:08.400 --> 06:09.640 Are we using SHA hashing? 121 06:09.640 --> 06:15.560 And all of this changes and creates some amount of variance. 122 06:15.560 --> 06:18.240 So AH is a little bit smaller, as I might imagine. 123 06:18.240 --> 06:19.560 There's less going on. 124 06:19.560 --> 06:26.760 And so we can get as low as 44 bytes of overhead for AH. 125 06:26.760 --> 06:30.120 And with ESP, depending on our options, we can actually get as high as an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 125 06:26.760 --> 06:30.120 And with ESP, depending on our options, we can actually get as high as an 126 06:30.120 --> 06:31.080 additional 127 06:31.080 --> 06:32.000 73 bytes. 128 06:33.000 --> 06:40.190 And, to be clear, there's a lot of values in between these two that can result 129 06:40.190 --> 06:41.040 in us, 130 06:40.990 --> 07:01.920 for us 131 06:41.040 --> 06:42.400 you know, depending on our options. 132 06:42.400 --> 06:46.720 We might end up at 70 bytes, for example, or something like that. 133 06:46.720 --> 06:48.560 So what do we do with this information? 134 06:48.560 --> 06:52.980 Well, again, if we're going to make changes, either to the hosts or to the 135 06:52.980 --> 06:54.080 underlay, then 136 06:54.080 --> 06:57.960 we need to account for probably the worst case scenario here. 137 06:57.960 --> 07:01.920 And even though we could subtract that from 1500, I will say it's pretty common WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 138 07:01.920 --> 07:08.940 to aim for a 1400 byte type of MTU shift, because that accounts for not just 139 07:08.940 --> 07:10.400 this overhead, 140 07:10.400 --> 07:14.680 but also potentially additional overhead if we're doubling capsulating anything 141 07:14.680 --> 07:15.000 like 142 07:15.000 --> 07:16.000 that. 143 07:16.000 --> 07:19.480 At that point, it's not worth trying to eke out every last byte. 144 07:19.480 --> 07:22.720 We might as well just call it good at 1400 bytes. 145 07:22.720 --> 07:26.280 So that's something to keep in mind with the MTU and IPsec. 146 07:26.280 --> 07:31.440 One other thing I wanted to toss out is the concept of crypto maps. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 146 07:26.280 --> 07:31.440 One other thing I wanted to toss out is the concept of crypto maps. 147 07:31.440 --> 07:36.220 So, crypto maps are a legacy mechanism, but as with all legacy mechanisms, we 148 07:36.220 --> 07:36.560 're probably 149 07:36.560 --> 07:40.630 going to run into this at some point, whether in production networks and lab 150 07:40.630 --> 07:41.840 networks, possibly 151 07:41.840 --> 07:45.080 on an exam, hopefully not, but you just never know. 152 07:45.080 --> 07:46.600 So what is a crypto map? 153 07:46.600 --> 07:52.440 Well, we have focused on two routers having a tunnel connection between them. 154 07:52.440 --> 07:56.440 Well, we didn't always have the luxury of assuming there was going to be a 155 07:56.440 --> 07:57.120 tunnel. 156 07:57.120 --> 08:02.400 We might have just had a bunch of routers in between, and I want to secure WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 156 07:57.120 --> 08:02.400 We might have just had a bunch of routers in between, and I want to secure 157 08:02.400 --> 08:03.000 traffic that's 158 08:03.000 --> 08:06.800 going from this interface to this interface. 159 08:06.800 --> 08:08.960 Well, that was the purpose of the crypto map. 160 08:08.960 --> 08:14.140 The crypto map would see as traffic was really not coming into the router so 161 08:14.140 --> 08:15.320 much as routing 162 08:15.320 --> 08:19.940 through the router and going out this interface, the crypto map would apply to 163 08:19.940 --> 08:20.920 this interface 164 08:20.920 --> 08:25.760 and use an access control list to identify what was known as interesting 165 08:25.760 --> 08:26.680 traffic. 166 08:26.680 --> 08:28.840 This is the phrase that we would use for this. 167 08:28.840 --> 08:33.310 It said, "Hey, I don't necessarily want to encrypt everything that gets sent WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 167 08:28.840 --> 08:33.310 It said, "Hey, I don't necessarily want to encrypt everything that gets sent 168 08:33.310 --> 08:33.800 out this 169 08:33.800 --> 08:38.450 interface, but if it's targeting this IP address or maybe we could even 170 08:38.450 --> 08:39.840 identify specific 171 08:39.840 --> 08:44.180 sources out here that we want to encrypt, at that point we're going to call 172 08:44.180 --> 08:45.280 this interesting 173 08:45.280 --> 08:47.720 and we're going to apply our encryption headers." 174 08:47.720 --> 08:49.800 So, the tunnel isn't required. 175 08:49.800 --> 08:53.740 We can encrypt the tunnel and at that point, sure, we're going to encrypt 176 08:53.740 --> 08:54.520 everything as 177 08:54.520 --> 08:57.560 it goes across that tunnel. 178 08:57.560 --> 09:03.620 But we also, before tunnels were really a major factor, we could use crypto WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 178 08:57.560 --> 09:03.620 But we also, before tunnels were really a major factor, we could use crypto 179 09:03.620 --> 09:04.440 maps in order to 180 09:04.440 --> 09:06.080 accomplish this. 181 09:06.080 --> 09:09.040 Now there were several downsides to crypto map. 182 09:09.040 --> 09:14.000 Maps not the least of which, by the way, is the fact that it didn't support 183 09:14.000 --> 09:14.760 broadcast 184 09:14.760 --> 09:17.520 or multicast. 185 09:17.520 --> 09:22.990 But if we're not supporting broadcast and multicast, then we're not supporting 186 09:22.990 --> 09:23.280 routing 187 09:23.280 --> 09:26.560 adjacencies across it either. 188 09:26.560 --> 09:32.390 So there wasn't a way for us to form a direct EIGRP or OSPF relationship WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 188 09:26.560 --> 09:32.390 So there wasn't a way for us to form a direct EIGRP or OSPF relationship 189 09:32.390 --> 09:33.600 through, again, 190 09:33.600 --> 09:37.400 what is effectively an underlay here between the two devices. 191 09:37.400 --> 09:41.160 So tunnels allow us to accomplish this. 192 09:41.160 --> 09:45.070 This is important, by the way, if this is like the internet and I'm trying to 193 09:45.070 --> 09:45.600 connect 194 09:45.600 --> 09:49.600 two sites, I really would want to have a routing relationship. 195 09:49.600 --> 09:53.160 If it's a different situation, maybe we could just have routing everywhere. 196 09:53.160 --> 09:57.320 But as we see, it's going to really hold us back. 197 09:57.320 --> 10:00.720 It was holding us back, relying entirely on crypto maps. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 197 09:57.320 --> 10:00.720 It was holding us back, relying entirely on crypto maps. 198 10:00.720 --> 10:06.020 So now instead, in a modern network, we're usually forming tunnels and applying 199 10:06.020 --> 10:07.000 our configuration 200 10:07.000 --> 10:11.320 to the tunnel, which is going to be what our focus is here within this scale. 201 10:11.320 --> 10:15.330 But be aware that crypto maps existed and that there's still a thing we can 202 10:15.330 --> 10:16.320 configure, 203 10:16.320 --> 10:19.240 but for the most part, it is considered legacy in the modern network.