IGF 2010
Vilnius, Lithuania
14 September 10
Session 158
0900
ICANN



Note: The following is the output of the real-time captioning taken during Fifth Meeting of the IGF, in Vilnius. Although it is largely accurate, in some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but should not be treated as an authoritative record.

********

>> MILTON MUELLER:  Welcome, everybody.  This is the Session 158.  And let me welcome you and apologize for the initial delay.  My name is Milton Mueller.  I'm at Syracuse University and --

>> (off microphone)

>> MILTON MUELLER:  And we are addressing an important issue here, that is the Routing and Resource Certification: Self-governance and security at the core of Internet operations .   Potentially very technical issue, basically a lot of additional discussion and information is necessary for people to understand this.  To explain the format of our workshop today, a And because we have broken down this two-hour workshop into the format that we hope will make the information come out and be more accessible to you, there will be plenty of opportunity for discussion.
I'll just briefly introduce you to the -- the panelists.  We have a good mix of people from registries to policy analysts, so we're trying to merge technology and policy here.  We have John Curran, and Andrei Robachevsky and Dmitry Burkov, all of them associated with an RIR, although having other affiliations as well.  We have Danny McPherson who used to be with -- well, still is with the Internet Architecture Board.  Brenden Kuerbis is with the Internet Governance Project and Andrea Glorioso is with the European Commission, the director on the Network and Information Society.  And she also is coming at it from a policy perspective.  So let's begin with the presentations, and we'll start with John Curran.

>> JOHN CURRAN: Thank you very much.  I have just a couple of slides that I will go through, sort of summarize the issues, sort of how RPKI works, and I'm going to ask -- I look around the audience and I actually see many people more technical than I in this field, not just a few.  So I'm going to ask -- I'm going to give apologies in advance, a simplification I've done.  I've tried to be true to what happens with RPKI, but at the same time simplified it enough so everyone can participate in the discussion.
So the resource functionality, RPKI resources RPKI functionality.  What you get with RPKI is the ability to create digital certificates that correspond to number resource blocks, address blocks, that the registries have issued to various parties.  So if you received an address block from a Regional Internet Registry, this now gives you a digital certificate, which is appropriately named, which corresponds to that block.
So as the holder of that address block you now have a certificate, which you control, which lets you say, I'm the authority for that block.  I've been assigned that block.  So user who has address block JKL or some number, network 192.X.Y.Z, has the corresponding certificate.
Now, you can use those certificates to sign what we call a routing authorization, and a routing authorization is something that says it's my address space and I need an ISP to announce it to the Internet, so Internet traffic comes to me.  What ISPs do I allow to connect me to the Internet?  And that's a routing authorization.
So the user signed a record that says, service provider ABC is my service provider and can connect me to the Internet, and you sign that with your certificate, using digital certificate technology, what we all -- we all know how this works and allows you to sign things and it's fairly secure technology.  So you take your address block, you take your certificate that corresponds to your address block and you sign a routing announcement authorization that says, here are the -- here's the provider or providers who can announce me to the Internet and then RPKI technology also has to publish those.  You take those and publish them in a way that can be found readily on the Internet by service providers.  So a service provider can look up your certificate public information and your routing announcement and your routing announcement authorization and see who was allowed to connect you to the Internet.  So it allows an organisation that has an address block to say what service providers can connect to that, and it's visible publicly.
So here's where the functionality really gets good.  Networks that get routing announcements from other networks can now, first time ever, rather than taking the validity at face value, can now look up your public certificate, the right authorization and say, did I get this from the entity, the service provider, that you said you've authorized to connect you to the Internet?  So for the first time ever we've given a service provider the ability to get some information how valid this route is and not just from whoever he got it from, but from a source that originates with the address block holder, it originates with you because it's signed with a certificate that you got from that address block.  And the net result is that this allows us to prevent inadvertent and intentional hijacking of specific users' network traffic by unauthorized networks.  
When you say only networks X and Y can connect me to the Internet, a network which isn't X or Y that attempts to route your traffic and say it's serving you will not be believed by someone following RPKI technology.  So it provides end user specified control over who's going to announce them to the Internet.  And this is not something that's without need.  We have inadvertently had on many indications networks announce -- networks announced by the wrong service provider.  We think the large majority of those is typos.  Someone makes a mistake in configuration, but there's nothing to prevent it from happening intentionally as a malicious act.  So this is functionality we're talking about.
Now, what I was asked by Milton when we were merging through the IGF process, we were merging workshops, and I realized that this one was about policy implications of RPKI, I have to admit I was a little thrown because I sort of scratched my head and said, that's like asking implications of screwdrivers and wrenches, but I guess it makes sense.  But let me sort of scratch my head and say, this technology already has a public policy already.  It's developed by the IETF, the SIDR working group, not to be confused with the other SIDR working group of the past.  The SIDR working group with RPKI has produced dozens of Internet drafts and they've been commented on many, many times and can be commented on by anyone, and, in fact, that's why their version numbers climb up into the high numbers, because they do get commented on.
So this is -- this says I already have an open technology to the process itself, and the RPKI certificates is an optional service that the RPKI is looking at offering because service providers and users are asking for it.  This is not a mandatory service.  No one is saying you have to secure it.  It's saying you can.  You can have this additional functionality.  The data that's involved is the data that's already public.  It's the date in the directory of who has what blocks and the various routing registries, only now we're offering it with a higher degree of credibility.  So we're not talking about new data that can't be seen today.
And someone said, well, we need to talk about this quickly because deployment is already happening and there hasn't been consultation and that really threw me because deployment is going to start not only after the RIRs issue certificates but after they sign to say certificates to provide and providers begin validating about that and that's probably going to take, probably months and months before it really catches on.
I guess the most important part is service providers today decide what routes to believe.  Service providers look at who has database, tune by hand, third parties they download filterless from.  Filterless they develop.  They already decide what routes to choose over what other routes, what routes to drop, and they have a lot of tools to give them input as to how to do that.  This doesn't control the Internet.  This is one more set of attributes that can be used to weight and filter your routing and hopefully one that's a higher assurance one that provides you a stronger validity, but at the end of the day each service provider decides what's in their routing table, and they determine whether or not they're going to put any credence in this and what level of weight to give it.
So the policy implications of this, if truly we're saying there's policy implications here, then if there's policy implications to every ISP builds its own routing table globally.  That's a pretty interesting can to open up.  This is one more tool for ISPs to do their job and hopefully it's one that will help lead to a better Internet.  That concludes my presentation.
(Applause)

>> JOHN: Our next presenter is Brenden Kuerbis of the Internet Governance Project.

>> BRENDEN KUERBIS: Thanks, John.

>> By the way, the sound quality from my perspective is absolutely dreadful in this building.  Can people hear what's being said?

>> BRENDEN KUERBIS: If I stand very close to the microphone, is that better?

>> Better.

>> BRENDEN KUERBIS: Thank you, John.  My comments are going to be based on a recently released paper from the Internet Governance Project.  It's available at the IGP blog and I encourage you to read it, respond to it, give feedback.
We identify and analyze four distinct governance issues that we feel are raised by RPKI's design and the implementation of it.  The governance issues meaning that the choices alter the distribution of power and/or the distribution of the costs and the benefits among the relative -- relevant institutions.  The four points in the brief are, RPKI could challenge the autonomy of ISPs, RPKI requires trade-off to be made and simplified global compatibility and central position of power.  RPKI affects the policies and business models of the RIRs.  RPKI provides some important lessons about the role of governments, nation-states and Internet Governance.  That's the first point.  Autonomy of ISPs.  
The Internet has evolved in a way that attaches responsibility for address validation from address responsibility for routing.  RIR register and address block assignments in order to keep them unique.  ISPs use it -- Internet ISPs control what routes they announce and they decide for themselves which other ISP routing announcements they trust or filter.
Indeed, the RIRs authority over address usage itself, it's almost completely a byproduct of the network operator's willingness to use their registries as coordination tools.  And RPKI changes that, potentially.  As stated by members of the technical community, RIRs direct operational impact on routing.  One of the key governance issues concerns the terms and conditions under which certificates would be revoked, potentially impacting routing allocated space.  Concerns have been expressed about the length of certificate validity, the length of certificate revocation to RIR member status and the reluctance to use resource certification if they have reasons to fear that routing may stop doing that.  Clearly RPKI diminishes the autonomy of ISPs.  It can be used to replace a network (off microphone) based on choices among ISPs with a hierarchical governance.
The second point, trust model and global (off microphone).  If RPKI has the potential to centralize power, the next key issue comes, where is this power centralized.  In particular, what organisation or institute serves as the root-level trust anchor for the certificate hierarchy.  Insofar as a centralized -- insofar as one uses a centralized strictly hierarchal trust model for RPKI, one is also creating the potential for centralizing political and regulatory authority over Internet routing.  You've already seen this drama play out in the hierarchal domain space, with responsibility of power at the DNS root has been expanded to respond to other economic plans and political objectives.  Is it desirable to move that type of centralization over routing in an attempt to make it technically as simple and unambiguous as possible?  
The working group recognized the political and governance issues of such in architecture, noting the potential and the possibility for parties to use a diverse set of trust anchors.  More colorfully this was referred to as the RPKI's get-out-of-jail-free card.  The RIR and (off microphone) both issued statements supporting trust anchor for RPKI, while noting that the reliant parties could choose their own trust anchor.  However both statements failed to explain how support for a single root is consistent with the ability of ISPs to choose their own trust anchor.  
The third point, future of the RIRs.  RPKI puts the RIRs in the centre of many Internet Governance issues by dramatically expanding their authority over Internet resources.  In addition to routing security benefits, a fully functional globally compatible RPKI system could act as an effective property title for ISP blocks, facilitating the smooth transfer of IPP 4, address resources from one party to another, after the (off microphone) is depleted.  However, getting such a system in place requires huge changes in the procedures and policies of the RIRs.  Depending on the policies adopted, such an implementation could introduce healthy competitive pressures among the RIRs or it could foreclose such competition.  
By creating a system, such a system, by creating a system requires -- but creating such a system requires widespread adoption and use of RPKI, and more importantly, it requires verifying the identity of existing resource holders, the validity of the assignments and the allocations and the issuance of a certificate.  This auditing process, and particularly the possibility that an RIR might have to revoke resources requires the development of revocation policies.  The issue becomes particularly thorny when considering legacy holders of the IPv4 address blocks, where RIRs are not in a position to certificate or approve validity of their address holdings.  Widespread adoption of RPKI and validation would raise other questions.  For instance, should certificates -- certification be contingent upon payment of membership fees.  
If RPKI and route origin validation was a widely adopted practice, memberships in RIRs would be compulsory and fees a monopoly tax rather than a membership payment for voluntarily selected services.  Another question is could the resource -- it has been noted, excuse me, that the absence of competition among address allocation authorities with regard to resource certification would make it difficult for businesses to -- for them -- for businesses to accept them as group certificate authorities.  Competition could provide a form of accountability lacking in this case, unless the RPKI regime allows anyone to certificate resources, not just the RIRs.  Introducing competition among the RIRs providers of services related to address holdings, for instance, in the case of certificates, would alleviate many of these concerns.  
And finally, the role of governments in Internet Governance.  Previously mentioned -- I previously mentioned RPKI's potential to centralize authority and how that could provide a target for regulatory action.  The history of RPKI provides insight into more subtly the history of RPKI provides insight into a newer more Internet-specific role that governments play in nongovernmental Internet Governance institutions.  In this case we've seen the U.S. government has succeeded in participating and shaping the bottom-up standards and policy development process at the IETF and the RIRs, by contracting with science and researchers to do research on the relevant standards and then interact more or less as peers with other participants in the development process.  A model is not ideal but it seems superior, far superior to more bureaucratic hierarchal oversight or models we see in other Internet Governance institutions.  Thank you.
(Applause)

>> It looks like you want to say something.  How about two minutes?  Can you --

>> Thank you.

>> We have a whole panel to respond here, so --

>> Understood.  I'll take the two minutes only because as the one who introduced the intro to the topic I felt fair, I have some chance to respond.  I want to point out again with respect to the information we're talking about, there already are databases run by the RIR.  Who is the databases and routing registries that contain this information that, in fact, policies in many RIRs for revocation already exist, which eliminate someone holding of a resource and therefore the entries in these databases.  We're really talking about one more way of propagating the same information.  We're not talking about new business practices or new tools.  It's new technology, but it's the same business practices and processes.  When you lose a resource, you would lose the entry and obviously the certificate that follows.  
So I will take, I guess, some difference of opinion with Brenden on the fact that this represents a new business model.  It's not really that different.  Only one other little point.  This is all voluntary, okay?  To the extent that an ISP worries about its certificate, it's because it decided to use RPKI, decided to participate in that process, have its blocks signed with (off microphone) where an end user decided that.  So an end user decides not to participate has no concern about any of this.  So I'm a little bit confused about the centralization of power since it's a voluntary question about whether or not you wish to use the RPKI certificate system at all.
The last point on the role of government.  I probably won't comment on other than to say we've seen significant end users in this discussion who are concerned about their address space how it's routed for security.  And I imagine the U.S. government is one of those parties, just like the others at the table who don't want to have their routing hijacked.

>> Now we'd like to ask our respondents to come up to the table and have Brenden and John go to that table.  This is meant to provide excitement in this kind of a.... want to go down the row?

>> I'm David.  Start from the left to the right?

>> Each of you has about 8 minutes or so to make a response and then there will be plenty of opportunities for inter-exchanges.

>> ANDREI ROBACHEVSKY: My name is Andrei Robachevsky.  I'm the TPO of the (off microphone).  One thing I would like to know, it might be confusing if we provide equivalence between RPKI and routing security.  I think RPKI, if you look at this, that's another way of exposing the allocation registry that areas are maintaining, so it's cryptographic in a more transparent way of exposing this allocation registry in the global skill.  Now, how this tool is going to be used and what it's -- and how it's going to be used in routing security, that's a separate question.  What is confusing, if we can see the routing security in RPKI and issues related to RPKI routing security in the same context.  I think that difference needs to be considered separately.
Let me just give you an example, for instance.  Certification of resources follows the allocation policy.  It's not the other way around.  So if resource is removed from the registry, then subsequently a certificate is going to be removed.  It follows that revocation of certificate doesn't exist without reclaiming the address space.
If we go to the security area, I think this tool can be used in different ways.  The fact that RPKI is hierarchical doesn't mean that in routing space and routing security would have to apply the same principles.  In fact, if you look at the IETF, you can see that RPKI, the certification of Internet resources, is a tool that might flag a preference of a certain rule for ISPs that participate in this activity.
So just to finalize, my point is that RPKI is no different from the existing practice of global registry and current application of RPKI technology in the routing security does make routing security more fragile and doesn't change it much from the existing practices that are applied now by the ISPs.  At the same time, it makes it more transparent, more secure and more technologically applicable.  Thank you.

>> Thank you very much.  That was short.

>> Hello, my name is Andrew (off microphone).  I work at the European Commission so I guess that makes me a top bureaucrat.  The European Commission has been interested for quite some time in security and the policy implications of security.  We have been quite heavily involved in the discussions around (off microphone) and we're trying to understand whether we should get involved in the discussion around RPKI, routing RPKI (off microphone).  I'm not going to discuss the technical details since there are people here much better suited.  I'd like to raise some points which perhaps in the discussions and especially in the discussion of the technical community, do not always come out clearly.  So one said before that technology is neutral.  Personally I don't think so.  Technology generates power, and public authority have to take care of that, have to understand how a particular technology changes the power, and from that perspective (off microphone).  I need to understand where a particular technology will be good or will be bad for the European Union.  That's my job.
I acknowledge also that this is something that -- I'm not sure it has been raised strong enough that RPKI does not (off microphone) the unite.  The European community network security agency has recently run a survey, a quite well done survey, and it's publicly available if you want to read it.  They (off microphone) interviews with the tech part of the community.  It was striking to me to notice that many of the jobs that people of the commission heard about, this particular technology, (off microphone) possession of power, in terms of what would be the role of the registries, would it change, what would be the added complexity to the system and what would be the security implications of the complex, were raised also by the technical people.  So I'd say it's not only fear of bureaucrats.
It has been also mentioned that there is also -- there is already a discussion process ongoing at the (off microphone) IETF.  This is absolutely correct.  However, I'd like to stress that the IETF works according to certain rules, one of which is almost total openness, which is very good for the IETF.  It makes sometimes very complicated for servants or public authorities to participate because whether we like it or not, public authorities do not always work in a full openness mode.  Personally I believe that the technical community doesn't either, just that they are (off microphone) a lot to gain (off microphone) always very open, except decisions by the technical community (off microphone).  
But the point is that if there is an interest by the technical community to have opinion of public authorities and -- this is something I should have mentioned, coming from the technical community and working on as bureaucrats, the interest of the technical community to evolve public authorities as early as possible because public authorities have this very bad habit of having reaction very late in the process.  Then they see that something is happening, perhaps (off microphone) and then (inaudible) because that's the kind of distinction (off microphone) reaction of public authorities.  
So the question is how -- the first question is, did the people that participate in this process involve public authorities early enough.  I have to say that the (off microphone) has been having what I believe is a very, very good attitude towards both the commission and other people authorities.  Members met to discuss, raised objections, they tried to answer to our objection.  That's (off microphone) we should follow, the whole community, because if you believe that public authorities will attend all meetings, or will follow all the IETF analysts, whether we like it or not, that is not going to happen.  
So I can give you two separate reports.  We can try to bridge -- to cross the bridge.  But perhaps the point, if I still have some time, the point -- that will be very quick, I hope.  I think it is important, I don't have much to add to either (off microphone) highlighted by Brenden or the reaction highlighted by the gentleman, which I think they're both of value, but the thing is that you have to enter the technical community -- the technical community has to enter into the psychology of public authorities and bureaucrats.  (off microphone) something that happens, want to find someone to -- want to find -- want to pass it to someone else, and that is going to scale down, scale down, scale down.  (off microphone) more or less at my level, which is not a very nice way of leaving, of course, but I cannot be satisfied with answers such as don't worry, nothing is going to happen.  It's more of the same story.  
When I see a new technology being introduced, which I have to say bears a striking resemblance (off microphone) implication and I do know we have been told for a long time, don't worry, it's always the same story.  (off microphone) long discussions on who should sign (off microphone) significant (off microphone) was signed, and it was signed for a process that basically gives more power to one single government than to others, and for governments and public authorities this is quite an important point.  
So my question is, are we sure that RPKI would not produce the same problems?  I'm very happy to be convinced to the contrary, but please do not -- more technology, because very frankly I cannot go back and tell that to the powers that be and (off microphone) the next three years hoping that nothing will happen, because something that will happen, then I will have to pay the price.  I will go back to you and tell you, why didn't you tell me the truth?  What were the risks?  And we can discuss and try to find a solution.  But let's at least try to understand also the perspective of the public authorities here.

>> Thank you, Andrei.

>> Victor (off microphone) Europe and Asia, but here it's more implication issues and I will speak only in person, not result (off microphone).  First of all I want to escape some misunderstandings, because a few different streams of activities mixed in this discussion.  I see the principal mistake is misunderstanding, because one process is source allocations, space allocations, and this is (off microphone) nothing new.  And it was the initial goal and still the goal for areas, certificates, allocation certificates.  Imagine (off microphone) own the paper, you have as a paper, official paper.  (off microphone).  Second field, fully different.  It's around policies and routing of (off microphone).  It's fully different and it's ISP issue.  And I simply don't know any ideas to create a routing policy (off microphone) authority.  And from this point of view, more clear.  
Yes, as these discussions a lot of years ago and different technical development now (off microphone) discussions for years, there is different issue, but the (off microphone) and I also raised some issues comparable raised a few years ago, but the key problem was to escape political consequences and unintended political consequences.  But you should understand just technical development.  If we -- I want to (off microphone) RIR work on (off microphone) policies, to (off microphone) to develop new policy issues among (off microphone).  At this moment nothing is proposed.  It can be used for different purposes, not only for global (off microphone) but also for more complex (off microphone) don't know.  It's still a development.
Regarding -- anyway, regarding (off microphone) mentioned centralized, regarding allocations, yes, it's (off microphone).  I can process after the information of (off microphone).  It's on the agenda to discuss which are the functions, and how should (off microphone) and how it can be implemented.  I can imagine examples where it can be done a different way.  It's a difference.  Still, it's not a technological issue.  It can be implemented, from my opinion.
Other points that were expressed, mostly in the IGP presentation, just technical issues, how to implement.  Technical issues how to implement.  In my opinion we can discuss in details about related to -- about -- about relation (off microphone).  Perhaps it's something more because there are a lot of technicalities and maybe key points -- it's still in development, because even a while ago it was hard to imagine this system became more flexible, and we can find more (off microphone) compromise how we can really deploy, and I want to repeat after Andrei that it will be used only if ISP will deploy it and will use it.
Especially -- I don't remember, you mentioned in your presentation or in your IGP papers about this -- some country -- imagine the situation, all the authorities in one place.  I was to remind you allocation of resources.  Currently, for example, for ISP (off microphone) can drop whole registry.  (off microphone) system after that simply not (off microphone) because I participated in one of the processes (off microphone) lose trust.  Current system built on trust.  If we are enhanced with some additional tools, it's very important to support some (off microphone) to provide transparency and to keep the existing trust.  I fully agree with this conclusion.  Thank you.

>> Thank you.

>> DANNY McPHERSON: Danny McPherson here.  So -- McPherson here, I'm going to read something I wrote a moment ago so I capture all my thoughts.  This is a rarity for me.  I'm speaking as an individual, an operating and IETF participant.  I am a member of the IAB and -- my presence and comments here don't represent the collective IAB.  That said, I think the --

>> Because of the noise level, can you speak very slowly and very loudly?

>> DANNY McPHERSON: Yes, okay.  Is that better?  The Internet routing system operates in (off microphone), mode which provides much in the way of autonomy but significantly lacks -- if the routing system is insecure, everything that rides upon that IP-based substrate is (off microphone) insecurities to bring about.  As more critical services are converged on to a common IP substrate the insecurities of the routing system seem to manifest themselves (off microphone) in interesting and concerning ways.  (off microphone) for secure routing is a cryptographically secure struck their a attests to the particular resource and subsequently enables association between a number of resource with the resource holder is identifiable within the routing system.  
That identifier is known as a (off microphone) system.  The more I think about this the more I realise that expressly acknowledging and delineating the (off microphone) structure from the secure routing protocol such as SPG and authorization of the routing structure are two entirely different things.  The RPKI should provide infrastructure to identify in a secure manner, particularly a number of resource holders.  The information in the RPKI can be used as a foundational element are security system, as well as other applications, such as source addressing and policies in the data pad.  
However, (off microphone) parties, ISPs and enterprises of that resource are surely going to put international business policy and security objectives first and then global policies that might somehow manifest themselves in the RPKI.  The current design work in the IETF site are (off microphone) express consideration to this and enables this capability expressly with (inaudible) capabilities.  The autonomy and flexibility afforded by the routing system is certainly a desirable attribute.  RPKI for number of resource certification is necessary and it's amazing to think we've come this far without such a system.  Careful balance and due consideration should be given to ensure that the hierarchy of the current Internet number resource allocation model doesn't force the hierarchy dependencies on the routing system, and simply an input to be given network operators routing policy that's developed based upon their objectives.  
The RPKI are subsequently (off microphone) in the form of secure routing framework cannot place restraints on the autonomy of the current model which continue to (off microphone) its autonomy.  And finally I think there is some work, at least from my perspective, to be done to make sure the delineation and technically that that separation is clear, but, you know, there is a linkage between the two.  Anyway, that's basically the statement I have at the moment.

>> Hi, this is (off microphone) today I forgot to bring my passport and my situation was (off microphone) (laughter) so I know it's important.  So yeah, I like the RPKI talk because in case of unauthorized announcement, we can easily (off microphone) loud announcement, and also we can easily check the (off microphone) resource from our customers want to announce (off microphone).
But on the other hand, if we continue effort to detect and authorize loud announcements, there are lots of (off microphone), I think RPKI could make our infrastructure secure if (off microphone) can (off microphone) in our infrastructure.  Because RPKI is useful if people (off microphone), so I think we need to train not only for SP (off microphone) but also for the (off microphone) as well.

>> What we'd like to do now is first foster a few initial interactions between the panelists -- the initial presenters and the panelists, so I'm going to bring these microphones over here and so now you are allowed to respond to anything you heard up there with some questions.  So --

>> I'll start.  I -- for a while I was IETF area director back in the early days when there was in a given period probably a hundred Internet drafts of technology coming out in any given period between meetings.  Now I note that the IETF has at some point more than a thousand Internet drafts open.  All of these new technologies are new tools (off microphone) the operator, and I'm trying to figure out how do you engage, or how do you decide which ones to engage on proactively on public policy, particularly when they're all optional and not mandated.  I imagine almost any tool can create a policy implication if you use it in the wrong way, and with all the technology being developed, which ones are policy matters?

>> I guess that was a question for the bureaucrats.  Our usual answer in that case is it's up to you to decide, but I will offer some suggestions, taking the example that Danny said has developed for ten years, the very first (inaudible) and I remember seeing the first papers around the possible policy implications of -- so five years after the first draft came out.  This might seem a lot in the technology field but in the policy field it's actually not that much.  But my point is although the first policy papers appeared five years after -- more or less after (off microphone) engagement with the technical community and policy makers happened later than that because at the very beginning the first reaction, and I'm not saying it was -- I'm just talking about the technical community that had experience with it, the first reaction was government should go away, and I'm sorry, this is still a very common reaction by the technical community.  
Why do you care?  This is the normal position.  Or this is too complicated for you to understand, which might be very well true, but it doesn't say -- it's not a very good discussion.  So if we try to triangulate, between the specification or whatever you may call them, the intellectual environment that tries to bridge the gap between the technical community and the policy community, and the policy community itself, if the -- let's say the academic environment starts to come out with papers, come up with papers saying, this might be a problem, perhaps the technical community should go immediately to policy makers, as -- I don't want to publicize (inaudible) but that's what I have experience with.  
It's very proactive with this point of view.  As soon as they realise there might be a problem, they immediately (off microphone), and that's very good because this allows us to be a little bit more relaxed.  This allows us to tell us our powers that be, don't worry, everything is under control (off microphone) and everybody is happier, but if the relation of the technical community is let's keep this under the weather because those bureaucrats don't understand technology and even if they understand it they're going to ruin our IETF scheme.  I'm sorry, I'm being a bit provocative here, that is not going to work because at the end of the day you will have a set -- instead of having five years to discuss the policy implications you will have three months and at the end of the day public authorities are often forced to take a position, the difference being that they will have had the three months instead of five years to reflect on it and you will have had three months instead of five years to make your case.

>> And you say in the case of this particular technology, right, came out proactively and approached you on the issue of RPKI, NCC came to you.  Did you find any policy matters as a result?

>> Did we find any policy?  Sorry, the last question --

>> Did you find any policy implications that concerned you as a result?

>> I would say we found a potential policy implications, which are not that different from -- not that much different from what's the paper from (off microphone) GCP, there was no relation between the two.  But for us the potential implications were one of the revocational certificates, what does it actually mean to revoke a certificate.  Here I would like to make two open brackets.  I will try not to name names as much as possible, but I would like to remind that several companies, big and small, they are now starting to see the Internet as a strategic -- strategic field for conflict, and if you read many of the papers that have been produced by many countries, I'm not talking about only one country, many are doing this, the initial revocation of addresses comes up time and again, the revocation of the address is warfare for law enforce him.  These are all actions that have deep -- very deep policy implications.  
So when I'm presented with a technology that frankly facilitates, I know it's already possible to revoke, but let me put it this way.  It's one thing for an RIR to tell its members, you should not (off microphone) this address book.  It's another thing to have the technology that will automatically allow -- that will automatically provoke the revocation and the blocking of this address, routing of this address book, what I (off microphone) with the exception of the business model on the registers, which frankly for the time being is not our business.  If people are happy with their RIRs, fine with them.
What I think is not considered well enough is that the (off microphone) of this technology is to be adopted.  I don't think people would spend so much time working (off microphone) were it not for most ISPs to be adopted.  Second, the Internet space, the number of ISPs is much more concentrated than it was years ago.  This means it takes a lot less effort to build -- to build a bigger number of ISPs, after which, because of the network effect of this market, everyone else they'll be basically not forced but deeply (off microphone) to use this technology.
So I find it kind of strange to me to think that on the one happened -- I'm finishing -- I saw you, yes, I'm finishing.  On the one hand you want to develop technology for it to be user.  On the other hand, say people don't use it, we don't really care.

>> I want to follow up on this myself.  I think it's an excellent question.  This relationship between policy and development technology is very interesting.  I can understand the technical people, when you consult with policy makers, and particularly government, and particularly in environment, which people tend to view this as a strategic issue in which there is conflict among states themselves.  
So if they go to you -- if you say, come to public authorities, the first question is, which public authority?  Okay?  Do they go to the United States?  Do they go to the European Union?  They're rivals in certain respects.  So the point I want to make is do we need more of an institutional capacity at the global level to talk about these issues and possibly to work them out.  I don't think it's realistic to say to technicians at the 1,000th working group that you have to think out all the policy implications of what you're doing.  I actually don't want technical people to be thinking about policy.  I want them to be doing good technology, and then we have to have an institutional process for solving policy problems as they come up.
So do any of the panelists have any thoughts about how to solve that problem?

>> Just a moment to (off microphone) because even today all national governments have enough (off microphone) through -- using the court to stop and manage routing policy.  And from this point of view all the discussions regarding (off microphone) roles (off microphone) because people can decide anything.  They can imagine any situation.  But the real world is most likely more complex than following such stupid decisions.  Hopefully we still live in civilized world because it depends on human decisions and outside of this room.

>> So I have two comments, actually.  One is that on the RPKI side specifically, is that the -- the crux of this, I think the reason why it's important to decouple the allocation infrastructure that already exists and RPKI providing a cryptographically verifiable form of that from routing on the Internet is extremely important because of this policy and national security issues.  That's important.  Anyone -- that seems to be intuitive.  I think there's another issue here that's sort of a little wider than just RPKI, which is if it's something that's systemic, like the DNS, for example, is systemic and hierarchical at certain levels, so it has global impact to change that.  
The hierarchy has wider impact to consumers of that infrastructure.  The routing system today is autonomous, and if directly employed RPKI might add some level of hierarchy to that, but we have to find some way to balance the two to find some security in that infrastructure.  I think that -- you know, the sort of global systemic infrastructures, like the DNS and routing, the transaction enablers, if you will, of some user-desired service is it's sexy and people like to look at it and it does have global implications, certainly, but at the same time there are lots of other things, you know, like (off microphone) which an RPKI could be used to help, and there are ways that people could do this today, but because it's not global in nature or systemic, it suffers from incentives and a capital market and tragedy of the (off microphone) so people don't invest in doing that in a competitive market.  And I think that's the sort of place that the policy could easily have some influence in that sort of -- or that sort of capability.

>> Go ahead, Andrei.

>> Just a small comment.  I'm not sure if I know how to (off microphone) this process you are talking about and whether there's a need to formalize this stuff, but I thought discussions like this help to evolve the system.  One example, I think the RPKI technology, and particularly and specifically, applicability of this technology in the routing security plain, it evolved a lot.  If I look at the last three years, it evolved, and the first applications of routing security did assume that like revocation of certificate has immediate effect on the routing system.  Today that's not the case.  That's simply for the true.  Simply revocation of certificate will have very little effect.  It will lose the preference of a sudden (inaudible) in the routing system will not make it invalid.  At the same time it gives an opportunity to an ISP to protect their routes.  
So what I was trying to say, the -- I think those discussions helped and that the current development of the system doesn't make routing more fragile.  That was one of the concerns.  And therefore that diminishes some of the policy issues that are related to this.

>> Can I -- a quick response and then we'll have Brenden ask a question of the panel and then we'll open it up.

>> Just on the question of institutionalization, well, that's a word (off microphone) one of your speakers.  To equal what the gentleman before me said, I'm not sure it's useful to institutionalize this relationship.  I think it should become a habit exactly like in most other areas of science, the (off microphone) there are certain policies and ethical considerations (off microphone) and there became for example experiments on animals.  Until a few years ago nobody cared about them, and now when you talk to a scientist, the scientist in that field, it's automatic (inaudible) like to use animals.  I would like to see the same baseline of sensitivity on the part of the technical community.  Can we help?  I would love to participate in the meetings of policy makers (off microphone) bureaucrats will help.  I understand your concern but my only point is we can't simply continue to work divided as we are.  That is simply not going to work.

>> Quickly.

>> Very briefly, I actually don't believe there is a difference or separation, and I do think that the IETF develops technology and technology has a lot of knobs and switches.  When it's deployed it's deployed by Internet service providers, by companies.  And to the extent there's policy implications on how a service provider runs its network, that's certainly something that in many countries the government intervenes in and says we want this service for our customers, for our users in our country.  So at the end of the day I'm not sure, looking at the policy implications of the IETF is really where you need to go any more than, again, looking at the policy implications of a screwdriver.  You really want to see how ISPs are operating this, and each country has a mechanism for regulating or at least providing oversight to its ISPs.

>> All right.  So John you got the last word on that one, but we're now going to move to Brenden, and he's going to give you an opportunity to question the -- given an opportunity to question the panel about their reaction to his talk.

>> BRENDEN KUERBIS: This is a question for Danny and Dmitry.  Danny, you mentioned possible changes to the IANA model, and Dmitry you mentioned technological developments that could address the political risks and also the risks to routing autonomy.  I wonder if you could comment further on that.

>> So I don't know what changes I mentioned with regard to the IANA model.  I said there is an IANA model for resource allocation, it goes from IANA to IARs and subsequently assignments from there.  An IEB statement and the current perspective is that alignment of the RPKI and the trust anchor model with that, the global RPKI I guess I should say, is important to avoid introducing other required dependencies in the system that could, you know, expand the tax service, for example.  But as far as the changes to the current IANA model I don't think I mentioned anything else to that regard.

>> I'd just comment because my opinion is that if we will describe definition of IANA functions IANA functional operators, it will easier to understand future IANA activities, but it's for future discussions.  But you want to ask me something else?

>> Technological developments that you felt necessary to deal with the political risks.

>> What about technological developments?  I missed the context.  All of this is technological developments.

>> It's my assumption you were thinking of specific developments.  Specific developments.  That deal with technical risks.

>> I just mentioned because historical -- historical, different approach, different views, because people who specialized in different fields have their specialized view, and during (off microphone) it's just from year to year work together and to understand the problems to revise the needs and Andrei also mentioned resolution, for instance (off microphone) and develop (off microphone).  
Moreover I want to say it's not the last step because it's open which tools we will need to provide for ISPs to use the system more flexible, because (inaudible) new additional tools to manage your routing policy for ISP.  More flexibility maybe to simplify operations as today growing (off microphone) a lot of (off microphone).  New issues too because it's also -- we'll go to IP -- IP (off microphone) consistent (off microphone) separate issue, and they can expect new schemes of routing so (off microphone) enough complex.

>> Yeah, I'm sure there are RPKI (off microphone) automated tool for high-speed, so we can easily check route announcement by router.  But still, we can decide, either out (off microphone) a preference.  Still, we can decide how to deal with (off microphone) announcement.

>> If I could say one more thing.  I think sort of acknowledging that the Internet is sort of a network of loosely interconnected networks, many of which span national boundaries, and those ISPs or the operators of those networks are the relying parties on this RPKI infrastructure.  I'm certain that the relying parties are going to have intermediary functions in place that allow them to -- and I think this was Dmitry's point, that allow them to apply preference to things they think are important, and, you know, that's -- that's an operational reality that this would exist for a very, very long time, and so....

>> Simply -- you missed one point because control point for the -- on ISP side.  Today in this model it's the same.

>> Okay.  Thank you very much.  I think now is the right time for questions from audience.  Please, if you're going to speak, say your name and your affiliation.  I saw three hands on the right side, so I will move there and I will try to bring people the microphone.

>> RAUL ECHEBERRIA: Thank you.  My name is Raul, I'm (off microphone) LACNIC and also the Chair of the (off microphone) society.  So I'm wearing my (off microphone) hat today.  One comment is that -- I'd like to make one comment and one question.  The comment very quickly is, some -- it was mentioned that that -- that if the technical community would be something absolutely separated from the policy makers, and I think that one of the characteristics of the RIRs, is the RIRs are not a pure technical organisation and (off microphone) stakeholders, and it is a very good point that it's important to understand that this -- the RIRs are very well -- the kind of organisations for placing this kind of services because the characteristics of openness and (off microphone).
I think that the -- my question is to the speaker from the European Commission, that you say that -- you expressed some concerns in this dialogue -- in the (off microphone) of the certificate of revocation.  I think because it was explained by Andrei what the real impact of certificate revocation and also has been explained by other speaker that the ISPs remain with the position -- making the decisions what to do in any case.  But the government, the governments of Europe has been worried about the other problems that take the people off the Internet, like blacklisted, for example.  This is a very rare problem in America.  It has a real effect in -- it's some organisations that are not transparent and not (off microphone) open.  They take decisions to blacklist big networks that in some cases are (off microphone) include entire countries.  They are off the Internet.  I have not followed in the discussion about this topic, but this is something that has a real impact, and so I do understand what's -- the (off microphone) of the concern regarding RPKI when there are products like this that remain on the table.  Thank you.

>> I just want to take this opportunity to thank you.  LACNIC actually helped to organize this workshop, I know you addressed that question to Andrei, but I want to point out there's interaction between technology.  You say currently it black lists could be (off microphone) whole ISPs.  One of the things that can happen is once the infrastructure is in place, regulatory authorities can use it, and do things with it that maybe the technologist didn't intend.  So for example in the new GDLT process of ICANN, (off microphone) new top level demands.  I'm sure the people designing it had no idea that would happen.  So we can imagine a case, right now, ISPs can ignore resource revocation, but a public authority somewhere might say, you must have the resource, and if you don't you can't function here, or something like that.

>> You (off microphone) the question.  You are very smart.  But, you know, that it's a (off microphone) person.  I think the question is that it is not (off microphone) that there could be decisions taken by ISPs who have a bigger (off microphone) in disconnecting people from the Internet.  I have not -- this is a much more safe situation, and I have not seen those (off microphone) from the governments before.

>> Should I react now?

>> Yes.

>> If I may react to the point by the representative of LACNIC.  I cannot speak for the governments of the European Union.  You will have to ask them.  Let me put it this way.  We all know that public authorities can do bad things.  Sometimes they do it because they don't understand the situation.  Sometimes they do it because they are (off microphone).  My point is if the technology would allow -- would make it easier for certain institutions to behave in ways which would be possibly damaging, isn't it worse to reflect whether we should put for that technology?  I am not saying and the commission is not claiming, first of all -- when I said the commission, it means the (off microphone) commissioners.  I speak here as the bureaucracy of the commission, the technical side, the people -- the working bees of the commission.  It's not like we think that RPKI will shut down the interpret, but we do see potential implication for using RPKI as an additional tool in the hands of certain governments, or certain public authorities, which may not necessarily (off microphone) the environment of checks and balances that you can find in parts of the world such as Europe and -- well, I don't want to run a list because then I will -- I'm sure that some countries will be offended.  
Again, within the public authorities (off microphone) in five to ten years' time frame, although that might not be apparent because politicians think six months (off microphone) in the time frame, but more I like to think what's going to happen in five years, ten years, what is going to happen in the relationships of power.  
To answer your point on black list, I find it bizarre that on the one hand I am told here that -- not to worry because RPKI is a choice by ISPs, and they can use it or not, sir, as they want.  Likely it's a choice by ISPs as well.  They can choose to go with a provider with black list or not.  So if they should be interested in black list, we should also be interested in RPKI (off microphone) and policies.  And I speak for (off microphone) and the result might be the large ISP black list an entire continent.

>> I'm Steve Kant, chief scientist for BBN Technologies, and according to Brenden and Milton a pawn of the U.S. government.  Although I consider myself the evil mastermind behind RPKI.  There are a number of technical things that were discussed this morning, especially in Brenden's presentation that are simply not quite right.  I'll just pick on one of them.  With regard to trust anchors, it is a common function of PKIs in general that everybody gets to pick who the trust anchors are.  It is also common that when a community establishes a public structure that they have a nominal set of trust anchors which they are assuming most people will rely upon.  The decision in the RPKI environment to align the certification authorities with the allocation hierarchy is a very sound technical decision.  A certificate authority is vouching for a collection of information.  The commercial certification authority cited in your paper, people, like (off microphone) signed, are authority for nothing.  They always rely to someone else's database, someone else's credentials to make an assertion.  This is another place to get things wrong.  
So it is preferable to have a certification authority issue certificates relative to a database that it itself is authoritative for, which is precisely what we're talking about in RPKI, whether it's IANA, a national industry, each of whom is a certification authority in the RPKI.  So the decision to make that alignment is a technically very sound one.  Bringing in third parties as CAs, as happened in the browser environment, results in terrible security problems, as anyone who's familiar with the current situation in the browser environment would tell you.  That's not a place that you want to go.  
So from the EC, the analogy here is do you want to outsource the issuance of passports?  Each country from a position of sovereignty and autonomy is responsible for issuing a passport as a credential, which attests to the citizenship of its citizens, not to other citizens, and that's what we do with the RPKI.  We allow each of the entities in the current allocation hierarchy, not introducing new ones that we have to ask (off microphone), but asking them to rely upon exactly the entities who hand out these resources today to take on an additional function, which is to digitally certificate what's in their databases already, which is analogous to countries issuing passports or analogous credentials to their citizens.  
Each of the ISPs take the A in autonomous system very personally.  They do get to make the decisions.  They get to do two things in this environment.  One, they decide to use the information from the RPKI or not, and of course we all hope they will do it because it represents an improvement relative to other assertions that they can get from things like I (off microphone) databases today.  Secondly, they get to choose who the trust anchors are, and the presentations I've made at the site of working group over a year ago in a document which has been posted, not yet a working document, we have a specific technical mechanism that makes it easier for ISPs as (off microphone) parties to configure their view of the world to protect themselves should they decide that some regional registry, some national registry, whatever in the world, isn't basing the way they thought -- behaving the way they thought it should.  They're trying to step outside of the boundary imposed by public use certificates.  That's better than you have in all the browsers in the world, which have a mysterious set of trust anchors that (off microphone) don't understand and have no authority over, and have no scope what they can certificate.  The RPKI makes sure that each limitation authority is limited based on the resources that were handed to it.  So if it tries to make an assertion outside that scope, it's immediately identifiable as, hey, you're lying, not good.

>> Okay.  So if I understand what you're saying, you're saying that the authoritative allocation hierarchy is the best place to get the certificates, but since there's only one and you want to give relying parties a choice, that the current architecture for RPKI allows the relying parties to make a choice, and therefore you are, in fact, recognizing the implicit policy issue which is that you don't want to make the ISPs completely dependent upon the allocation hierarchy for their trust anchors.  Is that correct?

>> What I said, Milton, was that all PKIs allow choosing parties to choose their trust anchors.  The -- it's just another PKI.  It has the advantage of being transparent in terms of the authorities in the system.  You're trying to translate this into what does this really mean to me.  Is that the question?

>> The point is when you say all RPKI --

>> I said all PKIs.

>> All PKIs permit choice of a trust anchor.  Are you describing a technical reality, an organizational reality or a political reality?

>> Actually all three.  I can go to my browser, because I'm a technical --

>> Political and institutional things can't change.  There's no -- it's just once you put the specifications in an IETF document, that's it.

>> Well, that's another one of the errors in your paper.  The IETF in the techs working group in your paper didn't invent the PKI.  It's a 509 standard, it's an IUT thing, dates back from the CCITT days.

>> I know.

>> Your paper says the opposite but that's okay.  So the reality is that technically relying parties are supposed to be able to do this.  Whether you get to do it as a function of the software that's given to you or the --

>> Or the institutional environment and the legal environment.  These are things you don't seem to grasp.

>> If you're going to talk about grasping and move into the technical arena --

>> We're not in the technical arena.  That's the point.  We're in the policy --

>> You're talking about policy with regard to technology, so one who doesn't understand both is not qualified to talk about them.

>> Can I make -- can I make a question?

>> We have -- Malcolm wanted to ask a question over there.  He was next in line, and Paul wants to ask a question over here.

>> Okay.  How I want to respond to what was said --

>> If I may just -- I just have one small question is if tomorrow a RPKI was implemented -- I think there is a deadline or timeline (off microphone) 2011 (off microphone) are supposed to have RPKI services.  Is that correct?  My question is if in 2011 RPKI will become used on the Internet, who is going to be the certification authority?  I understand -- let me finish.  I understand that technically there is the choice, but I'd like to understand, given the current political, economical situation, what's tomorrow will be the certification authority?  Will it be IANA, will it be someone else?  That is interesting to me.  Second reaction, it's interesting -- I do not agree that those who do not possess technical and policy knowledge are not qualified to discuss because if that would be the case we would discuss about nothing, because no one has all the knowledge about everything, so we should be open to listen, the technical people should be open to listen to the policy people and vice versa, but just one comment.  It's interesting that you refer to the passports.  That's a metaphor that's used before, because when you see a sovereign country, not the commission, issues a passport it takes responsibility for the issuing of the pass.  Which means if the passport is found, for example, on someone who is committing a murder of someone else, or committing a crime, that is implication for the country who issued the passport.  In the implication (off microphone) in terms of cooperation between the country where the crime was committed, B, and the country A that issued the passport of that person, or it has implication for immigration.  It has implication for a lot of things.
So my point is it's (off microphone) aware what the implications, real or perceived responsibility, political tents, once you claim that you are attesting, yes, this route information is true, you will have a lot of law enforcement authorities coming to you and asking you, are you really taking responsibility for this statement?

>> So to answer your first question, none of the IETF standards have established the January 1 date.  It's a statement by the NR (off microphone) collection of regional registries.  Secondly, the question of who will be the CAs.  The answer is at a minimum the regional registries will be acting as the CAs, and the CAs will be empowering all of the ISPs to whom they have allocated resources to become CAs simultaneously.

>> Iana would not be a certificational authority.

>> I have not heard explicitly from IANA, anybody can be a CA.

>> I'm not asking anybody can be.  I'm asking 2011.

>> You should ask IANA.  Third, continuing my metaphor with passports, I think it's appropriate but I think you're pushing it too much.  If I'm -- if I issue a passport, if I can be a country, am I issuing a passport saying that all the citizens I've identified are good people with regard to a murder?  No, I'm identifying them.  That's what I'm doing.  Will I insist -- will I comply with an extradition requirement from any other country?  That's a completely separate matter.  So I think you really read a lot more into this than is true.

>> Yes, but you will have to decide whether to comply with a extradition request or not.  That implies resources, political decisions.  So you need to take that into account when you decide to issue pass worst.

>> We have to move on.  Malcolm, is actually an ISP, would like to speak.

>> Yes, I'm Malcolm Huntsy.  So you know where I'm coming from, I work for the London Internet exchange, which an ISP and it's also sort of trade association for ISPs, so -- and I'm also the president of (off microphone) by the pan-European trade association of Internet service providers, but I'm not as well briefed on the technical discussion that we've just had and these issues as I should be to be speaking on behalf of these organisations, so that's just a background, but what I'm saying is not the formal position of those organisations.  And I want to drag the discussion back to where we started because I thought we went down quite a detailed rabbit hole with that discussion that was possibly dragging us away from an area that is interesting to look at, that we can all be interested in, and (off microphone) ISPs are interested in the policy issues that are being raised.
It started off with Brenden saying that the (off microphone) potentially reduces the autonomy of ISPs and particularly in the revocation area, and that's the sort of thing which from an ISP perspective would be interesting to look at.  We'd be concerned about if it were true and what the implications were, even though ISPs (off microphone) strongly disposed to be highly supportive of the (off microphone) IRR model and believe it works well.  Nonetheless (off microphone) no more engagements in their on-line internal policy, we like to look at this and I think it's important.  I think the issue Brenden brought up is worth engaging with.
Now I'll set out a couple of facts that I understand or believe to be broadly true because that sets the tone for this, but basically when Brenden made that point, there was a strong answer from Aaron and I believe from the RIRs -- from ARIN, that we don't need to worry about this because it's no real change to the current situation.  The certificate is given when you allocate the resource, and if you no longer have a resource then the certificate disappears again and that's fine, and what's changed?  
But my understanding is that by and large, while RIRs are relied on heavily for the allocation resources and it's -- and it's completely uncontroversial that few haven't been allocated an IP address block by an RIR you shouldn't be announcing -- you shouldn't be taking use of that address block.  But when it comes to revocation the situation is a bit more complicated than that, because it's my understanding that it's very rare to never do registries actually revoke an address allocation against the will of the person that's being properly allocated in the first place.  And certainly it's my -- it's my understanding with a high degree of confidence that their ability to revoke that is weak at best, because while some ISPs, when building their routing tables will look at -- routing (off microphone) databases maintained by the RIRs, not all (off microphone).  
So even if a routing object was removed from an RIR, database, that necessarily mean that the route's (inaudible) disappears completely.  With that background that would suggest this would make a chink in a world where RPKI became very much the way -- very strongly relied on in order to ensure routability, in a world where RPKI was a great success and if you didn't have a valid and current certificate for your -- for your address allocation, you couldn't get routability for it, in an Internet world actually the RIR would suddenly have acquired a strong ability to enforce the revocation of an allocation of address base.  Now, that seems to me to be a potentially significant development, and whether it's considered significant from a governmental point of view or from others, or whether it's considered a technical matter, nonetheless it's something that I think we should be looking at seriously, because then we have to ask at the very least for the RIRs on internal policies under what circumstances would you then exercise this power that suddenly has become under this new development a readily exercisable and strongly enforceable power for the first time?
For example, if a policemen shows up at the RIRs door and says, on this address block over there, there is bad stuff happening which is against the law, and we would like you to revoke the certificate of that address block so that it's no longer generally routable, what is the RIRs policy on that going to be?  My understanding is that RIRs do not get those kinds of requests from law enforcement authorities because they can simply respond, by and large.  And I really only have expertise here in my own region -- or knowledge in my own region, the right region.  So -- RIPE region, so if this isn't true in other parts of world I apologize.
But my understanding is you basically respond to law enforcement agents, or something like that.  I'm sorry, but we can't stop this address being routed.  That's not -- certainly not what RIPE does.  It's not something that RIPE is capable of doing.  If that were to change we could expect a change in behavior from policemen or from (off microphone) litigants, for that matter, and all sorts of others, and we would need to develop some type of rules for recognizing how we would respond to that.  If there is a potential for legal compulsion at the registry, does the registry protect itself against that by its organizational means?  Does it comply with that?  Does it -- how does it recognize who to obey and who to comply with?  What level of -- of recognition -- of seniority in the state apparatus do you have to be in order to make that section (off microphone) and be recognized by registry.  All of these things imply some kind of policy, whether it's a public policy or whether it's an internal matter for RIRs.  Nevertheless there needs to be some rule making around here and I think we as ISPs would be interested in seeing that this has been properly thought through before RPKI becomes something that we would -- have an unqualified delight at being seen -- being relied upon heavily.

>> Thank you, Malcolm.  I think -- the panel -- we have a question from Paul.

>> So are they going to respond from the panel so should I go to Paul?

>> Well, John wants to respond as well.

>> Oh, okay.

>> To be clear, so first, revocations, I will say -- I can only speak for the (off microphone) but we administer based on the policies adopted by the communities.  We have thousands of participants and so if the (off microphone) say revoke, we revoke, and that means on willing people.  It happens all the time.  The statistics are on-line if you want to look.  So the fact of the matter is indeed this already occurs.
To get to the exact point asked, to the extent that an ISP seeks a certificate and uses that to assign their RIR, their rote.  By seeking the certificate the certificate has a life and is being maintained by the RIR, they implicitly are creating a dependency, because now if people start following those route announcements and looking at that authorization, because they've opted to participate by using this infrastructure, there is implications.  There's no doubt about that.  I guess the most important thing is the first thing the ISP has to do is decide they want to participate in this infrastructure, and that's a voluntary matter.  The policies by which those certificates are issued and revoked are for each regional registry to have discussions with its community on how that goes about.
There are times when law enforcement, I know in the (off microphone) region, law enforcement does orders, and ARIN applies with all lawful orders in the region it operates.  Generally we don't get orders to revoke space because that's not what they're seeking.  They're seeking additional data on the parties registered, but there could be potentially implication.  This should be discussed in every RIR in every community thaws affected by this.

>> Can I just comment on that specific issue briefly, which is -- is microphone working?  Which is basically the one thing that I think that people are completely ignoring in this discussion is today in the Internet routing system pretty much anyone can assert reachability for anyone else's address space, and there's no place to verify what's appropriate.  And this infrastructure, however employed by operators or relying parties, helps to provide a source of authorization for those routing announcements.  If you don't have it, then the entire system is vulnerable to anyone asserting reachability, hijacking anyone else's space.
Now, I agree that these are important policy issues but I don't think that any of those policy discussions should ignore the inherent insecurities of the system today.  Evening that's absolutely critical.

>> PAUL VIXIE:  Paul Vixie, Chairman of the ARIN board of trustees.  I heard, I think, Brenden make a remark earlier that I wanted to follow up on, similar to what Danny just said.  So right now we have bad people doing bad things with the routing system.  They are injecting routes, pirating space from other people, launching an attack of some kind and then pulling that route out.  The rest of us have no recourse.  We have no way to recognize those as false assertions of routing authority, and so we accept the routes, we accept the packets, we accept the damages and the attacks and then we watch it disappear, and there's nothing anybody can do about it except to deploy something like RPKI.
If we're contemplating a different situation where the RIRs have these new cosmic powers where they can revoke address space, and if that's a bad thing, I would ask you-all to consider that we have no recourse currently.  The bad guys get to do whatever they want to do and we can do nothing about that.
In the alternate reality where RPKI has been deployed, we have some recourse.  The RIRs, our membership organisations chartered in their regions, they have corporate governance, there is Internet Governance, there are all kinds of ways that, for example, ARIN's members can make sure that ARIN does not use these powers inappropriately.  We will not be in a position to compel people to become ARIN members in order to get access to these features, unless that's what our members tell us to do, and I don't think they will.  If they do, then we have perhaps a situation where the majority is exerting its will over the minority.  That would be another governance problem, either an Internet Governance or a corporate governance problem.  There are recourses for that through the courts.
I'd like to move from the situation we're in now, where the good guys have no recourse against the bad guys, to a new situation where the good guys will have some recourse against other good guys if these powers are misused, and that is the choice I'd rather see discussed than the concern that Brenden mentioned in his presentation.  Thank you.

>> Just to -- thanks for discussing (off microphone) and also for Danny's intervention.  Of course, this issue should have been probably (off microphone) but I thought it was obvious.  We are fully aware of the stability and security, if you will, risks that we're currently running and the potential advantages with RPKI.  We put that on the table without ever forgetting that there are other implications we need to consider.  
I'm also a bit surprised by statements that seemed to me -- seems to me is they're picturing a (off microphone) either we (off microphone) or the Internet will explode.  I have to (inaudible) the (off microphone) information the information not prepared by (off microphone) but they have technical people in the union, and actually most of these people said, according to them the most efficient technology with the least side effects to be used today would be monitoring and filtering, filtering routes, which is available today.  I believe you don't need RPKI to do that, sir, or social security or dialogues between PGP routers.  RPKI is considered as an option but not as the most important option.  
So I would just like to -- it is right to frame RPKI in the context of the added security values.  I don't think we can claim it's the only way forward, but I'm not a technical person so I would very much like to hear from the technical person, if they really believe that RPKI is the only solution that we have to move forward.

>> I see a lot of hands but really we cannot take any other questions.  We are running out of time, so I will close the discussion and I will ask (off microphone) for wrap-up of the discussion.

>> Thank you.  Andrei, this is a great example, this workshop, of what the Internet Governance Forum can do.  It can bring together people from very different perspectives who do not often correctly understand what the other side is saying and need to coordinate their activities and their ideas and their policies, and I'm really pleased, despite the sharp clashes sometimes, I'm very pleased with the way this workshop has worked out.  I think it's done precisely what the Internet Governance Forum is supposed to do, and I want to thank in particular John Curran and Raul from the NRO site for actively cooperating.  I want to thank all of the panelists as well.  I'm sorry about your passport problem (chuckle).  We really wanted to have a broader and more diverse perspective.  I'd also like to thank Malcolm.  We tried to get some Internet service providers on to the panel, but we didn't, so your intervention was extremely useful.  Thank you.
(Applause)

>> Thank you very much for the participation.