[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clogging attacks on SKIP
> From daemon@ns Thu Dec 15 12:09 PST 1994
> No - it is limited to the number of machines which _may_ use this access
> point. This number can be prohibitively large. Furthermore, it is
> impractical to require that all these machines are predefined to the
> firewall, due to administrative reasons (when a new employee joins in we
> can't update all firewalls of the company, much less of all partners).
>
> > So, I disagree with your contention that the Kijs become unbounded
> > for the firewall scenario.
> >
> I don't see your justification. Please address the context I've
> elaborated on above.
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 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).
Can the same be said of the master key update protocol in
your MKMP document? (I am still waiting for your response
on this issue and the other issue on saving sender resources.)
This resistance to denial-of-service attacks in SKIP doesn't
require special protocol messages especially designed for this
purpose, or even messages. It just comes naturally. (And this
is because SKIP is operationally a shared-key scheme, and
uses a zero-message public-key operation just for the
bootstrap.)
Ashar.
Follow-Ups: