Re: [OpenCALEA] patches accepted?

[Jesse Norell]

Some more todo items:

- add "-i interface" for the collector (again, not mandatory)

- setup a debug framework, supporting maybe -d -dd and -ddd (3 debug
levels?).  When the collector is in debug mode, make it flush disk
writes (every time or every 10 seconds or something).



On Mon, 2007-03-12 at 10:00 -0600, Jesse Norell wrote:
>   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.