Re: [OpenCALEA] Cisco SII tap agents

[Jesse Norell]

Hello,

  I've no experience with Cisco's solution myself (it looked
interesting, but I didn't have time to look into the details).  What
you're designing is pretty similar to where OpenCALEA is heading ...
were you wanting to combine your work with OpenCALEA, or just looking
for others in the Cisco arena?

  More comments inline.


On Mon, 2007-08-13 at 20:42 -0400, Robert Blayzor wrote:
> 
> Hi list..
> 
> I've been following the OpenCALEA list for a couple of months now.  It
> seems things have stalled a bit due to everyone being busy; aren't we all!
> 
> Anyhow being a broadband service provider of course we're under the gun
> to be CALEA compliant.  The problem we've been finding is that current
> mediation device implementations don't seem to be everything they claim
> to be.
> 
> It seems to be the norm that if you just use Ethernet probes and
> Ethernet taps that's all you  need.  However, if you're a service
> provider that utilizes broadband aggregation routers, terminating lots
> of PPPoX connections, the only real option to be 100% CALEA compliant is
> either use something like Cisco SII or a very expensive passive optical
> tap (or DS3, etc).

  Or force your traffic to cross ethernet at some point and use an
ethernet probe to pick traffic out... but yeah, there certainly are
scenarios that don't fit without forcing otherwise unnecessary changes
like that.  In fact, we'll have a similar scenario ourselves very soon
at my company, as we bring some backup bandwidth in via atm that also
serves dsl customers.


> After having several proposals from the big Mediation Device vendors,
> we've shot holes in every one of them.  At least for us, they don't work
> perfectly.  So we're starting a new path that implements a multi-stage
> approach of using a very simple, open provisioning interface, a
> pluggable tap agent, a collector and a delivery method.

  That's pretty similar to OpenCALEA, too (or at least what we're
heading at).  It may make sense to beef up the OpenCALEA messages to
handle the additional info you need to control your taps and use the
core framework to handle provisioning/collection.

> It seems that most of the approach is on collect and delivery, which
> seems to be pretty much nailed down.
> 
> We have a couple of programmers (myself included) working on the tap
> model for Cisco SII for starters. (only because we have so much of it
> deployed).  Cisco SII uses standard PCLI format for sending data to a
> collector via UDP packets.
> 
> The initial goal is to have a trigger that will set the tap agent, ie:
> manually or from a RADIUS server.

  We've not started on RADIUS yet, but we plan to have exactly that.
You define an intercept that looks for something, eg. could be a staic
ip addr or could be a radius login ... if such a login happens, a CmII
agent generates the CmII info to ultimately send to the LEA, and fires
off a tap for the current ip addr.

>   The tap agent will then use SNMPv3 to
> set the Cisco SII tap MIB to start an intercept.  There is more that has
> to happen, it gets complex when tracking and maintaining the taps
> currently in progress.

  That form of a tap should be pretty easy to mix in with OpenCALEA.  As
for tracking intercepts in progress and handling provisioning, we were
last working on saving each intercept in a separate .ini type file
(actually using gmime's ini parsing to read/create/update the files).  I
expect you could pretty easily store a few extra fields to track
specifically what router is performing a tap and the session id or
whatever they use to track things.

> The reason for this post is to see if anyone has actually been going
> down the Cisco SII path as far as already having something developed
> before we actually start recreating the wheel.  If anyone else is
> interested at some point when we have more, I can share here or you can
> contact me off list.

  Not Cisco SSI specifically, as I mentioned, but you're working on a
remarkably similar wheel.  :)  If you're interested in throwing your
efforts in with OpenCALEA, we may both benefit ... just hollar (also
drop by irc://irc.freenode.net/calea if you want).

Jesse


-- 
Jesse Norell
Kentec Communications, Inc.
jesse@kci.net