|
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
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 [email protected]
|