[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC Security Gateways & NAT
----- Original Message -----
From: "Dan Harkins" <dharkins@lounge.org>
>
> The DoS attack mounted against IKE is one that exploits the fact that
> the responder creates state upon receipt of a single message from the
> initiator. That will not be addressed by moving the authentication
> step. It will be addressed by further complicating the protocol with
> a new stateless "cookie request" option.
>
Can't we just use the ISAKMP cookies instead of creating new ones?
What criteria they don't fulfill?
I agree that it will complicate the protocol as the HASH_I must be sent
before DH and must be computed without relying on g^xy, if that is
what you mean.
> Your suggestion to move the authentication step would further complicate
> the protocol. The way it is now there is a uniform progression of state
> for each of the authentication methods. As someone who has implemented
> this protocol I can tell you it makes it much simpler to code that way.
>
Yes it does complicate the protocol, but I am not suggesting
changes to IKE. I am just curious why it is done the way it is
done.
> As has been pointed out repeatedly in this thread (and in the past) a
> DoS attack that attempts to force the responser to do needless Diffie-
> Hellman work would expose its IP address and the attack could be properly
> addressed because of it.
>
Not necessarily.......
The responder will perform DH if the reply includes the correct
responder cookie. If a router is compromised (one that is in
the path between the spoofed IP addresses and the target),
you can spoof a whole bunch of addresses and send message
1's. Based on the message 2 from the responder, send replies
with the correct cookies. I Guess this will make a successful DoS
attack as the effort required to generate message 1's and 3's is
not much. You can't even throttle on IP address as you are getting
messages from different IP addresses.
> There are all sorts of changes that can be made to IKE but one that
> would make the protocol much more complicated for such a small (perhaps
> even non-existent) benefit is not something we should consider.
>
I think IKE is pretty good.
regards,
Jayant
References: