[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clogging attacks on SKIP
Phil, Ashar, others,
I agree with Phil, the solution below is expensive. But it is one (and so far
the only) possibility to provide (optional) anti-clogging protection even for
the non-interactive case. The price is not so terrible as it seems, however,
since the non-malicious user has to do this only once per establishment of
a shared key, while the attacker has to do this many times in order to
clog the system. Of course an alternative is that when attacked, a host
would only allow connection set-ups from a pre-defined set, as Ashar have
suggested. But this locks out ad-hoc connections.
Best, Amir
> >Let me mention that if one really wants to, we _can_ give a complete solution
> >to clogging in the non-interactive (SKIP) framework. Namely, require each
> >request to be accompanied by
> > MD5(IPaddresses, time, counter, x)
> >where cnt is the counter of number of tries within the same `time' (which is
> >roughly synchronized), and x is any number such that the last $l$ bits of the
> >MD5 are zero.
>
> Amir,
>
> As I said when you described this to me in my office on your visit,
> this *is* a really neat trick.
>
> But I see a problem. We ideally want our KM protocol to be useable on
> a very wide range of CPUs, from palmtops up through Crays. Most
> mobile clients (where security is most important) are going to land
> near the bottom of this range, especially when you consider that MD5
> is highly optimized for 32-bit machines and doesn't run nearly as fast
> on a 16-bit 8088 class palmtop. I.e., a hell of a lot slower than on
> the 486s and Sparc-class workstations that a typical attacker would
> probably use. So picking a value of $l$ that's sufficiently painful
> for the swamper may also prove to be too painful for the low end
> legitimate user.
>
> Phil
>
References: