Hi, On Mon, May 02, 2016 at 02:02:39PM +0000, Erik Bais wrote: > > If yes, I don't think this is a good approach - because if the RADB and > > other operators actually were *interested* in reducing the amount of crap > > in their database, they could cross-check RIPE route:/route6: objects > > already today, without any new API needed. > > If there would be a route object in the RIPE DB, the problem wouldn't exist > would it .. ? > The issue is specifically for NON-RIPE AS numbers with RIPE IP Resources .. > that aren't maintained for route objects in the RIPE DB ...
Well, RPKI ROAs would certainly work for arbitrary ASes - so "RIPE IP resources with non-RIPE AS numbers" have a working technical mechanism today. I'm not exactly sure about non-RIPE AS numbers, but that *should* be doable for route:/route6: objects as well (there's always the "must be authorized by the AS holder" catch, which might get in the way here). > > Evidence shows that they are not interested, even when presented with > > "hey, there is garbage in your database, look at the RIPE DB for the > > correct route: object" nothing happens. > > I don't share the same experience that you have on this with RADB, > I do see that with Savvy for instance ..... Level3 just takes a > month.. but it will be picked up is my current experience.. "A month" is a very very long time in Internet standards. > > Ceterum censeo: RADB must die, and as this proposal will not speed up the > > process, so it's not helping. > That is a bit harsh ... Yeah, it's a bit unfair to single out RADB. "Any IRR DB that is used by people to build BGP filters and at the same time permits arbitrary people to put in arbitrary routing resource records without verification with their home RIR must die." 20 years ago, when the Internet was a place full of friendly people that worked together to the common good, such a open databases had their place and were a good thing. Today, it's highly problematic. People have good intentions and *do* build BGP filters from these heaps of crap, which effectively do nothing to stop hijackers and intentional abusers. [..] > The goal is to limit the options so that spammers can't initiate > hijacks ... So there is a common goal .. I still fail to see why this new technical mechanism is better than the existing mechanism (RPKI, at least, and possibly route/route6 objects), *and* why these database operators would actually *use* them, if they fail to do verification today for the existing and easy cases. OTOH, some evidence of buy-in from L3, RADB, etc. that this is something they are only waiting for and stuff will get implemented quickly afterwards would convince me that it's a good thing :-) Gert Doering -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
