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
