On Wed, Apr 11, 2012 at 1:45 PM, Danny McPherson <[email protected]> wrote: > > On Apr 11, 2012, at 1:35 PM, Christopher Morrow wrote: > > > > From there, we can discuss the issue of, for example, HOW TO onboard and > purge signing and validating certificates to routers from the RPKI -- [I > suspect the intention was to use rpki-rtr protocol for this, but it doesn't > currently support it, nor are the security implications clear]. > > > > The rtr cert/ee-cert part was never planned/designed to be done via > rpki-rtr. > Ideally at provisioning time your ee-cert is dropped onto the box, > similar to base-config today. Potentially your fav vendor has a > methodology in their plan for this. I can't imagine it's too tough, > nor that it's exact specification needs to be in an IETF doc (since it > seems implementation specific). Could be wrong though. > > > It has huge implications on the scale and operations, particularly when
right: "Dear vendor, if you do this with a GUI only option I will stab you in the eye" 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. > considering how rollovers and other such changes are effectuated. Also, rollovers == acl-updates == routing-policy-updates == ntp server reconfig == .... normal router configuration processes. > decoupling these entirely from validating certificates means I've got two > mechanisms now for on-boarding [just] these things. I'd prefer not to leave or another configuration bit to sling, yes. > this to "magic happens" given that it's foundational to pretty much > everything else that's being built. copy my comment to vendors, into your rfp. > > sure, some modelling seems like a good thing here, I think this was > asked for at the mic in PAR as well, no? (in response to some > discussions with Sriram?) > > > Yep! > ok, so ... got proposal? I think Sriram is itching/looking for how to get a more reasoned approach to this (or that seemed to be his intent at the mic). > we can chat about that on-list or in the meeting... I suppose there's > a slew of milestones which are 'complete', there aren't really any > changes (that I planned) from an 'adding things' perspective. The > ops-documentation (see wiki) to me is probably NOT an ietf document, > again happy to talk at the meeting about that though. > > > > I'd be interested in lining out the longer-term deliverables for the group > on the list.. sure, shoot. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
