Ethical DDoS drone network

BATTLES, TIMOTHY A (TIM), ATTLABS tmbattles at att.com
Mon Jan 5 21:16:33 UTC 2009


 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.





More information about the NANOG mailing list