(if the ads want off this train, speak up) On Wed, Apr 11, 2012 at 2:23 PM, Brian Dickson <[email protected]> wrote: > My understanding is, that at least for the origination aspect, the > "freshness" argument is that the keys get rolled periodically.
they can get rolled periodically, sure. That could be as often as 1/yr or 1/N yrs... your (operators) choice, within reason... which the mic discussion also spun around in PAR. > 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. could be per router? per POP? per METRO? per REGION? per Continent? per Country? per ASN? > So, the key roll frequency alone, there are operational scalability things > to be concerned about. Sure, just like updating prefix-lists for all your customers today... which L(3) does ~4x/day? NTTA does ~6x/day? > The keys in question (which go into ee-cert?) have to have private keys on > routers, and public keys in RPKI, right? > Sure, you are updating 2 things here, potentially. Or pulling data from a single store to put in 2 places (depends on your perspective and systems/OSS I suppose). > 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). there are 2 systems there... with potentially very different operational requirements. we already all manage routers in the field ... this is just another 'prefix-list' or 'acl' or ... (or I hope it's just like that anyway - see 'stab in eye' vendor comment) > 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.) I think that ship sailed... but it seems like a fun list discussion. -chris > 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 > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
