j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On 22/08/2011, at 5:27 PM, Terry Manderson wrote:
RPKI is the base requirement for a routing security framework. It is simply stating that the holder of the private key is the holder of the address space, with the underlying layer being that the address space is unique and can be verified as such. This allows one to build a layer of routing security with that basic crypto-graphical slice of information. The resulting security framework (evolving as BGPSEC) is optional - it has to be. Some people will implement and engage faster than others. However BGPSEC is optional and the prose in the existing IETF drafts says not having it is ok, it's just insecure. Additionally the real power for RPKI is in the hands of the relying party (those who do the validation and apply it to routing). The relying parties may/will apply their own local policies, which could be orthogonal, to what is seen in the RPKI. This implies that the RPKI is quite toothless as a sanction. Consider it as an instrument closer in function to the title deed for your house.
I understand this intent but I see that as the product of much the same set of participants as the RIR policy process and so RPKI and the policy around it are all of the same nature.
The other aspect of your suggestion is that attempting to turn the RPKI into the truncheon for the "addressing police", with the RPKI being linked to the routing system as it is, effectively turns the RIRs into the routing police for those that choose to use RPKI/BGPSEC. This is something I personally would be loath to see. Firstly because this is not the RIR mandate and secondly, in a litigious society the pool of money the RIRs would need to fend off offended businesses would drain Apple's stockpile.
Ultimately an RIR is allocating resources that provide access and with that comes responsibility for the policies under which those resources are allocated. It took a long time for the domain name registries and policy bodies to recognise and act on that responsibility to create dispute resolution and other rules, but in the end they did and it is inevitable that the RIRs must do so too if they are to survive.
The key word here is responsibility. It is an intrinsic attribute of resource allocation and cannot be avoided or ignored or the system fails. Every outsider I know that has looked in on the RIR policy process in the last couple of years has seen this responsibility gap clearly and was astonished by it.
I dare say that the vast amount of operators out there would also rather not see a RIR given such reaching controls.
In .nz we are also acutely concerned to prevent too much power being vested with one entity and the need for appropriate checks and balances. Consequently the ccTLD role is split across two entities - the registry that operates the DNS and registration systems, which it does according to the policy set by the other entity, the regulator, who manages an open and consultative policy process. As the guardian of the policy it is the regulator that takes action If someone breaches the policy by instructing the registry on what action to take.
Both of these companies are private sector and as the registry receives all the income, it pays the regulator a fee so that it can operate. A clean separation of duties.