[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing
Chris Trobridge wrote:
> The defence lowers the responder's resource consumption /relative/ to the
> attacker's, by raising the cost to the attacker.
>
> I do share your concerns about the effects on the initiator, although moving
> the initial burden to the initiator does make sense in that it's probably a
> lot harder to spoof a target into initiating a connection than responding to
> one. Given that this is a defence against 'in the path' attackers, I think
> it leaves the initiator open to attacks too. eg Modifying the challenge so
> it is more difficult (or impossible!), or spoofing challenges where none was
> requested.
As I stated in my suggestion, an Initiator must not reply to any challenge it
gets back,
only challenges that do not take too much computational resources (The threshold
should be configurable on the initiator).
There is a trade-off between the level of security that the responder gets and
the burden on the initiator.
> I don't think the argument that initiator's are already open to
> this type of attack is particularly compelling.
What I was referring to was the fact that an attacker that can change packets
can cause negotiations to fail.
I agree that if an attacker has this ability and my suggestion is used, then an
attacker can steal some more cpu cycles from the initiator (but it is still
limited by the number of negotiations that the initiator is conducting). This
kind of attack is considerably less effective than attacks on the responder.
>
> There's also an (Tamir) assumption about the relative costs of operations -
> if you have modular maths hardware then the effect of brute forcing an hash
> search could be far greater on other aspects of performance. It is also
> much harder to make a task moderately tasking enough to deter a foe but not
> inconvenience a legitimate initiator, given the way that processing power is
> increasing.
>
> I think people should consider Ted's (Theodore) comments (philosophy?) about
> defending against DOS.
>
> The main concerns appear to about resource attacks on the IPSEC machine by
> an active attacker who is on the path between the legitimate parties. As
> stated it's very hard to defend this attack other than making it hard for
> the attacker to conceal their location.
>
> Chris
>
> > -----Original Message-----
> > From: Valery Smyslov [mailto:svan@trustworks.com]
> > Sent: 10 February 2000 09:25
> > To: Tamir Zegman
> > Cc: ipsec@lists.tislabs.com
> > Subject: 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.
Best Regards,
Tamir.
References: