Re: [OpenCALEA] Developer - New to the list

[Jesse Norell]

> I have been developing a T1.IAS only implementation, I have the ATIS
> Specs ATIS-PP-1000013.2007, ATIS-PP-1000678.2006, and ANSI-J-STD-025-B.
>   I was developing it for our own internal compliance for broadband data
> (we already have voice switches that handle the voice side of things via
> J-STD-025-B) and had considered offering it as a low-cost commercial
> product versus the $20+k solutions that are floating around out there.
>
> I would like to consider abandoning my project, moving over anything
> useful and joining in the open source development you are doing.  I have
> *some* ASN.1 experience as well.

  Excellent!  Welcome!

> I would like to discuss what I can do to help and what needs to be
> implemented:  from what I've seen ASN.1 and config files are pretty high
> on the priority list.

  Config files are needed, though probably secondary in importance
to actual functionality right now.

  I think the most immediate need is to implement df_collector;
we need to define the "front side" interface that all CmII and CmC
agents will use to send data to it (possibly the ASN in xml format
Norm has gotten with asn1cc), and make it send all data in a uniform
manner out the "back side" to lea_collector (I'm guessing ASN/BER
here).  Once that is in, it's easier to work on individual CmC or CmII
pieces (eg. sip can be seperate from internet data, and different
people can work on CmII agents for different authentication protocols).


> I was using the BSD licensed libconfig for my config.  It is pretty
> simple and lightweight.  Here is a sample config file for what I was
> doing:
>
> caseid = "FBI-1234";
> iapsystemid = "MTI 123";
> interface = "eth1";
> subjectip = "10.100.0.11";
> subjectmask = "/32";
> subjectiptype = "static";# static, radius, dhcp -- only static supported
> subjectaccessmethod = "dsl"; # dsl, dialup, lan, cable, wifi, wimax, other
> subjectidentity = "someusername"; # username, e-mail address, etc.
> startdate = "2007-04-07 19:30:15";
> enddate = "2007-04-07 19:07:00";
> deliverymode = "realtime"; # realtime, store
> intercept = "headers";  # headers, content, headers+content
> cmiiaddress = "udp:10.0.0.1:1000"; # udp:ipaddress, tcp:ipaddress,
> file:path
> cmccaddress = "udp:10.0.0.1:1001"; # udp:ipaddress, tcp:ipaddress,
> file:path

  Manish has said he'd like to use glib for the config file stuff,
simply because it has a lot of other functions thay come in handy.
My opinion is that if we're going to use glib for *stuff* anyways,
we may as well use it for ini parsing (and not require another
dependency like libconfig); otherwise, if there's nothing else to
use glib for, I'd lean towards iniParser, which is small and can be
included as source (no external dependency).


> My architecture was somewhat different that what you have developed so
> far.  Essentially I had designed a single process per intercept model
> that would intercept a target based on a libpcap filter and deliver the
> CmII or CmCC to one LEA.  According to the spec multiple LEAs may have
> warrants for the same target and cannot know of the existence of the
> other warrants/intercepts.  Each LEA may also request different data
> (CmII, CmCC, or both) as well as have different start and end dates for
> the intercept authorization.  Since I expect (as most of my peers at
> other companies) that this will be something used once a year if not
> less I thought the simple approach was best.

  I'd guess frequency of subpoenas will depend mainly on your network
size, and secondarily on the types of folks you harbor on your network. :)
It's not as frequent now, but it wouldn't suprise me at all if the
volume/frequency of subpoenas greatly increases in the future on the
internet side of things.

> In looking at the list archive I see that there is a trend toward
> sending all data to a single DF.  I think that it would be best for each
> "tap" to handle sending it's own data to exactly one LEA.  I think this
> insures separation required by the procedural SSI requirements of CALEA
> as well as allows for maximum scalability.  I think something along
> these lines (which is close to and borrows from what we have each
> developed) would be ideal:
>
> 1) The "tap" is capable of operating completely standalone and reads it
> configuration from a text config file.  It is all that is needed to make
> an intercept and send CmII and/or CmCC to an LEA.  It runs one instance
> per intercept.
>
> 2) Your "controller" process is capable of
> creating/configuring/starting/stopping/status of the "taps" running on
> one or more machines.  Initially this may be command line and down the
> road GUI if someone wants that.
>
> I think this would be ideal for users of all sizes.  A user who is going
> to have one intercept a year can just use the "tap" and not have to
> maintain any type of infrastructure or have security concerns.  Users
> with multiple intercepts can have virtually unlimited scalability with a
> single "controller" system controlling a number of machines running
> "taps".

  You will also need to be able to send CmII from other sources.  Maybe
not in your network, but in many (most?).  Eg. we use radius to
authenticate dsl subscribers - we'll need a CmII agent to deliver data
from the radius server that's completely in a seperate place that the
tap which would pick up the subscribers' CCCmC or CmC.  Hence the
df_collector.


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