New Draft Document: De-boganising New Address Blocks
william(at)elan.net
william at elan.net
Wed Feb 25 05:07:50 UTC 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
> > 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.
--
William Leibzon
Elan Networks
william at elan.net
More information about the NANOG
mailing list