Re: Suggestion for unallocated IP-Space
Date: Thu, 14 Mar 2002 09:46:43 +1000 From: Philip Smith <pfs@cisco.com>
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.
Hi Philip et al, I was wondering for a while what I should do with this BGP feed of unallocated prefixes ... Now, after Philip has made it clear, why aren't we simply putting those prefixes in the IRRs (e.g. as a route-set, or simply as routes with a specific/reserved origin-AS) and let interested ISPs use their usual (RA)toolset to build filters at their regular schedules ?
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.
I wouldn't like this either, but that's a different story ;-) Cheers CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl@CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---
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.
Hi Philip et al,
I was wondering for a while what I should do with this BGP feed of unallocated prefixes ... Now, after Philip has made it clear, why aren't we simply putting those prefixes in the IRRs (e.g. as a route-set, or simply as routes with a specific/reserved origin-AS) and let interested ISPs use their usual (RA)toolset to build filters at their regular schedules ?
I should pipe up as the presenter of this particular idea at the recent APNIC meeting - what was in my head was that the utility of this is that we currently use a process of: 1. client tells ISP what prefix they intend to announce 2. ISP checks (to some extent or other) that the client can announce prefix 3. ISP alters per-client filter 4. client announces prefix In this sequence the ISP check is normally a process of burrowing around in various whois databases to see what is know about the intended prefixc announcement. This proposal assist in providing the provider ISP with an up to date feed of what address ranges are considered unallocated and therefore should not be routed in a public context. The second location that this is useful is in the inter-provider peering context, where, as pointed out above, an ISP can feed this set of routes into an RA toolset to create an explicit deny filter that can be applied to all external BGP connections, again to ensure that bad (intentional or unintentional) routes dont proliferate. The overall intent of the proposal is that this list of unallocated prefixes is fed outwards to those who want/need to integrate this information into their routing control processes, rather than at present where this information is only available as a consequence of an out of band search with an explicitly named prefix that you want to check. regards, Geoff
At 8:11 +0100 14/3/02, Christian Panigl, ACOnet/VIX/UniVie wrote:
Date: Thu, 14 Mar 2002 09:46:43 +1000 From: Philip Smith <pfs@cisco.com>
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.
Hi Philip et al,
I was wondering for a while what I should do with this BGP feed of unallocated prefixes ... Now, after Philip has made it clear, why aren't we simply putting those prefixes in the IRRs (e.g. as a route-set, or simply as routes with a specific/reserved origin-AS) and let interested ISPs use their usual (RA)toolset to build filters at their regular schedules ?
Also a possibility. If people see value in this we can even do both. I believe some people were thinking about setting a BGP peering with a "zebra" type process and generate the filters from there, using a separate and contained data set. I hope no one would plug this stuff directly into their border routers without performing some sanity checking first. Joao --
participants (3)
-
Christian Panigl, ACOnet/VIX/UniVie -
Geoff Huston -
Joao Luis Silva Damas