A successful DDOS attack makes actual, valid, requests to the victim host. If it is a web browser, then it makes actual HTTP requests, possibly to the home page, possibly taking a random URL off that home page, in the same domain, and crawling the web site. Simply replying with an Ack isn't going to do squat. There are services out there that can scrub the requests for you. I'm not going to mention the name of the company, but you can research it if you want. Basically, once you sign up traffic normally goes to your site. However, if you are attacked they can use BGP to make your traffic go through their systems, and they scrub the traffic using proprietary methods, and only send clean non-DDOS traffic to your site. There are other things you can do also, if you have the right gear. You can inject a HTTP cookie if you get more than x requests from a particular IP address within y seconds, and then any future requests may get dropped (if you have a complying web browser or HTTP stack on the other end). Or, you can just keep a list of IP's that appear to be infected and drop the traffic if it is from those IP addresses. That's what is behind Cisco's and TippingPoint's, and just about any other decent IPS vendor's "reputation services" or whatever they brand it as. There is a lot you can attempt to do about DDOS, but "simply replying with an Ack" isn't a good one.

I'd say it is more of a problem of incorrectly configured QoS, or hardware with insufficient QoS capabilities, rather than large buffers. Obviously they are not using WRED or other methods, or the thresholds per queue are set too high to activate WRED or other packet drop mechanisms. This results in the buffers always being near 100% full, during periods of congestion. There are a slew of QoS capabilities on different hardware from different manufacturers, and even from the same manufacturer. Cisco, for example, has different QoS capabilities on almost every different piece of hardware they sell. So, you have to be fairly diligent that you are configuring QoS correctly on each individual piece of equipment, many of which will have very different capabilities, to be able to ensure an overall QoS strategy for the whole network.

However, this proper functioning of QoS is, as anyone who really knows QoS, dependent on the proper configuration on every node in the network. If you are talking VoIP, for instance, just one improperly configured node, or even a single link on a node, can break QoS on the entire network (or at least flows going through that node/link). Since most cheap home equipment does not have configurable QoS settings, or at least not to the extend that Internet infrastructure devices do, they may well be part of the problem.

However, as far as the Internet infrastructure devices, if Comcast, or any other ISP, is suffering from "buffer-bloat" on their equipment I'd blame them for not configuring QoS appropriately.

You don't really know what you are talking about, do you? Tail bits? That's going to get you around egress filtering? Also, as pointed out by others, ISP's do ingress filtering, not egress. Egress filtering is what companies that have their own firewalls and/or routers are encouraged to do, but the ISP should be doing ingress filtering also.

Absolutely correct. One of my brothers reached his lifetime limit, and can no longer work in nuclear power plants. It doesn't matter that he could request to avoid "hot" jobs, he just plain simply can't work in an areas where radiation is known to be present.

Oh come on. Not speaking for anyone else or any particular comment, I'd guess 90% of the snotty responses are in jest. One thing we do know, is that snotty responses get the attention of MS, and upset them. So, even if MS does something worthy of praise, the amount of praise would likely never exceed 10-30% of total comments, just because we like poking MS.

There is also the "once bitten twice shy" syndrome. MS has such a horrible past that even when they do something worth of praise it is very difficult to trust that there is not some hidden scheme with ulterior motives. So please understand forgive if us /. snots continue to have fun at the expense of MS.

With the usual caveat of IANAL, I don't believe the voicemail is the property of Buckyballs. They left the voice mail, but they left it on someone else's voice mail system. The recording is owned by the receiver of the message, not the sender. Now if the message were recorded on a tape, CD, or some other device, and the device was sent to the recipient, I suppose an argument could be made that the original recording is copyright Buckyballs, but not a traditional voice mail. There is probably relevant case law on the matter, but again IANAL. As far as the images, that all depends on where they were obtained from. Many, if not most, social networking sites, which I'm assuming these were grabbed from, explicitly state in their terms that you give up copyright on anything that you post. So even the images may, in fact, be non-infringing. So, there are really two issues here. One issue is the original complain in the voice mail, which I don't believe BuckyBalls has a leg to stand on in court. The second issue is the use of copyrighted material (the voice mail and the images of the BuckBalls guy acting like an idiot), which BuckyBalls may or may not have a valid claim on. Don't confuse the comparison of the products with the DCMA take down notice. Cheers!

Yes, he's entitled to the money he makes. Others are not. Speaking of a warped sense of entitlement!

If you are funded by the US government, then I would say no, don't waste any more of your time our our money on this. If you are privately funded, then sure, go ahead.

Sigh. Understand the protocol before commenting, or at least RTFA. There IS an individual key per user. But, there is also a shared key used for broadcast traffic. The problem is that the shared key is not authenticated, so a user who knows the shared key (i.e., anyone with access to the wireless network), can use the shared key to spoof the AP and send messages to other users, and force them to give up or change their unique per-user keys. A "fix" would be getting rid of the shared key for broadcast, but that would require the AP to send a separate "broadcast" packet to each user individually, using their unique per-user key, instead of just one packet.

There is an out-of-band key exchange. It is called a trusted certificate. You know, just like how HTTPS works. This is for WPA2 Enterprise, of which there are many different EAP methods possible, but for which most do include an out of band key exchange (i.e., certificates, or EAP-FAST PAK). In any case, there's also the old DH key exchange, which worked fine for IPsec for years.