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 <da...@tcb.net> 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 > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
