Force-delete of route object not possible as aut-num resource holder
Hi all, RIPE NCC has assigned me an ASN a couple of years ago. During some routine checks I noticed a few route objects with my ASN in it which were created long before the ASN got assigned to me. When trying to force-delete these objects I was unable to. After contacting RIPE NCC this is apparently by design, and RIPE NCC was unable to delete them either because the route objects were protected by a valid maintainer. They suggested I contact the original creator of the objects (which I couldn't, the email bounced), or contact the inetnum resource holder and ask them to (force) delete the route objects. I find it odd that as ASN resource holder I am unable to force-delete objects referencing the ASN that is assigned to me. I'm apparently not the only one. From what I've been told requests from ASN resource holders to delete route objects referencing their ASN pop up regularly in RIPE NCC support. I think this is something that can be improved. I suggest implementing the option to force-delete a route(6) object as ASN resource holder. This saves both the resource holder and RIPE NCC valuable time. Regards, Wessel
I think this is something that can be improved. I suggest implementing the option to force-delete a route(6) object as ASN resource holder. This saves both the resource holder and RIPE NCC valuable time.
Wessel Sandkuijl wrote on 20/08/2024 12:51: there's definitely an issue here, but I wonder if the authorisation model is opened up a bit, whether that would open up a can of worms (e.g. if you can auth a delete, why shouldn't you be able auth a create?). Would someone from the RIPE NCC be able to provide some suggestions about how this situation could be addressed? Nick
On Tue, Aug 20, 2024 at 01:11:40PM +0100, Nick Hilliard wrote:
I think this is something that can be improved. I suggest implementing the option to force-delete a route(6) object as ASN resource holder. This saves both the resource holder and RIPE NCC valuable time.
Wessel Sandkuijl wrote on 20/08/2024 12:51: there's definitely an issue here, but I wonder if the authorisation model is opened up a bit, whether that would open up a can of worms (e.g. if you can auth a delete, why shouldn't you be able auth a create?).
Would someone from the RIPE NCC be able to provide some suggestions about how this situation could be addressed?
As a start, this RIPE Labs article by Denis may be useful: https://labs.ripe.net/author/denis/out-of-region-route6-and-aut-num-objects-... Best, Piotr -- Piotr Strzyżewski
Hi, On Tue, Aug 20, 2024 at 01:11:40PM +0100, Nick Hilliard wrote:
I think this is something that can be improved. I suggest implementing the option to force-delete a route(6) object as ASN resource holder. This saves both the resource holder and RIPE NCC valuable time.
Wessel Sandkuijl wrote on 20/08/2024 12:51: there's definitely an issue here, but I wonder if the authorisation model is opened up a bit, whether that would open up a can of worms (e.g. if you can auth a delete, why shouldn't you be able auth a create?).
Well, "auth a create" opens the door to hijacks. "auth a delete" would possibly open the door to a DoS attack if a legitime route: object is deleted - but then, such an object would usually be a customer, so why would you do that? I'm not seeing anything obvious how to abuse force-delete route/route6: objects in this scenario, but my imagination is limited. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler 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 Tue, Aug 20, 2024 at 01:11:40PM +0100, Nick Hilliard wrote:
Wessel Sandkuijl wrote on 20/08/2024 12:51:
I think this is something that can be improved. I suggest implementing the option to force-delete a route(6) object as ASN resource holder. This saves both the resource holder and RIPE NCC valuable time.
there's definitely an issue here, but I wonder if the authorisation model is opened up a bit, whether that would open up a can of worms (e.g. if you can auth a delete, why shouldn't you be able auth a create?).
Would someone from the RIPE NCC be able to provide some suggestions about how this situation could be addressed?
Back in the olden days, creation of a 'route:' required both the prefix holder and the AS holder to 'cosign' the object into existence. This proved to be problematic in situations where the prefix was managed by RIPE NCC, and the origin ASN was managed by (for example) ARIN, in such cases the AS holder didn't have an aut-num & associated mntner object in the RIPE db, and requiring them to create one caused proliferation and duplication of data across RIR IRR databases. Re-evaluation of the route-object authorisation model was kicked off here: https://www.ripe.net/ripe/mail/archives/db-wg/2015-May/004597.html The outcome of this work was that the 'route:' authorization model was modeled similar to how RPKI ROAs are authorized: the prefix owner is the sole authorization controller. I suspect that this change drasticly reduced support burden for RIPE NCC & other RIR staff, at the cost of the odd 'route:' object referencing a random ASN as seems to have happened in Wessel's case. In the IETF work is under way to allow AS holders (such as Wessel) publish attestations about what prefixes they *might* originate, in turn also allowing Relying Parties to figure out what prefixes are considered out-of-scope from the AS holder's perspective (by virtue of not being listed in an SPL) https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-prefixlist-02.html https://www.ietf.org/archive/id/draft-sriram-sidrops-spl-verification-00.htm... I'd be very careful opening up the ability to AS holders to delete random "route:" objects which reference their ASN: such a system can only be made to work for ASNs managed by RIPE NCC and might increase confusion about who can delete what. I am absolutely not in favor of allowing ASN holders to create arbitrary 'route:' objects and favor continuing use of the hierarchical RPKI authorization model. Kind regards, Job
Hi, On 20 Aug 2024, at 14:11, Nick Hilliard <nick@foobar.org> wrote:
I think this is something that can be improved. I suggest implementing the option to force-delete a route(6) object as ASN resource holder. This saves both the resource holder and RIPE NCC valuable time.
Wessel Sandkuijl wrote on 20/08/2024 12:51: there's definitely an issue here, but I wonder if the authorisation model is opened up a bit, whether that would open up a can of worms (e.g. if you can auth a delete, why shouldn't you be able auth a create?).
Would someone from the RIPE NCC be able to provide some suggestions about how this situation could be addressed?
For reference, when creating an RPKI ROA the address space holder can also create ROAs with ASN without the ASN holder's permission. I always read route(6) and ROA data as "the address space holder permits this ASN to announce its space" and realise that the ASN holder might not even be aware of being given this permission. And there is indeed no way to indicate "I don't want to be given this permission" in either DB or RPKI. My view may also be different from other's. I understand that from a "keep the database clean" point of view it is annoying. Whether this is an actual (operational) problem has been argued both ways in the past, and I haven't seen any consensus. I'd love to see a discussion on that here. Cheers, Sander Speaking for myself, and as a long-time community member who understands that community guidance on things like this is important to the RIPE NCC :)
Hi, In the case where the inetnum holder can't be contacted (or is unresponsive?) maybe deletion by the RIPE NCC could be a sensible approach (then there will be a ticket trail). Will any change on this need to run through the PDP...? Cheers, Carlos
Hi Carlos,
In the case where the inetnum holder can't be contacted (or is unresponsive?) maybe deletion by the RIPE NCC could be a sensible approach (then there will be a ticket trail).
Will any change on this need to run through the PDP…?
I’ll leave the answer to that up to the RIPE NCC staff and WG chairs. Cheers, Sander
Hi, On 8/20/24 10:08 PM, Carlos Friaças via db-wg wrote:
In the case where the inetnum holder can't be contacted (or is unresponsive?) maybe deletion by the RIPE NCC could be a sensible approach (then there will be a ticket trail).
This can be extended even to personal contact reference in DB. It's similar issue. Now there is practically no protection against unwanted reference. It may also be just non-updated (historic) records, but if the LIR holding the object does not respond / doesn't care about record accuracy, there are not many ways to defend yourself from personal-object-holder perspective - there is no way to get rid of those references. And during ARC, you don't have to deal with such micro-details. A ticket from the other side is probably a reasonable choice here. And once I tried in the direction of NCC, but without success. Probably the lack of a policy is the reason for this. - Daniel
Hi, Some years ago, someone from ARINland (ab)used our postal address. It took us some weeks to be able to talk with them, so they would fix it. Cheers, Carlos On Tue, 20 Aug 2024, Daniel Suchy via db-wg wrote:
Hi,
On 8/20/24 10:08 PM, Carlos Friaças via db-wg wrote:
In the case where the inetnum holder can't be contacted (or is unresponsive?) maybe deletion by the RIPE NCC could be a sensible approach (then there will be a ticket trail).
This can be extended even to personal contact reference in DB. It's similar issue. Now there is practically no protection against unwanted reference.
It may also be just non-updated (historic) records, but if the LIR holding the object does not respond / doesn't care about record accuracy, there are not many ways to defend yourself from personal-object-holder perspective - there is no way to get rid of those references.
And during ARC, you don't have to deal with such micro-details.
A ticket from the other side is probably a reasonable choice here.
And once I tried in the direction of NCC, but without success. Probably the lack of a policy is the reason for this.
- Daniel ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
On 20/08/2024 22:28, Daniel Suchy via db-wg wrote:
This can be extended even to personal contact reference in DB. It's similar issue. Now there is practically no protection against unwanted reference.
Hi Daniel, for PERSON objects, there is an optional "mnt-ref:" attribute: https://apps.db.ripe.net/docs/RPSL-Object-Types/Descriptions-of-Secondary-Ob... This can be used to restrict who is allowed to refer to that particular PERSON object. -- Ondřej Caletka RIPE NCC
* Sander Steffann
For reference, when creating an RPKI ROA the address space holder can also create ROAs with ASN without the ASN holder's permission. I always read route(6) and ROA data as "the address space holder permits this ASN to announce its space" and realise that the ASN holder might not even be aware of being given this permission. And there is indeed no way to indicate "I don't want to be given this permission" in either DB or RPKI. My view may also be different from other's.
I understand that from a "keep the database clean" point of view it is annoying. Whether this is an actual (operational) problem has been argued both ways in the past, and I haven't seen any consensus. I'd love to see a discussion on that here.
One potential operational problems is relating to the construction of eBGP prefix filters. Say you and I peer, and you use an automated system to periodically generate and load prefix filters into your routers based on route6 objects in the RIPE database with origin:AS<tore>. Now some third party comes along and maliciously or accidentally creates half a million route6 objects for every /48 in their /29 allocation using origin:AS<tore>. Now what happens? Tore
Hi Tore!
Now some third party comes along and maliciously or accidentally creates half a million route6 objects for every /48 in their /29 allocation using origin:AS<tore>. Now what happens?
Very good point :) Sander
Hej, we had such an issue years ago and it was annoying. Perhaps one of these options could be improving the situation. 1. Route objects will be extended with a further mnt-by (or a new mnt-del or so just for deletion) which is automatically set to the mnt-by of the corresponding aut-num and cannot be deleted. So the maintainer of the origin is able to delete the object and the creator of the route object will be notified. 2. like 1 but the object will not be deleted immediately. Moreover the creator will be automatically notified that a deletion was requested. In the mail you have a link to confirm the deletion so it will be deleted immediately and you have a link to decline the deletion with a comment field and the RIPE has to review the case. If the creator don't touch a link the object will be deleted after X days. Perhaps this can help but i don't know if this is too much work or it's like cracking a nut with a sledgehammer :) Best Andi Am 20.08.24 um 13:51 schrieb Wessel Sandkuijl:
Hi all,
RIPE NCC has assigned me an ASN a couple of years ago. During some routine checks I noticed a few route objects with my ASN in it which were created long before the ASN got assigned to me.
When trying to force-delete these objects I was unable to. After contacting RIPE NCC this is apparently by design, and RIPE NCC was unable to delete them either because the route objects were protected by a valid maintainer. They suggested I contact the original creator of the objects (which I couldn't, the email bounced), or contact the inetnum resource holder and ask them to (force) delete the route objects.
I find it odd that as ASN resource holder I am unable to force-delete objects referencing the ASN that is assigned to me. I'm apparently not the only one. From what I've been told requests from ASN resource holders to delete route objects referencing their ASN pop up regularly in RIPE NCC support.
I think this is something that can be improved. I suggest implementing the option to force-delete a route(6) object as ASN resource holder. This saves both the resource holder and RIPE NCC valuable time.
Regards,
Wessel ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-- Mit freundlichem Gruß Artfiles New Media GmbH Andreas Worbs Artfiles New Media GmbH | Wendenstraße 408 | 20537 Hamburg Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 E-Mail: support@artfiles.de | Web: https://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478
participants (11)
-
Andreas Worbs -
Carlos Friaças -
Daniel Suchy -
Gert Doering -
Job Snijders -
Nick Hilliard -
Ondřej Caletka -
Piotr Strzyzewski -
Sander Steffann -
Tore Anderson -
Wessel Sandkuijl