Hi Tim, thank you for bringing forth clarity on LTA and answering the question of the availability of the code. On Tue, May 10, 2011 at 10:06 AM, Tim Bruijnzeels <tim@ripe.net> wrote:
Hello WG,
I am RIPE NCC staff, but having worked on this subject for some time now I have some technical input to the discussion that I would really like to share:
On May 10, 2011, at 3:20 PM, Rob Evans wrote:
Stop using them :) If it's not an LEA forcing you to do something then you always have this choice.
...and this is a point worth stressing. If things do "go bad," it isn't the end of the Internet, but we can bail on using the RPKI as it is implemented at the time. It's all about co-operation. :-)
The 'risk' of the RIPE NCC going rogue under legal coercion could be modeled as the product of the (1) 'likelihood' and the (2) 'impact'
(1) Regarding likelihood:
- revoking certs is not enough - a top entity in the pki chain like the ripe ncc would also have to reallocate resources so that a new valid roa may be made for a different as and that network be announced
(snip)
3) LOCAL TRUST ANCHOR (LTA) http://tools.ietf.org/wg/sidr/draft-ietf-sidr-ltamgmt/ This technique can be used in two ways:
a) more restrictive
This technique enables LEA to set up their own TA tree under their own control. This can easily be done in the absence of a community run repository. In fact it's easiest on LEAs if the techniques are available (and they are coming out of the IETF now), and there are no disturbing other versions of the truth out there.. a whole lot less to delete..
Excellent argument against hierarchical policy on the Internet, from my point of view.
b) less restrictive
Third parties (many in theory) can set up and maintain public LTAs for others. (threats to hierarchical systems removed) But the choice is yours... and if in fact more than one party is doing this it will be fairly easy to switch. You will have to ask yourself who *you* trust most.
What I trust *the most* is for the proper holders of a resource to attest to their own resource(s) *themselves*. If we allow ourselves the thought exercise to design a (BGP) routing security system without constraints and from scratch, would you agree the base model is something along the lines of the following? - "I can prove I have resource X and the right to originate it [into the network]", for origination, which may be a subset of: - "I can prove I have the right to announce resource X", for propagation/paths (which may or may not scale badly -- for example, the right or endorsement to re-announce a resource could be conceived as transferable from A to B, (!= NO_EXPORT, but related), possibly with transferability of the right to transfer the right to announce, as well :) (and if we get real picky A may steer the endorsement to only certain peers of B) ), in combination with, - a method for B to verify A:s proof of right to announce X, and, - for C (a peer of B), a method to verify B's right-to-announce X (functioning as endorsements). The gravest failure mode in this model I can think of is that A may lose its X against its will. Kind Regards, Martin