Open Source Working Group session
26th October 2022
10:30 a.m. Cyber resilience
Ladies and gentlemen, we will start in a few seconds to please sit down.
ONDREJ FILIP: Let's start please. The moment is here, something you have been waiting for for six months, the favourite working Group at the RIPE meeting, something you dream of and now it's beginning. So welcome to Open Source Working Group. I'm Ondrej Filip and this is Martin Winter. We are to apologise the co‑chair, Marco couldn't come, it's a pity, I am sure he is watching remotely.
Let me guide you through the administrative stuff. This is the agenda for today. We'd like to ask you if you have any additions? Usually there is nothing, so thank you very much.
Also, we need to approve the minutes from the last meeting, they are finished on time and published on the web page, we haven't received any comments but just in case, is there anybody who want to change something there? No. So then I will ask you to object if you don't disagree with the minutes. I don't see anything ‑‑
MARTIN WINTER: Then I can talk, we had, as always in the fall we have like a working group Chair election, we sent out an announcement, there were no candidates, and all three of us are continue to stand to no changes there. If you want to become a working group Chair, the next chance it for the fall meeting next year basically, about two months before we'll send out the announcements for that one.
ONDREJ FILIP: Thank you very much.
MARTIN WINTER: Our talks today. We have first Maarten. Then we have Annika, she isn't here, she will do it from remote, talking about the infrastructure as a code. And finally, we have Lefteris doing a demo, you may have heard his lightning talk which I believe he had yesterday from connect, he will do a bit more in details and do a fancy demo today about some of the BGP prefix hijacking detection.
Basically, with that, let's get started.
ONDREJ FILIP: I forgot one thing to introduce the ‑‑ Michele is taking minutes an Anand is monitoring the chat. So thank you very much for that.
MARTIN WINTER: And never forget the fantastic scribes.
MAARTEN AERSTEN: Good morning everyone my name is Maarten Aersten and I'll talk to you about the cyber resilience act. We make open source software and try to contribute to policy making efforts. Let's quickly see if the coffee worked. Can everyone who is relying on open source software in their networks or organisation raise their hand? It seems like coffee is working. So now, can everyone who is developed or has contributed to open source software in the past raise their hand?
Coffee is still working, excellent.
So let's get started.
So, the European Commission has regulated services, or is regulating services under the NIS two directive, and this is about digital services. But there is more of course and now they see two major problems for digital products. The first ‑‑ and this is all very abbreviated, you are get I go my summary of 80 plus pages of legal text, is that they see a low level of cybersecurity in digital product. And the other bit is that end users have an insufficient understanding and access to information about the security properties of this software.
So, what are they going to do? They intend to regulate product with that digital element. That's their definition, but it basically means all hardware and software that will be available in the European market.
So, the short of it, as told by the someone working for the Commission, is basically that they are trying to remove some holes in the cheese and this is a metaphor spoke to me as I am a Dutch man, but that's what they intend to do.
Now, the way they are going to do it, or they propose to do it, is through product certification. And if you live in Europe or have ever bought a European product, you may recognise this symbol, but that's what they are attempting, they attempt to put the same scheme product certification under the CE marking on software and on hardware, which is quite serious if you ask me, but that's the regime they are trying.
So what does it entail to be a certified product under this regulation?
First of all, it means meeting some minimal security requirements and requirements for vulnerability handling. In order to be able in the future to have this stamp, they propose you meet a minimum barrier.
Then, there are requirements to provide information to end users.
And finally, there is risk assessment involved. So you have to assess risks, make paperwork and technical documentation proving that this is ‑‑ you considered this as a developer.
And now, if this were the only thing, then it would be some work. But there is also of course the compliance aspect, namely you need to prove that you actually comply with the standards as being set.
And this is important, because the level of criticality of software in a proposal determines how this works. So if you have a product, you may do this yourself, do a self assessment, produce the paperwork and then you can affix the CE mark. But once your software is so‑called critical, then you can no longer do it yourself but you will need to get an auditor involved and I see some frowns but let's dive into that a little bit deeper, because critical software is on a list in the annex, and you may if you are able to read this, recognise some of the products that are on that list, including router switches, remote access software, etc., etc., so most of the, in my view, software that runs the Internet is in the critical bin, which means that you would have third party audits.
Now, why I am talking about this? Well, because we make some software ourselves, right, and during our first reading, we felt that most of the software we make is actually in this critical bin, so, this proposal may affect the foundation that NLnet Labs is a 16 person outfit. But this talk is not about us, because we feel that it's nice to meet these minimal barriers and perhaps we can spend some money to make this happen. Why I am standing here is because I know that not every open source developer is able to meet these requirements, and perhaps we should be helping them spend time on their code instead of writing paperwork.
So, is there some exception perhaps? Well, there is actually an exception, which is really nice, and so the European Commission wrote in their initial proposal that in order not to hamper innovation or research free and open source software should not be covered by this regulation.
There is a little caveat though, because there is this text about "Outside the course of a commercial activity" so what does it mean?
Now, they actually give some examples. They don't define it but at the give some examples. So a commercial activity might be characterised by a number of things, the most obvious being charging a price. But there is also this thing, the charging a price for technical support services.
So, maybe good for a question and see if the coffee still works. Does any one of you rely on open source software and support the organisations or developers that do so by, for example, paying them some money? Raise your hand. Coffee is still working.
So, that would classify as a commercial activity. But we don't know what the full scope is because these are just examples, right.
So, this proposed regulation creates a distinction between open source development which generates no income, some income, and full income. And we can ask questions about this. Because, there is legal uncertainty in knowing in which bin you are, right. Is the thing I am doing, is that a commercial activity or is it not? For a lot of open source software development, it's definitely not a commercial activity, and I am very happy to read it but there is also quite a lot of people, and some of you raised your hands just now, who support open source development which may well be in this commercial activity bin.
So, for those people, there will be compliance costs. Especially if the software they are making is in what ‑‑ is considered to be critical, and my guess would be, but you tell me, that this may well be the software you support. So the question is: Can these single developers, groups of developers, can they carry this compliance cost, or should they instead be focused on improving their software?
So, the next question is: If you are currently an open source developer doing this for nothing in your spare time, but you feel that you want to spend more time on this software and you want to earn your living doing it, will this new piece of regulation stop you from doing that because it will not only make you jump from your current job to being self supporting based on your development efforts? But it may also mean that you now have to bury the compliance cost of proving that your software meets a minimal barrier.
So, to be clear, I am not arguing against minimum barriers. The point here is, you need to prove it, and when your software is critical, then you may have to pay for auditors.
So, that's a question I have.
So, the final question I have with regard to this distinction is whether organisations that are not in the EU, which are a lot of countries and a lot of people, will they start avoiding EU ‑‑ software on the EU market because of this regulation? And I don't know the answer.
So, my question to the commission would be, and perhaps also to people in the audience more knowledgeable on this topic than I am: Why are we actually making this distinction? Why are we distinguishes between open source software developed by volunteers and as part of a commercial activity? What's the purpose? What are we gaining? Is this about catching rat hat? Is rat hat really the way why we're writing down this? Or is there maybe no ‑‑ and I don't know, perhaps the people have thoughts.
So, alternatively, if it's too broad to make an exception for all open source software, should commercial activities perhaps include some language around for profit or not for profit? I know some companies like writing routing software, and they offer support contracts. They are not living on it though, so, should we include these or not if they are not for profit?
So, at this point, like I said, I have more questions and concerns than answers and solutions. And that's actually why I am here today, because I would like to hear from you how does this affect you, how does this affect the projects that you depend on, perhaps spend money on because you believe they should continue.
So, track this legislation. If this is important to you. Because the way democracies work is that we have to get involved if things matter. So, please consider the Cyber Resilience Act impact on open source for your infrastructure.
And as an aside, I am not talking about the product liability proposal today, but there is a separate piece of law and it has the same commercial activity language. So, if ‑‑ that's a whole other talk for another day but make sure that you understand that there are two things going on right now with regards to open source.
So please talk to us when you have similar concerns, you want to team up or perhaps you can invite us to places that are effective at filing of these sharp edges. And I'll take questions if you have them, and otherwise I have a quick quiz for you.
MARTIN WINTER: Any questions?
AUDIENCE SPEAKER: Benedikt Stockebrand. The situation is worse. I have had the opportunity to learn about a couple of Euro norms relating to networking and they were written by people who simply didn't know what they were doing. So if there are some standards applied that remotely look like that, we are in a real mess. And the second point is IT is developing fairly fast these norms don't and standards. So, how do they actually want to catch up with the development when it comes to certification or auditing or whatever?
So the problem is even bigger. That said, considering the quality of some software you find in the market, I actually think we need to do suspecting, the big question is are there any ideas than what politicians who don't understand the business apparently to some degree are currently proposing?
MAARTEN AERSTEN: Thank you for your comment. Any other questions? Otherwise we'll do some more hand raising because I think that's fun. There is a question.
AUDIENCE SPEAKER: Sorry, I have actually many questions. Vesna from RIPE but speaking for myself. Actually, the first question is what is the timeline for this legislation and when can we, as a community, contribute and make sure that this is done in a better way?
MAARTEN AERSTEN: So this is currently a European Commission proposal. There is currently open feedback period where you can give your thoughts to the European Commission. And as the European policy process goes, then there will be a position of each member country, so, if you have thoughts about the issue, you can also share them with your own government. Finally there is be a phase where the European Parliament get to have a say so if you have a favourite member of the European Parliament make sure to let them know what you think. So then this process comes together and you are asking about time lines my understanding is that I want to get this done so there will be the next one or two years where this is going to be worked on but it all depends of course on how many questions are received, etc.
VESNA MANOJLIVIC: Is the initial reason for this the consumer protection?
MAARTEN AERSTEN: No, it's actually ‑‑ partially perhaps. Because they also explicitly mentioned in a text that they want to make sure that these essential entities under NIS 2, for example IXPs etc., etc., that they ‑‑ the products they rely on meet a good level of security. At least a minimal level of security. So this is also about our critical infrastructure in a sense.
LEFTERIS MANASSAKIS: Just one more quick one ‑‑ okay, never mind. I'll come back.
AUDIENCE SPEAKER: Peter Koch, DENIC, because I heard Ben say this was all bad and coming out of the blue. I would like to remember people in this room and the broader community that first of all, this is the Commission's response to IoT more or less, right, it selects IoT with ‑‑ that's how they sell it in the broader context. And we have had a multitude of presentations that was saying that all these IoT devices and unmaintained devices, this is all bad and it's a real, real danger. Careful what you wish for. This is the response. But luckily there is at least until December to submit further comments, you might want to go into further detail.
And also, there is an inter‑connection between the cybersecurity act, the cyber resilience act and NIS 2 and this needs all to be put into perspective, and unfortunately it makes things complicated especially for providers of critical infrastructure that rely on open source because if you are out of one regulation you are still in for the other one so we're talking about supply chain and so on and so forth. It's not about the whole couple of things going on at the same time. It needs more attention. Thank you for bringing it up here.
MAARTEN AERSTEN: Thanks for your comment. I wholeheartedly agree.
AUDIENCE SPEAKER: Niall O'Reilly, RIPE Vice‑Chair, among other things, but this is mainly a personal contribution. Peter got there before me, thank you for bringing this up, but also thanks to somebody who is not here who published a blog post just recently about this, Olive Koligman (phonetic), we need to address this in the same way that we made progress modifying the NIS 2 for the route server operators, and I think it may be worth making the distinction between open source software which is open to inspection, and proprietary software which is much more difficult to analyse, and is less scrutinised, or not scrutinised on the same scale as open source. So there is a job of work to be done here, and I'm not sure who the best players are to move towards that result, but the first thing is thank you, thanks to Olaf.
MAARTEN AERSTEN: I can wholeheartedly recommend the blog post. I reviewed it and contributed to it, so it's good, it goes into more detail with respect to the articles, so if you think this is a good talk, then go read the blog post. The link is at the bottom of the slide.
MARTIN WINTER: Last question.
AUDIENCE SPEAKER: This is slightly octagonal. Is this the submission also considering the funding model when they think this software is critical. Is there some talk about giving the public money for the public code so that all the, like, governmental institutions actually are contributing to the free software and open source code?
MAARTEN AERSTEN: So, this is actually a point that Olaf makes in his blog. There are ‑‑ like, the European Commission has ‑‑ is supporting open source software development, both in words and in money. So, in that sense it's kind of curious because if you are taking money is what you are doing a commercial activity?
MARTIN WINTER: Okay. Thank you very much for your talk.
Next up we have Annika. She will be remote so let's hope that works.
ANNIKA HANNIG: Hi everyone, I am sorry I can't be in person. Let's try to make the best of that and have a small presentation about infrastructure code, how you can deploy your critical infrastructure using open source tools, and I prepared some slides. Let me show these.
So, welcome everyone. So why do we want to do this? Yeah, you can already imagine, code is actually a nice thing ‑‑ well call me biased but I think code is still a nice thing, and you can have it revisioned, you can have versions, you can collaborate on it with multiple people, and you can of course reuse fragments of code you have already written for other things. So, in order to automate everything, this looks like well, a good idea to maybe have infrastructure also represented as something well text based maybe.
Okay, so whenever I am thinking about automation and deploying infrastructure, of course I think about IX API because it was an effort to provide this, and of course the other thing we need for this is a tool for actually interpreting this code, and making all these API calls to then provision things. A popular one is Terraform, you might have heard it and have already used this. What is the IX API? This again was the shared effort by Internet exchanges and other players in the market to provide a common interface to Internet exchanges to provision services and networks and stuff like this. And it pretty much looks like this. There are tonnes of enter end points for provisioning product, for provisions network service, network service configs and so on, managing accounts.
What is Terraform? So Terraform is a tool for basically wiring all this together, I see I don't have to rush it like this so I can take a breath.
All right, so what is Terraform? Terraform is a tool for basically doing this. You have a config file where you define resources, data Zorz, and using so‑called providers. These configurations describe your infrastructure, like for example an EC 2 instance at AWS where you, for example, provision your application server on there, or maybe in the IX API context you can for example say you manage a MAC address for a customer and so on. These are resources and data resources and the whole state of your infrastructure is then locally tracked by Terraform, and whenever you apply changes, it ever will react to this and propagate these changes to the infrastructure.
So, what is a data source in Terraform? A short production. Terraform provides data sources where you can retrieve read only data from a provider like for example the IX API or AWS, or whatever else. You have in this read only data, usually the possibility to provide filters and create a declarative query to for example get all required network features of type route servers for a given network service. Or to show, for example, other things. I will get to this later later because I prepared a small demo and we will get our hands a bit dirty later on.
So, how does it do this? It basically is them making this API request, filling out of these, for example, query parameters, and getting back a nice Terraform state.
This conversion from request to Terraform state is then done by the Terraform provider, usually using an API client. Luckily for us, we wrote the IX API as an open API document and then could derive, well with some manual tweaks, we could derive a client from this. The client is also open source and you can find it on our GIT labs site and there is a small example of where you can see actually how to use this, this client was written in go. Terraform is also using go, so this already was a good match.
The other really important thing about Terraform would be resources. So what is a resource? Resources ‑‑ a resource is basically an entity which is managed by Terraform completely, so if you declare one here, it will be created on the server side, and if you change anything, and here the change will be then applied using API code. So changes in this config which is the source of truth of your infrastructure, will then propagate to the server.
All right, so how does it do this? It makes a request. For example, in the IX API context, you have to check out, for example, if this ‑‑ you check the operation like for example Mac creates a MAC address which will register a MAC address on the server and then it will get back a response, which is then imparted to the Terraform state.
All right, this was fast. I hope I didn't lose you all. But maybe everything gets a bit more clear if we get our hands a bit dirty and check out what we can actually do with the IX API and with the Terraform client, with a Terraform provider with some window I want to share.
What can you see here? You can see here an initial more or less empty Terraform file. In this header part you would specify required providers, in this case the IX API provider. Usually you would then say yeah, okay, we also need, for example, AWS or whatever else.
So the next step you kind of have to provision your ‑‑ or kind of to configure your provider. I had coded this in here for the demo to reduce any friction, but in all of these keys you can also also use the environment variables for these.
So in practice, it's always a bad idea to encode or to put credentials in your source code. You shouldn't do this. But to illustrate how to use this provider for now, this is in here.
So you have the API end point which is currently pointing to IX‑API Sandbox running locally in my machine. Got an API key and an API secret I just filled in here, and now we can, for example, just define some data source. So if we are, for example, interested in querying for IX‑API for facilities in for example a metro areas, so you find a data source where you say yeah, we are using from the IX‑API provider, we are using the data source facility, so we are making a facilities query for a given metro area. However the metro area is an ID which needs to be derived from another data source. So, we kind of need to vary first the data source for metro areas, and luckily for us, we don't have to deal with IDs directly so we can just query for an a code, get back for example all the facilities in a given metro area. So when I now run Terraform apply, this all worked. The infrastructure did not change. So it now made a plan. It's reading the metro areas. It read everything else, it read the facilities queried by metro area, the infrastructure of course did not change, and when I now show the current Terraform state, we now see that we successfully queried our metro area by IATA code and now could list all facilities like our multitiered data centre in Frankfurt.
All right. So, far so cool. We can do queries. But let's do something more interesting, right. So, not only querying, let's create something. So, the first thing in my use case is yeah, I am acting as a reseller, I could now hard code for example my reseller ID and I am just looking it up using this convenient data source, and then let's create a new customer. So, we want to on board the customer where we already have our connection in place, and basically want to resell network peering services.
So, we create a new customer, let's call it alley net, I am really uncreative with names, so when I knew say Terraform apply, it will suggest or it will show you that some changes are imminent for the Terraform state. So it will perform the following actions. This is called the plan. It will create the account and a lot of things will only be known after the apply, like for example the ID, which is the usual thing. So when I do this, it's then applying the state change to the server, and if you do it again, not a change but ‑‑ yeah, you basically refresh the state only. So when you show it, you now see it okay, we have now successfully created an account. It's not discoverable. It's managed by the reseller ID, and it's in state production.
So, as this is all tracked by Terraform, changes to this account, like for example providing a legal name would then result into an update, this will be updated in place and a patch request will be done using the API and the resource will be updated.
So far so good. So, as you have seen, sometimes it's a bit tedious to always write like these long names, so you can always make short cuts. So, with local you can define local variables, like for example a reseller ID or an account ID, and other things we need to for our use case would be, for example, then publishing a contact. Let me do this real quick. We need a contact and an implementation contact. You can all find these in the spacecations of the IX‑API, and of course we would need to configure peering, a product offering, which defines what actual product to configure. So this play for example, you have always the possibility to create outputs. So, you could ‑‑ you can always show, for example the value of the IX‑API product offering peering Frankfurt, and if you apply this, for example ‑‑ yeah, this is where I always prepare this. If you apply this ‑‑ I forgot something. I skipped a line. Oh, no. What happened? This looks wrong. Now I am off track. I am so sorry. We have or resource, we have our product offering, we should have the exchange LAN and use the connections like this, and always apply this and yes, okay, it's creating a contact, that's all. Let's skip this for later. We pick our connection, we define an IP address ‑‑ not an IP address, we need a MAC address for later, which is then again managed by Terraform, so when you change this, again the whole change process will be done by this.
We need to access the specific role assignment. These role assignments are derived from the contact. The contact is then referenced from the resource, and to make things simple, we just add locals with a contact ID and so on.
So, everything great. I guess then we can just define our network service config like with the parameters we see on the network service config IX‑API page, there you would see yeah, you need to provide a managing account, customer account, billing account, all the stuff, a networking connection, network service, product offering, ASNs and so on, and hopefully this will all now work, so it will create this not only the contact, but also it will create the resource for the network service config. I can all say yes and it will just apply this and ‑‑ but if you now show your Terraform state, you will see oh, okay, there are still tonnes of stuff missing, everything is created but no network feature is signed and so on, and I am rushing now a bit.
So all this tedious work you would then more or less do a copy and paste and add all this configuration stuff and so on in there. You can also define a nice output and so you can have something to then further on put into, for example, a provisioning script and so on, to basically provision now this customer completely, and if I now run a Terraform apply, I should remember to save things. It will now create the required network service config. It will then have an output. It will have basically everything we need. I am doing this apply, and operate. We now have something we can pass to our customer like a BGP password, how to configure the gateway ‑‑ how to configure the router and so on, and even we got our assigned VLAN ID from the intended exchange. And so let's rush our state. Let's show it, and you can see everything.
All right. So much for my hands‑on demo. I hope this wasn't too much of an information dump. The next step now would be to abstract it and abstract this away from doing this pretty much hands‑on writing resources for a given customer to building a module where you can then just pass in some key variables like product ID and for example customer, and then provision peering not only in Frankfurt but based on the product offering, for example, in Munich or wherever else, and just then just an example for reusing your code.
I see I have like five minutes left, so I'll stop sharing my screen and we'll open the slides...
Everything you saw is open source, and you can find the documentation specifics for the IX‑API on docs IX‑API.net. There is a GitLab with the IX‑API Sandbox, schema, the go client. You can of course only play around with the go client if this whole Terraform stuff isn't low level enough for you. And of course, the Terraform provider itself is open source for name space and publishing reasons, it's hosted on GitHub because the Terraform registry is actually pulling things from GitLab.
All right ‑‑ oh and I just saw there were other issues. It's a good thing to see now.
Okay, I hope the audio wasn't that bad. This is pretty much from me. Thank you all. Hopefully I'll see you all next time in person again. So I will ‑‑ we can have a nice chat, and do you have any questions?
ONDREJ FILIP: Thank you very much Annika. I'll ask Lefteris to prepare his presentation and meanwhile we have a few minutes for the questions, so are there any? I don't see any Annika, so I think everything was clear, thank you very much.
ANNIKA HANNIG: All right. I had tonnes of fun with code generation, so writing code generation is really a nice thing to do, because especially if you have to, at the same time, have in your head multiple languages to deal with. So, yeah, I can always recommend ‑‑ this is a nice exercise. Okay. So much from me. Have all a great day. Have a great rest of RIPE, I hope to see you all next time in person again and bye.
ONDREJ FILIP: Thank you very much and we are all looking forward to seeing you the next time. Thank you.
LEFTERIS MANASSAKIS: Thank you Ondrej. Give me a second guys to boot up my laptop and open the presentation. Hopefully this is visible.
Great, that was step number 1.
The second step is for the mouse to work. Okay. We have got that.
So my name is Lefteris Manassakis. Co‑BGP is the company current maintaining ARTEMIS. ARTEMIS is an open source tool for detecting BGP prefix hijacking attacks in realtime.
For the ones that joined me in the lightning talk yesterday in the Plenary, some of the things that I am going to say right now you have had heard yesterday but for the ones that haven't seen the presentation, I need to say a few words about what ARTEMIS does and how it works so that you later see the demo and understand what you are seeing.
So, the ARTEMIS design goals is to provide realtime BGP observability, advance the BGP hijacking detection, it's an on premise tool that the operator needs to download and install at his own servers. It provides a custom UI that I will show you in a bit and it's built on top of a modern software stack.
The ARTEMIS overview: This is this slide that describes the high level view of how ARTEMIS works. On the left side we have the various data sources that like contribute data to the system, BGP data. We're talking about control plane data only here, so we have the public BGP feeds like RIS live, RIS live WebSocket and also BGP stream, and also you can connect your own routers to the system, the operator can do that. And what we ‑‑ the operator needs to do, and this is something that I will show you as well, is configure the ARTEMIS configuration file, which is a Yaml file that you can use in order to declare your autonomous systems. Your prefixes, your neighbours and some specific BGP policies can also be configured here and what ARTEMIS does is compares the configuration file that the operator has configured, against the data that it received from the monitoring module, from the public feeds. And if it finds discrepancies it raises alarms that the operator will be informed in slack or mail or syslog or Yaml UI.
I'm now going to do a demo. I am quite nervous for this because it's a live demo and I am going to do a hijack. So before I was sitting there and I was thinking in my life I don't do any bungee jumping, any adrenaline sports or stuff like that, to this will cover it.
So, I will open the UI. Before we do the actual hijack, I will give you a walk through of the UI, what do we see here?
ARTEMIS is ‑‑ has three main tables. It's the main dashboard that we see here where you can see if hijack is taking place currently. This go grab a beer is an idea that the original fraudulent developer had, he is currently a Ph.D. student in UCL and he obviously likes beer and I think that will resonate with an a lot of people. And whenever a hijack takes place, you will see it here. And also in this overview page you can see the values make row services that are currently running. You can switch on and switch on the micro services. And also, the modern micro services. Currently we have active the BGP stream Kafka monitor service, which is a collection of BMP fields by KAIDA, and also RIS live. And on the right‑hand side, we see currently some statistics like what are the number of prefixes we're currently monitoring. ARTEMIS is a prefix monitoring tool, meaning that it protects specific prefixes regardless of who is originating them and it also has the number of peers that are currently contributing data to the system and other statistics.
Next to the dashboard we have the BGP updates. These the updates that contain these prefix that is you have configured as the prefix in the update it can be an announcement or a withdrawal obviously.
And it shows the AS path. It provides the information, also the service, in this case it's RIS live and specifically the route collector number 3. And you can see more information here. You can filter based on different filters. I won't bother you with so much detail, I will try to go directly to what everybody is waiting for.
In the next table, we see the hijacks. In case a hijack takes place, the operator needs to go here and do some specific things that hopefully will work. In case it doesn't work, you will excuse me we will go to the back of the room and have a silent heart attack.
So I will open the router now. I will go back to the dashboard. First of all, we want to see that the RIS router has BGP session up, and it does, and it gets the full feed both v4 and v6. What I'm going to do now also one thing that I forgot to show you, which is important, is the configuration file before we go to the actual ‑‑ this compares the different configuration files.
Here, the operator can switch on and switch off modules, and this is a configuration file where you select your prefixes, who is announcing them, what are the monitorings that are currently active, this is the form of a Yaml file, what are the neighbours and what I have done in this configuration file in the end is that this sub‑prefix 4 that I am going to announce, I have declared all the upstreams that I am using but I have not declared one upstream, specific upstream that I am going to use right now. By not declaring it here, ARTEMIS will see that you have a new neighbour, although you have not configured it and it will detect it as a Type I hijack as we say. A hijack that the hijacker falsifies the AS path and presents himself as the first hop neighbour to you, which is a type of hijack attack that RPKI does not protect you against. So it's an advanced type of hijack. That's one thing that I will show you, and if time permits, probably it will, as it seems, I will also show you this type of attack which is what we call a squatting attack, meaning when you can have prefixes that you don't use but you don't want anybody else to use them because they belong to your own organisation, you can declare them here and have ARTEMIS inform you in case somebody else is using it.
Okay. Time of truth!!
So, I will do this announcement for this prefix and let's see what happens. When ARTEMIS will detect the hijack, it will take some seconds. In the meantime we can give a command to the router. I chose to use go BGP for this demo, but there are many open source software stacks that you can use, as you know. Excellent ones like the ones that are Working Group Chairs are supporting.
So, the router shows that this announcement has been done and let's me what happens with ARTEMIS when it will detect the hijack. Detective it takes longer than usual, I must admit. Usually it takes seconds. It's the Murphy's law, I mean what can I say? We'll see. Maybe you will have to excuse me in a bit. We'll see. Anyway if it does work, it does work, it's not the end of the world, it's one more story to say to my grand kids, I guess.
Normally, in either RIS one monitor of hundreds of the hundreds monitors of RIS has, or even Kafka, will see this update and will inform ARTEMIS that this is an update, and ARTEMIS will detect it and declare it as a hijack. This is a lesson for me to next time do a screen cast. In the meantime I will do the other ‑‑ the second announcement as well so that we see if in the meantime ‑‑ so you guys don't wait all this time, and give a bit of time to the some.
This is the second announcement that I'm going to do that is supposed to be detected as a squatting attack I do not think ‑‑ let's go to the updates to see if we can see anything regarding these prefixes? No. No luck I guess. I have three minutes.
Maybe while you guys ask me questions, something shows up here, so yeah, you can ask any questions and sorry, but my luck was not on my side today.
ONDREJ FILIP: Okay. Are there any questions?
AUDIENCE SPEAKER: Thomas from the university of Strasbourg. So thank you for the presentation yesterday and the demo, hopefully it will work. I wanted to ask you in the papers I went through the paper, the ARTEMIS paper, and you mentioned tour hijacks and some solutions to detect tour hijacks as well. I wonder if you include those in the implementation of ARTEMIS and if you plan to do it in the future?
LEFTERIS MANASSAKIS: Thank you for the question and thank you for going through the paper because it's a long paper. This question is related to the question the guy asked me yesterday in the Plenary about basically detecting hijacks within the path, like transit providers as he mentioned them. The thing with Type II hijacks, so that the other people understand what we mean by Type II hijacks. They are hijacks that are further than the first neighbour. It can be Type II or type N as we call them in the paper. We have a methodology in the paper on how to detect such types of hijacks that as I mentioned yesterday are a hard cookie to crack. The thing about this type of hijacks is that the further away you go from the source, the more paths we have, and the more unpredictability you have. So let's say that in the third or fourth hop you are seeing a new link, how would you know if this is like a legitimate announcement or not? We have in the methodology of ARTEMIS an approach that is novel I believe that says if you get the history of the all the updates through time, for this link to exist for real, there must be the backwards link from the destination to the source pre‑existing in the path sometime in the past. And if this happened, then the chance of this announcement being legitimate is larger. But that's not again, you know, absolute certainty, that this is a legitimate announcement. So for the current time being, ARTEMIS does Type I detection. In order to do Type II we have described in detail in the paper Type II and more how it can be done. Although it will also produce false positives, and it's ‑‑ it takes a lot of computational ‑‑ while we were speaking the hijack of detected, great ‑‑
ONDREJ FILIP: Just a quick update. I think you had some change on your screen.
LEFTERIS MANASSAKIS: Yes, yes, the update showed up also.
It will also produce false positives, and one of the goals of ARTEMIS is that we do not want it to produce false positives and false negatives because the operators get the false alarms and they start ignoring the alarms which is not a good thing. So this is the hijack, I don't know if I have one second maybe to show?
So you can see that it is an exact prefix hijack of Type I, meaning of the falsifying the neighbour. It took a bit of time for this announcement to be shown. And you can see details about the hijack here. How it looks like. What was the time stamp. For this announcement for some reason it took six minutes to be detected. Which is not bad, but it's not so ‑‑ it's not also not what we're used to. We're used to detecting hijacks within seconds.
And also, what you can do, since this, in reality, this is a legitimate announcement, what you can do is go here in this tab and mark it as ignored, apply, and when you do this, ARTEMIS can automatically reconfigure your configuration file so that next time this announcement shows up, there will be no alarms.
Thank you very much guys.
ONDREJ FILIP: One more question.
AUDIENCE SPEAKER: Thank you for the presentation. Lyon Bertolle, Univeristy of Twente. One thing, as we have worked with Anycast, we have created a lot of different oscillations in the network. Then we tried to use RIS and route views to see what change in the prefix that we do. And we noted that several different autonomous systems that send peers to ‑‑ that peering with RIPE, for example, they have different timers. So, one thing like this one had a that happened with you, normally we noticed that depending on which part of the planet you are doing change, it will appear in RIS like 30 minutes after the prefix has been ‑‑ there is traffic there and everything working. It's like just ‑‑ I don't know, I feel that problem when we are doing this type of watching what is happening and maybe, I don't know if you noticed that too or not?
LEFTERIS MANASSAKIS: Yeah, I have worked successfully with RIS, RIS is a great source of information for everyone of us while working with BGP. It provides 1,500 feeds, not all of them are fulfilled, but some of them are fulfilled as well like half of them, so it's a great source of information. But it can also produce some ‑‑ it has some inconsistencies I would say, and the community would be great if we could all work together to solve this type of inconsistency. But you are right, yeah, we have seen that stuff as well.
AUDIENCE SPEAKER: Okay. Thank you very much.
ONDREJ FILIP: We have one very short question.
AUDIENCE SPEAKER: Very short. Anton Bradot. Thank you for your presentation. I think that this demo shows that bad guys should be patient.
ONDREJ FILIP: Okay. Thank you very much for the presentation. Thank you very much. And I know this is all for today, from some reasons we don't have much time, we just got 60 minutes, so now you will have another six months that you will wait for another session like this. So please survive that. Thank you very much for joining us, I would like to thank the people who made this session happen, Anand, Michele, Guy, thank you very much and the others around, also the scribe, thank you so much, and enjoy your break. Thank you.
MARTIN WINTER: Again, thank you everyone, bye.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC