|
On Sat, 2004-03-27 at 20:39 +0100, Alexandre Cassen wrote:
> . Anti-replay prevention: Since sequence number is part
> of the ICV computation, any attacks based on packet
> replay will be dealt.
> [...]
> 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.
actually, how does server B know that the counter being reset by server
A's reboot is OK? keeping A's counter on stable storage so that it is
kept across a crash seems impractical.
--
Kjetil T.
|
