Re: [OpenCALEA] patches accepted?

[Jesse Norell]

  A few other ideas/questions as for features/design:

- Add -u user and -g group, and drop root privileges as soon as
possible.  lea_collector should be able to run as non-root now, but tap
will (in general) need to start up as root.

- Add config file support to specify default settings (ports, log level,
user/group, default collector ip addr, capture interface, etc.).  Is
there a policy/preference for including linking against external
libraries (eg. for config file parsing) vs. including other code in the
distribution?  (I'd guess if it's small, just include the code
directly.)

- Specify a capture file directory for the collector and maybe default
the capture filenames to something based on the caseid?  Would want to
specify whether existing files were overwritten or appended to, and
probably sanity check the caseid name for "../" characters (especially
until some authentication gets put in between tap and collector).

- I'm guessing the use of udp between tap and collector was an
intentional choice?  tcp has some advantages (eg. no need to measure
packet loss between tap/collector, it'll all get there; also much harder
for someone to send bogus/malicious packets to the collector).  It might
be nice to have a switch that people could use either udp or tcp as they
see appropriate.

- Definitely need some authentication between tap and collector.

- Make "-i interface" not be a requirement.

- Standardize commandline options.  Eg. -f would commonly point to an
alternate config file (could probably just parse known options and use
"all remaining arguments" as the pcap filter, like tcpdump does).  -n
commonly would mean "no name lookups", eg. if the debug routines were to
print hostnames or port numbers.


  As for the controller, the design looks to be for it to initiate a
tap/collector pair for each intercept, with all the "brains" in the
controller?  A few scenarios come to mind for communication design and
such .. maybe you could comment on them.  Of course you've gotta start
somewhere, which has been done, but as consideration for the long term:

- It would be nice to have a middle layer/api between the controlling
user interface and the actual piece that controls the taps/collectors.
That would allow 3rd-party apps to easily integrate as well.

- Is the controller intended to know (eg. by manual configuration) what
taps are available, and what ip network traffic they can see?  Would it
make sense to have a tap register with the controller and tell the
controller what it has access to?

- Instead of separate tap clients for every intercept request, would it
be good to have a single daemon running that provides the actual tap
functionality, then a local tap controller that can add/remove
intercepts to the running daemon?  You'd want the collector to save
separate cases to individual files.  This design would fit well with
something like memcache to store and distribute the active intercept
database.

- In either/both the current and future design, if the tap program
exits/dies it needs to be caught and restarted.

- Would it be useful for tap to be able to read a pcap file and send
data to the collector from that?  You could design redundant tap
machines (or could just use tcpdump to save the pcap file) and reconcile
duplicate packets at a later time, or otherwise take the collector
offline but still perform the intercept.  I've not read the spec yet ..
I don't know how close to realtime this has to be.



On Sun, 2007-03-11 at 08:16 -0400, Manish Karir wrote:
> 
> Good question.
> Here we were planning on targeting the following primary features in the
> next couple of releases:
> 0.5:
>   - intial release of controller/collector utilities.  These enable us to
>     remotely intitiate a tap collection and also to manange multiple tap
>     session on the same tap device.
> 
> 0.6:
>   - modfications to the controller/collector to enable a single controller
>     to trigger simultanteously taps at multiple collector sites.
> 
> Some more longer terms features are:
>   - optional encryption of the payload support
>   - secure logging of taps
>   - perhaps an encrypted connection between controller/collector
>   - support for tcp transmission of payload to LEA
> 
> these other features could be moved into the 0.5/0.6 releases if someone
> wants to take a crack at them?
> 
> -manish
> 
> 
> 
> On Fri, 9 Mar 2007, Jesse Norell wrote:
> 
> >
> > Hello,
> >
> >  I suppose I should be patching against the latest svn, not the 0.4
> > release?  Is there any published info of interest to developers, eg. the
> > "std" referred to in (iirc) calea.h?  Even what current plans are as far
> > as accompanying programs, added features, control api/interface, LEA
> > delivery interface, etc.  I can make sure any efforts I take are at
> > least in the right direction.
> >
> > Thanks,
> > Jesse
> >
> >
> > On Fri, 2007-03-09 at 20:51 -0500, Manish Karir wrote:
> >>
> >> Hi Jesse,
> >>
> >> Patches are most welcome! We are anticipating
> >> release v0.5 around march 20th and can probably roll patches into
> >> that release.
> >>
> >> thanks
> >> manish
> >>
> >>
> >> On Fri, 9 Mar 2007, Jesse Norell wrote:
> >>
> >>>
> >>> Hello,
> >>>
> >>>  Looking at the currently available code ... do you accept patches, or
> >>> is this a closed development project?
> >>>
> >>> Thanks,
> >>> Jesse
> >>>
> >>>
> >>> --
> >>> Jesse Norell - jesse@kci.net
> >>> Kentec Communications, Inc.
> >>>
> >>>
> > -- 
> > Jesse Norell - jesse@kci.net
> > Kentec Communications, Inc.
> >
> >
-- 
Jesse Norell - jesse@kci.net
Kentec Communications, Inc.