North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: New Draft Document: De-boganising New Address Blocks

  • From: william(at)
  • Date: Tue Feb 24 23:08:52 2004

On Tue, 24 Feb 2004, Timothy Brown wrote:

> > Completewhois bogon ip lists provide data on ip blocks that are not allocated
> > by RIRs to ISPs (rather then just list of /8 blocks not allocated by IANA 
> > to RIRs as for example cymru does). The list can be used for anti-spam 
> > filtering through dns using rbl-like feed at
> >
> As you say, you could use your "bogon ip lists" DNS feed for anti-spam
> purposes, but that wasn't the original subject of this discussion and has
> no relevance here. 
That its not the original subject does not mean it has no relevence as has 
been quickly shown by the first reply to the original message (which was 
then the message I replied to).

> With regards to using your lists for the filtering of
> invalid space, your own service has been proven to be little more than 
> unreliable and incorrect in the case of the hijacked IP blocks.  
If I were you, I'd not listen to rumors spread by certain very unhappy NY
networkadmin group or use the word "proven" when its almost the other way 
around. Not one of the blocks listed can be shown to be wrong and those 
that are suspicious but not easily shown as hijacked or confirmed in that 
way by RIRs are not put in list used for active filtering. 

However, its true I'm little behind on adding new found hijacked blocks to 
the webpage as unless the block is a big problem I prefer to do it together 
with full file about that block including info about real ip block owner
and there is also necessity to wait for answer from that owner. For those 
new blocks, you can check spamhaus zombie list (their files are brief but 
they will list most important data).

In any case, how matters with hijacked ip list are handled is completely 
different then what is done with bogons as creating bogon list is 
completely automated and based only on RIR data.

> Most people appear to trust the Cymru effort for this data. I think tracking 
> the blocks that are allocated by RIRs to ISPs is a little unwieldy at 
> this time, and i'd rather not trust a third party source of this data 
> without some verifiability, which to date, you have not been proven 
> capable of.  Even the RIRs have accuracy problems.
Completewhois publishes data for each day separately and keep archives 
from the beginning feel free to check/verify. Errors do happen from time 
to time, today there was a problem due to data that I got from RIR (first 
problem in two months BTW) which I'm reporting to them as it was almost 
certainly a bug on their side (in general I like to doublecheck the data 
with both whois and statistical files - unfortunetly for legacy blocks as 
already mentioned statistical files are not very reliable at this time and 
this is where most of the errors happen). 

As for using only IANA bogon data - it is good to to filter on engress but
(i.e. spoofed packets) but offers very limited protection against those 
purposely trying to announce/use invalid blocks (with so much data space not
allocated to ISPs within ip block allocated to RIRs, its no more difficult for
bad guy to use ip block in say 70/8 then it is for them to use one in 71/8)

> > > Uh, bogon route server, hello?
> > > 
> > >
> > Unfortunetly this is kind-of a bgp hack and as has been already mentioned 
> > it needs very carefull implemention and if not done right it leads to 
> > leaks like we saw in the today's "" thread on nanog-l. 
> I disagree with the view that it is a hack.
Most others who tried it do not disagree. But using hacks is not necessarily
bad and it maybe the only way to go until correct solution is developed. 
You just have to be carefull to know exactly what you do.

> It's no more a hack than using a DNS feed; 
Serves different purpose and not easily comparable. BGP feed is filtering 
on network level in network core and/or edge. DNS feed is great for 
filtering at the end and at specific service level. Yet another case
also exist for filtering specificaly at edge level through the firewall.

> as with any solution, everything depends on your
> cluefulness during implementation and your awareness of what you're doing
> to your network.  
Correct. But "hacks" tend to require a lot more cluefullness even from 
people who are otherwise quite good at something.

> The reality is that I agree with you when it comes to more features from 
> vendors in order to support involved external filtering changes,
> but the practical side shows that the way to do this today is via a prefix
> update via the routing protocol,  unless you go the route of other providers 
> who have implemented a strict regime for the management of configuations and
> their nightly updates.  Then again, we can debate functions of the control 
> plane and the desire to reduce reliance on external systems in a routing 
> product.
That maybe subject for another list, like IETF IDR.

William Leibzon
Elan Networks
[email protected]