Re: [OpenCALEA] Open Calea Useable?

[Jesse Norell]

Hello,

>   It sounds from this thread that the OpenCalea code base is not ready
> to be used for even minimal Calea compliance, correct?

  That's correct.  The closest thing we have to being actually ready
right now is an IAS network tap, for actual content.  As I infer from
what I've seen, content subpoenas aren't nearly as common as the "pen
register" or "trap and trace" (I believe I'm using those correctly, but
may have them mixed up), which would be just identifying information
(CmII); the latter being the most minimal compliance possible.  CmII
hasn't even been started on as far as working code (the asn work has
been done, now we need cmii agents to gather/send the info in proper
formats).

>   There are a lot of people on this forum that are hoping that this
> effort will produce code that will make them compliant come the
> deadline.

  Believe me, we're hoping for that, too.  :)  I've already seen 2
commercial products using opencalea for calea compliance.  It blows me
away.  I'm sure once opencalea is "ready" they'll have something, but
right now...

>    What is your honest assessment as to whether we should be
> using/integrating this code as part of a product or solution for
> CALEA?  Or, should we be purchasing some of the existing (albeit
> expensive) CALEA solutions.

  We're actively looking at commercial solutions as well; however the
only ones we've found that we could afford are based on opencalea.  Work
is progressing fairly rapidly on opencalea, but I don't know if it will
be ready by the deadline.  I'd guess some pieces may be.  There's also
the matter of testing our output against what a LEA (particularly the
FBI) can receive, which we'd like to do, but so far haven't made a great
deal of progress in that area.  (To be fair, we've only just recently
had a tap that would produce asn/ber in the right structures, so there's
been nothing to actually test yet, and maybe they're keeping an eye on
progress, waiting till something was testable; though I've not even
gotten a single reply regarding the possibility of testing in any of my
contacts with them.)


>    At least a partial list of what you feel is lacking in the current
> code base would be helpful to us. 

  The asn definitions have been compiled and ready to be used; there are
errors in the "pre-published draft" standard we have to work with, so
you have to guess and manually fix stuff up (hence the importance of
testing).

  The IAS tap is I think very close to putting data in the right format.

  The VOP tap is pretty similar, it just puts data in a different
format, so I'd guess wouldn't be a tremendous amount of work to get
going.

  Some work on extracting sip has been done (by Norm) .. I don't know
how far along that is.  You have to parse the sip packets and send CII
in the right format, as well as firing off taps for content.

  No work on DDE (dialed digit extraction) has been done, and very
little thought put to it so far.  Possibly we can say it's in the LEA
collection function as mentioned in Annex F (which just passes the
buck .. long term we probably ought to support at least rtp2833 digits).

  I'm working on a controlling / messaging framework, to be able to
start programs, check status, etc.  It's quite a ways off from being
ready.  That will be necessary for all but the most basic of setups.
Eg. a radius cmii agent that sees a suspect login has to be able to fire
off a tap for the proper ip address; that will happen through a control
message.

  Then there are various CmII agents that need to be written, eg. for
dhcp and radius.  A little thought, but I don't think much work on code,
has been put to them.

  We need our program for a DF function (df_collector) written.  I don't
think it's been started, but it's pretty straightforward.

  And then there's general cleanup, integrating config files,
authentication among pieces, all the non-critical features/support that
won't even be thought about on day one, etc.


  So, all in all - there's a lot of work to do.  People volunteer to
help from time to time, but so far there are only 3 of us that have
actually joined in on the work.  Anyone else that could help would be a
great help.  (Eg. I'd think any commercial vendors betting their calea
compliance on the project may be interested in seeing it progress
faster.)

Jesse


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