Folks should take a look at the work Bindview did on the Naptha family of dos attacks. Basicly, they found ways to move up the application stack, consuming CPU, without a serious comitment of resources on the client side. razor.bindview.com/publish/advisories/adv_NAPTHA.html Adam On Wed, Feb 07, 2001 at 02:29:56PM -0400, Adam Back wrote: | | So this is the kind of thing I was talking about -- it just moves | things to the next obvious escalation from which there is no | obvious way to go further down this dead end route of trace, | block, track down and prosecute, etc. | | So what if you couldn't send a packet without revealing a | source address. There are numerous ways to reveal someone | else's source address, which is a real source address, just | not yours. | | I'm not even sure it's a step forward to paint yourself | into a corner where there is no way to fix the induced | escalation of attack sophistication. | | Adam | | On Wed, Feb 07, 2001 at 05:16:13PM +0100, Lars Gaarden wrote: | > | > Andrew Alston wrote: | > | > > Basically, people who claim to be able to stop DDOS/trace DDOS/etc etc I | > > believe are playing on the public, making money out of a situation that | > > unfortunatly has no end in site, due to the fuckups made in the IP | > > protocol by the department of defense when they released the RFC. | > | > Spoofed source-addresses can be (and often are) blocked at the | > access ISP. RFC 2267, Ingress filtering. | > | > DDOS trojans on ISDN/xDSL/Cable home user boxes will have to use | > their real (or at least same subnet) source addresses on datagrams, | > or run the risk of having the traffic dropped silently at the first | > router. | > | > This won't stop DDOS attacks, but it will make it a lot harder to | > mount an attack without exposing many of the DDOS trojans | > participating. -- "It is seldom that liberty of any kind is lost all at once." -Hume