re-evaluate route-object authorisation model
Dear working group, Yesterday during the birds of a feather session about "cross-registry authorisation" the idea to relax the authorisation requirements for route-object creation was brought up (again). I ask this group to further explore. Today, to create a route-object, BOTH the inetnum mntner, and the autnum mntner need to approve the creation of the route-object. One could argue that it is sufficient to require only authorisation from the inetnum owner to create a route-object. This would simplify the process, especially if the autnum is managed in a non-RIPE RIR. No longer would ARIN autnum owners be required to create a superfluous autnum object in the RIPE database. Questions: - should the authorisation model work differently for RIPE managed space versus non-RIPE managed space? Should we even continue to allow route-objects covering non-RIPE managed space? - should the authorisation model work differently when creating a route-object for RIPE managed space with a non-RIPE managed autnum? If yes, how so? - although in this idea the autnum owner is no longer required to approve /creation/ of a route-object, would it be a good idea to allow the autnum owner to /delete/ any route-object in which their autnum is referenced as origin? - Is RFC 2725 the only reason why the authorisation model was implemented as it was implemented, can someone remember practical reasons for doing it this way? During the BoF it was pointed out that any potential DoS vector already exists today. - ... ? Kind regards, Job
Hi all, Just for a few things to discuss, this was a message Wilfried sent to the routing WG list in 2006 one of the previous times we started to think about this: <https://www.ripe.net/ripe/mail/archives/routing-wg/2006-September/000719.html> Cheers, Rob
Job, I cannot think of a reason why ignoring the aut-num authorization would be bad. (Possibly a failure of imagination... I am not a hacker....) Answers to your questions: On Wed, 13 May 2015 11:24:58 +0200 Job Snijders <job@ntt.net> wrote:
- should the authorisation model work differently for RIPE managed space versus non-RIPE managed space? Should we even continue to allow route-objects covering non-RIPE managed space?
I tend to think having a single authorization model makes more sense. I'm not sure, but there may be organizations that prefer a single place to manage all of their routes and also have space from other regions. Certainly the RIPE database is the best routing database among all the RIRs.
- should the authorisation model work differently when creating a route-object for RIPE managed space with a non-RIPE managed autnum? If yes, how so?
See above.
- although in this idea the autnum owner is no longer required to approve /creation/ of a route-object, would it be a good idea to allow the autnum owner to /delete/ any route-object in which their autnum is referenced as origin?
Seems reasonable to me. Anything to keep the database clean sounds like a good idea. :)
- Is RFC 2725 the only reason why the authorisation model was implemented as it was implemented, can someone remember practical reasons for doing it this way? During the BoF it was pointed out that any potential DoS vector already exists today.
AFAIK, yes. Basically the RIPE Database was migrated from RIPE-181 to RPSL in 2000 or 2001 IIRC, and at that time RPSL auth was adopted roughly based on the RFC. Cheers, -- Shane
On 2015-05-13 11:24, Job Snijders wrote:
Yesterday during the birds of a feather session about "cross-registry authorisation" the idea to relax the authorisation requirements for route-object creation was brought up (again). I ask this group to further explore.
To be fair, there were a total of four alternatives presented, of which the above was one. I had the feeling in the room that all alternatives had supporters as well as opposers. Maybe it'd be fair to explore the other alternatives at the same depth as well? Cheers, Robert
Dear Robert, On Wed, May 13, 2015 at 05:24:34PM +0200, Robert Kisteleki wrote:
On 2015-05-13 11:24, Job Snijders wrote:
Yesterday during the birds of a feather session about "cross-registry authorisation" the idea to relax the authorisation requirements for route-object creation was brought up (again). I ask this group to further explore.
To be fair, there were a total of four alternatives presented, of which the above was one. I had the feeling in the room that all alternatives had supporters as well as opposers. Maybe it'd be fair to explore the other alternatives at the same depth as well?
Yes, that is an excellent idea and I intend to do that. Personally I am very interested in the RDAP approach as I feel that the end result for the community could be a seamless experience when registering non-local-RIR resources. I received feedback from various operators this morning that they would like to be able to manage their resources from all over the global in a single database/service. I transposed that feedback to "Would be nice if you could submit an object to your favorite RIR, which then in the backend routes the objects to the correct space and handles validation" I will not persue my vague 'flat maintainer' approach in favor of RDAP. If an approach turns out to be a dead-end we can always return. I hope Tim can be interested to write down some more details about the RPKI Signature approach, I am very interested in leveraging RPKI for other things then just ROA's, but I suspect Tim will be pre-occupied so we might have to wait a little bit. Kind regards, Job
- should the authorisation model work differently for RIPE managed space versus non-RIPE managed space? Should we even continue to allow route-objects covering non-RIPE managed space?
some folk at euro ixen require route objects in ripe's irr. some folk who get address space from other rirs appear at those euro ixen and wish to peer.
I received feedback from various operators this morning that they would like to be able to manage their resources from all over the global in a single database/service.
i think we already have one randy
On 14/05/2015 00:32, Randy Bush wrote:
- should the authorisation model work differently for RIPE managed space versus non-RIPE managed space? Should we even continue to allow route-objects covering non-RIPE managed space?
some folk at euro ixen require route objects in ripe's irr. some folk who get address space from other rirs appear at those euro ixen and wish to peer.
ixps which build route server configurations using ixp manager can apply arbitrary IRR source tags (or combinations) on a per-customer basis. Nick
some folk at euro ixen require route objects in ripe's irr. some folk who get address space from other rirs appear at those euro ixen and wish to peer.
ixps which build route server configurations using ixp manager can apply arbitrary IRR source tags (or combinations) on a per-customer basis.
yes, and peval() and other tools take an IRR instance list. but i have enough windmills without tilting at this one. you wanna peer with brunhilde, you play by her rules. when i saddle up rosenantes, it is to get all this to be rpki-based origin validation instead. randy
participants (7)
-
denis -
Job Snijders -
Nick Hilliard -
Randy Bush -
Rob Evans -
Robert Kisteleki -
Shane Kerr