[ncc-services-wg] 2016-02 New Policy Proposal (Resource Authentication Key ( RAK ) code for third party authentication)

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/ncc-services-wg/attachments/20160502/77e4ab86/attachment.sig>