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

[Christopher Morrow <[e-mail]>]

Reviving a zombie thread...
So,
Where does this set of comments end us? Are the updates put in between
11/11 and 03/12 taking care of the discussion? or are there still
things to wrangle?

I think, given the length and breadth of discussion here we'd all do
to re-read and re-WGLC this doc once things are settled.

-chris
<cochair>

On Mon, Nov 14, 2011 at 5:57 PM, Danny McPherson <[e-mail]> wrote:
>
> 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
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr