Re: [OpenCALEA] df_collector

[Jesse Norell]

Hello,

> I agree that different networks may need different solutions.  Assuming
> you assign a static ip to your intercept subject two different taps can
> do the collection of CmII and CmCC without communicating with each
> other.  One tap simply sends CmII and/or CmCC based on ip and the other
> sends CmII based on dhcp/radius/whatever.  Assuming taps could
> communicate via the controller then you could even have the CmII tap
> start a CmCC tap for a dynamic IP.

  The latter will be required for some scenarios, eg. our dsl hosting.
A subpoena is likely to be against a username or the atm pvc we receive
their connection on, and their ip address does change every time their
modem connects.  In our setup we use PPPoA to the router, which itsself
authenticates users to a radius server.  We can't monitor the atm side
of things, so we'll have to pick up CmII on the radius server, and will
only know the ip address to watch for CmC from the CmII source.

Note: a single tap process trying to decode all the different
authentication methods (dhcp, radius, tacacs, pppoe, etc.) does not
seem practical or desirable.  Using radius as an example, it means the
tap would have to know every radius shared secret for every RAS
that would need to be monitored, and understand enough of the radius
in use (potentially including custom radius dictionaries) to properly
do it's job.  I think picking the data up on the radius server (either
from logs or integrating with the server itsself (easy with freeradius))
is a much better solution for this.


> If your agents are going to do the ASN then why wouldn't you just have
> them send the CmII and/or CmCC directly to the LEA instead of
> encode/decode/re-encode?

  I just seems like a much cleaner setup.  You have a single endpoint
from DF to CF.  It's easier to implement the CF side (eg. a single tcp
connection could gather all CmII, rather than multiplexing connections
from multiple CmII agents).  It's a little easier to filter on the CF
side (though that's not a big issue).

>  Alternatively, why not just have them send the
> data already encoded to your df_collector and let it send it verbatim?

  I was hoping to make the "front side" of df_collector easy for
creating 3rd party CmII or CmC agents, so more people would be able
to contribute, and XML would do that.  I've not looked, but I would
guess doing ASN/BER in php, perl, bourne shell, ruby, etc. would be
a lot more forbidding than in xml.  The "back side" is likely to
require ASN/BER.  So to accomplish both requirements, you end up
transcoding/translating.

  It may or may not be worthwhile, but that was my thinking.


> Where would you place the logic for the following scenario with a single
> df_collector:
>
> You have two warrants for an intercept of the same target from different
> LEAs.  One warrant calls for only CmII, the other calls for both CmII
> and CmCC.  One warrant starts June 1st and is valid for 30 days, the
> other warrant starts June 3rd and is valid 60 days.  One LEA wants
> realtime delivery via IP, the other wants short-term storage.

  I envision running a seperate df_collector for each intercept.  Likely
the CmII/CmC agents don't even know the case id (that'd be added
uniformly by df_collector), and maybe even content-id as well (haven't
looked into the details there).

  As for the starts/stops and whether it's CC or just II, right now
that's gonna be manually handled.  Long term, I think that should be
defined in a database and have a process on all the different IAP's
checking that database to see if they should start/stop (and monitor)
anything.  Maybe the current "controller/collector" type setup could
be used to check status, but not to control anything.  That's my
current thoughts .. it certainly may work out differently in the end.

  As for real time vs. short term storage... I'm currently reading
T1.678, but T1.IAS makes no provision whatsoever for short term storage;
you have 8 seconds to get data to the DF, and an agreed upon T2 time
to get it to CF.  I guess if you could agree that T2 is "at the leisure
of the LEA" and you setup a "pull" system, that could work, but it
certainly seems to violate what I gathered to be the general intention
of T1.IAS.  But if it's an option, it's again just a matter of where
df_collector sends the data.  In fact, the easiest implementation of
short term storage would be to fire up a copy of lea_collector on
the web/sftp/whatever server the LEA pulls from, and have df_collector
send there rather than directly to the LEA.


> I'm not against some type of collector function, I just think it would
> be nice to keep it where a tap/agent could be executed standalone if
> desired.

  It could (and mostly will) be for CmC and CCCmII - but there is other
CmII, at least in some common network environments, that will have to be
handled apart from that.  Hence the df_collector idea.


  Thanks for the post... useful discussion on this is exactly what we
need to make sure the project heads in the right direction.

Jesse

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