Re: [sidr] WGLC: draft-ietf-sidr-origin-ops

[Danny McPherson <[e-mail]>]

On Nov 14, 2011, at 8:37 AM, Rob Austein wrote:

> Ultimately, the problem is the same as distributing DNSSEC TAs, or any
> other TA for that matter.  Pretty much by definition, these things
> have to be configured outside the automated system, because they're
> the bootstrap data.  Inclusion in distributions of software using the
> system seems to be the most common way, but one could envision other
> methods (T shirts handed out at IETF or *OG meetings, publication in
> major newspapers, perhaps as QR codes, invent your own mechanism --
> the key point is that grounds for believing the TAL come from outside
> the system we're trying to bootstrap).

However, in the interim (until we have a single RPKI root), the origin-ops 
draft should provide some guidance about how an RP should have the 
capability to verify "look-aside" (ugh) what resources an "INR" holds, and 
recommend that they only accept associated RPKI data for those 
resources.  The onus cannot be on the RP to resolve this themselves at 
on a global scale.

The model where each of the TAs in the TAL can assert what it is they're 
authoritative for is even mode broken than the browser/SSL/CA issues 
that we're trying to fix with DANE (the attacker at least has to be on-path 
there, before they consult a compromised CA).

Furthermore, pending the outcome of the discussion in the other thread
I started related to this topic and local TAs, the origin-ops draft should also 
include some discussion about multiple parties involved in LTA-esque 
functions (or extra TALs with "constraints") to preserve inter-domain 
connectivity during putative RPKI override/bypass functions for source, 
destination, and intermediate networks.

-danny