Works for me. Though I’m not sure that there is a huge distinction between disabling BGPSec and taking the router offline since disabling BGPSec would trigger neighbor session resets for capability renegotiation unless we’ve specified otherwise in the protocol docs (doesn’t look like it in my quick skim), and most likely force an entirely ungraceful set of updates as the neighbors re-send their announcements with AS_PATH instead of BGPSEC_PATH.
Thanks, Wes On 5/12/14, 9:50 PM, "Sean Turner" <turn...@ieca.com> wrote: >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 <wesley.geo...@twcable.com> 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" <turn...@ieca.com> 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, internet-dra...@ietf.org 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 >>>> i-d-annou...@ietf.org >>>> 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 >>> sidr@ietf.org >>> 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. > 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
