Thursday, 19 May 2022, 9:00 - 10:30 UTC+2
Chairs: Ignas Bagdonas, Job Snijders, Paul Hoogsteder
Scribe: Ties de Kock
Status: Final
Routing Working Group Chairs
The presentation is available at:
https://ripe84.ripe.net/wp-content/uploads/presentations/108-rtgwg-ripe84-220519-0545.pdf
The working group chairs opened the session and introduced the hybrid meeting. They informed the working group about several requirements from the RIPE Database Requirements Task Force that were relevant to the scope and charter of the routing working group.
Ignas Bagdonas and Paul Hoogsteder opened the meeting.
Ben Cartwright-Cox
The presentation is available at:
https://ripe84.ripe.net/wp-content/uploads/presentations/110-The-unending-misery-of-bgp.tools-RIPE84-1.pdf
The video is available at:
https://ripe84.ripe.net/archives/video/816/
Ben Cartwright-Cox, bgp.tools, introduced bgp.tools. The tool is designed to provide a better user interspace than telnetting into various services. One data modelling choice is that the data is at the upstreams-per-prefix level, and not at the upstreams-per-network level.
David Lamparter/OpenSourceRouting / NetDEF asked if Ben considered ingesting BMP streams.
Ben explained that it is very hard to track when BMP streams disconnect. It has issues. David agreed.
Robert Kisteleki, the RIPE NCC, commended Ben for his work and asked if there is value in a crowd-sourced database that would have useful AS names.
Ben replied that someone had asked for an API for adding AS name information. He said that he never realised that there was a demand for this and would look into open sourcing this API.
David Schweizer, NetDEF, asked about data retention. David also maintains a large database and he asked how long Ben retains his data in the database.
Ben explained that until he starts exporting MRT files out publicly, basically no data is retained. In the near future he will purchase hard drives so this will change.
Antoin Verschuren asked if Ben had considered using RDAP instead of whois where available.
Ben replies that RDAP is basically the whois parsed into JSON, which is not always what he is looking for.
Ruediger Volk provided some insight in why the different RIRs provide a non-uniform format in their respective whois and routing databases. RDAP was developed in the IETF to overcome these formatting issues.
Mike Marchal asked for the link to set up a BGP feed
Ben replied that he could set up a connection via bgp.tools at the end of the page: https://bgp.tools/kb/setup-sessions
Ignas Bagdonas
The presentation is available at:
https://ripe84.ripe.net/wp-content/uploads/presentations/109-bgpsec-ripe84-220519-0725.pdf
The video is available online at:
https://ripe84.ripe.net/archives/video/819/
Ignas mentioned that he would focus on the performance of BGPsec in his presentation. He explained why current BGPsec implementations cannot use the speedups provided by modern computer architectures because of low-level factors such as memory alignment.
Kurt Kayser asked if an overhaul of BGPsec ideally would replace RPKI.
Ignas explained that BGPsec is orthogonal to RPKI.
Ruediger Volk mentioned that there was one incorrect statement that Ignas made. It was said that BGPsec is an AS path policy. Ruediger explained that Ignas missed the essential point - that BGPsec authenticates a key BGP attribute. BGPsec does this for the path attribute, which allows operators to make sane decisions about the route
Mikhail Puzanov, RIPE NCC
The presentation is available online at:
https://ripe84.ripe.net/wp-content/uploads/presentations/44-Publication-in-Parent-PDF.pdf
The video is available online at: https://ripe84.ripe.net/archives/video/822/
Mikhail gave an update on what the RIPE NCC is working on with regards to a new service called “publication in parent”.
With publication in parent, also called hybrid RPKI or ‘publish in parent’, the RIPE NCC offers a service where the delegated CA creates objects, and sends them to a separate service using RFC8181 for publication.
Blake Willis, Zayo, asked if the RIPE NCC has any idea about the scale they would need to reach before being required to re-evaluate this design.
Mikhail replied that currently there are some tens of delegated CAs under the RIPE NCC Trust Anchor and that they did not expect an immediate influx of CAs for this service.
TIm Bruijnzeels, NLNetlabs, mentioned that they use this model for over a thousand CAs in Brazil, using Krill, proving that this model scales well.
Job Snijders said that he believes that Publish in Parent is the best current practice for deploying RPKI. Imagine that a validator needs to connect to thousands of repositories. Publishing with the RIPE NCC reduces the number of connections that everybody needs to make. Job Snijders also thanked Tim Bruijnzeels for coding Krill.
Job Snijders
The presentation is available online at:
https://ripe84.ripe.net/wp-content/uploads/presentations/115-RIPE84_RPKI_debugging_Snijders.pdf
The video is available online at: https://ripe84.ripe.net/archives/video/824/
Job Snijders gave an overview of the implementation of RPKI objects. While everyone has heard of a ROA by now, Job dived into the objects and described how the various RPKI objects are implemented as RPKI signed objects and concisely introduced the validation of RPKI objects from the trust anchors downward.
Alexander Zubkov
The presentation is available online at: https://ripe84.ripe.net/wp-content/uploads/presentations/96-ripe84-zubkov-filters.pdf
The video is available online at: https://ripe84.ripe.net/archives/video/826/
Alexander Zubkov from Qrator Labs introduced an open source toolchain that operators can use to generate BGP prefix lists for the BIRD routing daemon.
Tim Bruijnzeels
The presentation is available online at:
https://ripe84.ripe.net/wp-content/uploads/presentations/107-rpki-rs-ripe84.pdf
The video is available online at:
https://ripe84.ripe.net/archives/video/827/
Tim Bruijnzeels of NLnet Labs gave a lightning talk about rpki-rs, a rust library that parses various RPKI objects.