Re: [OpenCALEA] df_collector

[Jesse Norell]

Hello,

  On df_collector design, Norm suggested we could have one port that
accepts asn structures in xml, and another port accepting ber.  That
long term design would allow us in the short term to build the ber
piece and get about the actual cmc/cmii agents, and put the xml piece
on the todo list.  I like it.

Jesse



On Thu, April 12, 2007 10:54, Jesse Norell wrote:
> 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
>
>
>


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