You're viewing an archived page. It is no longer being updated.
Date: 23 May, 11-12:30
Chairs: Ignas Bagdonas, Paolo Moroni
Scribe: Ulka Athale
Status: Final
The presentation is available online:
https://ripe78.ripe.net/presentations/125-rtgwg-ripe78-190523.pdf
The Chairs announced that the minutes of the previous working group had been posted. They shared that the second session of the Routing WG was an experiment, it would take place jointly with the IPv6 WG and was more of a tutorial.
The presentation is available online:
https://ripe78.ripe.net/presentations/39-2019-05-23-bgp2018.pdf
Jen Linkova, Google, pointed out that Geoff had made a presentation in another session about IPv6 having a very high failure rate for some packets, and that he had data about the source IP addresses. She asked if he had tried correlating those prefixes with the prefixes with high levels of broken packets in IPv6.
Geoff replied that Google Cloud charged him by CPU cycles and by megabytes of capacity, and that he could make these calculations if he had the budget as it was a big data question.
Aaron, a remote participant asked a question regarding slide 7 of Geoff’s presentation - whether that slide was generally more specific or more specific with the same organisation’s ASN?
Geoff replied that his slide showed the aggregated results of lots of specifics. There were more specifics for a variety of reasons including hole punching where the aggregate has one origin AS and the more specific has another. There is also traffic engineering, where the aggregate and the more specific have the same origin AS but different paths as well as also senseless routing vandalism where the AS of the aggregate and the AS of the more specific are identical and the paths are identical.
Randy Bush commented on IPv6 routing saying that there were lots of IPv6 routes that travel halfway around the world and back because of business policies and peering agreements. He said that tunnelling and the relationship difference between IPv4 and IPv6 needed to be stopped.
Geoff replied with two examples – India and New Zealand. India sends its IPv6 to England before sending it out globally while its IPv4 goes out along the Indian ocean. Happy eyeballs didn’t work because of this asymmetric routing. In New Zealand, Vodafone sends its IPv4 routing to Australia but the IPv6 goes to America. He added that if companies cared for their customers and making it work, they would align their routing, and it would support upper layer things like happy eyeballs.
Lars-Johan Liman, Netnod, asked about anycast and whether that made a difference to the numbers regarding Geoff’s comment about vandalism.
Geoff replied saying they were not big enough players to have an impact through the Anycast cloud.
Blake Willis asked whether if everyone requested their router vendors for a nobody that said ‘If you have a covering aggregate for this de-aggregate, please ignore it’ it would happen.
Geoff replied that it wouldn’t because withdrawals make FIB compression a nightmare. He said they’ve looked into it for 20 years, and the cheapest solution is simple-minded – buying more memory from router vendors. Researchers have looked at it, and they avoid FIB compression.
Nick, a remote participant, asked whether default routes are bad for routing security RPKI filtering.
Geoff replied that learning other people’s routes is what makes your FIBs grow. There’s nothing wrong with default routing, the world runs on it, it makes the Internet work in some places.
The presentation is available online:
https://ripe78.ripe.net/presentations/113-routing_security_ripe78_snijders.pdf
Nick, a remote participant, commented that Geoff Huston, who gave the first talk in the session saw no problem with default routes and RPKI based route origin validation. He asked if Job agreed with him. He said that if one were to use default route packets, it will always leave your network even if RPKI based origin validation would filter the prefix announcement and result in no packet towards the destination.
Job replied saying that if you rely on a default route towards another provider, approach that provider and ask them to do origin validation on their network. If you rely on purely default routes, origin validation wouldn’t make sense because there is very little to validate.
Cynthia Maja Revström, a remote participant asked what Job thinks of alternative databases such as Alt DB, RADB etc. since Alt DB has no validation and RADB only has payment at validation? She also complimented Job and Sacha for their work on IRRd 4.
Job thanked Cynthia for the compliment and said that we can encourage the deployment of IRRd software that has the origin validation capabilities built in, so that the useful data remains in databases, but outdated data disappears as more people create ROAs. Both Alt DB and RADB indicated they were interested in deploying IRRd version 4, so he was confident that these IRR databases would become far less problematic in the next six to twelve months.
Robert Shek asked via chat when the open BSD RPKI client, which is in private beta, was likely to be made publicly available and if there was a rough time line and road map for the RPKI client.
Job replied that the software was finished but depends on open SSL, which open BSD does not want to use. This was forked in the LibreSSL but that did not have CMS functions, which are essential for how RPKI certificates can be validated and turned into VRPs. They could go public with the RPKI client after they fix the CMS functions in LibreSSL. The timeline was difficult, volunteers contribute to this outside of work hours, so they were going as fast as they can under the circumstances.
Mike, a remote participant, asked whether ROAs can now specify AS paths? E.g. A /18 is valid from AS1, but a /24 from that /18 is only valid for AS1 via AS2?
Job replied that it was not possible.
Jen Linkova, Google, asked if it was possible to incentivise people to do the right thing, and if it would be possible to experiment with this and analyse the results.
Job replied that he agreed that incentives work well to motivate people. He added that there is Open Source software that helps people. Origin validation is one of the most selfish things a network operator can do as they will immediately enjoy the benefits of having done that by facing fewer misconfigurations (theirs or others).
Brian Dixon, GoDaddy asked whether the end goal of using IRRd 4 was adding validated RPKI data including future AS cone information, and IRR and to get it deployed everywhere?
Job replied that the end goal with IRRd was that it becomes a part of the provisioning pipeline, with a focus on higher quality data rather than on IRR. IRRd was maybe a misnomer as it does IRR, RPKI and other useful things, but they were sticking with the name as it is so well-recognised.
Jerome Fleury, CloudFlare, thanked Job for his efforts to promote routing security. He commented that AT&T has deployed strict validation and it was the only tier 1 as far as he knew. He asked if job thought that the other tier 1s should deploy strict validation?
Job replied that he thought that every network, including so called Tier1s, should deploy it and that almost all transit-free networks had put RPKI on their road map.
Blake Willis, a long time Open BSD user, stated that if people wanted to see RPKI client development go faster, they should donate to the project and make a comment.
Brian Trammell, Google, speaking in his personal capacity, asked Job what he thought was the most important factor in the success of routing security measures, and what had to happen for this?
Job replied that it started just when someone popped into the IRC channel of the Dutch community and announced that he had deployed origin validation with strict policies in a commercial network. It then grew from there, as Job approached competing networks and encouraged them to follow suit. In short, it took one person to deploy it to get the ball rolling.
Rüdiger Volk, Deutsche Telecom, had three comments. First, he remembered clearly from a few years ago when sceptics predicted that RPKI would not be deployed. He added that even the first Dutch deployment was possible because people populated data i.e. created ROAs. Secondly, that he liked the approach presented by Google on the previous day that one should mark and report first before dropping any routes, and when you do drop a route, you should inform your customers and neighbours what you are dropping. There is still more work to be done on dealing with bad information in ROAs. His third comment was about processes to generate filters using RPSL data. They have enhanced their RPSL client software from where they can do ROA validation rather than interfering with databases.
Job replied that the beauty of the Internet was that everyone can do what they like with their own networks, and as Ruediger highlighted – there are philosophical differences over who should take which steps. It’s hard to say which approach is the best or the fastest.
Sandy Murphy wanted to give a shout-out to ZDNS for taking over the support of the BBNs RPS D R since 2017.
The presentation is available online:
https://ripe78.ripe.net/presentations/110-201905-routing-transparency.pdf
Geoff Huston said that he works in this space, and it was relatively easy to process BGP updates. One challenge is applying a long-lived memory to see if the AS path elements in the prefix have been seen sometime in the past. The real challenge is even after applying that, being left wondering what is going on with this update. He was willing to put up tools on GitHub but what is missing is essential insights like the length of time it was announced, geolocation information, and these heuristics are the biggest challenge. Getting some assistance in understanding the heuristics of what makes an announcement or a withdrawal interesting, would actually be helpful.
Randy Bush supported what Geoff said and added that what one person considers interesting or an anomaly may not be one to someone else. BGPMON meets the needs of some people, but not all. An underlying problem is that there is no clear vision of what’s normal or what’s an anomaly.
Andrei replied that this sort of tool might be able to provide information with a certain level of confidence and filter out ROA BGP announcements. Mainly it would improve signalling versus noise.
Chris Morrow, Google, said that Andrei’s point to about one person’s problem not being another person’s is a part of the problem. Open collection infrastructure would be great, there are things that can be done with BGP live and other tooling. He added that he would like to be able to look at the data and apply a long-term set of heuristics that are built for his network’s purposes. It would be nice if other community members could contribute BGP data off their networks in a central fashion.
Andrei thanked Chris for his comments and added that his idea was still very rough but there are two facets to it – one is a long-term service, and the other is an open source tool that you can use in your own environment and modify for anomalies you are interested in.
The presentation is available online:
https://ripe78.ripe.net/presentations/89-RIS-Live-RIPE-78v3.pdf
Jared, a remote participant, said that he agreed with Randy in relation to the previous discussion and asked everyone to show support for RIS Live, and that he thought the service is great.
Stavros Konstantaras, Amsterdam Internet Exchange, asked people to support it. Artemis, a tool for detecting BGP hijacks has been deployed in AMS-IX, is heavily reliant on RIS and is really fast. They keep working with developers to improve the tool, without which they would be blind.
The presentation is available online:
https://ripe78.ripe.net/presentations/105-Taking-The-High-Route-Routing-WG.pdf
Rüdiger Volk, said that something in Niels’s proposition was not right. He asked whether as per Niels’s model, a company that hadn’t registered its AS for GDPR might find itself violating the law.
Niels replied that no, it would not, and it would be a voluntary expression of value.
Rüdiger pointed out that an AS-SET talks about layer-free forwarding. As packets are forwarded, we do not process anything related to what Niels is interested in. He asked whether he would be expected to ask customers what personal data they are shipping in a certain packet, and whether he would have to invest in mechanisms to deal with that.
Niels pointed out that they didn’t have any mechanisms thus far. He said that if Rüdiger was asking if people should consider operating ethically even if it goes against business interest, then his argument would be yes, they should, or they should consider social questions that ask for that. We need to find ways to accommodate such questions otherwise other people will make the rules for us.
Rüdiger replied that they were talking about layer 3 networking where one does not know about the application, content and end-user context. In the kind of routing infrastructure where naked packets are forwarded, you will probably have a gag order if you are forced to open your links.
Niels replied that it is most important to understand that the user layer or the application layer is not the only place where politics takes place. Technology is not neutral and it's not so that infrastructure has no values. And this is a way to try to accommodate for that and see how it can work.
Sascha Luck commented online that he didn’t think it was an appropriate use of the RIPE Database. Anyone is free to set up their own database server and serve whatever AS SETs they desire. The RIPE NCC should not be seen to make judgments on human rights or anything else not related to resources and routing.
Radu-Adrian Feurdean, speaking for himself, replied that in answer to Rüdiger’s comment, we are in the packet forwarding business but how we forward packets and where we send them already factors in non-technical criteria, money being the most obvious. So why not do other things like the one’s described by Niels. He asked further whether the RIPE Database is the right place for this. However in the long term, it is worth exploring how it should be done.
The video recording can be viewed online:
https://ripe78.ripe.net/archives/video/112/
The Working Group Chairs reminded the audience that the Programme Committee was still looking for lightning talks, and invited attendees to submit their topics.