If the primary purpose of the device is security, use a firewall. If the primary purpose is routing, use a router. Not to be a smartass, that's just the best way to make that decision.
Maybe the reason they don't post a side-by-side comparision is because each router is different and some PIXen also have different features. It's sort of apples and oranges. Since this is a broad subject, you will problably be best served making up your own product matrix and then checking off the features you want.
IOS Firewall will suck up CPU cycles on a router. PIX is much faster and easier to work and play with. It's also usually cheaper than using a router as a firewall.
If you post an idea of how your network is set up and what you want to achieve with the device, I'll bet people will post some more specific info.
Strictly speaking IOS firewall is not a firewall at all. All you need to do to evade application-layer inspection is just fragment your traffic. This will probably never be changed as 1) routers should pass all traffic, even fragmented, 2) Routers' CPUs are usually very slow -- they cannot do virtual reassembly. So, in a long term PIX is a better solution, but it has lots of its own problems.
8% - reverse order; 0.1% with duplicates or overlapping. Of this 1%: 52% - MS Media Player, 22% -tunneling (source - CAIDA, or like that).
2. PMTUD sometimes doesn't work as ICMP is blocked somewhere.
3. PMTUD is not implemented for UDP by M$ (so far as I know).
So, fragmentation is common and normal thing.
Routers SHOULD pass fragments, firewalls MAY not and usually you cannot block *all* fragments with "a-l 100 deny ip any any fragments". You *probably* can block fragments for *specific* protocols that are application-layer-inspected by the IOS firewall (say, SMTP, for SMTP Mail Guard to work), but this is not an easy thing. For example:
permit tcp any host myserver eq 25
deny ip any host myserver fragments
will probably work, but I'm not sure. At least it should be carefully tested.
Most PIX firewall fixups block all fragments of the respective application protocol by default (there are exceptions though - ftp without "strict" keyword, SIP until recently, etc. - they are open for various vulnerabilities).
So, in general, PIX (arguably) do the right thing with fragments. And it is much easyer to configure. I would say that the IOS firewall is "fail-open" and the PIX is "fail-closed" by default regarding the fragments and application-layer inspection, where "fail-open" means "pass the packet if unable to analyze it" and "fail-closed" means "drop it".
This basically means that the IOS firewall is not a firewall at all.
Very insightful comments but I do have to disagree with one point.
1. I would not say that because up to 1% of internet traffic is fragmented that IP fragmentation is common. Especially when you say that 22% of all fragmentation is caused by tunneling. Fragmentation in tunneling can easily be overcome by adjusting the workstation maximum MTU sizes. So that just leaves a maximum of 0.78% of internet traffic.
If you are saying that by blocking ICMP path MTU discovery packets, you must allow IP fragments then that is interesting. I really never thought of it that way.
I subscribe to the theory that it is better to block fragments and protect yourself against rather simplisitc IP fragmentation DoS attacks than it is to allow them.
I 100% agree about the IOS being fail-open and the PIX being fail-closed and from a security point of view the hardware firewall is always the best option.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :