RIPE 92 Routing Working Group Minutes

Date: Wednesday, 20 May 2026, 11:00-12:30 (UTC+1)

Chairs: Ignas Bagdonas, Sebastian Becker, Ben Cartwright-Cox

Scribe: Ties de Kock

Intro/Opener

Sebastian Becker, Ignas Bagdonas, Ben Cartwright-Cox

The presentation is available at:

https://ripe92.ripe.net/programme/meeting-plan/sessions/87/VNMFNM/

Ben Cartwright-Cox opened the session and welcomed participants to the Routing

Working Group. He noted that Ignas Bagdonas was attending remotely, and that the

session would be chaired by Ben Cartwright-Cox and Sebastian Becker.

The agenda contained three RPKI-related presentations: two from the RIPE NCC on

delegated RPKI CAs and ASPA, and another talk by Job Snijders on unusual RPKI

propagation behaviour.

Non-functional Delegated RPKI CAs

Bart Bakker, RIPE NCC

The presentation is available at:

https://ripe92.ripe.net/programme/meeting-plan/sessions/87/XPYQWF/

Bart Bakker started his presentation by describing the policy 2025-02. This policy aims to clean up the RPKI ecosystem and reduce the burden on validators caused by delegated Certification Authorities (CAs) whose repositories are unavailable or consistently time out.

Bart first explained the architecture of delegated CAs and the benefits and downsides of running your own repository, as well as the differing uptime requirements on the delegated CA and on repositories. This was followed by what is monitored to implement this policy, and an explanation of how the implementation uses Canonical Cache Representation (CCR) objects.

The RIPE NCC will initially perform revocations manually to reduce development work. Its goal is to have all CAs operational and to work with the delegated CA operators to make the ecosystem better.

Job Snijders, BSD, asked whether the rumours were true that operators whose delegated CA is revoked under the policy have to buy cake for others. Bart replied that this was not in the policy, but that the rumour was true.

Tim Bruijnzeels, RIPE NCC, added that the policy required changes to the terms and conditions that would come into effect on 8 June 2026, and the RIPE NCC would start counting the 90-day period before revocation after that.

Tom Strickx, Cloudflare, asked whether Job Snijders and others were monitoring validator latency and availability for validation and wondered if the operational impact of revoking non-functional CAs could be measured.

Job Snijders, BSD, replied that he hoped that Bart could do the talk. There is an intuition that if a CA breaks, it usually breaks forever, but Job said he had not analysed the failure patterns or whether operators recreate CAs after revocation. Job called this a to-do item for Bart.

Six Months of ASPA

Tim Bruijnzeels, RIPE NCC

The presentation is available at: https://ripe92.ripe.net/programme/meeting-plan/sessions/87/KBUQLT/

Tim Bruijnzeels presented the effects of ASPA after being available on the RPKI Dashboard for six months. Tim began with an explanation of ASPA, or Autonomous System Provider Authorisation objects, and followed this by explaining valley-free routing and how ASPA verification detected violations of the policy expressed in the ASPA objects for the ASNs on the path.

ASPA uptake was very slow at first, grew when it became available in the Krill UI, and accelerated when it was available in the RIPE NCC and ARIN hosted CAs. He estimated that around 3% of ASNs registered in the RIPE NCC region had ASPA objects.

To estimate how many paths these cover, Tim analysed BGP data, focusing on the unique paths leading to a provider-free network (AS0 ASPA), and evaluated these paths as being customer paths. He found ~700k unique paths, of which 93.7% were not covered by ASPA, 0.2% were fully covered by ASPA records, 5.5% were unknown (at least one relationship is covered and valid), and 0.5% were invalid.

This led to a discussion about whether the RIPE NCC should suggest providers to users. Tim noted that previous discussions had revealed two opposing views. One view was that provider suggestions should not be made because of the risk of false positives. The other was that suggestions would help prevent users from forgetting to add providers. Tim said that he favoured providing some form of guidance, but cautioned that any such feature should be implemented carefully, particularly within the RPKI Dashboard.

Silvan Gebhardt, Openfactory Group, commented on the role of AS0 ASPAs. He said that he had recently observed hijacks involving route objects and ROAs associated with legacy address space. When assisting customers with ASPA deployment, he also encourages them to publish AS0 ASPAs for unused ASNs and warns them that doing so may affect measurement data.

Tim asked whether such ASNs should appear in AS paths within [the Default-Free Zone].

Mick O'Donovan, Asiera, asked about providers that are only active intermittently, referring to an example on slide 12. He noted that, in the research and education community, it is common to have connections to other NRENs that may become providers through either automated or manual processes, even though they are not continuously active. He asked when such a provider should be included in an ASPA record: whether it should always be listed as a potential provider or only when it is actively being used.

Tim responded that the answer depends on the specific operational situation. He said that the ASPA record should be in place before the provider relationship becomes active. If the provider can be used at any time, or serves as a backup provider, then it should be included in the ASPA record at all times.

Mick noted the countervailing risk that listing a provider before active use could make path spoofing easier. Tim said that ASPA does not protect in situations where people spoof the path, as you need to look at BGPsec for that. Yet this makes constructing a valid path harder, as it depends on how many people sign their paths.

Ben Cartwright-Cox read a question from Antoin Verschuren, Liberty Global. Antoin noted that some networks use AS0 ASPAs while they are not yet connected to an upstream provider in order to protect their ASN from misuse during the network deployment phase. He suggested that some of the invalid ASPA results discussed in the presentation could be caused by this practice and asked what Tim would recommend for networks in this situation.

Tim said that he might not be the most qualified to answer that. Ben Cartwright-Cox added that AS0 is the right answer. Tim concluded that if you do not have a provider yet, AS0 would not be a false statement, but he was not certain this was a best practice.

Antonis Chariton, Cisco, commented that he operates AS4492, which is invalid on purpose. This AS has been intentionally ASPA-invalid since around January. This AS should not appear in paths. Researchers and operators can use it to check whether ASPA validation is working.

Maria Matejka, BIRD, commented that the discussion highlighted an issue that had also been raised earlier in the week. Referring to a diagram shown during the presentation, she noted that AS7 does not validate the path beginning with AS7, but rather the path beginning with AS2. She explained that validation takes place on ingress, before a router prepends its own AS number.

Maria said that she had proposed clarifying this point in the draft, but that the suggested change had not been accepted. She argued that the draft lacks sufficient anchoring in some places and that the algorithm is described in reverse order. In her view, the explanation would be clearer if it were presented from the opposite perspective.

Alexander Azimov, Yandex, asked whether Tim had analysed whether there are common patterns in the invalid paths. Tim said he had not done this yet. Tim then shared that, like

Maria, he also had an off-by-one bug in his implementation because of prepends. Tim did not look at the rest of the data yet.

Tom Strickx, Cloudflare, said that Cloudflare intended to advertise ASPA-invalid routes and add them to isbgpsafeyet.com to gather validation statistics. He then raised the case of having AS4 but not actively using it. Tom suggested that, if an AS has an active peering session but is not a provider at that point in time, the network could use the Only-to-Customer (OTC) attribute on its prefixes. This can help prevent some of the leaks that can occur. That could be a recommendation for NRENs. When the peer becomes a provider, you remove the OTC attribute.

Ondřej Filip, CZ.NIC, warned against the rapid adoption of ASPA validation. CZ.NIC is an early adopter and has signed ASPA records. One of their peers exported their route without CZ.NIC being aware. Unfortunately, this route was the best path for the upstream AS for the RIPE meeting. As a result, it was the best route for the RIPE meeting network, but ASPA validation caused the route to be dropped.

He recommended caution for validation in stub networks. It was fixed quickly, but Ondřej recommended starting validation from the core. Tim agreed that early adopters should be careful, but highlighted that it is also a data quality issue. Looking back on ROAs, in the early days ROAs did not really match what was in BGP – it was about 50-50. Adding a suggestion engine to the interface raised consistency to about 90%. But when networks started dropping invalid routes, networks fixed their ROA records.

Tim noted that these issues are likely to become visible as more networks begin validating ASPA records.

Ondřej responded that stub networks should not enable ASPA validation without first consulting their upstream providers. Tim added that it would also be prudent for providers to notify their customers before enabling ASPA validation.

Asbjørn Sloth Tønnesen, Fiberby ApS, said that his organisation is encouraging its entire AS cone to publish ASPA records. As validation coverage increases, he noted that one downstream dependency remains missing. He pointed out that AS12654 (RIPE RIS) does not currently publish an ASPA record and suggested that doing so would help improve validation coverage.

Ties de Kock, RIPE NCC, said that they would really like to do ASPA beacons, but would need a separate LIR to have a smaller blast radius. Tim added that access to the production network settings for RPKI beacon configuration can create operational and compliance concerns.

Job Snijders, Calgary Internet Exchange, referred to slide 15 and noted that the Calgary Internet Exchange has been performing ASPA validation on its route servers for the past three years. He encouraged other IXPs to adopt a similar approach, noting that ASPA validation is supported by both OpenBGPD and BIRD.

Job said that the exchange has approximately 100 peers, carries around 250 Gbit/s of traffic, and maintains roughly 175,000 routes on its route servers. Of these routes, around 470, or approximately 0.2%, are currently ASPA-invalid.

He characterised this as a very low proportion and suggested that it reflects a persistent but limited level of route leaks on the Internet. In his view, the fact that only a small number of routes are filtered indicates that the system is functioning as intended. He concluded that ASPA deployment is increasing and that the technology is already providing operational benefits.

Job also responded to Ondřej's earlier point, arguing that the incident under discussion did involve a routing leak. He noted that the route had been classified as ASPA-invalid and subsequently filtered, which demonstrated that the validation system had worked as intended.

Job also suggested that Ondřej may have intended to refer to single-homed networks rather than stub networks. He argued that single-homed networks should rely on their upstream providers for routing policy and, in many cases, could simply use a default route provided by the upstream.

For a multi-homed network, present at an IXP, with two or more BGP sessions, it makes sense to do ASPA filtering because if one path is a leak, others may be clear. We went through the same mechanics with the universal deployment of ROA validation in 2020. At the time, there were around 5000 invalid routes. It took the community some effort to understand that the 5000 number is big, but that the traffic flowing to those paths is so minuscule, and the benefits of not accepting mis-originations are so large compared to missing misconfigured destinations, that eventually, the community flipped to the trade-off of blocking invalids.

Job said that he hoped ASPA deployment would eventually reach a similar level of operational maturity. He disagreed with the suggestion that filtering approximately 470 ASPA-invalid routes on a route server represented a problem. Instead, he argued that the low number of filtered routes indicated a largely leak-free routing environment and demonstrated that the validation mechanism was functioning effectively.

Job further recommended that ASPA filtering should begin at Internet exchange route servers. He noted that route servers already distribute partial routing tables and argued that distributing slightly fewer routes, while preventing route leaks, would be a worthwhile trade-off. He then asked Ondřej about his deployment plans from the perspective of his role at an Internet exchange point.

Ondřej Filip responded that he supports ASPA deployment and was not arguing against the technology. He clarified that his earlier comments were specifically intended as a warning to single-homed networks. He added that his exchange point also plans to support ASPA validation.

Ben Cartwright-Cox read a follow-up comment from Alexander Azimov. Alexander agreed with Job's observation regarding single-homed networks, noting that it is common practice for such networks to receive a default route from their transit provider. Since routing decisions are already delegated to the upstream network in this scenario, he argued that using a default route is a reasonable approach.

Weird Things in the RPKI

Job Snijders

The presentation is available at:

https://ripe92.ripe.net/programme/meeting-plan/sessions/87/CVV98B/

Job Snijders presented on weird things in the RPKI. The talk was based on data collected by RPKIviews, which runs RPKI validators in a loop and gathers the results for archiving. The RPKISPOOL objects of RPKIviews capture almost all changes in the RPKI.

Job explained that the rpkispool archive for a given day contains only the files first observed on that date. While examining one such file, he encountered an unexpected object. Although the file appeared in a recent archive, it contained a timestamp from the past. Further analysis suggested that the object had been incorrectly dated in a way that could cause problems for validators synchronising repositories via rsync. As a result, the associated ROA would not necessarily propagate to all validators.

Job also highlighted that the RPKI functions as a distributed database and therefore inherits the complex failure modes common to distributed systems. He noted that operators may follow all recommended procedures and still encounter rare anomalies that are difficult to diagnose because no single party has visibility into the state of all validators.

Drawing on observations from multiple vantage points, Job said that he had identified a variety of small certificate authority artefacts. He noted that he had observed such artefacts in repositories operated by both ARIN and APNIC.

Ben Cartwright-Cox read a question from Shane Kerr, who asked whether RPKI uses actual wall-clock time for signature and object expiry.

Job replied that validators use local time to determine whether manifests and ROAs are still valid. However, objects are distributed with a lifetime between eight hours and two weeks, so there is a long window for objects to not yet have expired from the perspective of the validator.

Tom Strickx, Cloudflare, referred to an IETF Best Current Practice document on operating publication servers and asked whether future IETF work could help encourage operators to avoid the issues Job had described, including filename reuse and timestamp handling.

Job replied that the working group had produced a document describing the failure modes it currently understands and the precautions needed to avoid certain race conditions, including the use of unique filenames. However, he noted that migrating from the current system to a new publication strategy is non-trivial, particularly because these changes affect production systems. He said that operators such as ARIN, as well as systems such as Krill, face the challenge of developing reliable migration paths before adopting a new scheme.

Job also observed that technical documents often describe what should be done, but do not always explain the reasoning behind those choices. He said this meant it had taken him 12 years to understand the motivation for using randomised filenames. He described the RPKI as a collaborative effort based on shared learning and hindsight.

Cynthia Revström, Itnord Security Solutions, said that backdating signatures, especially backdating far, is a very big no-no. Cynthia recommended that CA software implement checks to prevent backdating signatures too far, because she does not know a good reason to do so.

Job explained that there is an inherent delay between the creation of an object, its discovery by relying parties, and its subsequent validation. He illustrated this with the example of an object signed on a given day. If a validator with an empty cache first synchronises two weeks later, it will encounter that object for the first time when it is already two weeks old.

He said that this behaviour makes time handling in the RPKI somewhat counterintuitive. Unlike a real-time system, the RPKI operates as an asynchronous protocol in which events are distributed over extended periods. As an example, he noted that the RIPE NCC's top-level manifest is re-signed every three months. Depending on when it is observed, the manifest may appear either very recent or several months old, even though its timestamp accurately reflects when it was created and is not backdated.

Detecting backdating from an old object that is newly fetched is very hard. And this is why RPKIviews is so useful, because you can recognise situations like this.

Closing Notes

The presentation is available at:

https://ripe92.ripe.net/programme/meeting-plan/sessions/87/JYMF9P/

Sebastian Becker closed the RPKI/Routing Working Group session and thanked the

speakers.