At Mon, 14 Nov 2011 18:45:09 +0800, Shane Amante wrote: > > More specifically, what I've been attempting to ask here is how one > configures, in one's _local_ RPKI cache (that syncs to the outside > world), /where/ the RIR's publication points are on Day 1. Do I > contact one RIR (which maintains a list of other RIR's publication > points) -or- each RIR individually to ask what is their publication > point? (If you can help provide an answer as to what is the > expectation on the operator, I can then potentially help to provide > text).
Starting point is most likely one or more Trust Anchor Locator (TAL) files, see draft-ietf-sidr-ta. On that glorious day when the RIRs and IANA have all their ducks in a row, there will be one public TAL for the root of the promised single tree; in the meantime, you'll likely have a small collection of TALs. Where do the TALs come from? Depends on whose TAL it is. Some of the RIRs publish their TALs on their web sites (one RIR, on the other hand, appears to be hiding the TAL for their pilot system in a locked filing cabinet in a disused lavatory in a subbasement with a sign reading "Beware Of Leopard", but that's neither here nor there). Those of us who write RPKI validation software collect these TALs when we can find and verify them, and I, at least, include them with my software. 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). _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr