Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
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
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.) 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@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
Hi Denis, On Tue, Oct 17, 2017 at 10:08:56PM +0200, den is via db-wg wrote:
Rob is correct, option 1 has been proposed before and it was opposed.
I am not sure 'opposed' is the correct word, throughout some of these processes trajectories, the lack of feedback proved to be a major obstacle.
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.)
I've never been able to figure out what the original reason was, other than that it was part of rfc2725. I do not know why it was put in RFC 2725. At the time (18 years ago) it probably seemed like a good idea. I cannot come up with reasons that were valid in the last 10 years, nor reasons that are valid now. There is one stubborn myth that if you can create a route object for an (any) origin ASN, that some ASNs will automatically start originating the prefix. I've not found evidence that this actually happens. Even if it did: if I as legitimate owner authorize an ASN to originate my prefix, and they do so, what is the issue? :) I'm sure we can find more myths, but the fact that aut-num authorisation is not required in virtually all other IRRs shows me that this there is no real necessity to do so.
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?
I think we are actually gaining something: we make it easier to correctly administrate resources. Right now We are in the awkward situation where it is easier to create a route object in RADB or NTTCOM than it is to create one in the RIPE DB. It is in everyone's interest to make it easy for RIPE stakeholders to create statements about routes. Kind regards, Job
On Oct 17, 2017, at 4:08 PM, den is via db-wg <db-wg@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@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
Dear Sandra, Thank you for this overview. You have cleared some of the mists of time and I am appreciative for that. It appears that over time, the 'root' of the conceptual model shifted from the AS holder to the IP space holder. Interesting. Kind regards, Job On Wed, Oct 18, 2017 at 07:37:47PM -0400, Sandra Murphy via db-wg wrote:
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.
I think it's about addressing abuse. If there's "bad things coming in", one usually addresses the source IP address, not the source AS. Also, one can move a prefix to another AS, but the ownership would stay the same until returned to RIPE. On Thu, Oct 19, 2017 at 1:54 AM, Job Snijders via db-wg <db-wg@ripe.net> wrote:
Dear Sandra,
Thank you for this overview. You have cleared some of the mists of time and I am appreciative for that.
It appears that over time, the 'root' of the conceptual model shifted from the AS holder to the IP space holder. Interesting.
Kind regards,
Job
On Wed, Oct 18, 2017 at 07:37:47PM -0400, Sandra Murphy via db-wg wrote:
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.
participants (5)
-
den is -
Horváth Ágoston János -
Job Snijders -
Rob Evans -
Sandra Murphy