[c-nsp] Securing IAD control plane / RTP not hitting CoPP?

[randal k]

I posted this message over on Cisco-VoIP and had very little traction, so I
thought I'd try here.

I have a bunch of Cisco IAD24xx models out in the field all running SIP
talking to our softswitch, and I thought I'd get the collectives input on
the best method to secure them.

Up until a few weeks ago we have custom-written ACLs on the WAN interface
of these routers to allow/deny SIP and other stuff. Well, a broken ACL
allowed access to the wide-open by default H323 service and cost us some
$TOLL_FRAUD -- nothing too bad, but enough for us review how we're doing
things.

So, we have deployed a demo control-plane based policer/dropper to make
sure that the WAN interface ACL doesn't have to be perfect (or even be
there, which is the goal). An example:

policy-map cpp-policy
 class cppclass-reporting
 class cppclass-monitoring
 class cppclass-management
 class cppclass-services
 class cppclass-voip
 class cppclass-undesirable
   police rate 10 pps
     conform-action drop
     exceed-action drop
 class cppclass-everything
 class class-default
   police rate 1000 pps
     conform-action transmit
     exceed-action drop
!
 Class Map match-all cppclass-voip (id 3)
   Match access-group name cpp-voip
!
Extended IP access list cpp-voip
    10 permit udp host SIPPROXY any eq 5060
    11 permit udp host SIPPROXY eq 5060 any (2159250 matches)
    20 permit udp host SIPPROXY2 any eq 5060
    21 permit udp host SIPPROXY2 eq 5060 any
    30 permit udp host AUDIO1 range 10000 20000 any (657129 matches)
    40 permit udp host AUDIO2 range 10000 20000 any
    50 permit udp host T381 range 4000 5999 any
    60 permit udp host T382 range 4000 5999 any
    510 permit udp host LEGACY1 any eq 5060
    520 permit udp host LEGACY2 any eq 5060
    530 permit ip CATCHALL 0.0.0.31 any
    540 permit ip CATCHALL 0.0.0.31 any


My question is that my cppclass-voip, and its associated Audio-related ACL
(#30) is NOT matching all the RTP packets. There should be orders of
magnitude more packets hitting that line than there are.

Anybody have any insight into how RTP is processed on these or on CUBEs in
general? Does it create some sort of CPU-bypass from the WAN interface to
the DSP that would make it not hit on a CoPP ACL?

Thanks!