Suggestion for unallocated IP-Space
Hello Routing-WG, since it's more and more difficult to determine, which IP-space is used correctly in the Routing table, is there any chance to setup an easy-retrievable page (say via HTTP or FTP) to view current unallocated IP-space. We all know martians such as: RFC-1918-space, default, localhost and Multicast Space. But it's very hard to filter correctly on address- space that's currently handed out by the RIRs. If there could be a database run - say in a weekly interval - which could generate the 'empty' space blocks in a list - which could again used to filter against. Any supports for this idea? Regards, Kurt -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Kurt, check out http://www.apnic.net/meetings/13/sigs/routing/index.html - Geoff Huston proposed a mechanism for exactly what you are asking... Action item on me (as Routing SIG chair) to talk to APNIC/ARIN/RIPENCC... Shouldn't be hard to set up a simple system which people can get an eBGP-multihop feed listing the unused addresses. philip -- At 13:41 11/03/2002 +0100, kurt_kayser@gmx.de wrote:
Hello Routing-WG,
since it's more and more difficult to determine, which IP-space is used correctly in the Routing table, is there any chance to setup an easy-retrievable page (say via HTTP or FTP) to view current unallocated IP-space.
We all know martians such as: RFC-1918-space, default, localhost and Multicast Space. But it's very hard to filter correctly on address- space that's currently handed out by the RIRs. If there could be a database run - say in a weekly interval - which could generate the 'empty' space blocks in a list - which could again used to filter against.
Any supports for this idea?
Regards, Kurt
-- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
And we (RIPE NCC) would be happy to set up such a peering point for RIPE administered IP space and coordinate with other RIRs if they would roll out such a service. I feel adding IANA "not allocated" space would not be as reliable as no RIR has control over that information. This service would then not be authoritative. It might still be valuable. Joao At 20:13 +1000 13/3/02, Philip Smith wrote:
Kurt, check out http://www.apnic.net/meetings/13/sigs/routing/index.html - Geoff Huston proposed a mechanism for exactly what you are asking... Action item on me (as Routing SIG chair) to talk to APNIC/ARIN/RIPENCC... Shouldn't be hard to set up a simple system which people can get an eBGP-multihop feed listing the unused addresses.
philip --
--
And we (RIPE NCC) would be happy to set up such a peering point for RIPE administered IP space and coordinate with other RIRs if they would roll out such a service.
thinking about liability may give you some pause
I feel adding IANA "not allocated" space would not be as reliable as no RIR has control over that information. This service would then not be authoritative. It might still be valuable.
mark with differing commuinities randy
At 9:38 -0800 13/3/02, Randy Bush wrote:
And we (RIPE NCC) would be happy to set up such a peering point for RIPE administered IP space and coordinate with other RIRs if they would roll out such a service.
thinking about liability may give you some pause
Good point though there would be a difference between this and an RBL-type list: this list would not be expressing an opinion about whether certain networks are good net-citizens or not, but rather expressing whether a particular block of address space is allocated by an RIR or not, and it would be generated from the authoritative source for such information (which is why I think I would not publish data for which I am not authoritative). Yes, I do understand that making an error in the publication of such data might have implications and that we have to pay attention to security (at least authentication).
I feel adding IANA "not allocated" space would not be as reliable as no RIR has control over that information. This service would then not be authoritative. It might still be valuable.
mark with differing commuinities
Would do. Also, any other ideas anyone might have would be great. Joao
randy
--
On Thu, 14 Mar 2002, Joao Luis Silva Damas wrote:
At 9:38 -0800 13/3/02, Randy Bush wrote:
And we (RIPE NCC) would be happy to set up such a peering point for RIPE administered IP space and coordinate with other RIRs if they would roll out such a service.
thinking about liability may give you some pause
Good point though there would be a difference between this and an RBL-type list:
this list would not be expressing an opinion about whether certain networks are good net-citizens or not, but rather expressing whether a particular block of address space is allocated by an RIR or not, and it would be generated from the authoritative source for such information (which is why I think I would not publish data for which I am not authoritative).
In this case, the list should include the addresses that the report covers ("From 193/8, 194/8, ... under control of the RIPE NCC, these are the block that have been allocated: 193.0.0.0/22, ...).
Yes, I do understand that making an error in the publication of such data might have implications and that we have to pay attention to security (at least authentication).
I feel adding IANA "not allocated" space would not be as reliable as no RIR has control over that information. This service would then not be authoritative. It might still be valuable.
mark with differing commuinities
Would do. Also, any other ideas anyone might have would be great.
The opposite list (= everything unallocated but under NCC control), with links to the appropriate RIS queries. If one sees an unallocated address then 1 click will allow you to find out who is announcing it. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)
On 2002-03-14T12:34:41, "Henk Uijterwaal (RIPE-NCC)" <henk@ripe.net> said:
In this case, the list should include the addresses that the report covers ("From 193/8, 194/8, ... under control of the RIPE NCC, these are the block that have been allocated: 193.0.0.0/22, ...).
Well, the general idea is pretty simple and straightforward to implement; you just build up the inverted list of allocated address space. If the RIR is concerned about liabilities, this could easily be provided by a 3rd party. One wonders whether the same list for _assigned_ address space might also be helpful; those filter would obviously have to be updated more regularly or only available in a semi-push fasion like via a eBGP feed in the first place. At least from a RIR perspective, it might provide valuable incentives to at least register used address space correctly. I have been considering issues like these a while ago when I was interested in building a distributed IDS consolidation system with online updated filters. (Similiar to what dshield.org is building up now) But then I got caught up doing something else entirely ;-)
Would do. Also, any other ideas anyone might have would be great. The opposite list (= everything unallocated but under NCC control), with links to the appropriate RIS queries. If one sees an unallocated address then 1 click will allow you to find out who is announcing it.
That would be helpful. Sincerely, Lars Marowsky-Br�e <lmb@suse.de> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl
thinking about liability may give you some pause Good point though there would be a difference between this and an RBL-type list:
understood. good-sounding (i am not a lawyer) defense, won't prevent you from being sued. but my culture, i.e. arin, has more silliness in that area than yours. randy
At 6:17 -0800 14/3/02, Randy Bush wrote:
thinking about liability may give you some pause Good point though there would be a difference between this and an RBL-type list:
understood. good-sounding (i am not a lawyer) defense, won't prevent you from being sued.
Nothing will prevent anyone from being sued. A different matter is which party prevails. I still keep the liability issue in mind, but coming back to the main thread: how useful is this? Are there any particularly desirable properties on how the service would be delivered that have not come up yet? Joao
but my culture, i.e. arin, has more silliness in that area than yours.
randy
--
Hi, On Thu, Mar 14, 2002 at 04:41:54PM +0100, Joao Luis Silva Damas wrote:
how useful is this? Are there any particularly desirable properties on how the service would be delivered that have not come up yet?
I can't really see the benefit of using BGP for this, as we'd would want to create a filter-list/prefix-list from the data, and not use it to do any kind of "live blackholing". We would prefer something either in the whois database or on the RIPE web site. Once per day, a script generates the filter lists, does some sanity checks, and distributes onto the routers... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 73385 (73032) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
At 04:57 PM 14/03/02 +0100, Gert Doering wrote:
Hi,
On Thu, Mar 14, 2002 at 04:41:54PM +0100, Joao Luis Silva Damas wrote:
how useful is this? Are there any particularly desirable properties on how the service would be delivered that have not come up yet?
I can't really see the benefit of using BGP for this, as we'd would want to create a filter-list/prefix-list from the data, and not use it to do any kind of "live blackholing".
We would prefer something either in the whois database or on the RIPE web site. Once per day, a script generates the filter lists, does some sanity checks, and distributes onto the routers...
Gert Doering
I tend to agree with Gert, the end goal is more simply facilitated by having the likes of RIPE and ARIN provide these data from the RDBs. Tony Barber WorldCom
On Wed, 13 Mar 2002, Philip Smith wrote:
Kurt, check out http://www.apnic.net/meetings/13/sigs/routing/index.html - Geoff Huston proposed a mechanism for exactly what you are asking... Action item on me (as Routing SIG chair) to talk to APNIC/ARIN/RIPENCC... Shouldn't be hard to set up a simple system which people can get an eBGP-multihop feed listing the unused addresses.
There are two problems from my personal PoV: a) administrative overhead of multiple eBGP feeds. ( I mention this for completeness ) b) Loss of the service in the midst of a DoS attack. With (b), if you are depending on the service to protect yourself from spoofed IP attacks apparently originating from unused space, then an attack focused on the distribution channel (ie, router at each end, or transit in-between) may open you up to the attack you are supposedly protecting yourself against. The distribution channel attack may also take the form of impersonating the RIR end of the eBGB feed, as could happen with any unsecured (e)BGP connection (the information is only as good as the method used to get it). Randy's point about liability is well taken. Any such service would be intended for use as informational only. What you do with such information is your problem, and not that of the Registry. From a technical perspective, providing the same information in RBL-style DNS zones is also doable in addition to/instead of eBGP. Retrieving the information in the first place is simple, deciding how to distribute it is another matter ;) Regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations
On 2002-03-13T18:49:20, Bruce Campbell <bruce.campbell@ripe.net> said:
Kurt, check out http://www.apnic.net/meetings/13/sigs/routing/index.html - Geoff Huston proposed a mechanism for exactly what you are asking... Action item on me (as Routing SIG chair) to talk to APNIC/ARIN/RIPENCC... Shouldn't be hard to set up a simple system which people can get an eBGP-multihop feed listing the unused addresses.
This seems like a perfectly legitimate idea.
a) administrative overhead of multiple eBGP feeds. ( I mention this for completeness )
Ok, not that much of a problem.
b) Loss of the service in the midst of a DoS attack.
With (b), if you are depending on the service to protect yourself from spoofed IP attacks apparently originating from unused space, then an attack focused on the distribution channel (ie, router at each end, or transit in-between) may open you up to the attack you are supposedly protecting yourself against.
Yes. However, if the service was provided for informational purposes only and for example hosted by the RIPE NCC or so, and used widely enough, the attacks _would_ come from an assigned IP address range and I am pretty sure that any sensible ISP will listen if an attack on a RIR originates from his IP space... I know that this doesn't protect much against a DDoS, but then, nothing does. (So far)
The distribution channel attack may also take the form of impersonating the RIR end of the eBGB feed, as could happen with any unsecured (e)BGP connection (the information is only as good as the method used to get it).
Of course. But then, eBGP does offer methods for authentication like MD5 etc.
Randy's point about liability is well taken. Any such service would be intended for use as informational only. What you do with such information is your problem, and not that of the Registry.
Definetely. This should be clearly stated.
From a technical perspective, providing the same information in RBL-style DNS zones is also doable in addition to/instead of eBGP.
In fact, the original MAPS RBL was distributed in both of these manners. Sincerely, Lars Marowsky-Br�e <lmb@kernel.org> -- "I'm extraordinarily patient provided I get my own way in the end." -- Margeret Thatcher
At 18:49 13/03/2002 +0100, Bruce Campbell wrote:
There are two problems from my personal PoV:
a) administrative overhead of multiple eBGP feeds. ( I mention this for completeness )
I'm not clear on this. Administrative overhead in that a feed has to be set up for who ever requests this information? Sure, there might be a scalability issue if all 13000 ASes currently in use out there want the feed...
b) Loss of the service in the midst of a DoS attack.
I don't see why this is relevant. The idea is that the ISP taking the feed would build an access-list of denied networks probably on a daily basis, or however often they consider necessary. Pretty much as some ISPs build their BGP filters from the IRR at the moment. I wouldn't for a second make this a dynamically updated list - so if you lose your feed due to a DOS attack, well, you don't rebuild your filters until you get your feed back.
The distribution channel attack may also take the form of impersonating the RIR end of the eBGB feed, as could happen with any unsecured (e)BGP connection (the information is only as good as the method used to get it).
I'd hope that ISPs are using passwords on their external BGP sessions - if not, this point is a valid concern.
Randy's point about liability is well taken. Any such service would be intended for use as informational only. What you do with such information is your problem, and not that of the Registry.
Ofcourse. The idea is that it is informational service for those who want to use it.
From a technical perspective, providing the same information in RBL-style DNS zones is also doable in addition to/instead of eBGP. Retrieving the information in the first place is simple, deciding how to distribute it is another matter ;)
Please don't suggest going down the path of further overburdening the DNS. Having routing dependant on a higher layer protocol is not too clever. philip --
participants (10)
-
Bruce Campbell -
Gert Doering -
Henk Uijterwaal (RIPE-NCC) -
Joao Luis Silva Damas -
kurt_kayser＠gmx.de -
Lars Marowsky-Bree -
Lars Marowsky-Bree -
Philip Smith -
Randy Bush -
Tony Barber