IP Header Fields

Let's begin our examination of the fields in the IP header. Each field will be discussed in terms of its function, any pertinent information about normal and abnormal values, reconnaissance that may be obtained from examining the field, and evasion or insertion attacks possible using

the field.

IP Version Number

The only valid IP version numbers currently in use are 4 and 6, for IPv4 and IPv6, respectively. IPv4 is the most common and pervasive version number thus far. IPv6 is not yet in wide use in user networks in North America, although it is slowly being deployed in the Internet backbone. It is also being used in Europe and Asia.

The IP version field must be validated by a receiving host and if not valid, the datagram is discarded and no error message is sent to the sending host. RFC 1121 states that the datagram must be silently discarded if an invalid value is discovered. So, crafting a datagram with an invalid IP version would serve no purpose other than to test if the receiving host complies with the RFC.

Also, if a packet arrives at a router with an invalid IP version, it should be discarded silently. Using this as a means of an insertion attack is rather difficult unless the attacker is on the same network as the NIDS. If this is the case and a series of packets is sent to the end host with an invalid IP version and a NIDS does not discard them, this is an insertion attack—something the NIDS accepts that the destination host or intermediate router after the NIDS should surely

reject.

Protocol Number

You have already learned that the IP protocol number indicates the type of service that follows the IP header. A list of all the supported protocol numbers and names can be found at www.iana.org/assignments/protocol-numbers. Conveniently, later versions of nmap have the capability to scan a host for listening protocols. This is done using the –sO option. The target host is scanned for all 256 possibilities of protocols. Protocols are deemed listening when no ICMP "protocol unreachable" message is returned. The following text shows an nmap scan for live

protocols and the returned nmap assessment: nmap –sO target

Starting nmap V. 2.54BETA1 by fyodor@insecure.org ( www.insecure.org/nmap/ ) Interesting protocols on myhost.net (192.168.5.5):

(The 250 protocols scanned but not shown below are in state: closed)

Here is a sample of the traffic that the protocol scan generated:

07:30:31.405513 scanner.net > target.com: ip-proto-124 0 (DF) 07:30:31.405581 scanner.net > target.com: ip-proto-100 0 (DF) 07:30:31.405647 scanner.net > target.com: ip-proto-166 0 (DF)

07:30:31.405899 target.com > scanner.net: icmp: target.com protocol 124 unreachable (DF)

07:30:31.788701 scanner.net > target.com: ip-proto-132 0 (DF) 07:30:32.119538 target.com > scanner.net: icmp: target.com protocol 166

unreachable (DF)

07:30:34.098715 scanner.net > target.com: ip-proto-236 0 (DF) 07:30:34.098782 scanner.net > target.com: ip-proto-129 0 (DF) 07:30:34.098849 scanner.net > target.com: ip-proto-229 0 (DF)

07:30:32.779583 target.com > scanner.net: icmp: target.com protocol 236 unreachable (DF)

07:30:34.099557 target.com > scanner.net: icmp: target.com protocol 109 unreachable (DF)

The nmap scan examines all 256 different protocol types. A host that receives this type of scan should respond with an ICMP "protocol unreachable" message to any protocols that it doesn't support.

Although the supported protocols of a host are interesting, another possible piece of reconnaissance from this type of scan is that the host is alive. This is a more stealthy type of scan that might not cause an intrusion-detection system to alarm. However, if the site has a "no ip unreachables" statement on the outbound interfaces of the gateway router or if it blocks all outbound ICMP, this information is not leaked to the scanner. In that instance, the scan is useless.

There is a flaw in the logic used by nmap to discern listening protocols. Nmap assumes that the absence of an ICMP "protocol unreachable" message means that the protocol is listening. Yet, conditions such as the scanned site blocking outbound ICMP messages prevent the nmap scanner from getting these messages. There are other conditions, such as dropped packets, that might also cause the loss of packets and falsely influence nmap. However, the author of nmap tried to consider such situations. Nmap sends duplicate packets for each protocol to deal with the problem of packet loss. Also, if nmap gets no ICMP protocol unreachable messages back, it doesn't assume all protocols are listening. Instead, it wisely assumes that the traffic is being "filtered" and reports this.

A Bloody Simple Analogy

Nmap uses the philosophy of the absence of communication is the confirmation of a condition to determine listening protocols. In other words, the absence of an "ICMP protocol unreachable" message is the confirmation that the protocol is listening. As we've seen, there are some flaws associated with this method.

This philosophy reminds me of the real-world situation of going to the doctor's office for some blood work. Because the doctor and staff are very busy people, they usually tell you on your way out that they will not call you unless they discover something wrong. They are basically telling you that the absence of communication, the lack of a phone call, is a confirmation of a condition, that you are healthy as a horse.

Yet, if you are even a bit cynical, you understand the possible problems with this situation. All kinds of things can go wrong such as losing your blood in the doctor's office before it gets sent to a lab, losing your blood on the way to or from the lab, or even losing your blood at the lab. Just because you don't hear from the good doctor doesn't necessarily mean that everything is copasetic.

Similar problems can beset a packet. A packet can get lost in transit or it can be dropped or blocked at many points in its journey. Nmap attempts to deal with some of these problems, yet the absence of communication might not always be a confirmation of a condition.

Differentiated Services Byte (Formerly Known as Type of Service—The Prince of Fields)

It seems that the former Type of Service byte has undergone several rounds of alterations since its incipient creation. One of these alterations in RFC 2481 and more currently RFC 3168 calls for the two low-order bits of the differentiated services byte to be used for Explicit Congestion Notification (ECN). The purpose here is that some routers are equipped to do Random Early Detection (RED) or active queue management of the possibility of packet loss.

When congestion is severe, it is possible that a router can drop packets. RED attempts to mitigate this condition by calculating the possibility of congestion in the queue to a router