[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WG Last Call for SKIP I-D



>From: Phil Karn <karn@qualcomm.com> 
> >The SKIP defense to clogging is to have a pre-compute cache
> >of master keys. In general when a SKIP node is targeted for clogging, 
> >it stops computing new master keys. This does NOT result in a
> >denial-of-service, since the pre-compute cache can provide
> >communications with nodes with which it has pre-computed
> >master keys (including brand new network connections).
> 
> Ashar,
> 
> You can deal with clogging in *any* key management protocol by simply
> disabling it as long as the attack is in progress, thus disabling the
> creation of new associations. Even if the system is not completely
> disabled (e.g., if prior associations continue to work) I see this as
> less desirable than a protocol that is designed to continue full
> functioning even when it is under attack.
..
> Again this is essentially a successful (partial) denial of service
> brought about by the attack.


Phil,

This point is worth clarifying. *New* associations can still come
in and work during a clogging attack, using the SKIP anti-clogging
scheme, even from nodes that have never communicated before with
the node under attack, since the cache is a *pre*-compute cache.

It isn't necessary to have made a prior association in order
for new communications to occur during a clogging attack. Since
this pre-compute cache can, with relative ease, accommodate 
thousands or even millions of nodes, I am not sure I see this
as a major drawback.

However, it would be trivial to add cookie style anti-clogging
to the existing SKIP ICMP message. This can be used in instances
when a node is feeling clogged (and not as the default
case). This could allow the flexibilility of zero message 
overhead communications under normal circumstances, and 
cookie style anti-clogging during a clogging attack.
 
Your comments?

>If the cache is not large enough to hold the entire database, then the
>attacker can purposely cause it to thrash (presuming he knows the
>replacement algorithm in use). Way back in my reckless undergraduate
>days we used to see how long we could keep the Cornell campus VM370
>system page thrashing with the minimal amount of billed CPU time. It
>was amazingly easy when you put your mind to it...

The caching algorithm does not have to be in any way similar
to an OS page replacement algorithm. One could always let the
cache be a set of nodes that must get through (so they are
permanently in the cache, and this could easily number in the
tens of thousands) and then let the other parts of the cache 
be more replaceable.

It is  worth mentioning that the cookie solution
is also a partial solution, since the cookie approach
relies on an attacker's inability to observe reverse
traffic. Any attacker that can passively monitor, say,
a major Internet backbone can come up with enough spoofed IP
addresses for which reverse traffic will be visible.

Passive monitoring of such a backbone would permit an attacker 
to conjure enough spoofed IP addresses to swamp a node that 
relies only on a cookie approach. The existing SKIP anti-clogging
mechanism does not rely on an attacker's inability to see reverse 
traffic. 

Regards,
Ashar.



Follow-Ups: