Learn how Wireshark and tcpdump, two powerful network packet analysis tools, can be used to solve real-world problems on local networks. Monitor network traffic, detect anomalies, and keep your network secure with these useful tools.
1014 
Network layer protocols are key components of communication networks, responsible for transferring data between different devices on the network. In the world of computer technology, there are many different network layer protocols, each of which performs its own functions and has its own characteristics. Analyzing these protocols becomes an important task for network security engineers, network administrators, and developers. Wireshark and tcpdump are powerful network traffic analysis tools that allow you to monitor and record packets of data transmitted over the network. They allow you to carefully study network layer protocols, detect errors, analyze connections between devices, and much more.
You will learn about the variety of protocols, their functions and features, and how to use these tools to identify problems, optimize your network, and keep it secure. Network layer protocol analysis skills are very valuable in the field of information security and network administration. This text will help you gain a deeper understanding of the importance of these protocols and learn how to effectively use analysis tools to achieve optimal performance and security for your network. Network-level protocols in Wireshark and tcpdump are fundamental components of modern networks and play a critical role in ensuring reliable data exchange between computers and devices. To achieve efficient network operation and ensure its security, it is important to understand how these protocols work and how they affect data transmission. Analysis of network layer protocols is an important part of the work of network security engineers and network administrators. It allows detecting anomalies, vulnerabilities and errors in the network, as well as optimizing its operation. These protocols include important standards such as IPv4, IPv6, ICMP, IGMP and many others. In addition, there are specialized protocols for various network services such as VPN, VoIP, and network security.
To detect anomalous network traffic, including diagnosing network latency, detecting malware, or fully mitigating security threats, you need to know what normal network traffic is. This chapter and the next two chapters explain how network traffic works both at the packet level and at all layers of the OSI model from bottom to top. Each part of the network protocol discussed here has at least one intercept file associated with it that can be downloaded and used directly.
In this chapter, we will talk about network layer protocols, which are the main executive mechanism for exchanging data over the network. These include ARP, IPv4, IPv6, ICMP, and ICMPv6.
This and the next two chapters on network protocols are certainly some of the most important in this book. Skipping the material in these sections is like trying to cook a holiday dinner without heating the oven. If you already know how network protocols work, review these chapters at least briefly to refresh your memory on the structure of the packets in each of them.
Logical and physical addresses are used to exchange data over the network. In particular, logical addresses are used to exchange data across multiple networks between indirectly connected devices. And physical addresses simplify the exchange of data in one network segment between devices that are directly connected to each other through a switch. As a rule, both of these types of addressing must communicate in order for normal communication to occur over the network.
As an example, consider the scenario when you need to transfer data to a device connected to the network. This device can be a server with a specific port or a workstation with which you want to communicate with the device on the network. The application used to initiate the connection already knows the remote host’s 1P address (via the DNS service, as explained in Chapter 9). This means that the system must have everything necessary to generate data from levels three to seven in the packet to be transmitted. And the only part of the data needed at this point is the second link layer information containing the MAC address of the target host.
MAC addresses are necessary because the switch that connects the devices on the network uses an associative memory table that lists the MAC addresses of all devices and their corresponding port numbers. When a passenger receives network traffic destined for a device with a specific MAC address, it uses this table to determine the port number through which the traffic should be forwarded. If the recipient’s MAC address is unknown, the transmitting device will first look for that address in its cache. And if the desired address is not in the cache, then it can be obtained by additional data exchange over the network.
The process used in TCP/1P (IPv4) networks to convert a 1P address to a MAC address is called Address Resolution Protocol (ARP). This is defined in RFC 826. Only two types of packets are used in the process of ARP address translation: ARP-0Tap (Fig. 7.1).
The sending computer sends the following message: “Hello everyone. My 1P address is 192.168. 0 .101 and my MAC address is f2 :f2 :f2 :f2 :f2 :f2 :f2. I need to send something to someone with the address 1P 192 .168. 0. 1, but I don’t know his physical address. Can whoever has this 1P address tell me their MAC address?”
This packet is sent in broadcast mode and is therefore received by every device on the network segment. All devices that do not have a specified 1P address should ignore the request mentioned above. And the device with the specified 1P-address should send the following ARP response: “Hello to the transmitting device! I am exactly who you are looking for at IP address 192 .168 . About. 1. my MAC address is 02 : f2 : 02 : P : 02 : f2”
As soon as the address translation process is completed, the transmitting device will update its cache memory and place in it the MAC and 1P address mapping of the receiving device and start transmitting data. By observing this process. In action, you can understand exactly how it works. But before moving on to specific examples, let’s look at the structure of the ARP packet header.
As shown in fig. 7.2, an ARP packet consists of a header containing the fields described below.
Type of equipment (Hardware Tour). The type of medium used in the second layer for data transfer. Typically, this is an Ethernet network (ie Type 1).
Type of protocol (Protocol Touré). An upper layer network protocol used to transmit ARP-3anpoca. Typically, this is IPv4 (0x0800).
The length of the hardware address. The length of the physical address to use (in octets or bytes). For an Ethernet network, its value is 6.
Protocol address length. The length of the logical address to use using the specified protocol type (in octets or bytes). For IPv4, its value is 4.
Operation. Packet function: code 1 for request or code 2 for response.
The address of the sender’s equipment. The physical address assigned to the sender of the packets.
Protocol address of the sender. Protocol address assigned to the sender of the packet.
The physical address of the recipient (the address of the target equipment). The physical address of the recipient to search for. All zeros are specified. Destination Protocol Address: The intended address of the recipient of the packet using the upper layer protocol.
Now open the .rsarpd capture file with arp resolution to see the address translation process in action. Considering this process, let’s focus on each package separately.
Capture file: arp _resolution.pcapng
To verify that this is indeed a broadcast packet, simply check the Ethernet header in the Packet Details panel of Wireshark. The recipient address of this packet is ff : ff : ff : ff : ff : ff A. This is the broadcast address of the Ethernet network, and anything sent on it will be received by all devices on the current network segment. The sender address of this packet is in and is essentially the MAC address of the transmitting device.
By looking at the structure of the ARP packet header discussed here, you can see what is actually being routed on IPv4 Ethernet networks. It contains the IP address. (192.168.0.114) and the MAC address (00 : 16 : ce : be : В: 24) of the sender, as well as the IP address (192 .168 . 0 . 1) of the recipient. At the same time, the MAC address of the recipient you want to find out is unknown, so it is set to 00 : 00 : 00 : 00 : 00 : 00 : 00 : 00 : 00 : 00
The response to the initial request (Figure 7.4) now contains the recipient address corresponding to the sender’s MAC address from the first packet. The header of such an ARP response looks the same as in a number of exceptions listed below.
The packet’s opcode is now 0x0002, indicating an ARP reply rather than a request.
The address information is listed in reverse order: first the MAC and IP addresses of the sender, and then the MAC and IP addresses of the recipient.
But the most important thing is that now we have all the necessary information. This means that we have determined the MAC address (00 : 13 : ba) of the host located at 192 .168 . 0. 1.
File Nepexaamaarp Usually, the word “free” has a negative connotation. But sometimes the unjustified application of the ACP protocol still gives a positive result, and in this case its packages are called self-fasing.
The device’s IP address can change frequently. At the same time, the display of IP and MAC addresses in the cache memory of network nodes may be invalid. To prevent errors during network communication, self-addressing is transmitted, which forces any receiving device to update its cache with a new correspondence between IP and MAC addresses (Fig. 7.5). In fact, this packet reports a change in the ARP protocol that has happened to a particular host.
The appearance of self-transformation can occur in a variety of cases. And most often this happens in connection with a change of IP address. To verify this, open the arp_gratuitous .pcapng file, which contains a single packet (Figure 7.6), as this is all that is sent in a self-directed ARP broadcast.
The main purpose of network protocols of the third level of the OSI model is to provide communication for data exchange between nodes located in different networks. As shown above, MAC addresses are used to communicate within the same network at the second layer. Similarly, third-level addresses are used to exchange data between different networks. There are several network protocols that can be used for this, but the most common of them is IP (Internet Protocol), which currently comes in two versions: IP version 4 and IP version 6. So, let’s start with Internet Protocol version 4 (IPv4) as defined in RFC 791.
To understand how IPv4 works, you need to know how network traffic flows between networks. IPv4 serves as the main executive mechanism in the communication process and is ultimately responsible for the transfer of data between devices, regardless of the location of the endpoints of the established connection.
A simple network in which all devices are connected through hubs or switches is called a local area network (LAN). If you need to connect two local networks, this can be done using a router. Complex shogs can consist of thousands of local networks connected worldwide by thousands of routers. The Internet itself consists of millions of local area networks and routers.
In IPv4, addresses are 32-bit numbers assigned by network administrators that uniquely identify devices connected to the network. It is unlikely that anyone will be comfortable remembering a sequence of ones and zeros with a length of 32 bits, and therefore IP addresses are written using a four-component (or decimal) numbering system using wheelbarrows.
In the dotted-decimal numbering system, each of the four sets of ones and zeros that make up an IP address is converted to a decimal number in the range 0 to 255 in the format A.B.C.D (FIG. 7.7). As an example, consider the IP address 11000000 10101000 000000000 00000001 in its original binary form. It is obvious that it is very difficult to remember or write down the IP address in this form. And in the number system with decimal points, this address can be represented as 192.168. 0. 1
An IP address consists of two parts that identify both the network itself and the node (or host) located on that network. In the network part, the number of the LAN to which the device is connected is specified, and in the node part – the number of the device itself in this network. It is not always possible to clearly determine to which part (network or node) the components of an IP address belong. Therefore, IP addresses are provided with auxiliary addressing information called a network mask or (most commonly) a subnet mask.
The network mask allows you to find out to which part (network or node) the components of the IP address belong. The length of the network mask is also 32 bits, where each bit with a set unit represents the component of the IP address that refers to the network part. And the rest of the bits with lots of zeros refer to the nodal part.
The sender and receiver IP addresses are the main components of an IPv4 packet header, but they are by no means all the IP information that can be found in a packet. The IP header is quite complex compared to the previously discussed ARP packet header. It contains many additional fields with information that help the IP protocol perform its functions. As shown in fig. 7.9, the IPv4 packet header consists of the following fields.
Interception of files ip ttl source. The lifetime value (Tirne to Live psarpd and ip ttl dest. rsarpd TTL) specifies the amount of time that can elapse, or the maximum number of routers a packet can travel through, before it is invalidated by IPv4. The lifetime is determined at the time the packet is created and is usually decremented by one when the packet is forwarded (NL to the next router. So, if a packet’s lifetime is 2, then the first router it reaches will reduce that time to 1 and forward the packet to the second router.And this, in turn, will reduce the lifetime of the packet to zero, and if the final recipient of the packet is not in the current network, then the packet is dropped (Figure 7.10).
Why is it important to remember the service life of parcels? As a rule, it is of interest only from the point of view of the time required for the transfer of the package from its sender to the recipient. Imagine, however, a packet that must reach a host over the Internet after passing through dozens of routers. At some point, this fear may encounter a misconfigured router, causing the packet to stray from its button to its final destination. In such a case, an incorrectly configured router can do many things that could disrupt the normal operation of the network. In particular, it can send a packet over the network in an infinite loop.
An infinite loop can cause a variety of complications, but as a rule, it leads to the failure of both an individual program and the entire operating system. Theoretically, the same thing can happen with packets in the network, which will be cyclically moved between marshalers. And as the number of such packets in the network grows, its bandwidth will decrease until a denial of service condition occurs. To avoid this, the expiration date of the packages was introduced.
Let’s look at a concrete example of packet sniffing in Wireshark. The IP protocol is used to deliver packets in the ICMP network protocol, discussed later in this chapter. This can be judged by expanding the relevant part of the IP header in the Packet Details panel. As shown in fig. 7.11.
The main purpose of ICMP echo request 110 is to check communication between devices. Specifically, data is sent from one host to another as a request, and the receiving host must send the data back as a response. In the above intercept file there is one device with address 10 .10. O. 3 0 sends an ICMP echo request to another device with the address 192.168. About .128 0.
This initial intercept file was generated on the sending host at 10.10. A. 3. Now open the ip_ttl_dest.pcapng capture file. In this file, data is intercepted on the receiving host at 192 .168. About .128. Expand the IP header of the first packet from this capture file to find out the lifetime of that packet.
As can be seen from fig. 7.12, the lifetime of the first packet is 127, i.e. it is 1 less than the original lifetime of this packet, which is 128. Even without knowing the network structure, we can conclude that the two devices mentioned above are separated by a router, and therefore the packet’s lifetime when passing through the router is reduced by 1.
Capture file: ipfrag_ source. pcapng
IP Interception File Packet Fragmentation is a feature of the IP protocol, both originally .rsarpd, that provides reliable data delivery over different types of networks by breaking the data stream into small fragments. Packet fragmentation is based on the Maximurn Transmission Unit (MTU) size for the link layer 2 protocol, as well as the configuration of the devices using this protocol. Typically, the Ethernet network protocol is used at the second link layer, where the default MTU block size is 1500. This means that a maximum of 1500 bytes of a packet can be transmitted over Ethernet, not including the length of 14 bytes.
When a device is ready to transmit an IP packet, it determines whether to fragment the packet by comparing the size of the data in the packet to the MTU size of the network interface over which the packet will be transmitted. If the data size is larger than the MTU, the packet will be fragmented.
The packet fragmentation process is divided into the following stages:
The device divides the data into the number of packets required for their successful transmission.
The Total Length field of each IP header sets the segment size for each segment.
All packets except the last packet in the data stream have the Moghe fragments flag.
In the Fragment offset field of the IP header, you specify the specific offset for the current fragment that it should occupy in the data stream.
The packets are then transmitted over the network.
ip frag source capture file. RSARPD was created on a computer with the address 10 .10. 0. 3, which sent an ICMP echo request to the device with the address 192.168. 0.128. Note that the column in the RasCat List panel contains two fragmented IP packets followed by an ICMP echo request. So, start by analyzing the IP header of the first packet (Fig. 7.13).
As you can see, this packet is part of a data fragment based on the values in the Moge fragments and Fragment offset fields. If the packets are fragments, the Moge fragments field will be checked, or the Fragment offset field will be set to a non-zero positive value. For example, a flag is set in the Moge fragment field of the IP header of the first packet, indicating that the receiving device should expect to receive another packet from this sequence. And in the Fragment offset field, the value e is set to zero, which indicates that this packet is the first in the sequence of fragments.
The flag is also set in the Moge fragment field of the IP header of the second packet (Figure 7.14), but this time the Fragment offset field is set to 1480. This indicates that the size of the first packet corresponds to the MTU block size and is 1500 bytes, of which 20 bytes occupies the IP header. Therefore, the data from the second received packet must be placed in the stream with an offset of 1480 bytes.
In the Moge fragment field from the IP header of the third packet (Fig. 7.15), the flag e is not set, which indicates that this is the last fragment in the data flow, and the Fragment offset field is set to 2960, obtained as a result of adding the sizes of the second and first packets ( 1500 – 20) * 2. All these fragments can be recognized as part of the same data sequence, since the ldentifcation field of their IP headers is set to the same values.
Now fragmented packets can be found on the network not as often as it was before. However, you should have a clear understanding of the causes of packet fragmentation so that you can diagnose your network or detect missing fragments when you find them.
When the IPv4 network protocol specification was drafted, no one could have imagined the number of Internet-connected devices that exist today. The maximum IPv4 address space was limited to only 4.3 billion. But the actual address space shrinks even further if you subtract the address ranges reserved for special use, such as test, broadcast, and internal RFC 1918 addresses. Although several attempts were made to delay the depletion of the pool in one way or another, in the end, only one way to overcome this limitation is to develop a new version of the specification for the IP network protocol.
Thus, the IPv6 network protocol specification was drafted, and its first version was released as RFC 2460 in 1998. This release introduced a number of performance improvements, including a significantly larger address space. In this section, we will look at the IPv6 packet structure and discuss how IPv6 differs from its predecessor in terms of network communication.
IPv4 addresses were limited to 32 bits in length, providing a space measured in billions of addresses. And the length of addresses in the IPv6 protocol is 128 bits, which is 4 times more and provides a space of 2,128 addresses that allows you to cover non-decillion hosts (that is, trillions trillions trillions). And this is a very significant improvement!
But since the length of IPv6 addresses is 128 bits, manipulating them in binary form is very inconvenient. Most often, it is written as eight two-byte groups, represented in hexadecimal, with each group separated by a colon. For example, the simplest one looks like this:
llll:aaaa:2222:bbbb:3333:cccc:4444:dddd
Looking at such an address, one involuntarily has the same thought as many who are used to remembering 1Pv4 addresses: it is almost impossible to remember IPvB addresses. And this is an inevitable compromise that had to be made in order to expand the address space. However, such an inconvenient notation of IP addresses can sometimes be simplified by collapsing some groups of zeros. Consider the following IP address as an example:
1111:0000:2222:0000:3333:4444:5555:6666
Groups of zeros can be completely collapsed to make them invisible, as shown below.
1111::2222:0000:3333:4444:5555:6666
But only one group of zeroes can be collapsed, so the following address is considered invalid:
1111::2222::3333:4444:5555:6666
It should also be borne in mind that leading zeros can be excluded from 1Pv6 addresses. Consider as an example the following address, where the fourth, fifth, and sixth groups have leading zeros:
1111:0000:2222:0333:0044:0005:ffff:ffff
This address can be represented more effectively by the following about together. Of course, using such an address is not as easy as a 1Pv4 address, but it is still much easier than using a longer record.
1111::2222:333:44:5:ffff:ffff
A 1Pv6 address also consists of network and node parts, which are often called the network prefix and the interface identifier, respectively. The distribution of these parts varies depending on the classification of data exchange according to the 1Pv6 protocol. In particular, network traffic according to the 1Pv6 protocol is divided into the following categories: unicast, multicast, or anycast. Most often, it is necessary to analyze intra-channel unidirectional traffic, i.e. data exchange between devices of the same network. The format of the intra-channel unicast 1Pv6 address in such traffic is shown in Fig. 7.16.
Intra-channel addresses are used when data needs to be transferred to another device on the same network. The internal channel address can be recognized by setting the binary value 1111111010 in its 10 most significant bits and zeros in the next 54 bits. Thus, the intrachannel address can be detected by the first half in the form fe80: 0000: 0000: 0000.
The second half of the intra-channel 1Pv6 address is the interface identifier, which uniquely identifies the network interface in the window host. In Ethernet networks, this identifier can be based on the MAC address of the network interface. But the length of the MAC address is absorbed in 48 bits. To fill all 64 bits, the MAC address is split in half and the hexadecimal value Oxfffe is inserted between the resulting halves as padding to produce a unique identifier.
And finally, the seventh bit in the first byte is addressed. This is a rather complex operation, so let’s consider the structure of the interface identifier shown in Fig. 7.17 where the source MAC address of the device indicated by this identifier is 78:31:c1:cb:b2:56. Then the bytes of the hexadecimal value Oxfffe were inserted in the middle and then the seventh bit in the first byte was reversed, changing the hexadecimal digit 8 to a.
IPv4 addresses can be represented in the previously mentioned CIDR form similarly to 1Pv4 addresses. In the following example, the 64-bit address space is represented by an intralink address: feB0:0000:0000:0000:/64 The composition of the 1Pv6 address will change when it is used in global unicast traffic routed over the open Internet (Figure 7.18).
If a 1Pv6 address is used in such traffic, global unicast is detected by having the combination 001 set in the first three bits, followed by a 45-bit global routing prefix. This prefix is assigned to organizations by the Internet Assigned Numbers Authority (IANA) and serves to uniquely identify the organization’s IP space.
The next 16 bits are allocated to the subnet identifier, which serves for hierarchical addressing, similar to the part of the 1Pv4 address that refers to the network mask. And the last 64 bits are reserved for the network interface identifier, just like in intra-channel unicast addresses. The routing prefix and subnet ID sizes can vary.
Структура заголовка в пакеті lPv6
http interception file The header structure in the IPv6 packet is extended by ip4and6. RSARPD to support additional features, although it is designed to facilitate analysis. Headers are now a fixed length of 40 bytes, rather than a variable size that previously required checking the header length field to parse it. Additional options are provided by header extensions. The advantage of this approach is that in most routers it is enough to process the 40-byte header to forward the packet further.
As shown in Fig. 7.19, it consists of the following fields.
Now let’s compare IPv4 and IPv6 packets to find out some differences using the example of their analysis from the http interception file ip4and6 .rsarpd. In the captured traffic from this file, the web server was configured to listen for both IPv4 and IPv6 connections on the same physical host. And the single client was configured to both browse the server separately for each of its addresses and load the page from the index file. php via the HTTP protocol through the library application (Fig. 7.20).
The HTTP network protocol, which is responsible for serving web pages on the Internet, will be discussed in more detail in Chapter 8, “Transport Layer Protocols.” And in this example, it should only be noted that the serving of web pages remains consistent regardless of the lower-level network protocol used. The same can be said about the TCP network protocol, which also works in concert. And this is a vivid example of the action of encapsulation. Although the IPv4 and IPv6 protocols function differently, this does not affect the protocols operating at other layers.
In fig. 7.21 Two packages, 1 and 11, that perform the same function are directly compared. Both packets are of TCP SYN type and are intended for the client to initiate a connection to the server. The Ethernet and TCP portions of these packets are virtually identical, while the IP portions are quite different.
Below are the differences found when comparing the two packages directly:
The sender and recipient formats are different.
IPv4 packet length is 74 bytes and payload length is 60 bytes including payload and 14 bytes IPv6 packet length is 96 bytes with 40 bytes payload, another 40 bytes in IPv6 header and remaining 14 bytes in Header Length IPv6-3a is 40 bytes, twice as long as 2() bytes, to account for the size of the larger address space.
Neighborhood Interception Battle When we discussed the different categories of s01ici tation earlier. As a result, we listed the unicast, multicast, and alternate traffic categories, but did not mention broadcast traffic. IPv6 does not support broadcast traffic because it is considered an inefficient data transfer mechanism. As a result, ACP cannot be used for hosts to discover each other on the network. How then, Will you be able to detect each other?
The answer to this question comes from a new feature called neighbor polling, which is a feature of the Neighbor Discovery Protocol (NDP) that uses ICMPv6, discussed in the last section of this chapter, to perform its basic functions. For this purpose, the ICMPv6 protocol uses a multicast type of data transfer that can be received and processed only by those hosts that subscribe to the flow of this data. Multicast traffic can be quickly recognized because it has its own reserved 1P address space (ff00 : : / 8).
Although the broadcast process relies on a different protocol, it uses a very simple sequence of requests and responses. As an example, consider a scenario in which a host with an IPv6 address of 2001.•08 : 1:2: 1003 needs to contact another host with an address of 2001 :d B8 : 1 : 1000. As with IPv4, the forward the device must be able to determine the connection address (MAC). The host with which it needs to communicate, since communication is established inside the network. This process is clearly illustrated in fig. 7.22.
The response to the neighbor request is in the second packet from the intercept file mentioned above. Having expanded the part of this packet related to the ICMPv6 protocol, the Packet Details panel (Fig. 7.24).
Support for ipv6 capture files for packet fragmentation has been built into zafragraents. RSARPD IPv4 protocol headers for packet provisioning
Therefore, it can pass through different networks in which the MTU blocks change significantly. And in the IPv6 protocol, packet fragmentation is used to a lesser extent, so its support parameters are not included in the IPv6 header. This assumes that a device transmitting IPv6 packets must first run a so-called MTU block size finding process to determine the maximum size of the packets to be sent before actually sending them.
If a router receives packets that are too long, exceeding the MTU size of the network where they are reached, it will drop them and return the packet to the transmitting device with an ICMPv6 Pac.ket LLP Big (Type 2) message, which is an ICMPv6 Type 2 message that the package is too big.
After receiving this message, the transmitting device will try to send the packet again, but with a lower MTU, if only such action is supported in the upper layer protocol. This process will be repeated until a sufficiently small MTU block size or the limit of fragmentation of useful information is reached (Fig. 7.25). The routing agent itself is not responsible for packet fragmentation at all, since the responsibility for determining the appropriate size of the MTU block on the transmission path and the appropriate packet fragmentation rests with the transmitting device.
If the upper-layer protocol used in conjunction with IPv6 is unable to limit the useful information in the packet, fragmentation is still necessary. In this case, the Fragmentation Extension header can be inserted into the IPv6 header. A relevant example of IPv6 packet fragmentation can be found in the ipv6 capture fragments .rsarpd file.
The receiving device has a smaller MTU than the transmitting device, and so there are two fragmented packets in this intercept file that represent each echo request. and an ICMPv6 response. The fragmentation expansion header from the first batch is shown in fig. 7.26.
Internet Control Message Protocol (ICMP) is a service protocol that is responsible in the TCP/IP protocol stack for providing information about the availability of devices, services, or routers on a TCP/IP network. Most network diagnostic tools and techniques focus on common Internet Control Protocol (ICMP) message types. The ICMP network protocol is defined in RFC 792.
ICMP is part of the Internet Protocol (IP) and uses it to transmit its messages. The Internet Control Message Protocol (ICMP) contains a relatively small header that varies depending on its purpose. As shown in fig. 7.27, the IMMR header consists of the following fields:
The capture file ()The pride of the 1CMP protocol is the echo.rsarpd ping file, which is used to check the current state of the connection between network devices. Although ping is not part of the ICMP specification, it uses this protocol to implement its core functionality.
To use ping, type ping ip-anec at the command prompt, replacing ip-anec with the specific IP address of the device on your network. If the target device is turned on, the source device will have a button to transfer data to it. As a result, you should see on the screen the reaction of the device to the ping command, unless this transmission is blocked by a firewall.
In the example shown in fig. 7.28, four successful responses are shown, with their duration, transmission and acknowledgment times, and packet lifetimes. At the end of the job, it also provides a summary of the number of sent, received and lost packets. If a data transfer failure occurs, you should see a message stating the reason for the transfer.
Essentially, the ping command sends packets one by one to the device under test and receives a response from it to find out if there is a connection with this device (Fig. 7.29).
Ugilita ping is a great example of a simple ICMP data exchange. Packets from the icmp _ echo capture file. pcapng show what happens when you perform a carbon ping. The first packet (Fig. 7.30) from this file shows that the host at the address 192 .168 .100 .138 rushes the packet of the host located at the address 192 .168 .100 .1 O. If you expand the part of this packet that refers to ICMP protocol, the ICMP packet type can be determined by looking at the Tore and Code fields. In this case, the packet is of type 8 8, and its code is zero 8, indicating an echo request.
(The Wireshark application should tell you exactly what is displayed in the Toure and Code fields.) But sending an echo request is only half the battle. After all, it is a simple ICMP packet that is sent using the IP protocol and contains a small amount of data. In addition to the type, code and checksum, there is a sequence number for pairing requests and responses, as well as an arbitrary test string in the variable part of the ICMP packet.
To increase the size of the field that is filled with data in the echo request and thereby force the fragmentation of packets, you can use the appropriate parameter (-s in Upix systems and -1 in Wipdows systems) of the pinq command. Such a need may arise when conducting various types of network diagnostics, where smaller fragment sizes are required.
ICNP interception phages The traceroute utility is used to identify the trace path. RSARPD packets from one device to another.
In a simple network, this path can pass through one router or without it at all. And in a complex network, packets may have to pass through dozens of routers to reach their final destination. Therefore, it is very important to be able to trace the specific path along which packets pass from one destination to another for communication diagnostics.
Using the Internet Control Message Protocol (ICMP) (and to a lesser extent the Internet Protocol (IP), the trace can show the fear of packets. For example, the first packet from the icmp traceroute .rsardpd capture file is very similar to the echo request from the previous example (Figure 7.32) .
In the captured traffic from this example, the packets were generated using the traceroute 4.2.2.1 command. To use traceroute on Windows, type tracert at the command prompt, replacing ip-anec with a specific IP address. the device to which you want to identify and trace packets to. And in order to use the traceroute utility in Linux or Mac 0S X, enter the traceroute ip-address command.
At first glance, this packet contains a simple echo request from a host located at 192 .168 .100 .138 to a host located at 4 . 2 .2.1, and therefore the entire contents of the ICMP part of this packet look the same as when the echo request packet is formatted. But if you expand the IP header of this packet, you can see that the field of this header is set to 1. This means that this packet will be dropped on the first router it reaches. And since the IP address of the recipient of the package is 4. 2. 2. 1 is inter-network, then, as you know, there must be at least one router between the source and destination devices. Therefore, this parcel cannot reach its destination in any way. And that’s a good thing, because the power of tracing relies on the packet to only reach the first route on its way.
The second packet, as expected, contains the response from the first reached marshugger on the way to the recipient (Fig. 7.33). The first packet reached the device at 192 .168 .100 . 1, where the value in the TTE field of its [P-header) is reduced to zero, so it cannot be passed on. Therefore, the router sent an ICMP response packet. This packet is of type 11 and is assigned a code of 0, which means that the receiver is unreachable because the packet’s lifetime was exceeded while passing through the router.
Such an ICMP packet is sometimes called a two-header packet, because at the very end of the ICMP protocol, the ICMP part contains a copy of the IP header and ICMP data that were sent in the original echo request. This information can be useful when diagnosing networks.
The above process of sending packets with the minimum value in the TTL field of their IP header goes through several more times before packet 7 is received. Again, the same thing is observed as in the first packet, but this time the PI field of the corresponding IP header is set to 2, ensuring that the packet reaches the marshugger on the second hop before it is canceled. As expected, the response will be received from the router on the next hop to 192 .168. 1. 1 with the same ICMP messages about recipient unreachability and packet expiration.
This process, incrementing the value in the TTL field, continues until the receiver at 4.2.2 is reached. 1. But before this happens, the request is exhausted, as can be seen from line 8 of the results displayed by the traceroute utility on the screen (Fig. 7.34). How, then, can this process be successful if the request is exhausted on its way? This usually happens if the router does not respond to 1CMP requests. Such a router still receives the request and forwards the data to the next router. That is why we can find the next transition in line 9, as shown in fig. 7.34.
On this transition, the ICMP packet with the message about the lifetime was simply not generated, as it was on other transitions. If the traceroute utility does not receive a response after the specified amount of time, it increments the value in the TT AND field by I and simply moves on to the next request.
The updated version of the IP protocol relies heavily on the ICMP protocol to perform functions such as neighbor polling or packet routing, as demonstrated in the previous examples. The ICMPvb protocol is described in RFC 4443 and is intended to support a number of capabilities required for the proper functioning of the IPvb protocol, along with additional enhancements. ICMPvb is not considered separately in this book because it uses the same packet header structure as ICMP packets.
As a rule, ICMPvb packets are divided into categories of error messages or informational messages. A complete list of types and codes available in the ICMPvb protocol can be found on the IANA web page at http://www. iana .org/assignments/icmpvb-parameters/ icmpvb-parameters. xhtml. This chapter introduced the most important network-layer protocols that you should investigate during packet analysis.
In particular, the ARP, IP, and ICMP protocols are at the heart of all network communication, and therefore play a critical role in solving the tasks you will encounter in your day-to-day activities. Chapter 8 will consider the most used protocols of the transport layer – TSR and UDP.
We used materials from the book “PRACTICAL RACKET ANALYSIS” written by Chris Sanders.
1014 
844 
746 
698 
763 
783 
758