[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing
On 10 Feb 00, at 14:58, Tamir Zegman wrote:
Hi, Tamir,
> 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
Yes, it may prevent. Simple example. An attacker initiates a lot of
simultaneous negotiations so that responder decides he is "under
attack". It begins to reply with your challenge setting B to very
small value. At that time legitimate peer tries to connect, but gives
up, because his CPU power is not high enough to be wasted for such a
difficult task. He has got a real "Denial of Service". Even if he
tried, a responer's state may get expired by the time he had
finished. The same result. You just put "CPU power threshold" for
everybody who want to connect to responder.
> -
> 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.
It depends on which attack he is trying to perform. You think that
his goal is to exhaust responder's CPU power. I think, that his goal
is to prevent legitimate peer to connect to responder. No doubt, your
proposal saves responder from exhausting his CPU resources, but, in
my opinion, doesn't prevent attacker from performing DoS attack
against legitimate clients with low CPU power - he only needs to
force responder suspect that he is being attacked.
> > 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.
Your approach lies in trying to offload responder and to distribute
load among all the initiators, both honest and malicious. The problem
is that responder gains no knowledge about initiator that
successfully solved his challenge besides "he is powerful enough". In
this light Kanta Matsuura's proposal seems to be more interesting,
because it allows responder to simultaneously perform peer
authentication.
Best regards,
Valera.
> > 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.
> >
[...]
> Regards,
> Tamir.
>
>
References: