On 9 May 2011, at 23:03, David Conrad wrote:
Alex,
On May 9, 2011, at 10:21 AM, Alex Band wrote:
On 9 May 2011, at 22:06, Sascha Luck wrote:
Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that. Again, it doesn't change that. Yes, it could potentially change that in some future where laws are changed, but right now revoking a certificate has no effect on routing whatsoever.
Of course, because no one is using it right now. Presumably, the point of deploying RPKI is that people are going to use it.
I meant now in legislative terms, not in adoption terms. :) Even with 100% adoption today, every network operator still has a *choice*. Only legislation can change that. It's just like basing routing decisions on 'route' objects in the IRR, but just more reliable because of the design of RPKI.
My understanding is that once people start using it, ISPs, under their own free will, will presumably implement routing policy based on certification status. At that point, revoking a certification would have an effect on routing. That effect can be anything from dropping de-certified objects on the floor to making them last resort to not doing anything special. Yes, it is my decision as a network operator what I choose. However, if "most" ISPs make the decision that a de-certified resource should be dropped on the floor, then the result is that every entity in the resource certification chain above that resource (LIR, {NIR,} RIR, IANA/ICANN) has the ability to cause that resource to be ignored for "most" ISPs.
Is my understanding wrong?
No. But if I look at this from an RIR perspective, it would of course never be in their interest to do so or play a part in that process. Our goal is to provide an infrastructure and make sure only the registered holder of an Internet resource can create a valid attestation. Other than that, network operators are free to add any routing policy they like, and other network operators are free to base any decision on the available information. Also, you have to realise that we've been working on this since 2006, by our Community's request. The system is based on open IETF standards in the SIDR working group which has been active even longer. All of this has been done in a completely open and transparent way. Now that we've finally launched this as a usable, tangible service, this discussion erupts. I'll leave it up to you to to draw a conclusion from that.
In the way the system is designed, everything revolves around preferences. At the end of the day, it it up to the network operator to base a decision on the information that is available to him/her.
Of course. And RPKI is providing a hierarchical system to provide information regarding resource certification. The implication of the hierarchical authorization model chosen by the RIRs for RPKI is that parents (and grandparents, etc) can impose policy on their children. Or do I misunderstand the technology here (entirely possible -- been buried under other things and have lost track of RPKI/SIDR developments)?
Allocating resources and registering them in the Registry is a function the RIRs have been fulfilling for years already. The same goes for IANA allocations. We've been using that information to for example lock down the creation of route objects in the RIPE Database. But by no means is the Internet Routing Registry system as a whole water tight. The power of it being a distributed system with more than 34 databases is its weakness at the same time. With RPKI, the only thing the RIR locks down is that only the registered holder of an Internet resource can create a valid Route Origin Authorisation. Yes, this is hierarchical in nature, but there is really no other way to make sure only the *legitimate holder* can make a *valid* attestation. This information is validatable by anyone on the Internet using public, open source tools from various parties. In this respect, RPKI makes the routing decision making process more robust. -Alex