RIPE DB Route Object fails creation
Dear friendly DB people, here is a problem I don't find easy to solve. Would you assist me in understanding the constraints? Customer has a /22 network 194.76.156.0/22 with the proper inetnum object. The inetnum objects has a mnt-by: IPHH-NOC and mnt-routes: IPHH-NOC. A route object exists but with a different maintainer: route: 194.76.156.0/22 descr: CMELCHERS-QSC-NET descr: via Plusnet origin: AS20676 mnt-by: PLUSNET-NOC <<<---- not IPHH-NOC We are now trying to create an additional route object for a different ASN: route: 194.76.156.0/22 descr: C. Melchers via MEKO-S origin: AS207630 mnt-by: IPHH-NOC <<<--- This is the maintainer in the inetnum object source: RIPE The RIPE DB refuses the update: Create FAILED: [route] 194.76.156.0/24AS207630 route: 194.76.156.0/24 descr: C. Melchers via MEKO-S descr: belongs to 194.76.156.0/22 origin: AS207630 mnt-by: IPHH-NOC source: RIPE ***Error: Authorisation for [route] 194.76.156.0/22AS20676 failed using "mnt-by:" not authenticated by: PLUSNET-NOC So the DB expects the maintainer from the other route object. But I don't understand why the mnt-routes in the inetnum-object doesnt give preference over the maintainer on a different route-object. Anyone who could share their honest opinion? Cheers Sascha
Hi Sascha If there is an existing, exact matching ROUTE object the creation of the new ROUTE object must be authorised by the existing object. There is a flow chart here explaining the sequence of checks:https://www.ripe.net/support/training/material/bgp-operations-and-security-t... If you want to 'replace' the existing ROUTE object the maintainer of the less specific INETNUM allocation object can delete the existing ROUTE object using the authorisation of the allocation object. This is explained here:https://www.ripe.net/manage-ips-and-asns/db/support/managing-route-objects-i... cheersdenis co-chair DB-WG On Thursday, 11 June 2020, 01:31:36 CEST, Sascha E. Pollok via db-wg <db-wg@ripe.net> wrote: Dear friendly DB people, here is a problem I don't find easy to solve. Would you assist me in understanding the constraints? Customer has a /22 network 194.76.156.0/22 with the proper inetnum object. The inetnum objects has a mnt-by: IPHH-NOC and mnt-routes: IPHH-NOC. A route object exists but with a different maintainer: route: 194.76.156.0/22 descr: CMELCHERS-QSC-NET descr: via Plusnet origin: AS20676 mnt-by: PLUSNET-NOC <<<---- not IPHH-NOC We are now trying to create an additional route object for a different ASN: route: 194.76.156.0/22 descr: C. Melchers via MEKO-S origin: AS207630 mnt-by: IPHH-NOC <<<--- This is the maintainer in the inetnum object source: RIPE The RIPE DB refuses the update: Create FAILED: [route] 194.76.156.0/24AS207630 route: 194.76.156.0/24 descr: C. Melchers via MEKO-S descr: belongs to 194.76.156.0/22 origin: AS207630 mnt-by: IPHH-NOC source: RIPE ***Error: Authorisation for [route] 194.76.156.0/22AS20676 failed using "mnt-by:" not authenticated by: PLUSNET-NOC So the DB expects the maintainer from the other route object. But I don't understand why the mnt-routes in the inetnum-object doesnt give preference over the maintainer on a different route-object. Anyone who could share their honest opinion? Cheers Sascha
Hello, On 11/06/2020 03:26, ripedenis--- via db-wg wrote:
If there is an existing, exact matching ROUTE object the creation of the new ROUTE object must be authorised by the existing object. There is a flow chart here explaining the sequence of checks: https://www.ripe.net/support/training/material/bgp-operations-and-security-t...
This comes up a lot, particularly with PI space. It confused the hell out of me when I first had to decipher that flow chart, and I realised recently that I hadn't looked at it for long enough that it had once again fallen out of my head.
***Error: Authorisation for [route] 194.76.156.0/22AS20676 failed using "mnt-by:" not authenticated by: PLUSNET-NOC
Could we reduce the confusion, and/or spread some more clue, by being more specific with this error? e.g. Authorisation for [blah] failed using "mnt-by:" - matching route object already exists - not authenticated by: PLUSNET-NOC Regards, -- Tom
Hi, On Thu, Jun 11, 2020 at 01:28:16PM +0100, Tom Hill via db-wg wrote:
On 11/06/2020 03:26, ripedenis--- via db-wg wrote:
***Error: Authorisation for [route] 194.76.156.0/22AS20676 failed using "mnt-by:" not authenticated by: PLUSNET-NOC
Could we reduce the confusion, and/or spread some more clue, by being more specific with this error? e.g.
Authorisation for [blah] failed using "mnt-by:" - matching route object already exists - not authenticated by: PLUSNET-NOC
And, while at it, can someone enlighten me why this is actually a desirable characteristic? If the owner of the inetnum and the owner of the aut-num agree about the creation of a new route: object, why is the owner of an existing route: object relevant? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 11/06/2020 03:26, ripedenis--- via db-wg wrote:
If there is an existing, exact matching ROUTE object the creation of the new ROUTE object must be authorised by the existing object. There is a flow chart here explaining the sequence of checks: https://www.ripe.net/support/training/material/bgp-operations-and-security-t...
Ah - great pointer. thanks. Denis, do you remember *why* that is the rule? I don't see a lot of benefit to requiring the existing object to authorise the creation of a *new* object, when the new object is authorised by the inetnum (in this case both through mnt-routes: and mnt-by:).
***Error: Authorisation for [route] 194.76.156.0/22AS20676 failed using "mnt-by:" not authenticated by: PLUSNET-NOC
Could we reduce the confusion, and/or spread some more clue, by being more specific with this error? e.g.
Authorisation for [blah] failed using "mnt-by:" - matching route object already exists - not authenticated by: PLUSNET-NOC
Perhaps instead of an error message, the operation that Sasha tried to do should just be allowed? Kind regards, Job
Hi, I have to agree with Job, I don't see any real benefit to requiring the existing route's maintainer's authorization if the creation is authorized by mnt-routes on the inetnum. - Cynthia On Thu, Jun 11, 2020 at 3:30 PM Job Snijders via db-wg <db-wg@ripe.net> wrote:
On 11/06/2020 03:26, ripedenis--- via db-wg wrote:
If there is an existing, exact matching ROUTE object the creation of the new ROUTE object must be authorised by the existing object. There is a flow chart here explaining the sequence of checks:
https://www.ripe.net/support/training/material/bgp-operations-and-security-t...
Ah - great pointer. thanks.
Denis, do you remember *why* that is the rule?
I don't see a lot of benefit to requiring the existing object to authorise the creation of a *new* object, when the new object is authorised by the inetnum (in this case both through mnt-routes: and mnt-by:).
***Error: Authorisation for [route] 194.76.156.0/22AS20676 failed using "mnt-by:" not authenticated by: PLUSNET-NOC
Could we reduce the confusion, and/or spread some more clue, by being more specific with this error? e.g.
Authorisation for [blah] failed using "mnt-by:" - matching route object already exists - not authenticated by: PLUSNET-NOC
Perhaps instead of an error message, the operation that Sasha tried to do should just be allowed?
Kind regards,
Job
I have no idea Job. It has been like this for as long as I can remember, maybe at least the last 20 years since we implemented the RPSL version of the RIPE Database. Tom gave some reasons for it in his reply. The database mechanics simply reflect the policies and practices. There are different options:-error, as it is now-warning that another ROUTE object exists-send notification to existing ROUTE ASN holder-allow creation and do nothing-??? If there is strong feeling that something should be changed or looked at again, maybe you should start a discussion on the best options for these situations on the Routing WG mailing list. The impact of any change is a routing issue. Then come back to DB WG if something needs changing. cheersdenis co-chair DB-WG On Thursday, 11 June 2020, 15:30:46 CEST, Job Snijders via db-wg <db-wg@ripe.net> wrote: On 11/06/2020 03:26, ripedenis--- via db-wg wrote:
If there is an existing, exact matching ROUTE object the creation of the new ROUTE object must be authorised by the existing object. There is a flow chart here explaining the sequence of checks: https://www.ripe.net/support/training/material/bgp-operations-and-security-t...
Ah - great pointer. thanks. Denis, do you remember *why* that is the rule? I don't see a lot of benefit to requiring the existing object to authorise the creation of a *new* object, when the new object is authorised by the inetnum (in this case both through mnt-routes: and mnt-by:).
***Error: Authorisation for [route] 194.76.156.0/22AS20676 failed using "mnt-by:" not authenticated by: PLUSNET-NOC
Could we reduce the confusion, and/or spread some more clue, by being more specific with this error? e.g.
Authorisation for [blah] failed using "mnt-by:" - matching route object already exists - not authenticated by: PLUSNET-NOC
Perhaps instead of an error message, the operation that Sasha tried to do should just be allowed? Kind regards, Job
Denis, do you remember *why* that is the rule?
RFC2725, section 9.9. He says, retiring to a safe distance... :) Cheers, Rob
Hi Rob RFC2725 only defines the mechanism, which we already know as it still works this way (except for the ASN authorisation). But it does not explain 'why' it is done this way. That was probably discussed in the process of writing RFC2725 :) cheersdenis co-chair DB-WG On Thursday, 11 June 2020, 19:08:16 CEST, Rob Evans via db-wg <db-wg@ripe.net> wrote:
Denis, do you remember *why* that is the rule?
RFC2725, section 9.9. He says, retiring to a safe distance... :) Cheers, Rob
Denis, do you remember *why* that is the rule?
RFC2725, section 9.9.
He says, retiring to a safe distance... :)
Heh. Well, first off, the rule specified in the RFC to require authentication via the origin aut-num object has been abolished, so that doesn't apply. Secondly, is it just me that find the RFC to be sorely lacking in justification for *why* the maintainer of an exact matching route object should be used in preference to the inetnum hierarchy maintainers? It just says "this will be used first", not why, neither in section 9.9 nor in appendix C that I can see. Also, the fact that such a "blocking" route object can be "forcefully deleted" (via some "special" operation?) based solely on the inetnum hierarchy maintainers is an indication that this whole matter hasn't been properly thought through and made consistent, and this workaround just sounds like a massive kludge which complicates matters instead of simplifying them. Also, it does not exactly help that the error message you get when trying to add a new route object "could be improved". Regards, - Håvard
Dear Sascha (and Colleagues), The error message that you quote is for a /24 (more specific) route, not the /22 route that you say you're attempting to create. I hope that helps. Kind regards. Pierre. On Thu, Jun 11, 2020 at 1:32 AM Sascha E. Pollok via db-wg <db-wg@ripe.net> wrote:
Dear friendly DB people,
here is a problem I don't find easy to solve. Would you assist me in understanding the constraints?
Customer has a /22 network 194.76.156.0/22 with the proper inetnum object. The inetnum objects has a mnt-by: IPHH-NOC and mnt-routes: IPHH-NOC.
A route object exists but with a different maintainer:
route: 194.76.156.0/22 descr: CMELCHERS-QSC-NET descr: via Plusnet origin: AS20676 mnt-by: PLUSNET-NOC <<<---- not IPHH-NOC
We are now trying to create an additional route object for a different ASN:
route: 194.76.156.0/22 descr: C. Melchers via MEKO-S origin: AS207630 mnt-by: IPHH-NOC <<<--- This is the maintainer in the inetnum object source: RIPE
The RIPE DB refuses the update:
Create FAILED: [route] 194.76.156.0/24AS207630 route: 194.76.156.0/24 descr: C. Melchers via MEKO-S descr: belongs to 194.76.156.0/22 origin: AS207630 mnt-by: IPHH-NOC source: RIPE ***Error: Authorisation for [route] 194.76.156.0/22AS20676 failed using "mnt-by:" not authenticated by: PLUSNET-NOC
So the DB expects the maintainer from the other route object. But I don't understand why the mnt-routes in the inetnum-object doesnt give preference over the maintainer on a different route-object.
Anyone who could share their honest opinion?
Cheers Sascha
participants (9)
-
Cynthia Revström -
Gert Doering -
Havard Eidnes -
Job Snijders -
Pierre Baume -
ripedenis＠yahoo.co.uk -
Rob Evans -
Sascha E. Pollok -
Tom Hill