I gave this a review since I am one of the folks who raised my hand as willing to be the resident PKI n00b to make sure that things like this are clear to "router guys" who are dealing with PKI for the first time outside of maybe generating the SSH keys for tty access to a router.
The second paragraph of the intro, starting with the sentence "The router-driven model is most..." is difficult to parse (grammatically). I recommend re-wording to eliminate "often times for human subscribers" from the middle of the phrase and generally streamline the point being made here. Editorial nit: multiple instances of %s/drive/driven 3. instead of serial/craft, I'd just say console. Or more generally, you could refer to in-band management vs out of band, as that covers a wider set of scenarios than specifically referring to an Ethernet port and a serial port. Yes, that doesn't exactly cover the hair-split when people use a management Ethernet port connected to a separate management network for "in band" (non-console) management of the device, but maybe that's clear enough, I don't know. I also don't think proprietary is the right word. Console access via a terminal server is pretty universal, and unless there's some sort of a tool pushing out the initial config snippets over console to bootstrap the box so that it can talk to it inband and finish the provisioning, "operator going typey-typey on a terminal" is definitely not proprietary either. Another thought - console access via remote terminal server isn't actually secure in every case. In a typical setup you have: User host -> (ssh) bastion/jump box -> (telnet) local terminal server -> RS232/USB connection to console Unless the path between the jump box and the local terminal server is such that it is nearly impossible to sniff the traffic (private network, direct connection, etc) using this to provision sensitive config might be ill-advised. Might be worth explicitly stating that for this reason, use of the console to provision the SIDR keys is NOT recommended. It's not clear to me whether the method being described in this first part of section 3 is actually important. Do you actually have to do something different in the way that you bring a router online (get it basic connectivity to the network) in this process in order to preserve proper security and trust for the keys, or is this just illustrating a typical process to provision a router from bare metal such that you have secure access to it to further manipulate the configuration? Is certificate-based authentication (instead of password auth) a MUST, or a SHOULD, or does it matter? If this is just illustrating a standard example, you can probably just say something like "this assumes that standard (BCP?) procedures have been followed to initially configure the router for secure remote access, via either inband or out of band means" and then just specify that it's necessary to have the secure connection between the router and operator before the router keying for SIDR is done ( because....). Some of this is down in the security considerations today, and I think it's important to actually discuss it here instead since it's basically a critical part of the provisioning process. The key (pun very much intended) thing here is to highlight things that are different from normal provisioning and explain why they're important. 3.1 - wouldn't it be sFTP/SCP or HTTPS or some similar? Direct/indirect makes sense, but the process for indirect transfer is a little light on details - what steps must be taken to ensure that the keys are not compromised in this transfer, either from the router or to the RPKI CA? Even a reference to section 5 might be enough to cover this. Also, I don't follow your last sentence "...linkage between private key and a router..." - why is that important? 3.2 "installed over the ssh session..." - are we talking simple copy and paste of a huge string of text representing the key, or is it actually SCP/SFTP of a file that is then read into the router's config via additional commands? If you're talking copy/paste, it's probably worth warning that for keys over a certain size, this method is error-prone. I've seen a lot of mangled config because someone exceeded a paste buffer when trying to copy/paste a config, especially over a 9600 bps console at the other end of 90ms of latency. 5. when you talk about offload methods, you should probably specify the required/recommended security precautions associated with handling the key so that it isn't intercepted across the transfer method used (e.g. use SNMPv3 with encryption, use sFTP/SCP, CLI with SSH, etc, as well as any considerations around chain of possession and level of trust as the keys are stored and transferred between old and new box. There are a lot of risk factors if a tech is transferring it to his (possibly compromised) laptop when compared with transferring to parts of the infrastructure (a config repository server, for example) that are properly hardened. Also need to discuss sneakernet transfer, where I dump the key to a local storage device so that the tech can plug it into the new RP/RE and upload it that way. This is sometimes important if the box is having issues and as a result has limited connectivity to offload the keys. Any considerations to ensure proper security in a transfer like that? Thanks, Wes George > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Saturday, February 23, 2013 10:41 AM > To: [email protected] > Cc: [email protected] > Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Inter-Domain Routing Working > Group of the IETF. > > Title : Router Keying for BGPsec > Author(s) : Sean Turner > Keyur Patel > Randy Bush > Filename : draft-ietf-sidr-rtr-keying-01.txt > Pages : 9 > Date : 2013-02-23 > > Abstract: > BGPsec-speaking routers must be provisioned with private keys and the > corresponding public key must be published in the global RPKI > (Resource Public Key Infrastructure). This document describes two > ways of provisioning public/private keys, router-driven and operator- > driven. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr 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 [email protected] https://www.ietf.org/mailman/listinfo/sidr
