The IP Packet Header

The IP packet header is what tells an IP-based host what to do with the packet that was received. Think of it as an instruction manual that contains the "how to process this packet" information. Therefore, an attacker wanting to generate malicious traffic will frequently modify the IP packet header in such a way as to instruct the receiving host to do something harmful with the packet, or to instruct the host to do something it is not capable of doing in hopes that it causes the host to generate an error condition that may allow the attacker to gain access to the system. Because of this, it is not good enough to understand that there is an IP header. As a firewall administrator, we need to understand what the contents of the IP header are and what the values represent so that we can identify and block potentially malicious traffic.

The IP packet header consists of 32-bit blocks of data known as words. These words are further broken down into numerous fields of various length and function. As mentioned previously, the typical IP packet header length is 20 bytes, which means that a typical IP packet header consists of 5 words. If any IP options have been configured, the packet header will contain the options values, and then the necessary padding to ensure that the header ends on a 32-bit boundary.

Figure 3-6 depicts the structure of an IP packet header.

Figure 3-6. IP Packet Header Structure

VERS

DIFFSEHV

iiDN

!DEN IIFICAI ION

TIME TO LIVE

PROTOCOL

TOTAL LENGTH

FLAGS

HEADER CHECKSUM

□ESTIMATION ADDRESS

IP OPTIONS (OPTIONAL)

! RAO ML NT OFFSET

PADDiNG (OPTIOWAL)

The fields of the IP packet header and their meanings are as follows:

• Version (VERS, 4 bits) This represents the format of the packet header. In most cases, the value is 4, which represents IP version 4; or 6, which represents IPv6. If the value is 0, the packet should be destroyed; and in most cases, any value other than 4 or 6 is going to be considered invalid.

• Internet Header Length (IHL, 4 bits) This field represents the length of the header in 32-bit words, typically with a value of 5. If IP options are included in the header, the value will be between 6 and 15. Any values less than 5 are invalid.

• Differentiated Services field (DS field, 6 bits) This field was originally known as the Type of Service field, but RFC 2474 replaced this functionality with what is known as the DS field. The DS field is used to provide scalable service discrimination and guarantee quality of service (QoS) for the datagram transmission. The DS code point (DSCP) is the value that is encoded in the DS field to define the QoS and per-hop behavior (PHB) for a given datagram.

In general, the DS field should have a DSCP value of all 0s unless QoS or a

PHB class has been implemented for the data and in fact the default DSCP value and PHB class for Internet communications is 000000.

Note

For more information about PHB codes and usage, refer to RFC 2597, RFC 3260, RFC 3246, RFC 3140, RFC 3247, and RFC 3248.

• Explicit Congestion Notification (ECN, 2 bits) This field is used to provide a congestion indication for incipient congestion through the use of ECN code points. If both bits are set to a value of 1, it indicates that congestion has been experienced.

• Total Length (16 bits) This field is the full length of the datagram, including the IP packet header and the data itself. Because the Total Length field consists of 16 bits, it is impossible to have a packet size greater than 65535 bits, because the maximum value that can be provided by a 16-bit field is 2^16, or 65536.

• Identification (16 bits) This field contains a value assigned by the sender and is used by the receiver to aid in assembling the fragments of a datagram.

• Flags (3 bits) This field is used to specify whether the datagram can be fragmented. Bit 0 is reserved and must be 0. If bit 1 is a 0, the datagram may be fragmented. If the value is 1, the datagram may not be fragmented. If bit 2 is a 0, this packet represents the last fragment of the datagram. If bit 2 is a 1, there are more fragments of the datagram.

• Fragment Offset (13 bits) This field indicates where in the datagram the packet belongs. The fragment offset is measured in units of 8 octets, and the first fragment has an offset of 0. The Fragment Offset field should only contain data if the packet is a fragment.

• Time to Live (8 bits) The Time to Live field specifies how long the packet may remain on a network before the datagram must be destroyed. This provides a means for removing packets from the network that were unable to be delivered in the time specified. A time-to-live value of 0 indicates that the datagram must be destroyed.

• Protocol (8 bits) The Protocol field indicates what protocol was used at the next layer to generate the data portion of the packet. For example, TCP has a protocol value of 6 (0x06 in hex) and UDP has a value of 17 (0x11 in hex). For a full list of protocols, refer to http://www.iana.org/assignments/protocol-numbers.

• Header Checksum (16 bits) This field is a checksum on the header only to ensure that the header is complete and verified accurate at each point that processes the header (for example, at each router or by the destination host itself).

• Source Address (32 bits) This is the source IP address of the transmitting system.

• Destination Address (32 bits) This is the destination IP address of the receiving system.

• Options (variable) The Options field contains optional pieces of information that can be used by hosts to assist in the processing of the packet. Because this field is not required, not all vendors successfully or properly know how to handle and process values in the Options field (even though they are supposed to), which makes manipulation of the Options field to contain "invalid" data a common attack method. In general, the Options field is not commonly used.

• Padding (variable) This field is nothing more than bits with a value of 0 to pad the bits of the Options field to ensure that the header ends with a 32-bit boundary.

Figure 3-7 shows a screen shot of a packet sniffer to show the IP packet header contents in a decoded fashion.

Figure 3-7. Sample IP Packet Header Contents

[View full size image]

Figure 3-7. Sample IP Packet Header Contents

[View full size image]

+1 0

Post a comment