[cgl_discussion] Security for internal messaging between diff erent nodes of the cl uster?

Pradeep Kathail pkathail at cisco.com
Tue Feb 11 12:08:19 PST 2003


At 2/5/2003 10:24 AM -0500, Makan Pourzandi (LMC) wrote:
>> -----Original Message-----
>> From: Mika Kukkonen [mailto:mika at osdl.org]
>> Sent: Monday, February 03, 2003 2:20 PM
>> To: Makan Pourzandi (LMC)
>> Cc: 'Eric.Chacron at alcatel.fr'; Makan Pourzandi (LMC); Cgl_Discussion
>> (E-mail)
>> Subject: RE: [cgl_discussion] Security for internal messaging between
>> diff erent nodes of the cl uster?
>> 
>> 
>> Maximum security and maximum performance are orthogonal 
>> goals, and I am
>> all in favor of letting the distro's and their customers to 
>> decide which
>> one they value more. 
>> 
>> But the discussion below is quite academic: could you guys 
>> come up with
>> a certain feature where this trade-off is an issue, and a decision by
>> us is needed? 
>> 
>
>Hi, 
>
>I believe that this is a possible issue when the boundaries between inside and outside of the cluster are somehow fuzzy. For example, a server recieving SIP requests need to access some databases in the backend or some other nodes for more info regarding the subscriber or available services. 
>There is also the case of servers providing some services through the third party software (software can be provided by open source projects, commercial, customer, .... ). This means that in some cases the server can run "untrusted" applications. Untrusted applications can be bogus or have Trojans. This means clearly that you need to protect some of your internal communications from untrusted software. 

Are you planning to have data encrypted between client server pair? There
will be some scalability concern with this approach. If not, then we need
to protect resources like IPC by enhancing kernel resource protection.
Securing channel does not help from rogue applications running on the
box.

Brgds.
Pradeep

>> I mean that just saying that "internal network needs to be 
>> secured" does
>> not tell anything how to do it; saying that each internal connection
>> needs to be run over IPSec does, and clearly that requirement IMHO can
>> not be a mandatory requirement, but ... "configurable" ;-)
>>
>
>I believe that so far we came up with the following: 
>
>1) Security for internal messages must be "configurable". 
>
>2) To be practical, I believe that one very valid candidate to secure connections is IPSec. Do we agree that all nodes in the cluster must support IPSec in order to be able to secure their connections in case of need? 
>
>Please correct me if I'm wrong, but my understanding is that IPSec will be supported in 2.6 anyway and our target kernel for CGL 2.0 is 2.6. This means that we don't need to add any requirement regarding this. 
>
>I don't believe that there is a need to add any requirement regarding configurability of the protection of the internal messages. Once, there is support for ipsec in 2.6, it'll be possible to turn it on and off. Is this level of configurability is enough?   
>
>The only thing that I don't know right now is the IKE implementation which goes with IPSec implementation in 2.6. This is important to know in order to be able to define the configurability. How well new IPSec implementation in 2.6 will support switching from no secure association to a secure association? Any info here? 
>
>Any comments? 
>
>Regards, 
>Makan 
>
> 
>> --MiKu
>> 
>> On ma, 2003-02-03 at 09:57, Makan Pourzandi (LMC) wrote:
>> > 
>> > Hi Eric, 
>> > 
>> > I understand your point here, however, if we take into account the
>> fast spread of SQL Slammer worm recently and the damages 
>> caused by it to
>> the intranets/servers of different corporate companies (which 
>> are behind
>> a set of different firewalls and supposedly in a secured environment),
>> not to mention anything else, I believe perhaps this is not 
>> that much of
>> paranoia. Don't forget that we do not ask for mandatory 
>> protection to be
>> used for all internal communications, we ask here for 
>> "support" for such
>> a protection to give the customr/operator/... the possibility of
>> activating such a protection in case of need. It is important that the
>> customr/operator can configure the desired security needed.  
>> > 
>> > Regards, 
>> > Makan 
>> > 
>> > 
>> > 
>> > > -----Original Message-----
>> > > From: Eric.Chacron at alcatel.fr [mailto:Eric.Chacron at alcatel.fr]
>> > > Sent: Monday, February 03, 2003 10:37 AM
>> > > To: Makan Pourzandi (LMC)
>> > > Cc: Cgl_Discussion (E-mail); CGL Specs-sg (E-mail)
>> > > Subject: Re: [cgl_discussion] Security for internal 
>> messaging between
>> > > different nodes of the cl uster?
>> > > 
>> > > 
>> > > 
>> > > Markan,
>> > > 
>> > > I think we must secure the system against paranoia too.
>> > > In another words i doesn't think internal cluster com. have to be
>> > > encrypted, excepted if this has
>> > > no significant performance cost.
>> > > 
>> > > Eric
>> > > 
>> > > 
>> > > 
>> > > 
>> > > "Makan Pourzandi (LMC)" 
>> > > <Makan.Pourzandi at ericsson.ca>@lists.osdl.org on
>> > > 01/31/2003 08:59:16 PM
>> > > 
>> > > Sent by:  cgl_discussion-admin at lists.osdl.org
>> > > 
>> > > 
>> > > To:   "Cgl_Discussion (E-mail)" <cgl_discussion at osdl.org>, 
>> > > "CGL Specs-sg
>> > >       (E-mail)" <cgl_specs at osdl.org>
>> > > cc:
>> > > Subject:  [cgl_discussion] Security for internal messaging between
>> > >       different nodes of the cl uster?
>> > > 
>> > > 
>> > > 
>> > > 
>> > > Hi all,
>> > > 
>> > > Context:
>> > > 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,
>> > > fiber,...).
>> > > 
>> > > 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
>> > > firewalls).
>> > > 
>> > > Question:
>> > > 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,
>> > > Makan
>> > > 
>> > > 
>> > > 
>> > > 
>> > _______________________________________________
>> > cgl_discussion mailing list
>> > cgl_discussion at lists.osdl.org
>> > http://lists.osdl.org/mailman/listinfo/cgl_discussion
>> -- 
>> "Good ideas do not die, they just lie down and get recycled." -- me
>> 
>_______________________________________________
>cgl_discussion mailing list
>cgl_discussion at lists.osdl.org
>http://lists.osdl.org/mailman/listinfo/cgl_discussion 




More information about the cgl_discussion mailing list