[routing-wg] RIPE NCC RPKI Routing Update May 2024

Dear RIPE NCC RPKI team,

< Speaking with no hats >

Thank you for sharing current status, plans, and reasoning behind
prioritization choices. I'm excited to see RIPE NCC's 'hosted' RPKI
service offering starting to move beyond "just ROAs".

Kind regards,

Job

On Mon, May 20, 2024 at 10:35:51AM +0200, Tim Bruijnzeels wrote:
> Dear colleagues,
> 
> Due to a full agenda, there will be no RIPE NCC RPKI update during the Routing Working Group session at RIPE 88. Instead, I will give a short high-level update during the RIPE NCC Services Working Group session. I would also like to share a more detailed update on our work and changes since RIPE 87 and our plans for the coming months.
> 
> If you have any questions or comments, or if you want to express your ideas on priorities, then please don't hesitate to talk to me in person at the RIPE Meeting, join the RIPE NCC Services Working Group session or discuss on this mailing list.
> 
> RPKI Compliance Project (ISAE3000)
> =============================
> 
> The RIPE NCC is currently conducting an ISAE3000/SOC 2 audit for the RPKI service. The SOC 2 type I audit is in its final stages. We are planning to continue to work on a (recurring) SOC 2 type II audit in the years to come. If you want to know more about this project, then I recommend you watch the Technology Update that Felipe Victoria Silveira will give during the RIPE NCC Services WG session at RIPE 88.
> 
> Supporting the audit has taken significant resources from the development team, but on the positive side, this has forced us to critically think about all aspects of the RPKI service: software, infrastructure, processes and the supporting organisation. As a result, we have made small but significant improvements such as providing more human-friendly insight into the Trust Anchor signing process, improving the database point-in-time recovery options (using write-ahead-logs), formally capturing existing engineering knowledge in a business continuity plan, and updating the Certification Practice Statement for transparency.
> 
> ASPA Support in the Pilot
> ====================
> 
> ASPA has been supported in the RIPE NCC RPKI Pilot (‘localcert’) environment since November 2022. We updated the implementation to use the latest ASPA profile in January 2024. More information on using the API can be found in this email sent to the IETF Sidrops mailing list:
> https://mailarchive.ietf.org/arch/msg/sidrops/K_d8S0ZDXnK0-vXD33uyHc6RnkE/
> 
> For those unfamiliar with ASPA, the very short summary of it is that it allows AS holders to declare who their provider ASNs are - in a BGP path sense, not necessarily in a business relation sense. This can be used to detect route leaks and to some degree (mainly dependent on uptake) path spoofing attacks against ROV.
> 
> For a longer explanation, I would like to refer you to my talk at SEE 12, where I try to explain ASPA using examples [1]. For a longer, and more precise talk, I can recommend a presentation given by Ben Maddison at AfPIF 2023 [2]. For a more fundamental understanding, you can read up on the formal specification of the verification [3] and proof of correctness [4]. Of course, there is more information available. So, if anyone has other useful pointers here, please don’t hesitate to mention them.
> 
> RPKI Dashboard Improvements
> ========================
> 
> As mentioned in the quarterly planning, we have been working on the RPKI dashboard to improve its usability and make it possible to extend its functionality with new object types. We have performed a user study of the existing dashboard and have started the implementation of the new dashboard.
> 
> We have been making good progress on this project and we expect to be able to start public beta testing in about six weeks from now. The primary goal of this beta testing is to ensure that the new dashboard works intuitively for the users of the hosted RPKI service, before switching over to the current dashboard. Of course, we also do our own testing, but input from real users is invaluable. If you are interested in participating in beta testing, then please let me know and I will make sure that we get in touch with you. 
> 
> Future Work
> ==========
> 
> Below, I will give an overview of several work items that we can pick up after the current work on the RPKI dashboard is done. We have ideas about what priorities to give to each item, but I would like to take this opportunity to ask the members of this WG to speak up and share what priorities they would give to each item.
> 
> - ASPA
> 
> Unfortunately, the discussion on the profile and RPKI to router payload has not yet been completely settled in the IETF Sidrops WG. That said, there is overwhelming support in the same WG for getting ASPA ready for deployment. Furthermore, early adopters are testing ASPA deployments, and the Calgary IX even uses ASPA in production [5].
> 
> We believe that ASPA, while it’s in its early adopter stages right now, has the potential to quickly provide a lot of additional value for routing safety. One of the main reasons for this is that the validation infrastructure stack for ASPA is very similar to the ROV stack i.e. ASPA objects are published by RPKI CAs, validated by RPKI Relying Party software, and the validated payloads are then communicated to routers so that they can perform ASPA verification without the need to do crypto in the router. Currently, ASPA is supported in Krill and RIPE NCC’s test environment and can be validated by (at least) routinator and rpki-client. OpenBGPd supports ASPA verification.  
> 
> In conclusion, we would like to enable the ASPA API in the production environment and add a UI for it as soon as the IETF has concluded its last call. We believe that this has high priority as it will help to get ASPA deployment on its way and convince router implementers to add support for it.
> 
> - RPKI Signed Checklists
> 
> RPKI Signed Checklists (RSCs), defined in RFC 9323, provide a verifiable general-purpose listing of checksums (a 'checklist') to be published in the RPKI.  The objective is to allow for the creation of an attestation, termed an "RPKI Signed Checklist (RSC)", which contains one or more checksums of arbitrary digital objects (files) that are signed with a specific set of Internet Number Resources. When validated, an RSC confirms that the respective Internet resource holder produced the RSC.
> 
> Note that “general purpose” in this context means that it can be validated that a resource holder made a signature over a (list of) hash(es) and optional file name(s). However, it’s up to the user to verify that those resources are applicable / make sense for matching files or documents.
> 
> This flexibility is by design. RSCs are not published in the RPKI itself but are intended to be exchanged between signing and validating parties, and presumably, these parties will have a shared understanding of the context. This may sound somewhat abstract, but think for example about bring-your-own-IP use cases where a prefix holder can sign a challenge given to them by a provider to demonstrate that they are authoritative for the prefix.
> 
> Implementing RSC signing in the RPKI dashboard and API is relatively straightforward. We propose that we work on implementing this after ASPA - or sooner in case the IETF's last call on ASPA is not reached.
> 
> - BGPSec Router Certificates
> 
> In a nutshell, BGPSec relies on the signing of announcements and updates along the BGP path by routers so that receiving routers can verify that the BGP path on the control plane is not modified. Asymmetric keys are used, and the public router keys for participating ASNs are published in the RPKI as a so-called BGPSec Router Certificate (RFC 8209) by the holder of the ASN.
> 
> There has not been significant uptake of BGPSec in production environments. Support in routers is lacking, but in part, this may also be because support in the hosted RPKI services is lacking. There has been a request in this WG to add support for this [6].
> 
> Implementing BGPSec Router Certificate signing support through the API is relatively easy to achieve, and therefore we propose that we start with this. This will enable early adopters to use this in production environments and build up much-needed experience.
> 
> We can implement support in the dashboard (UI) at a later stage. Our motivation for deprioritising this part is that (1) we prefer to allocate our UI development resources to ASPA and Resource Signed Checklists first, and (2) we would like to get experience and feedback from using the API so we can use it in the UI design.
> 
> - Faster BGP Feedback
> 
> The RPKI dashboard shows the impact of current, and pending, ROAs on BGP announcements as seen in the so-called “RISWhois Dump” files [7]. The same information is used for the daily (opt-in) alert emails about announcements that are ROV “not found” or “invalid”. The information in these files can be up to 8 hours old.
> 
> This system could be updated to use near real time routing information from RIS instead. This would allow for a much faster feedback loop in the dashboard, and it could potentially also be used to trigger alert emails based on changed announcements. Note however, that as ROV invalid announcements are increasingly dropped they may not be seen by RIS.
> 
> We believe that this could provide real value to operators, but it would be good to hear how valuable and urgent improving this is to this WG.
> 
> - IRR integration: Create/Delete Route Objects
> 
> While ROA and ROV uptake is still steadily rising, many networks also require Route objects and it is expected that this will remain the case for the foreseeable future. Maintaining both ROAs and Route objects separately incurs a maintenance burden for network operators.
> 
> The idea of automatically keeping Route objects in sync with ROAs has been around for quite a long time, but the differences between Route object authorisation semantics (maintainers, AS holder approval) and the interpretation of max length, as well as keeping two different datasets semantically in sync, make this more challenging than one might think.
> 
> That said, APNIC has been providing a way to do this and we can learn from their experience. In short, APNIC members can opt-in to creating or deleting an exact matching Route object for the ROA ASN and prefix, ignoring the optional max length. This synchronisation happens when ROAs are changed. Route object creation authorisation rules are bypassed this way, i.e. the user who can create ROAs may not have maintainer access in the database, and the AS holder does not authorise the creation. Furthermore, authorised database users can still remove or add Route objects manually, but this can result in the data sets being out of sync. So, a question to the WG would be whether this is actually a desirable way to do this, or if other ways should be considered instead.
> 
> In conclusion, we believe that this space is not yet sufficiently understood and we encourage discussion on this in the WG before we try to implement this.
> 
> Kind regards,
> 
> Tim Bruijnzeels
> Principal Engineer RPKI
> RIPE NCC
> 
> ---
> 
> [1] https://www.ripe.net/membership/meetings/regional-meetings/see/see-12/webstream-recordings/ (day 2, talk 1)
> [2] https://livestream.com/internetsociety/afpif2023/videos/237341493
> [3] https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification
> [4] https://datatracker.ietf.org/meeting/110/materials/slides-110-sidrops-sriram-aspa-alg-accuracy-01
> [5] https://mailman.nanog.org/pipermail/nanog/2023-February/221471.html
> [6] https://www.ripe.net/ripe/mail/archives/routing-wg/2021-September/004410.html
> [7] https://ris.ripe.net/docs/ris-whois/#riswhois-dumps
> 
> 
> -- 
> 
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/