[OpenCALEA] Developer - New to the list

[Kevin Wormington]

Hi,

I just ran across the OpenCALEA project.  I appologize up front for the 
length of this posting.

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.

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.

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


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.

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".

Let me know any feelings anyone has and how I could help in moving 
development forward.

Kevin