Tuning Flood Engine sigs

Question

Looking to shed some light into the behavior of the Flood Engine.
According to Cisco documentation:
The Flood engine defines signatures that watch for any host or network sending multiple packets to a single host or network. For example, you can create a signature that fires when 150 or more packets per second (of the specific type) are found going to the victim host.
http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a00804cf506.html#wp1040058
As an example, lets examine the default parameters of sig 4002 UDP Host Flood.
Engine: Flood Host
Rate: 100
Protocol: UDP
Event Count: 1
Event Count Key: Attacker Address
Specify Alert Interval: No
Is it correct to say that an alert is generated if the sensor sees that source A has exceeded 100 UDP packets per second? 100+ pps could have been to 1 host, or a bunch of hosts, as long as the total packet count from source A is greater then 100. The alert however, will show the victim address and port of the triggering packet (the 101st packet in that second). Am I correct so far?
My first problem, is the NSDB signature description says "This triggers when a large number of UDP packets are directed at a host." To me, for this to happen, the Event Count Key should be set to Victim Address.
My other problem, is that no matter what tuning I try on various Flood Engine signatures, alerts are generated that are not in line with what the parameters specify.
For example, lets retune sig 4002 so that it alerts on distinct host pairs (1 to 1 relationship). So we change Event Count Key to Attacker and Victim Addresses. Now if source A sends out 101 pps to multiple hosts, I should expect to see no alerts. The only time I expect to see alerts, is if source A sent 101 pps to dest B, and another alert if source A sent 101 pps to dest C, etc. But, after extensive testing, it doesn't work that way.
Anyone care to enlighten?

Answer 1

There's a little catch to the flood-host engine, and that's that there is an underlying storage key of xxBx in the engine itself, so the engine is doing some summarization.. which is going to lead to odd results if you try to use the summary key in the signature itself. Back in 4.x, this was a by design thing in the flood engines and from my digging yesterday, I believe that its carried thru into 5.x as well even though the multiple flood engines were consolidated.
Summary on the attacker Axxx works just fine, but not on the victim xxBx.
I'll update this thread once I get together with the engine developer and hash this out, but I'm pretty sure that this is by design.
Take a look at signature 4003, this was firing for me while I was fooling with 4002. Or even making a custom sig using the atomic-ip engine to identify a host to host flood using a count over an interval.
I'll update this when we hash out the details about summarization.