23 May, 2023
Plenary session
9 a.m.:
SPEAKER: We will start the session today, so we have ‑‑ I have a few announcements before we start, so first thing off, we need to take a selfie and it's the first time Antonio is chairing a session, we are two Italians so we have to make the IT ENOG group proud of us.
MASSIMILIANO STUCCHI: Before we start, we have a few announcements, first of all, please rate the talks, let us know if you liked them or especially if you didn't like them, as part of the Programme Committee it's important for us to understand the room, what you felt about what we chose as topics or as talks for the sessions.
Then second is, again part of the PC, Programme Committee, there are elections, and so far we have two candidates, but we would like to have more, so if you think you want to be where me and Antonio are standing maybe at one of the next meetings, please send your ‑‑ send an e‑mail to be a candidate for the Programme Committee.
Then last is when you go to the microphone, please state your name and affiliation before asking the question, that will ‑‑ that will help us also understand who you are and maybe find you later if we need to answer a question better or continue the discussion.
So, having said this, we have ‑‑ let's start with the first talk of the day from, we are going to talk about hyper‑specific prefixes, things that are seen on the Internet that most likely should not be there.
KHWAJA ZUBAIR SEDIQI: Thank you very much, MAX, and thanks for the applause. Good morning, ladies and gentlemen. I am Khwaja Zubair Sediqi, I am a PhD candidate at Max Planck Institute in Germany and today I am going to present one of our research work titled hyper‑specific prefixes, got to enjoy the little things and inter‑domain routing. This work is done a joint effort with my colleagues, and Oliver and it's published in CCR journal.
So as we all know, usually autonomous systems use BGP to announce the routing information to each other, exchange the prefixes with each other, and BGP best practices recommend that prefixes that are more specific than /24 IPv4 and also /48 and IPv6, for example, /25 to 32 in IPv4 and /48 in IPv6, they should be filtered by network operators. However, plenty of these prefixes are visible and observed in the Internet or at least with the data set of route collectors that we could observe them.
For this study we call this range of prefixes as a hyper‑specific prefixes, and we want to understand how prominent they are and why they are there, what could be the possible function or purpose that they observed in the Internet.
Before our work, there were some blog post about the topic in 2014 colleagues from RIPE they wrote a blog post where they did some announcement of HSP with and without route object to measure how far they propagate in the Internet, and they conclude their work that only 20% of route collector peers can observe these prefixes, so they do not propagate that far. A year later they also did similar experiments and they observed there is a marginal improvement in 2017 again, Strowes and Petrie conclude at most one‑fourth of route collector peers observe these prefixes in the Internet.
There was also a post by Geoff Huston about a similar topic where he investigated the more specific prefixes, and his conclusion was that there are possibly three cases for more specific prefixes, and he used the taxonomy of hole punching where prefixes originated from different origin autonomous systems or traffic generating purposes where the same original advertisers, these prefixes but through general autonomous system paths or AS paths and also Overlay Networks.
However, in that post, Geoff Huston referred to more specific, to any prefix that is covered by another one; for example, he refers a /24 could be a more specific of a /23. If that /24 is included in the /23.
So, for our analysis, we used the data from well known route collector projects like RIPERIS, route views and RIPERIS and Salario and for more than ten years, from 2002 to 2021. We collect 70 sample every quarter or every three months and one rep for 24 hours and also five‑minute update to check. We have it in the paper why we choose this sample size and then we filtered the outliers or data that was abnormal, also the private and preserved IP ranges from the data and additional we used supplemental data sets to give us more insight, from Kada rapid 7.
The first question is, how prominent or how large are these HSPs that we are talking? How many of them do we observe?
To answer this question, we tried to check the hyper‑specific prefixes existence of footprint in the routing ecosystem in the Internet. And in this plot, we show that here in the bottom, in grey colour the share of HSP on the Y axis we have the percentage of all the routes that we see, and we group the prefixes from /18‑15, 16 to 23 and HSP. The left one shows it for the IPv4, the right one shows the data for IPv6.
The X Axis shows the duration, the time frame that we collected the data.
As you can see, while yes, the yellow one, the /24 is dominant and also /48 is dominant in IPv6, however in the interests of our study, we are interested in HSP and you can see here sometime it reached to around 14% in IPv4 and more than 20% in IPv6. So what does it tell us? That yes, HSPs are there and we can say that on average, HSPs make roughly 10% of the prefixes that exist in their routing ecosystem.
Now, now that we know that there are HSPs, we try to understand how far they propagate and how long they stay in the Internet. To answer this question, this was not possible to do it with a seven days interval so we collect for the entire year every update and every rep, possible rep that we could collect and we measured the HSP lifetime as well as the propagation.
So, here, you can see that on the X Axis, we have the number of route collector peers so the higher it goes, the higher visibility it has. On the Y ‑‑ on the Y axis it's the number of route collector peers or feeders. On the X Axis we have the time, how long they stay, and at the end would mean one year, every cell contains two weeks duration, and on the Y axis around 10 peer ASs
The left one shows the data for IPv4 and the right one shows the data for IPv6. What you can see here is that the longer the prefixes stay the HSPs the higher the visibility so you can see on the right side for this plot as well as for the IPv6, so there is a correlation between the duration in HSP stays in the Internet and the visibility it gets.
However, it's also to be noted that, in the bottom, here the colour is red, and if you look at legend means there's high number of HSPs so a large number of HSPs they have a very low visibility, it's not that visible, I can say like largely they are visible by 40 or less route collector peers in the study.
The next question we wanted to ask ourselves was but what could be the possible functions or what could be the possible usage of HSPs?
To answer this question question, we think that certain CIDR sizes may hint a potential use case. If an address is under DDoS attack, then that company may advertise that specific IP with a blackholing community or as a /32 in IPv4 for example.
However, it may not be the case where a large size of IP addresses to be advertised for ‑‑ to address a particular under attack IP address. So hence, we ‑‑ we try to associate the following:
A /32 or a/128 in IPv6 will hint as this is probably a blackholing purposes, so this HSP is probably telling us that it was used for blackholing.
A /30 and 29 may hint as us about possible infrastructure peering subnets and also a/56 and /64 in IPv6 we classified as address block, assignments and /25 would possibly be used for traffic in general. How long it's a limited observation and I would love to hear from esteemed participants here how it is in your networks.
So if you look at the data, for the left plot for the IPv4 the green colour makes the highest fraction which is the range of 31 and 32 so we argue possibly the blackholing is the most prominent HSPs in IPv4.
And followed by the red colour, which is peering subnets or the infrastructure, and the routing infrastructure. On the right side the case is different for IPv6, you can see that the Orange colour is the dominant one and this is the range from/49 up to /64, so the address block assignment to the customers or to the devices, is the most common usage of HSP.
However, as I say at the beginning, the CIDR size can hint us and with this we can say, yes, HSP has heterogenous usage.
Now, next we try to see but what are the protocols running on top of these HSP prefixes or the IP of these HSP prefixes?
To understand or to do a deeper dive into this topic we used Rapid 7 open data for protocols and we try to measure the respond rate between the HSP and the non‑HSP or IPv4 wide IP addresses.
For that, we picked the top five protocol and it's interesting to know that four out of five protocol were similar in both cases. For IPv4‑wide and also for BGP.
And in this plot, we can see that we show the hit rate, the difference between HSP and IPv4. We noticed that for SMTP, BGP, HTTP, HTTPS, HSP has a higher hit rate than normal IPv4 wide. We also notice that this CWMP which is a protocol used to configure the CP devices of customer devices is commonly visible on the IPV4 wide but is not on the HSP prefixes, and also BGP was one of the top protocols in the HSP prefixes but it was not one of the top five protocols in IPv4‑wide.
So we can conclude that HSP prefixes have a higher hit rate for these protocols, up to five times in some cases than IPv4‑wide.
To do further analysis, we think that the community strengths may also help us to understand what are the possible usage of hyper‑specific prefixes. For this, we examined the BGP communities and our question was, or the idea was to check to what extent BGP communities contain specifically the blackholing community or if it has a route restriction, for example no export, no advertised communities like that. With are checking the data, we try to plot it, the median data in every bar here, and we have any community, so any community is some sort of string that is hard to derive or conclude specific information and if there was any type of blackholing community then we call it as any blackholing community. You can see it in the plot, that around 13% of the HSP in IPv4 and around 7% of the HSPs in IPv6 have a blackholing community, and the most well known black community within these prefixes were 666. So we argued that at least limited to this number, that's 13 and 7% of HSPs are concrete example of blackholing usage in the HSP prefixes.
However, we do not observe so many of route restrictions for route restriction communities within the HSP prefixes.
The next question that we wanted to ask is that are HSPs intended or they are some accidental route leaks? So what is the use case?
Now, it was hard to address it particularly but we tried to look at different databases and we think if the network operators takes time to add the HSP information into those databases, then it means they have an intention to use it, possibly.
For that, we look at the IRR database, RPKI and the BGP is the data that we collected through route collectors.
As you can see, the data for IRR and RPKI we collected from the time that it was possible so probably after 2015, 2017 it was possible.
In this plot, the green colour, the IRR, shows that there are roughly 2000 unique origin autonomous systems that they entered the HSP information into the database, into the IRR database. However, for the routes that we observed in route collector, we do not observe so much footprint within the IRR and the yellow colour shows if an HSP was observed in more than one category, so if it was observed within the route collector but it was also visible in the IRR or RPKI.
This plot tells us that, yes, there are operators that they intend to use HSP, they entered it in the IRR object but there is also plenty of HSPs they don't have any footprint, so it could be a route leak, it could be a misconfigured feeder or PAs of route collector that collects this information.
To do further analysis, we tried to look at ‑‑ our are BGPs ‑‑ are HSPs due to BGP prefixes hijacks because it could be there's a more specific prefix and could win. To address this question, we look at the BGP and ‑‑ we look at the HSP data in the RPKI database, so in this plot, an HSP information is categorised in four categories: The first one, it's valid, if the prefix length and the origin is correct.
The second one, we call it invalid length and it means the origin AS is correct but the prefix or the length or CIDR size is invalid; for example the operator entered a /24 but we observe an HSP which has /28. So the origin is valid, it comes from a valid origin but the prefix length is invalid.
The third case invalid origin: Well it is a possible this could be a hijack because the origin autonomous system is not valid.
And the last case, the red one, is invalid both, where neither the prefix and nor the origin is valid within the RPKI database.
As you can see, the grey colour is the dominant one and this tells us that large number of HSPs are actually originated from a valid origin, so the original autonomous system is correct. However, the CIDR size is not correct.
The green colour tells us that both the origin and the CIDR size is correct and you can see for IPv6 we have a large fraction, percentage, nearly 20% maybe on average, they have both the valid length and also the valid origin AS.
The yellow colour, that is shown as invalid origin. It makes a tiny fraction of the data.
And we ‑‑ it could be a hijack, it's possible, but it's also possible that some autonomous systems may have not entered the ROA information into the RPKI database or it could be that some companies, they use DDoS protection services or DP S, to advertise their prefixes and this could be also lead in such a situation to invalid origin.
With this, we conclude this one that legitimate autonomous system advertise around 70% of HSPs to the Internet.
Now, the question now that we can here together in RIPE, the question is, what about future of HSPs? What do you think?
So, there's two aspects:
One, we think the route collector are heavily used, at least with the research community, and it's important to have a clean data there. To help the community, we also collect the HSP information and we maintain a dashboard where we publish the HSP information, who originates it, from which feed, to make sure if there's a route leak or if there's an intended or misconfigured peer‑AS, the operator could take action and fix it.
And you can access the dashboard through this QR code as well as through that hyper‑specific URL.
But that's the discussion for the research community.
Here, in operator community, when we discussed our results with operators, with 13 operators, two of them they said yes, it's a misconfigured BGP filter and they fixed it. Some of them they also said, but yes we announce it but there's a customer request for it. For example, some small customers they want to do traffic engineering and that's why we announce it.
I also heard yesterday that there is in the RIPE policy a discussion going on especially for IPv4, shall we increase the filter size from 24 to /25 or 26 or not? Which is an interesting discussion for me.
We think that if the question is shall we filter it or not there's two parts: For IPv6, we think yes, we should filter it and the reason is because IPv6 is cheap to obtain and also if you do not filter it it may create a large routing table in the Internet for the routers.
For IPv4, we think that probably in some cases maybe shifting by few CIDR sizes/26 could be an agreeable compromise but it's an open discussion, we can discuss it, we do not say particularly that we should do it but I would love to listen and here your opinion in this regard.
Now, my question is open, how do you handle HSP in your network and how do you treat it and what do you think, is it okay to use it, keep it, filter it or not filter it?
What this I conclude my presentation, and in this presentation, just to have a short look, we analysed the hyper‑specific prefixes for one decade and we use that HSPs are visible by few route collector peers. Hundreds of them they are visible by hundreds of route checker peers in IPv4, the most of the HSPs they are associated with infrastructure announcements or blackholing and IPv6, most of the HSPs related to address block reassignment. And we think that though hundreds of networks use HSPs, we attribute even more cases to be route leaks or misconfigured ASs, autonomous systems.
With that, I'm done, and if you are interested to look at the, scan the QR code or check the hyper‑specifics.io for the update to date information on this topic and also for further details or papers available on that address, thank you very much for your attendance.
MASSIMILIANO STUCCHI: Do we have any questions? Oh, I see.
AUDIENCE SPEAKER: Hi, Giovane, SIDN Labs and TU Delft. Can you go back to slide 7, please? I am trying to understand what you were showing.
AUDIENCE SPEAKER: Hi, Warren Kumari, Google. Back in 2008 there was the Pakistan YouTube route hijack thing. Pakistan Telekom announced the YouTube routes. I was on call at the time, and so I decided to announce two /25s, not really thinking that would work, but around 80% of the traffic came back with those two /25s and I figured why not announce /29s as well and another 5 or 6% of traffic came back.
This was surprising and slightly worrying, but what I was wondering is, did you look at all at the difference between sort of hyperlocal or hyper prefixes on peering interfaces versus what you would kind of call transit or isn't that really something you could see? So announce /25s just what I would call peers not transit type connections and I don't know if there's a difference in how often you would see very specific prefixes just between peering type agreements.
KHWAJA ZUBAIR SEDIQI: So I assumed the peering should not advertise it publicly. Not ‑‑ because peering information is a bit hard to derive as well from the public Internet side. However we tried to look at it at the different network types like what are the operators and we find that the ISP transit, comparing to the non‑HSP, they are one of the dominant users.
AUDIENCE SPEAKER: So yeah, I'd like to know what are you showing on the Y axis there? You say IPv4 visibility maximum number of ASs. What exactly is on Y axis?
KHWAJA ZUBAIR SEDIQI: So it's the number of route collector peers that we have and we see that the same prefix was observed by maximum how many route collector peers.
AUDIENCE SPEAKER: I get it, thanks.
BENEDIKT STOCKEBRAND: Random IPv6 guy, so I don't really know what I'm talking about here. But a customer of mine the other day had some strange problems relating to IPv4 and it looked like there were problems routing /23s, 22s in some places already, apparently due to routing table constraints in some old hardware. Do you have any idea if there's something going on in that area or did you just focus on /24 and longer?
KHWAJA ZUBAIR SEDIQI: For this study, our ‑‑ the scope of the study was the ‑‑ longer than /24 in a sense or more specific. Then it's a deep dive question to look where the problem is, it could be ‑‑ I mean there are different cases, it could be a particular filter, it could be invalid announcement by RPKI, I cannot say to you right now but that was not the scope of this work.
BENEDIKT STOCKEBRAND: Okay, thank you.
RUEDIGER VOLK: Retired. Let me ‑‑ let me first make one short remark. I always cringe when people talk about ROAs with invalid length. 1,000 ‑‑ 1232 would be an invalid length, definitely, and since you are academic, terminology counts. The current ‑‑ the correct ‑‑ the correct terminology is non‑matching length instead of invalid. I know ‑‑ I know the invalid length is circulating in the practical community and I cringe, nevertheless.
For your question whether HSPs should be usually filtered, well okay, no, your question was well okay should the length restrictions be relaxed and your arm that well, okay, v6 is cheap and you do not not ‑‑ addresses are cheap and you do not need to restrict there and then, well okay you restrict the announcement lengths but well okay, v4 is a different question but kind of, you are then kind of suggesting that the price ‑‑ cost pressure and the scarcity of the address in v4 space, should be moved, well okay, that he is cost, should be by relaxing the length to the flip implementation in the routers, something like now 20 years ago, within the IETF, we can activity because we were afraid that the flip implementation, the line cards, would be going beyond what can be done and what ‑‑ kind of there is a cost trade‑off and I quite definitely, I quite definitely say we should keep the old borders, if we open up that we do not know how much cost ‑‑ how much cost we will actually force on to the hardware. And last ‑‑
MASSIMILIANO STUCCHI: We are running out of time, so please...
RUEDIGER VOLK: Last remark for your analysis of blackholing communities, kind of all of the communities that actually have a part where an AS number is in, kind of ‑‑ I would suspect or ‑‑ well, okay, quite clearly, if you have an AS number in the community, the community is kind of negotiated and defined by that AS, and if that community spreads somewhere else or that is kind of telemarketed to some distance AS, well, okay, actually I think that is essentially ever a bad behaviour or unintended and unfiltered spreading of stuff and you should actually ‑‑ you should actually kind of do that differentiation in your analysis as well. Kind of hygiene for announcements in the community space is pretty bad in many networks and that's actually a problem, that some of your colleagues, for example, Florian Streibelt, have been working for early on.
KHWAJA ZUBAIR SEDIQI: Thank you very much. So, on three points on community first, we understand that we have the lower bound analysis, communities might be stiripped by operators, might have been manipulated.
On the borders, keeping the border is an opening discussion and I appreciate the comment about the ROA and invalid length, I mean part of learning journey I learn that, thank you.
MASSIMILIANO STUCCHI: We have a question from the chat, from Meetecho.
ANTONIO PRADO: No more. But there was a quick discussion on your ‑‑ on the chat on your presentation.
AUDIENCE SPEAKER: Replying to Rudiger's point that routing table size could be an issue with IPv4 if we allow longer prefixes, we are looking at one million soon so we all need to replace our line cards in our routers anyway and also if we split IPv4 space into /24s it's already 40 million so I don't think this is a definite objection that holds.
MASSIMILIANO STUCCHI: Thank you very much.
(Applause)
Next we have Alexandros Milolidakis, who is going to talk to us about things that evade route collectors. So the floor is yours.
ALEXANDROS MILOLIDAKIS: So Hi all, my name is Alexandros Milolidakis, and this work, I am from the ‑‑ I am a PhD student and this is based on our recent article, so if you want to know about the full work, please read the article.
This is the outline of today's presentation, just to make sure we are all on the same topic I will start with background and introduce the problem about public route collectors, the lessons that we learned, our real world findings as well as suggestions to deal with a problem.
So, BGP hijacks keep affecting the industry with well known events documented here. For example, in 2022 hijacks affecting governmental infrastructure, as well as multiple suspicious hijack incidents documented from the previous year.
The problem begins because BGP was not designed with security in mind. Therefore, networks have focus on proactive based and reactive based solutions to identify and deal with hijacks. Today, although a lot of effort has been made on cryptographic based solutions such as RPKI and ‑‑ for filtering, these solutions are still not sufficient to capture all forms of hijacks. Currently that is. For this reason, for networks focus on reactive based solutions, so monitoring either the data plane or the control plane.
Monitoring the data plane has always been harder to commissionerise due to events and related to hijacking, therefore most of the success with commercial solutions currently focus on the control plane. Monitoring route collectors and looking glass.
So just a definition, a route collector is a BGP specific device which collects all the routes it receives from its peering names. The public route collector infrastructure, namely RIPE's routing information service route collectors and the route user collectors, etc., consists of a collection of multiple route collectors distributed around the globe.
BGP networks peer with these public infrastructure to publicly disclose the best route so we call these networks either monitors or BGP feeders so these networks, they connect to the public route collector infrastructure, they close best routes, then those routes are collected by the infrastructure and later analysed by commercial solutions such as Kentik, ThousandEyes, ARTEMIS, etc., with the help of either private data analysis framework or public analysis framework such as BGP stream.
To identify BGP hijacks.
Now, the problem begins because route collectors observe a limited view of the Internet, precisely those routes that feeders to disclose to public route collectors. A hijacker that observes what routes publicly route collector disclose for their victims with potential design hijack under the hood that is not visible by the public route collector infrastructure.
And to understand how this happens, let's go one step deeper to show you how a BGP feeder report its route traditionally to public route collector.
So what you see here is the routing information based so BGP feeder. The routing information based normally per the RFCconsists of three tables, local RIB, adjustment RIB out.
Receives from its inbound neighbours are stored in the RIB in, then from there if they pass, the best route, they propagate to the local RIB and from there to the RIB out and to the route collector.
Now, the problem begins because a hijacker that observes what route the route collector discloses for its victim could potentially design a less preferred hijack that won't be selected by the BGP best algorithm and won't propagate to the route collector.
Just to show you an example of such an attack, in its simplest form you can see a victim announcing it's prefix, /24 and the hijacker claiming to be the neighbour of the victim. That is not true, and AS 2 here sees both the malicious and the valid route. However, because the malicious route is longer, it is not reported to the route collector, because AS 2 is to propagate its most preferred route.
So, in this presentation, the example that I show you was rather simple but in this presentation we are now seeking to answer how hijackers are capable to design hijack not visible by public route collectors and essentially if I was to, we performed multiple hijack simulation as well as real world measurements and essentially if I was to summarise what we learned it's summarised in three bullet points. For hijacker to be able to achieve such an attack, knowledge about which BGP feeders will report the attack matters.
Knowledge of the hijacker about the routing policies of other ASs also matters. And where the hijack exports the attack and the shape of the attack also matters.
I will go with you now through each bullet to explain to you why this is the case.
So this is what we see here is an example of past BGP hijack incident of Vodafone accidentally hijacking contest prefixes and what you see here is the view as seen by BGP plane so how the BGP feeder is reported to hijack. I say this is a hijack, however this has been documented as an accidental BGP leak actually by the Cisco BGP monitoring service. In such attacks where the hijacker announces the same prefix as victim, they usually split the Internet into regions, one is the affected region and the other is unaffected regions. BGP feeder, in the feeder won't observe the hijack while BGP in the hijacked region will observe it. What is able to learn what is the affected region in such a way feeders in the affected region won't observe it.
For a hijacker to pull such an attack knowledge about the routing policies of other ASs matters.
We experimented with multiple type of hijackers, first a baseline hijacker so a traditional type hijacker which does not deliberately try to avoid route collectors. We did that to collect the baseline.
We then experimented with a realistic hijacker, such a hijacker it's how we expect the attack to be in the real world, the hijacker has limited knowledge about the of other networks and above the networks that other networks have in the Internet but can learn such an information from the routes that public route collectors disclose for their victim.
We also experimented with an omniscient hijacker that knows AS in the topology.
So using a simulated environment, we analysed from one day of measurements that the public route collectors disclose their routes that they were reporting and we extracted the monitors it, monitor ASs that were activity reported their routes. From one day worth we ended up with around 367 ASs that I have here in the X Axis and we performed multiple simulations to figure out what hijackers collected.
We experimented with multiple type of baseline hijacker, if you are not familiar with that, essentially the higher the type of the baseline hijacker, the less preferred the hijack is so the longer hijack that the hijacker announces.
So as expected, essentially the longer the hijack that the hijacker exports, the less preferred the route. So for type 1 hijacks we saw in 2% of our simulations they were completely ‑ type 2, 7%, type 3, 15 and type 4, 21%. Compared to those hijackers that actively tried to avoid public route collectors, they were stealthier, we were able to achieve 62% in our simulation and when they were visible they were visible by less monitors than user.
So and such hijackers can still make mistake. However, if the hijacker was to know the complete routing policies we show that the attack was completely invisible. As you can see in the line in the Y axis.
Yes, we also take the impact of such hijackers, we show realistic ‑‑ hijackers are usually more impactful than base line hijackers. We also experimented with future topology so flatter topologies with more and containing more monitors for our full results. Due to lack of time, feel free to look at our journal.
And where the hijack is exported, it matters. Not all neighbours of the hijackers are responsible for the hijack propagating to their route collector.
We quickly grouped the hijacker neighboured on where the hijacker was exporting the attack to customer peers and transit providers. What we saw is that essentially therefore baseline hijackers the length of the attack matters for peers. So, the longer the attack, the less visible it is for peers. However, that is not the case for transits because for transit providers routing policies matter more.
Realistic hijackers who were much more able to influence hijacks announced peers compared to hijacks announced to transits, such hijacks were quite visible still by realistic hijacker because transit providers care more about routing policies and not so much about path lengths. However, again if the hijacker was to know those routing policies the hijacker can design an attack, that is still stealth.
So, we also experimented with our attacks in the real world environment. We used the peering test‑bed, the peering test‑bed allows us to emulate with BGP hijacks in the real world. We set up a victim AS at the peering test‑bed website ‑‑ site at wins con sin, the victim was announcing his prefix and we set up the hijacker at GRNET site, at AMS‑IX and geonet and our goal goal was to try and design and stop the hijack that won't be visible by public route collectors. Essentially for hijacker to achieve that, the ability of the hijacker to identify the name servers monitors and the ability to circumvent the attack from reaching those monitors, it matters.
Unfortunately, the peering test‑bed was limiting our announcements so we couldn't utilise the full strategies that we wanted to use, but still, we saw that for a hijacker it's quite possible in some circumstances to identify all the dangerous monitors.
So we experimented with a binary classifier that was classifying monitors between safe and dangerous. If you remember this figure, essentially hijacks were the hijacker announced the same prefix, splitting the into two regions. Monitors in the unaffected regions are safe from the perspective of the hijacker. It's because the hijacker won't observe the hijack. While monitors in the affected region are dangerous that the hijacker needs to react against to avoid them.
So we experimented with a binary classified and actually two class fires. So proximity classifier that we tried to classify monitors between safe and dangerous based on the AS path length of the the hijack announcement (classifiers) and also business relationship classifier based on routing policies.
We experimented with announcing the hijacks in multiple neighbours, so three transit providers and three peers in the action IX, we selected those peers based on it's (AMS‑IX) ‑‑
What you see here is the number of monitors that were observing the hijack, those number of monitors may change a bit based on the hijacker location in ‑‑ of our announcements and we experimented with the classifier so its ability to identify essentially the safe and the dangerous monitors.
What we saw is that, as expected, the proximity classifier is not sufficient to identify complete the dangerous monitors. What we actually saw with our announcements, the interesting thing was that it could quite well classify the same monitors so our classifier was a bit over‑estimating those monitors. Compared to transit providers, we saw that for peers, we could sometimes completely identify all dangerous monitors, although, as you can see in the table, outliers may exist so it is not a golden rule.
However, announcing essentially a hijack to peer, the hijacker could take advantage of this vulnerability.
Now for a business relationship classifier, we saw that the quite well improves the identification of dangerous monitors. For transits at the cost of misclassifying some safe monitors.
So, I will conclude with this slides and with some suggestions also. So (these) in this presentation we tried to answer how vulnerable with route collectors at public route collectors actually at stealth attacks? We saw that route collectors may be vulnerable if the conditions hold. First, if the BGP feeders report only their best routes and if the route collector is public, a hijacker can take advantage of this vulnerability to design a hijack not visible by public route collectors.
Some prevention methods, obviously filtering helps, so if you don't use filter, please use filters. Recently I was also taking AS PA so autonomous system provider authorisation objects and from a theoretical perspective at least I can see that it helps to limit such attacks, so, when it comes also please implement that.
We also experimented with what happens if we peak feeders at new locations. It's harder to find which are actually these good locations so we started those ‑ locations but we can definitely see benefit.
Some other recommendations will be perhaps to think about the smarter feeder so feeder that does not simply report its best route but actually is able to identify suspicious routes to report them to the public route collector infrastructure and of course, implementing BNP BGP protocol monitoring helps although there may be some difficulties there.
And yes, thank you very much
(Applause) stuck tuck thank you. I don't see anyone with any question and we didn't have any on Meetecho ‑‑
DANIEL KARRENBERG: That can't be. Current employee of the RIPE NCC speaking only for myself. Thank you for the very interesting presentation. When I sort of had heard it all, my personal conclusion was what we need to do now is to keep the local neighbours clean so is that a (neighbourhood) would one of your recommendationing be to ‑‑ that every BGP speaker should be ‑‑ do filtering and be conscious of what's going on, not just the transits, is that a good conclusion?
ALEXANDROS MILOLIDAKIS: Yes, essentially if also that is interested in filtering, it definitely helps to limit hijacks, especially because those hijacks attempts are very hard to observe, so definitely it helps.
DANIEL KARRENBERG: And then second question is, do we have any great ideas on how to do that easily? Sorry, I know I am going to put you on the spot.
ALEXANDROS MILOLIDAKIS: Those meetings help for to get the community interested, as long as they higher networks, so the ASs is higher, yet more interested in security, I believe that, in the future, also, the ASs at the edge will soon get interested.
DANIEL KARRENBERG: Let's hope so, thank you.
MASSIMILIANO STUCCHI: There is a question from the chat.
ANTONIO PRADO: We have Emile Aben from RIPE NCC. What recommendation would you do for route collector projects like RIS? Should we try mitigate by finding the peers that make this type of attack as hard as possible, or is that a lost cause?
ALEXANDROS MILOLIDAKIS: I do not, of course, believe it's a lost cause. Now, what we need to do is, it's in my final two bullets here so if we can have a smarter feeder or if RIPERIS could implement BNP, I know there is some difficulties there, I am interested to learn why this has not been implemented but that will definitely help, at least to limit those kind of impact that stealthier attacks have.
Tom Strickx: Cloudflare. In the ideal world where RPKI is almost everywhere, as Pa is almost everywhere, we are running into position it's still possible, we are all human, automation breaks things, humans break things, there's always a possibility for leaks. With current export mechanisms, the likelihood of us being able to find these problems, is going to shrink significantly the better security improves
ALEXANDROS MILOLIDAKIS: Yes.
TOM STRICKX: The only way is BMP pre‑filter sending to route collectors is the problem is you can't distinguish between what's being actually seen on the Internet and what's trash that you are filtering, do you have other ideas or suggests that might be helpful in not a malicious detection which I guess this is mostly about versus configures more than anything else?
ALEXANDROS MILOLIDAKIS: So, first of all, I do not real believe that ‑‑ I mean, if we implement BMP we will definitely need one way to know what is the best route. And I believe this is an easy solution. I mean, somehow, we need to know this information, the BGP feeder itself will actually provide this.
Now for your actual question, sorry, I am a bit stressed so I don't remember it exactly.
TOM STRICKX: More about you are specifically talking about malicious attacks, right.
ALEXANDROS MILOLIDAKIS: Yes.
TOM STRICKX: If we go to a better routing ecosystem how do we detect non‑malicious configure mistakes more than anything else?
ALEXANDROS MILOLIDAKIS: The thing with malicious attacks is they try to seem valid or to seem like mistakes so you cannot really say that something, if something was BGP hijack you cannot really distinguish from a ‑‑ the hijacker will say sorry, this was a leak and how will you know? (From a leak). The effect is essentially the same. So it is really hard to deal with them.
Now, regarding RPKI, because you mention it, it's not ‑‑ it only Type 0 hijacks but not all kind of hijacks. And example that I showed you was actually hype 1, that RPKI won't help but AS PA will help.
RUEDIGER VOLK: Just one short remark. You are distinguishing between AS PA and RPKI, that's wrong. AS PA will be an object type in RPKI.
ALEXANDROS MILOLIDAKIS: Indeed, in that you are correct, that is how it will be implemented. So when it is ‑‑
MASSIMILIANO STUCCHI: It is how it is implemented.
ALEXANDROS MILOLIDAKIS: It is how it is implemented, noted.
MASSIMILIANO STUCCHI: Also Rudiger you were talking in the future but it is AS PA.
Maria: Developer of BIRD, I would like to ask, well wouldn't then be the best solution really how Tom was suggesting to have BMP or something like that from every single BGP connection to some feeder?
ALEXANDROS MILOLIDAKIS: Yes, so, to ‑‑ I mean, let's say that ‑‑ I mean if we have it from every feeder indeed it helps, let's say this is possible, actually no, it's not the best solution, and the reason is that from the perspective of the hijacker, if you report every route then the hijacker also learns something, so it's very predictable by the hijacker what routes the feeders have, so simple the hijacker needs to not reach these feeders and the attack is again stealth. If we have a smarter feeder the hijacker really doesn't know, what the feeder knows what are the routes there so it's much harder from the perspective of the hijacker to hide the attack.
So having a full BMP, it helps to reduce impact but stealth attacks could still exist, it would be much harder, definitely, for the hijacker to pull but it will be still possible.
Maria: So it looks like a possible topic for today's BoF on the AI S coming up?
ALEXANDROS MILOLIDAKIS: We can discuss that.
MASSIMILIANO STUCCHI: I see no more questions, we are actually out of time, so thank you.
(Applause)
Now to complete the Italian team in this session, there's Massimo Candela from NTT talking about geolocation so we change a little bit of topic.
MASSIMO CANDELA: We are a bit late, I am going to try to be shorter, so good morning, everybody. I am a senior software engineer at the global IP network of NTT. And as you can imagine also from the name the global IP network is a pretty big network and we are also not immune from geolocation issues and geolocation is the topic of today. I did some presentations in the past about this topic and but this is, I would say, quite an important status update and we will answer to the question geolocation problems, do we have a solution? And the answer is, probably, yes.
SPEAKER: Wow
MASSIMO CANDELA: Why status update. One‑and‑a‑half years ago with a bit more now, with a bunch of folks of our community, we did this RFC, RFC1992. We will see this RFC. However, the important part is no matter what technical solution you propose, it is good, as much as the adoption that basically manages to get. And this is what we will talk in this presentation.
But let's start from the beginning. So, what is geolocation, you have an IP address and you want to know the geographical location, where that IP address is connected and why you want to do that, to respect country regulations, to provide localised content, to ‑‑ for example, not only the language but maybe a specific movie for a specific country, to optimise latencies or you want to do troubleshooting, network operators for years have been annotating reverse DNS with geographic, I don't know, country code, codes, so that is clearly shows that that information is needed. And to do research. So basically, the geography is just another dimension of network and if you have geolocation problem you essentially have a problem on how content, for example, can be accessed through your network so you have a network problem. And ‑‑ at the end, please ‑‑ so, the ‑‑ why this issue, how this issue started, so essentially, it started mostly because the entire geolocation approach, geolocation grew as a, let's say an organised development and so there are the various regionally registries and they are not geolocation providers and they don't want to be geolocation providers so there are geolocation providers since that which are the one providing the service and they have their own data sets, and there are several I would say, many, and then there are content providers and CDN, they use the geolocation from the geolocation providers but they often have some patch for reachment of the data, locally they maintain. When you have some problem how do you find where it is, now the data is scattered across the various data sets so how do you correct it? There is no common strategy in general you go and see blog posts, tell you try to change this, change this other thing and in the end, send e‑mails. So essentially there is not a formal reproduceable amount of steps to reach a fix and this is mostly because geolocation is in general done by, I would say, guesswork, mostly on Whois data but also Reverse‑DNS, latency and stuff like this, and Whois geographical hints are a mess.
Also, you own these resources, well, you are managing those and basically there is no way for you to actually provide that information, you are not the source of that data.
So, in Whois, which is the basic source for many of the geolocation hints, there are two examples of attributes, there is the geolocate attribute which is supported from two out of five of the RIR which allows you to ‑‑ which is essentially the most accurate and human and friendly way to describe geolocation to annotate something so vague like an Inetnum, you can geolocate a /12 in your living room essentially. And then you have still 2 out of 5. You have the country attribute, that is Inetnum, works in three out of five areas but all the three they have different definitions, APNIC, is the country where the network is deployed, fine. The LACNIC is the country of the company that has those resources, and then you have RIPE, RIPE are the official documentation says this, this is reported here, which essentially says he has never been specified what this country represents, it could be the location of the head office, of a multinational company or where the server centre is based, or home, of end user, it can be whatever you like but it's mandatory, you have to put it. There is no definition of it but it's mandatory. So we had an issue recently in NTT about this because for reasons that I don't quite ‑‑ we moved our LIR account from the US to the UK, the one to RIPE, and basically for some reason, maybe some of our colleagues or during the process, I don't know, many of the country attributes they became from US to UK, and then all the prefixes that they didn't have geofeed they basically almost all in many geolocation providers they moved to the UK, I had a VM connected in Dallas but UK.
So, they are quite used, even if the documentation says oh, you cannot use it for this and that, they are quite used. And again, on Inetnum so if you would want to make this scale even if you would want to make it scale how many things are we going to put in Inetnum, also /32, I don't know.
How often does it happen? Quite often, 241 e‑mails about geolocation problems, none on mailing list up to September 2019 to two months an ago, one mailing a bit.
What do we want? To gain control of this data, to provide this data, and we want to be flexible. So we want to have a basically be able to specify this at prefix level or single IP level or want to do something like this /12 is in Italy but this /24 inside the /12 is specifically in Rome, we want to be a hierarchical even. We want to be flexible geographical level, country, region, city whatever and we want this to be easy, we want a lot of stuff, to be simple, like editing a text file somewhere, okay? In particular we do not want to send e‑mails to geolocation providers or to content, whatever tickets and stuff, we want just to edit a file and they have to pick it automatically. We have to remember in medium/large organises, most of the people do not have access to LIR Portal or to LIR so basically they cannot change this data (organisations) in Whois so what we want is essentially a way that once the system is set up I can just ‑‑ the network engineers they know where these resources are deployed, they can just add in their file whenever they want.
So the solution is, RFC1992, basically gives to the network operator the power to control the geolocation. What we did is we took ‑‑ basically, geofeed file which is a format, text format what's already that existed and it was already in use by geolocation providers and it was known by ISPs so we took something already people were familiar with and we just link it in Whois and this allows for various things. First of all is because Whois is Thortive for when you want to know information about resources you go there so that is the right place to start and once somebody puts the link and maybe you ask your colleague who has access to put the link, you keeping managing on the file, this is the idea. This allows also the geolocation provider so whoever wants to fetch this data, to just go fetch Whois date, find this file and basically know where you set your geolocation.
In addition to this, which is quite important, we provide a way to validate ownership of these files because ‑‑ so we said these were already used, so they were already shipped by e‑mail but how do you check that you own those resources, how do you even check you are who you are by e‑mail or authorised by the company and I receive various questions we check the domain of the e‑mail, stuff like this, so a list we provide a way to validate the ownership.
So easy, how do you do that? Create a CSV file, which is a simple text file, every entry, prefix, comma, country code, extra, region, city, there is also zip but don't go there, why you want to provide a Zip Code to match, that's why there is a trailing comma there. And then you put this file somewhere, you host over HTTPS this file and then you go find the Inetnum that encompasses the resource so they are described in the file, in the file that can be more resources so you have to find all the Inetnum that encompass basically these resources and you add remark in this format and the link to your file, okay?
This is an example of file. All fees fields are optional so you can put whatever level you want, if you don't put any of those it means do not geolocate, doesn't mean they are going to respect your wish. This is how you remark in the RIPE database, you are going in resources and going Inetnum and add remark. This is what it will look like after you do a Whois query and you have the file.
Now, important is do not forget to link from ‑‑ so imagine this is the file on the right, okay? And you have various resources. The way how the system works to validate is this Inetnum will validate these resources here, okay? So whoever reads this for example goes in Whois dumps, not fetching single, but the entire Whois dump and find the Inetnum and after finds a link follows from that Inetnum the link in the file and grabs only the prefixes inside the Inetnum, okay? This is ‑‑ so if you forget this link, for example, in this case, what will happen is this IP will not be fetched by geolocation provider so you forgot it and cannot be validated. Once you have it you keep editing the file as much as you like.
There is also a utility if you don't want to do this manually, mostly because there is at the moment more than 5% of geofeed files that they are like with randomised code, for example AU is not a code, various stuff. So, you can use this tool which is PacketVis.com/geofeed, which simplifies the entire process, and you go on PacketVis.com and you click, you set the prefix, next step is asking you the location, you can just type the CD, all the codes are correct and it will show you on the map so you cannot go wrong there if it allows you to go to the next tab. It tells you what you have to modify in terms of Inetnum. The system already creates and hosts the file for you so basically you can just copy and paste the remark in your LIR Portal and you are done with it you can switch to host myself, you don't download it, you host it wherever you want, just use it as a tool to create the code automatically and stuff and you click save and test and when you do, you will see that if everything is fine, so if your file was reachable from Whois and all the ice owe codes were correct and stuff, you will see this green thing here at the bottom and then you are done, there's nothing else to do, your geofeed deployment is correct and now the geolocation will provider it in general in one day maximum you will see and essentially ‑‑ there is an extra optional step check it is where it says it is, you have this anti‑abuse with a list of geolocation providers and will tell you at the moment where they see your prefix and the one in green are the one matching your geofeed file and they will also you keep checking this page in a few days since you ‑‑ more or less all green because the geolocation provider will start fetching this new data so you can use it to check and also as a sort of feedback loop.
And so it helps you with the correction of the data. But let's talk about adoption.
So another website that you can go is geolocate match.com, dedicated to the RFCthat I created, there is an ongoing experiment that crunches every day adoption numbers and when I did this screenshot it was less than two months ago we had 63,000 prefixes with geofeed, now we surpass 100,000 in basically a bit more than a month so this is pretty good. But even more important there is this table here which gives you a list of geolocation providers, that they are automatically fetching so they are supporting the RFC. And you see that they auto discovery for v4 and v6, there is an old screenshot, now there are more providers and you see how much time they take to fetch this data automatically and here there were some one day, some ‑‑ the last, if you go now on the website, many ‑‑ the majority of these it takes one day to automatically fetch this data. And there is one geolocation provider, only one of the ‑‑ missing, a lot of the effort behind this was also to talk with geolocation providers and interact with them and explain and support, and this geolocation provider which is missing now sends me an e‑mail a few weeks ago saying we almost have it and they gave me a data that is really close so when we will have that, we basically will have the entire market supporting that, the fetching of the geofeed but I will leave to them to do the announcement, so it's pretty good coverage I would say, we are using identity quite successfully to correct our geolocation.
Then, there is also in this page a way to do a quick test, this is only a test, it doesn't ‑‑ you just set it up however you want it. It's not a tool to set it up, it's just a tool to test it and it just checks that it's reachable and checks your ice owe codes and stuff and there is also this share on Twitter, I know Twitter is not fancy, let's say, like used to be, but anyway, if ‑‑ this is a way that I put there to help spread, so if you have all green this button will be green and if you click it says my organisation blah‑blah‑blah deployed correctly gey feed and in this way you help me and us share the knowledge about this solution.
So there is also an FAQ where you can find more information and you find also a file that you can download about all the geofeeds validated there are available at the moment.
So, my presentation is done, so quick recap:
So we do have a solution, a solution that works quite well, which at the moment I would say it solves many of the problems about geolocation and possibly in the near and near future will solve it all, at least that's my hope. And that you have also this utility, the first link PacketVis.com you can use to set up your gey feed and there's my brother in the audience today, he is behind this also, you can also ask him a question.
And there is also ‑‑ I can see Manuel is there. Geomatch.com to check adoption number and check more info and the RFCthat is here at the bottom if you want more information. So, if you have any question, please let me know, I think we have a few minutes.
MASSIMILIANO STUCCHI: We do have a few minutes. This is not very Italian, though.
AUDIENCE SPEAKER: Illich, actually, I am an anonymous person and my location is none of your business. I think this is all nonsense and I think the EU privacy privacy regulations agree with me because they classify IP address as a piece of information that can lead back to a person so GDPR, do with it.
MASSIMO CANDELA: It's fine, as I told you, the form allows you to even say that you don't want to be geolocation, you can express your wish about it which was a thing that was not possible.
AUDIENCE SPEAKER: You said they will ignore it.
MASSIMO CANDELA: They can ignore it, so anyway the reality is this: No matter how much you like it or not, the geolocation it makes your services possible, and if the geolocation is wrong, your services will not be possible, and then at least we can correct it, you can express you don't want to geolocated, this is where we are and this is what we have to deal with, the system is to help fix a problem and this is basically, if you don't want to be geolocated, I don't know, use VPN or another solution. I mean there is not really so much, at the moment this is how you access content, so at least we have a way to fix it.
PETER HESSLER: RFC1992 has two methods to declare your feed, one is geofeed attribute itself and one is a comment geofeed URL, I looked at the geofeed ‑‑ or the location information for the RIPE meeting, for the RIPE meeting prefix and they are only publishing geofeed attribute itself. However this database or this service you mentioned doesn't look at that at all, and so it only shows oh, you have nothing, ring Berlin, like last time.
MASSIMO CANDELA: No, what the services that I show, they actually read the geofeed attribute so if you did an experiment and it didn't catch it we should check why but it does read and I made sure it does read geofeed. The only thing at the moment the only RIR that supports geofeed attribute is RIPE and not all for all application, it became for me a bit complicated at the moment to explain why some yes and no and stuff like this and I realised, also, since it is a new attribute, geolocation providers, they basically rely mostly on the remarks because it's, basically it's the only solution at the moment that you can use to fix geolocation across all the five LIRs ‑‑
PETER HESSLER: Which do you recommend, one or the other or both
MASSIMO CANDELA: At the moment I would recommend the remarks, there is no clarity when it can be used, how and stuff, there is the DNS group on Wednesday I think, on Thursday, there will be a part dedicated to this, and also because the remarks are across all the ‑‑ you have more chance the geolocation provider would read the remarks against across all the entire thing, the gey feed is a reality in the RIPE and the tools should fetch it to test it.
PETER HESSLER: After the session let's just chat really quickly and I can know you what I saw.
MASSIMO CANDELA: Perfect, yes.
AUDIENCE SPEAKER: From ‑ global foundation. My question is, what about the content providers who have their own methods to determine geolocation? For example, we are the Swiss foundation, we have data centre in Germany and two years ago we got IPv4 allocation from RIPE which belonged in the past to a telecom provider in Russia, and some providers, content providers, still think we are in Russia, despite we put our coordinates and country code Germany in the Inetnum object and for example, Google thinks we are in Switzerland because well, our foundation is registered in Switzerland.
MASSIMO CANDELA: So the answer is, try to use the gey feed which would help in that case, also Google accepts gey feed directly on their portal which is not something that I am advertising they should support, just the normal RFC, but anyway, the gey feed is possibly something that will definitely help you in that direction.
What ‑‑ sorry, what was the first part? Oh, the content provider, the content provider, they fetch geolocation providers and I am in contact with some of them, including a big CDN and probably the biggest streaming provider and at the moment they are also in the process of implementing this. Sometimes it's difficult to understand where they are because they provide feedback that their pipeline is different. However, by fixing geolocation provider you essentially fix 90% of the problem and data they want to fetch data file directly is a good thing in my opinion because it may speed it up, may make the gey feed file even more authoritative, but try with the geofeed and should help fixing the problem.
Maria: Senior legal counsel. Thank you, Massimo, I just wanted to mention two things, about the country code and the Inetnum objects, on Thursday at the Database Working Group we will present some observations that we made from certain RIPE database use cases and one of them is relevant to what you mentioned about the country in the Inetnum objects and the fact there's no agreed definition over how these attributes should be used and how it was misinterpreted in some cases.
Now, regarding the geofeed there has been recently discussion in the Database Working Group about the geofeed attribute. Initially from a legal point of view we raise some constraints because geolocation was not supported under the current purposes of the database and therefore we ‑‑ as the community ‑‑ ask the community to agree if geolocation is a purpose that the database should fulfil to agree on that so it is documented and then for this reason we had suggested that technical limitations have to be implemented when the geofeed is used.
Now, we have recently sent another e‑mail to the Database Working Group, summarising the situation, and having in mind there has been consensus that geolocation is one of the purposes that the database should fulfil from now onwards, that the ‑‑ it is okay to be used but the privacy of the user has to be kept in mind because it is up to the resource holder themselves to decide the granularity of the geolocation information that will be inserted there and of course before inserting any geolocation information, the resource holder themselves needs to have explicit consent from the user, if we are talking about single IP addresses.
MASSIMO CANDELA: Thank you for your clarification, this is a point that is related ‑‑
RUEDIGER VOLK: You are responding to Illich, just get it, there will be no ‑‑ the service will not be available to you if you do not support geolocation. I quite certainly want to object to that kind of statement. I am a Level 3 networking person. Geolocation doesn't matter anything for the services I am concerned about. Kind of, yes, there may be services and service providers application layer that depend on it for whatever and there may be cases where kind of no service is delivered if they cannot figure out geolocation, but I have to say from my personal point of view, I probably will not want to use that kind of service
MASSIMO CANDELA: Thanks.
MASSIMO CANDELA: It's not this thing is now mandatory and everybody has to do it, just don't provide the data and also yeah, okay ‑‑ I mean, we are a backbone network and also we are customer complaining, oh this doesn't work because of geolocation so it is anyway related to impacting the services that you offer, even if you are working on a lower level of the network but still if you don't want to ‑‑ it is a way to fix a problem that there is at the moment, if you don't want to use it or fix it, just go ahead, anyway you have to be aware that somebody's making the geolocation decision for you at the moment. And it's out of your hand. The only thing that I'm introducing here together ‑‑ is a way for to you get some control of it, that's the final feedback of it.
MASSIMILIANO STUCCHI: One last question here from Kurt Kaiser.
KURT KAISER: Ordinary Internet citizen. I think there's so much wrong with that I want to to raise the issue even higher it creates artificial boundaries and walls and for me it's a modern way of racism, actually. It's more a statement than a question to make it better and I would hope that Randy would also be heard in the queue because he was also a long time waiting and hopefully I would like to hear him too, thanks.
MASSIMO CANDELA: Yes, I can agree with you, however we are in a system that there are also legal requirements that, for example, require geolocation so in the end, yeah.
AUDIENCE SPEAKER: This is nonsense, and Hollywodd wants to slice and dice gets to show, who, what, where, is nonsense,. We are here in the EU, I am revealing my location with moderate precision, in the EU we don't have borders, you can do business with everyone and we shouldn't support this kind of nonsense can canned how do you do data locality if you don't know what locality, how do you put the cookie pop‑up or enforce the GDPR inside the EU if you don't know the location of the end user, introducing GDPR introduce a lot of content to actually check the location of the user to respect it and that is ‑‑
AUDIENCE SPEAKER: You are completely backward, what they want to do want to know is this a non‑EU person so we don't have to be good private citizens, so they don't protect us, they don't stick to our rules, they want to ignore our rules if they can get away with it, that is the purpose of the geolocation.
MASSIMO CANDELA: Okay.
AUDIENCE SPEAKER: So we shouldn't want this. We are ahead here in the EU, we should export our privacy to the rest of the world, not import their misuses of personal information, we shouldn't import that from places like the US
MASSIMO CANDELA: When there will be no need any more for Lille and services will all fail, then we will just call it a day and close it but for now we need it (geolocation).
MASSIMILIANO STUCCHI: I think we have run out of time for the questions so thank you Massimo, thank you very much.
(Applause)
MASSIMILIANO STUCCHI: And before I let you go for the break, two things: There are the Programme Committee elections so please step forward if you would like to join us and secondly, please rate the talks, let us know if you like them and especially if you didn't like them. So thank you very much.
