My understanding is, that at least for the origination aspect, the "freshness" argument is that the keys get rolled periodically. And this has to occur on all the routers, with new keys published along with the key roll, and possibly a unique key per router.
So, the key roll frequency alone, there are operational scalability things to be concerned about. The keys in question (which go into ee-cert?) have to have private keys on routers, and public keys in RPKI, right? This isn't a "do it once when you build the router" thing, this is a live update of all aspects of the whole system (router + RPKI). As in, we should probably take at least some of the time allotted for the meta-discussion of, is private/public key really what we should be doing here? And if so, what are the ways that that can be done, with some analysis of scaling factors (order of magnitude at a minimum). E.g. it is one thing to say "sort the data", and quite another thing to say "When you sort the data, be aware that bubble-sort is really a bad idea, and quicksort is what you should use for N>6". (Some thought should be given to comparative analysis of non-PKI crypto mechanisms, such as hashing (SHA-256), including security, performance, and whether onboarding-offboarding-purging are needed.) Brian On Wed, Apr 11, 2012 at 2:08 PM, Chris Morrow <[email protected]>wrote: > > > On 04/11/2012 01:57 PM, Danny McPherson wrote: > > > > > >> I suppose, to me this looks like any other configuration thing you > >> do today on routers... beating the vendor over the head to support > >> sane (netconf? maybe?) methods for provisioning, is already done. > > > > So how we onboard, update, or purge information from RPKI and sign > > I think there are 2 things here: > 1) router-signing-cert (ee-cert?) > 2) rpki-digested-data (prefix + origin + cert-sig/etc) > > they don't have to get to the router in the same way, do they? (I > suppose they COULD, but that isn't necessarily mandatory and isn't how > it's currently spec'd) > > > stuff on n routers in z locations that 10's of thousands of others > > will evaluate in millions of routers to determine reachability of our > > wait, now you added a 3rd item: > 3) rpki data repository/publication-point > > > information is relegated to "out of scope" of SIDR? > > nope, I think the part I was talking about was JUST #1 above. you put > that cert on your router in some implementation-specific manner. Does > the IETF have to (should it?) state there are some operational security > concerns with this? ie: "It is probably a bad idea to copy/paste an > unencrypted private key on a telnet session across the open Internet to > the router." (that sort of thing could be placed in the bgpsec-ops doc, > it's not there as near as I can tell today). > > -chris > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
