[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing
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. I don't think the argument that initiator's are already open to
this type of attack is particularly compelling.
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.
Follow-Ups: