Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt

[Sean Turner <[e-mail]>]

On 9/16/13 2:20 PM, George, Wes wrote:
>> From: [e-mail] [mailto:[e-mail]] 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.
>