[cisco-voip] securing IAD control-plane & RTP not hitting policy

[Peter Slow]

"bypass from the WAN interface to the DSP that would make it not hit
on a CoPP ACL?"

...Yes. typically, there is an interface that represents the DSPs or
DSP card. on a WS-CMM-ACT module the RTP traffic never even entered
the voice gateway's switching path =) . In an ISR platform, there's
going to be an IDB of some form for the router to switch the packet
to. if you look hard enough in an ISR you may come across an interface
named voip-null0. I think this is a cosmetic name for that IDB. This
is an interesting question =) maybe someone else will pipe up and
elaborate =)

voice packets are not process switched to the DSPs. (unless you've
done somethign very wrong) Typically, I _believe_ CEF handles getting
the RTP packet to the DSPs in something like an ISR or anything else
with single data/control plane.

slownet-brdr1#sh cef interface internal | begin ull
VoIP-Null0 is up (if_number 4)
  Corresponding hwidb fast_if_number 4
  Corresponding hwidb firstsw->if_number 4
  Internet Protocol processing disabled
  Suppressed input features: MCI Check
  Output features: Post-Ingress-NetFlow
  Hardware idb is VoIP-Null0
  Fast switching type 13, interface type 222
  IP CEF switching enabled
  IP CEF switching turbo vector
  IP prefix lookup IPv4 mtrie 8-8-8-8 optimized
  Flags 0x6080, hardware flags 0x1
  Input fast flags 0x0, Output fast flags 0x0
  ifindex 4(4)
  Slot  Slot unit -1 VC -1
  IP MTU 0
 Status flags:
  hwidb    status 100800 status2 8000050 status3 0 status4 0
  fibhwidb status 100800 status2 8000050 status3 0 status4 0
 Subblocks:
  No subblocks present

-Pete





On Thu, Jul 31, 2014 at 1:20 PM, randal k <rkohutek at gmail.com> wrote:
> Good morning -
>
> 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!
> Randal
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>