[53142] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: ICANN Targets DDoS Attacks

daemon@ATHENA.MIT.EDU (Alex Bligh)
Fri Nov 1 12:46:28 2002

Date: Fri, 01 Nov 2002 17:45:03 -0000
From: Alex Bligh <alex@alex.org.uk>
Reply-To: Alex Bligh <alex@alex.org.uk>
To: "Stephen J. Wilcox" <steve@telecomplete.co.uk>,
	Jeff Shultz <jeffshul@wvi.com>
Cc: nanog@nanog.org, Alex Bligh <alex@alex.org.uk>
In-Reply-To: <Pine.LNX.4.21.0210292110410.1975-100000@MrServer>
Errors-To: owner-nanog-outgoing@merit.edu




--On 29 October 2002 21:11 +0000 "Stephen J. Wilcox" 
<steve@telecomplete.co.uk> wrote:

> As they say, if you dont set the rate limit too low then you wont
> encounter drops under normal operation.

It would be useful if [vendor-du-jour] implemented rate-limiting
by hased corresponding IP address.

IE:
 hash=gethash(source);
 if (!hash) {hash=gethash(dest)}
 if (hash) ratelimiton(bucket(hash);

That way you could (on transit interfaces) specify a paltry limit
of (say) 10kb/s of ICMP (per (hashed) source/destination), even
when there was 'naturally' hundreds of Mb/s of ICMP flowing
through the interface in a non DDoS environment. And if
an IP gets DDoS'd (or sources a DDoS), the ratelimit would
only affect that IP (oh, and any hash equivalents) only.
As, for these purposes, dropping large numbers of relatively
inactive hash entries wouldn't be painful, I would have thought
this would be unlikely to suffer from the self-similarity
properties that made Netflow hard - but perhaps not.

Alex


home help back first fref pref prev next nref lref last post