You're viewing an archived page. It is no longer being updated.
Date: Wednesday, 17 October 2018, 11:00 - 12:30
Chairs: Remco van Mook, Florence Lavroff
Scribe: Vesna Manojlovic
Status: Draft
The presentation is available at:
https://ripe77.ripe.net/archives/video/2238/
Co-chair, Remco Van Mook, welcomed participants and introduced the other co-chairs, Florence Lavroff and Will van Gulik.
The presentation is available at:
https://ripe77.ripe.net/archives/video/2239/
A question received over chat asked why it was important to know if a network is remote or not, or connected through a reseller or not? Are there any risks linked to that?
George replied that what is done with the information is up to the IXP operators and the IX members. IXPs can benefit from this for their business model. IX members can benefit from this by divesting their traffic engineering for instance, if they see some lower performance.
Another comment over chat stated that the presentation seemed to be biased against remote peering, although in the presentation it accounts for very little traffic and port utilization. This suggests remote peering is used either for redundancy (not primarily) and/or as a test before becoming local. So, was that such a bad thing?
George replied that the point is to uncover remote peering. This was difficult as inferring someone as local was more straightforward. He said he didn’t think there was a bias, rather he provided an alternative solution, which is more effective and accurate compared to what exists.
A remote participant on chat asked if the person commenting on chat believed 40% of connections to the given examples of large IXPs are connections for redundancy, or test connections.
A.S. Bjorn commented on chat that if you want to peer with for e.g. Netflix, you often have to be connected to an IXP far from your user base. He further commented that the methodology was based on RTTs. In the future, IXP databases will gather member information from IXPs to populate the database making it easier to find out where connected members local or not and who is connected via the resellers. Will the methodology be adapted to make use of this tool?
George replied that the methodology doesn’t depend on RTTs. The RTT is used only for the approximating the area. After that a number of different heuristics are used in order to have a final inference, this is actually the main difference from prior research work that only used RTT measurements thus missing many ping links.
A.S. Bjorn further commented that if we wanted to start accepting PNIs in AMS-IX, they would properly only put a switch in AMS, and still do routing in CPH.
Giovanni Moura asked a question about Anycast. He said with Anycast, you can announce the same IP address for multiple equations across the globe that's what they run on DNS. He asked about insights into peering and if the methodology works with Anycast or if it accounts for that or if he speaker has any insight into that.
George replied that he felt quite certain remote peering can affect Anycast, because it seems local, but it isn’t, so it actually redirects traffic away from the CDN. He said this was part of their future work.
Tom Strickx, Cloudflare, asked how the methodology would deal with an IX that has a panning fabric across multiple cities, e.g. like a peer that might be local for the city and for most peers there, but is not local on the IX because their latency is 20 milliseconds. He asked if the current methodology show this as remote because of the high RTT?
George answered that a wide area IXP is a unique entity, and the IX member based on his methodology would be local. On the other hand, DE‑CIX Frankfurt or DE‑CIX Munich, are not a wide area IXPs, which means that if an IX member is local to DE‑CIX Munich, it cannot be considered local also to DE‑CIX New York. The difference is that in the first situation, the IXP is like one entity and in the other case there is model back space in the same organisation but different entities.
Andy Davidson, Asteroid, referred to the research in the presentation that showed that 60% of traceroutes used a path that was longer when a shorter one existed. He asked if George was interested in making his research available to those affected and misconfigured ASes on a per AS basis?
George replied that as the next step they could try other IXPs or a larger time window.
The presentation is available at:
https://ripe77.ripe.net/archives/video/2240/
Vesna Manojlovic, the RIPE NCC, stated that she was happy that Andy used a project from the hackathons and that she would like to discuss holding a hackathon on this later if he wanted to develop more tools with the community.
Andreas Polyrakis, GRNET, said that GRX has already joined MANRS and that it is a five-minute job for an IXP. You just need to put up some information on your website and fill in the form. He said IXPs should support MANRS and that they should consider incentives to members who join it. He added that what is missing is periodic auditing of members to check that they follow what MANRS describes.
Andy replied that he couldn’t speak authoritatively on the work being done on MANRS for carriers.
A speaker replied that the requirements actually are well recognised and the MANRS community is working on measurements, some of which was presented in the MAT Working Group. The idea is to build a MANRS Observatory and share some data publicly so people can assess the level of MANRS readiness for MANRS participants. The MANRS website has been redesigned but people could suggest what fields of membership data they would like the API to show.
Andy complimented them on the new MANRS website.
The presentation is available at:
https://ripe77.ripe.net/archives/video/2242/
Job Snijders asked why this is being done on a per client basis, why not just enable it for all clients without an opt-out.
Nick replied that it was because this is an early implementation.
Remco van Mook, said that he is an operator of a very small network that is connected to a lot of Internet Exchanges. He recommended that Nick take a look at BIRD‑RTR /CLI which is now no longer just CLI. He added that he had improved on the source code to turn it into a fully functional daemon to get integration into BIRD 1.0 for RPKI.
Nick replied that he was aware of it but deliberately hadn’t included it in the talk as there are lots of patches for this piece of software. He said his talk was about what you get with standard distribution.
Geoff Huston, APNIC, said that he recommended looking at Job Snijder’s slides from from the routing security session at NANOG, proposed pulling the IRR feeds through an ROA validation phase and to drop the things that an ROA says are really bad. He added that we have gone so far down AS path validation in the BGPSec protocol as to make it undeployable. Although it is standardized, it requires so much heft and weight that no one is willing to deploy it in the way that it needs to be deployed. He asked if AS path validation was required?
He also spoke about the legal barriers to RPKI adoption, and the issue of indemnification. ARIN has responded to the issue within the framework of US law. Enormous damage can be caused to the routing system through negligence. He pointed out that nobody wants huge damages claims.
Nick commented on ROA pre-validation, saying it has actually been done on a root (route?) server and that it requires a bit more work.
Andrei Robachevsky, Internet Society, asked whether AS path validation refers AS cone set or whether it refers to a full path check.
Nick replied that at the moment of regular IRR filtering, they implement checks to make sure that the AS origin matches an AS which is included in the AS‑SET from the IRR. There is no similar mechanism available in RPKI. The AS cone proposal could solve this but is also several years away from being a mature product that can be deployed. No code has been written, nothing has been standardised yet. Pure RPKI AS path validation is quite difficult and is further down the road than he had originally thought.
Andrei further asked if this will be implemented in the IXP manager and when it would be available.
Nick replied that it will be freely available, and available soon but there was a large backlog of features that need to be added, including RPKI. They were trying to get it done as quickly as possible.
Maria Jan Matejka, CZ.NIC, commented that they were aware of the problem with RPKI reevaluation, and they had recommendations for the 2.0 version, and they were currently implementing the structure to enable RPKI reevaluation, but it would take several months to get into production.
Nick said that it's actually relatively straightforward to work around by having a daily process to reload all incoming BGP sessions and that will cause a reevaluation. It can be done in the interim and that's what he would anticipate doing until there is proper support in the software.
Brian Nickson, GoDaddy, said that it was possible to get results similar to the AS cone through an open parameter where you establish what kind of relationship it is between two ASes, peer or customer transit, combined with a route leak detection and mitigation mechanism. This gets almost all the way in terms of protecting routing other than somebody maliciously interfering with the actual announcements themselves in detail.
Nick replied that he thought it was too simplistic in its approach towards Internet routing mechanisms and asked that if we were to look at it ten or twenty years down the road, would we end up in the sort of place that we would want to be in.
Peter Hessler, Open BSD Projects said that one of their sub-projects is open BGPD and they coincidentally had a new release coming out the next day and he would be giving a lightning talk about the improvements they have made to open BGPD, including implementing RPKI and ROA sets.
The presentation is available at:
https://ripe77.ripe.net/archives/video/2244/
There were no questions or comments.
The presentation is available at:
https://ripe77.ripe.net/archives/video/2245/
There were no questions or comments.
The presentation is available at:
https://ripe77.ripe.net/archives/video/2246/
There were no questions or comments.
There was an open discussion on the functioning of the working group.
The Chairs invited participants to rate the presentations and thanked them for joining the Working Group