You're viewing an archived page. It is no longer being updated.
Tuesday, 23 November 13:00 - 14:00 (UTC+1)
Chairs: Ignas Bagdonas, Job Snijders, Paul Hoogsteder
Scribe: Adonis Stergiopoulos
Status: Final
The presentation is available online at:
https://ripe83.ripe.net/archives/video/645
The Working Group chairs opened the session, welcomed the attendees to the Routing WG session of RIPE 83 and explained the etiquette for submitting questions both during and after the presentations.
Job Snijders introduced the upcoming presentation.
The presentation is available online at:
https://ripe83.ripe.net/archives/video/646
Pavlos Sempezis presented the research work that DataLabs, part of the Informatics department of Aristotle University in Greece, has been doing to estimate the impact of an ongoing BGP hijack. Pavlos shared best practices on estimating and measuring a BGP hijack and raised some of the problems when using public Internet measurement infrastructures and how to avoid them.
Randy Bush, Arrcus & IIJ, thanked Pavlos for the interesting approaches presented and asked if he had learned anything about the topology of the “blast radius”, meaning that depending on the location of the attack, what shape within the topology is noticed and whether it goes past Tier 1.
Pavlos replied that in their paper, they shared some preliminary results, and they need to investigate further to answer that. This is something that his team is currently looking at.
The presentation is available online at:
https://ripe83.ripe.net/archives/video/647/
Ties de Kock shared an update on the RIPE NCC’s quarterly plans for RPKI. These included: i) Implement and publish the results of the penetration test report, ii) Implement the findings of the source code review and open source the RPKI core, iii) Replacing the offline Hardware Security Module of the Trust Anchor, iv) Scaling up the RPKI repositories and v) Monitoring and alerting.
Jiří Raška, ANAFRA s.r.o., asked how engineers of the RIPE NCC are notified when an error occurs. Ties replied that during office hours, they see all the alerts and react to them. Outside office hours, only one engineer receives these alerts. Ties said that he was unsure if there was an automated escalation setup in place, but from their experience, most errors occur during office hours and around deployments. He then added that they make sure that deployments take place in the morning to give them enough time to see if any metrics change. They also have good alerting rules in some areas, and they ensure these are tuned in parallel when they make any changes to the software.
Randy Bush, Arrcus & IIJ, asked Ties if any of the alerts or subsections can be added to a feed such as an IRC channel so they can have some visibility and transparency. He added that large infrastructure services do have some automatic status visibility. Ties replied that some ongoing work is taking place to publish a status page that is more automatically updated. He would be happy to share more insights into the technology being used; for instance, they use the Prometheus standard setup. Ties asked Randy whether if publishing part of their internal metrics would help. Randy replied that he is referring to real-time metrics and status updates, something that could be used whenever an issue is noticed and someone wants to check whether the RIPE NCC is noticing it too or if it is just them. Nathalie Trenaman, RIPE NCC, joined the conversation and mentioned that they have looked at Randy’s request already, and that they are currently assessing what level of transparency they can provide in terms of monitoring and alerting. Nathalie added that they have to check first what will be available on their public status page for all their services. Ties clarified that when he showed an example of alerts, most of them are false positives because they prefer to have more alerts rather than missing anything. They need to figure out which ones are relevant, and he is open to sharing the metrics as it would help everyone look at historical data. Randy commented that he would like to see something that would help others diagnose their network; for example, if they see a dip, they would be able to confirm if the RIPE NCC sees that too. Ties replied that some people are using Routinator’s Wikimedia for this purpose, and there is also the RIPE NCC’s Validator. Still, he agreed that they could be more transparent on this point.
Ruediger Volk, no affiliation, asked if he had missed any of the information on how or which events get publicly reported. Ties responded that since last year, they have publicly disclosed all the events which they thought were externally visible, but if anyone has noticed something being missed, to notify them as they want to be transparent about all the events they see. Ties noted that there is no written policy, at least not in these slides, on what they can publish and what they cannot.
The presentation is available online at:
https://ripe83.ripe.net/archives/video/648
Martin Hutchinson presented on certificate transparency and how it works and shared a framework that community members can use to design similar systems.
Job Snijders commented on how certificate transparency applies to RPKI, not in the sense of keeping track of ROAs or BGP certificates that are issued, but on keeping a close eye on the CA certificates, for example, how the RIR distributes entitlements to Internet number resources and if an RIR by accident grants entitlement to the wrong certificate authority. This is where full certificates in a Merkle tree will help us increase our trust in the ecosystem. No questions were asked.
The presentations are available online at:
https://ripe83.ripe.net/archives/video/649
https://ripe83.ripe.net/archives/video/650
Pim van Pelt shared his experience and lessons learned while renumbering a running ISP autonomous system (AS) from one number to another one.
Job Snijders shared that he has been aware of organisations that have decided not to renumber their ASNs because the amount of effort was considered insurmountable. Pim agreed that it takes a lot of work and could have gone in many ways, but network automation is the best way to achieve it.
Randy Bush, Arrcus & IIJ, suggested looking at a paper from Lauren van Woeber on the router migration configuration list. Job asked for the title of the paper. Randy answered that he did not remember the title, but that he could find it. Pim said that he had found little information on the Internet about this renumbering, and that he would be happy to help anyone who would like to try this out. Randy added that there was some work done in the IETF in the past about renumbering and that it is complicated.
Jiří Raška, ANAFRA s.r.o., asked what the benefits of renumbering are. Pim replied that there was no particular reason; he did it because he always wanted a four-digit AS number.
Ruediger Volk, no affiliation, asked if he would do it again with a two-digit number. Pim answered that he would.
Job Snijders thanked everybody for attending and closed the session.