RIPE 89
1 November 2024
9.30 am
Main Hall ‑‑ Plenary
SPEAKER: Hello good morning everyone, thanks for coming this early morning session, I hope that all the portions approved by the regions had their expected outcomes and no one got killed or abducted by the pirates.
So today we have one presentation and three lightning talks. After the presentation, it is very important to let you know that Ondrej will be presenting the final result of the general meeting so please do not leave the room immediately. If you want a grab a coffee, please go ahead and come back. So our morning's first speaker is Henry Birge‑Lee talking about global BGP events evade route monitoring, Henry.
(APPLAUSE.)
HENRY BIRGE‑LEE: Hello , my name is Henry Birge‑Lee from Princeton university, today I am going to talk about global BGP attacks that evade route monitoring, this work was done with Jennifer recognises Ford and Maria also at Princeton, let me begin by motivating the problem.
What is BGP monitoring and why is it important. Well I think of BGP monitoring as using a combination of public and/or private data feeds to observe global BGP updates.
And monitoring is really important because it cannot only be used for realtime responses to attacks but also a way to identify BGP attacks after the fact.
And as high security routing measures like BGPsec are taking a little bit to get adopted, I think monitoring is really important in the BGP ecosystem because essentially this is our way of finding out what's happening and detecting attacks.
So with that in mind, let me give a little bit of background also on stealthy BGP attacks, why is it interesting that an adversary can have a stealthy attack, if we are relying on monitoring for attack detection and mitigation, if an adversary can make their attack stealthy, they can evade defences and the hard resources they had to to invest in that tea tack cannot get burned. This is a really important problem and it's been shown to be possible and sort of a variety of previous works.
So at this point I think it's very important to clarify terminology. So what do I mean by a stealthy BGP attack.
And when you dig down into it, there's actually many different metrics which by an attack can be stealthy, the first one is how much of the internet sees your route, imagine you were to launch an attack in a small isolated Joe graphic region, maybe people wouldn't make that big a deal, 5% of connectivity for something is lost but stuff will go on as long as happy eyeballs, I am not particularly focusing on that today.
The other one which has been a major focus of research and I think the grip talks from Georgia Tech will shed light on is do you have algorithms that can pick out this attack from the noise of benign BGP you be dates and you can imagine an attack could be stealthy because you could make it look like all the BGP updates happening every day.
Super interesting topic, but not what I'm looking at today.
The other interesting one is okay, so you can have attacks, where actually the people who are using the malicious routes, so networks sending traffic and sending traffic to the add anniversary don't actually know they are using is because that route because the malicious route is not in their own network table. We also achieve this by this attack but the primary definition of stealth I am focusing on today is, do BGP monitoring services see the route? So on a long list of BGP updates generated by route views and RIPE RIS, does the adversary's BGP update get added to that list? So we consider it stealthy in this context if it's not on any of the monitors feeds anywhere.
Also, I think this is fairly common nowadays but in terms of attack terminology, there's sort of two paths an adversary can go: Either announce the same prefix of the victim that they are attacking, so this data centre on the right side is operating out of 222/23 and in the equally specific prefix tea tack scenario, the adversary announces that same prefix. In the sub‑prefix attack, the adversary announces a longer prefix, presumably with one critical resource in the data centre on it and they largely get global preference because it's a longer more specific match, longest prefix match routing.
Okay, so with that in mind, I want to talk about kind of the state‑of‑the‑art for where the community stands on stealthy BGP attacks. I'd say there's largely two camps. Camp one is you can launch an equally specific prefix attack and then do a whole bunch of stuff including communities, AS path poisoning an also just announcing to very few neighbours so avoid all of the public monitors, so there's actually quite a lot of ASes providing data to data to monitoring services and they can be avoided, so this is possible, my work as well as previously presented work at RIPE shows that you can do this.
The downside is, as I mentioned, there's actually a lot of monitors out there, so once you have chopped up the internet enough to make the strategy work, you are announcing over a couple of peering sessions, it's not a huge chunk of internet that uses your route, and also the people that do use it, it gets installed in the route tables and so, if you are able to get access to those or something is going on, an investigation, you can find it there.
The other interesting one I think came up sort of in more recent literature is that you can actually just stop the attack from spreading to the people that are using it. So you pretty much have to do it with a sub‑prefix attack, it exploits sort of routing with different prefixes so say there's/23, that carries to a provider that happens to have a /24, the victim doesn't show they are using a mall I shall route, super interesting but in the traditional sub‑prefix context, that prefix will spread through the internet largely uncontested, there's no victim announcement of the same prefix length.
And as a result like you see this attack at many, many public monitors. So I also want to talk about a real world stealthy attack, and this is an attack that actually happened some years ago. An adversary established a direct peering with Yahoo mail at DE6 and just announced over direct peering, just sent the malicious routes to Yahoo mail continued it did evade all BGP monitors, eventually it was used for spamming, the true victim own other after many complaints, they were able to find out that Yahoo mail had this route in their table that wasn't being announced by the prefix owner, they were able to to catch and that it's worth noting it was a hyper localized attack, it was routing traffic incorrectly for most prefixes this prefix was reachable and still doing okay. All of this together I think leads to kind of the current understanding on tell thee attacks which is that although you can make attacks that are sometimes completely stealthy, these attacks can only affect at most like 2% of the internet, so this is out of a previous work, an IEEE access and we were looking at the selective neighbour announcements on poisoning. So I think this s generally true, today I would like to present an attack that can affect the vast majority of the internet, is is seen by no BGP monitors and not even the networks that are going to be sending traffic down this malicious route see it in the route table. I think it's really important to step back and stun that all of the mechanisms we have and have successfully used to catch these BGP attacks can be evaded by this attack.
So now let me go a little bit into how do you launch this attack. So the key insight is to flag, have the adversary flag their route with the community known as no export. For those of who are not aware, communities are 32 bit tags that you can attach to a route and one of the many things communities can do is determine how downstream routers will go and repropagate your route.
The BGP communities introduced three well known communities, one of them is no export community and it says do not propagate the route outside your own AS, when it hits an AS boundary, you are supposed to suppress the output. It's important to understand this is actually baked into most routers by default because it's in the art of C, routers that support communities tend to have the functionality to honour the no export, they know what an eBGP session and then they suppress on those links.
But RIPE RIS and route views, the way they actually get the data is that they put into their BGP feeds is with eBGP sessions with major networks, so to the routers at those networks they think that's an eBGP session. As a result they go and and apply the no export community and don't send the update to RIPE RIS and route views and this is a large deviation from previous work in that previously we always assumed if a network that was providing data to RIS had a malicious route in their table, that route would be sent to RIS, we would see it in the updates feed. Obviously it's not used as best path, that's a different story but if it's selected as best path on a major network sending data to RIS, we should see that as an update feed but this technique we can put the routes in the networks and still hide them from RIS.
And as I said, this makes us be able to be much more effective than the previous work on stealthy attacks.
Just to visually demonstrate this. On the left side here we have sort of the status with prior works that if cogent 174 selects a path as best path, it's going to send it over its eBGP sessuib to RIPE RIS, they peer with RFC 25 and this is an eBGP session, RIPE RIS establishes their sessions out of 12654. It gets appended to the RIPE RIS updates logs. If the adversary tags the route with no export seen on the right side here, the route can actually enter the Cogent table. Cogent can use it as best path but still suppress on this edge to RIPE RIS. Now you have got into the route a major backbone, even a global backbone but it's not in RIPE RIS.
So what are specifically the steps for launching this attack? First, it starts by the adversary announcing a sub‑prefix of the victim's prefix. And ideally that's going to be en route for a lot of traffic. Now I understand that major transit providers tend to have prefix white lists specifically on their customers, I am not, I am going to talk about that later, let's assume that the adversary somehow by‑passes those.
Then the adversary attaches the no export community to their announcement and as I was mentioning currently monitoring services are run over eBGP sessions to so the the default behaviour is suppressed at these edges.
And then finally you get this phenomenon where a major transit provider has the route installed but not exported it to it to anybody and it's most effective if you target your victims upstream, so the providers being used for the victim traffic and you target in a network, you can get near 100% of the internet using that attack.
Yeah. So I want to take a brief pause to mention that everything I am about to talk about was done completely ethically. This is largely a hijacking ourselves approach, so this is our own IP space. All the nodes including the ones I am using as the adversary had authorisation to announce this so we did not test the social engineering or sort of filtering mechanisms of any major networks, we had authorisation to announce this prefix and there was no real services on, we were studying route propagation. In urban 9 set up, we announced this IPv6 prefix, the data centre had Cogent as an upstream, effectively the attacks were all global, all over the world where it's effective, we began with a benign or controlled case, not benign, control sub‑prefix attack, so we just announced a more specific of the adversary's prefix, this was effective in the data plane so the traffic from so you Paolo was being routed to the adversary, of course we looked in the control plane and this was totally visible, this is a BIRD 6 dump from the saw Powell client and it shows the slash 48 in the client's table, we had configured the Cisco cloud to throw an alert if we saw a prefix for the slash 47 and the active there means we did see the sub‑prefix, for this venue we were subscribed to RIPE RIS and if you notice peer ASN 174, this is coming directly from Cogent session with RIPE RIS, highlighted in red you can see the slash 48 so as we expected all of our monitoring systems were work correctly. We did not use the RFC defined river, Cogent has their own version which is 174990 with the 174990 community, the route didn't spread beyond Cogent. So none of the monitors and even the monitor connected with Cogent via direction link got the announcement.
But the data plane traffic from the client in Sao Paolo, we confirmed was being rerouted to the adversary.
So going through our monitors again, the client still saw the /47, it looked like a traceroute its route table had never changed, crossword include threw no alarms and our RIPE RIS feed was empty, looked completely like routing was stable and normal during this attack. We can confirm this attack successfully hijacked almost 100% of the internet. We did this by selecting a sample of 1,000 ping hosts. We set the source IP of our ping scan inside the hijacked net block. When these hosts generated a response, it would either go to the victim or the adversary, depending on how that host's network was routing traffic.
In the scan, 100% of responses went to the adversary. So every host we could find was routing traffic to the adversary instead of the victim. And I should mention that was as expected because the prefix owner exclusively used Cogent for transit, so they had one provider, we put the malicious route in that provider. If you are interested in seeing a video demo, you can visit it at this link. So we wanted to move beyond just a single isolated case to look at the viability of the attack in the wild.
I want to thank our partner networks including RGNet, NJedge and Princeton OIT office and we were able to test four major networks using their support. What we found is all of the networks honoured no export or some specific variant of it, all of them had a monitoring session with RIPE RIS. When we attached no export, they all stopped exporting the route over the monitoring session with RIPE RIS. We also tested this in Thousand Eyes and Cisco Crossword Cloud and noticed they were no able to see the route once there was no export tagged.
You also might be realising now that I am talking about no export, that also limits the spread of the adverary's malicious route, but you have to go and work out a time, it's not going to propagate from network to network the way traditional BGP hijacks do. How much of the internet can you actually get, if we ran simulation of AS paths between 150 random source destination pairs from the CAIDA topology and just assuming an adversary installed their malicious route in the four networks from the previous slide, they would be able to hijack 23% of those paths, 23% of them had one of those four networks on path.
If the adversary instead operated more strategically and shows the top five AS by CAIDA customer coin sides, so how many customers and customers customers do you have in that AS? Looking at the top metric, you improve this number to 39%, this is a pretty big difference from the sort of 2% that previous work was looking at. And it's largely enabled because you can now put routes into the large networks that are providing RIPE RIS data and not have it noticed.
And obviously if you just go and poison the routes of all of your victims transit providers, then you get up to near so 100% like we did.
I think it's also worth noting this requires a sub‑prefix attack, and one of the best tools we have to prevent sub‑prefixes is RPKI. Essentially, when you write an ROA, you specify how long the prefix can be announced in the global route table, so the maximum permissible length. But there is sadly one flaw that happens a lot with ROA configurations and I think it's justified by networks wanting flexibility but a lot of networks ‑‑ I should mention we are at very good coverage now at 50%, still 50% not protected, so it's quite relevant still but we have good ROA coverage. I was trying to get to is that many networks improperly configure the max length, so if they want to have more routing flexibility, they configure a max length that's longer than what they really need at the moment. So if you are announcing a /23 but maybe you are going do deaggregate in the future, you might have an ROA that says /23 up to maximum length /24, but that means an adversary can sneak in there and announce the /24 uncontested.
When you find kind of take all these factors together, the partial coverage and the fact that some people have max length long, a previous paper of mine look at how many domains actually had all of their IP prefixes somehow protected against sub‑prefix atax we came out with something around 30% domains have a the lo of IPs as well, normally DNS and a record providers and honestly it was only about half of these were really protected because of RPKI, the other half would just because they ran everything on /24, that's kind of the good old school way of stopping sub‑prefix attacks but not good for route table size. So RPKI progress is really great, we need to keep doing that but I personally think that doesn't in the short‑term do much to change the viability of sub‑prefix attacks which will remain a threat for the time being.
And then also I know I mentioned prefix filters. They are incredibly important. Know your customer is incredibly important, all of this is the front lines, it just that I think we also need back up because yes, sadly major tier ones will occasionally propagate a malicious route, these are just some NANOG list examples if you will, but this is definitely something that happens, even the best tier ones with the best sales teams and the best know your customer can potentially be fooled by creative determined adversary so I really think we need to rely on this but also have cryptography measures, backups and good monitoring visibility in addition.
So as I mentioned, I would really like to improve the situation and there are very concrete counter measures that networks can take.
So, at a high‑level, the counter measures revolve around this idea that a customer should not decide whether you send a route to route monitoring, like I, as an ISP shouldn't say I am giving you this route, please don't tell RIPE RIS about it.
You know. And there are several options for this. I would say the most straightforward is at ingress to a router, translate the RFC no export community into something within the local AS community name space and then on the normal BGP peers, you now have flexibility to decide how you interpret that community, and for normal peers do you interpret it the same way RFC specifies. For RIPE RIS you send all the routes even if you have the community tagged. Option 2 I have had some networks interested in is just move the sessions to iBGP. IBGP is not affected by these no export communities, this is being used by Kentik. There's a minor vulnerability with no advertise, but we have moved the attack from a localised to a single AS to localised to a single router, it's a much smaller attack vector. I would say the long‑term, and many people bring this up, we should move the monitoring to BMP. That would be really great. The engineering efforts behind that on the RIPE RIS side and network side still a little down the road but probably the proper long‑term move, because then the router fundamentally understand the difference between a monitoring session and another BGP peer. And as the middle ground, you could imagine maybe it would be nice if there was a flag you could put on an eBGP session that says this is actually a session for monitoring. So if there's a vendor support flag, obviously this requires a vendor to put it into their implementation. This is kind of a BIRD like configuration for a hypothetical AS 1234, I apologise if you own AS 1234 but you can imagine stripping these communities at import, replacing them with these AS specific communities that don't have the same baked in behaviour and then on BGP neighbours you match on the AS specific communities but for RIPE RIS you have a blanket accept rule. The other one is to move the sessions to iBGP so this is just a replacing with iBGP and in addition the next top self, there's several things like local pref and metric you could filter before you sent them to RIPE RIS. I think it would be really great if the RIPE NCC admins considered iBGP sessions it is being used by kin tech right now, I have interest in deploying these counter measurement atticlyESnet and internet 2 but I would really like to extend the invitation broadly to any networks that are interested in mitigating this, please reach out to me. If you are interested in more details on these attacks and more measurements, this the technical report published on archive at the bottom.
I really appreciate your time and I'd like to end by taking any questions.
(APPLAUSE.)
AUDIENCE SPEAKER: So I was wondering if we all just do BGP and we do RPKI, the problem that is measurable by the counter measures like by employing the counter measures already goes away, doesn't it.
HENRY BIRGE‑LEE: Yes. If everything does RPKI but that means that everyone also has to sign and everybody has to ROV. So I agree in a perfect world and the ROAs are minimally covering, yes you would cover with that but still have to have all those cases. We have not researched this yet but there's a chance to do it you could do it specifically with a specific attack but some traffic that would pop up on the ISP will be rerouted, I think these counter measures are much easier to implement than the whole world doing proper RPKI.
AUDIENCE SPEAKER: There is documentation like AS number ranges.
AUDIENCE SPEAKER: Just closing the queue. The first microphone.
AUDIENCE SPEAKER: I just want to point out that there is a flaw in the common use tool BGP PQ if you are using the plane as it is, put this output, it again rates AS paths which are vulnerable to these attacks because it allows sort of any intermediate RS, so if you put on a link on downstream and transfer as a downstream to put in such a route, you can simply add the original AS to RPKI is not invalidated and you can inject routes because even if the upstream is applying the filters using BGPqit will not detect such attacks.
AUDIENCE SPEAKER: Thank you for doing this work, this is very interesting, thank you for using IPv6 in your examples, it's wonderful to see, it seems to me you mentioned before that the equal length prefix would probably also at least capture traffic, that probably makes sense, the local will make the decision internally but I wonder if there's any correlation between transit providers who don't use prefix lists reliably and transit providers who don't do route origin validation, I am guessing there's a strong correlation.
HENRY BIRGE‑LEE: I think there is a correlation and I think there are transit providers based on people I work with in threat intelligence adversaries are different experiences working with different transit providers.
AUDIENCE SPEAKER: It seems to me there's also another mitigation would be to have better automation for creating ROAs because if you change, if you are using more specific lengths for traffic engineering, then probably just update your ROAs as you need them.
HENRY BIRGE‑LEE: I absolutely endorse automatically generated rapidly updated ROAs to accomodate traffic engineers and DDoS mitigation, it goes underneath the RPKI point as well. Thank you.
AUDIENCE SPEAKER: So everybody told everything I have to say before ‑‑ I have one more suggestion, if you want to filter and this is what's happening in network, Pascal presented routes collection tool in OpenSource,working group this week that would be really useful because then you would see whereas like an injection, somebody would be trying to inject a prefix within your routing table easily and because this is really efficient for that, if you didn't see that talk you should look at the collector because it's really well done, I think it's a decently good idea to not mitigate but at least see what's going on.
HENRY BIRGE‑LEE: Thank you, I will look at that.
VALERIE AURORA: Nothing online? All right, thank you so much.
HENRY BIRGE‑LEE: Thank you.
(APPLAUSE.)
VALERIE AURORA: We'll start the lightning talks now, we'll start with let's stop using licence by Jen Linkova at Google.
JEN LINKOVA: Hello, now when I hopefully get your undivided attention, I have a confession to make. This is obviously a click bait title, well it's actually correct title, just not complete one.
Well, so, yes I am obviously going to talk about IPv6 when I am talking about DNS. So how many of you deploy IPv6 only networks. Good. You need to listen and people, if you haven't raised your hand, you still need to listen because eventually we will need to deploy IPv6 only networks and then my lightning talk will be important. So if you deployed IPv6 only networks, most likely your end points need to run CLAT, so all those poorly written applications that need V4 will be tricked in believing they have IPv4 and then the CLAT customer side translate will translate everything to IPV6 and send it over the physical interface. Here is what I see on my laptop when I connect to RIPE network this week, right.
Obviously, to do the translation THE client needs to know which NAT 64 prefix is being used by the network. So, because when CLAT translates before IPv6, where is in the network there was a NAT 64 that will be translated back to IVP64 and send it to dual stack internet. As you can see, my laptop successfully gets the NAT 64 prefix from the network. Traditionally for the last eleven years, a lot of networks and a lot of clients were using RFC 7050 which allows you to detect NAT 64 by using our favourite protocol DNS. DNS can be used for anything, not just for name resolution, you can use it for detecting NAT 64 prefix, how it happens, your client trying to resolve IPv4 only name and trying to ask for V6 address of that well known name, here is what is happening in the network. Network announce your DNS server. If you ask normal DNS, let's say Google public DNS, you ask for a rear card for you only card, you get an IPv4 dress, especially one located Ayana, if you ask for QUAD A you get nothing because the an IPv4 only name, logical right. Now let's ask DNS server which RIPE network gives you which actually does DNS 64, you are actually getting QUAD A record back and you can double check, those last 32 bits. Now your client can take the prefix from the AAAA record and find out which prefix will be used. Great, right. What could possibly go wrong.
First of all there is, I know Jeff told us security doesn't matter. But the problem is you kind of rely on DNS, right. And this fundamentally would not work with DNS because DNS 64 designed to lie to you. You asking for something which does not exist.
So RTE 7050 has a security consideration section and does talk about security, yeah you need somehow to establish trust channel to your DNS server, somehow. It suggests using some security channel like VPN. So I have not seen anyone doing this.
So yes, you don't know actually are you really getting the correct answer and obviously there's a problem if your client is actually on before V4 only networks which doesn't have V6 security and someone tricked you into believing there's a DNS 64 and NAT 64 thinks it's very, very wrong, correct.
So there are actually other things which could go wrong, for example if I take my laptop and tried to resolve IPv4 only, and get AAAA I am actually getting nothing. Why? Because my laptop runs its own local resolver, it completely ignores what networks gives you as a DNS server and runs its local stuff. There is an RFC which suggests that local resolver needs to look in the network provider to resolver for resolving is specifically V4 only but nobody does that.
And obviously as I say, no DNSSEC, additional RTT and so on. A few months ago, some people were thinking can we solve this at least the security problem of 7050 and when we started talking about it, realised maybe we don't need to solve the problem of RFC 7050 because we have other ways of discovering NAT 64 prefix.
Again if you look at what this network actually gives you, it gives you NAT 64 prefix together with all other configuration for your network stack. Well if you ask me, obviously it's a much better way because I wrote that standard, so I am definitely biased. But yeah, I like getting everything in one packet, yes.
Yes, so now we have competing standard, great, right, we have multiple ways of doing the same thing and one of them gives you everything in one packet immediately and another one doesn't work with DNS, there's a security problem and gives you additional RTT so what can we do.
The solution is let's get rid of 7050. Well, as always with IPv6, we have chicken and egg problem, right? It's really hard to tell people please don't do 7050 because there are networks which have been doing that and not giving you pref 64 on the router advertisement and maybe there are clients which do not do pref 64 however the goal of the document is actually can be summarised in two consistent sentence,s please give prefix 64 your clients routing, you can keep your DNS 64 for legacy clients and so on but please provide prefix 64, it's better for clients. They can start faster without waiting for DNS exchange, right,
And if you are right in a client, please rely on pref 64 first and maybe only use DNS as a backup mechanism. This will be presented in Dublin next week and DNS OP on Monday, and I actually, that's all from me.
(APPLAUSE.)
Clear, right, we all agree.
VALERIE AURORA: Online question from Ondrej, RIPE NCC:
"In the RIPE meeting network, we support DOT and DOH withDDR, I think this passes as a secure channel between the client and a resolver."
JEN LINKOVA: This is how it started. The original version of the draft was yeah, can we use those shiney mechanisms to improve the plan to update 7050 and introduce security mechanisms there, then there was a long line to the microphone saying can you just get rid of it. You are like yeah, great, just get one way of doing things, will be much better so yes, theoretically we can look in that direction but do we really want to? There is a feeling like most people prefer not to.
AUDIENCE SPEAKER: This time I can make it to the microphone queue. Thanks for that work. Thanks for actually showing me what my Mac can do. It was enlightening to actually, after being here for five days in the RIPE meeting that everything just worked, look into the more detail and see the CLAT operation and so on. Thank you.
JEN LINKOVA: My pleasure. Instead of having kittens on the slide, I was going to have BCOPs on the slide and Andre showed me a nicer way of looking into stuff.
KHALID SAMARA: No more questions, thanks Jen. Finished one minute before time.
So let's dive into IXP from scratch by Marcel Koch
.
MARCEL KOCH: Hello everybody. I am Marcel Koch and I will present you IXP from scratch. IXP from scratch is article series on RIPE Labs we started publishing this year, we are founded in Dresden last year and the goals of the was mostly documenting what we have did through DD‑IX, gather feedback from the community and encourage others to do local internet exchanges and self reflect on design choices and actually think about them again, is it good idea to do what we have done.
A bit of history, there were already past efforts in dress den, sadly these did not succeed, last year we founded ourselves together and started DD‑IX, this is an association under German law, it's all voluntary work.
Earlier this year, we started our operational set up. We already helped multiple open tech meet ups, like a small network operators group where we gathered the local community and tell them everything we have done, what is going to happen in the future and get just together. We already have three peers, mostly local ISPs, and also we have multiple 1 gigabits per second traffic peaks and additional peers are awaiting cross connect and building their own workshop to start getting connected. What are the reasons we tried to build DD‑IX. This is a screen shot of a traceroute we have done before we had DD‑IX and we just pinged like a target from one ISP to another ISP and we went through the whole of Germany. As you can see with a latency of 12 miliseconds with DD‑IX we have a have latency below milisecond. Our motto is just keep local traffic local and it already kind of works. So IXP from scratch, we published two articles, the first of all building IXP, things you need to consider and the second focuses on the design choices we made and the third article focuses on the detailed implementation of the peering LAN, we also write to plan to right articles about automation and how we are monitoring traffic and IXP, if you have additional topics you want us to cover, please talk to us.
Now I want to give you a brief introduction to the second article, networks and security design. First of all an IXP needs services, first of all the most important thing, the peering LAN, you also need IXP management, in our case X manager and also monitoring stack to ensure the operation of the IXP.
Also because we are the German entity, we have paperwork to do and accounting stuff.
We segment our network in some parts. First of all, the peering past with the peering LAN or route servers monitoring, then of course some kind of management access for that we just have a VPN, we can access our infrastructure remotely. We also have management infrastructure, for example a file storage and identity managment, stuff like that, and also our hypervisor and the below path. Everything is connected through a firewall and also has access. We tried to build the management infrastructure IPv6 only, sadly we did not succeed fully, most of it is IPv6 only, some external APIs that are automation uses and IXP manage uses do not support IPv6 currently and also NIXOS operating used for the management structure heavily relies on Github and Github does not support IPv6 currently, so we still have some private IPv4 addresses.
On the operating side, the operating systems side, we chose align Linux and firewall, we used it in diskless mode, it means the whole operating system is on a templer face, it's loaded and boot. The disc does not need to be used any more. It has a really small overhead and just basically kernel and the routing daemon at BIRD. For NIXOS, we have everything in the configuration file, you can deploy the configuration file, each deployment generates a generation which you can select an alter generation if you approximate something and also pretty easy to deploy.
We also isolate our services because we have one management host and don't want to implications to interfere with each other, because the automation stuff is kind of critical, we don't want anyone to be jable to inject something in our cloud service peering LAN. For that we use micro VM, to deploy virtual machines using KVM, they are diskless and we can share persistent data using a simple mount point with the whole system,
If you have any questions, feel free to ask and also these are like our localized peers and sponsors that helped us with knowledge and also money. Thank you.
(APPLAUSE.)
VALERIE AURORA: Thank you for that great talk.
AUDIENCE SPEAKER: I have a question to slide 17. Can you publicly document which ones were also giving problems because at one point I am going to get there as well so that would be nice to know, because Github is why I have a NAT 64 gateway.
MARCEL KOCH: Yes we are going to do that, thanks.
AUDIENCE SPEAKER: So speaking a bit like a person who was, well thankfully in some way involved in what happened in esix ten years ago and you kind of missed one of the most important points of an IXP which is a community and community building because this is a technical presentation, I see the presentation list like the RIPE Labs article is, it's all about technology but in my opinion madeesix great was the community building around it and I would really appreciate to get that more out as well in how you actually start off such a community.
MARCEL KOCH: We already did multiple open tech meet ups, everyone was interested we got like everybody... from the city itself, most companies of the city that were networking and it was really nice evenings and we also like exchanged technical details.
AUDIENCE SPEAKER: I just wanted to thank you for actually documenting your efforts because a lot of companies, communities around the world build exchanges and they keep their knowledge for themselves or share it in closed user groups. I think it's particularly the effort you are making here very valuable to a lot of people who are probably not even sitting here in this room. Thank you.
MARCEL KOCH: I appreciate that. Thank you.
(APPLAUSE.)
VALERIE AURORA: Thank you again. Our next talk is observing trends in internet routing security by Iliana from the Georgia Institute of Technology.
ILANA XYGKOU: You can hear me. Perfect? So yeah, hello everyone, today I am going to present to you some very interesting trends that we have observed in internet routing security and this work is a joint work with Professor see Celia and the adviser Professor dane /OTity.
So we start this talk with a question for you, what do we know about routing incidents and by routing incidents, I mean both actually malicious hijack and also configuration mistakes such as fat fingering traffic, it can cause major financial losses and potential higher scale it can link back national security and unfortunately about these events, most, the most knowledge that we have comes from some anecdotal evidence and due to the high scale, they make it to the news.
So in order to illuminate the BGP incident space, we have grape, it stands for global routing intelligence platform and BGP and detection monitoring system. Grip has been around Georgia Tech for the past four years. In the following slides I am going to present some preliminary results that we have obtained by processing on the BGP data from the past five years from 200019 up to 2023.
But firstly let me give you some high‑level background on how grip works. So the events we are delegating such as those that lead to routing originalation and route hijacking, they generate specific types of events such AS most prefix or prefixes that are announced by more than one AS, or even the appearance of a new level topology. So, using the BGP from RIPE RIS will detect all of these BGP events and then greet one for each one it will add informational tags based on additional dataset such as CAIDA AS rank and RPKI, in order to build a complete picture of the event.
Finally, we have tailored a big set of rules which examine the assigned tags, the assigned informational tags of the event in order to eventually classify it as legitimate or an incident. Let's see what we have found so far. By focusing only on events that lead to routing originations, namely MOAS and sub MOAS events for IPv4. First some high‑level findings is that grip, most of the BGP events are edge legitimate and they remember mange 15% is marked as incidents.
Most of the incidents exhibit patterns of misconfigurations, these include forgetting the tied traffic asaspath prepending mistakes, we see RPKI related mission configuration, even though all the originally ASes are related to each other, there is not all of them are covered by laws, in order to be authorised.
Then only 2% of events exhibit patterns and another 2% might be attacks but we don't have any clear indications to explain the nature and that's why we also call them unexplained.
So if we look into the data in terms of numbers from 2019 to 2023, we start seeing number very interesting trends.
First of all, some very good news is that misconfigurations seem to have been decreasing and even if we break them down into the different types of configurations, we see that this decrease is dominated by the decreasing trend of the prefix fat finger mistake.
Nevertheless, we see similar behaviour for the other types of misconfigurations as well, for example the AS path prepending, except for a spike during the pandemic.
So now let's take a look at the other category of events, that might be actual attacks. Here unfortunately we see that they remain somewhat steady across the years.
So we break attacks into two components, namely events that exhibit patterns of attacks with the purple line and events that might be attacks but we don't have any clear indications to hint at the nature ‑‑ the blue test line ‑‑ we see that the unexplained events have been decreasing over the years while the attacks that, those events labelled as attacks have been increasing. So we wondered where does this invasion of trends comes from and it's largely due to RPKI invalids. So the growth in the RPKI ROA deployment and we speculate that the increasing the RPKI ROA deployment correlates with the version of trends that we saw in the previous slide because now it allows us to mark an event as clear incident due to the RPKI invalids. Actually RPKI provides more visibility to BGP events, which is intuitive but still very good news and this is all thanks to you and the community who have been pushing for RPKI and who have been publishing ROAs to protect the network spaces.
So, finally as GRIP is a system that we want to keep improving it in order to increase its utility for the community and other users. To do that, a very important first step is validation of feedback from network operators. Because after all, network operators are the only ones who can tell us more sure what happened to the networks or at least let us know of the nature of the event, whether it was legitimate and intended or it was hijack or misconfiguration.
Then GRIP is a very complex system to operate and it requires developers and researchers to improve and implement the detection and interest methodologies. And it requires more funding to be able to support the system.
I would like to close this short talk with more actionable note. It takes a village, including you, the whole community, from network operators to researchers to policy makers to build a reliable tool that will help us understand what is happening on the internet today, with the ultimate goal of improving security and ensuring its integrity.
And that was all from me. Thank you so much for your attention.
(APPLAUSE.)
AUDIENCE SPEAKER: Thanks for bringing this tool to my attention, I didn't know about it, I have been playing around it, it's finding interesting things. There's one shortcoming. There's no V6.
ILANA XYGKOU: That's true and we are planning to incorporate it as soon as possible. The problem with V6, there are different dynamics happening in V6 compared to V4 so, yes.
AUDIENCE SPEAKER: There's no V6 to the server so I have to use IPv4 to do my queries. I didn't check the IPv6 data but there's no V6 transport and that's easy.
ILANA XYGKOU: Noted. We'll take care of it, thank you.
KHALID SAMARA: Thank you. So it's nearly the end of the session...
(APPLAUSE.)
Thank you Aurora, I will hand over to Ondrej Philip, the chair of the RIPE board IPv4 presenting the result of the GM.
RESUMPTION OF THE GM ‑ RESULT OF VOTE:
ONDREJ FILIP: Thank you very much, I think we should wait until 10.30 is announced for the remote
participants, so give us a few seconds.
KHALID SAMARA: All right, thank you. That's the end of the presentation, thank you everyone.
(APPLAUSE.)
Coffee break.
