.
RIPE 83
.
Plenary session
.
22 November 2021
.
14:30 (UTC + 1)
.
.
.
BRIAN NISBET: Hello. Lovely RIPE 83 attendees. It is just 14:30 CET, so, this seems like an excellent time to start this afternoon's session. I am Brian Nisbet and this is Fernando Garcia, and we are chairing this session on behalf of the RIPE PC. We have three talks in this session, all of which we hope you will enjoy, and obviously, as mentioned, you can interact with those talks either by requesting audio to speak at the virtual mic with our own physical mic or, indeed, enter a question into the Q&A text box, and we will read it out on your behalf. I will say just two things before introducing our first speaker.
The first one of those is please, again, rate the talks, because we take that information and look at what people liked, didn't like and it will feed into future RIPE meetings.
And also, if you would like an opportunity to be one of the people who are making the decisions on what kind of things go into future RIPE meetings, then you can step forward to put your name forward to be on the Programme Committee, which you can do by sending a photo and bio and expression of interest to pcpapacharlie [at] ripe [dot] net.
Excellent. So, let us then proceed, and our first speaker is Alexander Isavnin from the Free Moscow University, who will be speaking about Sovereign Internet and number resources.
ALEXANDER ISAVNIN: Thank you very much. First of all, what is the Sovereign Internet? It's a nickname for a series of legislations which was invented by a Russian regime to ensure stability, sustainability and security of Internet in Russia in case of disconnections from outside. I would like to thank the Programme Committee for an excellent programming, because, in the end of the previous session, we heard about sustainability, and in the beginning of this session, I will tell you about sustainability of a small [something] like is displayed on cigarette packs.
So, I already made a presentation on Sovereign Internet two years ago when this legislation, or the legislation level, was just adopted by our parliament. Today, I will talk to you a bit more on development which happened on two years, and affects number resources directly. But first of all, I need to tell you a few bits of Russian Internet history.
Russia became an independent country in in the previous century and no one knows how to regulate Internet. So, Internet regulations was written, like telephone regulations, as a public services telecommunications network, but it does not affect development of Internet itself because there was no relevant international telecommunications Union document. So, there was no hardly affecting regulations in Russia.
There was only licensing requirement with some paperwork and requirements to connect a lawful intercept, but, starting 2012, the government noticed that the Internet audience overtakes audience of Russian TV and started regulating Internet, mostly regulating Internet content but using technological methods. In parallel, they tried to bring Internet regulations into the agenda of the United Nations or International Communications Union.
Unfortunately for us, Russian Internet regulations is very ineffective, for the purposes it was declared officially, because in 2012 content blocking was invented for the purposes of child protection, terrorism protections, copyright violations, protections. This led to waves of improving regulation like increasing responsibilities of the licensed ISPs.
Regulations come in a series of ways. First of all, responsibility of licence of ISPs was increased. Then, regulations added more actors, stability regulated, like news aggregators, search engines, VPN operators and bloggers. Lately, global intercept was increased in the amount of responsibility and so‑called anti‑terrorist V‑ware package was added when readers must store Internet traffic for at least three months, in a time span of five years they need to increase amount of storage traffic. A lot of identification ‑‑ end user identifications legislations were added, but it's still ineffective, the government sees the regulation is ineffective and tried to improve it.
Also, I need to say that all this content‑filtering responsibility and even lawful intercept had to be done on ISPs and regulated actors' account.
So, we see that all these measures related to regulated Internet is ineffective, it was ‑‑ regulations sometimes stupid, sometimes doesn't work well, and, at the beginning of 2019 in Russia, there were bureaucratic languages, there was invented amendments for telecommunications and information laws for the purpose of official purpose of sustainability and security, and that was a form of framework which put autonomous system number, number resources and domain names into regulated respects, without much details and again in very bureaucratic language because it adds responsibility of the owner of number of autonomous system also owning technological networks. And so I'm really experienced misuse in translating this bureaucracy language into English, so I will try to just give you an impression of what happens.
All this regulation became possible because, basically, Internet was regulated as public services network. Here is a link for my previous presentation. But now I tell you what happens.
Sorry, there will be a few slides not about number resources but to give you an impression of how situations have developed, because it requires a lot of paperwork.
First of all, after the introduction of [something] most of the government decrease was created. The major one for our today purpose is a creation of a centre of monitoring and control of public services telecommunications network. Also, I should mention that, in this legislation, in a low level, Internet have not been mentioned by the word "Internet", only "public services telecommunications service" was mentioned. The most popular things among this government, popular in western media, is training on sustainability security and complete functioning of PSD which are known as Internet disconnection trainings, or regulation on technical means for countering threats, middle boxes which intended to protect Russian citizens from other threats.
Later, on a level below government ministry of telecommunications created a lot of decrease, setting up requirement for the owners of the number of autonomous system owning the technological networks. Later, on the level below, Ruscom Networks, federal supervision services, is very close to the regulator, made a lot of orders which includes national domain name sees them rights of centre for monitoring and control of public services communications networks, and again, the most important for this presentation is requirements for reporting for the owners of numbers of autonomous systems.
This level of regulations are usually directly executed by IPs or regulated actors.
So, on the level below, supervision services, there was a created centre for monitoring and control of public services telecommunications networks, and on this level it issued a number of instructions for autonomous system number owners, and, like documents mentioned on previous slides on the three or four levels, these documents are not normative documents, they have not discussed publicly and available only for operators via Ruscom resource service portal. So, on this level, major instructions have extended details for operators, how they should report, the infrastructure, the number resources, the connectivity lines, especially lines crossing city borders ‑‑ or crossing state borders and also connectivity incidents.
Also, very important part of Sovereign Internet is the regulation of Internet exchanges. I don't know why they selected this form of operator, but a lot of Sovereign Internet legislation by‑laws and instructions are related to Internet exchanges.
So, as I mentioned, the major three orders of Ruscom ‑‑ yeah, three major orders of Ruscom [Mazor] contain 47 pages with information which have to be provided, but when centre for monitoring and controlling extended for instructions, it takes about 430 pages, and given XMLs for possible reports.
And now we came for number resources, so‑called register for address number resources was created as a part of Ruscom [Mazor] services portal. Also there is additional instructions written by CMC about how to report your number resources to the State. You have to report objects which were similar to Ripe Database objects, that's AS‑SET, aut‑num, inetnum, organisation person and role. This has the possibility to import your number resource defining objects from a database of RIR. Also on this level, there is no input/export attributes for aut‑num so routing information is not collected yet at this level.
.
Also, the special information system of Centre For Monitoring and Control have been invented. And as instructions, only 7 pages, but it contains the most important thing, I feel.
First of all, you need to accept up a BGP session, a multihop approximate session with a designated order of this CMC information system and just send your BGP. Currently, we have not seen any [something] from this BGP session. Also, you have to configure a simple network management protocol, second version preferred, and allow to scan your audit another this way. You need to set up a NetFlow feed from your router, the instruction especially says you have to set up this on your border, there is no route collectors, and how you have configured it, your IP addresses, your community, your ports, need to be fielded into an Excel file and sent to the CMC.
Also, not only number resources is affected by Sovereign Internet, national domain name have been introduced, and Centre for Monitoring and Control have issued an instruction of configuring such sovereign domain name system. Instruction is really short, it contains only five pages, but it's enough to give an example of configuration files for different domain name server, where to get root zone, how to store it, or you might configure four orders or even provide your customers with DHCP with recursive resolvers domain name servers. I hope some of you have typed Whois on this address slide to see who is operating a national domain name serve, and, actually, one of the versions of these instructions have included with a page of approval signatures.
And we can see that it's approved by the chief of DNS projects of joint stock company MSK‑IX, so this domain name system is operated by Moscow Internet Exchange. As far as the previous slides, the BGP session have to be set to the IP address of the company MSK‑IX.
How to enforce this: In a time span of two years after the introduction of this law, additional articles to administrative coded have been added. You see among these five articles, two articles are already working. So if you have not provided reports for Centre for Controlling and Monitoring and we also see court cases, you can be fined for about €1,000, and lately, a few months ago, we see some cases for non‑usage of national DNS service. If first cases for non‑usage of national domain name system included just requirement of use this national domain name system together with normal domain name system, but late cases are showing that Ruscom [‑‑] and Centre for Controlling and Monitoring requires exclusive usage of this, so don't use the domain name resolution as provided by national domain.
.
Also, this article was first learned I think at the beginning of previous year, but since that, they have, at least two times, have been [something] and the regulator is called and terms have been lost, so it's no longer the owner of the number of autonomous system owner, but very, very accurate set of network equipment with unique identifier. So, in administrative code, it can already been interpreted not just as IS number but as IP address, IP prefix or even domain name.
But instructions and are written not for all possible Sovereign Internet means. For example, still no instructions for acceptance of routing commands in case of emergency. No traces of validation of reported data have been seen, because I know that many are just sending not complete data but just to avoid penalty by administrative call they send some information. Internet disconnection training has to be organised four times a year, but in 2021 have not been published during the November the schedule for next year has to be published, it's still not done. Also, inter‑connection of properly reported operators on the Internet exchanges is not been enforced.
Among sovereignisation laws, a so‑called landing law has been introduced where the foreign ‑‑ where the foreign companies have to organise local office with local representative, and the latest news that the holders of autonomous system number have also stored all Internet traffic for up to three years, so they included inter‑RIR packet subjects.
Also, a very strange coincidence appeared. External relations officer from RIPE NCC, external relations officer, and technical adviser have been deployed and expelled from Russia. So now we lack a technical advisor from the RIPE NCC in this region and I would like to raise a question, but directed to NCC Services Working Group, because managing director in June said there is an investigation of this case, and the... have been suspended, but last week I see that the investigation is still ongoing, so what they have to investigate, how to replace, it's still a question.
Why I'm telling you about all this, because for community I think it could raise a lot of concerns. You see that actually sovereignisation like replacement of root zone files, of collection of data, of possible acceptance of route incumbents are done on real low‑level documents, so general public, human right protecters and other communities cannot see what's going on really. And when this legislation has been introduced and all these decrease and orders have been introuced, the technical guys, the engineers they don't like to read government decrease about distribution of power between Ruscom [Mazor] and Ministry of Communication, so they do not raise concerns at that stage. And as I have seen on slide or configuration, an example of configuration of domain name service is, there is no longer one working on the Internet from ICANN, so no more ICANN requires, only search Internet.
Standards and traditions are broken with ‑‑ not with this configuration files, not only with reporting of resources but also with middle boxes like technical means of countering threats. This Russian regulation is very accurate in a European way, so it's very accurate,
So, I think you may have some questions, but if you have no questions, I have questions to you. Thank you. So questions welcome.
FERNANDO GARCIA: There are two questions. The first is from Marco d'Itri from Seeweb. He asks: "Do Russian IP careers have to export netflow data also from the parts of the network located in other countries?"
ALEXANDER ISAVNIN: There is nothing special written on this but I think the regulator might have this in mind. So we still have no court cases on this, but we just see instructions and some agreed forces to do this. I'm not sure they already get to our international carriers who work, international data communications, they have points of presence in Russia and it would be interesting to listen to them how they comply to this legislation.
FERNANDO GARCIA: So Blake Willis asks ‑‑
ALEXANDER ISAVNIN: International careers markets leaving the Russian market do these requirements. I have not seen yet, because this instruction just published, and this court case just came to our attention and what we see is that most of these court cases are against educational institutions or small enterprises who are using BGP routing and holding it on a one system number. So no huge numbers are getting affected by this.
Is it the RIPE database not enough for the regulator, do you have any ‑‑ for way they want to manage the IPv6 space using the registry?
.
Well, I have a gut feeling on this, because usually the Russian Internet, and many other legislations, are written in a form, please register just ‑‑ and not just your existence, provide us with information, and lately the participants of such registry are getting additional requirements. So, like holders of autonomous system numbers must implement a [something] and must implement your hardware. So they may like to use something like this.
FERNANDO GARCIA: Now, there is a question from Bassel: "Do VPNs that are not blocking resources block in router?"
ALEXANDER ISAVNIN: Some of them, some of them, they have to be to be blocked, so it's a legal requirement for regulator to block VPN providers that are not blocking Russian Internet ‑‑ illegal Russian resources, but actually if VPN is in the registry held by a registry, it's not being blocked.
Any penalties for non‑compliance?
FERNANDO GARCIA: Read the name and the affiliation.
ALEXANDER ISAVNIN: Not ‑‑ so there is not yet. Fines for non‑compliance is about €500, and a fine for non‑compliance for cooperation with law enforcement for holders of autonomous system numbers, so the operators and the previous regulator, I mentioned in another articles of the code, so, non‑compliance with law enforcement agencies requirements are not $500 but something like $500,000.
FERNANDO GARCIA: Okay, Tristan Bruns from LWLcom: "Are there netflow ex‑flow expiration for exchange points?"
ALEXANDER ISAVNIN: We can say this: Because for example, the MSK‑IX also should be compliant with a package so they have to store all the traffic, Internet traffic for three months but lately it reported that they reached 5 terabits per second, and actually when they asked the ‑‑ public, because none of them in this conference, when they are being asked how do you comply to this regulation, you have to store your 5 terabits, they just smiled and shrugged and say something you understand. But regulation says that if you hold autonomous system number and you have networking equipment, you have to do this. In Russia we are being still exist and can leave because of corruption and incompetence. But you see sometimes professionals from networking work help control as professionals.
FERNANDO GARCIA: And now we have a question from Vasilis: "How do they block VPNs and route servers in this. IP... blocking, something else?"
ALEXANDER ISAVNIN: With Sovereign Internet legislations, so‑called ‑‑ I have not paid much attention in this presentation. So‑called technical means for countering threats have been introduced. It's DPI boxes installed on a state account for the first time on these regulations, maximum close... so they said that they already placed at mobile operators much closer to base stations and filtering traffic and on some traditional land line operators are installed, they are completely controlled by regulator and actually we don't know what do they do. So, technical means for something interference, actually we know that the DPI boxes produced by the IDP company.
FERNANDO GARCIA: Okay. I think there are no more questions. Also, we are running out of time. I don't know if you want to say some final words are ‑‑
ALEXANDER ISAVNIN: Yeah. Actually, if there will be no question, I have questions to you all, and the most interesting and important question that the RIPE NCC is a route server operator who have never given equipment autonomous system number and have a route server instances in Russia, and that really interesting how we will work. Also, the questions for content provider, caches and CDNs, how are are you going to work with Russian operators who have to work only with registered IGFs? And also it's interesting for me do you have repressive regulation in your country. Thank you. And I see the representative of RIPE NCC wants to answer my question. But okay, I am not expecting answer just now. Please think, ask your lawyers, because lawyers usually don't sink to the lowest level regulation. As we see, I have seen report from ICANN, they don't see even the second sort of level regulation also, I have seen presentations from the RIPE NCC last week, and (inaudible ‑ connection lost) lower level regulations. You are welcome to ask questions. I will provide you with all the documents you require, but think what will you do in future.
KAVEH RANJBAR: Thank you, Alexander, a very interesting presentation and I think it's very useful for us generally at the RIPE community to see what's happening in parts of the your region and I know it's not always easy, especially if you need to interact a lot with the country in question, so thank you very much, we really appreciate it.
As a route server operator, the RIPE NCC, we basically do one thing, which is providing IANA‑assigned root zone, correct, and we only do that and will always do that. If there is any regulation or anything that prevents us from doing that, any requests that's asks for additional data on how we do that, for more than what we generally request any changes, we will stop operating that instance, correct. And the thing is root zone is signed so basically we cannot make any changes to it, but of course, that's only being a route server operator and in that sense, if any requests is pushed on us to make changes or provide additional data other than what's documented and we open plea provide, then we won't serve in that location.
This is different from what the community might want from the RIPE NCC to do but that I guess, as you said we should discuss it as a community possibly in the Cooperation Working Group or otherwise. So, thank you very much. And hope that clarifies that part of the question.
ALEXANDER ISAVNIN: Thank you.
FERNANDO GARCIA: Thank you. Okay. Now, we have ‑‑ next talk is from, I think, Clemens Mosig, are you there? He is going to speak about a lightning talk.
CLEMENS MOSIG: Thank you very much for the opportunity to present and welcome to my talk about BGP route flap and configurations. This is a joint work with all these.
This talk is about BGP route flap dampening. It is a mechanism implementing routers that suppresses IP prefixes if too many BGP updates for the prefix are received.
Last year, at RIPE 80, I presented our measurements. We found that route flap dampening is most of the time configured with harmful parameters. These harmful configurations are most of the time simply vendor default configurations. Last year, I referenced the recommendations by IETF and RIPE and said use theirs instead but I didn't question if these were okay to use.
So today I'm going to talk about these recommendations and how they are still valid even though they are based on a studied from ten years back when at least according to simple measurements, there was much less Internet share.
Also the study on which these recommendations are based on are ten years old, considers only IPv4, considered only one router vendor, and the vantage point from which was analysed is not relatively necessary representative.
Back then I thought the recommendations can't be correct, right. We need to re‑investigate what configuration parameters to recommend.
So, we reproduced these measurements. We consider IPv4 and IPv6, we consider both route flap dampening vendor implementations and we tried to accept a representative vantage point which provide 5 handpicked and other selected at random.
.
I'd like to show you this plot where you can see how BGP updates are distributed across prefixes. On the X axis you can see all router prefixes sorted by how many updates the export ‑‑ are exported for them on average to route collectors. On the Y axis attention block scale, this represents the number of updates for a given prefix.
And yes, you see that correctly, most of the updates are caused by a tiny fraction of prefixes. If we want to suppress prefixes to reduce BGP updates shown and subsequently all other routers and route validators and locate on the general routing system, it doesn't make sense to suppress all these other prefixes.
So let's discuss how we can configure route flap dampening to suppress only the correct prefixes. Again a router maintains a penalty for each prefix and peer. Penalties increase with each incoming routing update and the penalty decreases exponentially based on a given half life. Once it reaches a so‑called suppressed threshold the prefix is suppressed and considered too noisy. If the penalty later reaches the reuse limit again, the prefix is considered usable. Adjusting this suppressed threshold is the major not to find route flap dampening. We analysed how long prefixes are suppressed depending on their BGP update rate. The above blot shows on the X axis all prefix is sorted, again like on the previous plot. By the number of updates we collected for them. So we have got quiet prefixes to the left and prefixes with the most updates to the right.
The Y axis depicts different suppressed thresholds. So if a prefix has been suppressed by at least one vantage point at a given suppressed threshold, we put a marker there and we colour this marker depending on how long it has been suppressed and the period, which lasted seven days.
2,000 is the vendor default suppress threshold and you can see that even the quietest of prefixes to the left gets suppressed by some router on the Internet..
[Lost connection]
BRIAN NISBET: We appear to have lost Clemens. Somebody says may have been some prefix being damp somewhere on the Internet. Okay. Let's just see if he is saying anything where we are elsewhere. We might just move on to the other talk and come back if Clemens reappears.
This is the wonder of doing this kind of thing live. Here we are, excellent we're back ‑‑ the last thing we heard was very quiet prefixes being lost, being dampened, so that's where you were I think at that point in time, around I'm going to say slide 28.
CLEMENS MOSIG: Sorry for that. The Y axis depicts different suppressed threshold and if a prefix has been suppress the by at least one vantage point we put a marker there and we colour this marker depending on how long it has been suppressed.
2,000 is the vendor default suppress threshold and you can see that even the quietest of prefixes to the left gets suppressed by some router on the Internet. This was an issue and the vendor default configurations should never be used. If we look at 6,000 in the buff, this is not the case. The prefixes in the top 3% are still suppressed. If we take the threshold that is too high, then also another top 3% are not suppressed and this is not what we want. Luckily, the count recommendations always suggest a suppressed threshold in that range.
So, do we need new route flap dampening configuration recommendations? No penalty takes care of increased load and IPv6 cross time. The difference between Windows is also negligible, and does not require separate configuration recommendations.
Here you can see the default configuration parameters for Cisco and Juniper which are harmful, as well as the count recommendations for route flap dampening which you should use.
Thank you very much for listening and if you would like to know more about this research, you can check our website, our paper or the summary in the RIPE Labs article.
BRIAN NISBET: Okay. Thank you very much. And I think the joke we were making, do you remember the brief time you were gone, is that clearly somebody had overly aggressively damped your prefix and that's why...
CLEMENS MOSIG: Probably.
BRIAN NISBET: So, do we have any questions, folks? I don't see any at the moment, or are we all just, we'll make sure we're using the recommendations and go on and thank you for coming along and obviously the slides are all up there now so you can look at that very clear summary slide with the recommendations.
So, seeing no questions, thank you very much for you and the group's work on this. Oh, Andy has suddenly appeared. No, it's Emile, it's all good. Sorry, slight difference with names. Thank you very much.
So we will move on to the last presentation in this section then which is Emile Aben from the RIPE NCC, talking about mapping networks with RIPE Atlas. Please take it away.
EMILE ABEN: This is a joint work between me and my colleagues. This is about what we call minRTT, a work in progress, measuring latency into networks as seen from RIPE Atlas. So, the problem we're actually trying to address here is geolocation in networks being spotty, well we have IP geolocation, MaxMind and we have IP Map, which we developed for infrastructure IP addresses. There is RIR stats files, where you typically get like, for a given autonomous system, you get the country where the headquarters of a network are. PeeringDB peering information about where people want to peer, but not everybody is in PeeringDB. So what can we do to improve here? And, of course, I work at the RIPE NCC, so I love using RIPE Atlas, so how can we actually use RIPE Atlas to augment our understanding with such a widely deployed platform?
.
So, what we ‑‑ the idea that we had was that because we have Atlas probes and we have latencies, and Atlas probes have a geo log and latency say something about how close a network is to the origin of measurements, you can actually figure out what's the minimum latency into a network from a particular location. So ‑‑ and we call the network will look at origins because I wanted to have a name for both prefixes that are originated by ASs left hand as for IX peering lens, because they are fascinating.
So if you take, for a given day, for each probe origin combination, and these origins contain multiple IPs, of course, if you take the minimum RTT from that, you will have an estimate of where something is deployed. If you have a probe in Amsterdam that has like one millisecond latency in some traceroute somewhere in the whole of RIPE Atlas, that probably means that the resource is also in Amsterdam, and yeah, for IXPs, we used a little naming convention that we use IX dash and then a PeeringDB ID, I'll show a couple of visualisations after this where if you want to use them, you have to know that convention.
So, what does this look like? So you have on the left side, there is a traceroute and we have like 180 million a day from them, and if you put that on a query in the Cloud where we have it, it's 3.4 gigs per day. It's complex data, lots of structure, and we make it into something very simple. Like, it's a dataset of the things I talked about. The address gives a minimum RTT, and it's 4.8 million, and it's very simple data. So you can do all kinds of interesting things, and I'll show two of these things that you can do with it.
All these probes have a geolocation, so we can just put this type of stuff on the map. And this is the, the URL has live data behind it, so you can fill in any autonomous system or IX in there and figure out what it looks like from RIPE Atlas in terms of latency.
So here is a trivial example. The RIPE NCC network, we're in Amsterdam, and you basically see everything going out from Amsterdam has increased latency. This is not very spectacular, but where I think it becomes interesting it if you, for instance, look at distributed IXP, so an IXP that is in multiple locations you can see low latency in the Netherlands and in Bulgaria here, and some of the places in between not, which I find very fascinating to look at. You can look at tier 1s, but it could be any other one where you can see they have like very low latency, pretty much all of the northern hemisphere and it's a little bit more spotty in the southern hemisphere, or you can have like networks with very specific latency profiles. This is Angola cables, which is fascinating because they have a capable between Angola and Brazil and you can actually see there is very low latency there because they probably also have like an Internet was deployed in Brazil.
So this is the ‑‑ yeah, one of the things you can do with it, and well we have data for a couple of weeks now everyday on IPv4, on IPv6, and for all the origins that we can find in RIPE Atlas in all the measurements that we take.
The next thing that you can do. That was basically looking at the networks. You can also look at the probes. So, if you take an individual probe, you can actually use this datasets to figure out what the neighbourhood of that probe looks like. So, what is actually going on in that neighbour in as far as we can see it with RIPE Atlas. And I picked a random probe, this is a probe in Denmark where you can actually see a couple of interesting things, I think.
The latency here are ordered low to high. And what you then see is some plateaus here, and these are points of interconnect. So if there is a ridge interconnect environment, in this case it's 4 milliseconds away from this particular probe, you'll see a plateau, and in this case you can recognise a couple of IXs, there is Copenhagen in green and blue, there is NLix which also is in Copenhagen, so, this is interconnect in Copenhagen, and you can see it goes up a little and then you have another plateau and that's interconnect and in this case I think it's Frankfurt. And this also becomes interesting if you have like isolated areas, islands. For instance here, Iceland, there is interconnects you can see here on the island, and then you see a huge gap, 35 milliseconds, and then there is interconnects in the UK and in the European mainland, which I find this fascinating, and again, if I move back, there is a URL here, put in a probe ID into this, the visualisation that you have there and you can see what it looks like for the probes that you own or other probes that you can find in the RIPE Atlas network.
Of course, I'm a researcher, so there is a lot of caveats that I want to mention here. There is not all sunshine and a great dataset yet. We're limited here by where RIPE Atlas is deployed, so we cannot measure where we don't have vantage points, and if these probes are wrongly geolocated, we also have a problem, and we actually trying to fix that by doing latency measurements between probes and figuring out which ones don't make sense. We are limited by where RIPE Atlas measures to, so if something close to a probe is not measured to, it won't show up in these measurements. But you could fix that by doing more measurements.
This is limited by ICMP blocking, so, in networking, it doesn't want to be seen, it cannot be seen in this way. And the last one is particularly nasty, it's what I call RTT lies. Some probes were devices close to them, middle boxes, things that respond with low latency with fake source addresses. So, if you ping or trace through these devices to a destination, the defence sometimes responds with the IP address of the thing that you ping to or trace to. That's ‑‑ yeah, that pollutes this dataset, of course, because anything you measure through will have low latency, but we are trying to ‑‑ the idea is to flag these probes and figure out. And that's also ‑‑ well, good for RIPE Atlas in general to know of these types of effects, of course.
Well, I hope that was interesting. I have a lot of ideas for future work, but what I actually want to know from people here is where to take this. What else, and do you see for this? And I hope to have a chat with people in SpatialChat, or otherwise. Some of the things, and I have a little bit of time left so I can go through some of this, we could use this to select probes close to IXPs, so, for instance, if you want to measure ‑‑ there is a problem around INEX, it shouldn't happen, but say it would, you could select all the probes that are within 1 millisecond of INEX and figure out things from ‑‑ to help debug that.
But what you can also do is figure out which IXPs we actually have sufficient coverage over and which not. And if you just take 2 milliseconds as a bar of like you want to have probes within 2 milliseconds, we have had 44% of IXPs covered currently, so we could actually do better there. We could do minimum RTTs from countries. So are networks deployed in particular countries, are content networks in particular countries or not? You could compare IPv4 and IPv6, and of course, your idea here, this is made on top of a platform called Observable HQ for the Visualisations and this is actually JavaScript code that runs like a Python notebook so everybody ‑‑ and the nice thing there is, people can fork and play with the codes, merge it back, all these nice things.
And I see my timer goes into orange. So, that's the end of my talk. I hope it was interesting, and if there is questions, I'd be happy to hear them.
BRIAN NISBET: Yes. Thank you very much, Emile. And apologies for the confusion earlier, I am blaming the NCC, which is apparently what we have now decided is happening. So, a question from Erik Bais:
.
"Is it possible to see if you could plot Tor‑hosted stuff and see if you can guess where certain devices are located?"
EMILE ABEN: Plot Tor‑hosted stuff? Well, then I do this for ASs ‑‑ yeah, anything that you can group, but I don't see any immediate applicability for this, for Tor‑hosted stuff. We group them by IX ID or ASN and I don't think you can do that in anything related to Tor. Maybe you know more than I there and maybe there is a trick, so we could do it.
BRIAN NISBET: Okay. And the other question from Vasillis from Magma: "Do you know any ISPs that consistently report RTT lies?"
EMILE ABEN: I wish I would have that list, and then I could filter them out. What I see is that this lies typically happen at hop 1 or 2, and maybe it's CPE or the thing beyond the CPE. Maybe there is like the great firewall of China, that type of thing, intercept boxes, where ‑‑ that's where I'm ‑‑ that's where we see that, but I don't have a list of particular ISPs that consistently have this, no.
BRIAN NISBET: Okay. So, somebody is ‑‑ so, Christian Bretterhofer is seeing a run‑time error, network error ‑‑
EMILE ABEN: Okay, that's ‑‑ well, that shouldn't happen. It's a prototype, but I'd be happy, Christian, if you go over to SpatialChat, we can look at what the exact problem is.
BRIAN NISBET: Let's not live troubleshoot.
EMILE ABEN: Probably not.
BRIAN NISBET: Cool. I'm not seeing any other questions. So, thank you. Very interesting. The ongoing search to get more accuracy and where things are in the Internet. So thank you very much Emile.
So, thank you to all of our speakers in this session. That's the end of the presentations. We have ‑‑ thank you to those who interacted and to those who are watching. So, we now have a half‑hour break. You get an extra five minutes because myself and Fernando are so nice to you. And I will just remind people, please rate these talks, and they are all up there and the slides are all up online and videos will be soon, and please do consider nominating yourself, or a consenting friend, to the PC, so you too can get the opportunity to be on even more video calls over the next while. So thank you very much and have a good coffee break.
(Coffee break)
.
