RIPE 90 Routing Working Group Minutes

Date: Thursday, 15 May 14:00 - 15:30 (UTC + 1)
Chairs: Ignas Bagdonas, Ben Cartwright-Cox, Sebastian Becker
Scribe: Ties de Kock
Status: Draft

1. Administrativia, announcements

Ignas Bagdonas, Ben Cartwright-Cox, Sebastian Becker

The presentation is available at:
https://ripe90.ripe.net/archives/video/1656/

The chairs opened the session. Ignas announced that the minutes from the previous session had been approved, and he reminded people to rate the talks in this session. Ben encouraged members to submit future presentation proposals early to avoid last-minute rushes for RIPE 91.

2. RPKI Functionality Roadmap

Tim Bruijnzeels, RIPE NCC

The presentation is available at:
https://ripe90.ripe.net/archives/video/1659/

Tim Bruijnzeels presented recent developments in RPKI features at the RIPE NCC. He highlighted the overhaul of the RPKI dashboard, which now featured more accessible ROA history and a rollback feature, and there were improved email notifications. He then summarised current challenges with BGPsec and noted that the RIPE NCC would now support router certificate signing via the API. Tim also discussed Autonomous System Provider Authorizations (ASPA), including the state of standards work and implementations and the RIPE NCC’s rollout plan.

Gus Caplan, speaking for himself, commented that RTRTR was released recently with ASPA support in the JSON input and RTR output.

Maria Matejka of BIRD noted that she was one of the people working on the IETF draft, which had been delayed due to detailed discussions on validation wording. She encouraged the audience to review the validation procedure and reach out with any comments.

Vladislav Vodopian of GLEIF described a scenario involving an IX where downstreams announced prefixes from their peers. He asked whether such situations would be ASPA-invalid if IXP peers were not listed as upstream providers. Tim sought clarification on whether a non-transparent route server was in use. Alexander Azimov clarified that at transparent IXPs, ASPA would work as expected, but for non-transparent IXPs, one should include the route server’s AS in ASPA records.

Ignas Bagdonas, speaking as a participant, asked Tim to compare ASPA and BGPsec and whether one replaced the other. Tim explained that BGPsec provides cryptographic assurance that path information had not been altered but did not address policy correctness. On the other hand, ASPA encoded policy to detect leaks but did not guarantee that the path had not been modified. As ASPA adoption increased, spoofing plausible paths would become harder.

Randy Bush of Internet Initiative Japan and Arccus highlighted that ASPA was path-based, while BGPsec was prefix-based. ASPA could say that an AS-path was valid because it was valid for 'red' routes, while in fact 'blue' routes should not have that path. ASPA could not detect that.

3. Go for RPKI rsync diversity

Simon Leinen, Switch

The presentation is available at:
https://ripe90.ripe.net/archives/video/1662/

Simon Leinen discussed his experience with alternative rsync implementations for use with RPKI relying party software. He focused on an evaluation of gokrazy rsync. After testing gokrazy rsync with Routinator and FORT, Simon found it functionally viable, with some caveats. There was a feature gap before this rsync implementation could be a full alternative.

Tim Bruijnzeels expressed support for diversity in rsync client implementations and noted that rsync would remain a necessary fallback to RRDP for the foreseeable future. Tim asked if there were efforts to develop a server-side version of gokrazy rsync. Simon said there was indeed a server mode.

Ben Cartwright-Cox, speaking as a participant, highlighted the risk of lacking include/exclude functionality as this meant people could accidentally upload very large files. Simon mentioned that some mitigation options existed—such as max file size—but agreed that there should be proper exclusion support. Ben also pointed out that openrsync provided a server backend.

Randy Bush, Internet Initiative Japan/Arccus, suggested avoiding the use of Windows. Simon noted that he had not tested gokrazy rsync on Windows but expected it would work.

Ignas Bagdonas, speaking as a participant, asked Simon whether it was better to focus on developing reusable libraries, such as in C++, rather than stand-alone tools to allow for broader integration via language bindings. Simon said this was a good approach. Ignas said that from a systems engineering point of view, there was more potential re-usability when investing time in a tool that had a stable application binary interface.

4. Nearly Stateless L4 Balancer

Alexander Azimov, Yango

The presentation is available at:
https://ripe90.ripe.net/archives/video/1665/

Alexander Azimov discussed the design and feasibility of stateless Layer 4 load balancers. As conventional Layer 4 load balancers managed connection state using hash tables, backend failures forced stateful management of TCP sessions and introduced vulnerability to DDoS attacks targeting connection tables. He shared a prototype based on IPVS with a modified version of maglev hashing that achieved a near-stateless design by retaining both old and new hash rings during backend changes and selectively maintaining state only for unstable connections.

Christopher Dziomba of Deutsche Telekom AG asked whether Alexander had compared his approach with GitHub’s GLB or Cloudflare’s Unimog. Alexander responded that the industry alternatives he reviewed all required backend integration, unlike his solution. He said performance comparisons were irrelevant unless tested on the same base system and emphasised that their approach could be implemented on any Layer 4 load balancer supporting consistent hashing. He noted that his project had become less relevant in his environment due to the development of a DPDK-based system called Yanet. The current release of Yanet did not include their double hashing model, but Alexander hoped this would be included in the future.

Ramon Bister, Eastern Switzerland University of Applied Sciences, asked what benefits this solution had over application-layer load balancers. Alexander clarified that in large-scale deployments, the backends being balanced often were the application load balancers, so his solution complemented application-layer approaches.

Dmytro Kohmanyuk, speaking for himself, raised concerns about hash table performance with very large connection numbers. Alexander replied that their tests involved up to 250,000 simultaneous connections per second and did not encounter practical performance issues.

5. Closing administrativia

The Routing-WG co-chairs

The presentation is available at:
https://ripe90.ripe.net/archives/video/1667

Ignas concluded the session by reminding participants to submit proposals for RIPE 91 well in advance and encouraged anyone uncertain about submitting to speak to the chairs for guidance. Ben reminded the audience to rate the talks.