WEBVTT 00:00.390 --> 00:06.600 Now, something else that you're really going to need to know backwards and forwards is the IP header 00:06.600 --> 00:07.170 fields. 00:07.560 --> 00:14.430 Of course, this is critical because so many attacks are going to involve elements of these headers. 00:15.150 --> 00:22.440 Now the IP header, remember, its whole job is to encapsulate additional network layer information 00:22.440 --> 00:23.520 onto the data. 00:23.910 --> 00:30.870 So there is this IP header that is encapsulated onto the data at the network layer. 00:31.290 --> 00:38.220 There's a transmission control protocol header that would be attached if this traffic was using transmission 00:38.220 --> 00:39.330 control protocol. 00:39.660 --> 00:43.260 How do you know if the traffic needs to use transmission control protocol? 00:43.350 --> 00:45.060 Well, you'll learn that in a moment. 00:45.720 --> 00:51.120 So it all begins with this 14 fields, 13 of which are required. 00:51.450 --> 00:54.880 And this is where we start to get into a crappy. 00:54.900 --> 00:55.380 That's right. 00:55.380 --> 01:02.520 I said a crappy thing about IP version four, and that is that we can have a variable length header 01:02.760 --> 01:08.040 that's not good that places strain on the entire system. 01:08.310 --> 01:11.340 Routers have to deal with these variable length headers. 01:11.610 --> 01:18.420 All our network devices have to deal with the header of a variable length, which is trickier then a 01:18.420 --> 01:25.890 fixed length header, which is exactly what IPv6, the next generation of TCP IP brings us. 01:26.220 --> 01:30.000 So any ways stuck with this format? 01:30.000 --> 01:33.000 We have 14 fields, 13 of which are required. 01:33.240 --> 01:37.050 We have an options field that could throw that off. 01:37.080 --> 01:42.510 There's options that could be added, which is why 13 are required. 01:42.510 --> 01:44.820 The one field options field is optional. 01:45.450 --> 01:45.960 All right. 01:45.960 --> 01:47.220 Let's go through the fields. 01:47.220 --> 01:48.480 They are critically important. 01:48.480 --> 01:51.030 There's the four bit version field. 01:51.180 --> 01:57.840 This is a snooze fest because this is always going to be set to four for this version for traffic, 01:58.140 --> 02:02.580 the internet header length notice the Internet header length, four bits. 02:02.820 --> 02:07.860 This is another field that's only required because of a variable length header. 02:07.980 --> 02:08.430 Yuck. 02:09.000 --> 02:11.880 Next up, the DSC P six bits. 02:12.240 --> 02:19.950 These bits and the two bits that follow used to be the eight bits of what we call the type of service 02:19.950 --> 02:20.520 byte. 02:21.000 --> 02:27.660 This is now broken up into the differentiated services code point or control point and the explicit 02:27.660 --> 02:29.460 congestion notification. 02:30.150 --> 02:34.680 What these two settings are all about is quality of service. 02:34.680 --> 02:42.390 The DSP six bits can indicate the priority of the traffic and how the traffic should be treated on a 02:42.390 --> 02:43.650 hot by heart basis. 02:44.070 --> 02:53.040 For example, voice over IP traffic would get the very highest possible DHCP bit settings so that it 02:53.040 --> 02:56.070 would be identified as voice over IP. 02:56.730 --> 03:04.080 The explicit congestion notification bits are for just that one node notifying another node that it 03:04.080 --> 03:07.020 is congested and please slow down. 03:07.950 --> 03:09.360 The IP header. 03:09.360 --> 03:12.570 Next field that we need to discuss is the total length field. 03:12.600 --> 03:13.830 16 bits. 03:14.190 --> 03:21.090 Another field that sucks and is only there because of the fact that it is a variable length header. 03:21.810 --> 03:24.510 Next up, we have the identification. 03:24.930 --> 03:27.840 This is critical for fragmentation. 03:28.140 --> 03:34.770 So if packets are going to be fragmented, the ID field can be used to help group fragments. 03:35.220 --> 03:37.230 Next up, we have the flags. 03:37.440 --> 03:39.150 It's important to know the flags. 03:39.390 --> 03:40.620 Three bits here. 03:40.800 --> 03:41.940 There's one reserved. 03:41.940 --> 03:42.690 You can't use it. 03:42.690 --> 03:45.780 And then don't fragment or must fragment. 03:46.170 --> 03:50.100 So we have these related to fragmentation. 03:50.250 --> 03:55.350 So the flags in the IP header are directly related to fragmentation. 03:56.250 --> 03:58.640 Next up, the fragment offset. 03:58.650 --> 04:04.080 So because fragments, packets can be fragmented, the fragment offset. 04:05.240 --> 04:10.400 Allows us to determine exactly where the fragmentation is occurring in the packet. 04:11.150 --> 04:13.250 Next up, the time to live. 04:13.280 --> 04:15.770 This is so critical in the IP header. 04:16.100 --> 04:22.040 This is a countdown to zero, which means the packet gets thrown away. 04:22.280 --> 04:24.980 This is our loop protection mechanism. 04:25.250 --> 04:34.220 So as each router passes the IP header from router to router, they are decrement ding the time to live 04:34.220 --> 04:36.020 down from 255. 04:36.230 --> 04:38.930 And when it gets to zero, that's it. 04:39.110 --> 04:40.370 The packet gets dropped. 04:41.210 --> 04:42.750 The protocol field. 04:42.770 --> 04:44.790 This is a great field. 04:44.810 --> 04:53.180 This is kind of the glue matching this encapsulated data to some other protocol. 04:53.190 --> 04:56.900 For instance, UDP, which is. 04:56.930 --> 04:58.140 Ah, let me see. 04:58.160 --> 05:05.750 UDP is protocol number 17, I believe, and TCP is protocol number six. 05:05.930 --> 05:10.220 I might have those reversed, but it's been a while since I've looked at those protocol numbers. 05:10.400 --> 05:14.360 But you get the idea and I will have that corrected in a moment. 05:14.720 --> 05:20.420 But the protocol field is going to indicate what protocol is going to be utilized. 05:20.690 --> 05:22.250 The header checksum. 05:22.250 --> 05:28.580 Any time you see the word checksum, you know it's about error correction and error checking. 05:28.580 --> 05:30.680 And that's exactly what that field is doing. 05:31.310 --> 05:34.790 And I just checked imagine that I was correct. 05:35.000 --> 05:38.870 Six is TCP and 17 is UDP. 05:39.890 --> 05:46.790 I remember that order, I guess because the lower number, the more common TCP and then the higher number 05:46.790 --> 05:50.150 of 17 associated with UDP, less common. 05:50.980 --> 05:52.510 Oh, let's see. 05:53.410 --> 05:53.900 What else? 05:53.920 --> 05:54.390 Oh, yeah. 05:54.400 --> 05:56.370 The source IP address. 05:56.380 --> 05:58.240 We got to keep going here in our story. 05:58.270 --> 06:01.530 Now, that's a 32 bit source IP address. 06:01.540 --> 06:02.170 Duh. 06:02.350 --> 06:04.780 And then a 32 bit destination. 06:04.780 --> 06:05.770 IP address. 06:05.950 --> 06:06.490 Duh. 06:06.700 --> 06:07.540 Double duh. 06:07.960 --> 06:09.700 And then the options field. 06:09.970 --> 06:15.880 This is a variable playing field that doesn't need to be used, and it often is not. 06:16.210 --> 06:23.920 So these are the important fields that make up the IP header, and I hope you have a new sense for all 06:23.920 --> 06:31.660 the information that gets encapsulated on to the data in order for a packet to make its way successfully 06:31.810 --> 06:33.040 from point A to point B.