These are unedited transcripts and may contain errors.

---

Notice: Use of undefined constant steno - assumed 'steno' in /var/www/html/ripe-60/steno-transcripts.php on line 24

Routing Working Group session: 2 p.m., 5th May 2010.

CHAIR: Hello, welcome. You are now in the routing Working Group session in RIPE 60. If you want to be in the Cooperation Working Group, that's the one taking place on the other side of that wall.

We'll go ahead and start since the agenda is a little bit tight and we don't want to run too much into the next session, or any at all if possible.

So, I'd like to start by thanking the scribes, the RIPE NCC has again provided the scribes and I'd like to thank Franz tore take ?? /PRET for doing the Jabber scribing.

Microphone etiquette: If you have any question to ask, you have more than welcome to go to the microphones and ask them but please do state your name and affiliation when you do so for the benefit of the minute takers, the scribe and the remote participants. (Affiliation)

So next item would be the approval of the minutes from the previous meeting, and these were circulated on the mailing list sometime ago. We haven't received, so far, any comments. If there aren't any comments here, we'll declare them final. So I don't see anyone jumping to the microphone.

So, they're final now.

Actions: There is one action that we actually touch in the AOB part regarding a proposal, called net using the RPKI to feed in the IRR. We'll get there. It's a small thing.

The first presentation today will be the IPv6 routing recommendations that Rob /EP Evans has been taking the lead on. I'll just let ?? there was a problem ?? there was a problem with the plug.



ROB EVANS: Right. Afternoon. Thank you all for foregoing the /TKHRAOEUTS of discussing the ITU's involvement with v6 to talk about v6 routing. So, the history behind this is that used to be in the v6 allocation document, a recommendation that your PA prefix should be announced as a single prefix instead of the routing, there was a lot of discussion about, for sites that need more than one ?? need to nouns more than one prefix but can't justify more than a /32 /#?RBGS whether they should have multiple /32 or nouns multiple prefixes. After /TPHOPL suggestion here we decided to take the routing recommendation out of the picks policy document and when that decision was made and is done, we are not going to revisit that here. If you want to, you can submit a new policy proposal. What we are talking about here is the subsequent requirement to document what sort of ?? document the best practices for Internet provider filtering.

We already have this document called RIPE 399, that's could he authored by Phillip Smith, mike Hughes and myself, which says aggregates wherever you can, but admits that there is the odd occasion where you might need to advertise for specific prefixes. It applies to IPv4 and IPv6 equally. But all the examples in a document use IPv4.

So, following on from the discussion on the list, we have ?? we seem to be coming down to a few options, and I'd like to make an attempt to get some sort of consensus on the way that you see us going on this, because this is actually, you know, documenting what people would like to do. It's do we keep the existing documents that's doing the rounds which says aggregate where you are, but suggests that you allow maybe up to a /36. Do we drop mention of /36 and merge it into an updated RIPE 399 that says aggregate where you are, but, you know, there may be times where you need to allow more specifics, but doesn't actually quote a figure. Or do we update the document with a new figure, there is been a couple of discussions on the mailing list about how we might arrive at a new figure, but for this it doesn't require that.

So that is all the framing I really want to do, and now it's over to you.

Or we could have a really short meeting. Really? Wow... Marco. Marco

AUDIENCE SPEAKER: Marco, wearing my operation hat. I stated this before in Lisbon, I like suggestion number one which suggests more specific of 36 or at least put some number there that there is a reasonable guidance that we're talking about 16 more specifics that way. And I would, the one thing I would say is also add the suggestion to maintain the less specific aggregate. So, feel free to allow more specifics but feel free also announce to /32 reachability where possible.

ROB EVANS: We are talking about the situation, one of the situations we are talking about is where there may be discrete islands of connectivity. So, advertising a /32, yes, but, you know, you can't guarantee it will reach ??

AUDIENCE SPEAKER: I understand, but I know there are specifics where you route generate islands but I am afraid most of the /TK*E aggregation will probably be due to /TREFBG engineer the way I see it in IPv4, in that case it would make sense to maintain the last resort to there. So, if it can't be done, it can't be done, but like, it suggests this is not law, so it suggests 36 suggests the presence of a last resort route, and I mean after all it's just ?? it's your address space and you need to make sure it's routed. The only thing we do is offer some guidance there.

SANDER STEFFANN: Sander Stefan. I also like the first option. The only point is I don't know if we should mention /32 or mention 4 bits because we don't want somebody who has a much bigger allocation split it into 36s, but ??

ROB EVANS: Well, as I understand, as I understood the idea behind writing this document, it have for something that people could put in as sort of a filter defence measure. So, if they put this in, it will be filtering on ?? we can't really say 4 bit small, because then we'd have of to have one filter for the /19 that says /23 and one other filter for the ??

SANDER STEFFANN: I meant it more like also for the people who want to deaggregate, to like have a guideline that they shouldn't deaggregate ??

ROB EVANS: Okay, yes.

SANDER STEFFANN: So you can read it from two directions. And I'd like the suggestion of Marco to recommend adding the aggregate where possible.

ROB EVANS: Okay. Rudiger.

AUDIENCE SPEAKER: Rudiger: Well, okay. I think, first of all, there should be strong wording saying you should have the overall aggregate in the routing system, expect that someone will only accept that.

ROB EVANS: Okay.

AUDIENCE SPEAKER: Rudiger: Well, okay, it may be not a nice route to work, but I think every organisation that actually deaggregates /HR?FR a means working with the provider, so whatever helpful deaggregate somebody supported.

Then kind of strongly object to say, well, okay, we are expecting people are filtering on prefix length. Bad. What I would like to see is whatever weird prefix you want to announce, at least if it's for the global community, you should register with the precise matching route, whether that is in the RPSL or in the preferred RPKI that we hopefully will be using real soon. I also would think, it makes sense to put in ?? sorry, I lost one track of thought. Let me see.

Now I am losing the other.

Well, okay, Randy take over. I hope to recover rather soon.

AUDIENCE SPEAKER: RANDY BUSH: Sander, have you you been here too? Randy Bush, I A J. I am a little confused on the first item. It suggests more specifics for 36 allowed to the provider. My memory is the existing document says no more specifics, and I specifically objected to that on the list. So, could you please ?? so, this is keep the existing document, in other words keep a separate document from 399 and modify the existing document to say these two bullets, is that what's meant?

ROB EVANS: Well, the existing document does say aggregate where you can and has this vague figure of maybe allow up to 4 bits more of deaggregation, e.g. dot /36.

RANDY BUSH: It says more specifics of size 36, not more specifics of a 36. Okay. In which case ??

ROB EVANS: Yeah.

RANDY BUSH: In which case I don't like it it, for the reasons I mentioned on list, which is essentially we tell people to hand out 48 its tond sites, we tell people to use this for multihoming (end) we have no better multi?homing scheme than we did in IPv4, but we are shooting those people.

ROB EVANS: Do we tell people to use PA space for multiowe homing or PI space?

RANDY BUSH: I suggest they use both. They are going to use both. And I am speaking as someone this week upgrading through routers because of FIB problems. Ashbourne, Dallas and the western. /RUD /RUD what kind of equipment are you using? I have been using really NATTey words about certain customers who came up and told me, well, okay, we can't accept the global routing table at the moment.



RANDY BUSH: I am in 94 percent. My router hasn't crashed yet.

ROB EVANS: You might want to go back to your desk and check.

AUDIENCE SPEAKER: Marco again responding to Randy. Maybe, okay, so /48, but maybe then at least make a recommendation that if you need more than one, you should at least /THRAOEU art try and aggregate them, so in the end you end up with basically one or two routes per AS and not 65 thousand so someone broke its whole 32 into pieces.

RANDY BUSH: I have no problem with that. I think strong recommendations for all possible aggregation is fine, but suggesting people filter at something that is shorter than we are telling them to assign to multihomers just seems brain dead.

ROB EVANS: Okay. So we are back to having two different viewpoints. There is one viewpoint which is people want a figure in there. There is another viewpoint that says we should take the figures out. It's going to be very hard to get consensus.

AUDIENCE SPEAKER: MARCO: Maybe I should ?? well I agree with, I said there must be a figure in there, maybe I should say I agree with Randy that that figure can also be 48.

AUDIENCE SPEAKER: Rudiger, a number in there that says we assume people are filtering just on length length is stupid, don't do it. And that essentially kind of alliance well with Randy's /48 can work. The question is whether any number ?? any advice in numbers on the number of more specifics makes sense. Of course that depends a whole lot an who is doing the thing. If I am doing that out of my /19, I might have quite a number of customers that validly are discussing this with with me, while someone who is a small local provider may have just 16 customers and well, okay, we probably wouldn't like to see all of them.

ROB EVANS: Okay. Well, Martin?

AUDIENCE SPEAKER: Martin Leavy, /HUR caine recognise click. The question has to be asked, if we put our hats on 15, 20 plus years ago, what do we write about doing this in the v4 world? Rhetorical, I know we didn't. The reality is the that market pressure has controlled all of this in the v4 world and the registries had absolutely nothing to do with this. Nothing against registries of course. So, I am going to throw that back out and say, language should really take into account the fact that the commercial world, the market pressures will be far more of a control, nothing against the registries at that point.

ROB EVANS: Exactly. And this isn't a registry Working Group. This is a Working Group of, hopefully a Working Group of operators discussing routing issues on the Internet.

AUDIENCE SPEAKER: But the discussion explicitly not for today, and not for this week's work, but at some point in time, at some point in time, someone will come to the microphone in the future with exactly what Randy just said for exactly the reasons at some arbitrary FIB size in the future.

ROB EVANS: Yes.

AUDIENCE SPEAKER: Martin: Market pressures will control how this goes.

ROB EVANS: Yeah, and I couldn't agree more. The reason, one of the reasons that Philip and myself started writing this document was because there was some pressure for it ?? I was sceptical about the need for it originally. So, what we have tried to make it is, or what we are trying to make it I should say, is documenting what the people here in this operator community would like to see. It's a movable feast. Things will change. So, what I am seeing ?? okay, if I revise slightly then.

The feeling I am getting now is that we are moving back to a scheme where we shouldn't mention any figures. We should just document that aggregate wherever you can, realise that people will split things up and you should make allowances for that without any fixed figures, which is kind of what RIPE 399 does and it may be back to revising 399 rather than having this distinct document.

RANDY BUSH: Just for the historical record, and that somebody complained to me yesterday that I hadn't called bull shit on anything. Martin and I call bull shit. In the Dan versus's ITF, the core operators and the registries and IANA got together and that's where the /19 came from. It wasn't an IETF meeting, we just happened to be there. Awed Rudiger: Adding specific advice with the right wording and reference to v6 to 399 seems to be kind of the best thing, and well, okay, particular points that should go in there is: Prepare for actually support deaggregate. Make sure that all ?? more specifics that you expect to be globally supported are specifically registered.

ROB EVANS: Good point.

AUDIENCE SPEAKER: Rudiger: Well, okay, keep the number down.

ROB EVANS: I think that's ?? I am more than happy with that outcome. I am happy to go back, revise RIPE 399 along the lines people said. Are there any objection to say going down that route? No?

Okay. Well, in that case, I think we can move onto the next item on the agenda and we have five minutes ahead of schedule, which is good. And the next one is ?? it's Ben owe and Martin please.

SPEAKER: Thank you for being here with us. What we tried to do is to have the key thing as the survey and interviews pointed out to us on secure routing, the state of secure routing, to check that with you and have your opinion on it. So, actually there is just three or four slides and it's really about you letting know what you think.

So, if we look to the outcome of the survey, and the interviews we had, the gross common denominator is that obviously there is a clear recognition that it's not perfectly secure. Perfect security doesn't exist, will never exist. And it is not entire secure.

At this moment, that if we look to how many people around the world have the confidence to rely on it at the moment, even for core practices, is still growing, and good. So, they consider it's not secure enough ?? it is secure enough for the moment, at least for them to feel easy. Again, the question that came back, particularly during the interviews, is: Well, little do they know. Yet, they do it, they use it. And the other one that was obvious in this audience of well informed people, that there is common agreement that action is needed for eninsuring that the routing remains or becomes safe enough. So action words to the future is needed.

So these are the other results that came out so far.

To put them in perspective ?? well these are the answers actually.

32% of the respondents, more than 100 respondents reported there had been routing related security incidents in their organisation. And of those, 32%, 18% experienced severe impact. In a way 16% of the whole. And moderate impact: 30%. So, again that's about 10% of the whole.

If you look at their plans for investigate investing in security, we obviously look to the total, and if you split it out to those who experienced security incidents, either severe or moderate, we see that 100% of them wants to do something about it. So, it shows that the world is going there. Yet, three quarters doesn't think it's a key priority right now. And these are just the facts of what we get back from surveys.

So, is secure routing a major problem today? That's the first question. And I would really appreciate your opinion on it. I will already disclose the second question, which is: What needs to be done to improve the level of routing security to prevent major problems in the near future? So...

Please, the floor is yours...

AUDIENCE SPEAKER: Rudiger: Well, okay, I would think everybody has some responsibility for the core of the network working. Well, okay, at least should understand that this is a very fragile thing that attacks are damned easy, well, okay, we know the attacks that are just happening by fat fingers of our operators so far luckily have been the only ones that got publicity. It is extremely good that the public perception at the moment is that well, okay, there is not a big problem, because if people get crazy there doing the right thing gets harder, but I think one of the main lines in Randy's presentation yesterday was: Well we need to get serious improvements in place before the public's perception changes, reversing the public's perception that this is safe and secure when they learned the hard way that well, okay, it isn't. Getting back into the nice state at the moment will essentially be impossible. And that will be really damaging to the industry as a whole and at all the major players that are involved. And we can't predict who is going to intervene and in which way and how reasonable that will be.

SPEAKER: Thank you. Please, I think what you just said is that you are disappointed by the large part of people don't think it's a priority yet?

AUDIENCE SPEAKER: Rudiger: Well, I don't have too much trouble if the bliss flee ignorant state of the general public extends to, well, okay, large parts of the very edge of the network. I really ?? well, okay, if you would tell me, and you don't have the data I guess, that you have the majority of the major players saying well, okay, nothing needs to be done, then I would really be scared.

RANDY BUSH: This is the other one of the two Rs, we really need to be able to do some harmony.

First of all, I already gave him trouble yesterday, but how you suck erred a good computer scientist like Ben owe into doing social science, God knows. Surveys ??

SPEAKER: It seems to be part of this world that there is a social life, not only technical life.

RANDY BUSH: Certainly there is, but these kinds of things, as Rudiger said far more politely than I am going to be, ridiculously biased in their sample. You have got 23 out of 30 thousand ASs responding, who knows who the hell they are, and it should be noted they had the spare time to answer the survey. So they couldn't be very seriously worked.

I would like to have a little bit of I tax on here. Add Rudiger said, there is the fumble figures. I do not use the word attack there Rudiger, they are fumble figures, they are mistakes. I think we agree what they are, but I ask you and the others not to call them attacks. They are honest accidents and mistakes and they are almost ?? they are almost all of what the public ever sees going wrong ?? all those things in history are, have just been fumble fingers. There are routing, i.e. control plain attacks. We have seen those. We have seen more than are talked about because the router ?? the ISPs don't like to take about them, just like the banks don't talk about large fraud cases. And the one thing that's been very nice to those of us doing research in this area is that Alex and Tony's delve conexperiment, where they showed the in?path "monkey in the middle" attack, now could be pointed to instead of trying to point to things that the ISPs don't like to talk about. We had a public demonstration of that class of attack and we could talk about in? path monkey in the middle attacks, but the third thing that I would think about in the long term is we have a case, in fact you'll see it in the next presentation, where the data plane does not follow the control plain and no amount of securing the control plain is going to solve that problem until we lack the data plain to the control plain.

SPEAKER: Thank you for that. And understanding this that some of the key attacks that are done not by fat fingering, but by serious attempts, are not talked about, still we have a feel for what needs to be done. At this moment, we are aware of obviously the RPKI initiative, and we are aware that once that will be installed, that will take sometime to really settle solidly in the system and the question is: Is that enough or does more need to be done?

AUDIENCE SPEAKER: Rudiger: No, no other self?announced expert in the room? Well, okay. Well, okay, Martin, when we are talking about that stuff here, we actually need to differentiate and well, okay, trying to do a very simple quick shot, I am seeing kind of four levels. The first level is stuff that everybody should be doing already. And well, okay, like in many walks of life, not everybody is doing what he should be doing. That's a lot of very simple filtering where, well, okay, you protect your system from people fiddling around actually with your resources. The next level ?? the next level is something where, well, okay, we essentially ?? well, okay, and this first thing is everybody can do right now because no information is needed that is not available to each single operator. All steps beyond that require reliable, current and automatically processable information about the global resources that are being announced on the network, and the RPKI is the only known horse sitting before the doors of v? town that can do that. It needs to be done right, and it needs to be done in a way so that a community actually accepts and uses it. The benefit first step is, and I am really lucky ?? I am really happy about Randy's presentation yesterday, is that well, okay, using that information, we have real chances and the router implementations are essentially being available next year to do the improvements, the filtering that can be done just by checking the actual announcements that we are seeing against the global trusted information base. That steps ?? well, okay, not technically origin validation, that step in fact seems to protect against all the fat finger incidents that have been published to far, and as Randy noted, well, okay, essentially no other incidents have been reported.

The next step beyond that actually requires adding security cryptography elements to the routing protocol. That's a little bit harder to do. Work on that seems to be in progress and different from the work that was done more than a decade ago. And that actually provides and outline for getting the solution. That looks like we have a nice chance of seeing that to come to life not too far in the future.

The last step is what Randy was mentioning is actually to get the functionality into the systems to lock down control end data plain and that seems to be much further away and well, okay, the first two steps ?? well, steps 0 ?? well, okay, everybody needs to do right now and well, okay, there is actually no excuse. Step 2: The RPKI based ?? feeding RPKI, building RPKI and starting to use origin validation, well, okay, that seems to be very feasible and doing ?? well, okay, scheduling that seems also to be a good thing.
The other things we all need to be aware of that it needs to be ?? that it needs to happen. We need to support the work on the solutions and we need to bang on the vendors when the definitions come out and we need to remember, well, okay, the RPKI is actually the absolute prerequisite of all of it.

SPEAKER: Thank you. Do I understand, if there is no talk about any incident except the fat fingering, that maybe some people on the edges may not be aware, as you say awareness may need to go up as well.

RANDY BUSH: The other half of the due /ET again. I'd like to refer to a Sharon Goldberg paper at the previous end he's conference where she compares the effectiveness of different defences against specific classes of attack, and the defences she particularly analyses are prefix filtering as we manage to do to a very minimal extent today to the weakness of the data sets, and the weaknesses of sum routers, derivatives of the class of a protocol protection mechanism known as secure origin BGP S or BGP out of /RUS white and his compass I can Chris could he, and S BGP and its class of defences as came out of BBN and Steve Kent who is probably right there. And I have disagreements with the results of the paper in two dimensions.

One is that I believe the actual analysis could be better. But she does show that filtering an a law B CP 38 is very strong. But there is a weakness in the paper which is to do the analysis she based on assumed topology of the network and those assumptions are classically known as the Rexford gal topology which presumes pretty peer provider customers relationships, valley free, all those terms and to me those are peer B S, that's not the way the real network goes and when you go to look to any provider of any scale ?? that's the way it is at the stubbs of the edge out. When when you look at a provider of any scale you find that policy is extremely complex, and changing but even if you do a static analysis, policy is very complex and we are currently looking at configurations in some very large networks and the complexity is extreme. But what the problem is that when we want to analyse those, what is an attack? It is /RA violation of the intended policy, not some computer scientist's model of what the possibilities of policy are, and we don't know what that policy is. When I look at, let me pick on some that I don't know, an UU net and sprint, and their policy words to each other, if I want to determine if there is an attack, I don't know what their policies are. And if I pick two providers whose configurations I do know, there is a horrifying semantic gap between their intended policies and the representation of them in configurations in these horribly stupid primitive languages that never say oh, I prefer local peers to distant peers. I prefer cold potato hot. Those aren't stated. They are coded in these horrible syntaxes and they are very hard to automatically extract which we are actually trying to do.

So the key point there is: You can't know their intent. There are more things on heaven and earth Horatio than are exist in your philosophy.

SPEAKER: I am a social scientist, so for me just an attack would have been when things don't work. Whether policies match or not, I wasn't aware that it could be considered a problem too. But thank you for that.

AUDIENCE SPEAKER: Nick Hilliard, just to correct Randy, there are more things in heaven and earth Horatio than a dreamt of in your philosophy which is one scale of magnitude even worse than exist.
I'd like to bring up the concept of worse is better. And risk analysis. Now, it seems to me that, yes, we do have fundamental gaps in our routing security policy throughout the world, and YouTube incident occur, there is no doubt about that. But all of this RPKI and secure BGP, these new policies are all heading words to a state of increased complexity and increased difficulty in terms of configuration. And this in itself, introduces a whole new class of outage risk for operators, so in essence, we are not ?? if we go down the route of using RPKI and secure BGP and all of these new technologies on our live networks err we are not going to end up with a more secure network particularly. We are probably going to end up with a hugely more complicated network which fewer people understand, which is really good news for the really smart people in this room because their continued employment will be guaranteed. But, the issue is that this is going to cause a lot of outages because people forget to play around with their certificates, update their configurations and as a result, we won't have a single large scale YouTube events or 7007 events or anything like that, but we will have a much greater low level configuration, or a much more continuous low level problems which will probably be overall an awful lot worse than the single short outages which we actually deal with fairly quickly. Has there been any risk analysis done in terms of the trade?off between increased complexity and increased writing security?



SPEAKER: Ben owe) I don't think that many operators did the risk analysis. There was a remark that security is not always aligned with stability of your network or with availability. That's certainly true, and introducing security mechanisms makes your infrastructure ?? can make your infrastructure more brittle. So that's correct. And ?? so, I have interviewed experts. I am not an expert on routing security per se. So, what do the people propose as a solution to this? Is it improved tooling?

AUDIENCE SPEAKER:

NICK HILLIARD: The essence of what we are working on here is we are trying to create the tools to make the option available rather than you know to try and recommend that everybody in the world do it. The risk that I see there is that there is going to be a split between different types of organisations, some of whom are going to do a risk analysis, decide the whole thing is far too complicated and not implement it. Some people who are going to do half?assed implementations and really break things rather badly, and then there is going to be most people who just don't really care. All in all, I don't see a huge level of thought going into how we can make this better for the operators, easier for the operators, such that these problems will be avoided in the future..

SPEAKER: I think it's very clear there is a different level of operators, the big ones and the professionalality, and then the the smaller ones.

AUDIENCE SPEAKER: Geoff Huston: Routing is kind of special, it has a lot of different properties to what we're normally used to in security. When you think about what we have done with, say, electronic mail security or even in the DNS, the question you are asking is: Is the information in front of me a precise and accurate replica of the information that was originally injected in the system? And this whole issue of cryptography and so on allows you, if you have some trust mechanism, to actually say, yes it's the same piece of information. When you think about routing, what gets injected and what you hear are never the same. The original thing, that blot of information, as it moves through the network, it is altered. So, you can't sign it and then look at it and say, you know, this is the original thing. So, the first kind of observation is that this environment is not readily susceptible to the usual things that we have done in typical security mechanisms. Did you really say that? Am I looking at what you did? Routing doesn't naturally be suspectable to that.

The second thing is that routing is a shared disease. Everyone wants to hear everything all of the time. So that, any individual's practices, if you will, are globally visible and that I might have the best practices in the world, but if you, for some value of you, don't and I believe you, then my practices don't count any more. This, then, leads to an interesting observation of what is routing security and what do we give up when we go there? I would see routing security as a constraint. You can't advertise anything. You are constrained in what you can do. I can't do anything. I am constrained. I am constrained in what I pass on and how I hear it.

And the real question here is: How is that constraint applied in a routing security world? Where do those mechanisms of constraint come from? We have seen models with the Internet route registry which tend to be self?imposed constraint. I say in the registry what I intend to do. I do it. You can see if I lied about my actions versus my intent. That's one system. And it's sort of this system that doesn't rely on authority or hierarchy, it just is I say it and I do it and you can tell you know what I did is what I said. Other models and you know certification tends to come into this kind of model, hierarchically imposed. There is a limit to what I can talk about because the authority model doesn't permit to to talk about everything. I can only talk about these things. Immediately then you start to worry precisely where and why does that authority model compose constraint and I remember in Lisbon a discussion in perhaps this same Working Group, about revocation of certificates and the authority thereby. And that's actually a pretty typical reaction when you get an externally imposed constraint on a system.

So, when you talk about what needs to be done, I am not sure it's that simple. I am honestly not sure it's that simple. It actually ?? you have got to look at the motivations of the players involved and their natural reactions to how they compose and impose common constraint.

It's not easy for me to understand how everyone is ever going to deploy secure BGP of some form of variant as a universal deployed outcome. But I can sense a number of players wanting to do it but universality is a very different thing it in the same way I am very cynical about universal deployment of DNSSEC on every last part of every last branch of the tree. You know we are not going to get that. Then I look at this model and say what works more naturally in this industry, and I suspect that's actually an interesting question to sort of start looking about, when you think about security as a form of constraint imposition, and what models of constraint imposition naturally fit, the motivations of players, consumers and observers. Thank you.

SPEAKER: I had a warning that we really will have the last two speakers now. So please, thank you for that insight.

AUDIENCE SPEAKER: Hi, Jamie here: I am putting my term /AL AS hat on this time. We have had problems nounsing new routes, naming no names but it was a large British telecom provider. What we found is obviously when they obviously peer with a number of different people at different exchange points and it took us three or four weeks to actually get them to sort their filters out. So, from an end user perspective, what existing document like to be able to do is if we are got RR RA, we can announce the prefix, the peering points know that it's come from us and what we'd like to see is obviously if each step along the path was signed by that autonomous system, then we could be assured that the traffic really is going along that path and hasn't been diverted from Mr. bad AS who said I am peering with YouTube.

AUDIENCE SPEAKER: Rudiger: Nick, I think your point that risk analysis for the new model is indeed important. I know, I know that we have been thinking along the lines of Randy for some tooling and so on, and well, okay, I would like to see the academic community chime in with analysis, kind of like the paper that Randy mentioned from Sharon Goldberg, I think there should be fertile grounds there. Nick, the point about the complexity and the reliability of a resulting system, well, okay, I think the current situation actually has lots of complexities that are based on, well, okay, we have only fairly unreliable and incomplete and very inconsistent and technically different sources for information and anybody who has to actually work with all that stuff, has an awfully complex system to deal with all this, and one of the benefits of the RPKI thing is that well, okay, that's a proposal that is global, homogenous and well, okay, well defined and it's nice to have a restart once in a while. We can't have it only ?? once in a few decades, and well, okay, for Geoff, well, okay, actually the concern about what can be done in ?? well, okay, what can be done in putting security into the routing system?

Well, checking that the the data' origin, when it was injected into the routing system quite easily can be verified and actually doing something that certifies that, well, okay recollect the path that we are seeing is actually genuine, seems to be pretty doable. The work has not been completely finished I think. We haven't seen the specific proposal. I think that can be done. Yes, of course there are a lot of other factors that need to be considered and well, okay, complete deployment, I am not quite sure whether I am expecting that before my retirement age.

SPEAKER: When are you retiring?

AUDIENCE SPEAKER: Rudiger: This is not an announcement. And actually my company has been asking many people including me whether he want to retire early, and I said no.

And, yes, well, okay, I think we can actually get significant improvements even with various forms of partial deployment, and not doing something about it I think is very sure way to get us on to wall street journal's headlines.

SPEAKER: Okay. Thank you. I think the suggestion is very much we want to do something about before it crashes again and things like that.

Just final remarks. It was remarkable in the survey how little response we got on the RPKI on the PKI type solutions in terms of thinking, awareness, etc.. so, things need to be done there as well. And for those who participated to the survey, thank you. We also talked with more than 20 experts in the field, some of them are in the room and maybe we picked all the wrong experts, but I must say the answers that we got of the survey and their answers were converging, so it seems to be some at least indicative value of what is there and please pay attention. Thank you for your time and your insights.
(Applause)

CHAIR: So, moving right along to the next item on the agenda. Randy if you could come up please. Randy Bush on AS topology visibility.

RANDY BUSH: Many of my fellow researchers. So, in routing research, we tried ?? this is a negative presentation. It's a negative result. You can't get there from here. But many routing researchers as I said, study visibility. In other words, what's the actual inter AS graph of the Internet? What's the topology of BGP routing? And then come questions of given that, how do you debug the network with ping traceroute? And what we are trying to study here is how biased is our methodology for doing this? And once upon a time RIPE and rows views were designed for the operators, it was so I could find out what Rudiger saw from me without calling Rudiger. And unfortunately, a bunch of researchers discovered this and said, oh my God, data. We can actually find out some stuff. But they didn't think well, how that data could be actually safely applied. And this is a story about that.

When we do a Google scholar for papers mentioning route views, we get about 130 a year she is years. These are research papers betting their careers on this data. How we got into this particular one: We did some deBogonisation for ARIN, this was a project that used traced routing and out to actually find the points where Bogons were actually being incorrectly filtered, right. We had these terms we use here in RIPE and APNIC, deBogonisation, they are not deBogonisation, they are just giving you the ability to ping something, it doesn't tell you what needs to be fixed, okay.

So, ARIN didn't deploy this software. We did get a paper out of it. So that's what academics want. We turned the tools to other use, and this is the story of that. One day Olaf says what happens if you announce a 25? So I announced a 25 to N T T's global network. John /HAOEZly said I'll pass it to my customers but my configurations won't allow that to go out to peers. Then we looked in route views and RIS and we showed that 15 ASs could see that /25. Total 15 ASs in the world, route views and RIS both showed the same thing. And then sourcing from that 25 we pinged and we have a database of 5 or more pingable addresses in ?? and 1024 could get packets back to that /25. That's a factor of 60 different than what route views and RIS were showing us. We also have access to about 700 BGP views from some large CB N, exact same results. They only saw those 15 ASs and yet, 1024 could move on the data plain to that /25. Back to what I said a few minutes ago about the difference between the data plain and the control plain.

So, just the silly little measurement, the AS HOP length, the solid red line, is what you normally expect from a distribution of a /20 as far as AS HOP length. The dotted blue line is what we get from the pinging the ?? from the 25. In other words it's pretty he much the same but shortened a little. But we get this funny shape from the BGP measurement at RIPE route views, etc.. so, that gives you another feeling for how inaccurate it is.

So we said, how much of this is due to use of default as opposed to RIPE and route views bias? So we designed an experiment which those who read NANOG will have seen all the flaming mail about. The experiment works like this: I want to see if AS 42 has default? How do I do that? Well I use the fact that BGP uses the AS path as a loop detection mechanism and I do something called past poisoning, where I announce a prefix to AS 42 with 42 already in the path. And by the laws of RFC, whatever the heck Yours sincerely, AS 42 is not supposed to believe that announcement and is supposed to drop it on the floor. (It is)

So I have pro prefixes, I have 98118 /16. Which for this experiment I actually chop into two 24s because I want to let in each announcement to settle for route flap damping for three hours. So ?? and then what we call our anchor prefix which is a prefix that's you know 20 years old, pretty stable, etc.. so, I path poison AS 42 for the test prefix. I ping from the anchor prefix to say are those pingable hosts alive right now? Yes. Then I ping from the test prefix and if she responds to those test prefixes, that means she has default. And if she doesn't respond, that means she has BGP reachability, because she could get back to the anchor prefix, she just can't get back from the poison test prefix.

So, what were the results? By AS in the /25 experiment, 70% had default. That number was a little larger than we thought it was being to be. So, we used a classification, Ricardo and crew at Lisa sang at U C L A have a classification of stub ASs, small transit providers and large transit providers. I believe that classification to be severely flawed because stubs are defined as having no more than four down streams. But let's ignore that for the minute.

And this is what it looks like when you do those classifications. It's a little more than just ?? you know, you see a big portion of the stubbs have default. Small ISPs, still a good chunkey bit and even still large ISPs are significant. So is there a default Freezone? Probably. But you are going to have a hard time finding it.

To give you the actual breakdown there, we were able, of 31,000 "Tub ASs" we had enough prefixes that were pingable in them that they were willing to call it a reasonable measurement. 77% of the small ISPs. 44% of the large ISPs, of which we could measure almost all and we are pretty good add measuring the small ISPs. 17% had default. In some part of their network. Now, notice these mixed results, they are kind of interesting. And I'll get to ?? let me ?? this is like if you want to like think of things in terms of out degree, which is how many BGP connections we could see in route views in RIS that an AS had and the various ?? so, Japan is different. You'll see at the end we put up a website to the people could enter their AS and see what we thought their results were and commented on it, etc.. and they typed in all the ASs for the all the ISPs in Japan. Right. And Japan only has 36% default. And so, he went further, he is a quick typist, and did Japan, pie within a, Australia, Korea and China, and pretty amazing. This is geek culture, we hypothesis. We actually, not being tricked into social science experiments, we are just hypothesizing, we just hypothesising, it's cultural. And in fact most BGP, senior BGP operators are actually culturally descended from about three or four early operators in Japan and anyway, they all drink beer together every couple a months. And when I say they drink beer together, you folks are light weights. They stop when the restaurant has no more. And I am serious. And they are serious.

So, you know, they are fairly homogenous routing colour and so forth. So this was really interesting to us.

So, as I said, we put up the website to do validation, and this is like three months ago. 216 operators had answered. 172, about 80% said "Yep, that's the truth. ". About 10% said "It's almost correct, but things are really more complex than that and you didn't catch the complex part of our network." 5% believed we were right but had no idea really. "Sure I'll believe you." 4 percent we measured wrongly. And this is an interesting one, I love it. Rudiger and say we peer. And Rudiger established one of the particular links, so he paid for the circuit so the convention among peers is we use his address space, we use his 31 for this link, sore 30 if you are really old and not paranoid any more, and so, it's in his address space, he doesn't have default but I do, you pinged me at that address point. You said "Aha!" That address space has default and you marked Rudiger had default, and he didn't. So that's one of the reasons for this 4% percent in raw measurement, all 8 of them. And 5 people said "We must be wrong."

So the mixed category I talked about before is also fun. You know, an AS is supposed to have homogenous routing policy and there goes another flying pig. They don't. And many had big routers for their core and oh, we have IPT v? cloud over there that's done with little routers and they use default. So, the routing policy of the AS was definitely non homogenous and so we measured both. And that was that mixed category we had before which was another source of error.

So, to sum it up. 1024 path poisoned ASs could reach the test prefix. Let's assume 70% had default. Since we measured that they did. The other 30%, or 307, therefore, had a BGP path to us. That did not show in route views and RIS. That's a factor of 20 error lower bound for the topology error of looking at data in route views and RIS, and it's not ?? I am not ?? it's any BGP monitor. It's a BGP monitors tend to be highly biased words to what I call the clue core. It's either the core of the Internet and/or clueful people who are participateing in those measurements. As a side note to show you just how biased and unbelievable things are. Here is another way of looking at things.

Say I want to do route cause analysis, and oh bloody, this is a PDF, this isn't going to work any value, but anyway...
AS 4 has hard coded some preference for AS 3, it's a friend, it costs less than AS 6 or whatever, so AS 4 prefers this path, so this path, we have a BGP monitor here. Here is the prefix originating at the left side. This guy, therefore, since this is 3, 4 hops and this is 3 hops, chooses this path. Life is fine. There is a cut right here. Therefore, this withdrawal occurs. Therefore AS 4 prefers this path, which is only 2 hops long. And tells this to AS 5. AS 5 now sees 2 paths of length 3 and says, ah, I prefer the one beginning with the smaller number and routes that way. And the researcher sitting right here doing route cause analysis says "Oh, let's see where did that error occur?" And notices that of the paths she could see at the monitoring point, none of them had the 2 ASs where the trouble occurred in the them at all. They didn't have the data on which to draw any conclusion. Okay. Route cause analysis from BGP looking bye?bye.

So our glasses are broken. I told you this was a negative result. Looking at route views in RIS doesn't tell you squat. Looking at just one is as good or bad as hundreds of BGP feeds. Researchers should be very wary of how they use these data for what classes of analysis. And we, as operators, should be equally wary.

And the /PREZ owes we have seen from Renasis, saying we see this thing from our 200 feeds, yeah well you know what those are worth.

And just so, you know, Remco, when you stood up at the mike, unless you left Equinix, I really wish you'd have said who paid your salary, because I like to know what people's unintentional biases are. These are my unintentional bias for this experiment.

Thank you very much.

(Applause)

CHAIR: Any questions for Randy?

AUDIENCE SPEAKER: Daniel: Internet citizen. So, negative result. How do we measure the data plain? I mean, should we get your active probes into all corners of the network and ??

RANDY BUSH: TTM is an attempt.

AUDIENCE SPEAKER: It wasn't designed to do that.

RANDY BUSH: I understand but you are actually using it partially to do that. I don't think you can. The whole reason, or one of the reasons and I think the major one is that RIPE and rows views are useless for, or not useless, are useless for a large class of topology experiments, or measurements is because where the sample is highly bias, the classic counter example is you can't see peering at the edge. I think you are going to have the same trouble inserting active probes or passive probes to look at traffic to try and get where the actual traffic flow is for the network. I just ?? I don't think there is ?? I think this is not ?? we need to change or methodology to be successful, I don't think we can be successful. I think this is a warning of how you use the data.

DANIEL KARRENBERG: I understand that warning and that point is well taken, although I don't quite agree that one BGP feed is equivalent in information content to 100 of them. But you have

RANDY BUSH: It measured, it was.

AUDIENCE SPEAKER: Daniel: In this particular one. But I am not a believer of passive measurements. So, if we want to actually know what the data plain is doing, or know it better, like an order of magnitude better, is wouldn't it be the right approach to actually put active probes in as many places as we can.

RANDY BUSH: I have friends putting in lots of active probes, Kurtis is probably playing with layer 9 instead of layer 2. The data is still highly buysed because you don't get stuff at the edge. We are doing the same within IIJ, other researchers at IIJ are actually putting active probes that look rather similar to Kurtis's actually around is that pan, and we have a better chance (Kurtis) that that community because we can get a lot closer to the edge due to the culture of inter provider cooperation (inter) so I will withhold judgement of that until I see the results. But I don't think we, as a core operator community, RIPE, ARIN, etc., are APNIC, or NANOG can do much to really get ??

AUDIENCE SPEAKER: Daniel: So, I hear you saying put probes closer to the edge is more helpful, and many of them.

RANDY BUSH: There are 30,000 pieces at the edge today and growing quickly. So it's not put three probes near the edge. The problem sufficient to cover that edge and did you ever play the game of go?

AUDIENCE SPEAKER: Daniel: I understand. I just wanted to bring this up.

AUDIENCE SPEAKER: Steve Kent, BBN, partially going to say was in response to Daniel's question is what user community are you trying to serve? That should be the starting point. I think Randy's point was route views and RIS from his perspective were designed to help a certain set of people with certain problems and the research, and they do a good job for that and the research community just, oh boy, data I can go to a cool conference if I write a paper. You know. I have been known to do that.

RANDY BUSH: I never do it.

AUDIENCE SPEAKER: No, of course, not you. And I haven't done it in a long time. But ?? so the question is: You know, who is the user community for this? Because if you want to do a much, much better job, I think Randy's observation of you'd have to put a lot of stuff out there, who should be paying for put a lot of of stuff out there? You know, what community are you serving? And I am not prejudging that, I am just saying I think that's the direction we should come to this from if the user community, certainly in the case of RIS, being principally RIPE members to first order, find that the data they get from that is sufficient for what they want to do, then I think you are in good shape and it is not to first order your job to provide data for graduate students to go to conferences around the world.

AUDIENCE SPEAKER: Daniel: I think that, if we continue this discussion, I think Java will intervene because it's out of scope. But I think it might be inscope for the measurement Working Group.

RANDY BUSH: I have omitted something, which is the group that ?? when I talk about in Japan doing research, actually a paper in 2006 or 7 Cidcom by Cho Kuda and, I am embarrassed to say I don't remember further, looked is he seven biggest ISPs in Japan cooperated. The idea was to measure broadband usage trends and broadband usage patterns and they exchanged between them, gave to the researchers all their international link SMPT data, all their inter providing inter peering SMPT date I and all their customer em SMPT. That would be very hard to do in this culture, it's somewhat easier in Japan. And that experiment has been continuing and ongoing and gave gate insight into the patterns and growth rate of broadband subscribers and was pretty hot stuff. So, you know, not to say you can't do traffic stuff. It's just really hard to do. Anybody else before we get in trouble?

(Applause)

CHAIR: So the next item and the last one is Weisner from RIPE NCC. She just wanted to bring to your attention some work that is on RPSL.

Hi, I am only a messenger. I wanted to bring to your attention something that actually ties a little bit to the previous talk which is, as Randy mentioned in his talk, he said oh I have a database of pingable addresses for a lot of ASs. And this is what we could have if people would start using something which is described in Internet draft. This was already circulated in the routing Working Group, so the link is included there. The author, Brian has been err man, this this proposal with with some other people that are present also at this RIPE meeting, so the idea is to add an attribute to the RPSL specification and the attribute will be called pingable. The value would be the address and then that would be something offered for the research and operational research to other people to send their probes to.

There would also have to be some kind of contact information and in that draft, the suggestion was to call it ping handle, and our database implementation department suggested that it should actually be called ping C, just to be more in sync with with other contact information that we already have in the RIPE database, and so my question to you is: Do you find that this would be useful? So can you show of hands if you think that this would be useful to exist in the database?

Okay, well that's a lot of hands. Maybe I cannot really judge, but 20?ish in this room. And how many of you would actually populate your route objects and Route?6 objects with the addresses once this is implemented? So can I see another show of of hands? More or less the same. So this is actually quite good news, good feedback to bring to the author.

If you have any other suggestion, please write to either the routing Working Group please or directly to the author or to the IETF list or approach me later in the hallway, or Randy, in the hallway and bring your comments to, because this is going to be interesting for the RIPE NCC staff to implement later on when this is published.

AUDIENCE SPEAKER: Daniel: Just an anecdotal thing, not really a proposal, but maybe something to think about. I happen to have a server from a sort of managed server caller provider, and I am quite willing to have it pinged. On the other hand, the only database object I control is actually the eye net numb. The route is much bigger than the I net numb and I don't control T I would put this thing in my my net numb. I can't put it in the route.

RANDY BUSH: I am also an Internet user, as is everybody in this room. That doesn't differentiate.

I just want you to know this is being recorded on video, all those people who raised their hands and said they will announce it, those that do not will be receiving a large invoice.

AUDIENCE SPEAKER: Nick Hilliard: The question about who was use it was interesting. Could we have a show of hands about those people who would not use it and who would deliberately stay away from this parameter in a retro INET NUM object? That's fine. Just secondly, IRRToolSet doesn't support this yet. I'll hack it into the source code pretty shortly.

CHAIR: Okay. I'd like to just have a hint of, about what Daniel just proposed. I mean, this item addresses RPSL and RPSL is a standard thing implemented in various different places and the I net numb on the other hand is mostly specific to the RIPE database.

RUEDIGAR VOLK: INET NUM is standard ?? for a couple of years.

CHAIR: It will remain there, it is a support object for the purpose of RPSL. It only ?? RPSL only specifies a subset of what the INET NUM object is, because it belongses to the communities like these in fact. It is just a requirement to support a certain number of features. Anyway, recapping.

Another an alteration to the INET NUM will probably be addressed separately from the alteration to the route and RIPE subjects. I am happy to take this to the database Working Group as input from this particular Working Group but I'd like to have a sense of the room, whether this would be a feature that people who raised their hands earlier would want to pursue. So if I could have that show of hands. In addition to the RPSL position, do this in the INET NUM that Daniel specified? Yes? In favour? Okay. Maybe I am not explaining the question.

Daniel: That's why I said it's anecdotal.

MARCO: Still responding to Daniel's question regarding the INET NUM. It's a bit of a question of what you want to achieve and how you want ?? what do you want ?? how do you want to retrieve that data? I mean, I'd probably have one dedicated pingable host in a sub net, but I how far I net numbs do you want me ?? it would be probably optional documents probably in my INET NUM objects introduce a ping C or do you want me specifically on the aggregate just say within this super net there is the target in Daniel: I said it was an anecdotal thing that just occurred to me as I was reading it. The way I would try to find these things is obviously look in the routes first and look in the shortest prefixes first but if I am interested in a specific prefix and there is no pingable thing there, I would just fire the more specifics query and see one of them had. Just pragmatic stuff. But since I am the only one yeuch we should make this an action.

RANDY BUSH: Since we are anecdotal, I'll tell you where this came from. Whenever the last IETF was in Minneapolis, the IETF.organise website was not reachable from the conference by IPv6. We had failures, we finally chase it had down to an MTU tunnel problem between gerbil crossing and AT&T. It took a long while. They fixed it. So the goal here is to be able to chase things that like that. That's where it started. Where it goes from here, I am sure like everything else in this community, will all add value. But you wanted the anecdote. It's just to debug, it's like Ralph using RIS, start using it for computer science and you get what you deserve.

CHAIR: It has operational value. Why not. It has very little cost.

AUDIENCE SPEAKER: David Cassens. I don't think that Daniel is really alone on this particular point. The thing that I wanted to say that interestingly enough, when we were running the six bone we also had a small database that looked remarkably like a RIPE style database. In that database we had an object that was a combined route and INET NUM object together. We did that because we wanted to keep thing a little simpler for testing users because this was a simple database and was for just testing and we didn't have those problems between routing and address space, etc.. with you for that database, we also in an attribute very similar to this one but we actually made it a little mitt more generic and we called it an application and in that one with, you could actually just simply indicate things like ping or HTTP or all kinds of protocols and the destination house. And quite frankly, that allows you a lot to test quite a few other protocols if you like to, gives you much more flexibility.

I also have a bit like, you know, just allow this kind of attributes as optional for both INET NUM and route objects. I mean, this is really not a big deal.

CHAIR: That's the general sense ??

AUDIENCE SPEAKER: Actually make it a bit more generic as well because there are a lot of othering this things people can test with. If you want to add it, add it, if you don't want to add it, don't do T

AUDIENCE SPEAKER: Daniel: Let the record show that for this one time I agree with Mr. Cassens.

CHAIR: Quite the moment.

AUDIENCE SPEAKER: One more point we published an article about IPv6 RIPEness and suggested that for one more criteria of proving the IPv6 RIPEness, we would test reachability by querying this attribute once it becomes implemented, and several people responded privately and said, oh I tried to create a Route?6 object with this attribute and it failed. So people are willing to do it even before it is implemented.

AUDIENCE SPEAKER: The last two speakers.

MARCO: I would say that let's not make it too generic. We have DNS for that.

AUDIENCE SPEAKER: I have a question. Is there any reason behind the route object has been chosen instead of INET NUM object? Because several years we are getting a lot of IPv4 classes which are announced under one ?? and following the diverse plains and only one could be enough. Instead of those modified route objects. I believe there are some other cases in which those smaller routes are in different places. Why not make it optional for both, out numb and route and maybe not INET NUM.

CHAIR: Because Randy showed earlier that routing policy within an AS is not uniform.

AUDIENCE SPEAKER: Make it optional for all three levels, not for only route level. Why not?

CHAIR: Last one, because you are working with David.

RANDY BUSH: Discuss it on the IETF list because Brian and I didn't agree on this one.

CHAIR: Thank you. So, with that, we come to the last item on the agenda which is AOB and I was going to read from the scene.

So, long time ago, two years ago, there was ?? came to this Working Group which is labelled twine?4 which went by the name of using the resource public infrastructure to construct validly IRR data was brought here by Kurtis Lindqvist and Randy Bush, and it didn't really go anywhere basically. I mean, even the authors and the chairs had forgot Ben this if it weren't for the very efficient RIPE NCC people who keep track of all this stuff. We would simply have forgotten about it.

Anyway, it was brought up, and because they'd like to have closure on operations. And so, reagreed that we'd bring it up. I talked to the proponent earlier today and they seemed to indicate that they felt that this has been overtaken by events, that there are now implementations that going to be soon available in the routers themselves that can cover this functionality, but since this is a Working Group, everyone has to have a chance to say something. I am bringing it up here and lastly unless there is some support to pursue this the proposed position is to close them. Withdraw.

AUDIENCE SPEAKER: Rudiger: I would kind of like ?? well, okay, I am quite happy to see the original validation things coming up in the router implementations. I guess that not everybody will actually upgrade stuff very quickly on this, and well, okay, there may be some router vendors out that are on the trailing edge. And some people on the trailing edge on installing and buying new stuff. I think, I think there may be some value for those moving slowly in getting the RPSL representation. I am certainly willing to do the few missing things for helping to make that work, but well, okay, it is essentially something where I would say probably the small parties that could benefit this way should speak up and I don't see the high need that was around two years ago, because there was no prediction of getting something else quickly.

RANDY BUSH: Rudiger, do you still want it? Yes or no? For yourself, for others ?? you want it, we'll do it and the second question is, does anybody object?

AUDIENCE SPEAKER: Rudiger: If ask that way, do it sure, fine.

RANDY BUSH: Anybody object? We'll do it.

CHAIR: We'll send this to the list and see who else says something, because...

Anyway...

I had forgotten actually an item that's explicitly mentioned in the agenda just before we go, and since I saw Vince Fuller getting up there, I thought I would; Vince Fuller is running the participating in the LISP project, is here, and if any of the beta sites wants to contact him, he is standing right at the back of the room right now. So you can go talk to him if you want to add anything.

AUDIENCE SPEAKER: Nick Hilliard. Could I just add something to AOB about RPSL. I have been looking at RPSL a little bit over the past year, specifically in terms of tool kit implementation. The standard is decaying in terms of its relevance to the current Internet world. It doesn't really support IPv6 terribly well. It certainly doesn't support MPLS. It doesn't support iBGP internal routing terribly well, we may as a Working Group want to reconsider whether we want to have a look at RPSL in terms of updating it or modifying it in such a way that it becomes easier to implement in functional tool kits, and if at all possible, to implement it because at the moment it's really flex. Can we put this, throw it out to the floor and see if there is any interest. Maybe on the mailing list will probably be better.

AUDIENCE SPEAKER: RANDY BUSH: The place to do this is the IETF. They only RPSL now and in my opinion, they can have it.

Rudiger: They just don't do the implementations.

CHAIR: No, they fell short of that.

Anyway, that was it. If you want to talk to Vince, he is back there. Thank you for coming. Sorry for extending into the coffee break and see you around.

(Applause)