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.
