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

RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing



Hi Paul,

I don't know that it wouldn't be possible to use client puzzles in a typical
VPN.

There are certain differences between the typical usage of clients and
gateways that might help to reduce load under common scenerios.

For example:

1. There are typically more clients than gateways.
2. The gateways have fixed IPs but the clients do not.
3. The gateways are usually initiating to a limited set of remote gateways
that is known in advance (or can be detected at runtime).

Under these circumstances, the responder could avoid forcing the gateway to
solve multiple subsequent client puzzles by issuing him a "get out of puzzle
free" token after each phase 1 negotiation.

There are a limited number of known gateways, therefore these tokens would
only use up a small amount of stored state. And sending the token during a
phase 1 negotiation would absolve the initiator of the puzzle-solving task.

Of course, this technique only works in the scenario I describe, but that is
a fairly common scenerio.

Note that this is quite similar to a method of active identity protection
that I described a few months ago.

Andrew
_______________________________________________
 Beauty without truth is insubstantial.
 Truth without beauty is unbearable.


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Koning
> Sent: Thursday, February 17, 2000 12:28 PM
> To: zegman@checkpoint.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs
> Addressing
>
>
> I have a concern about this notion of using puzzles as a way of
> addressing the DoS problem.
>
> It seems that there is an implied assumption in this approach: that
> the client is connecting to only one, or at most only a few, servers.
> In that case, the puzzles approach seems plausible because the client
> can afford the cost of solving a few puzzles as part of connection
> setup.
>
> On the other hand, what if your "client" is the hub of a hub & spoke
> topology VPN, and is initiating many IKE requests concurrently?  We
> already have seen some topologies of this kind, where scaling is a
> concern.  The cost of regular IKE exchanges (two DH operations plus
> typically some public key stuff) is already high enough to
> generate an
> interest in PKI accelerators.  If the initiator is trying to initiate
> several hundred IKE exchanges, and in the process is hammered with
> several hundred puzzles, life is suddenly very unpleasant indeed.
> Note that the puzzles proposed so far aren't things you can
> accelerate
> with available "crypto hardware assist" devices.
>
> Let's be sure to keep this scenario in mind when analyzing proposed
> approaches.
>
> 	paul
>




References: