source: RIPE may also contain invalid ROUTEs
Hi guys There is a corner case where invalid ROUTE(6) objects may occur in the source: RIPE database. Before NWI-5 a ROUTE(6) object could be created either by the address space holder or the ASN holder. Both had to authorise the creation, but whoever created the object would maintain it. Suppose the ASN holder created an object and maintains it, then the address space holder chooses another ASN to announce the address space. The address space holder can delete the ROUTE(6) object using the Force Delete mechanism(1), if they know about it. But many resource holders still don't know such mechanisms exist. They may instead just create an RPKI ROA for the new announcement and leave the old ROUTE(6) object in the database. AFAIK there isn't yet any alignment mechanism, but it has been talked about recently, and the cleanup proposal under discussion only applies to source: RIPE-NONAUTH (but I'm not suggesting you extend it). Although this is a corner case, it means you can't guarantee all the data in source: RIPE is still authoritative. (1) https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab... cheersdenisco-chair DB-WG
Hi Denis, Can you point us to one example object? Kind regards, Job On Wed, Oct 17, 2018 at 22:23 denis walker via routing-wg < routing-wg@ripe.net> wrote:
Hi guys
There is a corner case where invalid ROUTE(6) objects may occur in the source: RIPE database. Before NWI-5 a ROUTE(6) object could be created either by the address space holder or the ASN holder. Both had to authorise the creation, but whoever created the object would maintain it.
Suppose the ASN holder created an object and maintains it, then the address space holder chooses another ASN to announce the address space. The address space holder can delete the ROUTE(6) object using the Force Delete mechanism(1), if they know about it. But many resource holders still don't know such mechanisms exist. They may instead just create an RPKI ROA for the new announcement and leave the old ROUTE(6) object in the database.
AFAIK there isn't yet any alignment mechanism, but it has been talked about recently, and the cleanup proposal under discussion only applies to source: RIPE-NONAUTH (but I'm not suggesting you extend it). Although this is a corner case, it means you can't guarantee all the data in source: RIPE is still authoritative.
(1) https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab...
cheers denis co-chair DB-WG
Hi Job No I can't. I am suggesting it is 'theoretically' possible. But I'm not in a position to do the analysis to see if there are any such examples. Perhaps the RIPE NCC can figure out a way to check for any such cases. cheersdenis From: Job Snijders <job@instituut.net> To: denis walker <ripedenis@yahoo.co.uk> Cc: RIPE Routing Working Group <routing-wg@ripe.net> Sent: Wednesday, 17 October 2018, 23:18 Subject: Re: [routing-wg] source: RIPE may also contain invalid ROUTEs Hi Denis, Can you point us to one example object? Kind regards, Job On Wed, Oct 17, 2018 at 22:23 denis walker via routing-wg <routing-wg@ripe.net> wrote: Hi guys There is a corner case where invalid ROUTE(6) objects may occur in the source: RIPE database. Before NWI-5 a ROUTE(6) object could be created either by the address space holder or the ASN holder. Both had to authorise the creation, but whoever created the object would maintain it. Suppose the ASN holder created an object and maintains it, then the address space holder chooses another ASN to announce the address space. The address space holder can delete the ROUTE(6) object using the Force Delete mechanism(1), if they know about it. But many resource holders still don't know such mechanisms exist. They may instead just create an RPKI ROA for the new announcement and leave the old ROUTE(6) object in the database. AFAIK there isn't yet any alignment mechanism, but it has been talked about recently, and the cleanup proposal under discussion only applies to source: RIPE-NONAUTH (but I'm not suggesting you extend it). Although this is a corner case, it means you can't guarantee all the data in source: RIPE is still authoritative. (1) https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab... cheersdenisco-chair DB-WG
Hi, On Wed, Oct 17, 2018 at 08:22:54PM +0000, denis walker via routing-wg wrote:
AFAIK there isn't yet any alignment mechanism, but it has been talked about recently, and the cleanup proposal under discussion only applies to source: RIPE-NONAUTH (but I'm not suggesting you extend it). Although this is a corner case, it means you can't guarantee all the data in source: RIPE is still authoritative.
It is still authoritative in the sense of "we know that the owner of the address space authorized creation of the route(6) object". If they decide to have multiple different origins in the RIPE-DB, it's still *authorized* data - and there might be good reason (like preparing a move to a new origin AS, or just having moved and not yet cleaned up, etc). We might want to send the object owner a notification from RIS(?) if a conflicting ROA is detected, but I see no incentive to force-delete these objects. 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
Also consider that just like you can have multiple route(6) objects, you can create multiple ROAs. ROAs can't conflict with each other - they co-exist. Using multiple ROAs is useful in a number of ways: - migrating announcements from AS A to AS B - MOA (either for traffic engineering or ddos mittigation) Kind regards, Job
participants (3)
-
denis walker -
Gert Doering -
Job Snijders