Re: Filtering Unregistered Blocks (WAS: small vent)
[In the message entitled "Filtering Unregistered Blocks (WAS: small vent)" on Jun 29, 11:46, "Patrick W. Gilmore" writes:]
At 12:45 PM 6/28/98 PDT, Dave Rand wrote:
This has, in fact, happened before. One of the reasons that the unallocated spaces are listed on the RBL.
This topic comes up every now and then. I've searched the ARIN site and found some very outdated lists (some as old as 1996, but none newer than Feb, 1998). I've searched the archives, but no one seems to have an answer - except you. How do you tell what is and what is not allocated?
Unallocated is (once again) a state of mind. By unallocated, the RBL looks upon the IANA allocation of space, not the ARIN view. So, for example, 2.0.0.0/8 is on the RBL (as is 0.0.0.0/8). We watch for IANA allocation of new blocks, and when they are allocated, remove them from the RBL. Of course, this takes more work, and requires that we watch closely. As an example, AS3259 is currently advertising a bogon. *>i213.102.1.0 207.240.113.165 10 100 0 3847 3259 3259 i
Perhaps you could export just the non-assigned blocks in the RBL? Maybe under a second AS or something? I have no problem with the RBL myself, but some of my customers want a "full table", and won't take an RBL filtered one.
That's not how the RBL works in BGP mode. You can (easily) accept a feed from the RBL, and filter to accept only /8's from the RBL, which will give you the desired information. You are not permitted to redistribute AS7777 routes to your customers (or anyone, for that matter) without express approval and a disclaimer in place, so AS7777 is typically marked as a "no-export" community. The RBL, in BGP mode, is used by route-mapping the addresses listed on the RBL to a specific address. You can, for example, route all traffic to RBL listed hosts to go through a 9600 bps dialup port. Or you can route them to a T1. Or you can route them to the loopback port, which is what most people do. The RBL doesn't filter the BGP table, at all.
I do, however, filter blocks which should not be routed - e.g RFC 1918 - and would like to include the non-assigned blocks. I just can't figure out a way to automate such a process. Especially since the whois servers limit the number of queries. (I'm not complaining, I understand the reasons, I'm just stating a fact.)
You can't automate it, easily. But by using the RBL, you can certainly get the real-time aspect of it handled well. -- Dave Rand dlr@bungi.com http://www.bungi.com
At 12:23 PM 6/29/98 PDT, Dave Rand wrote:
Unallocated is (once again) a state of mind. By unallocated, the RBL looks upon the IANA allocation of space, not the ARIN view. So, for example, 2.0.0.0/8 is on the RBL (as is 0.0.0.0/8). We watch for IANA allocation of new blocks, and when they are allocated, remove them from the RBL. Of course, this takes more work, and requires that we watch closely.
I wonder if there could someday be a way to do this without all the work?
The RBL, in BGP mode, is used by route-mapping the addresses listed on the RBL to a specific address. You can, for example, route all traffic to RBL listed hosts to go through a 9600 bps dialup port. Or you can route them to a T1. Or you can route them to the loopback port, which is what most people do. The RBL doesn't filter the BGP table, at all.
Sorry, I misspoke. I just meant that I some customers have specifically requested that I *not* filter/rate limit/drop/whatever blocks in the RBL. But thank you for the suggestion about taking just the /8s from the RBL. I will definitely look into it.
You can't automate it, easily. But by using the RBL, you can certainly get the real-time aspect of it handled well.
Heh, with the RBL, *I* can automate it - you're the one doing the work! :) For which I thank you and Paul and everyone else profusely. Of course, if anyone with a /8 (e.g. BBN or PSI) gets onto the RBL, I could be in trouble. Would the RBL ever list a /8 just for SPAM? (Again, I am not saying that's wrong - people don't have to take the RBL. I'm just asking to make my filters more effective without pissing off my customers.)
Dave Rand
TTFN, patrick ************************************************************** Patrick W. Gilmore voice: +1-650-482-2840 Director of Operations, CCIE #2983 fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "Tomorrow's Performance.... Today" **************************************************************
participants (2)
-
dlr＠bungi.com -
Patrick W. Gilmore