You're viewing an archived page. It is no longer being updated.
Thursday, 20 May 14:30 - 15:30 (UTC+2)
Chairs: Ignas Bagdonas, Job Snijders, Paul Hoogsteder
Scribe: Karla Liddle-White
Status: Final
The presentation is available online at:
https://ripe82.ripe.net/wp-content/uploads/presentations/82-rtgwg-ripe82-210520-final.pdf
The Working Group chairs opened the session, welcomed the attendees and explained the etiquette for submitting questions both during and after the presentations.
Ignas Bagdonas confirmed that the minutes from RIPE 81 had been published with no comments. Job Snijders introduced the upcoming presentation.
The presentation is available online at:
https://ripe82.ripe.net/wp-content/uploads/presentations/79-RIS-update-ripe82.pdf
Job Snijders (jokingly) asked Emile what a tier one provider was.
Emile answered that this was a good question and (joked) that they use a list so if the list changed they would have to go after people.
The presentation is available online at:
https://ripe82.ripe.net/wp-content/uploads/presentations/81-Routing-WG-RIPE82-Nathalie.pdf
Erik Bais, A2B Internet, asked whether the RIPE NCC RPKI team had set up an RPKI-client testbed towards the rsync testbed. He also asked what the result of this was, and if it had not been set up, since the problems were with the RPKI-client, why it had not been tested. He said that an RPKI validator client testbed with the various SW would be helpful.
Nathalie confirmed that they had set up a testbed but did not have enough data to share yet.
Benno Overeinder, NLnet Labs, thanked Nathalie for sharing the roadmap plans. He asked whether there were plans for a publication server for RIPE members to publish ROAs, which would be like the service APNIC offers.
Nathalie responded that it had been on the roadmap but taken off because they changed priorities because they had to first be completely resilient. She confirmed that it had been postponed and that hopefully it will be looked at again next year.
A.J. Wolski, Netrunner Labs, asked how non-members would be able to report and ask questions regarding problems or inconsistencies with anchor or distribution, as RPKI was now a critical infrastructure and not only for LIRs.
Nathalie commented that this was a good question and that RPKI at RIPE.net is not only for members and that anybody can e-mail the team. She added that anybody can email [email protected] and the team would receive the message.
Rüdiger Volk, Independent, asked whether there were plans to publish the routes rejected by AS3333 in real time.
Nathalie explained that these were not published at the moment but that she would take this question back to the Ops team and see what they can do. She added that they would investigate whether this is possible and how and where it would be published.
The presentation is available online at:
https://ripe82.ripe.net/wp-content/uploads/presentations/83-ripe82_rpki.pdf
Randy Bush, RGnet Arrcus, IIJ Research, asked whether there were graph rates of errors and discrepancy graphs available.
Massimo said that there were currently no public graphs available since the system was for internal operations. He also said he could not provide numbers of how many incidents as he would need to ask for organisational authorisation to release the data.
Mike Booth, Liberty Global, asked where the BGPAlerter got its RPKI data. He also asked whether it was RIPE RIS or other sources.
Massimo explained that the data can be from wherever you would want to get data, such as CloudFlare but this means that you are delegating something else to provide the file. He continued to say that you can also do your own validation in-house and feed the VRP file that you will like for the RPKI data.
The presentation is available online:
https://ripe82.ripe.net/wp-content/uploads/presentations/15-ripe82-routing-loops.3.pdf
Randy Bush, RGnet Arrcus, IIJ Research, said that it was a nice study and asked how you could monitor and ameliorate loops.
Alexander said that as an example he monitors the loops for Qrator, the company he works for. He said if the question referred to AS, people can register and see their AS numbers.
Alexander continued by saying that loops caused by dynamic routing were hard to solve but they are temporary so we can live with them. He continued to say that loops in non-used IP space and BCP 38 are very helpful.
Rüdiger Volk, Independent, began his question by responding to Randy’s enquiry of how to obtain looping knowledge. He said he can recommend using the curator, and that scanned results are only available to people who in some way are authenticated as being in charge of the ASes. He said this was so the bad guys did not have an easy way to find the information and could then attack.
He continued to say that looking at some of the stats Alexander provided, he suspected that a lot of the loops were due to the use of default routes in the inter-domain case.
He continued to say that it was quite obvious when you use default routes, that you can make the assumption that everything will be well defined and quite obviously in many cases there are gaps which invite the loops.
Rüdiger then asked Alexander whether he had any indication of what the typical causes for the loops were aside from the default case that he mentioned.
Alexander said that unfortunately he did not collect such statistics and that he thought that one of the papers shared in the presentation did work on this but he did not see other ways of how to do it.
Jean-Daniel Pauget, FranceIX, then asked whether Alexander had statistics about internal, inside one AS, vs transversal, Multiple AS involved, loops.
Alexander replied that no, he did not collect the feed and he thought that it did not provide very good statistics, because on peer links you can see addresses from one AS but actually it would be a loop between different ASes.
The next question was from Dmitry Kohmanyuk, Hostmaster.ua, who asked if Alexander could share the Christmas tree AS number because he would like to test it next year.
Alexander confirmed that you can see the DNS name of the destination on the slide and you can then verify the loop.
The last question was from Lars Prehn, MPII, who asked how Alexander knew whether it’s really routing loops rather than just load balancing at complex infrastructure. He said that traceroutes are well known to sometimes report non-existing paths due to relying on various packets.
Alexander replied that if you see a packet that traverses the same route several times, it’s clearly a loop. He said that maybe there are some weird situations when one IP repeats several times in a loop. Alexander brought up an earlier slide and explained that in the highlighted loop, the IP looped several times and that it could be an ICMP included in the MAC address or incoming route so it multiplied several ICMP routes.
He added that when some IPs repeat and loop several times in a row then other IPs go, but all loops that he found, at least when he checked, and verified it with the result, he clearly saw that the pattern was repeating.
Alexander continued to say there are some other problems there, but he received TTL so the packet did not reach the destination, so he didn’t know what else it could be.
Job thanked everybody for attending and for asking good questions. Job closed the session and expressed the hope that he would see everybody either virtually or in person at the next RIPE Meeting.