Ethical DDoS drone network

Mon Jan 5 23:23:39 UTC 2009

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 at att.com> wrote:

> From: BATTLES, TIMOTHY A (TIM), ATTLABS <tmbattles at att.com>
> Subject: RE: Ethical DDoS drone network
> To: "Edward B. DREGER" <eddy+public+spam at noc.everquick.net>, nanog at 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 at noc.everquick.net] 
> Sent: Monday, January 05, 2009 12:03 PM
> To: nanog at 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 at brics.com -*- jfconmaapaq at intc.net -*-
> sam at everquick.net
> Sending mail to spambait addresses is a great way to get
> blocked.
> Ditto for broken OOO autoresponders and foolish AV software
> backscatter.