[Linux-cluster] Where to go with cman ?

[Steven Dake]

On Sun, 2005-07-24 at 22:38 +0200, Lars Marowsky-Bree wrote:
> On 2005-07-18T09:10:30, Patrick Caulfield <pcaulfie at redhat.com> wrote:
> 
> A late reply is better than no reply I guess.
> 
> FWIW, the Linux-HA project has been going through some of the same
> thoughts. 
> 
> (Not wanting to make any statements about the future of NCS here, which
> is a different group, but I know that Robert is keenly aware of
> OpenAIS/libtotem etc too.)
> 
> Linux-HA is looking to integrate with OpenAIS. The exact design is yet
> to be understood, but what is clear so far is that I'm convinced we'll
> support running on top of OpenAIS as an additional messaging layer, and
> figure out a way how to keep our Concensus Cluster Membership and
> OpenAIS's one synchronized.
> 
> We're not quite ready to abandon our existing communication layer
> completely in exchange with OpenAIS, for a variety of good reasons:
> 
> - We support some scenarios which OpenAIS doesn't; we can support raw
>   serial communication links for example, which is very useful for 2
>   node clusters (which make up 100% of our existing userbase and
>   probably even with the ability to support N nodes, will continue to be
>   in excess of 90% of all installations.)
> 
> - OpenAIS relies on the cluster network to be protected by IP/Sec (or
>   other forms of network layer security, and be it just "don't you dare
>   run this over anything but private links"). This is well for some
>   scenarios, but makes setup more complex.

I agree with everything you say except this statement.  The openais
libtotem code has symmetric encryption (sober128) and authentication
(hmac/sha1) of messages.  It is not perfect.  It is open to replay
denail of service attacks of captured messages on the local network.  If
an attacker is sniffing the local network, they may already have the
private key in which case game over.  The DOS problem can be fixed but
hasn't yet.  Another problem is that the private key is never
dynamically generated which is another thing I'd like to work on in the
future.  The security available, however, is better then un-ecrypted
packets without authentication...  If you want to read more about the
threat model assumed and algorithms used, take a look at the file
"SECURITY" in the sources of openais.

Because of the DOS possibility, I'd recommend ensuring the ports used in
openais are protected as best as possible from external untrusted
access.

regards
-steve