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 --