These are unedited transcripts and may contain errors.
Routing Working Group
27 September 2012
2 p.m.
CHAIR: Hello. Welcome, I hope you all had a good lunch. This is the Routing Working Group. The other Working Group is meeting in the room next door, just in case you got confused along the way.
We'd like to get started. We are a little bit tight on time with the agenda and as it turns out, as soon as we are done, the RIPE NCC general meeting, we reconvening in this same room so we cannot really run over a lot.
So let's go through the items. Some initial items, I'd like to thank you the RIPE NCC and Anne and Susanna for being scribe and Jabber monitors chatting and of course the stenographer who enables everyone to follow this thing better than otherwise.
Regarding the minutes, both Rob and I would like to apologise for submitting them to the list so late. So instead of asking for approval right now we'll give everyone two more weeks in the mailing list. If you have any comments please add them and then we'll make them final at the end of the those two weeks.
So again sorry about the delay.
It was not just ?? I just want to mention, it was not at all the fault of the RIPE NCC. They produced the minutes in August. We just dropped the balance. So it's the Chairs' fault.
Next up, a quick mention of the route flap damping document. Rob sent to to the mailing list on July 26, I haven't seen anything else, any comments, anything, so we are going to send it to the list again so that everyone can have a quick reference where to find it and we are going to at the same time, open our last call on that. So, if you have any comments, this will be your chance to do anything about it before we close it.
So, this is the list of talks we have here. Five talks. One of them is a tutorial by Nick Hilliard and one, we have had one report so far for the AOB. I don't want to spend any more time with this, let's go right ahead. Ivan please.
IVAN PEPEINJAK: A while ago the whole idea was the idea of Gunter Van de Velde, thank you. Gunter brought three of us together saying, hey guys, we know that everyone is doing toll BGP security and everyone is doing some prefix filters around doing a different thing so can we sit down and write something that would document what most people are doing.
And that resulted in a draft that's now in the third version, 02, and the idea was to describe the best practices, so what are people doing out there, and there are a lot of information out there in different bits and pieces, so, collect all that, make one document out of that, and you don't know this because you know what you're doing, but there are people out there who don't. Small ISPs and the enterprises, so the idea was give them something that will help them survive in the global Internet without doing too many mistakes. And hopefully, eventually having something more or less consistent that everyone would more or less use. And of course, we tried to be version agnostic so there is an IPv4 and IPv6 part of it.
So of course there are some basics in there like you do control plane protection, you do some inbound ACLs, you do BGP session protection on public segments, and whether it's DTL or MD5 or TCPAO, we just describe all of them, it's your choice what your vendor supports, what you think you need.
The biggest part at that time prefix filters. So the obvious ones that should never appear and most of them are listed in RFC 5735 and some of them are in the IPv6 registry, lick link local shouldn't escape and things like that. And then we have a whole section on should you use IANA for a location, which we call loose filtering or should you use IR or IRR and build the strict filters and both are described, so it's your option, but if you want to go down one or the other route, you can. There is RPKI mentioned as one source of possible address validation. And there is the mention of two specific prefixes and that thing is purely descriptive. So, we are saying we think that prefixes that are too specific should be filtered. But it's actually your choice what you think is too specific and by the way, this is what most people think is too specific. And there is a long section on IXP sub net and I have two slides on that one because it's a total mess, as you know.
So the first thing is don't accept more specifics for IXP LAN because if you accept that, then you will just send the traffic the wrong way and not only that, also you're EBGP sessions will crash. Because of BGP ?? TL ?? so don't ever accept that. This one is obvious. The other one is not so obvious.
If someone up here, and this was a long discussion on the RIPE mailing list, you may remember this, it's actually having low MTU and he is sending ICMP packet too big from the IXP address and someone down here is doing URPF check, he might actually drop that packet unless the IXP LAN is globally visible. So, you should ?? it's should, it should be ?? to could be must but you should propagate the IXP sub net to your downstream so that they will not filter ICMP packets. And of course if this guy down here implements strict filters and your sourcing IXP LAN from your AS, the strict filter will just drop that because it's not your prefix. So actually IXP should advertise this prefix from their AS so that IRR filters will pass. Okay.
So, there is a long section explaining why this is a good idea. I hope people will get it.
And then of course with this filter definitions being in place, we describe the case of full?routing networks where you have filters with peers, upstreams, and customers and the leaf networks and filters are always described inbound and out bound for loose and strict case. So, hopefully all the combinations are covered.
And then there is BGP flap damping actually saying don't do it. Maximum prefixes per neighbour with a caveat that expect that the neighbour will grow so keep that dynamic. AS path filters including the customer phasing filters where you should stop too long pre?pending. Next hop filters. This is a good one. And the community scrubbing, don't accept just anything anyone is sending you, make some sensible filters.
BGP next hop filters. This is fun. Yet again, on IXP, one of your neighbours could send you updates pointing to some other neighbours. Oh thank you. So, this means that actually someone is redirecting your traffic sending it some other way. This is bad. But this thing is worse. Someone could announce a route and would you accept it and it would point to an non assistant next hop. And because it's in the same sub net you would accept it, next hop it valid and then of course Arp would fail you would black hole the traffic. So, there is a long description of these two problems and the collusion proposed and this is more or less the only thing we can do is on the inbound route map, change the next hop to your neighbour's IP address on an IXP. If he is sending you routes, well maybe he wants you to use those routes, so make sure he is the next hop.
And here, for those of you who you are really interested in history, here's a long list of changes between version 0.2 and 0.1. So, those of you that submitted input, thank you, please cheque that your input was considered and incorporated. So these are the major changes, control plane protection. Clarification for IXP LAN prefix. New section on next hop filtering. And there is even more history between the previous two versions, so I'll skip this.
So, what you have to do is you have to read this, review it and comment. Please, do so. We probably missed one or two things. For example, the section on BGP next adjustments got in there like two days before the last draft was published, thanks to Gert, so we need your input. We need you to read this, figure out whether we have missed anything, figure out whether you disagree with anything, send the comments. Well, you should really do this on IETF Op?sec mailing list and, well, we think it's time to slowly move this draft which is now an individual submission within the IETF Op?sec and Gunter, tell us what needs to be done to get that going.
GUNTER VAN DE VELDE: So, one of the ?? Gunter Van de Velde, first time at RIPE, by the way.
So what we're trying to achieve actually is an element of making sure that what is happening within IETF makes sense, and one of those things, as such, is that the operational element makes sense also. So, for this draft, as such, it is a very complex thing to actually describe, and what I'm trying to achieve over here with this particular draft is to really have the operational, you know, trustworthiness as such, with IETF, because right now we don't have that. So, we have like lots of, you know, technical folks but we don't have the operational implication here, so...
IVAN PEPEINJAK: So that's all we had to say, and if there are any questions, please throw them over.
CHAIR: Okay, thank you Ivan and the others.
AUDIENCE SPEAKER: Hi, Leslie Carr, I am wondering if you have talked to any of the Internet Exchanges about their opinions on any given AS renouncing their space?
IVAN PEPEINJAK: Gert, do you want to answer that?
GERT DÖRING: I didn't think it actually came from me, I think it came from Jerome. But anyway the recommendation is if you do URPF filtering, then you might want to have that prefix in your routing tables, and in that case, the best way to get it there is to have the IXP announcement. The text is much longer, it says that you should care about not accepting more specifics of IXP prefixes and all the usual caveats. So, what Ivan presented was just a very short one slide thing of a two?page explanation of caveats. So, yeah... I would welcome you to actually read the full text and if you think this is dangerous stuff what we are doing there and shouldn't be there, please let us know by all means. This is the whole reason why Ivan got volunteered there to solicit feedback.
AUDIENCE SPEAKER: Hi, Nick Hilliard from INEX. I am going to answer for INEX, but a lot of other IXPs do the same sort of thing. We announce our address ranges from our own ASN and this is carried by several transit providers, it appears in the DFC. We do understand that at some stage we will probably be the subject of a denial of services attack in which case we have a sort of a plan that we could, in theory, just drop the announcement, we would send it to you are upstreams with tagged at no export. What we would say and this isn't a really BGP issue, this is a general IXP issue, is that if you are an IXP member, don't export the IXP refix into your IGP. This is bad stuff, particularly if you have multiple connections into the IXP because if you have a split in the IXP structure, you will cause yourself immense damage and cause endless trouble and basically lose every bit of connectivity you have into the IXP. Don't do that. If you are doing, it please export it into your BGP tables, your internal BGP mesh, with next hop?self from the loop?back of the router that you are connecting into the IXP mesh.
IVAN PEPEINJAK: Thank you. Perfect.
AUDIENCE SPEAKER: Mike Hughes. I used to one an IXP but I am getting better now. I can completely agree with what Nick says, I think I probably had a drunken chat many years ago with Gert about this which may be has helped with some of this, but certainly I can speak from when I used to run the tech operation at LINX. We announced our own IXP prefix ourselves from our own AS. Inconsistent origin AS is bad, it breaks routine loop detection for one thing. The other thing that you would also get is people deaggregating, this is even worse, people deaggregating the IXP prefix so they were advertising more specifics of the IXP prefix so if people had not protected themselves at their borders, that would cause serious problems, so we really, A, discouraged people from advertising the IXP prefix and more specifics, and if we did find people advertising it, we mercilessly tracked them, hunted them down and hounded them to stop doing it even if it was their own internal losses, because their IXPs didn't advertise their own prefix. They said their own internal policy is to redistribute IXP prefixes into our and advertise it to tower customers with inconsistent origin. We were like that's a bad policy and stupid and you shouldn't do it and please don't to it with our prefix F you want to do it with other people's IXP prefixes and they don't mind you hurting their IXP, that's fair fault, but we don't want you hurting our IXP so stop it. And we did have quite a few arguments with people about that.
NICK HILLIARD: This is a reply to Mike. We are in the lucky position that our IXP prefixes actual is a /25 and this is a net ?? even if we move up to a /24, you know, the truth is that a lot of networks will simply not accept anything more than a /24 so even if somebody does re announce, it and people do the amazing stupid things with IXP, even if he do reannounce a /24 it probably won't brake it just due to the structure we have. Thanks very much for bringing it up in the draft. It's important.
AUDIENCE SPEAKER: Max. I completely agree with all previous three speakers, and what I mention in our website explicitly written, but we announce our ?? with no expert community. We ask everybody to support this, no expert attribute, because sometimes people just ignore it and what you mention in your draft is a bit other way, so I think it's more communication needed between you and IXP communities. Thank you.
AUDIENCE SPEAKER: Eric, Cisco. The Op?sec Working Group there is another draft which for IPv6 traffic states on the the infrastructure links to IXP to be the case use only link lock?out, so you are forcing everyone to use a loop back, so any comments on this? It's related vaguely to this.
IVAN PEPEINJAK: Let's take this off line, okay. You have to enlighten me first.
AUDIENCE SPEAKER: Speaking as a co?author of the route flap damping document we are trying to have a look at. Have you read that because your documents in the presentation says flap damping, don't, we had a very good presentation at the last meeting based on work that he has done with others about how flap damping isn't entirely unuseful by just using a few appropriate parameters.
IVAN PEPEINJAK: Okay... so if I understood correctly, the agenda, there will be a RIPE document very soon that will document ?? which means that at that moment, we will be more than happy to throw that thing out and reference the RIPE document.
CHAIR: Thanks. We have to move on. So thank you very much and to the Working Group, if you care about the level of plane on the routing tables and the Internet, please have a look and comment.
Next up Emile Aben from the RIPE NCC.
EMILE ABEN: Good afternoon. My name is Emile from the RIPE NCC and I want to talk a little bit about IPv6 /48 filtering. The data plane effects it have as we see it in RIPE Atlas.
So, if I remember correctly, it was this Working Group where there was, a while ago, a heated discussion about this subject, it's basically IPv4 up to /24 is considered routable. IPv6 /32, /48, something in between, you do whatever type of filtering or you don't do filtering at all. So out of that, came RIPE 532 and that had some nice text in it. And I have highlighted the part that I found particularly interesting, which is "The operator community will ultimately decide what degree of Dublin division is sportable but the majority of since accept prefixes up to a length of /48 within PA space." Then this summer there was this discussion on the IPv6 ops list, and that was about a /48 out of PA space out of a /32. That was announced without the covering prefix, and basically two camps, people say you shouldn't do that, people say it's your network, your rules.
So, in RIPE 532 said, a majority of IXPs, so I am thinking what majority, is it 51%, or what is this majority? Are these /48s filtered, especially the /48s out of IPv6 PA space. And how much damage does it do if you announce a /48 RFPA space?
So what I would like to do is measure it on the data plane with RIPE Atlas so we have over 600 IPv6 enabled RIPE Atlas probes, and as, you know, data plane is not a control plane, there is default routes and there is what have you not that could influence all kinds ?? in a makes these things very different. So, what I did was, I traced Route?6. Every 15 minutes for two hours from all of the IPv6 enabled RIPE Atlas probes to a /32 PA ?? a target in a /32 PA block, a /48 PI block and what I call a naked /48 out of PA space. So there is no covering prefix, or at least not one that is significant.
So, what I had hoped to see there is failures to reach these destinations due to route filtering, but what you also are going to see here is other failures like temporary failures, I mean, you are using the death plane so ICMP data filtering and what have you not. The key difference between the baseline versus that naked ?? the two examples I have in /48 out of PA space that don't have a covering prefix.
I wrote this up in an earlier article on RIPE Labs, but there were a couple of issues with how I did it there. I used an UDP traceroute in three cases, I CP in other cases and I didn't do the experiment at ?? right at the same time so people said it could be temporary failures here and there, so I just thought, I'll repeat this and use ICMP traceroute for all of the expert and do it for two hours at exactly the same time frame. And it's also nice if you do experiments that you can repeat them and get the same results, right.
So, I only considered probes that were used in all four of these trout experiments to the four destinations that I have, one is the tube of the baseline and I have two where I have a /48 out of PA space. And what I did from that first, I filtered out trivial nonuseful traceroute results. So things that have no responding hops, less than three hops which catches most broken gateways and tunnels and traceroutes that have all hops with the same IP address. And this is what you get.
So, this trivially unuseful is ?? I was kind of surprised it's a little bit different for all of my targets, so, first target /32 out of PA space was IPv6.google.com. I mean, if you do v6 and cannot reach that, then you get ?? I guess this is the first thing that people will try, so...
A /48 out of PI space which is NS.ripe.net which I also expect to be widely visible. Then there were a /48 out of PA space cloud player and that was a little bit special because there is somebody who is announcing a /12 in IPv6, it's ?? and doing an IPv6 DarkNet experiment there, and I don't see him in the room, but he usually is. So, that /12 could have an effect here in that it's sort of routes you around the networks that do this filtering. And I have a /48 out of PA space, which is the website of a German broadcaster that went v6, but didn't have a covering prefix.
So, unusable: Round 50, between 50 and 60. Targets reached: All roughly the same. And I mean the failure rates here, that's where it sort of gets interesting. So, this is an experiment, so, things go wrong. There is one poor guy who can not reach Google. Two poor guys who can not reach NS.ripe.net. So that's my baseline. That's sort of where the noise is in this experiment.
9 and 8 who couldn't reach these two. So that's the probes, the probe hosts, that consistently couldn't reach this destination during these two hours.
So, there is a little bit of a difference. And out of this, if you look at a network unreachables there, you also see a different, 0.2, versus roughly 1%.
AUDIENCE SPEAKER: Emile, for the /48s out of PA space, have they exactly matching route objects or Route?6 objects register?
EMILE ABEN: That sub easy to find out, but I didn't look at that.
AUDIENCE SPEAKER: That could make a difference.
EMILE ABEN: Yes. Other interesting here maybe is that 9 and 8, only five of these overlap. So...
And if you then look at all the traceroutes and try to resolve these IP addresses, you see there into ASs, which I mean is not a hundred percent, you have to take care of IXPs and all kinds of fun stuff, if you look at all the ASs that were seen in all of these experiments, you see a similar thing.
1%, roughly 2%. So, if you don't believe my analysis, this is all on ?? if you have a RIPE Atlas login, you can just see the user defined measurements that you used for this, these are public measurements so they are available from this URL. So, what that kind of, what you see there on the data plane is in the order of 1% difference between the /48 out of PA and the baseline. So, this is like a rough order type thing. Don't ?? it's not exactly 1% or ?? but it's very low. So, it might even be noise. I don't know.
The other thing there is that we don't exactly know how a representative RIPE Atlas for the Internet at large of course, what we currently cover is 7 percent of the IPv6 ASs. And my guess is if there is a bias here, then we are biased towards the network geeks. So, we have more probes in networks that make conscious decision about filtering or not in networks, then don't read these documents.
So, a question slide ?? I can just say questions.
CHAIR: Okay. So we'll just ask. Any questions?
By the way, I just checked the two Route?6 objects and they exist. One of the cloud flair one is in the IEDB and the RTL one is in the RIPE database.
EMILE ABEN: So a follow?up experiment could be find one that doesn't have the object and ??
CHAIR: See if there is a difference. Martin.
AUDIENCE SPEAKER: Martin Levy, Hurricane Electric. Good work, but I have a question: Do we really care about PI versus PA in the big scheme of things on the backbone? I have to be very careful how I say this, not as an operators with customers but purely on the the backbone. We don't filter differently. This is a very RIPE?ish type issue, and globaley, the ability to see this noise that you're talking about, the difference between the PI and the PA, I just don't see this as a long?term thing that anybody is going to, you know, really operate their network differently. And I'm talking about at the backbone level and global connectivity, not at provider to customer which is different.
EMILE ABEN: I guess that's an open question to the room, not to me, really, I think.
AUDIENCE SPEAKER: Okay. Then the open question is does anybody filter PI versus PA space any differently? By the ways in a v4 question as well as a v6 question.
AUDIENCE SPEAKER: I filter rigidly and I don't make a distinction. If you don't have exactly matching route object N you are out. V4 and v6 ??
GERT DÖRING: Not speaking as myself, but in the discussion we had ?? some people spoke up and said that from ranges were 32s have been allocated they don't accept 48s, and from PI blocks they accept the 48s. So there are a few that sort of disturb only cling to strong aggregation in 32 space. Personally I think if it's documented, it makes sense. If it's not documented, don't accept it because then it's a leak.
CHAIR: Okay. No more questions? Thank you very much Emile.
Next up Martin, Martin Winter, there was a BoF on Monday if could you attend that, on routing, Open Source routing software so, we will get a summary and elaborate a bit on a follow?up proposal I guess.
MARTIN WINTER: We had the BoF on Monday evening. Just to give you a quick summary there on some of the statistics. We had about 50 people attending and when we ask around who is using what, that's basically the result we got. We had about 12 Quagga users in the room, 12 users on boarder and 2 open BGP folks. Kind of love to see here, basically there are four open sort routing projects, I will have a quick summary here, but I am wondering in this room, anyone here using open BGPD? Because I don't see that many. There are quite a few. Anyone here using XORP? Okay, we found one person. I would love to talk to you afterwards.
Okay. So, just a quick overview I want to make it very short. We have like Andre here if you want.
ONDREJ FILIP: I think it was introduced many times here at the RIPE Meeting so routing demon currently really very popular by Internet Exchange points but not just among those guys. It has been here for a very long time but became popular much later. Now it's used by the, as I said the biggest exchange points or maul exchange points as well, used by NetFlix for example for the open appliances, but yeah, it's an alternative to a demon, it has a strange configuration to the others. On the other hand, it is very efficient and fast for many things.
MARTIN WINTER: The other one was Quagga. As I say which we had presented ?? actually I work for Open Source routing but we basically work on Quagga, so it's basically a community project there. Quagga has sometimes a bit more folk who is less on route server but more on full routing and actually quite a few people use that as an alternative as a cheap router either on PC or on high end with dedicated now the push is with Open Source for routing below.
The other project is an open BGP F you are using it, would I love to get some of the maintainer sometimes to join in here and talk a bit about their goals.
And then we have XORP which I talked a bit to the maintainers, they basically tried to do a really nice clean source code. I haven't seen much use in the community, that's why I would love to talk to what people who are using it.
And they have like kind of nice, if you log into C++ and object the desize and want to look at nice source code there might be something to look at.
To give you a quick update, that's what we had the discussion at the BoF B it's basically what we're working on. On Quagga, we, as Open Source routing remainly work about on getting some I BGP fixs in there, basically ISIS, which we have a lot of work going on trying to get it in a usable shape, and I think with some patches that came in about two days back, it's probably now compiling and working for most cases for IPv4, no IPv6 yet. OSPF we are working on some fixes for large scales. BGP fixes came in. Then specific to Open Source routing we are working in data internally, a lot of cleaning up optimising it. API for things like OpenFlow to add it into. And we recently ran Fuzzer tests, if you go to basically Open Source routing site you can see there like Fuzzer testing and RFC compliance for the EURO?IX branch which some of you may be using, this is the branch like written by Chris Hall and he did a lot of òptimisation to make it fast to be usable again as a route server.
ONDREJ FILIP: We are working on many other features. And I think it is important to mention that many of those features were requested on the previous BoF in Ljubljana, so that it shows how important such events for us are. So, we are working currently on BGP at bath feature, it is in a better stage, probably we will be finishing the looking glass, it's going to be multipath on looking gas, not just for boarder but for many other implementations and we hope it's going to offer something more than the current implementation.
And one thing that was really very largely requested in Ljubljana and also here was ISIS, so we are working on this, but before we need to IPv6 and IPv4 integration in our boarder is two separate demons for those two protocol families so we would like to unite them much and we have slightly thinking, so this is something for more future, for more distant future about MPLS, so those are things we are currently working on.
MARTIN WINTER: So, another discussion at the BoF was also a discussion about starting a new like Working Group. This is actually we'll have more discussion tomorrow at the Closing Plenary, bring that go up there, I want to bring it up here mainly if ?? some of you have feedback I would be very interested in it but mostly discussion about how much useful or useful will probably be more tomorrow.
So the idea was like why do we need one? We wanted something where some of the Open Source community, the ones that are relevant to you, has basically changed to have discussions going on, update on interesting new developments, and get feedback back, what's interesting, what departments they are and other things, so basically make an active discussion, and we had now two because of mainly covering Quagga and boarder, together at this RIPE and the previous RIPE and we really appreciate the feedback and I think it was like very useful there. And we want your ideas like open it up, not just on the routing point of view, but all the other port checks there and we think about like maybe some network management port checks there, which may be popular here in the community /TPHAOEUG nag a, which might be interesting for you to see here, feedback, but those are maybe other two like /TK?P, like may be and open Working Group like any of these Open Source spot?checks relevant to this community like having roaming for there, bring it up, talk about discussions there, about features, problems and everything.
Just to bring that one up, I will present it tomorrow again, we have a proposed charter there this time, the idea is to have a discussion tomorrow and then probably have further discussions on how useful that is, pros and cons from it on mailing lists that are going on. So, on the RIPE mailing list there will be stuff coming up, so, again, just as a small hint there, it's coming up but that's basically the charter is a bit long and we would ask to make a longer version of the charter, not the very short version.
And that's basically it. If you want to look at the complete slides, they are online on the RIPE presentation website. The feedback on Working Group, if you want to tell me something before we have long discussions tomorrow, both me and Andre, we have very open to hear any feedback, suggestions, ideas there.
ONDREJ FILIP: I have to apologise I will not be at the meeting tomorrow, so just, you can throw stuff at him and I will be home. But thank you very much for attention.
CHAIR: Thank you. Any comments on the last aspect of it.
AUDIENCE SPEAKER: Jan Zorz, member of a Programme Committee in RIPE. Can you please send the outcome and the follow?up of this BoF also to the Programme Committee back because we were discussing today that we have no idea what happened there, and I have no idea how to follow?up with their request for the Working Group. This is other people that have to decide, right?
CHAIR: Yes, just so that everyone is at one level here. The creation or not of a Working Group at RIPE is decided by the Plenary. And the RIPE Chair suggests or not, depending on the feedback from everyone, basically. I think probably this time was the first time we walked about forming a Working Group, so, perhaps the most logical thing would be to have one more BoF, but run it as if it were almost like a Working Group so people can have a real sense of what we're talking about, and then call for a decision on that at the next RIPE meeting in Dublin.
ONDREJ FILIP: I think the idea to create a Working Group arose at the BoF so it's a very young idea, let's say so, we didn't want to talk about it on Friday immediately. We would like to warn awe little bit in advance and as soon as we were able to do so. So there will be space for tomorrow. So I don't think we really need to talk about it today, because that's a topic for tomorrow, but anyway, if you have any comments, they are welcome.
MARTIN WINTER: I want to make it clear again that tomorrow, as we are kind of trying to figure out exactly how to do our best. The plan is not to make a decision on the Working Group tomorrow. The plan is only to bring it up as a suggestion and the decision will probably be more at the next RIPE Meeting.
ONDREJ FILIP: We are not rushing. It will take sometime. So...
CHAIR: One step at a time.
ONDREJ FILIP: Anyway, we'll try to send you as much as we have from the BoFs to the as as Programme Committee.
CHAIR: If you are not here tomorrow. But you are going to be at the dinner?
ONDREJ FILIP: . No. I am trying tonight but I'll try to participate remotely as much as, but Martin will be there.
AUDIENCE SPEAKER: Hi, this is Yannis Nikolopoulos from OTE. I for one support the idea of the Working Group and I also have a question. About ISIS supporting IPv6, when do we see that coming best ?? well mainly in Quagga, but also for boarder?
MARTIN WINTER: On Quagga side, it's basically we now ?? if you know the history, I mean ISIS in Quagga was there for a long time but it was broken, it didn't work at all. So we got basically a lot of rewrite fixes from Google merged into it with the last release, the 21, but still with many many bugs in there. And I think we got about 20 bug fixes into the gate like in the last few days, and I need to go through again like the test results and see how bad it is, but I think for IPv4 it's more or less usable soon, I say I don't know exactly the result. I need to look at it again, how good they are. IPv6 is still broken and I know it doesn't come up yet, but our goal is to look at that after the v4 kind of works reasonable. So that would be the next step there.
AUDIENCE SPEAKER: Right. Well for, at least for the Quagga, if you want people to sess, we would be happy to help.
MARTIN WINTER: ISIS has this really challenging part of it. First of all, yes, we appreciate anyone who wants to test and stuff, especially if you have equipment or simulation stuff to test it. I think so far, before the last release, I told people don't even bother because I know ?? I knew so many crashes and problems in it that I figured lest just if I can the ones I know first and the next release which may be coming out soon, that I basically will be able to list what's broken still and hope people start picking up and testing. One of the challenges is there aren't really good public domain like testing similar lateers out there so that makes it a little bit difficult sometimes to discuss similar late the box in the public. B if you are networks who want to test, it I think now, if you want to take something from GIT, give it a look at, it if you feel some issues, feel free to ping me privatley and we can talk about it.
ONDREJ FILIP: With boarder, we plan to make a Version 2.0, which is going to be the IPv4 /IPv6 integration by, approximately by the end of the year. So, after that, we will fix all the previous protocols that became broken I'm afraid, and then we will probably work on ISIS so I expect it in the first quarter of the next year, well. It might be sooner, but you know... it's just a development, you never know.
CHAIR: Thank you both. Please, if you care about the existence of the Working Group, keep track of what's going on, be present at the Closing Plenary tomorrow, have an opinion, participate.
(Applause)
CHAIR: Next up, Nick Hilliard.
NICK HILLIARD: Hello everyone. Nick Hilliard from INEX again. This time I want to talk about remotely triggered black holes. This isn't specifically an IXP issue. It's a generic SIP Internet service provider thing and anyone who runs a default free BGP core really needs to consider taking a look at this sort of thing for their network.
So, this is a generic ISP to sort of customer structure. So on the one side you have got all your transits. You have got your ISP core in the middle and you have got your custody ministers. But of course bad things happen and sometimes you get, you know, a pile of bad traffic coming down into your network and it's usually directed at one or more customers. And, you know, we all know what it's all B it's all about extortion and you know sort of playing political games and all that sort of thing, script kiddies as well. But the problem is that it makes everybody sad. It's horrible stuff when it happens. It causes money loss for the ISP. They end up going over commit rates on a 24?hour DDoS that could be enough to push their 95th percentile above a certain threshold and that's going to cause them punitive amounts in terms of over commitment.
Customers get really unhappy about this. Their service level gets thrashed. And they are really unhappy. And if you have got a busy core you can find out that our own network is going to be thrashed by it as well which kind of feeds into the next problem which is you get other angry customers. You get third party spill I don't have into this problem. And it's not good, it makes people cry and I really don't like it.
So, this is ?? we need to define the problem. We need to try and figure out what we're talking about here so we can you know get some tools together and try and figure out what we're doing.
So, there is two general types of attacks here. There is smart attacks where you get TCP sin floods and all that sort of stuff. Probably very low volume. It's not generally going to cause huge third party problems but it's the sort of thing you really do want to get off your network.
Or you can just go down the plain old sledge hammer approach and you know, have a huge amount of traffic coming in. Now, Arbor Networks run a report and they solicit input from the community and you know, they give some pretty scary results in there. You are talking about denial of service attacks which might hit 100 gigs of traffic and you know, there are plenty of networks which can handle 100 gigs of traffic. There were no networks which would like to handle 100 gigs of DDoS but many networks simply can't handle this.
In terms of traffic profile, you can have one or more destinations. You can have a single customer or you can a bunch of IP addresses being targeted within the single customer domain. Or you can have, you know, a bunch of customers as a sort of a generic attack against the ISP. And similarly, you can have a single or multiple sources, and we have a name for this. The single source attack is a denial of service attack, multiple sources is a distributed denial of service attack. So obviously on a, you know, complicated network you need really fine tuned tools to try and sort this out, while causing the least amount of collateral damage possible. So, we're going to try and figure out what's the best way to implement these delicate things.
We have a hammer. We're going to thrash this traffic. Okay. So, in essence here is that we are going to try and drop packets. Okay so, here we have the single attacker and the single victim on the ISP network and generally peaking the attack takes the form of bad packets being sent from one direction to the next. Of course you can also have multiple attackers sending packets into the victim S makes the problem a bit more difficult but it is tractable all the same.
So, you have a choice to make. How do you drop the packets? Well, you can drop the packets based on the destination address in which case you are essentially going to take out connectivity for that service for that victim. That can cause problems, because if the victim has a big website like you know a huge big, something like a Ryanair dotcom or a BetFair dotcom or something like that, and you are sending all these packets into, it you don't want to take that site off line. The other approach is to try and deal with the source address. And somehow filter all that have traffic as it's coming in to you as it's coming into your network, so that the victim can stay online, and service all of those destinations that aren't trying to attack them.
Okay. So the naive approach to this is that you, you take your destination IP address, which is 192.168.12.34 and you route it, that will take that particular customer off the network if you have put that up on your transit routers, your edge routers, you will drop the traffic. And here is how you do it on Cisco configuration format and Juniper configuration format. It's exactly the same thing, you send the traffic to null 0, or alternatively I configure it as a discard prefix. It drops the traffic, but it's pretty naive, because you are only do this on single router and if you want to distribute this throughout your whole network, you might have anything from 5 to 5,000 routers on your network, and it's usually not feasible to roll this sort of configuration out because that's just a pain. We don't like to do that. But there is a problem here, we need a mechanism to try and figure out how to distribute this null route throughout your whole network. You can't do this with an IGP, an interior gateway protocol. The reason you can't do this is an interior gateway protocol deals with IP addresses. It doesn't deal with the concept of a null interface, or a discard conif you goration. So what we can do is, we can configure up a prefix with a next hop address to a ?? we can configure up a host address for your null route to a next hop address of pre?defined address and just use that on your entire network and then you null route the pre?defined address so. All of a sudden you have got this mechanism that if you can control the next hop on your network, that you can send all of this traffic to the next hop address which will be null routed throughout your entire network and we would you say BGP for this. BGP is ideally suited. You can't use an interior gateway protocol like OSPF or ISIS or God help us I think there is some people who actually still use EI group on their service provider networks, but you can do it with BGP.
So, this is how do you it. You go along to all of your routers and you choose a prefix, in IPv4 land we generally tend to use 192.0.2.1. This is actually a document prefix. It's defined in the RFCs. It should never be seen on a production network but there is just kind of a custom of using it for this purpose. So, that's the prefix. And once you role this out to all of the routers on your networks which you can do as a static configuration procedure, any traffic that's sent to this IP address is going to be dropped on the entire network. And that allows us to go to the next stage, which is to say that if we want to drop traffic to a specific destination, what we do is we say IP route, whoops, there is a mistake, that should be IP route, then the destination address and then we give the null route prefix. It's exactly the same thing on a JUnos box and we can distribute this into I BGP and then all of a sudden you'll find that this destination will be dropped on your entire network automatically as it propagates out into your IBGP mesh.
It also works on IPv6 obviously, so here we have a similar configuration for Cisco, Ios and JUnos, we are using 100 /28, or 100:: 1 /128, if you roll that out on to all of your routers, it's going to drop traffic to 100::1 on to your entire network. You just put that on every single router on your network. We are about half?way through the presentation and in any good presentation, you always have to take an ad break, so I'm going to do an ad break here and talk about RFC 6666, which is a ridiculously cool number. I didn't ask for it but David Freedman and I have asked that the prefix 100:: /64 be specifically assigned for remotely triggered black holes for IPv6.
We did this to specifically avoid the problem that we have in IPv4, that we're using the documentation prefix for both. So now we have 100::1, so that means we can roll that out on to our production routers and we can write up all our documentation with 2001:DB8 and everything is all good. Sorry about this shameless plug, I couldn't resist it really.
Okay. So, resuming the tutorial. So, that's fine for destination based filtering. But the problem is that destination based filtering will thrash the victim and you don't really want to trash the victim unless they'r are tener a month account in which case it doesn't really matter. What we really want to do is trash the source IP addresses on our networks and there is a mechanism that we use this. It is URPF, which is Unicast Reverse Path Forwarding, and URPF provides a mechanism to install implicit filters on any particular interface, and the implicit filter will allow traffic in that interface if there is a corresponding route for the source IP address of the packet either back out through that network or else to somewhere else in the network. You can specify which is which.
And the vendors did something really really smart here. They tied the null and the discard prefix concepts into this. So if you have a prefix which you direct at a null interface, then that falls into the Unicast reverse path forwarding filter mechanism. So that means that all of a sudden, you can take all of the IP addresses of all of the attackers and feed this into your black hole mechanism and those IP addresses will be distributed throughout your network and you can use the URPF mechanism to drop packets from those sources and this is amazingly smart. I mean, I'm that bloke in the purple trousers there with the tiny brain, but whoever thought of this had a brain that size. I am really in awe of them.
Okay. So let's take a look at the time methodology here. We have, for the destination IP address, if we want to thrash that, Working Group, it makes sense in certain situations. We just use regular prefix based null routing but if we want to block based on the source IP address we use Unicast R PF with null routing, we feed the whole lot into our I BGP mesh and then we have our finished product, which is a remotely triggered black hole.
Okay, so let's take a look at how we do this here. I recommend that for any system, any network really, that you have a separate, at least a remotely triggered black hole server, there are several reasons for this which I am going to get on to in a moment. So, you build your black hole server, and then you plug it into the router reflectors in your service provider network and you can use that to black hole all of the traffic coming in. But it actually gets smarter than that. Because if you're clever about it, you can also use your black hole server to feed to your upstream transit providers. Okay, so if you have this real all of denial of service attack which is completely trashing some tener a month customer, and you want to take the traffic off your overloaded Internet link, what you can do is you can feed that IP address address, that destination IP address of the victim to all of your upstreams and they will feed it into their black hole systems and they will null route the traffic for you and that will take the traffic off your links, which is a huge win in certain situations. Obviously there are many situations where you are not going to want to do that because you know you might have a customer paying you know 10 or 100,000 euros a month for a service, you don't want to feed them into a system like that because they are just going to move elsewhere.
It works the other way as well, you can take in feeds from your customers. If you have got a BGP enabled customer, you can accept host IP addresses from their networks, and you can allow them to configure your remotely triggered black hole server, and you can enable things like community tags to tell, to signal it to, you know, send the prefix up to the transit provider, or not, as the case may be.
This is a really flexible system for managing the whole thing. It's also fully standard compliant. There is no reason that it couldn't be run on any BGP implementation at all. There is a huge amount of documentation on the web about how to do this by the way. There is nothing new in this tutorial. It's purely a tutorial just to try and get some information out there about it.
It's defined in RFC 5635. And that's specifically talks about the IPv4 implementation and there are a great many implementation guidelines and tutorials out there and I'd really recommend looking at some of them, because they are extremely good.
It's very fast and efficient. It's supported by most transit providers, probably all transit providers, because if you don't have remotely triggered black hole configurations on your network, you're running a danger thing. Of course there is also RFC 66666, did I mention RFC 6666, it's a really cool number. Anyway...
Okay, so let's take a look at how you might configure this. You start off with your BGP routers on your network. And if you have got a Cisco box, you need to do two things. You need to distribute the null route, or your discard prefix on all of your routers. And you need to configure URPF on all of your edge interfaces. So this is how you do it. The first two lines there just create the discard refix, and then depending on what sort of a customer you have, you will either use loose or strict Unicast reverse path filtering. So, if you have a customer, just a regular PA customer, you know, with your IP address space and you are statistically routing some address space down to them, the most sensible thing to do is use strict Unicast reverse path filtering because that will be the most sensible thing to do, and you say, IP verify Unicast source reachable via RX and that will deny any traffic for which there isn't a corresponding static route in the other direction which means that any traffic that your customer cents, that isn't from their address space it will just be dropped, a sensible thing to do.
Obviously you can't do this on your peering links or your transit links so you have to use loose RPF, what you do in that case you say if it's reachable ?? if you just have a prefix pointing in some direction on your router, well then you'll accept traffic in for that particular prefix. Obviously, you can do this in JUnos as well. You create your static routes here and then you use RPF check on each of your interfaces.
Okay. A couple of implementation notes here. You need to make sure that your hardware supports Unicast RPF properly. There are some boxes which do it in software. There are some box that is do IPv4 in hardware but do IPv6 in software, such as the Cisco PF 3 B, that would include sub 720 O sub 720, etc.. if you enable Unicast reverse path filtering in that situation, it will punt all of your traffic and you will thrash your box and it will kill it, so you don't want to do that. Also if you are running an ASR 9,000, you will need release IOS 4.1.1 or greater. It wasn't implemented before then.
Most service providers will use next hop self in their I BGP course. There are very good reasons for doing this. Some don't. And they are billion come to do that as Randy Bush said, I encourage all my competitors to do this. But, if you use next hop self in your surplus provider core, you really need to have your remotely triggered black hole server on a separate box. And the reason for that is that if you are rewriting next hop self on each router, that means that you're rewriting the next hop of 192.0.2.1 which means that you'lley you are kind of breaking the whole thing and it's not really going to work properly.
So, that's why you kind of need a separate box.
It does work very well if you have got a good quality route reflector configuration, you just plug it as a route reflector compliant and away you go. It works very well. Obviously standards of compliance, you can run it in Quagga, BIRD, XORP, OpenBGPD, whatever you want. It's very flexible.
Okay, so in terms of server configuration. I have actually found that the best way of sending people to sleep after their dinner is to post up like 200 lines of configuration and to go down through it line by line. So I'm not going to subject you to that level of abuse because it would just be awful. So I'm not going to do that. I am going to go through the server configuration floss fee. There is mechanism to inject the prefixes. What I have done is I've built a couple of configuration templates that you can download. I'll give you the URL in a moment. This includes a system to inject the prefixes into your IBGP core. It enables two tags for controlling the prefixes. One tag will say look keep it within your own core and another tag says distribute to your upstreams as well. It's very important to accept just host prefixes for this sort of thing. Because if you accidentally taken tire, you know, say entire /24s off line and you get the tags wrong you can do an awful lot of damage very, very quickly. So you don't want to do that. This feeds back into the whole idea of taking an RT pH feed from one of your customers. You want to accept just host prefixes for them, and if you have that on a regular feed with say the regular BGP feed, you have to enable, you have to allow them to inject prefixes of up to a /32 or up to /128 for their regular BGP. You probably don't want to do that so that's why it's better to have a separate box for this.
The configuration examples include both IPv4 and IPv6 up links to transit providers. Downlinks to customers. There is both Juniper and Cisco configuration there which is to say Quagga will work straight out of the box, but as I said there is no reason that you couldn't do this with BIRD or Open BGPD as well. And it includes the trigger configuration, so it's pretty much an RTPH system in a box.
And the black hole configuration is at this URL, please don't put a slash at the end of this because we use a CMS, because if you put a slash in it gets confused. Anyway, have a look at the configuration. I am sure there is going to be a couple of bugs; if there are, please e?mail me directly or if you want to cause me acute humiliation, e?mail the Routing Working Group and we can discuss it all.
So, there we go. Any questions?
AUDIENCE SPEAKER: Ronan Mullally, from Prolexic. We use source realtime blackholing quite a bit. XR 411 is not reliable. We have seen issues where we get leakage through the other side when we use that. And it's a great technology, but it is a great rope with which to hang yourself. You need to be very careful about what you put in for your source based filtering. If you just take source addresses as being legitimate, you'll find somebody will send awe source address of a route nameserver or one of your own IXP peers or something like that, so here be drag once.
NICK HILLIARD: Absolutely. The sample configuration recommends that you put in customer prefix lists to restrict the customers to host prefixs from their own IXP address ranges only. Yes, that's a very important point. Regarding software stability, I can't obviously comment on that, but I think every software image has bugs.
AUDIENCE SPEAKER: One of the once I don't think you pointed out, when you do source base filtering it affects everything downstream of your network rather than just the victim who is being attacked.
NICK HILLIARD: Yes, that is true.
AUDIENCE SPEAKER: It's a bit blunt in that respect.
NICK HILLIARD: That's why you want to do single prefix only, because if you take out, you know, a /24 you might take out a bit of your own infrastructure or somebody else's thing. You want to do this as final tuned as possible, with a hammer.
AUDIENCE SPEAKER: Sebastian Wiesinger, hello. Regarding your statement with remote black hole and Unicast RPF, on Junior actually if you configure a Juniper RFP in loose mode, it will have ?? the card route will act as if the route was installed on any other interface, so it will not work, STARTing with JUnos 12.1, you can configure a special handling for this card routes but only there and on the MF routers and some of the, it routers so before that it will not work with loose mode. This is a something that could be seen as a feature or a bug, depending on who you ask.
NICK HILLIARD: Okay. Thank you very much.
AUDIENCE SPEAKER: Merike Kaeo. Thanks for the presentation, I am a huge fan of blackhole routing, and I will encourage people to actually test it in the lab first, because you don't want to be, you know, doing the trigger routing and then going, oh, look at all the stuff that we're blackholing. I have a question because I had a session before and I asked how many people were doing for v6 and it was interesting, most of the people that raised their hands that are configured for v4 raised their hands and said, yes, they were doing it for v6, but how many have had a practical use of it for v6? Because I don't know of any large scale v6 DDoS attack yet. So I'm just, I'm curious have you seen somebody ?? okay, they're prepared, have they actually had to utilise it?
NICK HILLIARD: Anybody in the audience? I certainly haven't had to use it ??
AUDIENCE SPEAKER: I believe the answer is no. I just figured I'd ask the question.
NICK HILLIARD: Thanks for asking the question. It is important. I think it's important to be prepared, because sooner or later it will happen.
AUDIENCE SPEAKER: So for once maybe we have the prevention mechanism before we see the attack?
AUDIENCE SPEAKER: Blake with L 33. My initial reaction was, you know, as you were going through the slides, I was thinking we kind of saw this with flow spec, as you were talking about injecting routes up to service providers, I thought two things and the first thing was, well, not very many small companies implement flow spec generally. It's folks that either give some money to ARBOR or have some geeks in the back making nice machines that inject routes or use XBGP or whatever. But I think, you know, as I went on thinking about this, it's quite a good thing and quite complimentary I think to flow spec in terms of what you can do with it and who is actually going to be able to realistically implement this without a very large engineering department.
NICK HILLIARD: Yeah, absolutely. There are several technologies for dealing with this problem. I'm painfully aware that actually quite a lot of people in this room will actually have implemented remotely triggered black hole systems on their networks. Probably a lot of other people haven't. If you haven't, you really should. But, yes, by all means, do have a look around at other technologies as well including flow spec.
AUDIENCE SPEAKER: The other thing that occurred to me with the flow spec thing was that I think this implies a whole lot less necessity of trust between the customer and the ISP versus flow spec where you can do crazy things where this is route and it's either there or not.
NICK HILLIARD: I don't think that's a huge issue actually. If you restrict your customer to blackholing their space, they can do whatever the hell they want. If you want to take down one of their machines, hey, that's fine by me, I don't care.
AUDIENCE SPEAKER: But also with flow spec you can do all kinds of things like policy based routing and stuff like that.
CHAIR: Last question.
AUDIENCE SPEAKER: Hello, this is Andrei POP, from GI net. Thank you for another great presentation, personally I have ?? black routing with outsource addresses, that was very interesting. Personally, I am very much in favour of stats services, I think that it would be great if ISPs would add up such things and probably buy them with some automated mitigation tools or if we could see at some point the situation where such information was exchanged not only between customers and ISPs, but even if they could propagate even further, and I think that this would be very interesting also, the there are some challenges there.
The other thing I would also like to mention RFC 5575 which is a BGP flow spec. This is a very interesting alternative. I consider an evolution of BGP black hole routing. Because it gives you the flexibility ?? there are some advantages. First of all, the information is exchanged over a different LIR, so it doesn't really mess up with your actual routing table.
Second, it allows you to do more fine grained filtering because apart from source and destination, it can also filter base on ports.
And the last, there is a bigger flexibility in terms of actions, so apart from dropping traffic, you have the possibility to rate the traffic, and these things and I think that it is great to have the option to rate limit traffic because it will allow you to ?? you know, dropping traffic is a very hard action, and this doesn't allow automated tools where you can have some false positives. But rate limiting is something you could probably do easier. So RFC 5575 is written by people from Cisco, Juniper and other vendors. The good news that Juniper has limited it quite sometime ago, but I haven't seen anything from Cisco. And also, it doesn't support IPv6 yet so, there are some drawbacks here. But, it would be nice as a community to ask from the vendors who support this feature and extend it to IPv6.
NICK HILLIARD: Very good. Thank you very much for your comments. Flow spec ??
CHAIR: There was someone else in the queue. I think we have to move on because we are going to run out of time. We still have two more things to go through if you don't mind.
AUDIENCE SPEAKER: Just the one quick comment that I wanted to make was if you are doing NAT 64 or map you kind of can actually block a port with this.
NICK HILLIARD: That's sounds really sick.
Thank you very much.
CHAIR: Thank you very much Nick.
(Applause)
CHAIR: And now we have Vasco Asturiano from the RIPE NCC.
VASCO ASTURIANO: Hello, good afternoon, my name is Vasco I am one of the developers behind RIPE Stat. And I'd like to do a quick presentation on a recent feature that we have in RIPE Stat, which is a prefix size distribution and hopefully how that you can be useful for adjusting prefix side filters.
So, we set off wanting to do an aggregated view of all the allegations and assignments that are done by all the five RIRs, and with with the main focus of aiding the configuration of prefix side filters. And we thought about enhancing this for the people that used to do this based on the minimum allocation size so that you could see not only what is the minimum allocation size but also what would be the routes that would you leave out, would you be cutting at a certain threshold for a /8 for example and we decided to take advantage of like the RIPE Stat framework because you get stuff like data calls and automatic integration with our RIPE Stat back ends, and being able to em bed this stuff in your own web pages, so, we thought it was a good idea to integrate it there.
The source for this is the extended delegation files that are published by the five RIRs daily. And there is one URL here forth RIPE NCC for this one.
Okay, a quick background on how this came to be. With IPv4 running out, the minimum allocation size were quickly dropping in the RIPE NCC region to maximise the conservation, let's say. And this was also happening quite frequently, so, this caused for the RIPE document that describes the address space managed by the RIPE NCC which used to have a longest prefix table which would describe like per block what would be like the minimum allocation size for that. That section got changed, or better, it got generalised to just saying okay, well like for the whole v4 space, we'll just minimum allocation is like a /29 and for v6 it's like a /48, so this prompted some network operators that were using this stuff to like adjust their prefix size filters to say, okay, well now, you know, it would be handy if we have another mechanism of getting that information. I mean we are not defending that's the right thing to do, but they were missing that when that was not present in a document any more. So...
And also, given that this stuff is changing more frequently and those documents were published like, I don't know, once every six months or something, and they would that information would quickly go out of date. So, we thought we better build something that monitoring reality instead of like reporting in advance what would be the usage of a certain block. And that made it perfect candidate for integrating in RIPE Stat.
Right. So, how does this stuff look like? The first step was putting this in a widget and basically you can get something like this based on like you just query on a prefix, in this case it's like 213 /8 and you have all the perfect size which there was delegations like running vertically on the left side and then this section here tells you all the delegations that exist at any of these sizes from any of the five RIRs. Like most for this specific block most it have is from the RIPE NCC but there is bits and pieces from AfriNIC there, probably like some early transfers or something. Then there is a sum for all the RIRs with the corresponding percentage for what ?? how many delegations that have size there is. Then we get a section that tells you like the cumulative sum, so basically, what's the values for prefixes of that size and longer, right.
So, let's say if you were to filter like on a, for, in this case for a /22 and longer prefixes, here, so you would basically like draw this line here. Would you basically see that you would be potentially leaving 4 routes out, or like a bit less than 0.5%. While if you would be doing it like on a /21 then it would be like over 6 percent so it shows a threshold here. Now, what's important to keep in mind that this is only looking at address space registration data, right. So, it doesn't actually check into BGP, so, you know, if LIRs would be, and they are, if they would deaggregate their own allegations into several routes, then these numbers would change. So this is just a kind of like disclaimer to you know, use this information with a bit of salt, let's say.
Okay, here is another example for /16 and here you can see like some prefixes that are like longer than a /24, it goes up to like a /29, although they are in like, smaller percentages.
You can also make it run for the whole v4 space, so like 0 /0 and here on the bottom, you can see like the total of the delegations from all the RIRs. ARIN is slightly on the lead there. And the obvious peak here is /24, so like that amounts to about 35% of all delegations in v4 are actually /24. And smaller stuff than that is like less than 0.22%, so, it gives you a rough idea. I mean it's good to have an overview of how the host spaces the delegated.
It also works for v6 N this case we are looking at like the NCC range where the small PI assignments come from, and most of it are /48 assignments and that's like 95%. More than 95% of all the delegations.
So, this stuff is included in a RIPE Stat widget, right, so it takes benefit of like you can download this data and it's produced dynamically, you can also like just grab this in some of your web pages or something, you can also use like to share with colleagues or something like that. If you want, here is the URL that goes directly to this widget where you can input your prefix and it renders this dynamically.
Okay. So, as an extra step, we also compiled a list for the whole v4 space for each /8 what's the prefix size that have more delegations in it. So, in this case, we see actually the prefix length here is running horizontally, vertically we see all the address space for v4, it's just in order, right. And by looking at this, you can quickly see what's like the minimum allocation size for each /8, and the numbers just represent how many of these prefix sizes exist for that /8, right. And this is pulled from ?? it's the sum of all the five RIRs, right.
And I think this can get pretty interesting when you see sections of the address space where it gets, it's a little bit more fragmented, especially here around the 192 /6, so those four lines there, it gets pretty interesting, so...
Okay, so, this is where you can access that page that we have just seen, this is produced daily from what's published in the extended RIR stats, and you just go to the home page of RIPE Stat and it's there on the top left on the list of special pages. You can also just hit this URL and it takes you there directly.
Now, just to reiterate some of the things that it has compared to what was published like statistically on the RIPE document. First of all you get data from all the five RIRs while the document only had stuff from the RIPE NCC. It's updated daily, so it's not something that's in a document that might be six months old, something like that. It shows you more than just the minimum allocation size, it shows you actually distribution per prefix size so you can adjust your thresholds and see if you're doing a good thing or not. And you can also like access this in several formats, so you can possibly integrate it with your tools and make like automated decisions and reports out of this.
Now, we'd like to get some feedback on this, and we'd like to know ?? this has already been out there for I suppose about a month and a half. We'd like to know if you are using this, and area you using this? And if not, why not? And so, we are just interested in feedback, so please contact us, just send us an e?mail or just grab me me in the corridor, we are very interested in this, and I hope to hear from you. Here is where you can contact us and access the tool recollect etc.. so, any questions, any quick questions?
CHAIR: Okay. Thanks Vasco. The static document was actually a request from this community in the beginning. I don't know how many versions of that document had throughout time to this is definitely an improvement because it's up to date rather than late. Does anyone have any questions? We have at most time for one, we are running out of time here.
(Applause)
We have one AOB item, rand eye row jest key wanted to ask some questions of the audience, while he goes up I mention that today at 7, there is a BoF about the ring that was presented earlier in the week. If you are interested in participating there it is.
ANDREI ROBACHEVSKY: The point of my question is actually, we are looking for operational data on routing security and routing security incidents. Just to give you a bit of context where we're coming from. And we are doing in this area, we talk become network operators trying to understand the needs and what kind of incentive to improve routing security from their perspective. Fostering goodwill and cooperation in the spirit of collaborative responsibility.
It's technology agnostics so we are looking for everything that can help. Raising awareness is very important and in this particular aspect, real data, factual data, please very important role, it's a very important piece of the puzzle. We talked to several operators and several of them expressed need in knowing better what's happening in the network, not only was their own network but just in general. I mean how much we know about what's happening, how often the routes are hijacked, what kind of other policy violations are happening in the Internet.
And well this is need for better understanding of risks. If you want to elevate the talk in I mean to the level of risk management, you need tomorrow data. And also looking how we are doing I mean are we doing better? Worse, what's happening in the Internet?
So, basically the bat we are looking, routing security incidents. We can describe them as policy violation but in particular route hijacks, well maybe you know, traffic detours. Type, duration and causes, and detection and measures.
So, we put together a small survey with so. Questions and this is the type of questions that we discussed with a few and thought that that makes sense. But my request to this community to this Working Group is, basically, I have a few questions, one is do these questions make sense? And if some of them you think either do not make sense or it's impossible to answer, I'd welcome your suggestions how to improve this survey. And another thing: If you are interested in participating in this survey, if you feel you are able to collect this data for your network, please contact me and that would be greatly appreciated.
Well, it's all ?? well input is appreciated and data will be anonymised, I understand that there are certain sensitivities in sharing this data so this data will not be shared, or will be shared if you wish on your terms. What's more important is to get statistical data out of this and not to, you know, portray anyone in whatever light.
So, questions, feedback, very appreciated. This is my e?mail address, presentation is in RIPE Meeting archive. I am here, please meet me if you are interested. Thank you.
CHAIR: Thank you. So there you have the request for information if you can provide anything, I think he will appreciate it and everyone else will also.
We are done for the day unless someone comes up with another item. I'd like to mention one thing I said, 7 p.m. was the time for the BoF. It's 6 p.m. don't trust what's printed here. In ten minutes time I think the RIPE NCC AGM is reconvening here, this room so, I think we have to ask everyone to leave the room, so that only the people with the appropriate badge can then come back, we are done for the Routing Working Group this time around. See you all in Dublin. Thank.
