[102139] in North American Network Operators' Group
Re: Worst Offenders/Active Attackers blacklists
daemon@ATHENA.MIT.EDU (Edward B. DREGER)
Tue Jan 29 13:08:47 2008
Date: Tue, 29 Jan 2008 18:01:32 +0000 (GMT)
From: "Edward B. DREGER" <eddy+public+spam@noc.everquick.net>
To: "Patrick W. Gilmore" <patrick@ianai.net>
cc: nanog list <nanog@nanog.org>
In-Reply-To: <BA679F4E-34DB-47D5-B765-15E4EE455BBE@ianai.net>
Errors-To: owner-nanog@merit.edu
PWG> Date: Tue, 29 Jan 2008 10:02:20 -0500
PWG> From: Patrick W. Gilmore
PWG> I read that, but discounted it. There has been more than one
PWG> single-packet compromise in the past. Not really a good idea to
PWG> let packets through for a while, _then_ decide to stop them. Kinda
PWG> closing the bard door after yada yada yada.
(Apologies for straying from ops into R&D-ish stuff.)
True. IMNSHO, lookups would need to be instantaneous. Kind of like...
routing. The RIB presumably is a very sparse array. What's needed is a
FIB capable of approximately 2^24 routes, yet with only two
destinations: "pass" and "drop".
A naive approach would be a simple sorted array of 2^24 entries.
Assuming IPv4, that's a 64 MB lookup table that can be searched using
good old binary search. Take this as a starting point for something
that definitely is possible.
Said sorted array contains much redundancy. One can do _much_ better
than a primitive sorted array. Uh, the more back-of-the-envelope
calculations I run, the more I believe this is entirely doable.
I'd need to dust off some code I wrote a while back, but I consider
150-clock IPv4 lookups reasonable. IPv6 would be slower by a factor of
four. (Predictions based on profiling performed on Pentium4-targetted
assembly code custom-written for a similar purpose.)
Note that the above is slightly optimistic. It does not account for
blowing out the TLB on every lookup. I'd need to review/profile that
penalty.
RAM use would be the biggest obstacle.
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@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.
