One document matched: draft-rogaglia-sidr-bgpsec-rollover-00.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY rfc2119 PUBLIC '' 
	'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
	<!ENTITY rfc4271 PUBLIC '' 
	'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml'>
	<!ENTITY rfc5101 PUBLIC ''
	'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5101.xml'>
	<!ENTITY rfc5102 PUBLIC ''
	'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5102.xml'>
	<!ENTITY rfc5226 PUBLIC '' 
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
	<!ENTITY ietf-sidr-pfx-validate SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sidr-pfx-validate-01.xml">
	<!ENTITY ietf-sidr-origin-validation-signaling SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sidr-origin-validation-signaling-00.xml">
	<!ENTITY ietf-pkix-cmc-serverkeygeneration SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pkix-cmc-serverkeygeneration-00.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" ipr="trust200902" docName="draft-rogaglia-sidr-bgpsec-rollover-00"
	updates="">

<front> 
	<title abbrev="BGPSEC roll-over">BGPSEC router key roll-over as an alternative to beaconing</title>
		<author initials="R.G.M." surname="Gagliano" fullname="Roque 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 initials="K.P." surname="Patel" fullname="Keyur 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 initials="B.W." surname="Weis" fullname="Brian 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="March" year="2012" />
<abstract>
<t>The current BGPSEC draft documents do not specifies a key roll-over process for routers. This document describes a possible key roll-over process and explores its impact to mitigate replay attacks and eliminate the need for beaconing in BGPSEC.</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 roll-over (or re-keying) is the process of changing the router's key pair, issuing the correspondent new End-Entity certificates and revoke the old one. This process will need to happen at regular intervals normally due to local policies at each network.</t>
<t>During a roll-over process, a router needs to generate BGP UPDATE messages in order to signal the new key to be used to its neighbors. So, intuitively, a frequent key roll-over process has similar effects as the beaconing process proposed by the BGPSEC base documents to protect a BGPSEC attribute against a re-play attack. However, there are a number of operational details to be considered if the expire time field in the BGPSEC attribute is removed.</t>
<t>This document details a possible key roll-over process in BGPSEC and explores the operational environment where key roll-overs could be used as a protection against a re-play attach against BGPSEC</t>
</section>

<section anchor="BGPSEC" title="Key Roll-over in BGPSEC">
<t>The key roll-over process in BGPSEC has not been well defined yet. However, this will be a mandatory process due to some of the following causes:
<list style="hanging" hangIndent="6">
     <t hangText="BGPSEC scheduled roll-over:">BGPSEC certificates have an expiration date (NotValidAfter). Although it is possible to generate a new certificate without changing the key pair, it is normally good practice to adopt the policy of using a new key pair in every roll-over event.</t>
     <t hangText="BGPSEC certificate fields changes:">A BGPSEC certificate field's information (such as the ASN or the Subject) may need to be changed. The normal process requires the roll-over of the old certificate with a new key pair and the revocation of the old certificate.</t>
     <t hangText="BGPSEC emergency roll-over">Some special circumstances (such as a compromised key) may require the roll-over of a BGPSEC certificate.</t>
</list>
</t>
<t>It should be clear at this point that a key roll-over process is required for BGPSEC. The next section describes how this process may be implemented.</t>


<section anchor="re-keying" title="A proposed process for BGPSEC key roll-over">
<t>The BGPSEC key roll-over process should be very tighten to the key provisioning mechanisms that would be in place. The key provisioning mechanisms for BGPSEC are not yet documented. We will assume that such an automatic provisioning mechanism will be in place (a possible provisioning mechanism when the private key lives only inside the BGP speaker is the Enrollment over Secure Transport (EST). This protocol will allow BGPSEC code to include automatic re-keying scripts with minimum development cost.</t>
<t>When the same private key is shared by different routers, a mechanism to distribute the private key will need to be implemented. A possible solution may include the transmission of the private key over a secure channel. The PKIX WG has started work on this sense by adopting <xref target="I-D.ietf-pkix-cmc-serverkeygeneration"/> </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 order to accomplish this goal, the new key pair and certificate will need to be generated and published on the correspondent RPKI repository. This process will vary in every environment as it will depend on where the keys are located (either in every router or on a centralized server), if the RPKI CA is hosted at the ISP or at an external party (i.e. needs to use the RPKI provisioning protocol) and finally if the repository is also local or hosted (i.e. will need to use the RPKI-Repository protocol.)</t>   
	 <t>Stage Period: A stage 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. Design documents mention a lower limit of 24 hours. If rollovers will be done frequently and we want to avoid the stage period in case of emergency rollover needs, an administrator can always provision two certificate for every router. In this case when the rollover operation is needed, the cache servers around the globe would already have the new keys.</t>
	 <t>Twilight: At this moment, the BGP speaker that uses the key 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.</t>
	 <t>CRL Publication: As part of the rollover process, a CA MAY decide that it will publish the serial number of the OLD BGPSEC certificate on its CRL. It may also be the case that the CA will just let the certificate to expire and not update its CRL.</t>
	 <t>RPKI-Router Protocol Withdrawal: Either due to the inclusion of the OLD certificate serial number or the expiration of the certificate's validation, the RPKI cache servers around the globe will need to communicate to its RTR peers that the OLD certificate's public key is not longer valid (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 WITHDRAWS (either implicit or explicit).</t>
</list>
</t>
<t>To conclude this section, we can say that the proposed rollover mechanism will depend on the existence of an automatic provisioning process for BGPSEC certificates, that it will required a staging mechanism given by RPKI propagation time of around 24hours and that it will generate BGP UPDATES for all prefixes in the router been re-keying.</t>
</section>

</section>

<section anchor="replay" title="BGPSEC key rollover as a measure against replays attacks in BGPSEC">
<t>There are two typical measures to mitigate replay attacks: addition of a timestamp or addition of a serial number. Currently BGPSEC offers a timestamp (expiration time) as a protection against re-play attacks of BGPSEC messages. The process requires all BGP Speakers that originate a BGP UPDATE to beaconing the message before its expiration time. This requirement changes a long standing BGP operation practice and the community have been searching for alternatives.</t>

<section anchor="beaconing" title="BGPSEC beaconing challenges">
<t>To be completed</t>
</section>

<section anchor="requirements" title="BGPSEC Re-play attack window requirement">
<t>The BGPSEC Ops document give some ideas of requirements for the re-play attack in BGPSEC. For the vast majority of the prefixes, the requirement will be in the order of days or weeks. For a very small fraction, but critical, 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 key rollover provide us a similar protection against re-play 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 router re-keying is the edge router of the origin AS. 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 inconvenient in the process.</t> 
<t>For a transit AS that also originates its BGP UPDATES for its own prefixes, the key rollover process may generate a large number of UPDATE messages (even the complete 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 should be frequently rolled-over.</t>
<t>Advantage of Re-keying as re-play attack protection mechanism:
<list style="numbers">
	 <t>Does not require beaconing</t>
     <t>All timestamps policies are maintained in RPKI</t>
     <t>Additional administrative cost is paid by the provider that wants to protect its infrastructure</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 re-play attack protection mechanism:
<list style="numbers">
     <t>More administrative load due to frequent rollover, although how frequent is still not clear.</t>
     <t>Minimum window size bounded by RPKI propagation time to RPKI caches. If pre-provisioning done ahead of time, it means 24 hours minimum in paper. However, more experimentation is needed when RPKI and cache servers are more massively deployed.</t>
	 <t>Increases dynamic 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>None yet</t>
</section>
</middle>
<back>

<references title="Normative References"> 
&rfc2119;&rfc4271;&rfc5101;&rfc5102;
</references>

<references title="Informative References">
&rfc5226;&ietf-pkix-cmc-serverkeygeneration; &ietf-sidr-origin-validation-signaling; &ietf-sidr-pfx-validate;
</references>
</back>
</rfc>