> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of > Sean Turner > > Better late than never? > > I believe this version addresses Wes' comments (if he can remember them > :) > [WEG] I had to go find the email, but yes, this addresses my comments, with one exception - we'd talked about sneakernet key transfers (copy to USB or CF and move the card, copy back to restore) in the hardware swap case. I don't know if you want to explicitly mention that in section 5 or not. I'd sort of prefer that to hoping that router vendors understand that etc. = sneakernet. :-)
Did another review, found a few more mostly minor things: Section 3.1 "...can be directly transferred to the RPKI CA over the Ethernet port..." I'd be less specific here and say something like "over the network" since "the Ethernet port" is both ambiguous and overly specific. Also you probably need to say something like "assuming that the router has direct connectivity to the CA at this point in the provisioning process" -- for that matter, it might be useful for both 3.1 and 3.2 if you were explicit about what the router needs to be able to talk to both inside and outside of the provider network at this stage of the provisioning process to make sure that none of these validation and key exchange steps fail on account of not being able to talk to the right server. In other words, which of these validations are local and which require communicating with an external TA, CA, etc.? The draft currently skips from section 3 to section 5. I might suggest that section 4 should cover key rolls (if, for example, the private key is compromised somehow, or if you simply wish to do this periodically), since you've covered provisioning a new router, and then go to scenarios where you want to swap hardware and keep the same keys. I don't think there's a lot that is different between initial provisioning and doing a key roll, but if there is anything different, it's worth highlighting, especially if there are gotchas around making sure that you don't accidentally break validation when you swap router keys (overlapping expiry, etc), and if there isn't, it's worth mentioning that the process is the same. A few grammar nits as well, but I expect the RFC editor can handle those. :-) > > Title : Router Keying for BGPsec > > Author(s) : Sean Turner > > Keyur Patel > > Randy Bush > > Filename : draft-ietf-sidr-rtr-keying-02.txt > > Pages : 9 > > Date : 2013-09-12 > > [WEG] Nice job in making this more accessible for those of us less familiar with PKI wrangling, this is a really helpful draft. Wes This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
