[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clogging attacks on SKIP
Hi Ashar and all,
> I already have. What I was and am trying to say is that *in case*
> explicit ACLs exist, these can help in precomputing master keys
> (and many circumstances *will* have explicit ACLs). In cases
> where this is not feasible, usage patterns and/or administrative
> action can facilitate this.
>
> The *worst* that can happen is that, only in case of wildcard
> ACLs, *unusual* access patterns *may* be denied service during
> a clogging attack.
This is what I was refering to. It appears a very reasonable case for a
firewall which allows access to employees of large organization esp. if
they are allowed to use DHCP.
> This isn't all that bad, especially since
> someone who desperately seeks service and is being denied,
> can be asked to put on the priority list and regain access,
> even if the clogging attack continues. (Note that administrators
> would always be on the priority list, and would always be
> able to take such action in a secure manner, even remotely).
Of course such manual solutions would help (but even that should be noted
in the spec!).
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.
The sender has therefore to perform O(2^l) MD5 operations until finding a
valid `ticket' - which should prevent him from clogging...
My belief is that we can achieve almost all properties very similarly in the
interactive and non-interactive cases and therefore we can have one tunable
design which satisfies all of the goals in the exisiting proposals (inc non]
interactivity as in SKIP although I still think this should be an option since
it is less secure - see other note)
>
> Can the same be said of the master key update protocol in
> your MKMP document?
Of course this kind of solution could apply to that protocol.
However since it appears that many people in the WG would like to have
serious protection against clogging, I think this should be added to all
proposals (not just denying service to all addresses when under attack).
(I am still waiting for your response
> on this issue and the other issue on saving sender resources.)
I"m not sure what this is, but I'll be away for a while (and was too busy
recently)...
Best, Amir
References: