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