[AfriNIC-rpd] Afrinic and RPKI

[Andrew Alston]

>> Hi Guys,
>> 
>> While I was considering developing a policy proposal around RPKI in Africa,

> What is the problem statement for the policy ??

The problem is RPKI in its current form, and myself, like many others I have spoken to around the world are opposed to its current form and implementation because of the dangers it creates.  I am prepared to go as far as saying, that unless there are a lot more assurances given about ways to prevent interference from political entities, I will propose a statement of rejection of RPKI from the African community. 

> I figured before I attempt that one, and its a bit of a minefield, I'd like
> to open some discussion on the list about RPKI.


> Great. We also have rpki-discuss at afrinic.net for RPKI related discussions.

>> A.) When a government declares that ISP X must be turned off, and issues
>> AfriNIC with an order to turn them off, that is generated in a court in the
>> country that the ISP resides in, how is AfriNIC planning on responding.

> Not a RPKI issue

Very definitely an RPKI issue.  At this point, if governments want to shut off ISPs they have to go after each ISP individually and actually force the ISP to do something.  With RPKI there is a potential situation where they can come after the ISPs VIA the RIR, and the get the certificates revoked at the RIR, dropping the ISP off the face of the net without even talking to the ISP.  That is DEFINITELY an RPKI issue.
 
>> B.) With the acceptance of RPKI we effectively allow outside forces to
>> control the issuing and revocation of IP space,

> Nope. RPKI reflects what  AfriNIC members and allocations databases say. If you are member and have resources, you will have a 
> RPKI certificate to say so.

In an ideal world, are you telling me that AfriNIC will give guarantees that under court order they will not withdraw certification of a route to shut down an ISP if a meddling political entity tries to force it?  Are you really telling me there is no danger here?  Sorry... gonna need a lot of convincing to believe that one.


>> and if we look at the
>> actions taken recently in Tunisia, Egypt and rumour has it now in Algeria,
>> is this really a road we want to walk down?

> Nobody wants to go there. Open and free access to the Internet should a goal  for every net citizen. 

No sane person wants to go there, governments and the powers that be can be far from sane.  RPKI gives them a method to exercise this insanity unless we are extremely careful.  I seek reassurances that we have ways to address these issues.  At this point, as pointed out here, and as pointed out by a LONG mail thread on NANOG, there are others that share the concern that we are creating a huge "internet kill switch", and this I have to oppose.   Once RPKI starts being used for "negative" testing of routes, I.E, no cert, no route, we develop a major problem.  Further more, part of the redundancy and the reliability of the Internet is based in its highly distributed nature, RPKI seriously reduces this and makes it reliant on a number of smaller authorities.  This is not something that I can see happen without serious objection.



>> C.) Has AfriNIC done any work with regards to RPKI to prepare for if this
>> does become a reality?

> For the RPKI, we have a CP and CPS and are looking at the legal related aspects with the Legal adviser. This does  include Legal > aspects on the Internet Number resources management.

I am glad to hear there are legal opinions being sort on this, and I would like to hear opinions from the legal side on this. I can tell you that before we walk down the RPKI route, I wouldn't feel comfortable without having our own legal council take a serious look at this as well.

>> 
>> Right now, I see the world discussing RPKI as a solution for IP hijacking,
>> which is likely to become far more commonplace now that IP space is running
>> out, at the same time, I see us being years away from RPKI implementations.
>> (There is no code in the routers to support this yet,

> you can just use the RPKI  objects  to generate filters for  routers  for now. 

If you do negative route testing right now with RPKI objects you'd end up filtering 99% of the table, we're a long way from that being viable.

>> there are immense
>> technical and political hurdles to be crossed, and its a fundemental change
>> to the way the Internet actually operates and in my opinion a grave threat
>> to the autonomy of ISPs).  

> I thought you were in favor of solutions  for  IP hijacking and  BGP threats :-)

You thought correctly.  I am in favor of solutions that prevent IP hijacking and BGP threats, including but not limited to, a complete overhaul of the current IRR system (which I believe if implemented properly on a global scale would solve half the problems RPKI is supposed to address).  I am NOT in favor of creating a mechanism that allows for political and other outside entities to influence the reachability of independent ISPs.  Nor am I favor of creating mechanisms that reduce the highly distributed nature of the internet that lends it the current level of redundancy and reliability.

It was once written (and forgive me, I forget who said it), that the internet is the worlds largest and more successful demonstration of anarchy that exists.  Some people don't like that, but the fact is, it works.  Go down the RPKI route as it is currently being discussed, and we walk down a road where the control is transferred to a few and we lose this. 

Pray tell as well, what happens if one of the root issuing systems is compromised?  Do we really want to risk that?  

Anyway, this is an academic debate at the moment, and I am not saying that I am beyond being convinced that this is the right way to go, but call me highly skeptical and highly cynical, but at the moment, looking at this system as I understand it, I consider this one guilty until proven innocent.

Just my 2c

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20110215/40484efa/attachment.html>