Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

ovt Bronze

Best practices for using Normalizer in ASA and in AIP-SSM

Both PIX OS 7.x and IPS 5.x software have a concept of "traffic normalization". PIX OS on ASA can do virtual reassembly, IPS on SSM (so far as I know) can do physical reassembly and fragmentation of IP packets. Also, both ASA and SSM can do TCP normalization. For example, they both can "check inconsistent retransmissions" and protect against "TTL evasion attacks". I realize that PIX OS has only basic normalization functions and the SSM is much more configurable.

The question is: what are the best practices here? Is it better to disable some IP/TCP PIX OS checks / IPS signatures on ASA and/or SSM? Is it better to use just SSM for traffic normalization? Does anybody has personal experience here?

Also, there is a BugID CSCsd04327 - "ASA all out of order packets are dropped when sending to ssm"

"When ips ssm is inline slowness is reported. show service-policy shows that the number of out of order packets reported match exactly the number of no buffer drops (even with queue-limit option). Performance hit is not the result of tcp normalization (on IPS 5.x ssm) in this case, but rather an issue with asa normalizer."

To me it seems to be more logical to have normalization function on the firewall, but there may be drawbacks in doing this.

So, those who're using ASA with SSM, please share your experience.



Re: Best practices for using Normalizer in ASA and in AIP-SSM

ovt Bronze

Re: Best practices for using Normalizer in ASA and in AIP-SSM

I read this. Unfortunately, cisco docs often lie... Just lie.

For example the says: "Reassembling all fragmented datagrams inline and only forwarding completed datagrams, refragmenting the datagram if necessary, prevents this. The IP Fragmentation Normalization unit performs this function."

This doesn't hold true. The IPS doesn't perform reassembly/refragmentation. It does virtual reassembly, like the PIX do.

What the above doc. says about the TCP normalization:

"Instead of the sensor acting as a TCP proxy, the segments will be ordered properly and the normalizer will look for any abnormal packets associated with evasion and attacks."

Yes, this is correct. But, how does it perform reordering? What does it do if some TCP segments are dropped by the router in the path? I've found out that IPS acts almost like a proxy in this case. For example, it can ACK TCP segments on behalf of the target host to force retransmissions... After receiving previously lost TCP segments it reorders them and passes to the target host. And IPS timers are very very aggressive in this case. I saw how it drops TCP session when some TCP segment is lost and is not retransmitted within 5 seconds!!! The timeout is not configurable! How will this work in real networks? Now I'm wondering if the PIS OS 7 behaves the same way... It seems that they share the same code for normalization.