RIPE 88 Routing Working Group Minutes
Thursday, 23 May 2024, 14:00 - 15:30 (UTC+2)
Chairs: Ignas Bagdonas (absent), Ben Cartwright-Cox, Paul Hoogsteder
Scribe: Tim Bruijnzeels
Status: Final
View the video archive
View the stenography transcripts
View the chat logs
1. Introduction
Ben and Paul opened the session and welcomed attendees. The minutes from RIPE 87 were approved.
The Routing WG session clashed with the Open Source WG session, hence Ben asked attendees if they would have attended the Open Source WG session if there had been no clash. It was concluded that roughly 25% of attendees raised their hands.
2. BGP Pipe: Open Source BGP Reverse Proxy
Pawel Foremski, IITiS PAN / DomainTools
Pawel presented about BGP Pipe. He illustrated some of its use cases, how it can be used to archive BGP messages, and how it can add ROV support by querying the routinator validity API end-point. Pawel ended his talk by asking for collaboration on software development and use.
Paul Hoogsteder asked a question via chat about his experience implementing a BGP speaker as a library, how much work it was, and how complete its coverage of the relevant RFCs. Pawel replied that as for completeness this proxy can connect to popular BGP speakers and translate formats, but it does not need to handle state so it is much simpler than ordinary BGP speakers.
Alexander Azimov, Yango, asked what happens if one of the BGP sessions goes down. Pawel replied that currently BGP Pipe would quit and would need to be restarted.
Peter Hessler, Zayo Europe, asked if there is the ability to easily change the BGP Pipe behaviour, or that it would need to be reconfigured and the session should be re-established. Pawel replied that the tool loses all info when it quits.
3. On "Reclaiming" 240.0.0.0/4
Ben Cartwright-Cox and Zbyněk Pospíchal
Ben talked about 240/4 which is currently “reserved” Class E space in case a “3rd type of routing” was discovered, which has not happened. Ben clarified that he believes that IPv6 should be deployed, that class E space will likely never get into the global routing table, but it is an interesting idea for local addressing. Ben proceeded to discuss findings in experimenting with the latter. Zbyněk talked about measurements of 240/4 reachability on the Internet today.
A participant raised a question on Meetecho, asking if practically reclaiming the prefix would merely delay the address exhaustion problem, and then whether it is worth the amount of engineering work. They continued by asking if internal uses be better served by going for example on link nets. Ben replied that other approaches like using IPv6 are an option, but in some situations, the easiest solution could be to use 240/4.
Radu-Adrian, France IX, observed that people who oppose IPv6 claim IPv6 does not work, so if they use 240/4 and break IPv4 this may remove this argument.
Tom Hill, BT, did not agree with using this for private address space and mentioned this may discourage the use of use of IPv6.
Ben replied that he only sees a use for 240/4 in link nets, not for end-user services.
Jen Linkova, Google, also disagreed and quoted the well-known phrase: “I suggest that all my competitors do this”.
Peter Hessler, Zayo Europe, asked if route objects and RPKI ROAs were set up for the experiment. They were not so this could explain the lack of propagation. Ben replied that there are routing security implications in this research.
4. RPKI Re-Validation: Revising the RPKI Validation Algorithm
Job Snijders, Fastly and Ben Maddison, World Online
Job explained that the current RPKI validation algorithm had very sharp edges as unrelated ROAs can be rejected because of transient mismatches of unrelated resources in the certificate chain in the RPKI tree. The alternative would be to limit the impact to related resources only. Job explained that this alternative existed (RFC8360) but is not deployable mainly because it would require RPKI CAs to re-issue everything, and suggested an alternative approach that did not have this issue.
Tim Bruijnzeels, RIPE NCC, clarified that the authors of RFC8360 did not like the need for re-issuance, but at the time the IETF required this. Furthermore, the alternative proposed by Job was implemented in an early RIPE NCC RPKI validator, so there is proof of concept. He concluded that it would be helpful for operators to speak up and say that they would like this to help the chances of getting this through the IETF.
5. Low Latency RPKI Validation
Mikhail Puzanov, RIPE NCC
Mikhail explained that he worked for RIPE NCC, but this talk is on a personal account and dedicated to his work on a project he maintained (RPKI prover, and RPKI validator). He proceeded to talk about how badly behaved RPKI repositories can impact RPKI validators.
Tim Bruijnzeels, RIPE NCC, thanked Mikhail for his work and commented that the CPU reduction (in partial revalidation) was interesting. He noticed that asynchronous fetching is done in some cases and wonders why this is not done in all cases.
Mikhail replied that for a cold start, one would have to wait for all repositories to be fetched, so the validator needs to wait to collect all data anyway.
Job Snijders, as a contributor to the RPKI client project, thanked Mikhail for his work on RPKI Prover. He commented that the partial revalidation optimisation is also used by an RPKI client.
Ben Maddison, Workonline, asked for clarification around synchronous-asynchronous fetching versus blocking fetching. Mikhail replied that RPKI prover blocks only when it first encounters a repository, or when it is time to refetch it.
Ben asked about dynamically adjusting the re-fetch frequency. He commented that historical publication frequency is not an obvious indicator and suggested that it should be cheap enough for validators to request updates as frequently as possible. Mikhail clarified that there is support for this, e.g. by the use of eTags, but this is not implemented everywhere.
6. Chair Replacement Procedure
Paul Hoogsteder announced that at the next Working Group meeting at RIPE 89 in Prague, there will be a Chair selection and he will step down when one or more new Chairs have been selected.
Paul then read out a proposal for a chair selection process, based on the input received from the Working Group and asked the attendees for a show of hands in agreement/disagreement, and concluded there was support for the proposal.
Ben Cartwright-Cox thanked Paul for his years of service as co-chair and commented that Paul will be a co-chair of the Connect WG which shares many similar topics.
Ben concluded the session by thanking everyone for attending.