One document matched: draft-ietf-sidr-bgpsec-rollover-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc6489 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6489.xml">
<!ENTITY ietf-pkix-cmc-serverkeygeneration SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pkix-cmc-serverkeygeneration-00.xml">
<!ENTITY ietf-sidr-bgpsec-reqs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sidr-bgpsec-reqs-03.xml">
<!ENTITY ietf-sidr-bgpsec-ops SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sidr-bgpsec-ops-05.xml">
<!ENTITY ietf-sidr-rtr-keying SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sidr-rtr-keying-00.xml">
<!ENTITY ietf-pkix-est SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pkix-est-02.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-ietf-sidr-bgpsec-rollover-01"
ipr="trust200902" updates="">
<front>
<title abbrev="BGPSEC rollover">BGPSEC router key rollover as an
alternative to beaconing</title>
<author fullname="Roque Gagliano" initials="R.G.M." surname="Gagliano">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Avenue des Uttins 5</street>
<city>Rolle</city>
<region>VD</region>
<code>1180</code>
<country>Switzerland</country>
</postal>
<email>rogaglia@cisco.com</email>
</address>
</author>
<author fullname="Keyur Patel" initials="K.P." surname="Patel">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Driv</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>CA</country>
</postal>
<email>keyupate@cisco.com</email>
</address>
</author>
<author fullname="Brian Weis" initials="B.W." surname="Weis">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Driv</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>CA</country>
</postal>
<email>bew@cisco.com</email>
</address>
</author>
<date month="October" year="2012"/>
<abstract>
<t>BGPSEC will need to address the impact from regular and emergency
rollover processes for the BGPSEC End-Entity (EE) certificates that will
be performed by Certificate Authorities (CAs) participating at the
Resource Public Key Infrastructure (RPKI). This document provides
general recommendations for that process and specifies how this process
is used to control BGPSEC's window of exposure to replay attacks.</t>
</abstract>
</front>
<middle>
<section title="Requirements notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
</section>
<section title="Introduction">
<t>In BGPSEC, a key rollover (or re-keying) is the process of changing a
router's key pair (or pairs), issuing the corresponding new End-Entity
certificate and (if the old certificate is still valid) revoking the old
certificate. This process will need to happen at regular intervals,
normally due to local policies at each network. This document provides
general recommendations for that process that Certificate Practice
Statements (CPS) documents MAY reference.</t>
<t>When a router receives (or creates depending of the key provisioning
mechanism to be selected) a new key pair, this key pair will be used to
sign new BGP UPDATE messages that are originated or that transit through
the BGP speaker. Additionally, the BGP speaker MUST refresh its outbound
BGP UPDATE messages to update its respective BGPSEC attribute by
including the correspondent signature performed with the new key. When
the rollover process finishes, the old BGPSEC certificate (and its key)
will not longer be valid and thus any BGP UPDATE that includes a BGPSEC
attribute with a signature performed by the old key will be invalid.
Consequently, if the router do not refresh its outbound BGP UPDATE
messages, routing information may be lost after the rollover process is
finished.</t>
<t>As a key rollover process invalidates BGP UPDATE messages signed with
the old key, frequent key rollover processes could be used to control
BGPSEC's window of exposure to replay attacks as required by <xref
target="I-D.ietf-sidr-bgpsec-reqs"/>. This document explores the
operational environment to achieve this goal.</t>
<t>In <xref target="I-D.ietf-sidr-rtr-keying"/>, the "operator-driven"
method is introduced and it enables that a key pair could be shared
among different BGP Speakers. In this scenario, the roll-over of the
correspondent BGPSEC certificate will impact all the BGP Speakers
sharing the same private key.</t>
</section>
<section anchor="BGPSEC" title="Key rollover in BGPSEC">
<t>A BGPSEC EE certificate (as any X.509 certificate) will required a
rollover process due to causes such as: <list hangIndent="6"
style="hanging">
<t hangText="BGPSEC scheduled rollover:">BGPSEC certificates have an
expiration date (NotValidAfter) that requires a frequent rollover
process. The validity period for these certificates is typically
expressed at the CA's CPS document.</t>
<t hangText="BGPSEC certificate fields changes:">Information
contained in a BGPSEC certificate (such as the ASN or the Subject)
may need to be changed.</t>
<t hangText="BGPSEC emergency rollover">Some special circumstances
(such as a compromised key) may require the replacement of a BGPSEC
certificate.</t>
</list></t>
<t>In most of these cases (probably excepting when the key has been
compromised), it is possible to generate a new certificate without
changing the key pair. This practice simplifies the rollover process as
the correspondent BGP speakers do not even need to be aware of the
changes to its correspondent certificate. However, not replacing the
certificate key for a long period of time increases the risk that the
certificate key may be compromised.</t>
<section anchor="re-keying"
title="A proposed process for BGPSEC key rollover">
<t>The BGPSEC key rollover process should be dependent of the key
provisioning mechanisms that would be in place. The key provisioning
mechanisms for BGPSEC are not yet fully documented (see <xref
target="I-D.ietf-sidr-rtr-keying"/> as a work in progress document).
We will assume that an automatic provisioning mechanism will be in
place. (A possible provisioning mechanism is the Enrollment over
Secure Transport (EST) <xref target="I-D.ietf-pkix-est"/>). That
protocol will allow BGPSEC code to include automatic re-keying scripts
with minimum development cost.</t>
<t>If we work under the assumption that an automatic mechanism will
exist to rollover a BGPSEC certificate, a possible process could be:
<list style="numbers">
<t>New Certificate Pre-Publication: The first step in the rollover
mechanism is to pre-publish the new public key in a new
certificate. In order to accomplish this goal, the new key pair
and certificate will need to be generated and published at the
appropriate RPKI repository publication point. The details of this
process will vary as they depend on whether the keys are assigned
per-BGP speaker or shared, whether the keys are generated on each
BGP speaker or in a central location and wether the RPKI
repository is locally or externally hosted.</t>
<t>Staging Period: A staging period will be required from the time
a new certificate is published in the RPKI global repository until
the time it is fetched by RPKI caches around the globe. The exact
minimum staging time is not clear and will require experimental
results from RPKI operations. RPKI repository design documents
mention a lower limit of 24 hours (NOTE: need reference only one I
found is the ops document). If rollovers will be done frequently
and we want to avoid the stage period, an administrator can always
provision two certificate for every router. In this case when the
rollover operation is needed, the relying parties around the globe
would already have the new keys. A staging period may not be
possible to implement during emergency key rollover, in which case
routing information may be lost.</t>
<t>Twilight: At this moment, the BGP speaker that hold the private
key that has been rolled-over will stop using the OLD key for
signing and start using the NEW key. Also, the router will
generate appropriate BGP UPDATES just as in the typical operation
of refreshing out-bound BGP polices. This operation may generate a
great number of BGP UPDATE messages (due to the need to refresh
BGP outbound policies). In any given BGP SPEAKER, the Twilight
moment may be different for every peer in order to distribute the
system load (probably in the order of minutes to avoid reaching
any expiration time).</t>
<t>Certificate Revocation: This is an optional step. As part of
the rollover process, a CA MAY decide to revoke the OLD
certificate by publishing its serial number on the CA's CRL. On
the other side, the CA will just let the OLD certificate to expire
and not revoke it. This chose will depend on the reasons that
motivated the rollover process.</t>
<t>RPKI-Router Protocol Withdrawals: Either due to the revocation
of the OLD certificate or to the expiration of the OLD
certificate's validation, the RPKI relying parties around the
globe will need to communicate to their RTR peers that the OLD
certificate's public key is not longer valid (rtr withdrawal
message). It is not documented yet what will be a router's
reaction to a RTR withdrawal message but it should include the
removal of any RIB entry that includes a BGPSEC attribute signed
with that key and the generation of the correspondent BGP
WITHDRAWALs (either implicit or explicit).</t>
</list>The proposed rollover mechanism will depend on the existence
of an automatic provisioning process for BGPSEC certificates. It will
require a staging mechanism based on the RPKI propagation time of
around 24hours, and it will generate BGP UPDATES for all prefixes in
the router been re-keyed.</t>
<t>The first two steps (New Certificate Pre-Publication and Staging
Period) could happen ahead of time from the rest of the process as
each network operators could prepare itself to accelerate a future key
roll-over.</t>
<t>When a new BGPSEC certificate is generated without changing its
key, steps 3 (Twilight) and 5 (RPKI-Router Protocol Withdrawals)
SHOULD not be executed.</t>
</section>
</section>
<section anchor="replay"
title="BGPSEC key rollover as a measure against replays attacks in BGPSEC">
<t>There are two typical generic measures to mitigate replay attacks in
any protocol: the addition of a timestamp or the addition of a serial
number. Currently BGPSEC offers a timestamp (expiration time) as a
protection against re-play attacks of BGPSEC attributes. The process
requires all BGP Speakers that originate a BGP UPDATE to re-advertise
("beacon") the message before it expires. This requirement changes a
long standing BGP operational practice and the community has been
searching for alternatives.</t>
<section anchor="requirements"
title="BGPSEC Replay attack window requirement">
<t>In <xref target="I-D.ietf-sidr-bgpsec-reqs"/> Section 4.3, the need
to limit the vulnerability to replay attacks is described. One
important comment is that during a windows of exposure, a replay
attack is effective only if there was a downstream topology change
that makes the signed AS path not longer current. In other words, if
there have been no topology changes, no security threat comes from a
replay of a BGP UPDATE message (the signed information is still
valid)</t>
<t>The BGPSEC Ops document <xref target="I-D.ietf-sidr-bgpsec-ops"/>
gives some ideas of requirements for the size of the BGPSEC windows of
exposure to replay attacks. At that document, it is stated that for
the vast majority of the prefixes, the requirement will be in the
order of days or weeks. For a very small but critical fraction of the
prefixes, the requirement may be in the order of hours.</t>
</section>
<section anchor="proposal"
title="BGPSEC key rollover as a mechanism to protect against replay attacks">
<t>The question we would like to ask is: can the key rollover process
earlier described provide a similar protection against replay attacks
without the need for beaconing?</t>
<t>The answer is that YES when the window requirement is in the order
of days and the BGP speaker re-keying is the edge router of the origin
AS and the full process is completed (i.e. the OLD and NEW certificate
do not share the same key). By using re-keying, you are letting the
BGPSEC certificate validation time as your timestamp against replay
attacks. However, the use of frequent key rollovers comes with an
additional administrative cost and risks if the process fails. As
documented before, re-keying should be supported by automatic tools
and for the great majority of the Internet it will be done with good
lead time to correct any risk.</t>
<t>For a transit AS that also originates BGP UPDATES for its own
prefixes, the key rollover process may generate a large number of
UPDATE messages (even the complete Default Free Zone or DFZ). For this
reason, it is recommended that routers in this scenario been
provisioned with two certificates: one to sign BGP UPDATES in transit
and a second one to sign BGP UPDATE for prefixes originated in its AS.
Only the second certificate (for prefixes originated in its AS) should
be rolled-over frequently as a means of limiting replay attach
windows. The transit BGPSEC certificate is expected to be longer
living than the origin BGPSEC certificate.</t>
<t>Advantage of Re-keying as replay attack protection mechanism: <list
style="numbers">
<t>Does not require beaconing</t>
<t>All expiration policies are maintained in RPKI</t>
<t>Most of the additional administrative cost is paid by the
provider that wants to protect its infrastructure (RP load will
increase as there is a need to validate more BGPSEC
certificates)</t>
<t>Can be implemented in coordination with planned topology
changes by either origin ASes or transit ASes (if I am changing
providers, I rollover)</t>
<t>Eliminates the discussion on who has the authority over the
expiration time</t>
</list></t>
<t>Disadvantage of Re-keying as replay attack protection mechanism:
<list style="numbers">
<t>More administrative load due to frequent rollover, although how
frequent is still not clear. Some initial ideas in <xref
target="I-D.ietf-sidr-bgpsec-ops"/></t>
<t>Minimum window size bounded by RPKI propagation time to RPKI
caches for new certificate and CRL (2x propagation time). If
pre-provisioning done ahead of time the minimum windows size is
reduced (to 1x propagation time for the CRL). However, more
experimentation is needed when RPKI and RPs are more massively
deployed.</t>
<t>Increases dynamics and size of RPKI repository.</t>
<t>More load on RPKI caches, but they are meant to do this
work.</t>
</list></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>No IANA considerations</t>
</section>
<section title="Security Considerations">
<t>No security considerations.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>We would like to acknowledge Randy Bush, Sriram Kotikalapudi, Stephen
Kent and Sandy Murphy.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc6489;
</references>
<references title="Informative References">
&ietf-pkix-cmc-serverkeygeneration;
&ietf-pkix-est;
&ietf-sidr-bgpsec-reqs;
&ietf-sidr-bgpsec-ops;
&ietf-sidr-rtr-keying;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:48:06 |