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

Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing

On 9 Feb 00, at 11:38, Tamir Zegman wrote:

Hi, Tamir, 

please, see some comments below.

First of all, a very similar idea was described in 
http://search.ietf.org/internet-drafts/draft-moskowitz-hip-01.txt

But in both cases I'm puzzled what benefits will this approach lead 
to? In my understanding the way to defend responder against DoS 
attacks lies in lowering responder's resource consumption (both in  
memory and CPU) _while performing peer authentication_. The last 
addition is important.

And, for example, stateless cookies do meet this requirement - they 
perform a weak peer authentication with minimum resource consumption. 
In this case responder's credo is "OK, I will talk to you if you 
proof that you're alive". It makes sense to me, because "to be alive" 
is some part of authentication. But what is responder's credo in your 
case? With your approach responder requires initiator to perform 
costly operation that doesn't add any bit to initiator 
authentication. Responder says: "OK, I will talk to you if you proof 
that you're alive and have substantial CPU power". Does it make any 
sense?

In my understanding good DoS attack defending technique should 
protect responder from attacker _while still allowing legitimate 
initiator to perform connection_ (at least with some probability). 
Your approach deliberately prevents poor legitimate peers to connect 
when responder feels it is under attack. It is not DoS attack 
defending, it is a real DoS (Denial of Service) for such peers, so an 
attacker may celebrate... In this case I would prefer a simple 
"random drop" technique - at least it is more democratic :-)

Best regards,
Valera.

> While Main Mode and Base Mode provide some protection against DoS attacks
> through the cookies mechanism, no protection is provided whenever the attacker
> is on the path between the responder and the spoofed initiator.
> In such a case the responder is still susceptible to cookie crumb attacks or to
> modular exponentiations attacks.
> 
> Let me propose a method to ward off modular exponentiations attacks.
> The method is as follows:
> If a responder detects that it being attacked (let say by the fact that it has
> more than X simultaneous Phase 1 negotiations, where X is configurable) it will
> do the following:
> 1. Generate a 128 bit random number A.
> 2. Compute MD5(A).
> 3. Send a special ISAKMP payload to the initiator that contains -
>    I. MD5(A).
>    II. The first B bits of A, where B is configurable.
> 
> Upon receipt of this payload, the initiator will be asked to compute A (using
> brute force methods) and send it back to the responder.
> This computation is possible with the aid of the first B bits of A.
> The responder will then proceed to do the modular exponentiations computations
> only if it got A from the initiator.
> 
> Using these methods (and assuming that there is no efficient method to invert
> the MD5 function given MD5(A) and the first B bits of A) DoS attacks become very
> difficult.
> 
> Notes:
> 1. Any other cryptographic hash function can be used.
> 2. If B is too small the initiator can refuse to carry out the exchange (so as
> not to spend to much resources).
> 3. This theoretically opens up another attack in which the attacker attacks the
> initiator (and not the responder) by sending him this payload. This in my mind
> is not such a serious problem, since in scenarios that allow this kind of
> attack, the DoS attacker instead of mounting this attack can simply pretend to
> be the responder making the initiator to do the modular exponentiations.
> 
> Regards,
> Tamir.
> 
>
Follow-Ups: References: