[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clogging attacks on SKIP
>From ipsec-request@ans.net Wed Dec 7 09:05:57 1994
>First clogging attack: flooding receivers with junk packets.
>============================================================
>
>In SKIP, when a receiver $r$ receives packets from a new source $s$,
>then $r$ should get the public key for $s$, verify it, and
>then compute the master key $K_{rs}$. It is not specified
>what is to be done to the packet(s) in the meanwhile, but
>I'll assume they are cached rather than dropped unless the
>spec said otherwise. (Dropping the packets loses much of the
>SKIP-appeal).
Our implementation maintains a (flow-controlled) cache, but
I dont understand why dropping the packet loses the
SKIP appeal?
>
>An attacker could abuse this mechanism by simply sending many
>packets with different source addresses. Poor $r$ would have
>to buffer all of these packets as well as engage in asking
>for master keys for all of them, verifying,...
>
>Q: doesn't this attack hold for all methods?
>A: Well, in any method the attacker can pretend to initiate
>the key exchange, that's true. But in SKIP packets are sent
>immediately following the key exchange, and there is no
>negotiation mechanism so $r$ cannot limit the number of
>concurrent key exchanges.
This isn't true. The receiver always knows when it
is computing a new DH derived key, and therefore
can keep a count of the number of such concurrent
activities it is willing to tolerate. Same as
the case for interactive key management.
>Second clogging attack: re-sending old packets
>-----------------------------------------------
>
>By resending an old packet between two legitimate computers
>$r$ and $s$ an attacker can cause $r$ and $s$ to constantly
>trash and replace the packet key $K_p$. This may be (only)
>detected by the sequencing mechanism (if used), but it is
>not clear what is the right response if any.
Two comments.
First, a SKIP implementation doesn't have to trash the old key
as soon as a new one appears. In fact this scenario can occur
in benign ways as well, for example out of order packet
arrival on key-change boundaries. The implementation can
keep the old key based on some usage meter, so as long
as *some* legitimate packets can come in (within the
inactivity timeout) the legitimate key will not be
trashed. Our implementation already does this.
Second, playback of legitimate old packets can occur within
a session for interactive key-management cases as well.
As soon as an attacker has one legitimate packet, that
packet can be repeatedly played back for the duration of the
session. The only way to prevent this for the interactive
case is to use sequencing as well.
Ashar.
Follow-Ups: