Fwd: Re: Digital Island sponsors DoS attempt

Patrick W. Gilmore patrick at ianai.net
Fri Oct 26 20:16:58 UTC 2001


At 02:56 PM 10/26/2001 -0500, Quibell, Marc wrote:

[...]

 >If a vendor uses ping times and hops to determine closest servers, where
 >does it ping from? Each M$ server? And then how does it tell the client or
 >server where to redirect the traffic? If I read the original post right, the
 >pings came from DI. How does this determine the location of off-site
 >servers? Is this the best way to do it and what is the total bandwidth
 >impact on the internet?

While I agree there may be unintended consequences, even to the point of 
poor performance or effectively DoS'ing a site, this is not really 
relevant, or the province of the IETF.  If I feel like using cisco's or 
DI's or Joe-The-Web-Guru's new wiz-bang load-balancer speeder-upper 
performance-improving reliability-enhancer on MY WEB PAGE, then that is MY 
decision.

Period.

And the IETF, IEEE, RFC-editor, NANOG, EFF, PTA, SPCA, or any other 
alphabet organization has nothing to say about it.  (Assuming, of course, I 
am not violating standards, attacking people, etc.)


 >The original poster of this message stated afterwards, offline, he's now up
 >to over 2400 pings in three hours. Add this number of pings to the number of
 >servers and the number of clients being pinged. It grows exponentially. Do
 >you not think that there should be some Official Standards developed to
 >accomodate and support this?

Unfortunately, it *MAY* be that DI is violating that "assuming, of course" 
part above.  I honestly am not sure why they would need to send 2400 pings 
in 3 hours.  But I am also not 100% certain that sending 2400 pings is 
excessive or "wrong".  Suppose the end users on that network asked for 500 
GB of data from 100 DI customers?

Honest, I do not know the answer, and I doubt most people here do 
either.  Without knowing the circumstances on both sides of the connection, 
it is a bit difficult to say "You did a BAAAAAAD thing".  IMHO, of course.


 >Marc

--
TTFN,
patrick




More information about the NANOG mailing list