LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [PATCH 1/2] Syncd Strong authentication extension

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx, keepalived-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [PATCH 1/2] Syncd Strong authentication extension
Cc: Wensong Zhang <wensong@xxxxxxxxxxxx>
Cc: Julian Anastasov <ja@xxxxxx>
From: Alexandre Cassen <Alexandre.Cassen@xxxxxxxxxx>
Date: Thu, 15 Apr 2004 23:39:22 +0200
Hi Kjetil,

At 20:20 15/04/2004, Kjetil Torgrim Homme wrote:
>       The Sequence number is monotonically increased by  one  each
> time  a new syncd message is created. Since syncd is not an elec-
> tion protocol we don't need  to  deal  with  kind  of  anti-cycle
> mecanism  in  order  to broke a potential dropping loop. Instead,
> the syncd maintains a local sequence number counter  as  dropping
> policy.  This  mean, while processing incoming syncd message, the
> sequence number received in the syncd message is compared with  a
> local  copy,  if  sequence number in the syncd message is greater
> than the  local  copy  then  the  message  is  granted  otherwise
> dropped.

there is a replay attack here, if it works as stated.  server A has been
running for a long time, keeping server B up to date, and malicious user
M is able to capture a packet.  server A has to reboot, and starts
counting at 0.  the malicious user injects the old packet, and server B
will accept it, but drop new legitimate packets until the old high
watermark has been reached.

If A stop sending B will keep seq-num tracked to n. If A stop, B still UP and syncd still in BACKUP state, so if M is sending seq_num m < n it will simply drop datagram since already played. Syncd is not an election protocol, syncd state is not FSM drived, it stay stuck in the state we configure it. If master syncd stop sending backup syncd must be restarted. This can be done automatically but IMHO, it is just preferable to leave admin the decision to restart syncd. If we go ahead ones can suggest to change ICV key each time syncd is restarted... this is security politics point here.

BTW, we can extend BACKUP state seq_num reset if no syncd datagram have been received for a while but this will expose to replay attack. I done this in a first devel step, but IMHO this is less secure than leaving admin decision. OTOH, the syncd restart can be drived by another FSM drived election mecanism like VRRP, that way admin will trust VRRP election.

BTW, if master lvs crash then backup lvs must legitimly become master which will restart its syncd and seq_num to be in master state.

Best regards,
Alexandre

<Prev in Thread] Current Thread [Next in Thread>