[cgl_discussion] Re: [cgl_specs] Security for internal messaging between different nodes of the cl uster?

Pradeep Kathail pkathail at cisco.com
Sun Feb 2 13:52:53 PST 2003

Agree that we need to maintain the security of the internal messages. But,
I think we need to leave this to equipment providers. It is okay as
an option, but if internal interconnect is completely isolated from 
the external interconnect, I do not want to pay the cost of encryption.


At 1/31/2003 02:59 PM -0500, Makan Pourzandi (LMC) wrote:

>Hi all, 
>We have a carrier-grade server that consists of multiple nodes with LAN 
>between nodes (LAN has been chosen to simplify the discussion, the 
>interconnection between nodes can be of any kind: Ethernet switches, 
>Generally, one supposes that the server is in a trusted environment, 
>(i.e.; the server is behind one or several firewalls, and is protected 
>from intrusions). In reality, the spread of all viruses and Trojans 
>shows that firewalls are not enough to secure the whole network 
>(c.f. more precisely the propagation of viruses inside intranets of 
>different companies despite that those intranets are behind 
>1) Do we need to support any security mechanism for the internal messaging 
>between different nodes inside the kernel? 
>2) Do we need to support confidentiality or integrity for messages exchanged 
>inside the cluster? 

>Remark that the fact that we support this does not mean that we want to use 
>them upon all messages exchanged. We can choose not to encrypt/authenticate 
>all or part of messages when the cluster is heavily loaded to avoid loss in performances. 
>Also, clearly not all communications must be protected, for example I don't 
>believe that we need to protect heart beat messages. 
> I personally believe that even if we do not support encrypted messaging inside 
>the cluster at least we want to be able to guarantee integrity for some communications 
>inside the cluster (for example, to be able to protect some requests/commands 
>through the control panel). 
>Any comments? 
>Thank you, 

More information about the cgl_discussion mailing list