This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] RE: Hierarchical authorisation failed, request forwarded to maintainer ???
- Previous message (by thread): [db-wg] RE: Hierarchical authorisation failed, request forwarded to maintainer ???
- Next message (by thread): [db-wg] Re: Hierarchical authorisation failed, request forwarded to maintaine r ???
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Engin Gunduz
engin at ripe.net
Tue Nov 5 14:48:09 CET 2002
Hi Christian, On 2002-11-05 11:46:35 +0100, Christian Rasmussen wrote: > Hi Engin, > > Yes, I understand that the "old ISP" can authorize the new ISP by adding the > maintainer of the new ISP as a MNT-ROUTES in the route object. But this > actually means that if the current should ISP refuse for some reason to > either delete the route object or add another ISP as MNT-ROUTES then the end > user doesn't have too many options!... The idea of PI blocks should be that > they are independent of the provider which doesn't exactly seem to be the > case here. Unfortunately the RFC does not distinguish between PI and PA space for route object creations. My personal opinion is that the owner of the IP space (thus the owner of the inetnum object) must have absolute control over it, including route objects in it. So even in the existence of other encompassing route objects, inetnum object must be taken into account. However this is not the RFC specifies. On the other hand, RFCs are not set into stone, and they can be changed (or rather, obsoleted by newer RFCs). Other than that, there might be another solution: the "reclaim" attribute. From the RFC2725, section 9.5: -------------------------------------- 9.5 reclaim and no-reclaim attributes A reclaim attribute is needed in as-block, inetnum and route objects. The reclaim attribute allows a control to be retained over more specific AS, IP address or route space by allowing modify and delete privileges regardless of the mnt-by in the object itself. The reclaim attribute provides the means to enforce address lending. It allows cleanup in cases where entities cease to exist or as a last presort means to correct errors such as parties locking themselves out of access to their own objects. To specify all more specific objects the reclaim attribute value should be "ALL". To allow finer control a set of prefixes can be specified. [...] -------------------------------------- This attribute and functionality is not implemented in RIPE RR, as it is listed as "non-core" functionality in the RFC. I think, even if it was considered for 'address lending' cases, it might be useful for the case you mention. Regards, Engin Gunduz RIPE NCC Database Group > In situations where modifying/adding route objects are relevant it means > that a customer is changing/getting another provider, in such situations its > not always in the "old ISP"'s interest to speed up the process. > > I understand that the current implementation follows the relevant RFC, but > maybe this should be reviewed. > > > Med venlig hilsen/Best regards > > Christian Rasmussen > Hosting manager, jay.net a/s > > Frederiksgade 7, 2., 1265 København K., Denmark > > Email: noc at jay.net > Personal email: chr at corp.jay.net > Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 > > Produkter / Products: > http://hosting.jay.net > > > -----Original Message----- > > From: db-wg-admin at ripe.net [mailto:db-wg-admin at ripe.net]On Behalf > > Of Engin Gunduz > > Sent: 5. november 2002 11:06 > > To: Christian Rasmussen > > Cc: Harald.Singer at tesion.de; Ripe db-wg > > Subject: Re: [db-wg] RE: Hierarchical authorisation failed, > > request forwarded to maintainer ??? > > > > > > Hi Christian, > > > > On 2002-11-05 10:49:59 +0100, Christian Rasmussen wrote: > > > Hi Harald, > > > > > > I have recently had the same problem, just with a PA block. I > > solved it by > > > asking my customer to have Ripe insert our maintainer as > > MNT-ROUTES, then > > > our customer asked their current ISP to delete their route > > object, hereafter > > > I could create our route object. > > > > > > It would have been preferable if we could have added our route > > object, then > > > after we had verified everything was working then we could have > > the route > > > object for the previous ISP deleted. I have a ticket at Ripe > > asking how to > > > solve this problem, but maybe someone on the list has a suggestion? > > > > The solution could be to ask the previous ISP to modify the "old" > > route object to add a mnt-routes attribute that lists your > > mntner name. This will allow you to create exact match and less > > specific route objects. > > > > > > > > Looking at: > > > > > > http://www.ripe.net/ripencc/faq/database/route-creation-checks.html > > > > > > it seems that the reason for the "Hierarchical authorisation > > failed" is that > > > when a route object exists and a second is beeing created, the > > first one has > > > to authorize the second.. Im not sure I understand the reason > > for this...? > > > > This is what the RFC that RIPE Routing Registry implements says. > > It's RFC2725, Routing Policy System Security > > (ftp://ftp.ripe.net/rfc/rfc2725.txt). > > > > Best regards, > > > > Engin Gunduz > > RIPE NCC Database Group > > > > > I think it would make sense if it was only the enduser of a > > PA/PI block who > > > could authorize the creation of route objects by adding > > MNT-ROUTES for each > > > upstream provider. > > > > > > Med venlig hilsen/Best regards > > > > > > Christian Rasmussen > > > Hosting manager, jay.net a/s > > > > > > Frederiksgade 7, 2., 1265 København K., Denmark > > > > > > Email: noc at jay.net > > > Personal email: chr at corp.jay.net > > > Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 > > > > > > Produkter / Products: > > > http://hosting.jay.net > > > > > > > -----Original Message----- > > > > From: db-wg-admin at ripe.net [mailto:db-wg-admin at ripe.net]On Behalf Of > > > > Harald.Singer at tesion.de > > > > Sent: 4. november 2002 17:59 > > > > To: db-wg at ripe.net > > > > Subject: Hierarchical authorisation failed, request forwarded to > > > > maintainer ??? > > > > > > > > > > > > Hello, > > > > > > > > i have the problem to create a route-object for a customer of me. The > > > > customer will transfer his PI-Network (192.109.176.0/24, I´m > > CNSPLUS-MNT) > > > > from another ISP into my AS. And of course a > > > > mnt-routes:CNSPLUS-MNT exists. > > > > I need to create the new route-object, but i get the error: > > "Hierarchical > > > > authorisation failed, request forwarded to maintainer." I think I > > > > should be > > > > able to create such an object without assistance from another ISP. > > > > > > > > - As the ISP and I are using Crypt-PW I don´t want to send a > > mail with my > > > > password to this ISP (like the proposal from Daniel in this WG). > > > > > > > > - Some time ago i was able to create such objects without any > > assistance, > > > > what was the reason to change this behaviour? > > > > > > > > - The discussion some weeks ago doesn´t have any hints for a > > > > solution, or i > > > > missed it. > > > > > > > > - Do you have any proposal to create the object? > > > > > > > > Regards > > > > > > > > Harald > > > > > > > > -- > > > > Harald Singer Telefon: +49 (0)711/2021-847 > > > > tesion )) Telekommunikation Telefax: +49 (0)711/2021-93-847 > > > > Systemingenieur / CCIE #7326 Mobil: +49 (0)178/2021-847 > > > > Kriegsbergstrasse 11 Mail: harald.singer at tesion.de > > > > D-70174 Stuttgart Web: http://www.tesion.de > > > > > >
- Previous message (by thread): [db-wg] RE: Hierarchical authorisation failed, request forwarded to maintainer ???
- Next message (by thread): [db-wg] Re: Hierarchical authorisation failed, request forwarded to maintaine r ???
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]