[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Clogging attacks on SKIP
Hi Aziz and all,
Here are some long over-due comments on SKIP. I'm trying to
SKIP comments already made by Hugo and others.
In order to be effective, in this note I'll write only
two comments on one concern: the resistance of SKIP to
clogging (denial of service) attacks. In the first possibility
I'll continue with other comments.
I am concerned about two possible clogging attacks against
SKIP.
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).
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.
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.
This attack is less severe but could hurt performance.
Well, have to run, more later... Let me mention both attacks
could be dealt with, but I don't have a really wonderful
solution so I'll rather see maybe Aziz will
have a nicer one.
Best, Amir