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

Re: Clogging attacks on SKIP




>From ipsec-request@ans.net Thu Dec  8 14:10:27 1994
>Of course the receiver can count number of key exchanges it engages in and
>discard any more... You missed my point rather than finding me untrue :-)
>The problem is that if the receiver is deciding it is too busy, the sender
>is unaware of this, and continues sending messages. If the receiver is just
>dropping all of them, this is as severe a denial of service as any you'll get.
>This is not the case with the interactive scheme, where the sender is aware
>that the receiver has not agreed to a key and therefore would not spend
>resources sending the packets.

I think I did miss what you were trying to say, for which I apologize.

However, there is still some confusion, and I am not sure it's all on
my part.

First, let me mention that the pair keys Kij always (conceptually)
exist, and can be precomputed *prior* to any communication attempt.

This can be done by following a prioritized list using the per node 
ACL (which you always need, because otherwise there is no need to
authenticate). Note that this sort of precomputation cannot be performed
using traditional (non-SKIP) interactive schemes, because there
are no shared secrets prior to communication. This precomputation
can follow usage patterns of the machine, or some administrative
action.

Now, if nodes on this prioritized list try to perform service
access, there is no need to do computationally expensive operations
(like DH). All that is needed are lightweight operations like
MD5 or shared key operations. In case of clogging attacks, the
end node can simply discard packets that require computation
of *new* DH operations (provided the ACL was not completely covered
by the precompute effort). 

This means that nodes on the priority list for which precomputation 
has been performed can *always* get access, because there is no need 
to engage in a computationally expensive operation to figure out if 
their packets are valid.

The second point I would like clarification on is your comment
that with interactive key-management the sender knows that there
is no key, and therefore doesn't "spend resources sending the
packet".

This is only true if the interactive key-management protocol is 
embedded in a connection oriented network protocol.

However, IP is most certainly *not* connection oriented. IP
contains no mechanism to flow control back to the transport
or application entity, which may be on a local machine or on 
a remote machine. If, e.g., IPSP is operating in intermediate 
system mode, there is no IP way for the intermediate node to 
tell the transmitting IP node to stop sending packets.

This is not a SKIP issue, but rather an IP issue. If you have
a way for addressing this issue in the context of connection oriented
key-management protocols running with IP, I would be happy to learn 
of it.

Third, I should point out that since with SKIP one can have
precomputed and cached shared master keys, the master key update
protocol (with perfect forward secrecy) that I presented 
at the San Jose meeting is far more resistant to a clogging
attack than the master key negotiation protocol in your
MKMP document.

This is because the master key update protocol messages
are protected using lightweight mechanisms like MD5. In
your protocol, one has to do an RSA signature verification
before one can decide what to do with the message. This
is far more vulnerable to a clogging attack than the
SKIP master key protocol, where one doesn't need to peform
any public key operations, if one isn't happy with the
result of the MD5 based authentication.

>Agreed, however in the interactive scheme there is no demage except the
>replay of the packet. In SKIP, this makes caching more keys and reduces
>efficiency.

Caching shared keys is quite a low overhead operation considering 
their small size, and the large amount of memory available on most
machines.

Regards,
Ashar.


Follow-Ups: