Plenary session,
Tuesday, 15th May 2018
9 a.m.
CHAIR: Welcome to the second day of the RIPE meeting. I'm glad that so many of you have shown up in the morning after the welcome party, and this is a Plenary block dedicated to BGP, and we have three great presenters and each of them will have 20 minutes for their presentation, 10 minutes for the talk. And that said ‑‑ well, one more thing. There is a PC RIPE Programme Committee elections coming up with two seats up for election or re‑election, so if you are interested in serving on a Programme Committee, please send your picture and short resume to the PC at @ripe.net. And welcome the first presenter, Martin Winter, from Hurricane Electric, and enjoy the presentations.
MARTIN WINTER: Good morning for the ones that made it up here. I always think the second day would be easier to get up at nine o'clock, and tomorrow will be hard.
I'm here to talk about some new servers from Hurricane Electric which basically started there and I'll give you an introduction and what you can expect out of it.
So, first about me. I do some research at Hurricane Electric, otherwise I work on the FR routing, you may know me from that side. On Hurricane Electric I work on this realtime BGP tool, we call it RT BGP. For now your first question is what the the hell is that? What is a realtime BGP tool kit? Maybe it's not what you expect or maybe it is. So, if you are all familiar with the traditional Looking Glass is. Traditional Looking Glass you have normally many companies like session arch provider have one, they give you like the different views on BGP from different location there is in the network, so you can pick like which router you want to execute some BGP commands, you can go there and look at some of the data, so it's basically realtime data directly just from that router and so that's the example from Hurricane Electric, they put the fancy web better face on it, on the Looking Glass maybe CLI, or a Cisco router or a Cisco light router from the CLI but it normally just gives you classic output or something. Here are the routes at our exchange point or at this dataset or data centre, or normally most Looking Glasses are very provider‑specific.
We figured how about we go and change that. We want something which is more worldwide and more combining things so. First idea is like so, we'll break down, we don't want a single entity any more. We don't care about just having routes from Hurricane Electric, we want everyone's route. BGP feeds and some of the IDs we get like at these 1,000 or 20,000 BGP feeds together and we prosed it in all one location so we can go and start looking at interests things. We are basically asking for BGP feed from anyone who is willing to provide it to give us BGP feed.
So the interesting things then what you can do is is first of all, you have go there and sign up basically, you can like put your AS number in there. But the interesting things we want to look at it like when you see a new route, so we see it maybe a few seconds earlier in Asia than Europe or something, so things like that. Like, bad announcements, sometimes it's very common that you see it, most normal routers may just drop them or ignore them or fix them for you. We are basically customer limitation of BGPs or we log all this information, we want to know if you have some weird attributes attached that don't make sense we want to the issues there.
We also are very interested like on the leaking part, so route leaks and also hijacks is like a big part of this whole thing. So we want to be able to see especially on the hijack, who is hijacking, where it may come first or something, and if you go and sign up, you can go and register your routes and we basically, with your e‑mail and we will send you a detection, and let you know from where it's getting hijacked. I'll get into that in a moment.
So, the bogus BGP announcement is really interesting and with the whole notifications part.
But then we say like we don't want to just go for the personal information. We want the history too. So, we take every BGP update we get and put it in one large database and store it forever. So, we want to be able that you can go back in time and say like, who announced specific route before. Or from which AS this route comes before, like a few months or weeks or just ten minutes ago or something like that. And you want to also see authority term actions, if somebody leaked the route for a few seconds and disappeared. In our database you can go there and look at it and fine things like that. You can also potentially look at what matrix has changed so really we store the full contents of the BGP update messages there with all the prefix announcements.
So, one interesting thing you can do as an example, we can go and compare BGP feeds. So, a long time back, when I worked for the first large ISP, we always had the issues like consistent announcements across other network. First we do it perfect, then we were told, no, you don't, and then we looked into it and we ran into configuration bugs, software bugs and stuff there and it constantly was wrong. So we always had started comparing BGP feeds. If you provide multiple feeds from multiple locations, we are very happy to take multiple feeds, you can go in and compare them. You may also wonder like why does my full table have like 1,000 routes or 10,000 routes more or less than this other provider? I mean, everyone talks about what's a full need. It may be about that amount of routes but it obviously can be a few more or less, so you can go and compare your full table with someone else and like full table from a specific peer and see the differences. So you can see which IPv4 networks and which IPv6 are missing or additionally available somewhere.
How does an AS path compare too. You can also look for that. And also like, do I potentially get different source ASes for the same route? It sometimes happens on purpose and that may be correct, but most of the cases it may be something a bit strange going on.
So, if I go back to the ‑‑ like, here is an example when I register my routes, I can go in, if I create an account and I can go and register my routes. We don't look at least not at this time at any database, so hijacks, we wouldn't know unless you register your routes, and the only visible to you are hijacks because we don't verify it yet, you can basically register any route claiming they are your route at this time, but you are only the ones that see this as hijacked and you are the only ones who get notification for these but you can also see other changes and stuff. So you can go in, register a route today, you can see ‑‑ with the source AS, where it's supposed to be coming from and look for it.
So, you will get notification basically there when ‑‑ if it shows up from a different source AS, the same prefix, you also get a notification if it is not the same prefix but the more specific might be happening for if somebody does specific like hijacking, the more specific announce. You will get that part. We also look for bad announcements, that part is not implemented.
At this time we are still working on that, we have multiple IDs. We only detect hijacks if the source is different. Obviously you are probably familiar that frequently people put their AS somewhere in the middle and put the original AS at the end again so it looks like a longer path. This is something which we are working on and it will be probably a few months down the road will be showing up as a feature. We have some ideas how to solve that problem too.
So, looking at the initial features, what we have right now. As I say, this is the first version, this is the first time I am presenting about this tool. You can search for specific routes. You can also specify at what time. You can look at it, the routes or the paths received from the different peers which we have. You can see, like, which peers they don't have it, you can see a highlighting if the source AS is different in some places. You can also look through the same thing for the past. So instead of now you can say I want to see it for a few hours, day or weeks back. You can see all the routes from a specific AS which we define as that specific AS as a source AS. And we also have this unassigned AS number report which I expected the list would be quite small what we would see there. Like, the unassigned private ASes leaking out there, I was actually quite surprised, I'll show you afterwards.
So, we also see the timeline of a given prefix obviously today, so you can look at it what part it is, like how long things took there.
And we have the BGPlay in there too, the RIPE staff can probably tell you way better explain it what it all does if you are not familiar with it.
So, a few screen shots from it, how things look like. It's probably ‑‑ I'm not sure if you are read it ‑‑ it's hijack report, this is from a test account, some of the testing there. It will show you in there like some of the routes. It's just one test prefix I used where I announced more specific and other things and it shows what time it happened, what time the announcement showed up. So this is like on the web interface if you log in, and you can see it's there. You can also do the peer comparison as an example. Here I'm comparing two peers, like so two full feeds from Hurricane Electric, I have to admit I am not really sure which locations they are, but they are on at least different coasts, maybe different continents, so obviously you see frequently some small changes because the Internet is always a bit of flux. So here you see now that we have 45 B4 around about 163 B6 routes are currently different and it shows you below the differences there on the list.
A quick view on unassigned AS reports, that's about how it looks like. That's quite a long list of it, where you can scroll through. Keep in mind it's just not the ones you see right now. It's basically also the history which we are recording so you can see old things even if it's just for a second announced.
And if you go and look at more, in the prefix, if you will click on one of these prefixes, you would basically then see, hey, what the issues are. On this one you see some private AS in there from a few peers. So it's kind of an interesting case here where you see some of the peers they remove the private AS and some of the other ones didn't. So somebody probably is missing the private AS feature.
Let's talk about some of the early findings. We played around a little bit. We looked at what's the interesting stuff. We don't have that many peers, that's what you, I hope, many of you will help me out later. But we had still enough fun.
BGP Attribute 21. Who remembers that? Can I see any hands? Oh, I see one hand... two. Wow, for the ones who remember that it's a draft expired 11 years ago. It allowed you that you could attach a transitive BGP attribute. So it gets forwarded and it also gets forwarded if the router is in a standing. It tells you how far you want your route to be propagated. If you set it at example 5, it will be propagated to 5 routers and then basically ASes and then it should get dropped and disappear in the routing table. Now you can imagine the thing is like when a few routers still report that, most other routers then, they just forward it unchanged. It gives you lots of fun. You can have interesting routing loops where, like, some routers just dropped the prefix and other ones still have it.
So, I saw that actually from three different originating AS. And sent an e‑mail asked them what are you using? And it was interesting, two out of three answered, the third one was a bank, they were probably afraid security‑wise. And both used the same vendor, and when you go to the manual on the website as of the current code, they still reported and documented how to use it, how to configure it, and a few people started using it. And I contacted them, they may be changing that soon to a bigger thing.
Then another interesting thing. That was like one company we tried to peer with and the realtime BGP uses a 4‑byte AS. We did it on purpose because it's easier to get 4‑byte AS and it's a separate AS from Hurricane Electric. It helps us to get more like the paths, the 4‑byte paths. We ran into an issue that from one box, one vendor, they sent us the open and when they send us an open it basically didn't have the 4‑byte AS extension in it and then obviously it failed because it couldn't really understand it and when we send the open, it basically responded back as the wrong AS number. So like, okay, they just configured it wrong. We asked them for a config how it looked like, and that's the config they looked at, Cisco like, it looked all perfect. Everything was fine. It just every time we checked it, it's the wrong AS number.
So, we finally figured out, this is like a fancy box who basically you have to enable 4‑byte AS, and if you don't enable, you can still configure the peer, it does not complain, it will still try to open the session, they will just complain that AS numbers don't match in both directions and it will actually re‑try it every I think about five seconds with no back off at all. Anyone here from Brocade, extreme here? You may want to have a discussion internally.
Okay. High AS numbers. There was always a question, well it goes more in the wrong AS numbers or something like what is like the unassigned ones and we say I'm wondering what happens there, I see some this really weird AS numbers when I zoom in like that. And I'm not sure if anyone have ever seen that in a BGP path. If you say sure, I would, I am curious what you had. The case we had, it happened at one company, they had a peer of ‑‑ it was a peer between net online extreme and the Juniper router. It was the normal, it happened there so it was not the connection to us. It was on an incoming peer, a normal 2‑byte AS peer, we looked at it on their side. It was a software version that was different. We don't know what it is. The BGP session cleared it up, but it actually was really interesting how it propagated the wrong. Something went wrong in this box, I don't know, either on the Juniper side on on the net online extreme or whatever, and very corrupted. So if anyone knows more what's going on, I would be very interested, but it seems ‑‑ I have seen it about three times. So, it's not the a one‑time issue. And between different like other companies and peers.
If you have some of these combination on your peer, I mentioned just do a simple regulation, look for something, have you anything like AS numbers with 7 digits in there, then maybe you should look into it.
Extra withdrawals. By RFC you should only withdraws which you actually announced. There is, we saw like withdraws for the default route. Kind of a bit weird, but then we figured it out, well I don't know if it makes any impact, but in BIRD actually they seem to be not keeping track on it, so when you announce that part, then it's basically about ends there. That's basically, they just ‑‑ they don't seem to care when they do withdraws, they just send all of them basically because they don't know what announced the BGP. If any one of you knows if there is any bad impact, then talk to the BIRD developers or anyone who is here. I don't know if that really makes any bad issue.
Repeated BGP announcements. We haven't really figured that one out. But there are some peers who announce the same route exactly the same prefixes as us, same attributes and everything, 01, 01, 01 again over again. I still have no idea what's going on there and I haven't got any answer yet there. I'm not sure if any one of you those any practical use why I want to do that. I mean, there is nothing changing in it.
Okay. And that's basically it. So, I welcome you all, go to the website. Try it out. Sign up with an account. I would love to get as many peers as possible so I can get more interesting things and we can do more cool things. We have a lot of ideas but a lot of it depends on like we get at least a few hundred peers.
Okay. That's it from me.
(Applause)
CHAIR: Thanks for the interesting presentation. Are there any questions for Martin?
AUDIENCE SPEAKER: Hi. Ben ‑‑ RPKI.
MARTIN WINTER: We don't do any RPKI in there. I was looking at it a few times to potentially just do a compare, what happens if you turn on RPKI compared to not. And because I worked on a bit of that, I can test FR routing, but I ran out of time and into an issue there on FR routing of the RPKI. So, not yet. I may do that. But you could announce 2 peers to it, one with and one without RPKI and compare it and see what it is. But it's not part of the tool directly.
AUDIENCE SPEAKER: Stephane Bortzmeyer, AfriNIC. I noticed in your slide that there is API information but when I create an account and log in, I don't see it, so there a PI, is it happen?
MARTIN WINTER: There is an API there, but if you are clever enough you find out where part of it, let's say like that but we haven't documented yet. So we removed some of the main links there but it's planned to open it up somewhere in the near future. But yes there is a full address, full API and stuff there.
AUDIENCE SPEAKER: Good idea. Thanks.
AUDIENCE SPEAKER: Randy Bush. IIJ and Arrcus. Yet another route views in RIS, and then the Italians also, there seems to be a popular sport to collect announcements if I care about history, route views goes back to 1997, every could you go back one slide. We published a paper on this. This problem is well known. You know, your presentation came in two halves. Yet another route views, RIS, and yes, we have seen these crazy things on the net, well people have been getting Ph.D. thee season the crazy things in BGP for 25 years. Okay. This is one. That's known why that happens, I'm not saying it's good, but it's known why this happens.
Lastly on the RPKI question, if you just check the announcement versus RPKI it might amuse you, especially if you point it at he.net‑announced prefixes.
MARTIN WINTER: Okay. So from the repeat announcement that it was done before, that's possible, I have to say, I didn't investigate on this one that much. From the RPKI, yeah, obviously right now I think it's not such in good shape and I there are a lot of people who like verified the whole thing, so that's a community problem in general.
AUDIENCE SPEAKER: Andrei Robachevsky. So there is indeed several data collection efforts existing for years. APNIC is planning to deploy a bunch of route collectors to expand in Asia Pacific, is there any idea to cooperate because, well, there are different presentation layer and different tools built on that, but data collection seems very similar.
MARTIN WINTER: So, I am aware of some of them, we looked at some of the data initially, but in our initial look at it for some, not all the features we have here, we have a long list of like additional things we want to do, and we kind of missed some of the information there that we couldn't get all the details on there. Especially from the exact timings and other parts. Also, having really the, from the announcements how much is like with announcements in there so say let's like do it our self this way. So, we tried to import some of the things, but it gives us like limited view from the imported part, the one we found. But if you are involved in the other ones, ping me afterwards I'd love to talk to you and see if we can do something there.
AUDIENCE SPEAKER: Another question. Do you have a methodology how you identify those incidents documented? Especially route leaks.
MARTIN WINTER: The leaks we haven't implemented yet. It goes down there like, so that's ‑‑ we have some ideas. We haven't really tested them, all the ones, which one works best. So I can talk to you off line if you have some ideas too. The hijacks, we have some good ideas how we want to do it right now it's a basic set that may not get that much use, but a lot of it as I say, it depends on getting much more peers for like seeing some stuff. But, again, talk to me off line afterwards and we can talk about that part.
CHAIR: Okay. Thank you. Thanks Martin. Any other questions for Martin? No, okay. Thank you again.
(Applause)
While our second speaker comes to the stage, remember to rate the talks, and remember, we have elections for the PC, you can nominate yourselves, so go to the website and look at what you have to do. Just send a picture and your small biography. And our next speaker is from Qrator Labs.
ALEXANDER AZIMOV: In the next week I think there will be a lot of talks about BGP. I'm sorry for that.
So I am from Qrator Labs and today I'm going to discuss with you flexibility of BGP configuration process and its consequences. So, BGP is a unique world, we have thousands of players that have same rights and obligations.
Each ISP may request an allocation from its routing registry, each ISP may announce prefixes and traffic, and of course there are several obligations.
ISP must not hijack address space that don't belong to it. ISP must not leak routes, ISP must drop spoof traffic. ISP must configure proper ingress filters. Northerly all of this is fake.
The only obligation that each ISP has is is to pay fee, regular fee to its routing registry, and that's all. And the consequences are clear. We have two types of BGP incidents that are happening on a daily basis. So it's BGP hijacks, when announces systems of prefixes that don't belong to it, and route leaks, when ISP announces prefixes received from one provider peer to another provider peer. And here is the most notable event of the previous year. It was Google, and it leaked a significant amount of routes at Japan to Horizon. As a result, disrupting a significant part of Japan Internet. It was, in mass media it was widely discussed and unfortunately it resulted not in rates of awareness for the community. But for a lot of people supported a very dangerous illusion that there was a hijack of YouTube, and after ten years, there was a leak by Google. And that's all.
The realtime of course is different, and in realtime such events have already become a regular, and let's see they are notable. Global or regional events that happens here last month. The first one happened with Amazon, it was hijacked. The hijack affected the Amazon DNS service, but Amazon was not the target, so attacked address space after that they changed DNS output for several websites, their use were redirected to the phishing website. After that, it was easy. The traditional off users were gone, the interesting thing is that the attack lasted for two hours and was a full ‑‑ Amazon, okay, it was noticed by Amazon but only afterwards when the attack was successful.
In another one, it happened only two days after Amazon. Most of the people laughed both days, especially kids. And what do you need for a party? You need friends, presents, birthday cake with candles, and each ISP in the world, when it starts to announce prefixes maybe want to become one day in the centre of the Internet. And so what happens to an ISP that emerged at Brazil? And their day of birthday. It announced about several prefixes that were not belonging to it, including 16 /8 prefixes. So, it's nearly 5% of all IPv4 address space. And unfortunately, there were conflicts with some ISPs including Comcast, AT&T, that don't have less specific. The significant traffic was redirected through China to Brazil and this was dropped.
So, another one, a week ago, after a hijack in Brazil, it happens in Asia. So normally traffic from Russia to Asia region goes through Europe, it has a lot of latency, and so an ISP decided to assist Russia and it leaked routes from Russia to China Telecom, creating a more straightforward route and the latency may have become less, but it was not because the amount of traffic was high and the ISP died. So we are fortunate that it lasted only for two minutes.
So of course, we can blame the sources of these anomalies, but the problem is not only the mistake. The problem is that these announcements, these malformed routes are distributed globally.
Okay. We don't have BGP police, we don't have BGP exams. The only thing that we have is BGP ingress filters and if something is really wrong with these filters, if such anomalies become globally propagated and become globally propagated at regular better values.
So speaking about BGP ingress filters. I will just briefly just describe how they work.
For an upstream provider should, for a selected customer connection, select AS‑SET. This AS‑SET must then be transformed to a set of ASNs and for these ASNs must be retrieved a route object. It's an Olympics list. It doesn't create a regional validation anyway. And applying these prefix list is a road map, we are getting a Proxy‑Arp IRR filters. So in an ideal world, I said equal to AS Cone. If an AS receives a prefix that doesn't belong to a customer cone, it must be dropped. It has limitations. For example, if incidents happen inside customer cone, it doesn't matter if it's a hijack or route leak, it will bypass any proper IRR filters, but of course it's not the only problem. The main problem is that AS‑SETs are poorly maintained and the problem spreads for bottom to up. The properly implementation of filter will be learned by upstream provider and so on, until it will reach tier 1s. So, IRRs can be useful, but the situation with quality of AS‑SETs makes it much more less effective.
So, we decided to investigate this issue so find out how many filters were already bypassed, were already violated by such incidents as hijacks and route leaks.
We created a very specific scenario. We started propagation of route leaks. We were studying it for prefixes that had a unique and proper route object. We also built a customer cone using our AS model to guarantee that the prefix ‑‑ the route leak that is accepted doesn't belong to the customer cone. And here is the results.
We have proved evidence that 7% of transit ISPs in IPv4 have problems with filters. And 1% in IPv6. One may say, the numbers are not so high. But, if we sort it by size, we will find out that all tier 1s are affected. More than 50% of top 400 ISPs in IPv4 are also affected. IPv6 looks a bit better, but it's not about IPv6. It's about that IPv6 is still under deployment, there are less transit ISPs in IPv6.
Also, we decided to start, okay, there are problems with filters, we definitely have them. But sometimes we can say that the filters are broken beyond repair. So, we can say that something is terribly wrong or there are no filters.
And for this, we started propagation of route leaks with origin of tier 1s. You should never accept from your customer connections routes that are originated by tier 1s. This is the list that are doing this. On this slide, there are highlighted several ISPs in Russia including local tier 1s. It just explains why such incidents are happening in Russia.
On this slide, you can see China Telecom and China Unicom. Here are IXs, including the biggest IX in the world. And here is Hurricane Electric. One of the biggest ISPs in IPv4 and tier 1 in IPv6. So thing about it. It's your peer, if you are huge, and you will constantly receive leaks, hijacks from your peer.
As a result, AS‑SET may be a useful mechanism but the quality of AS‑SET nullifies investments of people who are keeping their AS‑SET up to date. And normally, these filters are not applied with the peers, and if your peer is not using IRR filters, what is the use of your filters?
So, of course, people realised that there is upcoming problem years ago, and the most promising solution at the moment is a region validation that is built on top of RPKI infrastructure. It gives an opportunity to check the validity of prefix or region. It sees accidental hijacks but it's not working for malicious, because it relies on the AS path attribute. It can can easily formed to bypass a reasonable validation. There is another problem adoption rate.
So, only 10% of prefixes in the world have a ROA records. And 10% of this 10% have the status of this check will be invalid. This just highlights no transit ISP in the world are dropping invalids.
It is a vicious circle. Transit ISPs can't implement ROA validation if their customer links or peer links or anywhere else because of the quality of data. And other ISPs are not signing ROAs because nobody using them. I think the first step must be done by signing ROAs because it's really easy and, for example with RIPE visit, it will take you only 10 minutes, not more.
So, ROA validation can be very useful to a filter mistake hijacks. But, it can be used to detect route leaks and also malicious hijacks will easily bypass this.
The main problem of course, it's adoption rate.
So, speaking about the security step of BGP at the moment. We have IRR filterings and ROAs to detect hijacks. Again we have IRR filters and a set of drafts to detect a mistake route leaks. And we have only one mechanism to detect malicious activity. And it is BGPSec. BGPSec was actually developed during last 7 years. So the idea is to sign ‑‑ to have a potential to geographically sign AS path so that nobody will be able to put anything invalid in it. The idea is to sign not only the attributes you have but also to sign the target where the prefix is announced.
So, it's working. Unfortunately it does not. Just remember, that the problem of mistake hijacks was already solved by a ROA validation. And of course BGPSec is a bit complicated protocol. And there was a need for backward compatibility. And to support this backward compatibility the speakers must agree that they can both speak BGPSec at the beginning of BGP session, at the open. And for takers, the only thing they need to bypass possible BGPSec and all its filters is you have to say, I can't use BGPSec, sorry. That's all. So, it's a very strange situation when to have a security opportunity, you need to make attackers to support t it's really, really weird. So, at the moment BGPSec is bringing complexity and it does not bring anything in return.
So, here we have a problem. There is nothing at the moment that can help us with malicious activity. Still, the good thing is that malicious activity at the moment is rare. The main problem is still mistakes. It's fat fingers. And of course, we can wait for some new drafts that will for example assist us in detection of route leaks, but there are things that we can do as a community at the moment.
So, each party must do their own homework to keep our wonderful system of BGP alive. So, for transits.
Transit ISPs should remove any legacy filtering including laws, including route sets and should apply IRR filters on all their links. You should also work with your customers. For example, you see that your customer have edit in its AS‑SET level 3 or entity, you should work with them. I know for sure that some ISPs are already doing this work for example, I know for sure that it's done for Tata, there is an effort by Deutsche Telekom, but it must be done by all major players, and unfortunately, previously, you were constantly relying on your peers. But at the moment you are relying on your peers you are delegating your security, security of your customers, and at the end of the day, for the end user, it doesn't really matter from which source have you learned your Amazon hijacked route. If it was a customer, peer or provider. His money is gone.
So, about IX, first recommendation they are the same. But at the same time IXs are in perfect position to lead routing innovation, because they don't have full table. You can start, for example, streaked a region validation, just now, because it will not affect services of your customers. Of course you need, maybe you need to work with your customers to tell them in advance, guys, you have a problem. But if you have a good guy of course, but you are already dropping routes according to the route objects, why should you not drop it according to the ROA validation?
And multihomed. It's okay to rely on our upstream providers. We should ask them to ‑‑ we rely on their filters. It's part of their service. But we have our own work to be done. We should keep our route objects up to date, we should keep our AS‑SETs up to date. We should sign ROAs. Again, I'm not able to say it for all regions, but in RIPE region it's very, very simple. It took 10 minutes to sign objects for my autonomous system. Unfortunately to detect malicious activity, there will be no option than constant BGP monitoring for a couple of years at least.
So thank you for listening. Questions?
(Applause)
CHAIR: So if you have any questions, come to the mic and state your name.
AUDIENCE SPEAKER: Patrick Gilmore, currently representing RIPE but speaking for myself. You suggest that IXs filter on IRR boundaries, most IXs don't look at anything above the Mac address so you are suggesting that they start going beyond that and actually looking at the BGP on peer links?
ALEXANDER AZIMOV: First, two things. First one, scenarios I know, IXs are already implementing IRR filters, including the biggest European IXs.
AUDIENCE SPEAKER: Are you talking about on the route server?
ALEXANDER AZIMOV: Yes.
AUDIENCE SPEAKER: Sorry, I thought you meant on bilateral peerings.
ALEXANDER AZIMOV: No, I'm speaking about route server.
AUDIENCE SPEAKER: Ruediger Volk, Deutsche Telekom. First, let me confirm, yes, getting the IRR information that our peers and customers give us to get cleaned up is really hard, and kind of tools that help and provide a little bit of diagnostics of what looks bad and what should be investigated are not well known and circulating a lot. I am most willing to share experience and tools and demo stuff of that kind if anybody is interested.
Then I would like to comment in two places where I think your message was not exactly correct.
The one thing is for that question, whether there is a chicken and egg problem about the ROA signup. If people recognise that creating the certificates and the ROAs is providing additional high quality set of information that can be used for the origin validation, but also as an alternate and additional source for doing their filters if they are for whatever reason not yet willing to jump onto the origin validation in the live network. If that information path is recognised, actually I would say that chicken and egg circle really kind of blows away, and by the way, the idea of using that information path has been inserted into the discussions of ARIN that is considering to redo their IRR because they figured out it wasn't up to the demands and kind of the idea of instead of wasting effort in doing a respin of their IRR, putting effort into actually getting their RPKI well done and the information path available and making all that information actually publicly available, which is not the case at the moment, seems to be a good thing.
The other thing is, your observation that BGPSec kind of is essentially broken if someone doesn't cooperate, I think you missed the opportunity that parties that actually are using BGPSec, parties that don't want to use it we can't help, obviously. And if I am BGPSec‑enabled and one of my neighbours ‑‑
CHAIR: Rudiger, can you keep it short.
RUEDIGER VOLK: Yes. And if one of my neighbours just doesn't enable the capability or he actually enables but doesn't send secured stuff, of course my policy will actually take into account when accepting announcements whether I have secure information or not. So, that can not be subverted. Well, okay, someone who is playing fowl there may actually subvert the propagation of the route he is sending around.
ALEXANDER AZIMOV: So, it was a long comment. So, speaking about the opportunity to use BGPSec to detect, to deprioritise some routes that are unknown. Okay, it's possible. But still it's not part of BGPSec.
And at the moment, what the document states, so the goal of the document was to secure AS path and if we ‑‑ we need to realise that the AS path will be secured if it is supported by hijackers. For me it's strange.
AUDIENCE SPEAKER: Andrei Robachevsky, Internet Society. Regarding your last slides what different players can do, I just wanted to mention that last month, the IXP community launched a MANRS IXP programme where many actions are summarised that five actions that IXPs should do as a baseline and one of the most prominent one is filtering on, or AS filtering we should improve and I wish you mentioned MANRS. This is a community effort which sort of distills things that you mentioned on your slides and can create actions which we promote as a baseline, as a now norm in routing security.
ALEXANDER AZIMOV: Thank you for your comment. I'm sorry, I wasn't ‑‑ I forgot to add MANRS as one of the options that you should follow. Sorry.
AUDIENCE SPEAKER: Hello, Andreas Polyrakis from GRNET. My comment was pretty much the same. I just want to add that basically I agree with all the things that you said. I just want to say that another thing that we can do is that we can, if we go to your second slide with things that the IXPs should do but they do not, their only obligation is to pay money. Maybe we can enhance this. Maybe we can write some RFCs or some best practices document, or maybe then we can create some kind of obligation and hear some consequences for people for ISPs to break this obligation. Okay, the last thing is no so easy, but at least we can have some documents. For example, I had a customers a couple of years ago and I was trying to convince him to create route objects and they I said that you must do it and he said why, and I couldn't find a document that actually said that they must do it. Not even a document that said that they should do it. So... I think that I think that would be useful.
ALEXANDER AZIMOV: So is it ‑‑ you say that it will be useful for your operation ifs there will be for example a BCP that you can researches and say my dear customer, take a look, it is written on the IETF, it's like a like you should obey?
AUDIENCE SPEAKER: Yes, exactly, because ‑‑
CHAIR: Can I cut you please? I just want to say that ‑‑
ALEXANDER AZIMOV: Thank you for that comment.
CHAIR: There is a BCOP for the best practices document on the Monday evening every RIPE meeting that, would be a good thing to do there. Geoff. Go ahead.
GEOFF HUSTON: Geoff Huston. Thanks for a really depressing talk, because at this stage ‑‑
ALEXANDER AZIMOV: I did my best.
GEOFF HUSTON: At this stage I think we really are in bad place with no answer. BGPSec is protocol correctness. If we all deployed it, if. That still doesn't, if you will, filter out policy problems. Because I can renounce routes from transit A, transit B, BGPSec is just fine with that. It's still a bad thing. IRRs, if we all did it, it's policy correctness without protocol correctness. Again it's the other half of the problem but we all need to play. If we all built houses out of steel, maybe we don't need a fire brigade, but it's really expensive to build houses out of non flammable material and none of us want to do that, all of the time where where. So a lot of tools tend to fall over because no everyone plays the game. This is a problem. You go well, okay, we have fire brigades, build your houses out of wood, when the smoke starts going, call them up and they'll put it out. We just saw evidence of attacks that you put up where the attack need only last for a second to be effective. And so how fast do you want your fire brigade to run now? So at this point, I can't build my houses out of steel. The fire brigade is too slow. I'm stuffed. Like I said, thanks for a really depressing talk.
ALEXANDER AZIMOV: The conversation is more depressive than the presentation.
CHAIR: Last comment.
AUDIENCE SPEAKER: Tim, RIPE NCC. Just a very small comment regarding the chicken and egg problem with radios. So 10% of the global table tension of prefixes may be signed, but there is a big local regional differences. The up take in the LACNIC region and the RIPE region are higher than that. And in some European countries for example you see 25% of prefixes validly signed and 50% of ‑‑ so I just wanted to leave that as a data point now. It depends on where you are. It may be more useful to you ‑‑
ALEXANDER AZIMOV: A valid point. But, at the end of the day, we need full table to be signed, not one region to be signed. That's all. Still a valid point. Thank you.
CHAIR: Okay. Thank you.
(Applause)
And welcome, Job, with the last talk for this session.
JOB SNIJDERS: Good morning everyone, my name is Job Snijders from NTT Communications, and today I would like to share some insights into data sources that are available to us to the filtering and I'll mention some upsides and downsides of the various sources, how they relate to each other, what path forward can be for this community.
I'll cover why routing security is important, because we don't just keeping banging the drum but there is a reason why we want this stuff. How IRRs work around the world and then we'll hopefully have sometime left for short comments.
So, BGP hijacking has become quite lucrative with the rise of digital objects that represent values, for instance, Crypto currencies or authentication tokens. We see more and more that BGP hijacks are leveraged to steal data that is in transport. A great example of this was the hijacking of the prefixes which contained the authoritative name servers for MyEtherWallet.com. This lasted for about two hours. The perpetrators inserted more specifics into the default Freezone. Originally all of these prefixes were lash 23s originated by 16509 Amazon and then for two hours we saw lash 24s originated by an entirely different ASN and the traffic was syphoned away through a tunnel of sorts and fake replies were sent to people querying for an AAAA records in this domain.
This was like a heist that was basically the equivalent of what you see in ocean's 11. A few years from now people will make movies about this stuff.
The good news is it could have been worse. The ASN that was complicit in facilitating this hijack had various upstreams. NTT, Cogent, Level 3, all of these blocked the announcements because they were generating filters based on IRR. So however infallible we consider IRR, there is still some value to it.
There was some peers, Hurricane Electric, Google, BBOI and others that did accept the hijack, and some of those propagated it far wider than necessary. More information is on the Internet Society blog, it's an interesting read up.
So, these are the three reasons to do filtering.
By creating filters based on public data sources we force adversaries to at least leave some trail of their attempts to create opportunity to hijack prefixes. I monitored the IRR databases carefully, we store every change, and this allows us to go back in time and see who created what objects and then hopefully correlate that to malicious acts. Bugs happen. We worked on routers where the running config was clearly not the running config the router was thinking it was running. To simplify that. We thought we had routers configured with export nothing, and in practice, they were exporting everything. Cannot protect against bugs, my only hope is that the people on the other side of the eBGP session have some form of filtering, have put in some safety mechanisms, because once my router is acting in a way that is not compliant with how I configured it, I am quite powerless at that point.
And then last but not least, all of us have made typos. The letters on the keyboard are quite close to each other, 4 is adjacent to 5, it is really easy to mistype and cause problems for someone on the other side of the planet. So by both sides having filters, we mitigate all three of these issues, at least in part.
If we look at how to construct filters, there are various steps in every, what I think should be in every eBGP filter. You reject private IP space, you reject announcements with private ASNs, you reject peering LAN prefixes and its more specifics. You can do a rejection based on AS path filters based on ground proof, for instance, we would never accept routes from level 3 which contains AT&T ASN anywhere in the AS path because we know that that obviously is a misconfiguration.
So I will zoom in now on, you know, not the rejection side of the filters, but what is the white list and how you can generate the white list. And if a prefix announcement is not part of the white list, then we reject it.
So what is this IRR thing? It stands for Internet routing registry. Many operators use this as a source to generate per customer or per peer prefix filters. These IRRs generally are public sources and this facilitates debugging but also provides transparency. And by making your sources available to the public for inspection, other parties can see what you will consider in your white list and they can replicate your approach to filter generation.
There are all kinds of data sources and I am just going to lump on one big pile IRR, WHOIS and RPKI. Within the IRR family, there are sources that are offered by the regional Internet registries, so these are RIPE, APNIC, ARIN. Then there are IRR sources operated by what I call third parties. Now these are the likes of RADB, NTT, ALTDB, so aside from these requires sources there is also WHOIS sources. What I mean about WHOIS is that it's not structured in the way that IRR sources are with RPSL, but there still is routing data hidden within those archives and we can use that to create filters.
Then last but not least there is the RPKI to consider as a sort of data to generate filters as well, but unfortunately not all of these sources operate by the same rules.
Before we delve into that, let's deconstruct what happens when we generate filters. The atom of the IRR is the route object. The route object is basically a tuple where only three things are relevant to the programme I can filter general race, there is the prefix itself, the origin ASN and the source which IRR it came from. And these three components are the only ones relevant to the filter systems NTT users and that many other operators use. Everything else, description, notification, when it was changed, is not considered in any of the processes.
When I want to generate a list of prefixes that may be originated by AS15562, I can issue the intuitive commands ! GAS15562, for instance, running here, and it will give me back a list of prefixes where the origin ASN is 15562. This list of prefixes can easily be transformed into a Cisco, Junos, BIRD or whatnot configuration.
BGP Q3 is often used to interact with IRR daemons and can be used to construct filters for various platforms.
Now, this only helps me for one ASN and this only helps for stuff networks. What if there is an ASN is a provides transit service to say other ASNs? You will need some kind of way to signal to the one generating the filters what the group of ASNs is that may show up behind the directly adjacent ASN. For this, we have AS‑SETs. In an AS‑SET, there are a few components that are relevant to automation systems. There is the name of the AS‑SET, AS 15562: AS‑Snijders, and then there is list of members. Members can be either ASNs or references to other AS‑SETs. And of course the source of the IRR object again is relevant.
If we look under the hood at what the automation systems do. They issue a command like !IAS15562: AS‑Snijders, 1, and it will list a list of ASNs that can be expanded from this AS‑SET. Then for each of those ASNs in the AS‑SET, you do the !G look‑up and the totality of those results can be mangled a bit, aggregated, deduplicated and that is basically what ends up on people's routers. But there is an issue here. Not all IRRs are equal. They differ in terms of ownership. Some are member based, some are corporation owned. Their purposes differ. Their policies, their validations. And another interesting thing is that all of IRR is garbage in, garbage out. All of this is as good as the people submitting objects to these systems. Some of the IRRs provide excellent training material on how to construct these objects and how to properly inform the rest of the Internet of your routing intentions. Some don't. Some of the IRRs have fancy web interfaces. Some require interaction with this archaic thing called e‑mail.
So let's go over some of differences and I don't expect you to remember all these minute differences by heart. But it just goes to show that there are significant differences between the IRR sources.
For both NTTCOM and RADB, the two largest IRRs on this planet, the only validation is basically does a route object exist today? And if not, we will happily store your new proposed route object. And the only requirement that we have is that you are a customer of NTT or a customer of RADB. So for 500 bucks a year you get to create any route object for any prefix that is not yet covered. This is, of course, far from ideal and requires substantial reactive policing to try to keep some clean data in there.
Then, there is the ARIN IRR, who have a very different approach. All you need to do is be a member of the ARIN organisation, and then you can create any route object for any prefix as long as it doesn't yet exist in the ARIN database.
Then ARIN has a second source of data: ARIN WHOIS, and in the ARIN WHOIS database, only the owner of an IP prefix can designate who the origin AS is. So this is where there is already two databases, one is unvalidated and one actually has pretty good data.
Then comes the RIPE database. And this is the most confusing out of all of them. In the RIPE database, only the owner of an IP block can create or designate route objects except when it's not RIPE managed space. So, if the IP space is managed by RIPE NCC, there is a pretty good chain of trust from RIPE's internal administration to who can create route objects and these objects are are good quality because only the owner can modify them. But if you, for instance, bring APNIC space or AfriNIC space and you want to register that in the RIPE database, there is no barrier, there is no validation and it just goes through.
But the future is bright. In the Database Working Group session later this week, it will be covered in far more detail and there is also good articles on the RIPE Labs block, but in the future we will be able to differentiate between which route objects from the RIPE database were actually validated against the internal authority chain, and which were admitted into the database without any validation whatsoever.
Another thing about the RIPE database that sets it apart from other IRRs is that it requires not just the owner of the prefix to somehow pass validation, if there is validation to be passed, but also the origin ASN has to approve creation of the route object. This is fairly complicated from an operational perspective, because it requires you to create perhaps duplicate aut‑num objects and there is all these hoops you have to jump through. Luckily this is going to change later in 2018 and this will align the RIPE IRR more with APNIC and others.
Then there is the APNIC and AfriNIC database where at this moment you can only create objects that are managed by APNIC and you can only create those objects if you actually have ‑‑ if you are the owner of the prefix or you have been designated by the owner of the prefix to create objects. And this is the most clean approach.
So, the summary is not all the same. It's kind of a mess out there. Luckily enough, many of the IRRs are on a trajectory towards improvements and are modifying how they admit new data.
Let's zoom in on the concept of WHOIS for a little bit. From one of the early slides I highlighted that route objects the only relevant piece to automation is the prefix, the origin ASN and the source. So, in the ARIN WHOIS database, you can designate per prefix who the origin ASN is, and this gives us the tuple we're looking for, prefix, ASN, that we can use in the creation of filters. And the good thing is, this database is quite trustworthy because per definition only the owner of a prefix can modify that trick field, so what NTT is doing these days, we download the entire WHOIS database, we throw away everything we don't need except the CIDR parts and the origin ASN, that's converted into IRR objects, loaded into rr.ntt network so it can work with our tool chain, and this is an example of how such a prefix looks.
So, this is basically a WHOIS to IRR gateway at this point. Similar for the Brazilian region where we do not yet have either RPKI or an independent IRR. There is the Registro.br database and by policy of how they manage things recollect the data in this database is of significant quality and can now be accessed in a programmic fashion by downloading the entire dump of that particular database.
So both these sources contain routing information that previously would not be used in an automated fashion, but because of the use of dumps and conversion to IRR, these are now actually accessible by the likes of BGP Q3.
Then there is, of course RPKI to consider as a source of data as well. In RPKI, we have the concept of ROAs that can be used for not just origin validation but perhaps also for provisioning. In RPKI, we can recognise the tuple of a prefix and an ASN, and this can be transformed into IRR style objects conceptually as well.
Per definition, RPKI is very trustworthy data because only the owner of a prefix can affect these ROAs, and that, for me, is a great assurance that we have at least some hope they can communicate what their intentions were.
So, don't just consider RPKI for origin validation purposes. Also, consider RPKI in your provisioning process when you create peer or customer‑specific filters, because in the end for the provisioning purpose, a ROA is not that different from a route object.
This is a super simple one liner that I do not recommend for production purposes. But what we do here is, I take a dump from an RPKI validator in adjacent format, I pipe it through jq to only select the ROAs where the origin ASN is AS33.33 and then I filter out IPv6 of course and what we result is a list of prefixes that could be installed in an IPv4 specific BGP filter.
So, this is quite easy to integrate with many tool chains and I would invite the audience to do so.
Then there is another consideration. Given that we know that RPKI data that is derived through the five RIRs is in fact created by the owner of the prefix, maybe we can use some of this RPKI data to drown out rogue or still route objects. Many of the IRRs are filled with legacy proxy registrations, the very notorious in that regard is the reach database but NTTCOM, RADB are also seeing significant amounts of registrations for which we don't know if the owner of the prefix actually wanted that route object to be there.
So, leveraging RPKI data, maybe we can have IRRD instances that consume both recollection data and IRR data and will only return the RPKI data if the IRR data is in conflict with that RPKI data. I think this could be a way forward for the community to at least dampen the negative effects of legacy proxy registrations and it creates an incentive to create ROAs, because even if people are not doing origin validation, the ROA still have a benefit because they help drown out the false IRR entries.
If you want to interact with RPKI data and generate configuration snippets, I wrote a very small tool that depends on a JSON expert from an RPKI validator called RTR Sub and this allows you to inspect or create ESP files from RPKI data for your analysers and perhaps provisioning.
So this is my last slide, and what I'm basically doing is creating a to do list for your community on how to move forward on this concept of routing security. I don't think everything is hopeless. I think there is actually a viable path for us to significantly increase the robustness of our ecosystem. So, first of all we need to deploy or fix any outstanding IRR issues related to non validating RIR‑driven IRRs. So in this case RIPE already is working on implementation plans to fix their issues, and ARIN has held a public consultation in which they asked the community what should be the future of our IRRs? Should we kill it? Make it better? If we make it better, how should it be made better? Either way, if they make it better or kill it, that's fine by me.
For RPKI. I think we need to increase the operational robustness of this system. For instance, we should consider certificate transparency, as is also popular in the TLS world, we can consider using RPKI to drown out IRR objects, so that's a change that only happens at the IRRD level and we should gain more operational experience, I would challenge people doing origin validation for their directly adjacent neighbours, because even if a world without path validation, your directly adjacent neighbours are your directly adjacent neighbours and what we originate could be validated against RPKI and therefore giving you a good path that is trustworthy, although it's only one hop.
To facilitate the ingestion of all these sources of data, it is important that we allow ourselves to be able to innovate in this space. And the current IRRd that is used by the majority of people generating filters has been an organic code based written over the course of at least 20 years, and unfortunately it is no longer maintainable. It is not possible to extend the IRRd version 3 code base in such a way that we can give give operators better quality data by weighing various sources of the data. It doesn't have HTTPS, it lacks a lot of things that will be impossible to have. So to that effect, NTT has tasked a company called [Desh Care] to write a new IRRd daemon from scratch in a modern language to at least get the industry to the point that we can innovate and consider sources of data differently.
And then finally, I think it's important to create an equivalent of AS‑SETs in the RPKI data structures, because AS‑SETs in the IRR have quite some down sides. There can be duplicates. We don't know for sure that an owner of an ASN created that specific AS‑SET and some of these concerns can be taken away by using RPKI.
So, this is a long to do list. This will keep us busy for at least one or two other RIPE meetings, but I think there is some hope, even though hijacks are quite easy at this moment.
With that, I have reached the end of my slide tech and I would open up the mic to short questions.
CHAIR: Thanks, Job.
(Applause)
We have a little slot for short questions, please.
AUDIENCE SPEAKER: My name is Iljitsch van Beijnum with Logius. I have one short question and one maybe not so short. The short one is what is certificate transparency?
JOB SNIJDERS: If you look at certificate authorities, these are entities that create a certificate that asserts something. For instance, that the owner of this public key in fact is the Google corporation. In the RPKI world, the RIRs are certificate authorities and they can create attestations that this radio was in fact created by the owner of a prefix. However, the RIRs have chosen to deploy a model where they can sign for any prefix, so in theory, a compromised certificate could sign ROAs for space owned by, or managed by another RIR. This, in theory, could open us up to lesser robustness. And the idea behind certificate transparency is that the producers of certificates publish with certificates they have created in a pent only log that can be validated by the public and this can help mitigate the negative impact of a compromised CA. Google it.
AUDIENCE SPEAKER: Okay. So, but my main thing with the RPKI is that what do you do when something doesn't validate? Because in all the examples that I see, for instance, on the Cisco website and other places, that it just gets lower local preference. Of course that doesn't help at all especially if it's more specifics.
JOB SNIJDERS: Yes. The lower local preference paradigm is utterly useless. If an announcement is unknown, there is not much that can be done other than fallback to the traditional mechanisms such as IRR based filtering or WHOIS based filtering. So, I hope the future is to outright drop RPKI invalid announcements but if they are unknown, there is not much that can be done.
AUDIENCE SPEAKER: So why in the future? Why not today?
JOB SNIJDERS: Today there are roughly 5,000 RPKI invalid announcements in the default Freezone. And for a company like NTT which has a significant chunk of single‑homed customers, I always recommend do homed, but some of them don't, and there could be negative effects that have dire consequences for their reachability. We need a path forward where we ease into origin validation and do strict rejection of RPKI valid announcements. The path forward for that would be to first do that on IX route servers who by nature have no obligation to provide a full routing table, and other than that, NTT is exploring doing what we call selective origin validation where we start trials with a select number of ASNs and slowly gain operational experience before enabling this for the entire RPKI Repository.
AUDIENCE SPEAKER: Sounds like World IPv6 Day all over again.
JOB SNIJDERS: No! This one will be successful.
AUDIENCE SPEAKER: Blake. First of all, thanks for putting this together. As someone that has walked down the path of of trying to clean up at least the RIPE data for a very large old tier 1 ISP, I can say that it was much easier to just jump on the RPKI. But I have to ten times more good RPKI data than I do IRR data for Zayo's right prefixes, and the second thing is, maybe in PeeringDB, we can put a field that says I have made a reasonable effort to clean up my stuff, please filter me.
JOB SNIJDERS: The default is I will filter you. So there is no need for a flag.
AUDIENCE SPEAKER: I mean, in general, in PeeringDB, if somebody wants to like implement part‑filtering per AS or not, then like that's a way to say I have voluntarily gone and cleaned up my stuff or say I don't know what my data will look like.
CHAIR: We already ran out of time but we will take these two last questions, please keep them short and the answers too.
AUDIENCE SPEAKER: Randy Bush, IIJ and Arrcus. Programme Committee. Could we throw in one positive cheering BGP talk next time? It's a very good talk Job. Two things: One is, most RPKI validation software has the option to generate IRR objects, and you can just put that right into your IRR flow and the RPKI stuff will overlay the bad IRR stuff. And that's there today. It was originally requested by some German telco...
JOB SNIJDERS: Do you mind if I interrupt? It will not overlay. It will add. So, this ‑‑ in the current way the IR D implementation functions. I'm not specifically talking about the code basis for merits and the way BGP Q3 which queries, which is a tool used by many, you can in this use that expert. But it will not only add to the garbage that is already there, and what I hope to achieve is that it drowns out the garbage that is already there.
RANDY BUSH: Just to be careful recollect the data are there. It's how you read them and generate your filters from them that needs to deal with the overlay.
JOB SNIJDERS: Yeah, and that's not trivial at this point in time.
RANDY BUSH: Agreed. And just one last picky point. A ROA does not validate means that it did not have a valid certificate chain down from the RIR. It does not mean that the BGP announcement was invalid. Just to be picky about the terminology. This thing is a mess. We need to get our nouns and verbs straight
RUDIGER VOLK: I would have to say a lot. First, let me join in with Randy, in the security stuff one has to be very picky, with fuzzy understanding of things you quite certainly will run into unpleasant surprises and generate unpleasant surprises for others.
In that vein, there is one question and then I would like to come back to the exchange you had with Randy just now. The question ‑‑ and I'm really picking, what semantic are you taking for the WHOIS origin AS?
JOB SNIJDERS: It's similar to how we interpret RPKI ROAs.
RUDIGER VOLK: It is similar. So it is max length maximum.
JOB SNIJDERS: There is no max length.
RUDIGER VOLK: So it just allows the aggregate?
JOB SNIJDERS: Look, let's go back to ‑‑ I'm going to be short here, Rudiger, because I'm not interested in a discussion about semantics.
RUDIGER VOLK: The semantics ‑‑
JOB SNIJDERS: I see a prefix. And an origin ASN and this is easy to use. Why are we arguing about semantics?
RUDIGER VOLK: Well, okay, if you look into the WHOIS, you will find stuff like something that aggregates a /13 and a /12 and has 2 origin AS numbers there. What does that mean?
JOB SNIJDERS: It's two route objects, or actually four.
RUDIGER VOLK: It's two route objects and the route objects ‑‑ the semantic of a route object is it is exactly matching so no more specifics are allowed by the route object. I am pretty sure that the WHOIS in ARIN is usually not felt that way and I don't think it is useful to have an in‑depth discussion about this right here, but the point I'm making is, the exact semantics count. And so let me jump over to the second point.
And that is, I wanted to point out that opening the way for innovation, as you termed it, in evaluating data is not only what is being done database server side. Kind of, if you have the ability to fiddle around with the client software, you obviously also can do stuff there and, kind of, the question is, where do you have more agility? In principle, I would claim very likely on the client side. Unfortunately, really nice code base for client side isn't there but interesting stuff can be done there. Fortunately, I had a guy who did some of that for me, and kind of that discussion joins in with Randy's remark, kind of, if I have the RPKI information available in, say, an RPSL format on the client side, I can do whatever I like with it.
JOB SNIJDERS: You are right. There are many places where we can do policy ‑‑
CHAIR: We should really stop because we are running out of time. We are running into the coffee break.
JOB SNIJDERS: Let me make one last comment that is short. Modernising the server side will allow us to build clients in an easier way, so they go hand in hand and I look forward to the day where we can have clients that use modern things like graph QL or APIs to interact with the databases rather than what we have today.
RUDIGER VOLK: Kind of interesting thing is how well is that interface able to deal and provide diagnostic information about interesting stuff? I can tell you that's really hard to fiddle in on the server side.
CHAIR: Thanks. Maybe we can just try to talk about it during the coffee break.
Thanks everybody and sorry for this delay and please be back at 11.
(Coffee break)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
