CCIE or Null!

Flexible packet matching, definitely an extremely powerful tool and a complicated one at that, not only because of it’s configuration but also because you need to be familiar with the different protocol structures as well as regular expressions if you want perform some fancy matching criteria.

In a nutshell, Flexible packet matching allows routers to look deep into a particular type of packets, & into the various fields contained within the packet to perform specific actions based on the contents of those fields.

Before you can configure flexible packet matching, you will first need load a PHDF, Protocol Header Definition File. The PHDF is an XML file that outlines the format of the protocol header, the name of the fields, the length of the fields, and where the fields start within the packet. Below is sample of the XML text with the icmp.phdf:

To dwell on the PHDF for a bit longer:

• The field name matches a particular field within the header for the most case.
• The offset, denotes where the field starts in the packet header. The offset is always from the start of the header.
• The length, defines how long the field is.
• Notice the length and the offset can either be in bits or bytes
• The total length of the header at the bottom of the PHDF is also a requirement.
• This is all good to know since you can create your own PHDF files.

Here is a quick outline of an ICMP packet so you can correlate the PHDF to the to the actual packet.

To load the PHDF file itself, you’ll want to issue the following command:

After the PHDF is loaded you can issue the following command to see the specifics of the PHDF file itself. Similar to what is listed in the PHDF file itself.

Next, we are going create an ‘access-control’ class-map to match our traffic. I will keep the example to ICMP for simplicity:

Notice, we have multiple match statements, making sure we only look ICMP Echo packets, that have have a number with the first 256 byes of its payload. Now remember you can get pretty creative with regular expression, (If you’ve done any real work with BGP routing policies you know what I mean) for the sake of this post I wanted to keep it simple.

Now we need to create a ‘stack’ class-map, this particular type of class-map allows the router to narrow down its matching criteria by matching particular protocol headers in a particular order. If you do not specify a ‘stack’ class-map the the ‘IP’ header will be assumed. The example below matches ICMP over IP. Check out the INE link at the end of this post to see an advanced ‘stack’ involving ICMP within an IP-IP tunnel.

Since we have the ‘stack’ and ‘access-control’ class-maps defined it is now time we tie this together within a policy-map. Before we do that, we need to create an ‘access-control’ policy-map to match our ‘access-control’ class-map, and define our action when matching traffic is seen. There are only a few different options with ‘access-control’ policy-maps. (All of the pretty much listed below)

To tie together, the ‘stack’ & the ‘access-control’ class-map we will need to create another ‘access-control’ policy-map referencing the ‘stack’ class-map as a class, and then referencing the class-map containing our action as a service-policy.

With all the pieces tied together now, we can apply this to an interface:

So now, any ICMP Echo packets with a digit from 0-9 in the payload will get dropped, we can verify this by issuing the following show command:

Not an easy process, and quite a tedious one in fact. So what could you possibly use this feature for?  Well this feature could be used as a psuedo-IPS to block a specific set of malicious traffic, or even to block ICMP Covert channels without the use of an IPS.

Here are some other resources for Flexible Packet Matching:

Cisco FPM Deployment Guide

Cisco FPM Configuration Guide

INE FPM Article – Great resource for showing off the power of FPM, by matching ICMP packets within an IP-IP tunnel

I highly recommend the Wireshark WCNA book for learning about the different protocols headers (and much more)