Re: New Draft Document: De-boganising New Address Blocks
The RIPE NCC has prepared a draft document titled "De-Bogonising New Address Blocks":
That is a misleading title. The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially. However, it will also allow spammers to announce this space and get it through bogon filters. The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes. Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time? --Michael Dillon
On Tue, Feb 24, 2004 at 04:32:46PM +0000, Michael.Dillon@radianz.com wrote:
The RIPE NCC has prepared a draft document titled "De-Bogonising New Address Blocks":
That is a misleading title.
The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially.
However, it will also allow spammers to announce this space and get it through bogon filters.
The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes.
Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time?
Uh, bogon route server, hello? http://www.cymru.com/BGP/bogon-rs.html Tim
On Tue, 24 Feb 2004, Timothy Brown wrote:
On Tue, Feb 24, 2004 at 04:32:46PM +0000, Michael.Dillon@radianz.com wrote:
The RIPE NCC has prepared a draft document titled "De-Bogonising New Address Blocks":
That is a misleading title.
I agree, consindering the block is still a bogon until it has been allocated by RIPE to ISP, but advanced notification is still good. And its especially good that RIRs are actively trying to get involved in things like this.
The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially.
However, it will also allow spammers to announce this space and get it through bogon filters.
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 The actual list of all such RIR unallocated blocks is at: http://www.completewhois.com/bogons/data/bogons-cidr-all.txt Similar list can also be created based on RIR ip statistics file (not right now as they still have serious problems with not listing some legacy blocks, but hopefully RIRs will finish the ERX and fix it all in the next year).
The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes. Yes, 24-36 hours delay exists before new allocations are cleared from bogon list when done in automated way. But I found that < 1% of the blocks are routed within first 24 hours of allocated (in fact 30% are still not routed 2 months after allocated).
Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time?
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.
What we do need is for ISPs and other organizations to urge vendors to implement router software changes for distributed bgp filtering as has been detailed in this draft (already mentioned quite extensively on other threads): http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-01.txt -- William Leibzon Elan Networks william@elan.net
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. 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. 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.
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. It's no more a hack than using a DNS feed; as with any solution, everything depends on your cluefulness during implementation and your awareness of what you're doing to your network. 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. Tim
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
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
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
On Tue, 24 Feb 2004, Timothy Brown wrote: then the message I replied to). 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. 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@elan.net
On 24.02 16:32, Michael.Dillon@radianz.com wrote:
That is a misleading title.
I thought it was to the point and rather cute ;-).
The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially.
This is the status quo, aka best *current* practise.
However, it will also allow spammers to announce this space and get it through bogon filters.
Correct, but only in the absence of more specific filtering. the problem this proposal aims to correct is the increasing number of false positives caused by the apparent *serious* lag in relatively static bogon filtering.
The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes.
Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time?
Personally I think this is a great idea and if we hear from a lot of operators actually willing to take such feeds it may become reality beyond volunteer efforts like the Team CYMRU one. However there are a number of serious issues with something like this, not the least of which are the liability issues in case this goes wrong very dynamically and semi-automatedly. It is certainly something to progress if there is enough interest. However I think the current proposal shold go ahead too because the false positives are a real problem that needs to be addressed quickly. Daniel
Daniel Karrenberg wrote:
Correct, but only in the absence of more specific filtering. the problem this proposal aims to correct is the increasing number of false positives caused by the apparent *serious* lag in relatively static bogon filtering.
Do you think this can be fixed after vendors started putting in bogon lists into their SME and SOHO products and let loose the consultants promoting them as "plug-and-play security for small office"? There is probably hundreds of thousands of these devices out there. Pete
participants (5)
-
Daniel Karrenberg -
Michael.Dillon＠radianz.com -
Petri Helenius -
Timothy Brown -
william(at)elan.net