IP packet Options, Filtering, Identifying.

Unanswered Question

I am trying to filter all IP options as shown in the Cisco Guide to Harden Cisco IOS Devices.



When I implemented the ACE:

deny ip any any option any-options

I s-l-o-w-e-d all traffic through my uplink. I used it on the inbound and outbound uplink lists.

I haven't found a way to identify whether or not my packets have options. I have a NAM. The packets have values in the 21st. byte of the packets, typically 05, 17, 19, or 0d. The 21st. byte is the first byte of the tcp header. Is this byte showing me info about the options?

Another method of blocking options uses the global config command:

Router (config)# ip options drop

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
michael.leblanc Fri, 07/11/2008 - 08:57

The document you provided the URL for, states:

"IP options present a security challenge for network devices because these options must be processed as exception packets. This requires a level of CPU effort that is not required for typical packets that traverse the network."

... which may account for the slowdown.

Your ACE specifies "IP" which is the first clue that it is an IP header field, and not a TCP header field that is relevant.

The first byte of the IP header is comprised of two four-bit fields (Version, Header Length).

The IP Version field is typically 0x4, and the Header Length field is typically 0x5.

The Header Length field specifies the header length measured in 32-bit words (4 bytes, if you prefer). Therefore a typical IP header is 20 bytes (5 x 4 bytes).

If this field is greater than 0x5, IP Options are being used.

If the global config command you've referred to doesn't suite your needs, take a look at Flexible Packet Matching.




I've done some reading on Flexible Packet Matching, but have not implemented it, and would not be in a position to advise you on the subject.

Flexible Packet Filtering is yet another method of ACL. This time patterns in the packet can be matched on the very granular bit level. It is rocket science to do this, but XML and perhaps something like MARS, Cisco Self Defending Networks, (not now but probably in the future) will use it to do very fast ACL protection on edge devices. If you were good with XML and could identify the attack patterns, you might be able to implement a day 0 defence with this tool. Some kind of GUI would help with field identification and field patterns.

If the header length field is greater than 5 (X 4 octets per word = 20 octets) then options are being used. I will test this.

I am still reading the link on reflexive ACL entries. This technique allows you to do an "extabished" like filtering, used with TCP. It polices the establishment of all protocol flows, including, UDP, TCP, ICMP, etc., not just the TCP used in the "established" ACE.

I am still studying this and the IP options page listed above and will get back later..


This Discussion