Well that was my thoughts exactly. Although I think it is a bit worse then that since the only thing that makes sense to me is to limit legitimate connections. Example a.b.c.d connects and does not return an answer, it connects again and again, still not returning answers. After a set number of failed or not replied to puzzles block all connections from that a.b.c.d but an attacker could create another DOS by spoofing and blocking out legitimate users. Even if they created client software An attacker can still create a DOS of legitimate users by spoofing legitimate users. Hmm, they could use a challenge/response to weed out spoofed connections but that would be like SYN Cookies and then what is the point of the puzzles? On Mon, 14 Feb 2000, Michael B. Rash wrote: > > http://www.rsasecurity.com/rsalabs/staff/ajuels/papers/clientpuzzles.pdf > > So basically RSA seems to think that this technology could be used to help > stop the recent DoS attacks that gained so much media attention, but > either I am not understanding something, or they have made a mistake in > their architecture. > > The technology can be summarized by the following excerpt from the > paper's abstract: > > "...TCP SYN flooding is an example of a connection depletion attack in > which an attacker... <snip>. We introduce a countermeasure > that we refer to as a client puzzle protocol. When a server comes under > attack, it distributes small cryptographic puzzles to clients making > service requests. To complete its request, a client must solve its puzzle > correctly..." > > OK. First of all, "distributes puzzles" implies that the attacking > machine is listening for them in the first place, which most likely it > will not be (the TCP SYN packets would most likely be spoofed > anyway... where do they think they are going to "send the puzzle"?). An > attacking machine simply needs to create a bunch of SYN packets and get > them to the target, who will then begin generating the corresponding > SYN-ACK packets thereby overflowing its connection buffers. That's > it... that is the whole attack. The only advantage in doing something > like the client puzzle protocol would be to limit the number of > *legitimate* connections that a machine could make since the > computationally expensive cryptographic puzzles would start eating lots of > compute cycles if it tried to initiate 10,000 connections. If I'm an > attacker I don't care about legitimate connections... I don't even care if > I see *any* packet return from the target. > > What am I missing? How would the CPP help to prevent DoS attacks? > > (Note of course that we are talking about both a client and server side > modification to make all of this possible in the first place... sounds > like an upcoming product from RSA). > > > --Mike | "...the whole aim of practical politics is > | to keep the populace alarmed (and hence > http://www.math.umd.edu/~mbr | clamorous to be led to safety) by an > | endless series of hobgoblins..." -Mencken > ========================================================================== --"the more you know and understand the more you must know and understand .. knowledge is an unsatiable hunger .. which makes life easier and at the same time harder .... knowledge is a paradox w/ no resolution just a boundless function of human nature .... knowledge is a trap which we embrace and which we run away from .... and in the end the only escape is death .... or maybe not "<grin>-- ========================================================================== -Unite for Java! - http://www.javalobby.org- -This message transmitted on 100% recycled electrons- -Save the whales, Feed the hungry, Free the mallocs- Two cats on a roof, Which one falls off first? The one with the smaller mew.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:04:22 PDT