|
On Thu, 2004-04-15 at 23:39 +0200, Alexandre Cassen wrote:
> At 20:20 15/04/2004, Kjetil Torgrim Homme wrote:
> >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.
thank you for the explanation, I understand much better now.
> 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.
I agree, that is not a good solution.
> OTOH, the syncd restart can be drived by another FSM drived
> election mecanism like VRRP, that way admin will trust VRRP election.
it can also be done outside the protocol by keeping a list of
pre-generated ICV keys which is shared between the participants. the
admin would have to refill the list occasionally as a key is consumed
every time the master is switched. it seems to me VRRP is sufficient to
signal when switch-over should happen. doing this signalling in the
syncd protocol as well will make it possible to get inconsistencies or
race conditions.
--
Kjetil T.
|
