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

Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing



Valery Smyslov wrote:

> 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 order to carry an effective DoS, an attacker needs to initiate a several (I'd say
hundreds) of simultaneous negotiations with the responder.
By using the method I propose, and assuming that the attacker computational power is
limited, only few negotiations will reach the stage in which the responder is needed
to perform the costly modular exponentiations.
Note that my proposal does not prevent an honest peer from performing the key exchange
-
First of all the "Please reverse the hash function" challenge is only sent when the
responder suspects that it is being attacked.
Second, an honest initiator will only need to answer one of these challenges - a task
that it can no doubt perform - whereas an attacker will need to respond to several
hundreds in order for his attack to succeed.


>
> 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.

This is a matter of configuration. If the challenge is as such that the number of cpu
cycles needed to answer it is in the order of let say the cpu cycles needed to perform
one modular exponentiation, then even poor legitimate peers would be able to respond,
whereas an attacker will need to invest at least a 100 times more cpu power in order
to succeed.


> 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.
> >
> >

Regards,
Tamir.
Follow-Ups: References: