Home page logo

nanog logo nanog mailing list archives

RE: Ethical DDoS drone network
From: David Barak <thegameiam () yahoo com>
Date: Mon, 5 Jan 2009 15:23:39 -0800 (PST)

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: 

--- 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
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
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

-----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> 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"

Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. -
Bandwidth, consulting, e-commerce, hosting, and network
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
Ditto for broken OOO autoresponders and foolish AV software


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]