On 9/16/13 2:20 PM, George, Wes wrote:
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. :-)
Luckily we all have email archives ;) How about:
OLD:
Note that cut/copy and paste operations for keys over a certain sizes is
error-prone.
NEW:
Note that cut/copy and paste operations over a SSH-proected CLI session
for keys over a certain sizes is error-prone; a less error process is to
use a USB or CF device to copy the key to and then insert the device in
to the router.
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.?
Replacing Ethernet with network no problem.
And, you're right the draft needs to say something about network
connectivity with the entity that requests the certificate and the CA.
I made the following changes:
s3.1:
OLD:
The PKCS#10 request, which includes the public key the router wants
certified, can be directly transferred to the RPKI CA over the network
if the router supports protocols such as FTP and HTTP [RFC2585] using
the application/pkcs10 media type [RFC5967] or EST (Enrollment over
Secure Transport) [I-D.ietf-pkix-est].
NEW:
The PKCS#10 request, which includes the public key the router wants
certified, can be directly transferred to the RPKI CA over the network
if the router supports protocols such as FTP and HTTP [RFC2585] using
the application/pkcs10 media type [RFC5967] or EST (Enrollment over
Secure Transport) [I-D.ietf-pkix-est]; direct transfer assumes that the
router has direct connectivity to the CA.
OLD:
The operator off-loads the PKCS#10 and uploads the request to their RPKI
software management tools.
NEW:
The operator off-loads the PKCS#10 and uploads the request to their RPKI
software management tools; external network connectivity is not required
if the operator acts as CA.
BTW - you'd still need external connectivity if the operator acts as the
CA to publish the certificate in the RPKI. I put some words in to that
affect.
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.
I'll have to give some thought to what other requirements there are for
key rollovers.
I'll go ahead and publish a new version with a blank section 4 to make
sure we knock out the other issues.
Thanks again for the review!
spt
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
