[c-nsp] IP Options Drop

[Phil Mayers]

On 21/04/2014 17:26, Saku Ytti wrote:
> On (2014-04-21 17:09 +0100), Phil Mayers wrote:
>
>> Can you expand on this? Currently you can either do "platform rate-limit"
>> for IP options or disable the RL and use the built-in / magic CPP class-map:
>
> As ACL match work, you could do it in iACL and then you're only left with own
> customers attacking you.
> Mind you, I don't run PFC4. But amongst things I'm missing in PFC3 ACL
> classification are packet size and IP options, both should be available in
> PFC4.

Seems so; I had assumed options ACL match was still absent because it 
had a platform RL/CPP match, but a test on our box says:

#sh ip access-list TEST
Extended IP access list TEST
     10 deny ip any any option any-options
     20 deny ip any any pak-len lt 128 (117 matches)
     30 permit ip any any

#sh platform hardware acl entry interface vlNNN security in ip
...
tcam:B, bank:0, prot:0    Aces

L3_Deny               ip any 224.0.0.0 15.255.255.255 L3_len lt 128
L3_Deny               ip any 224.0.0.0 15.255.255.255 v6_flags(0,0)
Permit                ip any 224.0.0.0 15.255.255.255
L3_Deny               ip any any L3_len lt 128   (53 matches)
L3_Deny               ip any any v6_flags(0,0)
Permit                ip any any

...and the "len" match certainly works, just tested. Assume the v6_flags 
thing is just an internal / field re-use detail, though I didn't have 
any easy way to test IP options.

That said, the ACL merge logic seems a bit sub-optimal currently on this 
release - the thing with duplicate copies of ACEs for 224.0.0.0/4 and 
longer routes versus everything else, even with the same outcome, seems 
to be pretty consistent. Wonder if they'll optimise that?

I will refrain from ranting on the pain of *managing* ACLs on IOS-based 
platforms however ;o)