(-home-email ... never should have started that:( )
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
