RIPE 77

Session I

Date: 18 October 2018, 14:00-15:30
Chair: Ignas Bagdonas
Scribe: Suzanne Taylor
Status: Final

A. Administrative Matters: Opening, Administrative, Global Activities

This presentation is available online:
https://ripe77.ripe.net/presentations/95-rtg-admin-181017-final.pdf

Routing WG co-Chair Ignas Bagdonas opened the session, went over the format and themes for the Routing WG sessions at RIPE 77, explaining that there would be two Routing WG sessions at RIPE 77 to allow for more time for comments after presentations. He said that the feedback from the IETF BoF at RIPE 76 was that the community is interested in specific areas in which the IETF is working, but not an IETF overview, so there would be a session dedicated to that.

B.BGP Policy Update - Job Snijders

This presentation is available online:
https://ripe77.ripe.net/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf

Ruediger Volk, Deutsche Telekom Technik GmbH, said he had remotely seen a version of Job’s presentation from NANOG and that he found it useful in providing arguments to fix things that were badly designed in the past. He said he couldn’t remember seeing such a systematic approach taken by anyone else. He added that Job could have pointed out cases where he had used heuristics, and pointed out a case where he found Job’s example incorrect, saying that some responsibility for the outbound sometimes gets lost.

Job agreed that his presentation was biased because he’s a transit provider and so the focus was on what’s being accepted, but that if you had a different type of network, you would have a very different view of things and that more attention would indeed be paid to ebgp-out. He thanked Ruediger for his positive feedback.

Rafael Freitas Zalamena, NetDEF/OpenSourceRouting, thanked Job for his presentation and asked if it would be possible to turn his presentation into reading material for new IXP customers.

Job said that the industry hasn’t generally taken a systematic approach to designing routing policy and that he would like to work towards a BCP document or software that would let people easily adapt things to their own needs.

Sherif Khalifa, Telecom Egypt, said he was confused about how to apply this recommendation on a multihomed network and optimise the IPs advertising to the upstream providers.

Job asked for clarification, and Sherif explained that they don’t use communities to advertise to an upstream provider, but just advertise prefixes.

Job said that he would recommend using both approaches, using BGP communities to decide which announcements propagate where, because by default you’ll want to announce all your prefixes to all your neighbours. He said that, on top of that, you could use ebgp-out as an explicit prefix list filter to block certain announcements. In this way, he said, the two approaches are not mutually exclusive. He said that using BGP communities as the basis would provide a very safe foundation on which to build prefix-based traffic engineering policies.

A remote participant commented via the chat room that the presentation was very good and explained things well.

There were no further questions or comments.

C. TNT: Revealing or Detecting All MPLS Tunnels - Pascal Merindol, RACI

This presentation is available online:
https://ripe77.ripe.net/presentations/90-88-TNT.pdf

There were no questions or comments.

D. DB Non-Authoritative Route Object Clean-up - Erik Bais, Martin Levy, Job Snijders

This presentation is available online:
https://ripe77.ripe.net/presentations/87-RIPE77_dbwgroutingwg_2018_06_RPKI_IRR_Cleanup_Snijders.pdf

Job Snijders presented on behalf of himself, Erik Bais and Martin Levy.

George Michaelson, APNIC, thanked RIPE NCC staff for the work they did in implementing the NWI-5 changes to the RIPE Database, which has made a big difference in APNIC staff explaining the existence of IRR objects to resource holders in their region. He said that the proposal that Job presented is a very good step towards a collaborative, respectful, mutual way of managing the data and that he specifically like the idea that someone must be actively engaged in a process that is their authority to make statements about routing. To make a ROA, he said, you have to be in the system, you have to mentally engaged, and you make a positive assertion that’s testable and can be cryptographically validated. He continued that if you see a ROA, you have incredibly strong evidence that someone with routing authority is saying what they want, and so if there is historical data that counteracts that, it should be superseded by the ROA. He said he also likes the approach of doing this only where there is contradictory information available, and not simply sweeping away older information. He said that approximately 380 entities across members and non-members still have these objects, and that many of them date from recent years.

Job thanked George for his feedback.

Randy Bush, IETF Meeting NOC, asked why the proposers aren’t looking at cleaning up objects in the RIPE data.

Job answered that they limited themselves to non-authoritative data because in the RIPE Database, any routing information is created with the explicit consent of the resource holder, which Job finds less troublesome than objects that were created without any consent of the resource holder. He agreed that there may be conflicts between RPKI data and RIPE data, but said he trusts that the RIPE NCC staff will be able to address inconsistencies by edging End Users away from misconfigurations rather than this necessitating a policy proposal.

Randy replied that it’s not clear that non-authoritative data was created without the resource holder’s knowledge. He said that Job should show leadership and, in the NTTIR instance, apply the RPKI data so that there aren’t any IRR objects in the NTT database.

Job responded that they intend to use that method, and that NTT has some bad data as well that they intend to clean up, so Randy’s concerns should be addressed.

Warren Kumari, Google, said he has some personal resources that are out-of-region but he put them in the RIPE Database because he likes the RIPE NCC. He said that he’s fine creating ROAs for them, but asked whether he would still be able to edit these objects under the proposal, and asked about making a new out-of-resource in the RIPE Database, if he creates a ROA.

Job recommended that Warren use the IRR database associated with the RIR that allocated the resources.

Nick Hilliard, INEX, said that he liked the proposal in general, but brought up a concern mentioned on the Database mailing list. He said that if someone in another RIR region creates a ROA, the RIPE NCC might simply blow the non-authoritative object away. He said this is not a very good idea because, as Randy pointed out, some of the data – and he would argue much of the data – tied to non-authoritative objects is accurate.

Job countered that if the data conflicts with a ROA, it cannot be accurate.

Nick said there are lots of reasons why it could still be valid data. He said that if you create a ROA, you can assign it any ASN you want, so you can have the same announcement coming from multiple regions with different ASNs. He asked the proposers to please include a grace period and a notification system so that the person who has created the ROA gets a notification that something is going to be deleted, as they may be on the other side of the world and not following RIPE procedures or policies.

Martin Levy said that this isn’t how things work today, and that you could create objects RADB or ALTDB that is in conflict with any other RIR database, or vice versa.

Nick said that is a parallel problem, but not related to the problem at hand.

Martin said that they were trying to tackle at least one problem.

Nick said that any routing filtering system that depends on IRR data needs to filter on the source tag, and that people shouldn’t be pulling everything from every database.

Martin responded that the database someone chooses to use may be regional or local in nature, but that the ROA at least has the authority of the prefix, which in theory is the most important thing to control. He said the key issue is that they’re dealing with RIPE-NONAUTH data, not the whole world, and ROAs created in an authoritative manner, and this is the focus of the proposal. He said that Randy is correct in that the IRR is a big mess, but that they’re trying to work on a very specific part of the problem and come up with a solution for that.

Nick reiterated that the resource holder needs to be notified and should be given a brief grace period so there is a back-up procedure in place if someone makes a mistake in creating ROAs and thereby deleting other objects in the process.

Martin pointed out that, independent of whatever the implementation, no End User of any of this routing data has access to a transactional-based rollback environment. But he thanked Nick for his feedback and said they would take it into account.

Nick said that in other situations, there were backups available but the proposal didn’t allow for any kind of backup.

Ruediger Volk, Deutsche Telekom Technik GmbH, said that Job’s assertion that objects in the RIPE Database are not authorised by the resource holders is not really true, as this was changed by the NWI implementation.

He added that the idea of applying the origin validation classification from RPKI data on building prefix lists and evaluating RPSL data is a good idea and very useful. However, he said that jumping from that to a policy that manipulates existing data is going too far. He suggested postponing the policy proposal and letting the community figure out their own way of applying this to their databases and what communication would be required before removing data that others rely on and which is being used by people who can’t necessarily be easily reached.

He also said that when talking about applying the RPKI classification to RPSL data, they should be aware that what’s happening in the RPKI and RPSL databases is different. He gave the example of someone removing more specific routes that someone has in a database because RPKI says it’s invalid, while three days later someone may want to turn it on and decide that synchronising the RPSL data is not reasonable. He said that, from a technical point of view, you should not be removing RPSL data because you do not know the consequences of removing it.

Job responded that it should be put in the correct database.

Ignas said that the session was in overtime and that there was clearly a strong interest in the topic. He asked whether the audience would be willing to continue the discussion tomorrow.

Job asked whether they could give every person at the microphones 30 seconds and Ignas agreed.

Marco Schmidt, RIPE NCC Policy Officer, said he wanted to make a point about the PDP. He said he saw many policy experts in the room but that that Routing WG had its last policy discussion in 2010. He encouraged everyone to make comments on the Routing WG mailing list so that it could be taken into account in the PDP.

Alexander Azimov, Qrator Labs, said that he discovered that there is no clear understanding of the quality of RIPE-NONAUTH data and that it might be simpler to suppress this output rather than delete it.

Ignas said that was a good idea.

Brian Dickson, GoDaddy, asked whether the proposers were talking about just ROAs in RIPE, and the team responded that they were including out-of-region ROAs as well. Brian then suggested that, instead of deleting objects, they could change ownership and notifying the ROA contact.

Martin responded that this only pertained to the RIPE-NONAUTH data, which is already down from RIPE “core” data. Erik added that these records should not be in the RIPE Database. Martin said he wondered whether anyone is using them for filtering.

Brian asked whether there would be any RIPE ROAs that would conflict with the data, and the team responded that this pertained only to out-of-region ROAs.

John Curran, ARIN, asked whether the team considered a notification system rather than immediately deleting the object.

Job countered by asking who should be contacted – the adversary that created the object without permission?

John said that there are probably many cases where there would be contacts available in the RIPE Database, and so asked again whether they considered notifying the responsible party.

The team responded that they hadn’t considered this.

Randy Bush asked everyone to refrain from using dehumanising language, saying these people are not “adversaries” but people who registered an object.

Job said he would do that if Randy would stop referencing racially driven genocide.

Randy said that was what he was trying to compare Job’s use to, saying that what they were doing was “Trump”.

Ignas asked whether the audience wanted to continue the discussion during the WG’s second session the next day, rather than on the Routing mailing list.

Job said that, from a PDP perspective, the mailing list would be preferable. He said that a presentation on the quality of the data would be useful, but wasn’t sure whether there was enough time to produce the statistics. Someone from the audience volunteered to try to look into the data quality before the second Routing session.

Ignas said that some topics for the second session could be shuffled to allow for more time to discuss the proposal.

Ruediger Volk suggested that they could split the discussion into two parts, one dealing with the technical classification and notification, which could be applied to any IRR database, and postpone the discussion about forcing change in the existing database.

Ignas said that the interested parties would discuss it and notify the mailing list of the plans going forward.

Ignas then thanked everyone for participating and closed the session.

Session II

Chair: Ignas Bagdonas
Date: 18 October 2018, 9:00 – 10:30
Scribe: Alun Davies

E. BGP Route Security - Cycling to the Future - Alexander Azimov, Qrator Labs

The presentation is available at:
https://ripe77.ripe.net/presentations/118-ripe77.azimov_v2.pdf

Jen Linkova asked whether all prefixes are assigned in this approach or whether assignments are made per prefix validation. The speaker replied that users assign a union of all upstream providers. Jen asked whether it would be possible to skip announcements for selected providers.

Alexander replied, not at present.

Tim Bruijnzeels, NLnetLabs, remarked that he was very enthusiastic about the whole idea, adding that if the speaker is looking into research implementation work, Tim and his colleagues would happy to work with him on this.

Massimiliano Stucchi, RIPE NCC, suggested there was an overlap with the AS cones overlap. Alexander responded that he didn’t think this was the case. Max suggested this can be solved with the AS codes. Following discussion with Job Snijders, Alex pointed out that it had been confirmed that there was no overlap.

Ruediger Volk, Deutsche Telecom, started his question with a response to Massimiliano. He pointed out that ASPA allows an AS to authorize its upstreams, adding that AS cones don’t certify. It documents a claim that ‘these are my customers’. This means there is awareness of the kind of issues that arise, several hops down from old systems. Returning to the speaker, he added that, as Jen had pointed out in previous discussion, ASPA is only at the AS level, and sometimes you need to be more specific. So there’s an underlying issue that routing decisions are made based on info that has no secure authenticity. In fact, the sources are prone to fake info. He cautioned that attackers will therefore find ways to insert fake info into the decision flow. In sum, he commented that whilst this is a nice method – it doesn’t go all the way. The speaker responded that, in the scenario described, you’re only going to be attacked by those who are sending you prefixes. It’s not so difficult to control things so as to avoid these issues.

Randy Bush, IIJ, pointed out that Jen had been quite correct. The approach works per AS and not per prefix. He added that this has been a weakness in AS BGP all along. This means that the approach the presenter had outlined would work in 98% of cases, but the big ASes don’t work this way. BGP Sec is complex and extremely hard to deploy, and this is a simple hack. Randy commented that he liked it because it can be deployed simply and is inexpensive, but it won’t solve all the problems.

F. Segment Routing (and why you shouldn't be afraid of it) - Florian Hibler, Arista Networks Inc.

The presentation is available at:
https://ripe77.ripe.net/presentations/16-20181015-SegmentRouting.pdf

Radu-Adrian Feurdean, Coriolis, pointed out that there are other ways to see segment routing. Segment routing looks interesting because it means you can get rid of LDP. However, there are issues with vendors using segment routing. But there are also lots of other interesting approaches. They should be taken into account. But, he added, the biggest issue here is vendor implementation.

Florian said that this is a fair concern, but that segment routing has been well tested. There are several reports that indicate stability.

Muhammad Aamir, Juniper Networks, asked if the speaker could add successful deployment details.

Florian commented that he can’t share customer details. 

Blake Willis, L33 Networks, commented that he’d been following SR for a while. He asked whether there was work going on at IETF to figure out the max number of segments one can stack on a given path before failures occur, and whether consensus had been reached on what the maximum load on a path should be? The speaker responded that there had been no particular limit agreed to, adding that he’d seen six level stacks out in the wild.

James Bensley asked whether the issue of Entropy levels can be approached with this. He added that, although there are lots of cool advantages to the approach outlined by the speaker, there just aren’t enough major issues being caused by this on his network for him to go through the upgrade to SR.

Florian responded that, actually, in traffic engineering and source spaced routing, there are a lot of worthwhile benefits. James added that, the entropy labels cause issues, saying he was skeptical that people will go through dealing with all that for such minimal gains.

G. RIPE-NOAUTH - Is it Alive? - Alexander Azimov

The presentation is available at:
https://ripe77.ripe.net/presentations/123-RIPE-NONAUTH.azimov.pdf

Alexander stepped up to pick up on the discussion from the previous day’s session. He carried out some analysis of issues that had been raised in that session. Alexander summarized the main points that, since invalids are bad, and need getting rid of, a decision needs to be made as to whether we delete or suppress them. He pointed to a problem with deleting them; i.e. what if a deletion is made by mistake? The objects are then gone and the database is locked, leading to real operational problems. Alex had looked at objects that exist only in RIPE NONAUTH and found more than 25000 objects. He still didn’t know if these objects are in use. So he decided to test this by looking at global prefixes to see if they belong to these route objects. He found at least 4000 route prefixes that have a corresponding route object belonging only in RIPE NONAUTH, meaning there are about 600 ISPs who would potentially face problems for if the object were deleted. He opened the discussion up to the room at this point.

Martin Levy, Cloudflare, thanked Alexander for the data points, pointing out that they’ll allow people to make decisions. He also requested that the raw data be made public. Alexander said he’d take care of this after carrying out a few checks.

Ruediger Volk said he’d also carried out some further analysis that provided more data points for this. He added that a quarter of his customers’ AS sets derived route objects in NONAUTH. Finally, he asked whether the deletion decision could be made before the next meeting?

Martin Levy said that, by the next meeting, they would have further analysis to present. Randy Bush commented that, although he was initially against this proposal, he appreciates that there is room for work in this space and supported the authors trying to go forward.

Lightning talk Martin Hoffman (NLnet Labs)

The presentation is available at:
https://ripe77.ripe.net/presentations/121-routinator-routing-wg-ripe77-v3.pdf

Blake Willis asked if there would be stickers. Martin said there would be.

Z. AOB

There was also a request for feedback on having two sessions next time. There was general approval for two routing sessions at RIPE 78.