WEBVTT 00:00.000 --> 00:13.000 So we can begin. Thank you for coming. We're going to talk about securing the internal 00:13.000 --> 00:22.000 control plane and I am Antonius. I work at Cisco for the past eight months, but this 00:22.000 --> 00:29.000 is some work that I've been doing personally for many years now for my own network. 00:29.000 --> 00:35.000 And let's talk a little bit about the problem that we have, and I've seen this problem 00:35.000 --> 00:41.000 in enterprise networks, like especially if they're large enough and complex enough, you start 00:41.000 --> 00:48.000 using EBGP internally. So you have private ASS and you speak EBGP to all of your routers, 00:48.000 --> 00:55.000 maybe you use some rout with reflectors, and that's how you glue the network together, 00:55.000 --> 01:01.000 and if you use VPNs, so things like OSPF are more tricky to get working, eventually it's 01:01.000 --> 01:07.000 very common to rely on BGP. And this doesn't matter, like this ASS can be different 01:07.000 --> 01:13.000 rocks that you have in your network. It can be different branches you have around the country. 01:13.000 --> 01:19.000 Whatever this ASS is meant to you, you usually have a set of that looks like this. 01:19.000 --> 01:26.000 And of course, every ASS that you have has its own prefixes. In this case, if they are branches, 01:26.000 --> 01:33.000 they have the Wi-Fi prefix and the gas prefix and all of that. But this also applies to provider networks. 01:33.000 --> 01:40.000 I've seen provider networks in the wild that use EBGP internally with private ASS. 01:40.000 --> 01:46.000 And this is something that basically applies to them as well. 01:47.000 --> 01:59.000 So I run my own ASS. It is AS4601. And I've been using that for several years now. 01:59.000 --> 02:04.000 And all of this that we're going to talk about today has been applied there. 02:04.000 --> 02:08.000 I had the problem that I'm about to describe, and I'm going to tell you how I solved it, 02:08.000 --> 02:12.000 and all of the operational experience that I got out of it. 02:12.000 --> 02:19.000 So let's talk about how routing is done. And first of all, there is no IBGP, no router reflectors. 02:19.000 --> 02:24.000 I knew we're in the network. All of the sessions are IBGP sessions. 02:24.000 --> 02:30.000 So it's very similar to the thing we described earlier. The only difference is that I'm using BGP confederations. 02:30.000 --> 02:35.000 That's a feature where you can use your public ASs for all of your routers. 02:36.000 --> 02:42.000 And then internally you can split it into private ASs, and they have one for every router. 02:42.000 --> 02:46.000 So every machine I have has its own private AS. 02:46.000 --> 02:54.000 And it's router acts independently. It does not rely on other routers or router reflectors to make decisions for it. 02:54.000 --> 03:00.000 It has its own rib, and it makes its own decisions. 03:00.000 --> 03:05.000 And if we want these routers to collaborate, I use large communities. 03:05.000 --> 03:11.000 For example, if I have an IXP, root server session, I target with specific communities. 03:11.000 --> 03:19.000 So then a router further, like maybe in another country, can make decisions where that there's prefix was learned from peering or transit. 03:19.000 --> 03:23.000 But these communities are informative. 03:23.000 --> 03:27.000 And it's multi-vendor because it's something I do as a hobby, I pay for it myself. 03:27.000 --> 03:32.000 I did not go to a vendor and get the latest and greatest hardware. 03:32.000 --> 03:35.000 It started with whatever used hardware I could find. 03:35.000 --> 03:38.000 And now I'm slowly as I replace the hardware that's changing. 03:38.000 --> 03:45.000 I'm moving to a Linux based routing with Tabian and BERT2 as the routing demon. 03:45.000 --> 03:49.000 And with kernel routing or VPP. 03:49.000 --> 03:52.000 Right now it's not a huge network or a large one. 03:52.000 --> 03:57.000 It's around 20 core, like IP routers that have full tables. 03:57.000 --> 04:04.000 And it's a large enough where you cannot start to see what breaks and what works. 04:04.000 --> 04:06.000 So the networks look like this. 04:06.000 --> 04:17.000 So it's the same as configured everywhere and the private asses that are used to communicate with EBGP on all of the sessions. 04:17.000 --> 04:22.000 And by profession, I am a security engineer, like networking started as a hobby. 04:22.000 --> 04:27.000 So I wanted to see what I can do to improve the security of this design. 04:27.000 --> 04:30.000 And I wanted to move to reducing trust. 04:30.000 --> 04:37.000 So right now, only routers only trust themselves in this network. 04:37.000 --> 04:44.000 In most designs you'll see today, every router, every equipment you have, everything that participates in BGP. 04:44.000 --> 04:47.000 It is usually assumed to be trusted. 04:47.000 --> 04:51.000 I try to move away from this design to something where each router can only trust itself. 04:51.000 --> 04:54.000 It doesn't have to rely on everything else. 04:54.000 --> 04:56.000 And everything is treated as a hint. 04:56.000 --> 05:00.000 Like if you see this large community, okay, it's there. 05:00.000 --> 05:04.000 But you don't necessarily trust it unless you somehow verify that. 05:04.000 --> 05:06.000 And this is working. 05:06.000 --> 05:13.000 So it's kind of like a mini-internet, the same way that when you have an AS and you connect to your transit and your peers, 05:13.000 --> 05:19.000 and your down streams, you don't inherently trust them, you apply filters, you apply prefix limits. 05:19.000 --> 05:22.000 You do all these sorts of things. 05:22.000 --> 05:28.000 And this is what I'm doing internally as well. 05:28.000 --> 05:33.000 And hopefully this means that even if you get root access to one of these machines, 05:33.000 --> 05:37.000 the damage is contained to whoever is connected to that. 05:37.000 --> 05:40.000 You cannot take down the entire network, all of the services, 05:40.000 --> 05:43.000 even if you have root access to one of these. 05:43.000 --> 05:46.000 However, this is more of an end goal. 05:46.000 --> 05:49.000 It's not possible yet. 05:49.000 --> 05:53.000 So I'm not going to give you root access to try. 05:53.000 --> 05:58.000 And when we validate public sources, 05:58.000 --> 06:03.000 when you connect to other ASs in the Internet, there is a playbook. 06:03.000 --> 06:09.000 This is most of the NL-Nox best practices and how to validate prefixes. 06:09.000 --> 06:13.000 So you drop RPKI invalid, hopefully you have the IRR, 06:13.000 --> 06:18.000 RPSL stuff that you are doing to generate prefix lists and all of that. 06:18.000 --> 06:23.000 Then there are certain ASs, there are IP addresses that cannot appear on the Internet, 06:23.000 --> 06:25.000 and you drop these two. 06:25.000 --> 06:30.000 And of course, you know, if you have a Slash 49 or a Slash 100, 06:30.000 --> 06:36.000 this prefix is too long and it is being dropped hopefully by your filters. 06:36.000 --> 06:42.000 So you do all of these things for your connections to others. 06:42.000 --> 06:47.000 And then eventually if you have a prefix, you can certainly, you can be well, 06:47.000 --> 06:51.000 as close to certain as possible that this should originate from this AS, 06:51.000 --> 06:56.000 and it's not a hijack or a route leak or something like that. 06:56.000 --> 06:59.000 But when I looked at how we can validate internal routes, 06:59.000 --> 07:02.000 like what do you do internally, 07:02.000 --> 07:06.000 it was slightly different. 07:06.000 --> 07:09.000 Like the rich URLPF to drop the traffic, 07:09.000 --> 07:12.000 but this can go only as far as the control plane, 07:12.000 --> 07:15.000 the BGP will allow it to go. 07:15.000 --> 07:18.000 However, a lot of the problems that exist on the public internet, 07:18.000 --> 07:23.000 they usually exist in sufficiently complex internal networks as well. 07:23.000 --> 07:25.000 So you have route leaks like, 07:25.000 --> 07:28.000 okay, like this end branch in the middle of nowhere, 07:28.000 --> 07:31.000 somehow is part of my backbone now. 07:31.000 --> 07:34.000 Or, you know, this prefix was assigned in New York, right? 07:34.000 --> 07:37.000 Not Seattle. So why is it being sent to Seattle? 07:37.000 --> 07:40.000 Why is it originating from there? 07:40.000 --> 07:44.000 And it's usually even messier than the internet, 07:44.000 --> 07:47.000 because you don't know the IP address holders, 07:47.000 --> 07:50.000 you don't have a definition of valid. 07:50.000 --> 07:52.000 So, you know, you can say, okay, 07:52.000 --> 07:55.000 we started all of our company with a Slash 24, 07:55.000 --> 07:57.000 as the smallest prefix. 07:57.000 --> 07:59.000 And then suddenly we merge with another company, 07:59.000 --> 08:01.000 we acquired another one, 08:01.000 --> 08:02.000 we had IP conflicts, 08:02.000 --> 08:06.000 and you have all sorts of exceptions that start to add up. 08:06.000 --> 08:10.000 So your entire playbook is kind of useless, 08:10.000 --> 08:12.000 like what you do for external connections 08:12.000 --> 08:17.000 cannot be applied within your own AS, within your own domain. 08:17.000 --> 08:20.000 And then I started looking at other networks 08:20.000 --> 08:24.000 I doing, I spoke with operators of mostly enterprise networks, 08:24.000 --> 08:27.000 and the most common answer was nothing. 08:27.000 --> 08:31.000 We trust every single piece of equipment that we have, 08:31.000 --> 08:34.000 and most of the time it works, 08:34.000 --> 08:37.000 like, you know, sometimes the network may go down, 08:37.000 --> 08:40.000 but it's too complicated for us to deal with it. 08:40.000 --> 08:43.000 Others have static prefix lists, 08:43.000 --> 08:45.000 that they generate and update. 08:45.000 --> 08:47.000 So when they install the equipment, 08:47.000 --> 08:49.000 the SSH, you know, into that, 08:49.000 --> 08:50.000 they configure a prefix list, 08:50.000 --> 08:52.000 and then if they get a new link, 08:53.000 --> 08:56.000 they have to SSH again and update it. 08:56.000 --> 08:58.000 But this is very manual, 08:58.000 --> 09:00.000 even if you try to automate it, 09:00.000 --> 09:01.000 it's complicated, 09:01.000 --> 09:03.000 it has a lot of issues. 09:03.000 --> 09:04.000 So you may have, you know, 09:04.000 --> 09:06.000 two links that connect to data centers, 09:06.000 --> 09:09.000 and you only updated the prefix list in one of them. 09:09.000 --> 09:12.000 So you think you have redundancy and you don't. 09:12.000 --> 09:13.000 When that links goes down, 09:13.000 --> 09:15.000 you have, you know, 09:15.000 --> 09:18.000 your data center, your network is split in half. 09:18.000 --> 09:20.000 So I was thinking that, 09:20.000 --> 09:23.000 it's something that has to be solved. 09:23.000 --> 09:26.000 It's something that's complicated enough. 09:26.000 --> 09:29.000 What am I going to do personally to try? 09:29.000 --> 09:32.000 And make this better. 09:32.000 --> 09:35.000 And instead of creating something new from scratch, 09:35.000 --> 09:37.000 I tried to reuse the playbook. 09:37.000 --> 09:40.000 Like we have all of these systems already, 09:40.000 --> 09:43.000 and this is the playbook by the way, 09:43.000 --> 09:44.000 and it works. 09:44.000 --> 09:47.000 It works well enough in the public internet. 09:47.000 --> 09:52.000 So why shouldn't it work within your own network? 09:52.000 --> 09:55.000 And this is to complicated, 09:55.000 --> 09:57.000 like you have IRR there. 09:57.000 --> 09:59.000 I think everybody hates it, 09:59.000 --> 10:00.000 nobody does it right. 10:00.000 --> 10:01.000 And the bug on list, 10:01.000 --> 10:03.000 it's difficult to define all of that. 10:03.000 --> 10:05.000 There are problems that you, 10:05.000 --> 10:06.000 you start to have. 10:06.000 --> 10:09.000 So I even went and tried to simplify it. 10:09.000 --> 10:12.000 And this is a simplified version. 10:12.000 --> 10:15.000 Let's only use RPKI. 10:16.000 --> 10:19.000 So how does that work in practice? 10:19.000 --> 10:20.000 So first of all, 10:20.000 --> 10:24.000 you cannot use the five IRRs for this. 10:24.000 --> 10:25.000 And what you do, 10:25.000 --> 10:29.000 the rough idea is that you run a private RPKI. 10:29.000 --> 10:31.000 And instead of this having, 10:31.000 --> 10:32.000 your public addresses, 10:32.000 --> 10:34.000 it has all of your internal addresses, 10:34.000 --> 10:36.000 and all of your internal aliases. 10:36.000 --> 10:39.000 And then, like in theory, again, 10:39.000 --> 10:42.000 you go to every BGP session you have, 10:42.000 --> 10:45.000 and you drop all of the invalid. 10:45.000 --> 10:47.000 And okay, that's good enough. 10:47.000 --> 10:49.000 But ideally, you move a step further. 10:49.000 --> 10:51.000 You also drop the unknowns. 10:51.000 --> 10:54.000 And this is a little bit more dangerous. 10:54.000 --> 10:56.000 And this creates a single source of truth. 10:56.000 --> 10:59.000 Your RPKI data contains everything 10:59.000 --> 11:02.000 that you need to know about the network. 11:02.000 --> 11:06.000 Here's a visualization of how that would look like. 11:06.000 --> 11:09.000 You know, you have a slaster to 1.2 points link 11:09.000 --> 11:12.000 that's being originated from this private AS. 11:12.000 --> 11:14.000 You have this slaster 48. 11:14.000 --> 11:17.000 And even if you have internal aliases, 11:17.000 --> 11:19.000 or things like that with multiple origins, 11:19.000 --> 11:22.000 you just issue multiple rows for this prefix. 11:22.000 --> 11:26.000 And then you can just get basically 11:26.000 --> 11:31.000 the entire representation of how the network should look like 11:31.000 --> 11:34.000 into RPKI. 11:34.000 --> 11:37.000 So filtering suddenly is simpler. 11:37.000 --> 11:40.000 You need to generate filters around them by hand. 11:40.000 --> 11:42.000 This is bird syntax. 11:42.000 --> 11:46.000 Basically, if the net belongs to your IGP, 11:46.000 --> 11:47.000 check if it's valid. 11:47.000 --> 11:49.000 And if not, just drop it. 11:49.000 --> 11:52.000 Or, you know, do something extra with it, maybe. 11:52.000 --> 11:56.000 And suddenly things are much simpler. 11:56.000 --> 11:58.000 If something is RPKI valid, 11:58.000 --> 12:00.000 you let it propagate. 12:00.000 --> 12:02.000 If it's not, you don't. 12:02.000 --> 12:05.000 So this looks amazing. 12:05.000 --> 12:09.000 Let's talk a little bit about how it's done in practice. 12:09.000 --> 12:13.000 So first of all, you have to build this private RPKI. 12:13.000 --> 12:15.000 Like it was a single bullet point earlier, 12:15.000 --> 12:17.000 but it's more complicated. 12:17.000 --> 12:21.000 When I started in 2021, there was no software. 12:21.000 --> 12:23.000 So you had to issue all of the certificates 12:23.000 --> 12:25.000 and build everything manually. 12:25.000 --> 12:28.000 But thankfully, things changed since then. 12:28.000 --> 12:31.000 And it's now much easier for people to set up something like this. 12:31.000 --> 12:34.000 There is Krill by Annel Natlobs, 12:34.000 --> 12:37.000 and it's designed for the public RPKI. 12:37.000 --> 12:40.000 But there is now a feature where you can use it 12:40.000 --> 12:43.000 to create your own hierarchy internally. 12:43.000 --> 12:46.000 And it's, you know, an open source software 12:46.000 --> 12:48.000 that you can use. 12:48.000 --> 12:52.000 You can issue rows for all of your prefixes and your ASCs. 12:52.000 --> 12:57.000 And you can have a separate structure away from the public RPKI. 12:57.000 --> 12:59.000 The next thing you have to do is, you know, 12:59.000 --> 13:01.000 calculate your data. 13:01.000 --> 13:05.000 This obviously depends on the quality of that in the first place. 13:05.000 --> 13:08.000 Some people use Excel or something like that. 13:08.000 --> 13:11.000 To document their network, some people use networks. 13:11.000 --> 13:16.000 So this really depends on what you are using. 13:16.000 --> 13:19.000 Personally, for my network, it was networks. 13:19.000 --> 13:21.000 So it has a great API. 13:21.000 --> 13:25.000 Krill has a way to import everything and create all of the rows. 13:25.000 --> 13:28.000 So it was fairly straightforward to get the source of 13:28.000 --> 13:31.000 networks and import it into Krill. 13:31.000 --> 13:34.000 And as long as you can, whatever you have, 13:34.000 --> 13:37.000 even if you don't have anything, as long as you can create 13:37.000 --> 13:41.000 a map of prefix to internal AS, this should work. 13:41.000 --> 13:45.000 The next thing you have to do is to keep the data in sync. 13:45.000 --> 13:48.000 And if you use something automated, 13:48.000 --> 13:51.000 the API, you can probably rerun the same script 13:51.000 --> 13:57.000 and you can update Krill all the time, keep it in sync. 13:57.000 --> 14:00.000 Now, if you use something like Excel or something, 14:00.000 --> 14:03.000 I don't know, then it's more complicated, 14:03.000 --> 14:08.000 but consider dropping this not automated old tool 14:08.000 --> 14:11.000 and move to Krill for your source of truth. 14:11.000 --> 14:16.000 It supports the IP to AS mapping, so maybe it's a good IPom. 14:16.000 --> 14:18.000 I mean, you can try. 14:18.000 --> 14:25.000 And the important thing is that this should be kept accurate. 14:25.000 --> 14:31.000 The positive thing about that is that if you don't keep it in sync, 14:31.000 --> 14:34.000 and you set up a new link or a new prefix, 14:34.000 --> 14:35.000 it won't work. 14:35.000 --> 14:39.000 If you drop unknowns, your network will not work, 14:39.000 --> 14:42.000 so you will know your database is not in sync. 14:42.000 --> 14:46.000 The only way for you to use a prefix is to actually set it up 14:46.000 --> 14:49.000 on your source of truth correctly. 14:49.000 --> 14:52.000 So, for me, it's a feature, really. 14:53.000 --> 14:56.000 And then you have to get the data into your routers. 14:56.000 --> 15:00.000 This is the same way you do RPKI for your public internet stuff. 15:00.000 --> 15:02.000 You have to do it internally as well. 15:02.000 --> 15:04.000 You have two options here. 15:04.000 --> 15:07.000 The first one is you can run two instances, 15:07.000 --> 15:10.000 like, for example, routinator is the easiest software. 15:10.000 --> 15:13.000 You run one instance for the public internet stuff, 15:13.000 --> 15:17.000 and you run another instance for your internal RPKI. 15:17.000 --> 15:20.000 And of course, this is not, you know, two physical instances. 15:20.000 --> 15:23.000 You can have 100 virtual machines, it doesn't matter. 15:23.000 --> 15:26.000 It's two hierarchies in reality. 15:26.000 --> 15:31.000 And then you point into your distribution points that create 15:31.000 --> 15:32.000 creates for you. 15:32.000 --> 15:34.000 And it's the same thing. 15:34.000 --> 15:36.000 Same configuration, nothing changes. 15:36.000 --> 15:40.000 And now your filters are if this prefix is mine, 15:40.000 --> 15:42.000 then and sure it is valid. 15:42.000 --> 15:44.000 So, we're done. 15:44.000 --> 15:46.000 Right? 15:46.000 --> 15:49.000 Well, unfortunately, no, we're not done. 15:49.000 --> 15:52.000 Because when I try to run this, 15:52.000 --> 15:54.000 I stumble into so many problems. 15:54.000 --> 15:58.000 And some of them went away, but not all of them. 15:58.000 --> 16:03.000 And this is what I wanted to share with you today with this talk. 16:03.000 --> 16:06.000 So, let's start looking at all of them one by one. 16:06.000 --> 16:09.000 And the first one was that not all BGP implementation 16:09.000 --> 16:12.000 support multiple RPKI sources. 16:12.000 --> 16:15.000 I used birds, so it was very lucky that it can do it. 16:15.000 --> 16:18.000 It can have unlimited sources and everything works musically. 16:18.000 --> 16:23.000 However, if you use like FRA, for example, I think it doesn't 16:23.000 --> 16:25.000 exactly work. 16:25.000 --> 16:28.000 What you can do there is merge them, merge the public 16:28.000 --> 16:30.000 and the private RPKI. 16:30.000 --> 16:34.000 And I didn't have any problems with that when I did it. 16:34.000 --> 16:38.000 So, I think it should work just fine. 16:38.000 --> 16:43.000 The second thing, if you use BGP configuration, 16:44.000 --> 16:47.000 is that handling them is not standardized. 16:47.000 --> 16:51.000 So, for example, in Verde, if you query the UI like you do, 16:51.000 --> 16:55.000 the show routes or something, you can see AES 65,000, 16:55.000 --> 16:59.000 if it's a configuration, AES, it will be in brackets. 16:59.000 --> 17:06.000 But if it's the EBGP 65,000, it will not be brackets. 17:06.000 --> 17:09.000 However, when you write filters, there's no way that I know 17:09.000 --> 17:11.000 to distinguish between the two. 17:11.000 --> 17:14.000 But this is still not a problem. 17:14.000 --> 17:17.000 You're not going to get AES 65,000 from the internet. 17:17.000 --> 17:20.000 So, as long as you use private AES is only internally, 17:20.000 --> 17:24.000 it should not be a problem. 17:24.000 --> 17:28.000 The other thing is that RPKI, at least today, 17:28.000 --> 17:32.000 does not protect from all of these types of attacks. 17:32.000 --> 17:36.000 Like, currently it only ensures that this prefix is 17:36.000 --> 17:38.000 originating from this AES. 17:38.000 --> 17:40.000 But if there are multiple AESs in the path, 17:40.000 --> 17:44.000 it's more difficult to get all of the properties you want. 17:44.000 --> 17:48.000 So, it's still not up to par with IRR data. 17:48.000 --> 17:51.000 But we're slowly moving that way. 17:51.000 --> 17:53.000 And there is the Aspa standard. 17:53.000 --> 17:57.000 It's recently been added to a routing nature. 17:57.000 --> 18:02.000 I think to Creela as well, where you can also specify all of the valid paths. 18:02.000 --> 18:07.000 And on the internet, getting a really legitimate AES path is very difficult, 18:07.000 --> 18:10.000 but hopefully on your internal network it should be easier. 18:10.000 --> 18:13.000 If you have, you know, from a visual drawing to, you know, 18:13.000 --> 18:15.000 something more advanced like networks, 18:15.000 --> 18:18.000 as long as you can export all the valid AES paths, 18:18.000 --> 18:21.000 and you import them into this pipeline, 18:21.000 --> 18:25.000 this will automatically get validated for you. 18:25.000 --> 18:30.000 And your filters will take care of everything for you. 18:30.000 --> 18:33.000 In the meantime, if you don't have Aspa, 18:33.000 --> 18:36.000 it's not supported by your software. 18:36.000 --> 18:40.000 Then what you can do is just have a list of route maps or prefixes 18:40.000 --> 18:43.000 of all the AESs behind the BGP session, 18:43.000 --> 18:45.000 and this should be good enough, 18:45.000 --> 18:48.000 like depends on your network design, of course. 18:48.000 --> 18:51.000 And the final problem that I found 18:51.000 --> 18:56.000 was that if your RPKI valid data goes down, 18:56.000 --> 18:59.000 and the table is removed from your router, 18:59.000 --> 19:01.000 your whole network goes down. 19:01.000 --> 19:05.000 And I discovered that in a very unfortunate situation, 19:05.000 --> 19:09.000 where I prefer to be swimming instead of fixing that, 19:09.000 --> 19:12.000 but I had to go back and fix it. 19:12.000 --> 19:16.000 And in order for the valid data to get all of the information, 19:16.000 --> 19:19.000 they need to reach certain IP addresses. 19:19.000 --> 19:23.000 And if they can only reach them because they are valid, 19:23.000 --> 19:27.000 then you have this cyclical dependency that breaks everything. 19:27.000 --> 19:30.000 So some networks are very lucky. 19:30.000 --> 19:34.000 They have 100% independent out of bond connectivity, 19:34.000 --> 19:37.000 and you can run the RPKI there as a critical service, 19:37.000 --> 19:40.000 but most of the networks, including mine, don't. 19:40.000 --> 19:44.000 Like we don't have this privilege of having this option. 19:44.000 --> 19:49.000 And what I did was that I host all of the RPKI stuff 19:49.000 --> 19:54.000 that's necessary in a special prefix, an exception, if you will, 19:54.000 --> 19:56.000 and this is okay to be unknown. 19:56.000 --> 19:59.000 So when you're bootstrapping, where your router starts, 19:59.000 --> 20:02.000 and it doesn't have any RPKI information, 20:03.000 --> 20:06.000 it's okay for this one prefix to be unknown, 20:06.000 --> 20:10.000 because you can bootstrapping everything off of that. 20:10.000 --> 20:14.000 And since all of the connections use authentication, 20:14.000 --> 20:16.000 at least in the application layer, 20:16.000 --> 20:20.000 like TLS for Creal and SSH for Routineator 20:20.000 --> 20:27.000 and RPKI client plus Sutter, this should not be a problem. 20:27.000 --> 20:31.000 And I also have multiple instances that are closed to the routers. 20:31.000 --> 20:33.000 I don't have one for my network. 20:33.000 --> 20:36.000 You know, in Switzerland and then everyone has to connect 20:36.000 --> 20:39.000 to this single instance, I have multiple VMs, 20:39.000 --> 20:43.000 and sometimes they're even running on the same hardware as the router, 20:43.000 --> 20:47.000 wherever this is something that's supported. 20:47.000 --> 20:49.000 So I got away with this problem, 20:49.000 --> 20:52.000 it's been working for three years in this architecture 20:52.000 --> 20:54.000 without any problems. 20:54.000 --> 20:57.000 And so one quick final slide, 20:57.000 --> 20:59.000 about the long term goal, 20:59.000 --> 21:01.000 eventually I would like to get to a point 21:01.000 --> 21:05.000 where I don't have to trust any of my own devices. 21:05.000 --> 21:08.000 Despite me being the person that owns them physically, 21:08.000 --> 21:10.000 set them up and configure them, 21:10.000 --> 21:14.000 I don't want to have to implicitly trust them. 21:14.000 --> 21:18.000 And I think that it's very smart to move to a model 21:18.000 --> 21:22.000 where you don't rely on this trust. 21:22.000 --> 21:24.000 Because then you can verify things. 21:24.000 --> 21:27.000 If you have RPKI, you can use all sorts of existing 21:27.000 --> 21:30.000 BGP monitoring tools that will alert you. 21:30.000 --> 21:33.000 So if you have routes, likes, hijacks, 21:33.000 --> 21:35.000 you wouldn't even know about them before. 21:35.000 --> 21:36.000 And now you do. 21:36.000 --> 21:37.000 So that's it. 21:37.000 --> 21:39.000 Thank you very much. 21:39.000 --> 21:41.000 Thank you.