[Discussion] Features - Designing for Scaleability

[Martin Holste]

Since all of the OpenVPN nodes use identical config files, there really is
very little admin overhead.  You just put a different private key on each
one which is generated in one simple command with the shell script included
in the OpenVPN tarball.  (Actually, you can use the same private key if you
don't care about being able to revoke a specific one).  So, it takes about
60 seconds to add a node and they all "discover" each other rather easily.
>From there, all the communication is over standard IP as far as the apps are
concerned, which really really helps in troubleshooting.

However, Jason's point regarding allowed protocols in certain environments
is a valid one, so I can definitely see TLS as an advantage there.  My
concern is to keep whatever we use a socket or tunnel and not something
baked into the application.  That's because it's a huge headache to make
sure that every component of the system is capable of encrypting its
communication as opposed to the comfort of knowing that anything routed to
specific addresses will absolutely be encrypted.  If you know you've got an
encrypted tunnel from point A to point B, you can always resort to
wget-style hackery if you need to, you can implement any module you want
without worrying about encryption, and best of all, you are guaranteed to
only have to setup the certificates (or keys) once for each node, instead of
once per node per add-on application.  There's also the whole controlled
export of strong encryption pitfall for some of our international
colleagues.

--Martin

On Thu, Jan 15, 2009 at 10:38 PM, Jason Ish <ish at unx.ca> wrote:

> I know that some large companies and government agencies aren't to
> keen when they've found out you are using your own encryption scheme.
> They'd much rather see something along the lines of TLS.  I think TCP
> can be quite efficient, its also much easier to keep track of state if
> you need to.  Lately I've been looking at Google protocol buffers, and
> it is quite efficient at encoding data over the wire.
>
> Hub and spoke sounds about right I think.  I could imagine something
> where a company has their sensors talking to their server.  Their
> server could then optionally hook into the global network where
> information such as IP reputation could be distributed, or even
> notification of new rules.  Sensors wouldn't talk directly to each
> other in this scenario but would send a message to their server which
> would then broadcast to its connected agents, and perhaps upstream
> into the bigger network.
>
> Jason
>
> On Thu, Jan 15, 2009 at 10:41 PM, Matt Jonkman <jonkman at jonkmans.com>
> wrote:
> > I was kind of thinking something along the lines of the sensors being
> > aware, but assuming they could all communicate with eachother may be too
> > much in many places. I think a hub and spoke architecture would probably
> > be best. But the communication method would probably be quite efficient
> > if we just used udp and internal encryption. i.e. udp with the payload
> > encrypted to preshared keys.
> >
> > Matt
> >
> > Frank Knobbe wrote:
> >> On Thu, 2009-01-15 at 12:35 -0600, Martin Holste wrote:
> >>> Regarding sensor-sensor communcation, I recommend using OpenVPN for
> >>> all communication since it's free, cross-platform, provides built-in
> >>> compression, has easy configuration, it's PKI infrastructure based,
> >>> and makes debugging much easier since you can sniff your tun0 socket.
> >>> It also makes your host firewall rules much more simple.
> >>
> >> But then you have administration overhead, right? (Sorry, I don't use
> >> OpenVPN. All my VPN's are SSH-based).
> >>
> >> Wouldn't it make more sense to use some sort of cloud/P2P-based
> >> sensor-to-sensor communication that is able to "find" other sensors to
> >> reduce admin tasks? Give it a name and let it join the sensor cloud.  :)
> >> I think that may be what Matt was eluding to in regards to sensors being
> >> aware of each other.
> >>
> >> Cheers,
> >> Frank
> >>
> >>
> >>
> >
> > --
> > --------------------------------------------
> > Matthew Jonkman
> > Emerging Threats
> > Phone 765-429-0398
> > Fax 312-264-0205
> > http://www.emergingthreats.net
> > --------------------------------------------
> >
> > PGP: http://www.jonkmans.com/mattjonkman.asc
> >
> >
> > _______________________________________________
> > Discussion mailing list
> > Discussion at openinfosecfoundation.org
> > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
> >
> >
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20090116/0cd02230/attachment-0002.html>