Routing Working Group session
Thursday 23 May 2019
11 a.m.
CHAIR: Good morning. The Routing Working Group. One session this time, we did some experiments ‑‑ the single Routing Working Group session this time. Some administrative housekeeping. The minutes of the past session have been posted. If you are interested in remembering some history, please take a look at those. We have remote attendees, so the microphone he had quiet, please state your name and affiliation clearly when you have your comments and questions.
Agenda:
We have two topics, one is a look at what happened last year in terms of routing and addressing, and then what is happening right now on routing security aspects. And a few topics on aspects related to routing. Routing transparency an update on RIS life services and some applicabilities, or the possible applicabilities of AS‑SETs. Don't forget to rate the presentations, that is important. The committee pays close attention to those ratings. One request from the Programme Committee, they are still slitting for topics for lightning talks for tomorrow's session. If you have something which of think is of interest to the community, please submit that and you might get to the stage.
And with that ‑‑ there is one other announcement. This time we have another experiment. Not the second routing session slot, but a joint meeting with IPv6 Working Group, and that is something like a tutorial or education session or an open discussion on how a modern, contemporary router works and how it sometimes doesn't work in the way that you expect. That is happening in this same room just after the lunch. So, if you want some desert after a good RIPE lunch, please come to that session. And also, provide a feedback on that.
With that, let me invite the first presenter, who will present a view on what happened in routing and addressing last year.
GEOFF HUSTON: Thank you and good morning all. My name is Geoff Huston I work with APNIC. You know, there are two fundamental protocols that glue the Internet together. One is the the domain name system and the DNS resolution protocol. And the other one these days is the border gateway protocol, BGP. Both we're actual artifacts from the 1980s and post were designed in an Internet that was vastly smaller than where it is today. The DNS has effectively survived even though it's scaled by factors of billions. The amount of querying pressure in the DNS is phenomenal. Yet the underlying protocol operation has remained largely unchanged. If I could design a protocol that's scaled by billions, I would be so happy. You know, it is an amazing feat. But oddly enough routing has been even more amazing, I believe. Because not only has BGP which first started routing around 1,000 entries is currently you know most of your FIBs are sitting at close to a million entries if you look inside them, an astonishing scaling factor across the entire Internet. But it's also resisted and kept on working despite your best efforts to adorn it with all kinds of crap about I'm going to do link state inside BGP. I'll going to make attributes carry all kinds of things the colour of my eyes, the the lot. All these efforts that are daunting BGP, yet BGP still works. And one of the questions that we come to time and time again is when will the miracle stop working? When will a 1980s protocol finally give up the ghost and go I'm sorry, the Internet has just got too big, I am going to die?
Now, BGP is a really strange protocol, because what BGP does, is actually bring the world to your router. Every view of BGP actually expressions reachability for every single prefix on the net. There is very few other protocols that bring everything to you. Northerly, you go somewhere else, even the DNS. So BGP is unique like that, that it brings information in. And if you look at a time series from any point, you team get the full history of the Internet.
So this is a scale from 1994 about five years after BGP was first let loose on the world recollect all the way through till basically the end of last year. The introduction of CIDR, inter‑domain routing because we thought BGP was going to die. The great Internet boom and bust because we thought things were going to die. The consumer market finally hit the Internet in the early 2000s and this rise bizarrely, bizarrely was meant to start the v4 Internet before you hit address exhaustion. You were all meant to have gone v6 is the way and the truth. We hit the v6 exhaustion at 350,000 entries in v4, you are now kicking 800 thousand. When are you going to snapshot there is no more addresses, what are you routing? Let's have a look.
This is last year, in fact it's the last few years in detail, 2016 to 2018. Why two distinct bands? Because I am combining route views which is basically a north American collection of peers with the RIS servers which has a fair amount of European predominance and interestingly enough you have less routes in this part of the world than the Americans. Now I don't know what's going on. Either you are missing out on something, who knows? Or, there is this phenomenon of ghost routes, BGDp doesn't constantly refresh. If I withdraw something I'm never going to withdraw it again, you know, but if somehow I fail to withdraw and I should have, you are carrying a route that you shouldn't, and maybe this is all about ghost routes that aren't quite in the other collection. Routes that get stuck in BGP and just never go away. Irrespective of that sort of ghost problem, this network just keeps on growing inexorably, that growth trend is sort of linear, so some quick stats.
Routing prefixes grow by 52,000 every year. I wonder how many of them are hijacks? I wonder if we could ever find out? Because so many, so many, are just new prefixes, 52,000 new address space every single year. AS numbers, 3,400 a year. This is the a machine. Where are all these new ASes coming from? There is no oh next year there is a blip or something, it's just almost like each of these RIRs has a work to order rule and you're only allowed, only loud to process 50 a day because that's the work to order. Because that's this oddly linear. So I don't know if it it's the demand side or the supply side.
Routing indicators, we always said that more specifics and load balancing and BGP kind of took up space that was seen to be a bit inefficient. Whatever the message we said, you're not listening. You are just not. The number of more specifics hasn't changed for years. It's even grown slightly. This is where we stuffed all those nonexistent addresses. When we ran out of new prefixes, you took the grinder and the slice errand started slicing up the old ones. The time of the exhaustion, 7,000 addresses on average per routing entry, today, 3,000800, the trend is down. So, inexorably, you are going to be routing /29s. It's only a matter of time 3800) it will just happen.
This is the only other space where address exhaustion is obvious. This is the total amount of space addressed in BGP. You'll notice after exhaustion we still kept on growing because we mined our history. You know all those legacy addresses is actually the brown coal of the Internet, and we're being coal mining for a while. The coal scene has given out. There is no more. The amount of address space being routed has hit a ceiling, whatever isn't being routed is probably never going to get routed.
And interestingly as well, you are super friendly to each other. No one likes being a customer of anyone else. You really don't. So, when you bring up a new AS you go to the heart of where you see the best connectivity. Long and stringy is not the Internet. The average path length for the last six years from where I see it has been constant. So the topology of the Internet is largely the same. This is a neutron star. As it accumulates more matter, the diameter stays the same. It just gets heavier, the interconnection mesh in the middle. So in other words what's going on here is that you are not growing bigger, just growing fatter.
This is another way of looking at it. And again this is from my perspective. You might see different players. Everybody's view of the Internet is different. This is my view coming from 131072, one of those pesky 4‑byte ones. I see a number of players sitting right by the core. From where I sit the folk who carry the most routes or the most adjacencies is this set here. Your list will probably validator. But what I would reckon is that if you do a distribution you'll find a very similar log log relationship. It's a power series. So what goes on is most of the ASes are at the edge. And the ones that are at the middle, it's actually really very small and mostly if you try and get as close as you can to the middle in as few a hops as possible and that's been the case for years.
So what happened last year? Address exhaustion didn't matter. Interestingly, growth is still happening. 750,000 has been achieved. We're still growing. 52,000 per year. What about address exhaustion? Well, you know, it's going to happen. All the other RIRs, ARIN of course went right to the wall. AFRINIC has got about until May 2020, LACNIC had reserved a small amount of space I reckon that will give out this year, APNIC has got about till November 2020, and the RIPE NCC earlier. Those numbers validator a bit. But the last of those residuals, unless you bring out a new policy that says if you come for the last bits of last address space, we'll only give you a /32, if you ever get to that point you can change that date. I'm not sure what the Internet will get from that action but you know you can push it out if you want. Go for it.
What's driving exhaustion, growth after exhaustion, transfers, last /8s, leasing and address recovery. This is an interesting one I prepared the routing table at the end of the year to the routing table at the start of the year and look at all the new addresses and look at their age. So, in 2010, most of the new addresses I saw, 80%, had been allocated in the last twelve months. Allocate, advertise. So, the growth of the routing table was because of allocation. These days, last year, only 20% came from allocations that are present. All the rest of the growth the in the routing table were old addresses and almost one half of those new addresses I saw last year were coal, brown dirty coal, they are more than 20 years old. This is the legacy space that has been brought to life, animated and thrown back into the network. Over the years, as you see, we have become better and better at mining that finite amount of space. At some point, you are going to run out. Because there is only so much to mine. Hard to say when, for me I haven't looked hard at it hard at it. That's what's going on on why.
This is advertised versus unadvertised. This is the advertised space you are trying to mine. After 2011 that slow growth of unadvertised addresses stopped. And we started going flat and we actually started recovering some. But fascinatingly, last year, in fact that total volume of reclaimed addresses started going up again, blow it up a bit further and what we find is we allocated some address space, the blue line, but the changed in advertised addresses went the other way, the unadvertised address pool rose. So, even though we're under intense pressure in v4, more addresses were unadvertised at the end of the year than at the start. Maybe this whole thing about pressure is a myth. Maybe there is more addresses around than you think, because some folk have got addresses that they are not advertising. That's what the numbers say.
So, that's the summary of that in text. Let's not worry.
Let's move to v6 because v6 is always fun. Here was the exhaustion day. This is the day when v6 was meant to take off. It did, it did. Absolutely it did. I saw it. Oddly enough, you know, things have happened more in the last few months than any other time in its history. Things are moving quickly. Fewer ghosts. What the Americans see, what the Europeans see, largely the same, there is no delineation between the two. It's not linear. Whatever else it is, it's not linear. So that growth is probably exponential, it's around 15,000 prefixes per year less than v4, but that rate is growing. So that will change.
AS numbers: Slightly more than linear. More players are playing in v6.
2,000 ASNs per year compared to 3,500 in v4, still not growing at the same pace yet.
But of course, v6 comes of age when the more specific crap in the routing table equals v4 and you are trying really, really, really hard. The number of more specifics is getting so close. What's the most common prefix in v4? /48s. How big is your router in terms of prefixes? A few million. How many /48s are there in v6? More than you can think. This is unsustainable. This will not scale up because you don't have the silicone to do this forever. That's got to stop. These /48s polluting the v6 routing table mean we have all got a problem sometime out there. And interestingly, because of that, the average routing size is getting smaller because the more specifics are actually taking over. Thank you, such a good job, not.
Advertised address span. I found it really hard with with v6, the numbers are so big you have got to use prefix size. So instead of the numbers going up, the prefix size comes down, linear log means exponential growth. So, you know, read the slides later. Advertised address span is growing at exponential rate because the log span is linear, it's called maths. The shape of the inter AS connectivity is now basically getting a bit like v4. It's getting slightly stringier lately, but it's still pretty constant, around 4.8 to get from one side of the Internet to the other that that's pretty constant.
The adjacency graph, much the same. The number of players, slightly different, and again your view will validator from my view. But that log log relationship still linear. That's the v4 one in grey, that's the v6 one in blue. Same shape. You don't like being anyone else's customers. You just don't. You connect in as tightly as you can.
What to expect in all this. When is your routing going to blow up? We can do projections. Remember I mentioned maths. Do you remember first order differentials? No. This is the first order differential of the v4 routing space. You can see that we're growing at around 150 a day and that's been steady for sometime. So if you have take that first order differential and then extrapolate it back, what you see is, within the foreseeable future we are going to crack the million. Why? Because you are just going to route smaller and smaller prefixes because you are addicted to v4 and you are never going to turn it off. Since exhaustion in the last few years you keep on growing, nothing will change.
V6, it's not linear. The first order differential is actually a slope. Right. Remember maths. So this is accelerating growth rather than constant growth. This means the most likely trajectory is actual one that shows that it keeps on growing T keeps on growing. So we're going to find in a few years it will get up to around quarter of a million. But don't forget this is 128 bits, not 32 bits. The amount of FIB space, the amount of memory space for that quarter million is exactly the same space for your one million v4 so in terms of allocating space if you are holding the routing table in some kind of memory bank you are going to find the same space allocations for both protocols inside of five years.
So in terms of memory size that's what I said.
Don't forget, it's knots just how big it is, but how much it's sort of throbs the level of updates in BGP is really really really important, and this is one of the classic pieces of anti gravity. This is one of the things that made BGP scale that none of us understand why and probably never will. That's the size of the routing table. This is the distance investigator protocol. As the routing table gross, the number of updates required to make it stabilise should increase, right? Right. It doesn't. This is the number of updates per day. Is has almost no relationship to the number of prefixes. We have actually managed this to be relatively constant, even weirder, the number of withdrawals is steady at 10,000 a day.
Why do you with withdraw a prefix? And why don't you? Why is it only 10,000 a day and has been for nine years? I have no idea. Whatever secret sauce you operators are saying to each other, whatever slack channel you are you have never insighted me on, you are going to withdraw a prefix today? No, I'm leave it today, okay, fine I'll do it orderly queue. It is so weird.
But this is the payoff. This is the one pay off. As BGP grows, it is as fast as it ever was, as fast. When we look at the average convergent update count it takes only two updates for a withdrawal and update to be across the Internet, which means inside of 50 seconds everyone knows your knowledge. As a global distributor of knowledge, BGP is as good as it was in 2009, ten years later. Exactly the same performance. If you can do a protocol that scales and still performance at the same rate, using distance vector, you have just achieved the impossible. I am amazed. I don't know why this is happening but it is brilliant that it is. So, you know, your routing will keep on working as long as you have got enough memory, the CPU is just fine, there is no certain there at this point in terms of number of updates.
V6. I wish it was the same. Number of updates is increasing more than the number of prefixes. Now, this is the same protocol, doing the same stuff. But for some reason when you see v6 you sort of panic, really panic, start throbbing around with updates. What is wrong with you guys? Well, I suspect, despite our best intentions, there is still an awful lot of 6 offer 4 tunnelling and the one thing you have got to remember is tunnelling is evil. Always. It's just evil.
(Applause)
Everyone that's not clapping, stop tunnelling because that's what creates a huge amount of this instability. Tunnels don't work very well because the overlay doesn't always reflect the underlying topology. And so when you see convergence performance that's not a cluster graph, that's just noise. It takes 50 seconds, 100 seconds, 200 seconds, for an update to converge to a new stable point. If you're serious about v6, and you are, you have got to get this down to that all the time. You have to make this protocol perform better. And I suspect it's getting rid of the tunnels is part of it. The other thing is you should align v4 and v6 in routing. They should be indistinguishable. You should be routing the same paths. Don't try and go here is my v6 provider here is my v4 provider, they are different. Bad idea. Because that provides this kind of nonsense. Align it, it will work better.
In terms of futures, a little in the way of scaling pressure recollect line speeds and so on are are going to work.
What you need to do is understand your FIB capacity. If you are doing full routes in your FIB and some of you still do you are going to have to watch the next few years because things are growing and growing relentlessly. You also need to look at the v4, v6 proportion ago. V6 is taking up more memory space, it just will, so have to look at the way in which you are splitting it up. Default is your friend. You don't neat to run full routing tables. You can run default. It's quite permitted and make it someone else's problem and that will make your problems go away, someone else will have them.
And that's it. Thank you very much.
(Applause)
AUDIENCE SPEAKER: Jen Linkova, Google. So you just made a presentation in another room about v6 having very high failure rate for some packets not being delivered and I know you have all the data about source IP addresses. Did you try to correlate those prefixes with the prefixes you see high level of the brokers from in IPv6?
GEOFF HUSTON: You know, good question, and what I have noticed also is that Google Cloud charged me by CPU cycles and by megabyte of capacity, and if I had the budget I could compute this stuff. I actually. ‑‑
AUDIENCE SPEAKER: I'll take it as a challenge.
GEOFF HUSTON: It is a big data question. It is a great question but it is a humongous data question and it is a case, yes, we have both datasets putting them together and computing across. If you want to help me ‑‑ oh cool, I just have a Google account.
AUDIENCE SPEAKER: Gergana. The chat monitor for this session, I have a question from an online participant. Aaron for slide 7, can I bring you back to there. The question is: Is that previous slide generally more specific or more specific with the same organisation ASN?
GEOFF HUSTON: Oh. More specifics have a whole variety of reasons. There is hole‑punching where the aggregate has one on gin AS the more specific has another. It happens a lot. There is also traffic engineering, where the aggregate and the more specific have the same origin AS but different paths. There is also senseless routing vandalism, senseless routing vandalism is where the AS of the aggregate and the AS of the more specific are identical and the paths are identical. Yeah, right, as if I needed to know. So, all of those three contribute and I did previous presentations on counting them, this is the aggregate result, lots of specifics. Thank you.
RANDY BUSH: More to the v6 routing mess. A lot of routes that go v6 go half‑way across Asia and back just to get a simple place because of weird business policies and peering agreements, and we don't do anything about those but we screw met cogent than make mockery for them for insisting that their v6 and v4 policies in routing are identical. So we as a culture are not encouraging sane operation, and so that's not going to get cleaned up until, as you say, stop the tunnelling and stop the funny business relationship difference between v4 and v6.
GEOFF HUSTON: That's a very good point and I'll cite two recent examples. One was India. India has a lot of v6 these days. For reasons only known to the Queen and almost no one else, they send all their v6 at the time to England, before sending it out to the world, whereas the v4 works around the Indian ocean. Happy eyeballs doesn't work any more because of the relative delay of this weird asymetric routing, fails, bad idea, they fixed it. Well done. Right now today in New Zealand Vodafone, all the v4 goes to Australia ‑‑ because obviously Australia does it better than New Zealand, that's just an axiom ‑‑ but the v6 goes to America. It's kind of, guys, what are you doing. If you really cared about your customers and cared about making this work, you'd align your routing, because what cogent is doing is right, align your routing, and those upper layer things like happy eyeballs works, if you don't do that don't be surprised if you get crap answers. End of rant.
AUDIENCE SPEAKER: Lawyers Lehmann. I was going to your vandalism there. I'm kind of curious with the numbers because I can cook up a strange situation known as Anycast where it actually makes some kind of sense to have that in place. But I guess the numbers are like this many compared to your, that many, yes. That was what I suspected.
GEOFF HUSTON: I'd need Anna atomic microscope to find your Anycast Cloud. In the large scale of routing vandalism you guys are not big players. Sorry, you need to work harder.
AUDIENCE SPEAKER: Blake Willis. If everyone in this room asked their router vendor for a nobody that says if I have a covering aggregate for this deaggregate, please ignore T do you think we'd get it?
GEOFF HUSTON: No. Because withdrawals make FIB compression a nightmare. We have played with this for 20 years, the researchers have looked at T quite frankly, the cheapest solution is simple minded. Buy more memory from us, sayings the router vendors. I suppose I can't blame them. It's really simple and it works. Clever things with FIB compression, you get into trouble. So, they avoid it.
AUDIENCE SPEAKER: I have an anonymous question. You suggest using default routes. Aren't default routes bad for routing security RPKI filtering? Sorry, it's from Nick, independent.
GEOFF HUSTON: No. It's your routes you're worried about. How you learn other people's routes is what makes your FIBs blow up. Default routing basically says it's someone else's problem. There is nothing wrong with default. The world runs on default. There is numerous presentations by many folks saying they per niche issues default is. Default is actually what makes the Internet work in some places. That's the way it works.
(Applause)
JOB SNIJDERS: Thank you. It is very nice to be here in Iceland with a packed room, and thank you for allowing me to share with you an update on developments in routing security in the last few months.
Before we proceed to give you the actual update, I want to remind you and specifically newcomers, what it is we are doing here.
This Internet thing that we're building together is sort of a shared hallucination. Like marriage it only exists in our minds, yet, we tiresly put money, energy, software development into this shared dream because I get we believe in facilitating communication amongst each other, or making money with this tool. Whatever the purpose is, whatever our motivation is to participate in this Internet experiment, I want you to do so without disruption. And a problem we face with BGP is that inherently, there are very little security checks. This means we need to go out of our way to facilitate, to mitigate these disruption that is may arise from misconfigurations, route leaks, hijacks, malicious activity.
So, in this update, I want to share with you some challenges that we currently face, what software tools are available nowadays, what you should be taking a look at at the deploying your networks, how we're getting rid of still outdated routing publications, and finally, I will share with you some examples of networks that have deployed origin validation.
By far the largest challenge that we face today is the fact that there are misconfigurations in the RPKI. People have created RPKI ROAs that are ‑‑ that either never were or no longer are aligned with their BGP announcements, and this is possible because for many years, there was no feedback loop, misconfigured ROA would not lead to surface disruptions, and without a feedback loop, cannot expect this community to do better so a few hundred people misconfigured their ROAs, this is resulted in a few thousand BGP announcements which are so‑called invalid and from a business perspective we can call these false positives. The software says it is invalid, but from a business perspective, it actually is not an invalid announcement. The ROA is invalid. And like with many things, the computer does exactly what you tell it to do. Not what you want it to do.
And essentially, this is a reminder from me to you, that if you miss configure things, it may hurt. It may not do what you want it to do, and you will have to face the consequences. And we should not be liberal (miss configure) in accepting these misconfigurations, we should be strict. Because the moment we are liberal and forgetting towards these misconfigurations, we, at the same time, jeopardise the security features that origin validation brings us. For more considerations and deliberations on whether we should or should not be liberal in what we accept, I can recommend this draft.
So, what is the path to get rid of these misconfigurations? I think the answer is very simple. Deploy origin validation now. Deploy routing policies on your eBGP edge that say invalid announcements will be rejected. And this works. Because AT&T, on their peering edge deployed invalid as reject policies, many networks very quickly repaired their ROAs, because CloudFlare is pushing origin validation to all their nodes, people have actually incentive to fix their ROAs, and because YYC EX or DE‑CIX or NetNod or NSK‑IX, you name it, are redeploying origin validation and rejecting announcements, we suddenly have potential security benefits and a very good reason to analyse whether our ROAs are still aligned with our actual distinctions.
Many organisations respond very well to a gentle poke when you e‑mail them and say hey, I think you made a mistake, can you take a look. Other organisations have such big to‑do lists, that it's a matter of priorities, and creating situations where the routing is through supply optimal paths or the surface doesn't work in the first place is sometimes the required incentives to repair these ROAs.
Here are a few study resources I recommend you return to later on. They have created excellent tools to allow you to identify which ASNs have probably ROA misconfigurations. I suggest go to these websites, type in your own ASN or your own IP space and see if things are what they should be.
And this deployment effort, analysing the data out there, publishing lists of ASNs that may need to take another look at their ROAs, that is resulted in a 50% reduction of this type of problem in the last six months. So, we're seeing the needle move a lot, which is very cool.
Another tool I want to share with you is PMACCT. This is an Open Source traffic analyser engine, and what it can do for you is it can consume NetFlow IPFIX or sFLow data, it will correlate with BGP data coming from your edge routers, it can aggregate this data and turn it into a database. And this data can be used to analyse how much traffic is flowing from my customers through which peers, how much traffic from customers is going to which transits, which destinations behind which transits, and this tool can help you understand the profitability of your network and can help you understand which networks you should be peering with.
What we have done in PMACCT is we have extended it with origin validation capabilities. This means that the daemon not only takes the flow data's input and BGP feeds input, but also the RPKI database. And the daemon can then correlate all these things together and you can see exactly how much traffic you are sending to RPKI invalid destinations. This feature was recently released in 1.7.3.
What we have done in PMACCT is quite nifty because we have separated out the RPKI invalid announcements into two categories. There is the category of harmless miss configs and there is the category of unrecoverable destinations. And the difference is, if you create a ROA for say a /16 and you announce a /16 and for traffic engineering purposes you also announce a /24, a more specific of that block, and you fail to create a ROA to permit that /24 from existing in a default Freezone, the destination is still reachable, but perhaps not via the correct path. And we call this implicitly repath. While it's not optimal we can still reach that set of IP addresses. There is a different category of RPKI invalid announcements that are unrecoverable where there is no alternative route and if we drop the announcement, there plea is no path towards those IP addresses. And it's the unrecoverable category that requires most of our attention, because that may be where the most hurt can be.
So, we have deployed PMACCT in the network to understand what would be business impact if we dropped RPKI invalid announcements? So I made a graph and it's without context and without axis because I cannot close net with you, but let's share with you what I can share. This represents a week's worth of traffic of our global backbone. The blue is traffic flowing towards IP destinations that are not covered by RPKI ROAs. So‑called unknowns. Cool. Business as usual.
The yellow colour represents traffic flowing towards RPKI valid destinations. So, we can say that roughly 20% of our traffic is going to destinations where the owner of the IP resource took the effort to create a ROA and allow us to use that ROA to facilitate their routing.
Then on top of the orange, we have a sliver of pink. Those are the destinations that can be recovered through alternative paths. So, for these destinations, a valid or unknown less specific exists and theatre will not be problematic. And then at the top of the graph, the green thing, it's roughly 1 pixel and the software won't let me make it smaller, but those are the unrecoverable destinations, and from my business perspective, this is statistic noise. This will not have any impact on our revenue. And this number is being confirmed by AT&T, by NSK‑IX, by cogent, all of us have seen that the unrecoverable IP space apparently doesn't matter for business. Is this IP space that people are not using? Who knows?
Here we see the same thing if we zoom in on a day. So with this we can conclude there is software available to analyse whether dropping invalids will be problematic and a software does not require you to make any changes in your network. You don't need to reconfigure your routers, all of this happens off path. And we are not alone in the conclusion that there is no revenue impact.
So, let's go onto the next topic.
What is the state of software? And I am very happy to say that in 2019, we have a set of excellent choices when its comes to RPKI cash validators, a view years ago we were in a far more vulnerable spot. If we look at software ecosystems in order for them to be two excellent choices we need at least three or four implementations that are competing with each other, and competing as in, you know, friends striving to win a race. This has been resolved, LN labs has put out a beautiful piece of software, route nature, it works well. CloudFlare has been kind enough to Open Source OctoRPKI which is a very fast and useful cache validator. The OpenBSD project is about to open its own validator with another language. And at the bottom you see RIPE NCC's RPKI validator, it has been a beautiful project. Stop it now. It has served its purpose. It was one of the first validators, we needed this validator to understand the certificate authority to help develop the standards in IETF, and it paved the way for the other validators, but nowadays from an operational perspective, it no longer suffices and would I like to ask RIPE NCC please divert the resources you are putting into this validator towards more rewarding goals, for instance, spend the time and development cycles on ensuring perfect integration with NLnet Labs, Krill through the up/down protocol. Invest time in the web interface, in alerting systems, you know, there is lots of work we can do, but I don't think the RIPE NCC validator should go on.
A little bit of news about open BSD's RPKI client. In January we did some fund racing to be able to hire a contractor to write a new implementation in C under the BSD licence, and this hopefully paves the way for the likes of Cisco and Juniper to ship their routers with this software. A nice side effect of this project was that we now also have a second implementation of the Rsync protocol under the BSD licence, so the world truly is better off now that we have almost completed this project.
Another topic. This is about proposal 2018‑06, a proposal to use RPKI data to clean up still misconfigured IRR data. Generally speaking, we apply the origin validation procedure to BGP updates. We look at the prefix, we look at the origin ASN and then a procedure is followed to see if this is valid, invalid or unknown. But we can also apply this procedure to IRR route objects, specifically IRR route objects for which no consent was obtained from the resource holder. There are many databases out there where there are zero checks with the owner of the resource agreed to the publication of that route object. So by using the origin validation procedure on IRR route objects we can do very interesting things. Here is an example of an IRR route object in the RIPE non‑authoritative IRR database that was created without permission from NTT. It covers part of our IP space and we have no way of deleting this route object. There is no process in our community to get rid of this incorrect data.
And if we zoom in a little bit on what is happening. At the top you see it's a /24. Below that you'll see the origin ASN as perpetrated by this route object, and then the source at the bottom is run RIPE non‑authoritative. This is in conflict with an RPKI ROA that we published. In the RPKI ROA is the real source of truth. Because that's what we created. And it is unfortunate at this moment in time that there is no recourse to get rid of objects like this. But I do think there is a path forward if we apply origin validation to IRR objects. So to this effect, there is a formal proposal in the Routing Working Group following the PDP process, recently we published a new version of this proposal. The most significant changes between Version 1 and Version 2 of this proposal is that we introduced a grace period between deleting the route object and observing that there is an RPKI ROA which it is in conflict. We think it's good to send notifications to the owners of the IRR route objects so that they are aware the object will disappear soon. This allows them to take affirmative action such as contact the holder of the resource or put the route object in a more appropriate place.
At the bottom you see a tool I've wrote where you can analyse the impact, if any, on your own ASN. The tool allows you to see which IRR route objects would be deleted and then you can see if that has negative sequences for you or not.
Another effort in this space, which is less community driven, is the development of a new IRRd daemon. I want to introduce you to IRRd version 4. Version 3 was very nice for many years. IRRd has, is one of the most critical pieces of software in NTT's operation. Every night we generate all eBGP filters using this software. But unfortunately, the software from an architectural perspective was not ideal. And the reliability of the software is not where it should be either. We need to restart this daemon very often. There are bugs in it that are hard to fix. Most importantly, this software version 3, is very hard to extend. It was not built‑up from the ground with union tests and regression tests. There were some shortcomings that made innovation very hard.
So, we decided to start from scratch, management signed off on funding this, DashCare was happy to build the software and it is now available on GitHub.
One of the cool features that is coming to IRRd version 4, the innovation part, is that we are going to do origin validation inside IRRd and ensure that whatever it published through other IRR mirrors will not trickle down to the clients that are requesting information to help construct BGP filters. If we do origin validation inside IRRd, two things happen. We have an industry wide mechanism to get rid of of still proxy route registrations, and going forward, it becomes extremely hard to insert fraudulent route objects into this ecosystem. So, it cleans up the past, and it helps us going forward. Those are nice selling points, and may motivate people, more people to create ROAs, because those ROAs will now carry more meaning and have more value.
A quick comparison. Both IRRd with 60,000 lines of code in a myriad of languages. The new thing is just 10,000 lines of Python with excellent end‑to‑end testing. So this is far more manageable than what we had before.
Another thing I would like to highlight, is that some friends of mine wrote a book, day one: Deploying BGP Routing Security. You can either find it on Amazon or for free on the Juniper websites or e‑mail the authors and ask them to send you the PDF. This book is designed for newcomers. Imagine your first day on the job, your boss approaches you, "I heard something about routing security. I think security is very important," lots of hand waving, go do your thing. This book will help you bootstrap from zero to get to a better routing security posture and it guides you step by step in that regard.
Then there is another resource that I love to share with people that are curious about RPKI. LN NetLabs has put together a website, RPKI dot read the docs dot IO and it contains a wealth of information on what RPKI S what it means for your business, what failure modes exist, how it can affect you, what advantages are. If you know nothing about RPKI, this website is a great starting point.
Another really cool tool that was created this very morning, I am not joking, 20 minutes before this presentation started, the final things were typed in. But we now have a testing tool that allows you to quickly see whether your assess provider is doing origin validation or not. It's a quite simple tool. It's still in the early stages but if you go to this website it will show you with a smile owe whether your assess provider is doing origin validation and rejecting invalid announcements, or whether it's not doing this. And of course you can use this information and approach your access provider and tell them hey, what's up? And this is a fun tool to use when travelling around going from hotel to hotel and seeing which Wi‑Fi networks care about your security and which care less.
So take a look at this tool. I think it's very useful to have analysis tools like this.
Now we want to share with you some deployment updates. We're trying to make as much as noise as possible about every new deployment, and this snow ball is now rolling. It start with a select few. CloudFlare and the Calgary Internet Exchange felt let's do more, let's honour RPKI ROAs and let's reject invalids. And then it slowly got out‑of‑hand. AT&T suddenly said well, this is what we are doing too. Wow. The NREN inordinate is dropping invalids. This has significant impact on education in the Nordic region of Europe. Major transit providers towards the African couldn't tent like C‑COM and/or can line have deployed invalid adds reject as policy on their edges as this is beneficial both to the African community and the rest of the world because in both directions, facilitating misconfigurations where hijacks becomes much harder. There is a lot of movement in the IXP space. INEX, AMS‑IX, DE‑CIX, France IX, NetNod have either already deployed origin validation or are half‑way through the process. MS X IX, this Monday, went public with their announcement that they are honouring RPKI ROAs and rejecting invalids. XS 4 all announced this week that they too are rejecting invalids and if they can do it, you can do it. Even the RIPE meeting network is rejecting invalids. Have any of you noticed problems? Exactly. And since the deployment pace is picking up so rapidly, I feel that it is time we can get rid of this tie. I use this tie as a gimmick to associate visual imagery with the concept of origin validation and make people think about what it is we are doing. Because if I dress up funny you may pay more attention to what I'm saying. At this point, it's no longer needed. Now the ball is rolling. This is incredible that our community has managed to find direction and agree on the direction and no longer question should we do this, but change the question to how do we do it this? What's the timeline? What do I need? How do I include this in my operations? So ‑‑ I'm really happy I can get rid of this.
We are changing. The industry very rarely sees change at this scale at this pace with such obvious benefits. Change is coming and for once, it's very enjoyable.
With this, I want to conclude my presentation, and open up the microphone. If you don't feel comfortable going to the microphone, feel free to e‑mail me or approach me in the hallways, I am more than happy to help my competitors, we are network engineers without borders. Let's start.
AUDIENCE SPEAKER: I have several questions from online participants throughout your presentation. Nick is asking, the previous speaker sees no issue with with default routes and RPKI based route origin validation, do you agree with him or with Bangkok's analysis on this? And he wants to explain where he sees the problem with with default route. If you use default route packet, it will always leave your network even if RPKI based origin validation would filter the forensics announcement and result in no packet towards the destination.
JOB SNIJDERS: I hope I am understanding the remark correctly. But in case you rely on a default route towards another provider, approach that provider and tell them, I am giving you money, in return can you do origin validation in your network. If you purely rely on default routes, origin validation doesn't make sense because there is very little to validate. But if you rely on default routes, just ask your vendor, do it on my behalf.
AUDIENCE SPEAKER: All right. Thanks. I am moving on to a question from Cynthia Maya, also independent. What is your opinion on alternative databases such as Alt DB, RADB etc. Since alt DB has no validation and RADB only has payment at validation? Great presentation and you along with Sacha have gone good work with IRRd 4.
JOB SNIJDERS: Thank you for the compliment. With unvalidated IRR databases such as NTTCOM, which we are ourselves add trait. Our RADB or any of the others, cannot get rid of them overnight. What we can do is encourage them to deploy the new IRRd software that has the origin validation capabilities built in and that means that the useful data remains in such databases, but there is still outdated data or the data that is dangerous will disappear as more and more people create ROAs. And both LTD and RADB have indicated this they have very strong interests to deploy IRRd version 4, so I am confident these IRR databases that possess problems will be far less problematic in the next six to twelve months.
AUDIENCE SPEAKER: Thank you. Moving onto the next question from Robert Shek. You mentioned open BSD RPKI client being in private beta currently. Could you estimate when it will be publicly available, even if it's still beta? Just a rough time road map for RPKI client.
JOB SNIJDERS: The road map is a little bit complicated. The software is finished but it depends on open SSL. Open BSD however does not want to use open SSL in any way, shape or form. This was forked in the Lieber SSL, but that does not have CMS functions and CMS is a mechanism that is critical to how RPKI certificates can be validated and turned into more useful data the VRPs. So the moment we fix CMS functions if LIBOR SSL we can go public with the RPKI client. The timeline, it's very hard, I depend on volunteers that are slaving away after working hours, so, maybe a few weeks, maybe a few months. We're going as fast as we can.
AUDIENCE SPEAKER: Okay. Thank you. Mike is asking, do ROAs now have the facility to specify AS paths now? So a /18 for example is valid from AS1 but a /24 from that /18 is only valid for AS1 via AS2?
JOB SNIJDERS: No.
AUDIENCE SPEAKER: Thank you.
JOB SNIJDERS: Let's leave the long question for the end. You first.
AUDIENCE SPEAKER: Thank you, because I truly have a question but not for you. I have ‑‑ Jen Linkova. Part of the problem we are trying to encourage people to do something they are not really in the mood for doing for many reasons, they might be busy or... and as far as I know positive incentives work much better, at least with dogs and horses, so I assume is the same is true for network engineers. So, maybe ‑‑ and we have people here who registered to the RIPE meeting and probably specify their AS numbers. Maybe RIPE could provide some discounts for networks for registration fee if they are doing the right thing, and see it as an experiment and see how much it would help so we can have data driven discussions.
JOB SNIJDERS: So the discount we already got it. There is lots of Open Source software out there that helps us do this, and we're not paying for that. That is the real discount. I agree with you when you try to motivate people to do anything, there is carrots and whips and carrots work way better, and with origin validation, it's probably one of the most selfish things a network operator can do. You don't require other people. You can deploy origin validation in your network and you will immediately enjoy the benefits of having done so. You will face less misconfigurations, you'll face less ‑‑ you will face less negative side effects from other people's misconfigurations, or hijacks. So, I think with origin validation, the incentive is already very much aligned with how we humans are motivated or become motivated to do anything.
CHAIR: In the interest of time can we limit one question to a minute and the mic lines are cut.
AUDIENCE SPEAKER: Brian Dixon, GoDaddy. That's all really great work. It's great to hear about IRRd 4. Would I like to see the eventually you will end goal of using IRRd 4 plus validated RPKI data including future AS cone information also added to RPKI and IRR and do BGP 38 to get it deployed everywhere and there reason not to.
JOB SNIJDERS: The end goal with IRR is it it just becomes part of your provisioning pipeline. The name IRRd is nowadays misnomer because in reality it's the thing that does IRR plus RPKI plus some other useful things. But since IRRd is a fantastic well recognised brand name, we are sticking with that name. But the end goal is just it becomes an integral part of provisions, the focus will be less and less on IRR and more and more on higher quality data sources.
AUDIENCE SPEAKER: CloudFlare. Thanks for everything you are doing to push routing security. That's great. I have one question. AT&T deployed string validation, as far as I know it's tier 1, do you think that old tier 1 because of the central plays on the Internet routing should deploy strict validation today?
JOB SNIJDERS: I think every network, including so‑called Tier1s, should deploy and I have good news, virtually everyone of those transit free networks has put RPKI on their road map.
AUDIENCE SPEAKER: Blake, long time Open BSD user. If folks would like to see RPKI client development go faster, you just need to donate to the project and make a comment.
JOB SNIJDERS: Thank you.
AUDIENCE SPEAKER: Brian Trammell, Google. Speaking in a personal capacity. As someone very interested in sort of like protocol transitions in large coordinated networks. Aside from the tie which was clearly the most important factor and success here, what do you think caused the rock to start rolling down the hill just now? What do you think the biggest thing that cause that had to happen?
JOB SNIJDERS: There is a specific individual in the Netherlands that one day popped into the IRC channel of the Dutch community and he said hey, listen up, I deployed origin validation with strict policies in this commercial network. And I was like, you what? He was like, yeah, I just turned it on. I was like, what? You are very confident about this. I was like, yeah. And with that, I went to one of his competitors and I said, look, your competitor is doing this, are you sure you want to lag behind? And they are like no, no, no, let's do this. And then I went to slightly larger competitor and made them jealous. I said, look, they have a press release and they have security features that you don't have, and they were dismayed. So, very quickly, they deployed origin validation, and we went from bigger to bigger to bigger to bigger network, where at some point the likes of CloudFlare and AT&T have put it on their road maps or even already deployed. It kind of got out‑of‑hand but it start with one individual that just deployed it and told the world I deployed it and that was all it needed.
AUDIENCE SPEAKER: Rudiger Volk. Unfortunately I have three stages on response. First one is I am happy to see people move on this very actively even if I remember quite clearly three years ago they were telling me, well, okay, it's never going to happen with us, we can't do it. You remember? And yes, and we have no interest in putting the data into the RPKI, the ROAs. Of course your Dutch friend would not have had any reasonable success if people had not started to actually populate the RPKI.
On that ‑‑ so, again, I'm happy to see this rolling. Actually, looking at it as someone who has been looking deeper and for a long time at this, I sometimes ‑‑ I sometimes and in some places see that things are taken over enthusiastic and things that actually also matter get rolled over. So for one thing I would point out that just doing the drop the invalids is something that, where I prefer the approach that was presented yesterday from our friends at Google, that well, okay, mark and report first and then drop I think is the way I'm proceeding, and I would suggest that regularly should be the way of doing, and actually when you are dropping, it still would be a good idea to tell your neighbours, your customers what you are dropping.
For the uptake and for dealing with bad information out there in the ROAs, quite clearly a little bit more work on figuring out what feedback to provide to the resource owners about what is in the RPKI I think would make a lot of sense and help, and as we are expecting a situation where more actors are dealing with the information, the question whether the intentions of the resource holders are actually truly represented in this formal certificate system becomes more interesting because more parties in the way may have misinterpreted fat fingered and so on what people really intended.
For the first part of my comments ‑‑
JOB SNIJDERS: This was the introduction to your comment?
RUDIGER VOLK: No. I'm going to the third and final part.
JOB SNIJDERS: And I say this in the most loving way. You are a brilliant mind.
RUDIGER VOLK: That's somewhat poisoned. I once in a while make fun of people where I say well, okay, they really want to show up how brilliant they are, what complex stuff they can deal with and fail in the end. But okay.
For the third part, what I would like to talk about is the processes and techniques for generating filters where you were talking about RPSL data, we have, by now, enhanced our RPSL database clients software so that we can do the ROA validation there and the tools are there for generating the filters, taking into account selected IRRs, the ROAs positively from the RPKI and filtering out the garbage that is invalid, I quite certainly would see good reasons for not messing around with databases and essentially leave the filtering to the point where you are generating your filters instead of removing stuff that you do not own and where you do not have insight how and why and with what intentions they were injected, generating reports and pointing out to owners of objects that they are ‑‑ that they have something dubious there quite certainly is called for.
JOB SNIJDERS: I think this is a beautiful thing with the Internet. You have your network. I have my network and what you highlight is a philosophical difference between who should take what steps, who owns what part of the inter‑domain pipeline. And that's okay. We may not agree on how we do things. Fortunately, you work for a different company than I do and cannot stop what I will be doing. So, do with that what you want. Make reports. That's fine. There are multiple approaches here. It's very hard to say which one will be best one or the fastest one. But yeah, Internet engineering is a little bit of a wild west.
AUDIENCE SPEAKER: Rudiger and Job what you are discuss something right and important but we also have other questions, please bring this to the mailing list and continue it there.
AUDIENCE SPEAKER: Super short comment from sandy Murphy who wants to give a shout out to Z DNS who took over support of the BBNs RPS D R since 2017. That was a brief comment.
JOB SNIJDERS: Thank you.
I think this is it.
(Applause)
CHAIR: Next next speaker. For the interest of time if I may ask to squeeze one minute out of your time slot.
ANDREI ROBACHEVSKY: Hi everyone. I would like to talk in this presentation about whether we need more visibility in what's happening in the routing system. So, the question is, if the Internet routing system transparent and of course the first answer is yes. To a great extent the routing system is transparent. Proof to that when something bad happens, we usually get quite comprehensive reports and investigations of what happened and who was involved.
But making sense of this data, because BGP data is very noisy, it is quite a heavy lift. It is available to a few and only on sort of certain occasions, right. It's very hard to continuously look at this and monitor what's happening in the Internet. That's a really heavy lift.
So do we need more transparency? Do we need more visibility in the anomalies that happen in the internet? So one case in point is this bit canal case. Do you guys remember last year this case that sort of was discussed in NANOG? Basically what happened is that someone brought up on the NANOG mailing list a case of serial abuser, hijacker, spammer, and it took some conversation before some operators and IXPs to consider action and actually stopped routing this particular entity. But, there was no real tools where you can really point out, so, Ronald actually provide some data grabbed from different sources proving his point.
So, coming from that case, I think the ability to see and analyse those anomalies that are happening in the Internet continuously. With many eyes will more clearly expose systemic abuse or gross negligence allow the remedy anomalies quicker and better inform research discussions related to routing security with stable references. .
So, we have tools. It's not like we have no visibility. So, great tools like starting from stat and BGP statistics, commercially solutions like these. They are great. But good to use them when you know where you are looking. If you are looking in a specific network or a specific incident. But global routing system based I personally no only one which is BGPStream dotcom. That's a great service, but it's not really transparent. We don't know what heuristics this tool is using, so there is also a limited opportunity for improvement and producing false positives. What is probably more important is that this tool will be is end of life and will probably be decommissioned early next year.
So, what we have now is, we have raw BGP, right, and while here is a BGP dump and we have this data and we have great collectors like RIS, like route views, like PCH data and some others, right. And what we are get, we see all this data but it's extremely noisy. Wouldn't it be great to have another layer on top of that, provide also as a sort of a service to the community which will expose more signal from this noise i.e. unusual events.
So this is what I call the transparency layer. So if you can use this raw data collection, and apply certain heuristic and filter out the signal from this noise and provide this layer as a service to the community, would it be useful this I think yes, because based on this layer you can enable much lighter lift for other players, right. You can build monitoring tools much easier. You can enable network troubleshooting much better. You can enable research even, right, because research will not need to do the sort of first step, first very heavy step but can use this data. And as a result, we'll have better understanding on what's happening in the routing system, but also will shed light, right. It's like lighting streets, reducing some crime. So people will be more careful I think when they do some stuff on the Internet.
So, this service, what kind of answers the service ‑‑ what kind of question the service could answer were there any unusual events related to a specific prefix? Were there any events presenting a specific network? What was the network that caused those incidents? And so on and so forth, that's something that we can discuss.
What are the requirements if we decide to build the service? First of all, it should be open, right. I think it should be provided like RIS, like route use, like PCH, it should be provided as a free service to the community. It should be transparent. I think one of the problems is that yes, there is no sort of ‑‑ you need to apply certain heuristic. You need to figure out how to sort of separate the legitimate BGP change from some anomaly, right, maybe a conconfiguration mistake. So, you'llth would be great if the heuristic methodology opened a subject modification by the community. Imagine sort of this heuristic as an Open Source project where a community can contribute and improve.
And of course community driven. Right. So impartial responsive from the community needs and also regarding those improvements.
So, where from here?
Well, this talk is really to get some of your feedback whether you consider this as something that we need as a community, whether it's something useful. And also, if, for those who think that's useful, solicit some sort of contribution in terms of if you feel that you can contribute in terms of knowledge or otherwise, it would be good to get those people together and thrash out the proposal better and then maybe set up work on the proof of concept that we can ‑‑ well, that's an aggressive timeline, but present at the next RIPE meeting.
So, how about that?
CHAIR: Any questions? We have four minutes.
GEOFF HUSTON: Look, I'm actually working in this space, and it's relatively easy to process BGP updates. It's a slight challenge to actually apply a long lived memory to see if you have ever seen the AS path elements in the prefix sometime in the past. But that's still quite doable. The real challenge is even when you apply that, you are still left with wondering what is going on with this update. And in some ways those heuristics is really the biggest challenge of the lot. I am quite willing to put out tools you know in an open space on GitHub, that's easy. What I'm missing I suppose is also some of those essential insights, the length of time it was announced, the geolocation information that is might actually signal some kind of oddity. The origination point, the AS path point. What sort of heuristics would make sense to ab initio say that's odd. Because the ones that really work right now are the ones where the folk who are looking talk about their own prefixes, ignore everything except this origin AS etc. When you are looking at the big feed, you don't get that liftup. You are trying to guess in the dark, and in some ways I certainly would support what you are saying, and if we can get some assistance in understanding the heuristics of what makes an announcement or a withdrawal interesting, would actually be helpful. Thanks.
AUDIENCE SPEAKER: Randy Bush: I underline what Geoff just said, but it's worse, what's I consider interesting or an anomaly may not be one to you. So, BGP MON was a good go at it and a whole bunch of people didn't think it met their needs and a bunch of people did. The problem is we haven't defined ‑‑ we don't have a clear vision of what's normal, what's an anomaly.
ANDREI ROBACHEVSKY: I agree with you. But I'm not saying this sort of tool or this should ‑‑ well it can say with a certain level of confidence maybe, right. This is an anomaly, and your anomaly is not my anomaly, so it can have a union presumably. The thing is can we sort of filter out the ROA BGP announcements and say hey, well those announcements are clearly okay, and those are I don't know, maybe they are unusual, maybe they are interesting, maybe we need analysis to look into it, maybe we we need statistical analysis to look at this and see if it's really an abuse for instance. But just slightly improving signal versus noise.
AUDIENCE SPEAKER: Chris Marco. I think your point to Randy about your problem is not my problem, or your anomaly is not my no, ma'am low is probably a good portion of the problem here. I think an open collection infrastructure would be great. There are some things you can do with RIPE BGP live I think. There are some things you can do with other tooling. Being able to apply my own set of heuristics is what I'm interested in. I don't really care so much about BGPStream because they almost never get my answer correct. So, I would like ‑‑ it's just me ‑‑ I would like to be able to look at the data and apply long term set of heuristics that I build to, that are built for my networks purposes and I think that's the goal you are trying to get to here, right. So I think that would be great to see. It would be nice if other folks in the community that had BGP data off their networks could contribute in a central fashion. So...
ANDREI ROBACHEVSKY: Well thanks. And I think once we start thinking about new ideas come up. This is a very rough idea. It doesn't have a lot of substance, as you probably noticed. But, if we start looking at this there might be two facets. One is the service that you can use sort of long term an I think the whole sort of heuristic of this analgies can be as an Open Source tool that you can use in your own environmenten patently and you can modify this to really sort of nail down your anomalies, so anomalies you are interested in.
CHAIR: Rudiger, really sorry, but really running out of time. Can you bring your question onto the mailing list. We still have other topics to discuss. Thank you.
ANDREI ROBACHEVSKY: Thanks.
(Applause)
So next one is brief update on RIS live services, what is happening there.
CHRISTOPHER AMIN: I'm Chris from the NCC. I want to talk about RIS live, which is currently being run as a trial service by the NCC. We're supporting it definitely until September time and we're going to make a decision based on feedback, whether to keep it. So I would just like to get the opinion of this Working Group on if this tool is useful. I'll just do a brief description of the tool.
So it's about RIS data. The NCC routing information service which most of you will know about already. We're ‑‑ we have around 230 full table peers, this is just kind of an opportunity to plug the fact that we would like more full table peers especially in Bucharest and Montevideo and they are the ones which add the most value to the system.
So, it's always been possible since RIS started, which was the beginning of this century, sorry if that makes anyone here feel old ‑‑ it's always been possible to get the data from F D P dumps, RIPEstat offers where you can get this. There was a BGP hackathon in 2015 in Amsterdam, and I thought okay, we have this infrastructure for streaming BGP messages and then we do all sorts of things and it ends up in FTP sites, we just implemented RIPEstat streaming, I'm knock up a BGP streaming service, or ‑‑ which I did, and it was running in a technology called TMUX, which is the terminal multiplexer where it stayed for four years, it's technically running there. And every now and then my then colleagues, Colin at the NCC would poke me and say hey, it's died again, can you restart your TMUX session, people were using it on that basis. I thought, we should do something with this because people found it useful, but it wasn't in a state which was really sort of production ready.
So we came up with RIS live. The principle is that you can connect to a WebSocket or a simple HTTP connection, you can can you be subscribe to any of the router collectors, you can filter and you can get pretty much like less than one second from when the peer sends a message, you can get it in your client in your browser in your command line tool.
So, this is the demo. So if you go to RIS live dot right.net it's an introduction into using the tool, which is primarily a WebSocket API. You can see the service side filtering so the most important ones are the prefix, you can put any prefix and enable more specific or less specific matching so you can really just get those update messages which are relevant to you and to your network. And the path. So you can put any ASN, single ASN or in this case, this, this is showing every message which has 3356 somewhere in the path. If you hover over this little I guy there it will explain there is a simple syntax for specifying that the ASN should appear at the beginning or the end of the path and you can also have ASNs together so you can see particular pairs of ASes.
And just kind of plug this, so, as I say, this is a trial service. I'd like to get feedback in the room, but we also have a survey and there is a link will come at the end as well. And the more responses we have in the survey, the greater the chance we will keep the service and also the greater the chance that your feedback will get processed.
Okay. So, you can play with the demo. You can see the filtering in action. You can write scripts and programmes which use this. There is manual at the moment which kind of gives you a simple start. There are some code examples in Python and JavaScript. You can even get the entire fire hose using kernel if you are that kind of person. Please fill in the survey, and please let me know if you like the service. Will you use it? And how will you use it?
As I said in Q3 we are going to make the decision, so we just want to know is this the right direction? Is this something that the NCC should be supporting and providing for the community? So I'm hoping that people have questions.
CHAIR: We have a few comments online and then time for one question, please go ahead.
AUDIENCE SPEAKER: Gerard is saying concerning the previous discussion that he agrees with Randy and he also likes views in the various Cloud providers and other backbones that have these invisible events that inpacket global networks and he is also ‑‑ for this presentation, he is asking everybody to show support for RIS live, that the service is great.
AUDIENCE SPEAKER: Hello, Stavros from Amsterdam Internet Exchange and actually a comment, please support it, because actually one of the use cases that we have in AMS‑IX is that we deployed Artemis which is a tool for detecting BGP hijacking which is a very crucial tool for us, and is heavily based on RIS and is really really fast. So, we keep working with the developers to make that tool even better and better for the community as well, but we without this we are going to be blind. So, that's an open comment for the community. But I will also fill the survey to help you guys continue the work.
CHRISTOPHER AMIN: Thanks.
CHAIR: So then the next and last topic, a brief discussion on using of AS‑SETs.
SPEAKER: We have a great challenge before us right now, because we're going to try and go against the ancient old truth of food first and ethics later. So let's see if we can do the ethics before we go the to the food at least for a little while.
So, this work comes out of a presentation I held at a previous RIPE meeting where I showed how value such as human rights and innovation were subverted in the Internet architecture and after that several people came to me and asked how could we then design four specific values and this is an experiment in that and I hope you will go and engage in this experiment with me.
So so I am a Ph.D. candidate and researcher at the University of Amsterdam and I try to think how can we design this thing that we did not expect that it would do what it does not to retro fit it for society? Because, we can influence society with our technology and architecture, but it would be a bit naive to think that society then not has questions to us. So when the Internet governance regime comes upon society and other governance regimes it needs to interface and react. So if you do not interface and react and we had a lot of discussions about that this week, you can either work with other forces, or expect to be regulated or other people to push their values on you and then you have less control. I'm not the first one who thought about this. Actually, Dave Clarke, and the others already thought about this in the famous tussle paper. It described the different stakeholders of the internet milieu have different interests and we need to accommodate for those different values, or else the infrastructure might break.
In the famous tussle paper, they thought of classic stakeholders such as network operators, equipment vendors, protocol developers, but now actually we have a lot more stakeholders in the Internet that we are touching, so how do we accommodate to their values?
Right now, routing decisions are based on a mixture of efficiency, trust and economics, but efficiency trust and economics between network operators, vendors etc., and not necessarily societal stakeholders. So how do we take their values into account and what values would we use? So, try to come up with some values, also based on Dave Clarke's new book. Of course, values need to be relevant because who wants to inscribe irrelevant values, right. But they need to be relevant for both Internet working and for the stakeholders. Furthermore, these values should be applicable so we can operationalise them, and ideally we use existing framework so we're not trying to reinvent the wheel and ideally they would be transnational he will, just like the network S so with these criteria I have been trying to think of some value systems that could work. And then easily, something that many of you are actually already very knowledgeable of and probably many of you are compliant with, is the general data protection regulation, the EU law on data protection and privacy that unifies data regulation across the EU and the European Economic Area and that is applicable for inhabitants of the EU and EU citizens.
Another one are the united guiding principles on business and human rights. You probably know human rights from the Universal Declaration of Human Rights written in 1947, that then got ratified through a range of treaties and then also got made applicable to non‑state actors such as companies through the human guiding principles. And a lot of companies are already subscribing to these, and two recent examples are SIDN, the Dutch ccTLD and Blacknight undergoing human rights impact assessment based on these. So these are understood value systems that have been implemented in our sector. So how could we make them explicit so people with make routing decisions based on them. So to do that I created two AS‑SETs in the RIPE databases, namely AS GDPR and ASUNGP of which you could become a member and then people could do preferential routing or exclusive routing on ASes that have become member of these sets.
So, should this be done? Are these the right values? Will you use this? Or are there better ways to approach this problem?
Looking forward to hearing from you. Let me know.
CHAIR: Any questions?
(Applause)
AUDIENCE SPEAKER: Rudiger Volk: I think this goes somewhere into a wrong place. Is in your model a company that might avoid registering their AS for GDPR that way admitting that they are violating the law?
SPEAKER: No
RUDIGER VOLK: Okay. Then ‑‑
SPEAKER: A voluntary expression of value
RUDIGER VOLK: Kind of, so, the AS‑SET is actually talking about layer‑free forewarning, nothing more, nothing less. As we are forewarning packets, we actually do not have any concepts in the processing that are related to the stuff that you are interested in.
SPEAKER: Thus far.
RUDIGER VOLK: Thus far, but kind of, am I supposed to ask of my customers that they tell me what interesting personal data they are shipping in a certain packet and how much extra information will that take and would I actually invest into the mechanisms to deal with that? No.
SPEAKER: So you are asking should we consider operating ethically if that goes against our business interest? And then my argument would be, yes, we should. Or at least we should consider questions from society that ask for that. Because for a long time we have been thinking we are running the infrastructure that hides in the woodwork of society and we have been enabling this great thing that goes for the right thing but now we are often on the front page of newspapers, if we want it or not. So we need to find ways to accommodate for those questions, because if not, other people will come and make rules for us. So, this is a relatively easy and lightweight way to express it. Why not?
RUDIGER VOLK: Again, we are talking about describing something that is layer‑free networking. And in layer‑free networking, you have actually no clue about the application, the content and the end user context, and you can go out and suggest that people who are running stuff where the concepts that actually are significant for you are part of the business and of the operations. And if you were asking, say, about statements, what are platforms that are handling user data, I would say yes, that's fine, well, okay, but kind of the routing infrastructure where just the naked packets are forwarded, it doesn't help and kind of quite obviously, marking the stuff in ways so that I know as an end user I'm avoiding sending my stuff over links that the five eyes are looking at. That's not going to work. Because, we know, we know if you are using ‑‑ if you are actually forced to open your links that way, you probably will have a gag order about it.
SPEAKER: I think what is most important to think that we are not even understanding that the user layer or the application layer is not the only place where politics takes place. Technology is not neutral and it's not so that infrastructure has no values. And this is a way to try to accommodate for that and see how it can work.
AUDIENCE SPEAKER: I have a comment from Sacha lucks, speaking for himself in a somewhat similar vain of what Rudiger was saying, he also doesn't think it's an appropriate use of the RIPE database. He says that anyone is free to set up their own database server and serve whatever AS‑SETs they desire. And he thinks that the RIPE NCC should not be seen to make judgments on human rights or anything else not related to resources and routing. So that's just a comment. Thanks.
CHAIR: Thank you. So last question please.
AUDIENCE SPEAKER: Hello. Just an answer to Rudiger's comment would be that, yes, we're in the forwarding packet business, but how we forward packets and where we send them is something that already takes into account some non‑technical criteria, money being the most obvious. So, if we are doing this, why shouldn't we do some other things like the one you described.
Now, the issue is: Is the RIPE database the good place? I'm not sure. Can it even be done with the RIPE database? I'm not very sure either. But what you are trying to say is, it's worse exploring how we should do it. So, yes we should do, we should at least think about doing it, and there should be a discussion of how. But this is something on the long term.
SPEAKER: Thanks so much. Let's take it to the mailing list.
CHAIR: Right. Thank you everyone. So this concludes the Routing Working Group meeting. Lunch awaits you.
One announcement from the Programme Committee. They are still looking for lightning talks for Friday. If you have something to share with the community, please consider submitting the topic. Thank you.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
