RIPE 91 Routing Working Group Minutes
Date: Wednesday, 22 October 11:00 - 12:30 (UTC+3)
Chairs: Ben Cartwright-Cox, Ignas Bagdonas, Sebastian Becker
Scribe: Tim Bruijnzeels
Status: Final
View the stenography transcripts
Routing-wg Opening Remarks
Ignas Bagdonas, Ben Cartwright-Cox, Sebastian Becker
The presentation is available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/30/GHTXME/
Ben introduced the agenda and reminded the working group attendees to rate all the talks. Ignas noted the minutes from the last meeting were approved.
Assessing the feasibility of routing security compliance tests
Moritz Müller, SIDN Labs, University of Twente
Lisa Bruder, SIDN Labs
The presentation is available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/30/L3FE7Y/
Lisa Bruder and Moritz Müller presented a prototype they developed for testing networks’ MNRS+ compliance through a peering session. They shared tips for doing so most effectively, such as withdrawing the test prefix as soon as a connectivity provider (CP) AS has passed or failed a test to avoid it being propagated further, and using third-party monitoring tools to measure how a CP AS has implemented its controls for the peering session.
Shane Kerr, IBM, asked if SIDN had tested this on their own networks.
Moritz said they had, although not all of MANRS+ applied to stub ASes like SIDN.
Tom Strickx, Cloudflare, observed that peering with every AS to measure them would be problematic in terms of scaling.
Lisa responded that they had experimented with multi-hop sessions.
Tom observed that this would not work across transit networks.
Moritz responded that measurements would likely be done from IX vantage points or remote peering.
ASPA in the RPKI Dashboard
Tim Bruijnzeels, RIPE NCC
The presentation is available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/30/VZNKWV/
Tim Bruijnzeels presented on how ASPA works and how it can be used in the public RPKI test environment. He explained how ASPA could be useful but also warned that, to avoid issues, care should be taken to ensure that ASPA objects reflect operational reality. He asked the group about whether the RIPE NCC should try to give users of the RPKI dashboard guidance in deciding which operators to include in their ASPA objects.
Nathalie Trenaman, AMS-IX, praised the work done so far, including the new UI. She noted that early ROAs were unreliable, as people did not yet know how to do them properly, so she thought that in this case it would also be important to support people very well on how to do this, such as at RIPE NCC events and in training courses.
James Bensley, Inter.link, recommended against trying to determine upstream connections as it was not possible. He said there were inaccuracies in ASPA already, such as due to regional variation in peering relationships, where two ASes could have an upstream-downstream connection in one place and be peers in another.
Tim said, in that case, the recommendation was to add anyone who could be a peer as a provider, even if they did not appear as the provider everywhere.
James said this created a potential for leaks. He noted that large DDoS providers could pose a problem, as there needed to be a record that allowed DDoD providers to announce prefixes, but they should only announce an individual customer’s prefixes a small amount of the time, when that customer was under attack. The record, however, would allow the provider to announce these prefixes all the time. For large DDoS providers, this encompassed a large amount of prefixes and ASNs. In a sense, this authorised route leaks.
Tim said this had more to do with ROAs and ROV.
James noted a comment made to him by Ben Cartwright-Cox, who had said that announcing prefixes was the point of DDoS providers. James responded that it was not good for these providers to announce a customer’s prefixes when that customer was not under attack.
Ben Cartwright-Cox, bgp.tools, responded that there was a contractual relationship between the provider and the customer. To Tim, he noted that he had experience using code to determine upstreams, but he recommended against this approach because it took too much work to be worth doing. He praised the idea of the RIPE NCC reminding people of any providers they had missed, as people most likely would forget relevant providers. It would also be good to inform people of violations, just as the RIPE NCC warned people about ROA hijacks. He noted it was very good that RIRs were starting to do ASPA, as it would make a big difference.
Tom Strickx, Cloudflare, also praised the work here. He noted that ASPA was still in draft and questioned when it would be finalised. He also advised against recommending providers, as RIS was biased toward Europe and the US and might miss providers elsewhere. He echoed Ben’s comment that reminding people of providers they might have missed might be useful, although he did not think warning about violations would work here.
Tim said there had been some discussion about a draft regarding the ordering of ROA information, but it was quieting down. There was also no discussion still ongoing for two other drafts, so it seemed that now was a good time to start implementing this.
Stavros Konstantaras, AMS-IX, was in favour of the work here and the UI. He said that recommending upstreams would probably not work because there would be false positives due to collectors appearing as upstreams, so RIS would not be helpful in this regard. He agreed with Ben’s suggestion for the RIPE NCC not to list the providers initially but to suggest upstreams that might have been missed.
Geoff Huston, APNIC, asked what would happen if you were a provider to someone over IPv4 and they were your provider over IPv6.
Tim said that earlier drafts had references to the differences between IPv4 and IPv6, but this was removed to keep things simple. In the case of what Geoff mentioned, then both people should list each other as providers.
There was an online comment from Antonio, who noted that if you could not list providers, your next step should be inventory, not ASPA.
Tim added that if you did not have any providers, you could put AS0 as your provider.
Tom Strickx, Cloudflare, noted a potential situation where Tier 1s might not do this and then might need to explain that transit-free networks were not actually transit-free.
What happens when you overshare? A Look into the BGP Maximum-Prefix Feature
Orlando Eduardo Martínez-Durive, NetAI & IMDEA Networks (work done as a research intern at Cisco ThousandEyes)
Antonios Chariton, Cisco
The presentation is available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/30/JDHZFZ/
Next up, Orlando Eduardo Martínez-Durive presented research findings on how the lack of clarity between BGP peers about the Maximum-Prefix Limit could lead to issues such as dropped sessions. He suggested that, in the short term, operators should set the Maximum-Prefix Limit of their peers slightly higher. He questioned whether there should eventually be a way to negotiate this limit in BGP sessions.
Shyam Krishna Khadka, University of Twente, asked if the relationship between the size of a prefix and the maximum limit was defined in PeeringDB.
Orlando said it was not the size of the prefix, it was how many prefixes an operator was advertising.
Rewriting BGP Origin
James Bensley, Inter.link
The presentation is available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/30/GJ8PFJ/
James Bensley, Inter.link, presented on how IP transit providers manipulated the BGP (IGP) origin attribute to attract more traffic, as the lowest IP address was used as a tiebreaker. This practice effectively resulted in a zero-sum game between transit providers, where not doing so resulted in losing traffic and getting customer complaints. Therefore, Inter.link was also forced to do this, but they decided to do this transparently and offer their customers a way to opt out.
Wolfgang Tremmel, DE-CIX Academy, asked about the occurrence of EGP attributes where Google was the origin.
James responded that the small number of prefixes tagged with EGP might still present significant amounts of data.
Ben Cox, bgp.tools, observed that removing the mandatory attribute would not be possible, but it was possible to make it irrelevant.
Peter Hessler, CCC, asked if customers were complaining about rewriting the origin on their prefixes or the prefixes announced to them.
James said it was the latter, where another upstream modified the origin, and traffic went through them. This resulted in lost traffic and in support tickets by customers who were confused by traffic going over the wrong link.
Will van Gulik, Saitis/RomandIX/AS2613, expressed support for the opt-out option and planned to implement it as well.
Blake Willis, L33 Networks, asked if they had considered letting customers use a community to opt in or out.
James said that opt-in did not work for them because it did not reduce the number of support tickets or lost traffic.
Tom Strickx, Cloudflare, observed that transits were in a race to the bottom and noted that one did not need to hold the origin IP. There were issues in the routing table, and naming and shaming might be needed to improve this situation.
James Rice, Jump Networks, mentioned that 0.0.0.1 was a perfectly valid ID.
James responded that this worked business-wise, but not ethically.
James Rice then suggested that if you defaulted to going reroute to IGP, what you could do with Inter.link’s BGP communities was the same as for different specific peers or regions: you could add a prepend and have a set BGP, set unknown and set IGP. Then an opt-out option was not needed, as you were already giving people the ability to do what they wanted.
James said this was a good point that he would make a note of.