In my opinion, the real thing you can puzzle out of this kind of testing is the occasional hidden dependency. I've seen ultra-robust servers fail because a performance monitoring application living on them was timing out in a remote query, and I've also seen devices fail well below their expected load because they were using multiple layers of encapsulation (IP over MPLS over IP over Ethernet over MPLS over Frame-Relay ...) and one of the hidden middle-layers was badly optimized. The advantage of performing this DDoS-style load testing on yourself is that *you can turn it off once you experience the failure* and then go figure out why it broke when it did. This is a lot more pleasant than trying to figure it out at 2:30 in the morning with insufficient coffee. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com --- On Mon, 1/5/09, BATTLES, TIMOTHY A (TIM), ATTLABS <tmbattles@att.com> wrote:
From: BATTLES, TIMOTHY A (TIM), ATTLABS <tmbattles@att.com> Subject: RE: Ethical DDoS drone network To: "Edward B. DREGER" <eddy+public+spam@noc.everquick.net>, nanog@merit.edu Date: Monday, January 5, 2009, 4:16 PM True, real world events differ, but so do denial of service attacks. Distribution in the network, PPS, BPS, Packet Type, Packet Size, etc.. Etc.. Etc.. So really I don't get the point either in staging a real life do it yourself test. So, you put pieces of your network in jeopardy night after night during maintenance windows to determine if what?? Your vulnerable to DDOS? We all know we are, it's just a question of what type and how much right? So we identify our choke points. We all know them. We look at the vendor data on how much PPS it can handle and quickly dismiss that. So what's the next step? Put the device that IS the choke point and pump it full of all different flavors until it fails. No harm no foul an now we have data regarding how much and what takes the device out. If the network is scaled, well we now know that we have x amount of devices that can fail if the DDOS goes X PPS with Y packet types. What I don't get is what you would be doing trying to accomplish this on a production network. Worse case is you break something. Best case is you don't. So if best case scenario is reach, what have you learned? Nothing! So what do you do next ramp it up? Seems silly.
-----Original Message----- From: Edward B. DREGER [mailto:eddy+public+spam@noc.everquick.net] Sent: Monday, January 05, 2009 12:03 PM To: nanog@merit.edu Subject: RE: Ethical DDoS drone network
TAB> Date: Mon, 5 Jan 2009 11:54:06 -0500 TAB> From: "BATTLES, TIMOTHY A (TIM), ATTLABS"
TAB> assuming your somewhat scaled, I would think this could all be done TAB> in the lab.
And end up with a network that works in the lab. :-)
- bw * delay - effects of flow caching, where applicable - jitter (esp. under load) - packet dups and loss (esp. under load) - packet reordering and assiciated side-effects - upstream/sidestream throughput (esp. under load)
No, reality is far more complex. Some things do not lend themselves to _a priori_ models, nor even "TFAR" generalizations.
Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.