[db-wg] Foreign ROUTE objects in RIPE Database - final decision?

> On Oct 17, 2017, at 4:08 PM, den is via db-wg <db-wg at ripe.net> wrote:
> 
> Hi Colleagues
> 
> Rob is correct, option 1 has been proposed before and it was opposed.
> Whilst neither supporting nor opposing anyone's views let me ask a
> couple of questions. I think these questions need addressing even if
> it is just to quote some historic facts and dismiss them. It's always
> good to document that all angles have been considered in a decision.
> 
> For those with long memories, why was authorisation required from the
> origin ASN and is that reason still valid? (I think it was this point
> that blocked the last attempt to take this option.)

Well, my memory is that the routing registry was designed to express the routing policy of an AS, and all other objects were authorized on the basis of the holder of the AS.

Adding authorization of the prefix holder in addition to the AS was the new authorization step for the route object in RFC2725.

But you should really ask Curtis Villamizar, who did all the heavy lifting of the writing for RFC2725.  I recall sitting wide-eyed as Curtis and Carol Orange discussed thorny routing issues.

There are probably people around from RIPE who needed to do the implementation of the trust model.  They might remember more.

RIPE-120 of Oct 1994 said:

Special Rules in the Routing Registry

Because routes are  originated  by  autonomous  systems  the
autonomous system concerned should be the only one maintain-
ing route objects.  The maintainer of a route object is thus
expected  to  be  the  same as the one of the aut-num object
referenced in its origin attribute. 

RFC1786 of Mar 1995 says:

   Route object update procedures

   Adding a route object will have to be authorised by the maintainer of
   the originating AS. The actual implementation of this is outside the
   scope of this document.  This guarantees that an AS guardian has full
   control over the registration of the routes it announces [11].

where [11] is a pointer to RIPE-120.

—Sandy

P.S.  Carol Orange’s name was on the first two versions of the RFC2725 draft, but disappeared in -02.  I don’t know why.
  
> 
> It has been said several times in this thread that dropping the origin
> auth requirement will bring the RIPE Database IRR into line with other
> IRRs and RPKI. But are we losing something from authorisation by doing
> this and are we dropping to the lowest common denominator?
> 
> cheers
> denis
> 
> co-chair DB WG
> 
> 
> On 17 October 2017 at 17:05, Rob Evans <rhe at nosc.ja.net> wrote:
>> Hi,
>> 
>>> 1) Remove the "origin:" authorization requirement. RIPE is currently the
>>> only RIR that requires this, the current implementation creates data
>>> concurrency issues across Internet databases by requiring the creation of
>>> duplicate autnums.
>>> 
>>> 2) Flag "route:" objects for non-RIPE-managed space with "source:
>>> RIPE-NONAUTH" to identify non-authoritative data.
>> 
>> 
>> I support both of those.  I’ll observe that there have been attempts to do
>> (1) in the past that have floundered.
>> 
>>> 3) Consider possible, simple options to allow non RIPE resource
>>> holders to 'approve' (if not authorise) the creation of a foreign
>>> ROUTE object.
>> 
>> 
>> I wouldn’t want to lose the ability to make progress on (1) and (2) because
>> we end up getting bogged down in the details of (3), which is what I fear
>> will happen, so I’d put something like this on the back burner for now.
>> 
>> Cheers,
>> Rob