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

[Sean Turner <[e-mail]>]

Wes,

Randy and I bashed some text around; would this work:

When it is decided that an active router key is to be revoked, the
process of requesting the CA to revoke, the process of the CA
actually revoking the router’s certificate, and then the process of
rekeying/renewing the router’s certificate, (possibly distributing a
new key and certificate to the router), and distributing the status
takes time during which the operator must decide how they wish
to maintain continuity of operations, with or without the compromised
private key, or whether they wish to to bring the router offline to
address the compromise.  

Keeping the router operational and BGPsec-speaking is the ideal goal,
but if operational practices do not allow this then reconfiguring the
router to disabling BGPsec is likely preferred to bringing the router
offline.

Routers which support more than one private key, where one is
operational and the other(s) are soon-to-be-opertional, facilitate
revocation events because the operator can configure the router to make
a soon-to-be-operational key operational, request revocation of the
compromised key, and then make a new soon-to-be-operational key, all
hopefully without needing to take offline or reboot the router.  For
routers which support only one operational key, the operators should
create or install the new private key, and then request revocation of
the compromised private key.

spt

On Apr 30, 2014, at 16:26, George, Wes <[e-mail]> wrote:

> This update address my comments on the document, and I think it’s in good
> shape now. The new section 4 is really good. The one thing I might
> recommend adding for completeness is a few additional words around
> revocation process at the end of section 4, specifically if there is any
> difference or recommendation in process for make before break (provision
> new key, then revoke old) or when that may not be a good idea compared
> with the risk of outage caused by revoking and then rekeying. It may be as
> simple as saying something similar to the above about whether a router
> supports multiple private keys or not, but I’m not sure if there are
> additional considerations that need to be discussed.
> 
> Thanks,
> 
> Wes
> 
> 
> 
> On 4/29/14, 10:14 AM, "Sean Turner" <[e-mail]> wrote:
> 
>> Hi,
>> 
>> This version includes a new section 4 that addresses key management
>> (i.e., keep a timer to make sure your cert doesn’t expire).  There’s also
>> some editorial/readability corrections.  Please review as the authors
>> think this version pretty much wraps up what we wanted to say.
>> 
>> spt
>> 
>> On Apr 29, 2014, at 10:10, [e-mail] wrote:
>> 
>>> 
>>> 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
>>>       Authors         : Sean Turner
>>>                         Keyur Patel
>>>                         Randy Bush
>>>     Filename        : draft-ietf-sidr-rtr-keying-05.txt
>>>     Pages           : 10
>>>     Date            : 2014-04-29
>>> 
>>> Abstract:
>>>  BGPsec-speaking routers are provisioned with private keys to sign BGP
>>>  messages; the corresponding public keys are published in the global
>>>  RPKI (Resource Public Key Infrastructure) thereby enabling
>>>  verification of BGPsec messages.  This document describes two ways of
>>>  provisioning the public-private key-pairs: 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-05
>>> 
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-05
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
>> _______________________________________________
>> sidr mailing list
>> [e-mail]
>> 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.