> 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
> bogons.dnsiplists.completewhois.com
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?
> >
> > http://www.cymru.com/BGP/bogon-rs.html
> 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 "168.0.0.0/6" 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.