| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
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 |