These are unedited transcripts and may contain errors.
Plenary session on 31 October, 2011, at 4 p.m.:
AXEL PAWLIK: Good afternoon. You are very welcome inside again, please find a seat and get settled slowly, there are lots of seats in the front, as well.
Let's start the plenary session of the Monday afternoon, thank you very much. My name is Axel, I am the managing director of the RIPE NCC as you probably know and I am here to make a very short announcement and then I will hand off. As I said in the newcomers' intro this morning, the RIRs, together, as the number resource organisation are also part of ICANN, the performs the function of the address supporting organisation, and where we don't have that much to do within the RIPE meetings it's still important part of what we all do together. In the MoU that we signed signed with ICANN many years ago there is a sentence that says would be reviewed and the NRO would be looking at ways to do that. So, we have a couple of months ago, items international and we have one of their stuff here, there, there he is, and halve vase is here to ask members of the community about how this all works and how they perceive the address supporting organisation to work. So he is not just didn't walk in the street, he is legitimate and you are happy to talk to him. With that, I want to hand off to Daniel, as I also said this morning, the RIPE NCC's 19 years old this year, and we all want a big party so you all supposed to come next year for the big party, but before that, Daniel has a few words for us, thank you.
DANIEL KARRENBERG: Good afternoon. My name is Daniel Karrenberg, I am the chief scientist at the RIPE NCC. And I first of all, I have to apologise because this speech was actually scheduled for the previous session, but I was still in Dusseldorf at that time, because my flight didn't depart because as they say in aviation, take offs are optional; landings are mandatory. The aeroplane was broken.
The programme committee was gracious enough to experiment with something entirely new at the RIPE meeting, at least in my recollection for the last dozen or so meetings or so and that is a speech. So this is going to be a speech, I am going to read it, actually, and I have no slides to distract you from your e mail, and as it is with speeches, it's a particular form; it's a form that actually allows the audience to express their agreement or disagreement while it is going on rather than at the mikes at the end, so feel free to do so.
It's now 20 years ago that we started to build the RIPE NCC. It's quite a long time ago the Internet has come a long way since. The official 20th anniversary will be on 2nd of April next year. Just before our meeting. Today, I will not give you a birthday speech, celebration is for next time. I will take ten minutes to give you a personal reflection on the challenges ahead in the context of what we have already achieved together.
Much of what I am going to touch on will be the subject of discussions during this meeting, and remember this was planned for the previous session, so you can also take this speech as an indication of what I consider important this week.
20 years ago, the European Internet was starting to grow significantly. We started RIPE two years earlier, and it had become clear that we needed a secretariat, a secretariat to perform some day to day coordination tasks that had become too much for volume tiers to do. The most important task at the time, and notably still today, was to maintain a database of operational contacts, the RIPE database. Another task was to help organise the mechanics of the RIPE meetings, that has not changed, either.
Because the secretariat was all about coordination we called it the RIPE network coordination centre. This NCC also already provided statistics based on measurements like we do today. Many of you will remember the famous RIPE Hostcount. One the RIPE NCC started operations, the registration of Internet number resources was still provided by the United States government, many of us realise that had this would not scale and soon the RIPE NCC became the first renalinal Internet registry. We helped to scale up the Internet number resource distribution, one of the few central coordination functions in the Internet architecture. We did so by regionalising it, and by building a bottom up self governance structure for it within RIPE and we all know and love the Address Policy Working Group. We did all this in a calm and determined manner based on consensus. And let me remind you that there are other central coordination functions have have to do with names that took much longer to establish, actually.
So we can be quite proud of these achievements, especially because our way of doing was it later emulated in other regions, even North America. We can also be proud that we have been good stewards of the IPv4 address space, and that we are managing the run out of the IPv4 address pool quite well. We have the policies and the structure that is necessary to see this flew without major discontinuities.
Nowadays, also most governments themselves respect our structure and achievements. Competing established institutions like the ITU, cannot do a better job by a fair margin, despite some claims to the contrary. The reasons for our success as a community are these:
First, we know our stuff.
Second, we succeed to achieve consensus across different opinions and interests.
And third, we adapt well to changing circumstances like the IPv4 runnout.
I am proud of our achievements and I believe we all should be.
Let me now come to the challenges ahead and some important topics at this meeting.
The next big challenge before us is to make the IPv6 Internet perform better than the IPv4 Internet. Unfortunately, we will have to operate two similar but largely separate layer infrastructure layers for some time to come. We have no alternative to us that will scale. It is time we all fully realised this. And work together to make the IPv6 network notably not only perform as well as the IPv4 network but outperform it. There is vital in order for the Internet to scale as it must and for the Internet to remain as open and universal as it is today.
As an engineer, I am convinced that it would be a waste of energy and resources to extend the life time of the IPv4 network using all sorts of cluages.
Some are calling IPv6 a failure today because it is not deployed as rapidly as they expected. But let us not just stair at the adoption rates; let us build a production IPv6 network that out performs the IPv4 network, even in times when investments receive extra scrutiny. It is in these times especially that we should be weary of wasting our resources, our scarce resources on cluages to extend the lifetime of neck following that will not scale.
Talking about extra scrutiny of expenditure, let me spend a minute on the money that most of us, the members of the RIPE NCC association, spend on the RIPE NCC. As an employee of the association, it is not my place to discuss the details. You members will do that on Wednesday. But let me say this much: All those 20 years the RIPE NCC membership has done a good job of making sure that their money is well spent on coordination activities that benefit the RIPE community. We also have maintained consensus that the charging scheme by which the money is collected, is recognised as fair enough.
In times when expenses are scrutinised more than usual, they have always been some who would argue for cutting back activities of the RIPE NCC. Especially activities not directly related to number resource distribution.
I have observed that these arguments are often based much more on emotions than rational reasoning. In tease times, we often hear if we have to cut back ourselves, why should we continue to pay for them. To this, I have to say, first of all, that the RIPE NCC is us, and not them; it is an association of members, after all. In addition, I remember quite well the 1990s, the time of the bubble. The work of the RIPE NCC was suddenly increasing many fold with the bubble. However, it was near impossible to high qualified people to do it, most people at the time wanted both high salaries and stock options, remember? We cut for neither. Then once the bubble had burst there was calls to cut back the RIPE NCC budget, supported by little more than everybody has to cut back. Ironically, some of the more vociferous proponents are the same people who would not consider to take a job at the RIPE NCC before, for lack of stock and high salaries. There was no logic in that, as some would say, but there were certainly a lot of emotions.
Today, the facts are that the Internet business is not generally shrinking, and as far as we can see it, the RIPE NCC membership is still growing at an astonishing pace, so do we really need less RIPE NCC? So do we rather need more?
Let us also consider the absolute amounts that we are talking about. If we were to divide the budget that is currently before the executive board evenly among the members so everybody pays the same, then each member would have to pay a bit more than 2000 next year. This is not a trivial amount of money in some places, I agree, but compared to other costs of being in the Internet business, it is definitely not a major concern, either.
My Friend Rob has been trying to convince me that we should indeed justify the cost by the number of members. A very simple charging scheme. However, Rob has not been able to convince me that charging everybody the same amount would be considered fair enough by most of you. On the other hand, I ask myself how complicated a charging scheme has to be in order to be considered fair enough.
So above all, I urge all of to remain rational and not to let this become an emotional thing and jeopardise what we have achieved.
I had a few words to say about RPKI as well but since this is not in the last session but in this, I don't want to give the impression that I am pre empting things, I will leave that out so we can proceed with the RPKI thing.
Thank you for listening to my views about what is going to be important this week, and I think the RPKI is important. I look forward to discuss with all of you during the meeting and of course to meet you working on the net.
(Applause)
OLAF KOLKMAN: My name is Olaf Kolkman and I will be moderating the rest of today's session. We are going to talk about RPKI, and we are going to do that somewhat staged; that is, we are first going to listen to Axel, who will give a little bit of a RIPE NCC background and context. Alex, who will be then giving a small introduction or overview of technology, and possibilities. After that, we will have about 30, 40 minutes of a panel discussion, and I will introduce the panel discussion a little later and after that, we will open up the mikes for discussion as a whole for about 30 minutes.
So, a lot on the agenda for the rest of the day. So without further ado, Axel.
AXEL PAWLIK: And I am back. Thank you, Olaf. Basically, just a very few words about this session. I am extremely happy that it takes place and that we have a very full room here for a number of reasons:
Talking about anniversary and the NCC becoming 20 years, I looked up my old presentations and actually certification turned up on my presentations five years ago, that is a little bit scary, a long time ago, 2006. I think we had one RIPE meeting where Wilson from APNIC said we are going to certify all our number resources and that is interesting, maybe we should think about similar things. The next RIPE meeting, I think that was in Istanbul, I got pointed at, I hope you do something about this, I hope you do similar things. Well, it's in my presentation already and that is when I presented my first thoughts around the activities and that we should have Certification Task Force, members from the community who should think about this jointly and give us the RIPE NCC, some indications of what to and how to do that and that happened, there are reports done and developments as well, and as it goes with those activities, the longer they go the better you understand them or I understand them, and I am not asking for yet another five years, however.
So, in better understanding what is what this is and how it might develop, I started to have those thoughts about repercussions in the future and similar things and I am sure my chairman remembers that we had some discussions about this and I said, we want to foster some discussion here, and I tried in Lisbon at the RIPE meeting and we did have discussions there, the task force was also there but those things ended up more or less I felt on the operational level a little bit.
So, I am, in the end, happy that how do the I am just back from the ICANN meeting before that, the Internet governance forum in Africa, how do the diplomats say, I was quite happy that those robust discussions happened at the last meeting where we we looked at the really big picture for the first time in the plenary I believe it was. I am very happy we have the opportunity to have this panel here and discuss some or to foster some deep understanding what have we are trying to do and what the options are and operational implications and the like. And as Daniel has referred to, of course on the Wednesday, we have the general meeting, and as our board and myself also, we thought that after the last discussions, we were in a really weird situation as RIPE NCC in between the members who at least tolerated the activity or actually asked us to do this, and the community had really important concerns here, we want to find a way out of this and we hope that the general meeting on Wednesday afternoon, we get some guidance from our members formally, but more important than formal decisions, maybe is understanding in the discussion here and I am very grateful to have all those panelists and Olaf, the moderator, to guide us through the afternoon, and that is all from me, really, here. Thank you.
ALEX BAND: I am the product manager at the RIPE NCC and before we start the panel discussion, I want to give you a quick overview of what it is that we have been working on since 2006 and what is available today in terms of basing routing decisions on the RPKI system.
Now, why is the RIPE NCC involved in the first place?
Well, what you have, what we are building here, is a system, a hierarchy system using digital X 5 and the 9 certificates and these contain IPv4, IPv6 resources as well as AS numbers, you could have them on there, and since we are the registry, we are the entity that hands out IP addresses based on need and we are the authority on who is the holder of which block of address space, it's sort of natural evolution that we would have be involved in running such a system. So as Axel pointed out this has been an activity since 2006, it's been in our activity plan and our budget ever since, so we have always given updates on what we have been doing on it, we have formed a Certification Task Force, evaluating all of the work that has gone into it.
Now, what is actually available? As said, it is a standard X 59 certificate with extensions for IP addresses and ASNs, these are all by all of the RIRs, ARIN is still working on getting a system deployed but they intend to have one available as well, the other four RIRs have something available.
The certificate itself is validated proof of holdership, so that is something that could you use for other purposes as well where you would need to verify outside, for example, to RIPE database, who is the legitimate holder of a block of addresses, you could use these certificates as validated proof of holdership for that.
The implementation that we have done in the technology preview that we launched on 1st of January 2011, we said let's just take it slow, let's give some let's give all of our members something to play with, something that they can gain some operational experience with and let's not gain down to the dirty details of all of the different kinds of address space that we have because we have provider aggregates, provider independent, ERX space etc., we said you know what, we are just going to have provider aggregatable space listed on the certificate, so that is the only thing that you can use and make out the stations with, make claims with, with regards to your address space.
The certificate doesn't contain identity information, so if you are capable of making an attestation using the certificate, you are deemed as the legitimate holder. People always ask me, is my company name on the certificate? In fact, no, it isn't.
The validity time of the certificate is actually tied to the RIPE NCC membership through us having contact with you at least once a year, we know who you are, which address you are at so we can verify on a yearly basis that you really are the LIR who we think you are because only then you can ask a registry of a certificate with assurance that it has correct information.
Now, there is many options available within the RPKI system, there was a workshop this morning where you talk about parents, children, grandchildren, different kinds of publications, different places in which you can check repositories. It's a pretty complex system to wrap your head around but what we have available is just a very, very small subset of everything that is possible. And this is what it is:
The RIPE NCC sets itself up as a certificate authority, so we have a self signed route certificate and it contains all of the address space that was handed to us by the IANA. Using those that route certificate, we can issue resource certificates to our members and they contain all of the IP addresses that were handed out to them. So this is what we do. It's just one level down. It's not possible to create child certificates of that so you would have a resource certificate over assignments, for example, it's only allocations that are put on the certificate and using them, you can create so called route origin authorisations and that is nothing more than a claim that says, I authorise this autonomous system to originate these IP prefixes. That is the only claim that you are making using your certificate. And a valid ROA means that you are absolutely sure that this attestation was created by the legitimate holder of the address space. Now, a valid ROA doesn't automatically imply that what the person put in the ROA is actually correct information; you only know that it was created by the legitimate holder. This is a thinking mistake that many people make, by creating a valid ROA I automatically validate a certain route announce. By creating that you can make one valid whilst you make another route announcement, for example a hijack, invalid, that is the whole point of the system.
Now, for that, we have set up a hosted system because we wanted a very low threshold into the system. We have learned from what we have seen with, for example, DNS SEC employment that if you require every single LAR or every single entity to run their own operation, that the time with which you can get to a reasonable level of deployment, it takes very long and not many people will be willing to run their own crypto and rely on a system that they run themselves. They are like, OK, I am willing to compromise, I am OK with the private key of my certificate residing on a system that the RIPE NCC hosts. I have faith that they are operationally capable of keeping such a system in the air. So that is what is available. It sits in our LAR portal which is the portal that all of our members can access to interact with the RIPE NCC and you can instruct through a web interface to let the certification system do things for you.
Let me show you how that works:
Here, we have an at ROA specification butt oranges you click it and full in an AS number, you give a descriptive name that makes sense for your organisation and you drag in one of the prefixes. You can click the prefix to he had at this time it and fill in so called maximum length. This maximum length thing, this is where most people make a mistake. I am serious. This is why I am stressing it.
The reason why we wanted to make something available to you so we could actually gain some operational experience with it, is exactly this. All of you, lots of you, 600 and 670 LARs have enabled their certificate authority and put in, for about 220,000 /24s worth of ROAs into this system, almost ten percent of the RIPE NCC address space. You know what you did: You created more invalid route announcements than valid ones. Because you all still need to learn thousand deal with the system and this is is also something we saw in the workshop this morning. So getting this operational experience and teaching us what we should change in the interface and what we should do in terms of clarifications is actually really important. And this is why we felt that it was a good decision to make something available to you because we are learning, we are learning here; this is really good.
So, maximum length specifies to which point you authorise the AS to deaggregate, so in this case, it's /22, as you can see. Now, if I fill in 22 as the maximum length, and the only thing that you authorise that AS to announce is a /22, if they announce anything more like /24s, the route will be regarded as invalid. This is what most people do, it's an optional plank field, if you field it blank only the entire aggregate can be announced.
So, let me just fill in /24 here. Well, the thing obviously also does v6. You can set and start date and end date and, the next step is just adding a ROA all of the crypto is done in the background is all of this is taken care of for you. Key rollovers, etc., it's all embedded in the system, you don't have to wore bee a thing. If you don't specify validity date it will just be veiled for as long as you are the holder of the addresses, also if you get new resources from the RIPE NCC or return resources to the RIPE NCC it's automatically reflected within the RPKI system.
Now, with regards to what I just explained in gaining this operational experience, we notice that people aren't aware what the effects of creating a ROA are on actual routing so we took all of the data from our route collectors, and we display within the interface now, what the effect is of the ROA that you created on what we see on what you expect to see within actual BGP. We thought that was kind of an interesting feature. And unfortunately, we implemented this feature not so long ago and most of the data has already been put in so that why we have so many invalid.
So, each RIR has public repository. If you run the certificate authority yourself, if you run the non hosted system, you are responsible for your own of cryptographic material and all of this is using validation tool and this is what we will talk about next.
Like I said, 670 people have done this up to now so they show a great level interest in gaining some experience with the system that doesn't necessarily imply that they think it's a good idea. I just want you to know that this is the amount of people that have that are working with this or have done something with this at some point.
So the non hosted software of course, as I said, you have the private key of your certificate in a hosted system, it will reside irretrievably on a RIPE NCC server. You may not want that. So for obvious reasons, we decided to create a non hosted client, so you can generate your own certificate, you will get through a secure channel, get your resources pushed on it, you can do your own creation of ROAs and creation. All the other open source tools that are available, from Randy Bush, it interoperates with our system.
So you generate your own key player. Here is a screen shot of it. It's a really simple set up in which you can say, OK I am going to configure my repository, make it available, you establish your identity so you need to prove to the RIPE NCC that you really are who you say you are and the RIPE NCC proves to you that you are really talking to the RIPE NCC, so there is an exchange of identity certificates and that is all the configuration that is needed to get it going.
Then the validation tool is essentially the other side of certification. You have one group of network operators putting information into the system [freeze], on which other network operators can base routing decision. Now, in all of this, the predominant fear that I have heard from so many of you is that I don't want a system that just ought mates everything for me, I don't want a system where all of the ROAs are eventually going to determine my routing preferences; I need to be in the driver's seat. I don't want this system to make decisions for me, that is not what it's for. So we are okay we have a good idea: When we implement a validation tool we can go to first give you a web interface and completely automate importing all of the data from the different repositories that are available and then we are going to take all of that data and you can apply your own filters to it so you can have an ignore one and say anything that is in the RPKI system makes a claim about this address space, I want to you ignore it, pretend that it doesn't exist and you can lass have a white list saying, OK, I don't care if there is a ROA for this that makes a certain claim about a certain route announcement and even if there isn't a ROA for this particular prefix, I want to locally create one and treat it to my BGP decision making process as valid, so you are in complete control of what happens within the local decision making process that you have available.
And all of this data, so the ROAs that are imported from the repository, your own filters, all of that information can be fed directly in ton RPKI capable router and these routers, we had Cisco and Juniper this morning, demoing their real life routers who can do this, in Q1 2012 they should be available for production release, likely data, some preliminary testing with Quagga which also works so there is a real effort within the routing community as well to get this going.
This is how our validator looks, it just starts up as a service and off web interface to use it. As you can see, it just takes the Trust Anchors and moves ton all of the ROAs, apply your ignore filters and white list and that goes into your BGP decision making process. Here is another screen shot and all are all of the validator ROAs over all of the page..
As I said, your local validator tool, it sees an RPKI capable router with all of the processed data so the router doesn't doesn't do the crypto. It's real fast and efficient, you have a local, could be R tool and it just interfaces with your router allowing to you make more informed and more reliable routing decisions and ultimately, everything that you do, every routing decision that you make will be based on three states:
One, a ROA is found and the route announcement is deemed valid.
Two, there was a ROA found for that prefix but it doesn't match the correct AS number, so a hijack, if you will. That is considered invalid. It could also be accidental leaking of course.
And the third option and that is what we see most in the system now, sun known. So no ROA was found, we don't have any information on this system. And it allows you to configure Cisco and Juniper to st up prefs and route maps based on these three steps.
That is it, really. So it's just route origin authorisation. It doesn't do any path validation, there is work in the IETF going on right now trying to tack they will particular problem but all that it is doing now is route origin authorisation and validation. Giving you the option to make better informed routing decisions.
You want to know more? ripe.net certification or hash tag on Twitter. Thank you, that is all I have to say.
(Applause)
OLAF KOLKMAN: Thank you. With that, we are ready to do panel discussion, I would like to invite the panelists to the stage. What is this panel discussion about? That is always hard to say with a panel discussion because you get four people gathering on stage and you basically allow them to discuss among each other, but I have set myself a goal: What I would like to learn, I would like to learn from this discussion, is something about the tussles between technology implementation, regulatory frameworks and so on and so forth. Technology offers a certain space to operate in. It also allows a certain regulatory or self regulatory environment with a number of knobs and dials and what I wonder is, whether the introduction of technology like the RPKI actually changes the space. What are the changes to your operational environment? What are the changes to what regulators can do? Because that is an important part of what I have seen in the discussion. Now, those are my goals, and I try to discuss this a little bit with the panelists, but the other thing that I would like to see here is that this panel starts to lead its own life so I'll be stepping back as much as possible. There are a few ground rules and also if it comes to discussion at the open mic: This is not the AGM. The other ground rule is 2008 008 has been re drawn, so we are not going to talk about that specific policy.
Third ground rule is for the panelists. Please keep it on high level and I thought of a rule to enforce that and came up with: do not use too many acronyms, not more than three, but thin thought, if they say RIPE NCC [freeze] we already done to so that ain't going to help and I thought maybe I should put a bottle of very nice wine on the person to the person who uses least acronyms, while saying in a panel with Dr. Kent will be make that a very expensive proposition, so it will not be nice wine but will be a local delicacy, namely a nice tin of /KAO*G for the panelists that uses the least acronyms.
So, in framing the discussion, I thought a little bit about setting a few premises. And those premises that I gave to the panelists already led to some discussion among them, and I want to read these premises to you and then ask the panelists on their responses on those premises, whether they think that is a good way to frame the discussion.
First premise is we are in need of additional BGP routing security.
That is number one.
Number two: The Internet routing registry, acronym, IRR, there I go, one down oh, no, BGP is second is proven not to provide sufficient means and truth for operators to make informed routing decisions.
Third: Resource certification. Using RPKI technology is one of the logical methods to provide cryptographic proof for uses at the station, because of the role of the IRRs as resource authority for IP resource it's logical that they play a role in the certification of those.
And then the last premise is: The users of that RPKI system that we just built, that we just discussed, the uses of that is not you don't necessarily need to apply that to routing. It might be useful for other things as well.
So, with those four premises, I would like to open the discussion but I also need to introduce the panel and I would like to ask the panelists to do that themselves, starting with Steve Kent.
STEVEN KENT: Thank you, I am Steve Kent, chief scientist for information security at BBN Technologies and one of the folks working on standards for the RPKI in the IETF.
SANDRA MURPHY: I am Sandra Murray, I work for Sparta, I am the Working Group co chair of the CIDR Working Group in the IETF that is developing specifications and standards in this realm.
MALCOLM HUTTY: I am the head of public affairs at LINX, the London Internet Exchange. I am also, though not here in this capacity, the president of trade association that, European trade association for Internet services providers and my role is frequently to be the least technical person in a room like this and the most technical person in a room full of government officials.
DAVID FREEDMAN: I work for a company called Claranet, we are an operator and I work in engineering, we are also a RIPE NCC LIR, Local Internet Registry, and I also do some work in the IETF.
OLAF KOLKMAN: With that, who would like to respond to those four premises that I gave or any one if particular? We are in need of routing security, additional routing security.
DAVID FREEDMAN: I don't think anyone disagrees with that, do they?
MALCOLM: I was being difficult in the preparation for this and asking really actually, a lot of discussion that I would like to have is really about these premises, rather than about the rest. We are not going to talk about 2008 08 but I think the purpose of this discussion is to talk about the ideas behind it and what we were trying to get to with that proposal or some other mechanism [freeze] and the reasons why that was proposed was based on a set of assumption like this and the reason it was withdrawn was because it blew up into a big discussion which brought in a lot of things that were challenging precisely these assumptions and I think if we are going to move forward and build a community consensus of what we should do in the RPKI space then we need to start from the beginning and ask ourselves some basic questions and build consensus from there. So it's easy to say we need more routing security because obviously it's a good think that routing is secure; it's bad when there are hijacks, and nobody is going to deny that, but to say you need more routing security of this kind of a technical nature is saying the current system is not good enough and also the technical system that we might put in place would be better and it would be better even having taken account of the cost of putting it in, and these are the kinds of questions that actually should not be assumed; they should be examined.
STEVEN KENT: Was that a yes?
SANDRA MURPHY: Or a no.
MALCOLM HUTTY: So I don't think we have established that as a community. I don't think we have a community consensus on that. I think we can have an easy consensus that yes it would be good if there was more routing security but as a basis for making policy, that question is actually do we need to take action in this of this kind of nature, and that, I don't think we do know. We don't know we don't have a lot of research about quantification of the impact of current routing incidents, we have got very little consideration has been given to what kind of costs would there be across the community as a whole for implementing a RPKI system. I haven't seen any research on that. In order to make any kind of valid cost benefit analysis of whether this is a good route to go down we should make a start on that. I don't expect it to be down to the last dollar and cent or euro and cents, that is not a sensible way to make decisions but it is sensible to ask: hold on, if are we just assuming the premise?
SANDRA MURPHY: I collect incidents that are pubically reported of routing outages, routing incidents, and they have been consistently reported over the years and reported publically, there are lots more reports of private things that have happened that are unverifiable. Some people have presented at NANOG, I see Todd Underwood here so he can speak to that himself. There have been many presentations in various forums of the amount of impact that particular incidents have caused. The number of ISPs, the belief the bogus data, the number of companies whose data was affected and where the data went instead of where it was supposed to go to, in the technical sense of the impact of routing incidents, I think we have had a lot of public discussion of the impact.
In terms of an economic model of the cost of this, I do not know on what basis you would put a cost on data being transmitted to the wrong entities.
STEPHEN KENT: Yes. I agree with at one level with Malcolm's observation that it would be nice if we could assign the cost of each of the incidents arises due minute plea I think today to just operator error, not maliciousness, but then we have to also look over a time frame and say what is the likelihood of this occurring, which, with some of the incidents that sandy has, you could start to do that cost estimate, then it's fair to say what is the price that everybody pays for doing this both as an organisation have a regional registry operate an RPKI to have a major ISP operate the RPKI to deal with the allocations that they make to their subscribers when they are multi homed. And then looking forward, to try and say what are a failure modes that the RPKI creates that don't exist today, what is the likelihood of them happening and what would the cost be? I have been doing security in the Internet environment for before there was an IETF, and nobody does this, by the way. We have done a lot of security protocols over the last 25 years or so and I know of no one who ever went through and tried to collect the information, in particular because a phenomenon we frequently see in the security environment is the likelihood of a given kind of attack is essentially zero, you just never see it, and then somebody develops the attack, makes it available, because the Internet is all about sharing, and the probability ramps up to close to one. So, expected value is almost meaningless in this environment because in the attacking environment it can change so dramatically. While I am sympathetic to the notion of wouldn't it be nice to do this, in the security environment I don't ever see people doing this. We didn't do this when we decided to deploy D CHEM to improve mail security with regard to spam. We didn't do for the DNS SEC, for lots of things. We just don't do these things, for TLS, so I disagree with but wouldn't it be nice if we did this study and then decide how to act. Frankly, that is not feasible and wouldn't be helpful.
MALCOLM HUTTY: The changing probability of an attack, I can see if you have got your basic bug in Windows that allows for red code excuse, nobody nobody abouts about it until everybody knows, does this really fit that?
STEVEN KENT: DNS SEC provides a good example, the economies key attack on DNS demonstrated that the wide range of Band Aid approaches to trying to reduce vulnerability of DNS spoofed responses for cache poisoning were essentially rendered iny fecktive with modern high speed links and the ability to spend responses to somebody in a short term. DNSSEC provides really good security against that, it wipes out that as an opportunity but DNSSEC like the RPKI and the amgies are not perfect by any means is something you can't do overnight. It's going to take a lot of time, it took us years to get the standards right in the IETF, it's taken years to get deployment, to get the route signed in IANA, etc., so my concern is that in the case of routing attacks, we can't anticipate the attacks, we can anticipate the vulnerabilities, those don't tend to change dramatically for the existing system but specific attacks do come up that have not been anticipated, somebody makes the tools available so that you just have to push a button, you don't have to be a smart guy to do it and then to use a technical term, you are screwed, and you can't just fix it instantaneously. If you don't have the infrastructure in place for people to make use of, then you have got several years of having to live with the effects and that is really unpleasant. So I offer that as an alternative rationale for doing where not everyone will agree that the priority is high enough to do it. A bunch of people will feel that it's important, and you take a little chance on whether or not the cost of doing it, especially if it's voluntary, is something that you are willing to live with but it's ultimately up to the operators as to whether or not you do that, RIPE members and everybody else in all the other regional registries.
DAVID FREEDMAN: RPKI is isn't an overnight job, either. It's one thing rolling it out and getting adoption; it's another thing actually getting adoption inside the network, operator, having the operator trust it and decide what kind of overrides they want to use and how they are going to use them. This could takes years, as well.
STEVEN KENT: Absolutely.
SANDRA MURPHY: One other thing: almost all the incidents that we have seen have been incidents of misconfiguation. There have been private hints of things that have happened deliberately, but the Pakistan incident was the first pubically acknowledged incident in which the misorganisation was deliberate and intended to capture data, that it escaped the impact area of the announcement was more than they had intended, but the miss orange nation itself was deliberate, and once one entity begins to use a feature that that people notice you can do this on purpose, it's the first step and it's some cause for concern.
MALCOLM HUTTY: If you are worried that more people might start following Pakistan's approach by using the routing table to implement essentially social policy, then that actually is very much in line with the concerns I was raising on the Address Policy Working Group about this, that this could very much be a vector for that, and encourage that kind of behaviour, and I think it would be desirable if we keep as much separation as possible between those two realms.
SANDRA MURPHY: Well, as, you know, my counter is that the RPKI does not introduce any more risk, that that sort of control could be exercised, that the existing database entries could also be used as a method of introducing that sort of control.
OLAF KOLKMAN: May I interrupt for a moment because I think, for the people who have not been taking part in our lunch, that step went a little bit too fast. Malcolm, can you explain what you just meant?
MALCOLM HUTTY: For the past several RIPE meetings there have been police officers, serving police officers from one country in the RIPE NCC's service region turning up and attending the Cooperation Working Group meetings, which I know many of you don't attend because it's not nearly as well attended as this meeting is and that police officer has been saying, when I identify a network with bad stuff on it, please will you cancel their address allocation and give it to me, the police authority, so all the traffic goes to me instead of bad people. And under the and in a moment, the basic response from the RIPE NCC is we couldn't make a change in a database but people don't really build their routing tables out of our database, so there is no point in doing that, it won't get you anywhere, and it wouldn't achieve what you want. Under RPKI, the request would be this, it would be: Please deallocate the assignment and reallocate it to me and, also, revoke the certificate to the person who originally had it and give me a new certificate and then I can make an announcement that would have a valid certificate and their announcement would either be, I can't remember what it was, but either non or invalid and in other words it would make the person who was actually the assignee, look like a hijacker and make the police authority look like the genuine network and that is exactly what they would like to achieve. Whether you are talking about police authorities or lawyers or scientologists, there is all kinds of people out there that would like to use lawful authority to try and compel the RIPE NCC to make networks go away. And I suggest that it is a bad design feature if we make it look to those people like the RIPE NCC is an effective place to approach with compulsory powers.
DAVID FREEDMAN: I think that Sandra has taken this and, correct me if I am wrong, is that a system exists already, the RPSL filtering system and the argument goes that if you look at the proportion of people that use that today to filter versus the proportion of people that will end up using the RPKI, those could be different, and really, my thinking behind this is such, if I go and ask people do you use the RIR, how much, why can't you use it, most of the stuff that comes out, there is not enough data, we don't have an implementation of it, we don't trust it, so on. Why will adoption of this be any different from RPKI especially if, as Malcolm says, you are going to be compelledat some point to take additional security measures. Sandra said you could be compelled to use the RIR data. That is one of the possibilities as opposed to being compelled to use RPKI. My accountant says well RPKI is a number of work in progress standards, if you like, some of these standards refer to implementations inside routers and of caches and it's very likely a vendor is going to produce a router major vendors have been saying coming to the IETF Working Group saying we are going to produce implementation of router that has this stuff baked into it and you are going to be able to buy a router in a couple of years' time that all you need to do is configure this is the location of the cache that I trust, you don't have to do anything. Compared to what happens with filtering now where you have to have your own system for generating prefixes and pushing those things to your routers so really, it's going to become easier based on what commercial companies say, vendors say they are going to be doing. Their objective is to make this easier and not to make the RPSL and RIR bit easier and when Malcolm talks about being compelled to use such a mechanism, to improve the security of your network, well if we give this our blessing, Malcolm is saying, then we are going to be compelled so to use this and support will be in vendor software and there is going to be less argument.
MALCOLM HUTTY: You got a bit ahead there. I haven't
OLAF KOLKMAN: If I hear you correctly, Malcolm is saying the issuing party could be under stress by guys with guns walking in or guys with papers what have you you, while you Dave, at the other end, say the relying party will have gotten used to the tools in such a way that de facto there is no overwrite any more?
DAVID FREEDMAN: Possibly. I am saying it's going to be made so much easier that some of the barriers and the inhibitors to deploying this will be resolved and it will become much more likely.
STEVEN KENT: I think another way of stating that is, and this came out at lunch so again, it's because we kicked people away when they tried to sit at our table so I can't blame you guys, is that if RIPE says yes we are going to continue going ahead with the RPKI and the other four IRs, three of which are already deploying and one of which this my home country because we are be set behaving way too many lawyers is still trying to make sure the way too many lawyer problem doesn't cause them problems but if they overcome this and the other RIRs continue down the path this is an atrack of it means of enforcing the I want to kill this network or divert its traffic to me because the programme ultimately it's not because it's adopted by the RIRs, it's because it's adopted by the ISPs, that ISPs see it as a superior technology to what is availabled to [freeze] they make decisions about yes, I am willing to change my procedures in way so I can deal with this data, so the threat is that this is viewed as successful by the ISPs of the world, and so we want to keep them from having the option of doing that because they don't have the foresight to realise the potential for a bad thing. That is the evil characterisation of your position.
And I can't help but smile when I say it that way, of course. But isn't that fair?
MALCOLM HUTTY: Well, it's obviously not the characterisation. Because I don't accept one of the other premises that is Olaf started with, that we can be confident this would stay voluntary. It might, but it might not. A lot of people in the discussions around this have said to me, and maybe many of you sitting watching this debate might be thinking, this doesn't really matter, it's never going to get taken up so, I will just go back to my e mail. I know that some of you are thinking that because some of you told me. The thing is, that it's a nice little package of security measures. That you can tie a rib on around and say hey you can do this and it will make things better. And right now there is a specific argument concerning European Union and I know service regions is much bigger but in the European Union right now there is already a law that was passed just at the end of last year, telling the national regulatory authorities that they needed to pass new edicts, administrative edict toss network providers to increase the level of security, but the law didn't say what the content should be, so right now, the bureaucrats and the national regulatory authority are casting around for a specific set of best practice statement or things that seem to have the blessing of industry and network operators as bag good thing to do but which has lower take up than might otherwise by hoped for, they can say right, we haven't invented this, we aren't at risk for this bag bad decision because it was the industry that decide it had, network operators, but we have got to make it mandatory and this fits the bureaucratic need to be able to deliver on that requirement to, pass an edistrict which there is right now, there is a requirement to pass some kind of edict and the question is, what should that be and this would fit the bill.
SANDRA MURPHY: So there are already best current practices that are recommended in every RIPE meeting and every NANOG meeting of the best way to handle your network and they are in best current practices in all sorts of regulatory environments, standards bearing environments like mist as best current practice. These things already exist if your hypothetical situation of people looking around for things that the network community had already come to a consensus over and were recommending, should come about, then there are things available right now for them to go after. And the RPSL database is an example.
DAVID FREEDMAN: And I dream of world where BCP 38 was law. [Freeze].
SANDRA MURPHY: So I don't see the additional risk from introducing the RPKI.
STEVEN KENT: How much do we have to pay you to steer the regulators toward all the other things first? Since this is your business. You are telling us. And you are in touch with the heartbeat of these guys, you know that they have this strong desire to do something so they can get a check mark. If you represent a lot of ISPs can't you steer them towards something else or are we just on your black list.
MALCOLM HUTTY: I will do my best but I can't promise success and I am not here to say a this is evenly second order objection; it's not a this is just a warning to anyone out in the audience that is thinking, well actually, we don't have to worry too much about the primary issues because it's never going to happen and all going to be voluntary and the answer is it might not be, you need to engage with the primary issues.
SANDRA MURPHY: You should be just as worried about regulatory issues of the RPKI as you are about regulatory issues with respect to the RPSL.
MALCOLM HUTTY: I don't think so. There are best practices out there that also look like a nice little package with a rib on on top that would be quite easily legislatable but many of the things in this space don't look like that because they look too uncertain or they involve private actors that regulators don't trust. Things like Team Kimry, whom sure do a lot of good work but they are not likely to get regulatory backing because they are a private organisation. So there are some things that are best practices that are likely targets for we could turn into a mandatory requirement. And there are other things that really aren't. And RPKI looks to me like something that fits the bill and
SANDRA MURPHY: RPSL does not?
MALCOLM HUTTY: And building fit he is out of
OLAF KOLKMAN: Team Comry referance is a set of black list of things that
SANDRA MURPHY: Bog ons.
MALCOLM HUTTY: Team Comry is a private organisation and a regulatory authority would probably look as scans at giving the authority to a non public authority, to a private organisation to build essentially a black list even if it's black list of Bog ons. They might be willing to do that if they were a public authority that would do that but they are less likely to do so for a private body but this is not that situation. This is about saying that network operators should adopt something that has already been blessed by the network operator community.
OLAF KOLKMAN: I want to do a step back because we are still talking about premises. And one of the premises one of the questions that I wanted to ask earlier is about utility of the RPKI itself and not apply to routing. And you were talking a little bit about costs and so on, but I have heard the argument made that having an RPKI might actually cut down on the list of provisioning your routers even if you don't use a system of ROAs and configuration management. Care to comment?
STEVEN KENT: Well
OLAF KOLKMAN: Let me phrase it another way: Does the RPKI have a utility without an application, on, say, routing?
STEVEN KENT: Well, there is an IETF document that has been approved and will be issued as a BCP, hopefully before the end of the year, which is the certificate policy for the RPKI, and that is broader than just routing security; it talks about valid uses of the securities associated with the RPKI to be in supportive applications that have something, I don't remember the exact wording even though my name is on the document, it's ban while, but with regard to statements about resource holdings and so your observation [freeze] is correct this that it wouldn't have to be used exclusively with regard to issuing ROAs and those being consumed for original authentication but we have so far in fairness as standards are in that particular direction, that is what we focused on.
SANDRA MURPHY: The RPKI certificates attest to your right to use the prefix [freeze], it doesn't there are suggestion of other things you might do with it but you have to be careful that you stay within that, that policy of what the certificates really do attest. But anything that falls in that is fair game.
DAVID FREEDMAN: I don't think we are quite at the stage where we can turn off BGP and turn off a routing table every night.
MALCOLM HUTTY: It you build a RPKI system for one purposes, dream up other purposes for later. The transfer policy within the RIPE region is based on the assumption that there will be certificates to attest to your, right to use the prefix so that you can transfer it. But, that in itself to, my mind, doesn't really do anything much to justify creating a RPKI system because we could just amend that policy to say the certificate on paper with Axel's signature would do the trick as well. Transfers of address space need to happen in
SPEAKER: L want to take a leap, if those premises are all true we are living in a RPKI space where we apply things to routing. And the reason why I do that is because I want to explore what the effects are of having everything automated and just blindly believing whatever the issuer says and what you can do to not enter that space, so how can you protect yourself by introducing an RPKI system where there is potential threat that the issuer is forced to do something that he don't want, how can you protect yourself as the relying party on those malicious effects? Is that somewhat clear question?
DAVID FREEDMAN: As an operator envisaging a future where the RPKI is deployed and I am the relying party and something happens to the issuer and something is issued or revoked that I don't like, I can override it on the local basis but how am I going to know to override it or there is something wrong with it? I mean it's one thing signature on operational mailing list, how many national telecoms operators sit and watch Internet operational lists? How many people would react to it and feel confident duff to put if places overrides on a prefix per prefix or path per path basis for instance? What is the future of this going to look like? If we want to make them how do we do so and coordinate it, it's a big question.
MALCOLM HUTTY: I would say it's even worse than that. If we imagine a world where the RPKI is widely deployed and relied upon by network operators to determine hijack rates and suppose my fear that is this could be very attractive to people precursory powers as a system of blocking access to certain resources, if those were true, if that were the world that we were living in, then you'd have a lot of use a lot of certificates being both revoked and then the address space being reassigned and new certificates issued for things like sites that are alleged networks that are alleged to contain websites that facilitate copyright infringement, large number of those in this world if that were true. Under those circumstances do you really imagine that you would be putting in place white list to make sure that your users could still get to those sites bearing in mind that a court would have already determined that that site must be blocked. You wouldn't be doing so because
OLAF KOLKMAN: Which court? The US court.
MALCOLM HUTTY: In this case probably a Dutch court but that is by the by. Generally speaking operators obey and don't want to subvert the lawful authorities, and if the lawful authorities decide that this system is going to be used so as to prevent access and reachability of certain network resources, then you are not likely to override that by a positive statement of defiance but if you don't like the look of that or think that is a good way of lawful authorities going about enforcing the law then it's probably unwise to create a system that invites it.
SANDRA MURPHY: So you are suggesting a world where the Dutch government would do something in RIPE that an ISP in the Netherlands or an ISP in a different country would then be affected by it?
MALCOLM HUTTY: Say, for example, you have got some site that is alleged copyright infringement material and it's somewhere within the RIPE NCC region, let's say it's in somewhere like the Ukraine or Russia that has already expressed concern about ICANN having too much control over the Internet, and then you get copyright lawyers coming along to a Dutch court and saying I want to make use of the powers that you have under the copyright directive to issue an order to an intermediary to prevent the infringement to copyright, plus order the RIPE to prevent the infringement of copyright on that Internet resource, that network. And then that court order comes to the RIPE board and the RIPE board say, well, the only way I have of obeying that order is to deallocate the assignment and to issue a revocation certificate, reallocate it to the MPAA or the RIAA who are whoever is applying and issue them a certificate so it looks like the original site was a hijacker and the IRAA as genuine people.
SANDRA MURPHY: I am still following. You haven't got my question yet, whether the ISP that is obeying this rule is in the Netherlands or outside
MALCOLM HUTTY: Then, anyone that is relying on the certificates, would naturally, if they are relying on certificates generally, would see that there is a valid announcement here which ends up going to the MPAA and an invalid announcement, which goes to the people that it was really intended to be going to, and unless you put it in a local you presumably therefore, that would be effective at blocking access to that network. Now, would you white list that? Even if you knew about it, would your employer authorise you to white list that?
SANDRA MURPHY: I am curious as to the difference between the ISP being in the Netherlands or outside the Netherlands.
MALCOLM HUTTY: Yes, including outside the Netherlands. This is the thing. If it were just the Netherlands then actually the Dutch government could order to block access anyway but this is going to affect people across the whole of the Internet, anyone who is choosing to rely on those certificates.
SANDRA MURPHY: I am curious as to whether an ISP outside the Netherlands would be concerned about a court order inside the Netherlands. I don't know.
OLAF KOLKMAN: I think what Malcolm is saying, if you relying on the certificates automatically, you don't have any insight in why they have been changed. But that is something
SANDRA MURPHY: We are discussing the white list capability. And he is saying that the ISPs would be reluctant to white list because of an action of the Dutch court. And I am asking whether ISPs outside the Netherlands are concerned about Dutch court actions.
OLAF KOLKMAN: Or would a dutch ISP live up to a court order in the US, so a change in certificate in the ARIN region.
MALCOLM HUTTY: I am suggest
OLAF KOLKMAN: But I want to give Stephen and Sandy the opportunity to respond.
STEVEN KENT: I realise it's just an example but I think it's a really silly example and I point out I am trying to be polite reason is that we see, today, people in the law enforcement community going to DNS registrars to delist a site and getting pushed back when a lot of people on the site are not, in fact, the target of the court order in question. You are expanding this to killing an entire network. I find it hard to believe that that will be acceptable in most circumstances. I know of one case where this was done, it was the Pirate Bay case I advised people who were expert witnesses in that, and that one did work and did have them delisted but it worked only by going directly to the ISP in question because it turned out that the people in question were just using it as fake front, etc., and the court saw through that and the court said yes you have the technical ability, as the ISP, to block the traffic, it's in my country, we are going to do that because there is nothing but pirate based stuff on the network. The nor general case you are referring to, it's we started with an admission, I think, that you are speculating on what might happen. Now, we are speculating on an extreme case of incredible bad judgement that would happen if this other speculation turned out to be true. When we start talking about multiplying probabilities, you know how that works, they just get smaller. This
MALCOLM HUTTY: I think it's reasonable to put, for the sake of argument, the probability of widespread adoption and reliance at one, for the sake of argument, because if we are not considering the world in which this is when considering whether or not this is a good policy to get to try and reach, then you assume that that were to happen, and then you think, is that a good place to reach? And the mere fact that it might not happen, yes it might not.
STEVEN KENT: I am not making that argument, don't put words in my mouth, I am agreeing that we should be having discussion based on assumption that the RPKI, over a multi year period has a reasonable probability of becoming successful. That is not the argument we are having, Malcolm. We are having the argument of whether, subsequent to this, regulators in some part of the world, you are citing EU because this is one you are most familiar with, seize on this as an opportunity to shut down entire networks, which is questionable, and then you gave an example of there is an offending site on a network and unless that site is the only thing on that network I think it is a tremendous stretch to say we are going to wipe out everybody on that network and particularly the notion of redirecting the traffic.
MALCOLM HUTTY: You may think that this is such an awful outcome as to be completely implausible to the point of saying that my example was sillly.
STEVEN KENT: Yes.
MALCOLM HUTTY: In that case I think you are going to be disappointed when you see how close we already are.
STEVEN KENT: At the IGF meeting in Nairobi a few weeks ago I was watching legislators from various parts of the world talking about their desires for exerting greater control over the Internet, and while there were certainly some out lieers there, I watched them being laughed down by people from a variety of other countries, and actually criticised rather harshly in front of a large audience with international representation, so I have some confidence in
MALCOLM HUTTY: I was at the same meeting and I know some of the people doing the laughing but from places like EFF and other civil liberties campaigners...
STEVEN KENT: I am particularly thinking of the French ambassador who asked a Pakistani woman whether she gave this
OLAF KOLKMAN: Guys, we are rat holing on who said who in what context and what are speculative visions about what regulators will do. It's a difficult crystal ball. Let's try not to argue
MALCOLM HUTTY: Let's look at what the regulators have already done because at least we can be specific about that, and I don't have to be accused of speculation or black helicopters or anything of that sort of stuff when we talk about what has already been done. Now, the I made reference earlier to the copyright directive. There are other reasons why you might want to block access to certain material, copyright is a good example because it's already law across the European Union and creates broad bush powers for courts to issue these sorts of orders, that already exist. And they have existed since 2001, and for all that time we have assumed but surely those powers couldn't be used for this kind of thing because that would be far too ridiculous, wouldn't it, and it wouldn't be require ISPs to suddenly engage in wholesale network filtering on the basis of please stop an infringement from taking place. That is more than a court could do surely, it wouldn't be block access to sites because that is more there is no law that would support that, is there? And yet we have seen, recently, these powers being used for precisely that mechanism. So when you say that I am speculating about future laws that will be passed, no, I am not, I am pointing out that existing laws have been readapted to do the exactly this kind of thing in a slightly different space and all that would be needed would be to assume when they talk about intermediaries, it wasn't just referring to ISPs as intermediaries but also referring to Regional Internet Registries and that is a much lesser
STEVEN KENT: You are confusing sites and entire networks. I think that is inappropriate.
MALCOLM HUTTY: With regard to on line filtering in the /SPARPL case, which is admittedly under appeal at the moment, that was applying to entire networks.
SANDRA MURPHY: Do you see any reason to believe that that sort of expansion of regulatory power could not be used in the current system?
MALCOLM HUTTY: I am not promising
SANDRA MURPHY: Is that a yes or no?
MALCOLM HUTTY: I am not saying it;s certain with this or that I can promise that it won't happen any other way. What I am saying is that if this policy, if this approach makes it more likely that we move in that direction, that should be seriously considered and weighed in the balance as a reason we might want to be cautious about taking this approach and more important for to you show soiled, clear and harm that is being done to set against it rather than this looks like it might make things a bit Bert, there is serious reasons to think it might make things worse and it deserves to be taken seriously as a possibility.
OLAF KOLKMAN: I want to ask, still, a clarifying question, because this, still sort of relies this argument relies on the relying party blindably following what the issuing party does. Is that correct? That what I hear? You are saying that the relying party will not overwrite whatever happens by the issuing party, which I believe if I am not [freeze] misinformed, is always possible in this
STEVEN KENT: It is technically always possible but in fairness going back to our lunchtime conversation, there are two factors to consider: Is there a sufficiently effective essentially out of band communication capability among enough operators to [freeze] get the word out to say don't pay attention to this entry on the CRL because it's just RIPE being forced to do this by a Dutch court, for example. And the second question, and I am not sure what the answer to this is, is that earlier today, and in various other fora, Randy Bush pointed out that there is research to suggest that 70 percent of the ISPs out there are doing some form of default routing. Presumably, these are ISPs who are going to get their idea of what to believe from upstream providers and so the isn't whether tens of thousands of ISPs around the world have to act in this fashion; what is the subset of ISPs that would have to communicate and say, I am not going to pay attention to this and have this flow down to the others. I don't know the answer to that but I think that is another factor.
DAVID FREEDMAN: If you hand the track off
STEVEN KENT: If you are going to hand it off you are not merely playing the game.
MALCOLM HUTTY: I think that is fair. Of course it's highly possible that people will not just accept revocation certificates at all except on the basis checking each one man you willy very carefully, and based on what I am being told that vendors are building these tools and capability into their product lines and if that is the case they seem to be envisaging an automated world.
SPEAKER: The key concept is to be able to do immediate revocation in the case of malice, a number of things built into the system to try and reduce the likelihood that style information so the CRL, the revocation can come along and trample over what people have and you talk lifetimes for example. The thing about using the CRL for malicious, one assumes it's operational emergency you don't know if the NCC are forced to issue a revocation and to make it look like it was doing for genuine operational reason and not because a Dutch court had asked them to, how can you tell without communication method? We talked about things like having, you can have a distributed veto authority, that voteties CRLs as they come down, then that is an act of disobedience so how do you agree?
STEVEN KENT: I want to disagree with one detail. . The revocation capability is mostly not there to deal with malice, and it is not presumed to be instantaneous if you look at the standards there is a notion that they are going to be there is a frequency with which relying parties will query repositories to collect information. It certainly is not viewed as instantaneous.
MALCOLM HUTTY: I believe it's been discussed and Randy has had a presentation about what do we need to do in order to reduce the lifetimes, how do we instantaneously tell everybody that something bad is happening.
STEVEN KENT: I think you may be confusing with RPKI certificate lifetimes and frequent receive CRLs.
OLAF KOLKMAN: With that, obviously this is not conclusive, this kind of discussion, but I hope you have been exposed to a number of arguments. By the way, the use of unique acronyms, not the number, currently as counted Steve used 19 14, sorry, Sandy used eight, Malcolm used 12 and David used 10. We will keep on counting.
With that, I want to open the microphone. Alex, how much time do we have for this part.
ALEX BAND: Max, half an hour. People need to realise this session is over now but we are running over.
RANDY BUSH: IIJ. I agree with Malcolm, there are serious attacks on the system today by people who wear funny clothes and carry guns. Some of them were my students like Tara Kamal who pulled a plug in Egypt. They are doing it already. I am being attacked about two forces: Those people and people with fumble fingers. Doing RPKI, original validation will remove most of the latter and leave most of the former. Those people have guns, bombs, the courts and whatever they want to attack my system. You are foolish to think that any bit of technology is going to stop them. Right. As somebody said, we had static routing, go back to that and maybe a little more resilient against those people, although Tarac Kamell cut the frigging wires. They will do what they want to do. They have guns. Gate real. Hunt hunt is your network in the Netherlands? Because this is placing you not only under the existing set rush rush no matter where we are, it is the global Internet. There are RIRs that cover all the regions. I have networks in Asia and in the States and they will have the problem of people going to the Australian courts and the court in Virginia, and if you think you are worried about a Dutch court, you think about an American court. The problem isn't where the court is or that there is a court or that is an avenue of attack; this is the power structure, they bought our government. They own us. They will do whatever the fracking hell they want. I just want to stop the idiots.
(Applause)
OLAF KOLKMAN: Dave.
Dave Wilson: I take the point strongly about the risks of deploying RPKI and how that rigid infrastructure, if it turns out to be rigid, can be overtaken. I am trying, in making my own decisions, to balance this against the alternative nightmare scenario that I have; I mean, I worry. The picture I have, it comes from, I think, I first started hanging around RIPE when ICANN was being formed and domain names were properly being and it was a formative influence on me to the extent that I never wanted to see that happen here. I fear with the IPv4 run out that we are going to see it happen here soon. I fear that while we are look at the routing system today and go it's working well enough, we don't need to worry, past performance is not a guide to future performance in this instance. I am trying to balance and have not heard enough discussion for me to be able to do this, can anyone enlighten me as to what the risks are of not going ahead with this in a scenario where the motivation for hijacking IPv4 prefixes changes substantially?
OLAF KOLKMAN: Anybody on the panel?
SANDRA MURPHY: I think past performance in this particular case would indicate that without RPKI, we would have no defence against prefix hijacking. We seem to have no effective defence against it at the moment. The best current practices aren't being practiced.
DAVID FREEDMAN: We have as much as defence as we have deployment.
STEVEN KENT: Saying in the absence of RPKI so I defence relies on that perfect out of band communication system we were referring to earlier.
AUDIENCE SPEAKER: I want to add an observation and my observing was this whole discussion was not really about RPKI or anything, but it was about automatic route validation from an external database. And the thing is that this crypto thing we added up does not introduce any more security than we already have. It's just like there is a whole security that was introduced this by creating interface to the routers to automatically validate external routing information and I wonder whether someone has ever thought about building in RSPL to RPKI router interface, router protocol how is it called? anyways. If someone has built a proxy that translates RSPI data to RPKI router protocol and I think that would just like totally get the same result without even introducing any crypto add on.
STEVEN KENT: So I disagree with the characterisation if it's not any more secure. The RPKI because it builds into the certificates the allocations that come down through the hierarchy, says that whatever point you are in the hierarchy, you are constrained to do allocations from the addresses you have as determined by your parent and determined by that parent, as oppose toed IRR databases where you can make any assertion would you like, so it's better in that regard. With regard to your second question, actually software that we have available was open sourced as the opposite. It takes RPKI data and produces RPSL out of it so that you could use existing tools that you might have as an ISP and give it a higher priority so the other direction has been done.
AUDIENCE SPEAKER: I think.
DAVID FREEDMAN: Just to answer you, Steve, we are very lucky because we work and operate in the NCC service region and they have a great database. You look at some of the other regions and people that are forced to use RADB and can put anything in there. I think it's fair to say that as long as if you are a paying member that there isn't the same sort of validation that there is if you are an NCC LIR and you put stuff into the NCC database so we don't see the whole problem here because a lot of this has already been done for us.
AUDIENCE SPEAKER: I want to go back to Kent. You say that I can put random RSPL data, at least for RIPE that is not true. I can just only create route updates from my prefixes.
SANDRA MURPHY: That is true in the RIPE database that has employed the security system that was spec add long time ago. The other Regional Internet Registries see, I skipped an acronym do not always follow that same security system, RADB, which is not associated with a regional Internet register oh, no, no I don't even know what it stands for
STEVEN KENT: And your acronym count just went up by one so you better be careful.
SANDRA MURPHY: I heard him remark. has no way of authenticating the person making a registration that they are authoritative for the registration that they are making, so in those places, it's possible to do a registration of anything you want. And you will hear people talk about making proxy registrations for their customers, that is what they are talking about.
AUDIENCE SPEAKER: But that is, just to get back to that directly I can also set an out POP certificate authority that allows everyone to certificate anything, so that's no problem.
STEVEN KENT: That is the important difference. The browser certification authority model is severely broken because it allows to you do just what you said: Any trust anchor in there can configure a certificate for anything. The RPKI does not allow that. You are tightly constrained. That is one of the important differences.
AUDIENCE SPEAKER: How is that even possible because I can configure on my router what my Trust Anchor is right? I can use any trust and if I control
STEVEN KENT: That applies to you and no one else.
SANDRA MURPHY: That is the relying party.
STEVEN KENT: You are the relying party. You can believe as a relying party anything you wish. The security problem arises when you, as a certification authority, can convince other people to believe things that are inappropriate, which was Malcolm's example.
AUDIENCE SPEAKER: What then I said your argument is that the IRR data from other regions is just broken and not that is not as a security model, RIR data is broken and that is not an argument for RPKI but for fixing this IRR data security model.
SANDRA MURPHY: Well, OK, so one of the suggestions has been that the IRR data is not used now, so it would not be employed by regulators because it would not be effective. You are suggesting that we ought to improve the RIR data. Malcolm would you advise against improving the RIR data because it might then introduce the possibility of regulation? Should we direct the NCC to ensure that any variation in the data should remain?
MALCOLM HUTTY: I am not arguing against regulation. I am pointing out that creating a new degree of centralisation carries risks. The idea that we should be adopting RPKI, is being presented as this is a solution, please do this, without having gone through process of looking, really is there anything better. I think this community deserves to look at a much more basic level whether there is something else there would be, and I Daniel is about to take the microphone so I will quote it back at him: Good enough.
OLAF KOLKMAN: There is a long mike line and if we take five minutes for every discussion we will run over 6 o'clock. So I am going to move to the next person on the mic.
WILIFRIED WOEBER: I would like to start out with basic statement that my position would be to be continue with the RPKI as proposed just to digitally sign [freeze] the legitimate holder these of a piece of resource for a particular entity, just to get that out of the way.
The other thing which I'd like to double check with you here if my readings or feelings are correct and please correct me if I am wrong, I don't like this black and white thing that is going on at the panel here because I think we are looking for a technical solution to a problem. And usually we do not make reasonable progress by being 100 percent on that end of the stick or 100 percent on the other end of the stick, so my reading of this and my observation, and this is actually checking whether I am correct, is currently, the routing plain works as a mesh of mutual credibility, like you are sending me stuff, I am believing in the stuff, I am applying a couple of safeguards but other than that it's a mesh. That is more or less what it is now and that is pretty much resembles the PGP, the web of trust model. If we go into the direction with this RPKI as it is proposed to be implemented right now, and it's not an argument against the thing, against potentially the implementation, we are consciously and on purpose introducing a single point of failure and that is the source of the certificate about the rightful holdership of the resource. I don't want to go into details or discussions whether this can happen by accident, whether this can happen by a targeted attack, whether this can happen by interference by regulator, I really don't bother about the reasons but my reading right MoU is the way the we are going to go to hierarchal CA type model where single point of failure in the system and I would like to have anyone or awful you to set me right that my reading is wrong.
MALCOLM HUTTY: I wish you had been up here instead of me. I have talked about copyright attacks and things because that is what I know about. But it's more general than that.
WILIFRIED WOEBER: If sort of there is some sort of agreement that there might be a single point of failure in the system as it is proposed right now, wouldn't it be prudent to think about a different or better implementation where we remove that and I think think about one or two or three different approaches to do that which would be pretty simple but that is something for the techies to sort out, in general with a little bit of background in the security thingy, I don't like any single the points of failure and I think it was not the way the Internet was built from the very beginning.
(Applause)
SANDRA MURPHY: The Internet was built from the very beginning with a single point of address allocation and the address allocation system in the Internet has always been hierarchy I can. If you build a security system it's best to be built with respect to the authorities that are in the system. If you build something other, have some way of attesting to things that doesn't match the authorities that currently exist in the system, your system will not work well.
If you come up with a new address allocation system that is web of trust, you and three other guys agree on what addresses you are going to use and you find a way to make that work, then you can institute a security system to protect that, which is also web of trust, but as long as the address allocation system is hierarchy I can, you are not going to find a non hierarchical system for security protection that is works well.
OLAF KOLKMAN: Another way of phrasing the question that Wilifred just asked is, would you what you just explained is that the registration authority for the RPKI actually matches to the IRSes, what is sort of logical, you have the RPKI and going to apply it to routing and go from the hierarchical address assignment to peer to peer gossip world and how is that matched? I think that is the rephrase of the question, isn't it?
RANDY BUSH: Daniel has yielded me one minute. Two attacks, one is the attack on operational infrastructure. I and a bunch of others are working on approaches similar to what happens in DNS with Anycast blah blah blah. There are ways to run the so there is no single point of failure. The second is the attack on the cert hierarchiy itself, you have that same problem in the DNS signature structure, the IANAs got documents being generated with key signing blah blahs and all those ceremonies, etc., and Steve can certainly bore you to death mother than I can on that subject. I will bore you with the operation.
STEVEN KENT: I am flattered. The observation is that in the DNSSEC and with regard to address allocation, there are hierarchy I can real world organisational models and the PKIs, because is a PKI, parallel those, any time anyone tries to build a large scale PKI in which you bring in third parties who are not authoritative and trust them, bad things happen. The browser PKI model being one of the great examples we can see from today. So, if there is a good way to make that transition from yes, we know who have the resources based on exactly the people who are in charge of that using their databases, to what are we going to do with regard to further information disnation, I am all in favour of hearing this. People have worked on this for over a decade, this was the decision we came to about thousand do it.
OLAF KOLKMAN: Move back to the mic.
AUDIENCE SPEAKER: I don't want to repeat Wilifred, whom I fully agree. I also agreed fully it is easier to turn power off, but I wanted to say about two risks you missed in the discussion: One is human mistake. In the system with one single failure, point it's a problem. Secondly, that we will behaviour national governments because to be fair in these situations, resources from outside and we will initiate the are creation of national RIRs. It's the most predictable way. And it's simply lack of provocation sorry, I'll speak about the situation with full automation. In full automated system, it's absolutely predictable.
MALCOLM HUTTY: I think that is a very good point. I take the point about the, that you are making about the hierarchical nature of allocation but it's not but I don't entirely agree with it. In given that IP addresses have to be globally unique, we have actually in the way the Internet is currently organised, constructed about and decentralised non hierarchical system as it's possible to be while still maintaining global uniqueness. Staying there is still a certain element of hierarchy in it is not really a good reason for saying well, let's move and increase that dramatically, as Wilifred was say, you know, we have actually in the design of the Internet tried to avoid it wherever possible, not tried to create it where it does not need to exist.
SANDRA MURPHY: Could you say what you see as non hierarchy I can about the current address allocation system.
MALCOLM HUTTY: For example, the routing decisions at the moment separated from the allocation of addresses. That is not a fee that you are it any system needs to have. That is a separation as to keep that hierarchical nature in its box and put a tight ring around around it rather than expanding it out generally.
DAVID FREEDMAN: The routing makes that I stated earlier that that bridge is rather weak and the adoption isn't high.
SANDRA MURPHY: So you are not saying that the address allocation system is non hierarchic; you are saying that the routing system is
MALCOLM HUTTY: What I am saying is that the design generally is to try and minimise the impact of the hierarchical nature and to try and keep away from a hierarchical nature and rather than so you cut it's not really a good argument to say, well, we have a limited amount of hierarchy here therefore it's fine to expand it into this other area.
SANDRA MURPHY: All the best current models practices that exist right now for protecting routing, aside from things like max filters, assume trust model is that the prefix holder is the one who is allowed to speak for the origination, that is what ties the address allocation system to the routing. If you want to expand that, understand that this the best current practices have been in place for however long the RPSL database, which is about as long as RIPE, you are saying are you disputing that those things should be in place because they marry this hierarchical allocation system with routing?
OLAF KOLKMAN: Short answer.
MALCOLM HUTTY: I am getting seriously technically out of my depth, I would rather Wilifred took this, but I would say that the creating hierarchy, creates opportunities for power and that is in the area where I know better than some other people, that some of these ideas are not silly. So I would rather not get into an area that I know less about, I know those threats are not silly and allow Wilifred to take the point and argue the argument about why it is a bad idea to expand single points of failure. He can do it much better than me.
OLAF KOLKMAN: There was somebody who wanted to respond to the points made.
AUDIENCE SPEAKER: One word /TKEUPBLG know at that.
OLAF KOLKMAN: I didn't want to bring up the D word. Wilifred.
WILIFRIED WOEBER: First of all, for the technical aspect, for the lack of address space, there is no hierarchy.
SANDRA MURPHY: Absolutely incorrect.
WILIFRIED WOEBER: There is IANA but the distribution of not hierarchical, it was coming from one place, but it there was no hierarchy. The only hierarchy that does exist in /S* in the provider aggregatable space. All the other stuff is coming from one entity which is earmarked to be the guardian of the big block of unused addresses. The reality that we have in the regional registry system, is we have got five of them. We are operating at the same layer and underneath these five things there is, for some aaddress space there is some hierarchy, but just claiming there is just hierarchy and nothing else, is just simply wrong. It's not the reality.
STEVEN KENT: The reality is that IANA allocates all address space, it hierarchically assigns it today through RIRs who then sub allocate to LIRs, etc., and when John past he will was handing it out he was the route as Sandy noted, so, no, it really always has been. And to respond to your point, Malcolm, we are not creating a new hierarchy; we are just modelling it exactly on the one that exists, not creating a new one.
SANDRA MURPHY: There were no other sources than IANA for addresses. That is one point that makes it a hierarchy, not a web of trust.
MALCOLM HUTTY: This is getting a little sterile. The fact is that numerous people were concerned that this is creating a change in the power relationship.
OLAF KOLKMAN: I think that this is that the debate that I am just hearing is it doesn't the allocation hierarchy, the way that addresses are handed out, is hierarchical, and I think everybody agrees that BGP is a gossip protocol, peer to peer gossip protocol and the concerns are that when you bring that hierarchical structure into routing, that something happens. That is how I sort of hear your concerns, Malcolm. And with that summary, I want to go
DANIEL KARRENBERG: I am the networker for this purpose. And actually, if the sole discussion only brings out this fact, that we are actually talking about a clash of two par dimes, one being the hierarchical one and actually I agree with Wilifred, absolutely, the part of the address allocation called hierarchy had one route and one layer beneath it and I don't think that's distinguishable from a non hierarchical system other than formally. But never mind. The main point, and it's been said a couple of times, what we are witnessing is on the one hand, a hierarchy structure, on the other hand a gossip structure or what I would prefer to call it, a structure of autonomous systems, autonomous actors working together with their neighbours to keep the system working, and of course that is a clash, and if this discussion makes only this one clear, then I think it has served a purpose. And what one can my conclusion from this is, that what we need to do is to merge the two a little bit or bring them closing to each other, make the hierarchical RPKI a little less hierarchical and it has some benefits but it also has some drew backs and the whole discussion was about the drawbacks, or much of it, so we need to see what kind of mechanisms we need to bring them closer together.
In that regard, and my question to the panel would be. . What could these mechanisms be? My hint is, and Dr. Kent has already mentioned it, is like out of band communication channels about reasons for revocations and actions by RIRs and so on, but one can maybe even think about it a little more; it doesn't need to go into a totally unorganised web of trust, there could be some other mechanisms in there. And one thing that actually might be quite inspirational, to think about a concept that I heard exposed at this year's black hath conference, the concept of trustability, I think one of the things that is happening here in this clash, if you call it a clash, is there is also some fear to be stuck, to be stuck with the RIRs as source of the only source of actually getting a useful RPKI mechanism. And of course, because the RIRs are in the allocation hierarchy, that is the natural thing to do, and I would hope that over here, we trust the RIRs per se, so all this argument goes about how the RIRs could be coerced to do stuff that they wouldn't do if we were just calling the shots here. So we need to actually look for things that make that more palatable and trust agility is one of the things, who do I have to invest my trust in? Can I withdraw it and move around that, kind of stuff. Might be something that helps us here. But I think we have to find a little bit more of coming towards each other from this hierarchical and this mesh of autonomous actors and I think if we can find some of these things and I would ask the panel what they would see as mechanisms to bring those closer together, then I think we are making progress. And sorry for this being so long, I am just tired.
OLAF KOLKMAN: In order to make sure that we sort of keep the time limit, I want to give everybody on the mic to give their comments and then we go back to the panel one more time and everybody can respond to the points that were brought up and we close and we hand out the prize. Forget that.
FERGAL CUNNINGHAM: I have a comment from John Curran. A government could order an RIR to reassign address space and for many ISPs this would impact availability. Can the panel describe how an order changing RPKI meaningfully differs in risk?
SANDRA MURPHY: So
OLAF KOLKMAN: Hold that thought.
WILIFRIED WOEBER: Wilifred's comment
RUEDIGER VOLK: Dutch telecom. I would like to point to some advantage in RPKI that I am not seeing in other approaches that are known for improving routing security based on some common database, some data collection that can be applied automatically. In general, I think kind of the requirement of somehow managing a database of trust worth data and merging this automatically into the router operation is kind of what is generically needed. And well, OK, the thing that I am seeing is that, well, OK, if the operation of a database actually can be monitored in detail, independently, the threat of people mucking around with the data or someone actually failing having a failure in the operation, can be mediated to some extent, and the design of the RPKI has this repository thing in, which essentially means that all what all that happens in the RPKI is actually visible to everybody and the technology that is used for distributing the stuff can be also used, of course, to archive and track stuff, then maybe additional enhancements that can be done by adding more information about what transactions are happening and what they mean, and make camouflaging interesting stuff, even harder; the question from Steve, well, OK, what out of band mechanism do we need potentially for relying parties to modify the stuff that comes automatically out of the system, of course still apply, and people who have concerns that things can go wrong, probably will have to invest something in getting tools and infrastructure for this, and that hasn't been investigated in full. That is what I think. But I think there is potential and I don't see anything of the kind in all the known other systems, in particular it is absolutely out of question for RPSL.
OLAF KOLKMAN: If I may summarise what you have just said, I think something that Daniel basically brought up: That is a way to provide more trust agility in the system?
Des Ray: I just have one quick comment, trying to understand a little bit more whether I understand the panel in saying is nobody is saying there should be single technologies solution as a single route, that that is not necessarily where this is aiming to, and secondly, I think it's a difficult discussion because we haven't really explored all the ramifications from a policy and match the RPKI solution as to how the world functions and matched it against some of the geopolitical realities, so lastly, I would like to know from any of the panelist ifs they think that the adoption of the RPKI certificates would, if it's introduced on voluntary basis, would they believe that would always stay as a voluntary basis? Thank you.
JIM REID: Just some random guy off the street.
OLAF KOLKMAN: Not so random.
JIM REID: I think so, anyway. Understandably a lot of focus here on this potential for RPKI to be a vector for control purposes and things of that nature, but I think there is some other characteristics that perhaps need to be considered or thought about, too, and this takes off into slightly different plain and I apologies but I want to mention these out loud:
We are probably going to be using this certificates at some point in the future to facilitate transfer of trading on a rest space. Does that the look and feel of a cartel? Another question in a similar vein to that: If ISPs are using these secure routing statistics to make decisions who they peer are or how they peer with them or if it becomes a badge of entry for being able to get access at particular Internet Internet Exchange point does that not become a barrier to entry. Randy has just said no and no.
OLAF KOLKMAN: Two times no and no. I close the mic lines, I am sorry for that, we are running out of time.
AUDIENCE SPEAKER: Two words. I mean about hierarchical system, IANA has control for distribution of this space but not control for controlling the other space. It can't to say this other space from this technology, IANA adopts control over the other space.
SPEAKER: That is 34 words.
OLAF KOLKMAN: The lines are closed. I hope that somebody parsed the question that John Curran asked, give opportunity an opportunity speak to what you heard.
DAVID FREEDMAN: John talked about having a government come in and ask an RIR now to pull a registration and what the difference there is. Well, I think there is a similar answer in the case of people filtering now, that would effect them now. If they are not filtering, it won't affect them at all. Except, one interesting point I must make: the NCC, when they pull if they remove a registration for some reason, I have seen recently and now suggest they are going to contact up streams and inform them a hijacking has taken place. Does somebody want to tell me that is wrong? Because I have certainly seen that in literature now. So maybe it will affect some people, maybe if the registry is forced to contact the carrier networks in the middle.
SANDRA MURPHY: It's my understanding that if an address allocation is pulled the reverse DNS entry is also pulled. The further step Randy is saying is if they pull address space, they can reallocate to someone else, which is an even greater impact because someone else is using your address.
SPEAKER: It's similar but it's as you start adding more it becomes more. Pulling does affect the reachability to a certain degree but maybe not that much, in most cases. Reallocating it to somebody else will impact the reachability more because some of that space that is being reallocated will be used...
DAVID FREEDMAN: And the new owner won't be too happy.
MALCOLM HUTTY: And if we are in a world where people are relying on certificate validating certificates to determine hijacks, then the impact will be that much more; so it's progressive.
SANDRA MURPHY: So I think John Curran asked the panel to suggest whether, to compare address pulling to RPKI stuff.
MALCOLM HUTTY: At the moment, when the man that does turn up to RIPE meetings from a law enforcement agency asks why don't you do this, can do you this for me please? he is willing to be persuaded that this is not an effective means of going about what he wants and it seems to me that it's that would become progressively harder sell as it would become progressively more effective.
SANDRA MURPHY: I will ask the question that I asked before: The reason why it's not effective now is people's lack of use because of the data not being consistent and complete. Would you then say that making the RPSL data consistent and complete introduced risk?
MALCOLM HUTTY: I am going to pass that to somebody more technical.
Okay, they say it will. I believe that. Can I say I am being cast as the person that doesn't want this to happen and I see people nodding at me. That is not really what I am about here. I am pointing out that there are bigger issues that maybe if we don't just look at here is the solution as being prepackaged and I have been working on it for ten years and have an open mind, we might be able to bring in this trust agility that was being spoken and get to a better outcome, and that is really where I am coming from. I am trying tone courage the community to look at a broader set of things rather than things just relevant to the precise solution on the table at the moment because that might be too limiting and it it might be better to look tattoo broadly.
OLAF KOLKMAN: Take those as your final words and then ask Dave, Sandy and Stev for their final words.
DAVID FREEDMAN: There are a number of other points that haven't been addressed so when Daniel and Rudiger stood up and Desiree stood up. I want to say to Desiree, you talked, and Jim to a certain extent, all of these potential investigations that haven't been done. I take it you are volunteering to do them for us? I would find the results quite interesting. On the case of trust agility as an operator, it would be great if somebody could tell me if I have a community supporting me to tell me don't listen to this and don't do this. If my vendor makes it easy for me to put those in place without too much work, I'll do that as well. Ultimately it comes down to understanding the reason why I need to override and how easy that is for me and at the moment we don't know that, we don't know what implementation, we don't have a vendor, we have an empty chair. We don't know how easy it's going to make it for us. Those are my final words.
SANDRA MURPHY: There are two parts to this problem: There is the attestation that someone legitimately holds the prefix space. I maintain that the address allocation system is hierarchic at the moment. There is only one particular place that everything comes from, that is IANA, that makes it hierarchy. There is no web of trust exchange of addresses. That is one part of it. Then, comes the tie to the routing system, and right now the trust model that we are working from, is that the prefix holder is the one who is authorised to speak for an origin origination of a route to the prefix. This actually is the trust model that is used in the best current practices that, as a community, the operators have been using, for a very long time, all the RPSL database, all the filter your customers, all the build route filters depend on the idea that the person who holds the prefix is the one who decides where the origination should come from. This is not a new trust model; it is the existing trust model, and it's the one that is encapsulated in the tie between the RPKI and the routing system.
STEVEN KENT: I certainly agree with the points that Sandy made. I observed that, based on what a number of people have said, the current IRR database is viewed as unreliable, it's certainly most reliable here in the RIPE region and yet still not perfect, and most many of the observations that have been made basically say if we get a better version of this, then it represents a point of control. Whether it's the RPKI or IRR done by every one of the other RIRs or whatever, we create an opportunity for control. Yes. So maybe that is the price you pay for having decent data out there, is that you do control these points that people could attack and we when people talk about things like might someone in the future, one of the last speakers at the mike, said could use of the RPKI become a price of admission to Internet Exchange point; sure, I know of ISPs who have told me if people don't maintain their IRR data to their standards, they won't peer with them. The A in autonomous system, I believe people really believe that and this isn't changeing that; it's giving you another source of data, the scenario has been put forth it it becomes good and it's it creates some potential new problems. I agree with Malcolm, it does, people should make conscious decisions based on that. We don't want to get in a fear among erring situation however, because we don't know what they will be. They could vary all over the map although I admit there are potential bad paths for this. If we want to live with what we have got today, that is easy to do. If we want to do something better this is one approach put forth. I have been dealing with routing security technology for a long time. I have seen lots of papers published about this. They all have various levels of problems and none of them has gone successfully through a standard process and had all the details for housekeeping worked out. This is at this time only data in time that is comprehensive and can be understood well enough to throw bricks at.
DAVID FREEDMAN: Just one layer to this, we are only talking about original authority ration, we are not talking about path validation. When we talk about hijacking, if you have got a tight coming between the resource and somebody else just originates the prefix from the ASs, it's authorised to come from and the same result ensues. So look at the argument we are having now about original validation, think what is going to happen when it becomes path validation.
OLAF KOLKMAN: Which is a topic on itself, and we are run out of time. I would like to thank the panelists and of course the box was only sort of incentive to use less acronyms and you all get the prize because I didn't think that somebody would keep a count, actually. I am going to give my final thoughts I am not going to give my final thoughts because I am not supposed to have any, and it's very easy I don't have any, but this has given, hopefully, enough food for thought for the coming days and I hope it brings wisdom to whoever it be at the AGM on Wednesday. And with that, a final thing is that five minutes ago now, so that is, say, 6:25, a session in the next room will start. So you have time to go to the toilet, unless you all go at once because then you have to stand in line. Thank you for that, and enjoy the rest of your evening.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES RPR
DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.
WWW.DCR.IE
1