[address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region)

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

This is both against all current ripe policies and several people have pointed out that legal feasibility is very low at this time. However I understand from the thread that not everyone is convinced.

So that leaves:

(2) Regarding impact (i.e. affecting real routing)

The RPKI is not enabled automatically in routers. In fact if it is enabled the *information* is available in routers, but decisions are up to local policy.
There are at least three layers where local policy may be enforced:

	1) ROUTER

...by having additional configuration that overrides the rpki governed local preferences you just added yourself.

Essentially this is not so different from what's going on now. People use many rules, some are maintained manually, others are scripted eg based on IRR. The rpki adds a powerful default rule set that people can use, but it is not the end of all configuration. Just don't think that one should just set up the default 'prefer certified routes' rules and forget about all other rules and exceptions...

	2) VALIDATION TOOLS

If people express the demand it's fairly easy to add whitelisting functionality to validation tools. This would mean that the router would not know the difference between an AS-Prefix tuple coming from a ROA in the RPKI or an entry on the whitelist. The same router config could be used in both cases.

Having said that, please realise that the whitelist (presumably maintained by a 'trusted' third party), is in itself an attack vector. But the choice is yours...


	3) LOCAL TRUST ANCHOR (LTA)

See here:
http://tools.ietf.org/wg/sidr/draft-ietf-sidr-ltamgmt/

This draft explains a method that allows a 'relying party' to take information from one (or more) source RPKI trees and build up a locally consistent tree. The party doing this will essentially copy data and use his own keys. This allows the party to be *more* restrictive, or *less* restrictive with regards to ROAs, certificates, validity times etc. (many more details in the draft)

BBN has a reference implementation for this Local Trust Anchor handling.

Note that existing validation tools can use this new Trust Anchor as a starting point without any modification needed to the tools.

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..

	b) less restrictive

Third parties (many in theory) can set up and maintain public LTAs for others. If the RIPE NCC or any other player in the rpki is found to have inappropriately done something like revoking a certificate and re-allocating to someone else (as determined by the maintainer of the local trust anchor), then the maintainer can choose to keep using the old stuff.

Please note that if you trust someone else to maintain such an LTA for you, they may also be susceptible to LEAs, bribes, threats, mistakes etc. 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.


Regards,

Tim Bruijnzeels


Senior Software Engineer
RIPE NCC