Routing Working Group
RIPE 80
14 May 2020
11 a.m. (CEST)
JOB SNIJDERS: It is one second past eleven in Berlin. However I am in Amsterdam and you are anywhere on this planet ranging from California to Honolulu maybe.
This is going to be the RIPE 80 Routing Working Group session. Welcome. If you are not looking for the Routing Working Group session, you have been routed to the wrong meeting. However, if this is the content you're looking for, join us.
Today, we're going to go through a few work items.
We have the opening, which which had in the last few seconds.
Our agenda. If there are people that wish to make changes to the agenda, now would be the final moment to signal this to us. As part of our opening, we will have a poll which runs through Zoom, I hope the interface is intuitive for everybody.
Our agenda is very packed. We have a very short time slot compared to previous Routing Working Group meetings, so that means that some of our presentations have been pre‑recorded to ensure that we don't overrun. This also means, depending on how we manoeuvre through the technicality of the Zooming thing, that there may not be time for Q&A after some or all of the presentations.
So this means that our fallback, as always, is the Routing Working Group mailing list.
I'm going to hand it off to the Paul.
PAUL HOOGSTEDER: Our agenda is as follows: We are going to have a talk from Nick Hilliard about the database work task force. Then we'll have an update on policy proposal 2019‑08. Johannes Moos is going to tell us about new features in PeeringDB and then we'll have an update from Ben Cox about RPKI deployment.
I assume you all have read the minutes from the last meeting, RIPE 79. You should see the poll on screen. Do you approve of of these minutes?
The poll has stopped right now. Then we'll continue with Nick Hilliard. Hello, Nick.
NICK HILLIARD: Hi everybody. Okay. So, I want to give an update from the RIPE database task force.
One of the issues we came across while investigating the RIPE database was the IRR. It's a very technically complicated part and there is not ‑‑ a huge amount of complication associated with it. There is a lot of bits of the routing registry used, for example, lots of us build prefix, prefix sets, prefix lists from routes and AS‑SETs and aut‑nums and things like that. But plenty of our objects are really not used at all.
And particularly ‑‑ in particular, huge quantity of the peering policy in the RPSL component of the Internet reaching routing registry sun usable. It can not be used, and this is something that I gave a presentation on about ten years ago actually, coincidentally in Berlin, and I don't think things have improved since then.
So it's been about 20 something years, probably about 25 years since RPSL was designed and I think it's fairly clear at this stage that it hasn't really met the original intentions, which was to say to provide a database which would allow organisations to announce and define their exterior BGP peering relationships with each other.
And I think at this stage we actually need to have a think about what we want to do with RPSL and also the Internet routing registry. As I said, there are parts of it that are very useful, and there are parts of it that are not.
So this is a call to start off with the ‑‑ to kick off a discussion on the mailing list and to try and figure out what we should do and where we should go from here. That's pretty much all I have to say. I think the next stage of the discussion is to bring it up on the mailing list and get some community input.
JOB SNIJDERS: This was a little bit shorter than I expected, which means we have time for perhaps one or two questions. If you have a question for Nick about RPSL in the context of the RIPE NCC IRR database, please input it in whatever wizardry we are using right now.
PAUL HOOGSTEDER: Q&A. Oh, there is one question.
JOB SNIJDERS: I don't know if you can see this, Nick, so let me read the question to you:
"The stats on objects used are fascinating. Even ROA hard to believe route objects need it."
From George Michaelson.
NICK HILLIARD: Yes, possibly. I think that's an issue that we need to resolve in future, because certainly route objects are used very widely at the moment, and it may be at some stage in the future we can move away from even route objects. But for the moment, they are used so widely in production that I think it would be inadvisable to touch them right now.
Okay, so the next question is from Kostas Zorbadelos: "Is there a proposal to reach the onions parts?"
There is no proposal yet. This is ‑‑ this is a call for discussion at this point.
JOB SNIJDERS: All right. Yes, speccing from my own experience as a network operator, do I recognise there are object types that are used everyday and object types that are not used and perhaps can lead to complications, and I think it's very worthwhile to kick off a discussion to explore in the wider community what is it that we're using, what is it that we're not using, what can we do to improve? I look forward to this.
Nick, thank you for checking this off and thank you for joining us in this Routing Working Group session.
Next up, we have Max Stucchi and Melchior Aelmans, who recorded a video.
MELCHIOR AELMANS: Good morning.
MASSIMILLIANO STUCCHI: Good morning.
MELCHIOR AELMANS: In the next few minutes we would like to give an update on the RIPE 2019‑08 proposal. We first discussed this proposal at RIPE 79 in Rotterdam, and the idea was to create ROAs with AS0 for unallocated and unassigned space. There is three authors, myself, Max and Martin. The proposal has seen a few iterations and we would like to give a small update on that.
So at first, the proposal stated that RIPE should create a zero ROAs ‑‑ sorry, ROAs with a zero for unallocated an unassigned space thanks for all the feedback on the proposal. We changed that then in the second version to create a separate tool, TAL. And then again interesting discussions, good feedback. And so the third version of the current proposal is that we ask RIPE to create a SLURM file instead of a new TAL.
And, of course, we're still very interested in feedback and to learn if the proposal suits the needs and wishes of the community
MASSIMILLIANO STUCCHI: So what does the current proposal say? Well, it says ‑‑ well, what we are asking that to do is we ask the RIPE NCC not to create a series of ROAs. Not to create a new TAL, a new TAL, but we are now proposing to, instead, create a SLURM file containing the exceptions for every part of address space that that is unallocated and unassigned. What does this mean? This means that the SLURM file which is an exception that you load into a validator, into a relying party, can be an optional part of your validation problem. So an operator could decide at this point to use it or not.
This is why ‑‑ this is because the files could get big. There is a proof of concept script that we worked on that generates the SLURM file for all the unallocated and unassigned address space across all the regions and it creates especially for IPv6 address space a list, a long list of entries.
But also, it means that the SLURM file can be distributed via HTTPS. So, any CDN could be used. Distribution could be much quicker than it could happen with RIR sync or, well now all the validators should be moving to ‑‑ well, correct me ‑‑ IRDP. But this also means, and finally the last point here, is that we don't have any fake ROAs. So, one of the biggest feedbacks we got was that the RIPE NCC would create what some people have considered fake ROAs for address space, and so we were not going that route any more.
So this means that things can be more lightweight and so here, we are kind of ‑‑ that was right ‑‑ let's go to the next steps ‑‑ we are looking at more discussion, first of all, and maybe adoption.
What we are waiting for now is the Impact Analysis for the latest version of the proposal, which is version 3. The RIPE NCC has been working on it, so it should come quite soon, but we're looking forward to comments on that.
And then maybe asking vendors for ‑‑ people who work on the validators, if they are willing to implement this feature or not. And so from that, we could gather feedback all together and make sure that we follow the voice of the whole community.
Apart from this, we are open to questions and we're open to discussion here. So, feel free to ‑‑ I would say, step up to the microphone, but we're not going to have a physical microphone this time but we will both be online to address any questions or any concerns you might have about the proposal.
And from all of us, thank you for listening. And now open to you ‑‑ back to you.
JOB SNIJDERS: Thank you. We have a few questions ‑‑ actually we start with an observation from George Michaelson.
"SLURM is unsigned. DMAN, IETF participants, suggest the need for a signed CERT for this kind of publication."
And I guess that that hooks into the third question, so I'm going to do them out of order.
Randy Bush from IIJ and Arrcus requests: "How do I carotigraphically validate the SLURM file?"
Max, would you like to answer in this session? You may have to unmute yourself if you wish to answer.
MASSIMILLIANO STUCCHI: Sorry, everyone we weren't prepared for this, to be honest. We were told there would be no time for questions here. So, sorry, Job, which one should we answer?
JOB SNIJDERS: Let's go with Randy Bush's, how do I cryptographically validate the SLURM file?
MASSIMILLIANO STUCCHI: You know it better than I do. So far, there is no mechanism yet, but we could actually think about working on that as well parallel on, at the IETF. So that's something we can do.
JOB SNIJDERS: Then a final question from Kurt Kaiser:
"Is the SLURM file then similar to handling martians?"
MASSIMILLIANO STUCCHI: Sort of in this case, it contains them as well, so, I can point you to the tool, the proof of concept that we work on, that we wrote, and there you can see how it produces the SLURM file. And then any poll request is gladly accepted. So, there we can promote a little bit of work to have more ideas in the proof of concept.
JOB SNIJDERS: Thank you, Mass, and apologies for putting you on the spot without proper preparation in this session.
MASSIMILLIANO STUCCHI: No problem. Thank you very much.
JOB SNIJDERS: This proposal follows RIPE's policy development procedure, the PDP process, sorry, and this means that input is solicited primarily through the mailing list. So if you are interested in contributing feedback on this policy proposal, the best way to do so is to subscribe to the Routing Working Group mailing list and e‑mailing what is on your mind.
With that, we will go to our next agenda item. This is a recorded presentation. RIPE NCC, if you'd be so kind...
JOHANNES MOOS: Hi. My name is Johanne Moos. I'm a network engineer at DE‑CIX. And in this short talk I'm going to tell you about a new PeeringDB option to enhance routing security. That is called 'never be a route servers'.
What is the motivation behind this feature? We want to improve the detection of route leaks, and this is here in the context of IXPs, so we're talking about IXP route servers and IXP participants that the benefit from this feature.
What can we do to detect the route leaks. First up, you notice that in prefix limits on your BGP sessions, that is generally a good idea. However, they protect only against bigger or even full table leaks which means that, yeah, smaller or partial leaks, they often go unnoticed. So if you have a look at this example AS path here. Let's say AS 65501 is classified as a tier 1. The right‑most ASN is a downstream of that tier 1 and the left most ASN is our BGP neighbour.
So if you look at this AS path you have to ask ourselves the question if the AS most left in tier 1, in this case it's AS 64513 is really an upstream of the tier 1. You already know the answer. This is really unlikely.
So we talked about prefix limits before but what with conventional filtering methods like RPKI and IRRDB. Would they have to detect the leak.
Let's have a look, if the originating AS from the prefix of the leak does not change then the prefix is still RPKI valid and, as we know, RPKI is not the ultimate source of trust here so we can't solely rely on it.
Which means we need to take some IRRDB filtering into account so let's if ahead and do that, and what we see is, if the laking ASN has included its upstream in this case a tier 1 in its AS‑SET, then the prefix is resolvable from the AS‑SET from the leaking ASN and from our AS‑SETs that further include this AS‑SET. For example, this could be the AS‑SET of my direct peer from which I did my filters on.
So, the originating ASN, it might also be a member of my peer AS‑SET and, in this case, the prefixes would also get accepted, of course, and we observed a similar case in API at the DE‑CIX Frankfurt route servers.
So more intelligence in this announcement or not is needed and what we want to achieve is, we want to spot networks that should not show up in the BGP AS path. What can be done to achieve that?
Well, let's go ahead, compile a list and filter based on that. That would be nice community effort, right?
The problem is, this list would, of course, need to be actively maintained all the time, but this is not the biggest issue. More importantly, we would ‑‑ or we might not reach consensus in case of certain ASNs, if they belong on the list or not.
So we thought the smartest solution is networks, they should know their peering relations best themselves. So just let them indicate on their own if they buy transit from other ASNs, other let them ensure their prefixes do not get processed by IXP route servers if they do not want that. And we thought the logical place to put this kind of information is PeeringDB.
As you can see here, in the supported protocol section of the network object, you can now enable the route server SLAAC and as of last Saturday, 42 networks, they have already checked the box including Cogent, Vodafone, Telia, NTT, Deutsche Telekom, PCCW and Liberty Global, and I would encourage you if you are a tier 1, go ahead and check the box.
Here, you can find some more information on the topic. Rene Hernandez has written a nice article about it and I also provided a link to the original GitHub request that I opened.
And that was my talk on the route servers option. Thank you for listening.
JOB SNIJDERS: I believe we have Johanne here in the Zoom meeting and we have time for one question if somebody has a question about this PeeringDB feature.
Rudiger Volk asks:
"Yes, it is useful to be able to publish constraints for the use of autonomous systems. Using such information, e.g. for suppressing routes, requires the authorisation that can be verified. As an example, ASPA."
I guess this was not a question.
Then we have a real question from Simon Lockhart:
"Would this not be better placed in an attribute or an object in the RIPE dB?"
Johannes, if you have a short answer to that, now is a good time.
JOHANNES MOOS: Well, you could also put it there of course, I guess, this is what came to our mind first, just put it in PeeringDB. We thought it would be a quick option to get it done, and of course, because you know database related things, this might take much longer to implement or reach consensus in this case. It might be a valid alternative of course, but this is what we have today and we can already filter on that, and yeah... I hope this answers your question.
JOB SNIJDERS: Thank you.
We will now proceed to the next agenda item, which is Ben Cox with an update on RPKI deployment in the default‑free zone. This is also recorded, so, past version of Ben, take it away.
BEN COX: Hello everyone, I am Ben Cox, and, as you might have guessed already, the talk is an RPKI‑based talk.
The context, the last two years I have been giving a talk similar to the one you are about to hear but longer and more detailed. So, if you are interested in this talk in general, and want more detail, you can check out some of the textual versions of those talks or the recordings from the event themselves.
So this graph. This graph is generated by NIS, an American standards body, and shows how ROA validation compares with what is in the PKI chains versus what is in the BGPDFZ from their point of view. Here, you can see there are about 0.8 percent of invalid prefixes.
This offers a slightly better version of this graph, that instead looks at this by address space, showing the invalid space is actually quite low compared to the prefix count. And data later shown by Job Snijders shows that the traffic going to these invalids are incredibly low. It's likely safe to discard them.
Even better though this graphs gets much better when you look at what RIPE NCC region. Almost 50% of all RIPE prefixes are ROA valid. That's amazing. It's likely due to the ease of signing in the RIPE portal that has made this entirely possible.
That's all well and good. How is the adoption of ROA validation required. To be ROA validating or be behind an ROA validating network entirely.
To test this, I'll start with a few assumptions. One, that people probably have a lot of default routes in their network and those are quite hard to get rid of. Two, that there are a lot people signing but not validating, probably due to the difficulty of getting that to work or vendors not supporting, there are a whole reasons why you might not do this.
To do this test, we'll utilise a programme I've been calling the ICMP 9000. Under the prefixes, two ROA invalids from RIPE and ARIN and one control valid prefix that's used for scanning. We can ping the whole Internet. And collect those responses into a bucket. And we can use that bucket to feed the other ICMP 9000s that use the invalid addresses allowing us to say which networks can respond and thus we can infer that they have a valid return route to us, from then we can infer they do not sit behind a network that is validating their ROAs.
After a short while, I end up staring at spreadsheets for a few hours and, lo and behold, I can give you graphs for decision makers.
Now is a better time than ever to be deploying ROA validation. There are now 2,598 validating ASNs out there with the bulk of them being in America, Russia, India, Ukraine, Germany, Netherlands, south Africa, Italy, Sweden and Poland.
The bulk of the US ones are behind super carriers like Charter and AT&T, who are assuming you are a single home to them and are not on any peering lance are getting ROA validation for free.
And if you are interested in detailed met forensics you can scan the QR code here.
This is a nice step‑up from August last year, where only 600 or so were validating. Assuming the rate keeps going, I expect we will be there by August 2021.
Coming back to this graph. This is the RIPE address space covered by RPKI certificates graph showing Anna playing 47%.
When you account in for the actual ROA validating IP space and not just the address space that is covered by those ROAs, the picture looks a lot for depressing. There is any take away from this mini talk is that signing is only the first step and there is a whole load of us need to be deploying ROA validation on to our own networks.
Because it seems that only 0.6% of prefixes are actually behind ROA validating networks.
Since this is a pre‑recording, I need to give my thanks to Job Snijders for letting me borrow his infrastructure and NTT Communications for sourcing the prefixes used in these text.
If you have any questions please e‑mail them here, and if you missed anything in this talk, albeit I was speaking relatively quick because I only have five minutes, you can probably watch a rerecording of this now on my Twitter. Thank you.
JOB SNIJDERS: Now, I'm going to loop Ben in. Does anybody have questions for Ben about this presentation? I see Randy Bush has asked:
"That count validating AS includes those getting it for free from upstreams. What is the real number of validating AS numbers, Ben?"
Hold on, Ben, I need to relay this.
Ben ‑‑ Ben suspects that the real number is around 1,000.
Second question from Gordon Gidofalvy:
"Have you taken a look at stop versus transit ASNs validating /non‑validating ratios?"
I guess the question is, do you see more stop networks doing origin validation or more transit networks doing validation?
Ben suspects that it's mostly stop networks that are the common ROA deployment.
Ben, thank you very much. I am going to stop sharing the screen and we're switching back.
Thank you all. I think we are right on time within our allocated time. I hope that at the next RIPE 81, whatever physical or virtual or distributed meeting, we'll have more time to approach technical topics in more depth.
I see one final question POP up in the chat.
"Is there no any other business?"
And I think if RIPE NCC doesn't cut us off, we ‑‑
PAUL HOOGSTEDER: We do have time, yeah?
JOB SNIJDERS: Is there any other business?
Gert Döring says: "The meeting plan says you have 15 more minutes. This is true, but initially when we planned this session, we were given a 30‑minute slot which was later extended to 45 minutes, but by that time, the programme was finished and the recordings were made. So, yes, we can hang around, but...
PAUL HOOGSTEDER: I don't see any new questions in the Q&A.
JOB SNIJDERS: We have a 15‑minute leak. All right. I am calling it. Everybody gets to have a longer coffee break.
Thank you all for attending this session, and I hope to see you either online or in person at some later point. Take care everybody.
PAUL HOOGSTEDER: Thanks.
(Coffee break)
