draft-ietf-sidrops-bgpsec-rollover-03.txt   draft-ietf-sidrops-bgpsec-rollover-04.txt 
Network Working Group B. Weis Network Working Group B. Weis
Internet-Draft R. Gagliano Internet-Draft R. Gagliano
Intended status: Standards Track Cisco Systems Intended status: Best Current Practice Cisco Systems
Expires: April 30, 2018 K. Patel Expires: June 14, 2018 K. Patel
Arrcus, Inc. Arrcus, Inc.
October 27, 2017 December 11, 2017
BGPsec Router Certificate Rollover BGPsec Router Certificate Rollover
draft-ietf-sidrops-bgpsec-rollover-03 draft-ietf-sidrops-bgpsec-rollover-04
Abstract Abstract
Certification Authorities (CAs) within the Resource Public Key Certification Authorities (CAs) within the Resource Public Key
Infrastructure (RPKI) manage BGPsec router certificates as well as Infrastructure (RPKI) manage BGPsec router certificates as well as
RPKI certificates. The rollover of BGPsec router certificates must RPKI certificates. The rollover of BGPsec router certificates must
be carefully performed in order to synchronize the distribution of be carefully performed in order to synchronize the distribution of
router public keys with BGPsec Update messages verified with those router public keys with BGPsec Update messages verified with those
router public keys. This document describes a safe rollover process, router public keys. This document describes a safe rollover process,
as well as discussing when and why the rollover of BGPsec router as well as discussing when and why the rollover of BGPsec router
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2018. This Internet-Draft will expire on June 14, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Introduction 2. Introduction
In BGPsec, a key rollover (or re-key) is the process of changing a In BGPsec, a key rollover (or re-key) is the process of changing a
router's BGPsec key pair (or key pairs), issuing the corresponding router's BGPsec key pair (or key pairs), issuing the corresponding
new BGPsec router certificate and (if the old certificate is still new BGPsec router certificate and (if the old certificate is still
valid) revoking the old certificate. This process will need to valid) revoking the old certificate. This process will need to
happen at regular intervals, normally due to policies of the local happen at regular intervals, normally due to policies of the local
network. This document describes a safe rollover process that network. This document describes a safe rollover process that
results in a BGPsec receiver always having the needed verification results in a BGPsec receiver always having the needed verification
skipping to change at page 3, line 22 skipping to change at page 3, line 22
and thus any BGPsec Update that includes a signature performed by the and thus any BGPsec Update that includes a signature performed by the
old key will be invalid. Consequently, if the router does not old key will be invalid. Consequently, if the router does not
refresh its outbound BGPsec Update messages, previously sent routing refresh its outbound BGPsec Update messages, previously sent routing
information may be treated as unauthenticated after the rollover information may be treated as unauthenticated after the rollover
process is finished. It is therefore extremely important that new process is finished. It is therefore extremely important that new
BGPsec router certificates have been distributed throughout the RPKI BGPsec router certificates have been distributed throughout the RPKI
before the router begin signing BGPsec updates with a new private before the router begin signing BGPsec updates with a new private
key. key.
It is also important for an AS to minimize the BGPsec router key It is also important for an AS to minimize the BGPsec router key
rollover interval (i.e., in between the time an AS distributes a rollover interval (i.e., the period between the time when an AS
BGPsec router certificate with a new public key and the time a BGPsec distributes a BGPsec router certificate with a new public key and the
router begins to use its new private key). This can be due to a need time a BGPsec router begins to use its new private key). This can be
for a BGPsec router to distribute BGPsec updates signed with a new due to a need for a BGPsec router to distribute BGPsec updates signed
private key in order to invalidate BGPsec updates signed with the old with a new private key in order to invalidate BGPsec updates signed
private key. In particular, if the AS suspects that a stale BGPsec with the old private key. In particular, if the AS suspects that a
updates is being distributed instead of the most recently signed stale BGPsec update is being distributed instead of the most recently
attribute it can cause the stale BGPsec updates to be invalidated by signed attribute it can cause the stale BGPsec updates to be
completing a key rollover procedure. The BGPsec router rollover invalidated by completing a key rollover procedure. The BGPsec
interval can be minimized when an automated certificate provisioning router rollover interval can be minimized when an automated
process such as Enrollment over Secure Transport (EST) [RFC7030] is certificate provisioning process such as Enrollment over Secure
used. Transport (EST) [RFC7030] is used.
The Security Requirements for BGP Path Validation [RFC7353] also The Security Requirements for BGP Path Validation [RFC7353] also
describes the need for protecting against suppression of BGP WITHDRAW describes the need for protecting against suppression of BGP WITHDRAW
messages or replay of BGP UPDATE messages, such as controlling messages or replay of BGP UPDATE messages, such as controlling
BGPsec's window of exposure to such attacks. The BGPsec router BGPsec's window of exposure to such attacks. The BGPsec router
certificate rollover method in this document can be used to achieve certificate rollover method in this document can be used to achieve
this goal. this goal.
In [I-D.ietf-sidr-rtr-keying], the "operator-driven" method is In [I-D.ietf-sidr-rtr-keying], the "operator-driven" method is
introduced, in which a key pair can be shared among multiple BGP introduced, in which a key pair can be shared among multiple BGP
skipping to change at page 4, line 20 skipping to change at page 4, line 20
Router certificate field changes: Information contained in a BGPsec Router certificate field changes: Information contained in a BGPsec
router certificate (such as the ASN or the Subject) may need to router certificate (such as the ASN or the Subject) may need to
be changed. be changed.
Emergency router key rollover: Some special circumstances (such as a Emergency router key rollover: Some special circumstances (such as a
compromised key) may require the replacement of a BGPsec router compromised key) may require the replacement of a BGPsec router
certificate. certificate.
Protection against withdrawal suppression and replay attacks: An AS Protection against withdrawal suppression and replay attacks: An AS
may determine withdrawn BGPsec updates are being propagated may determine that withdrawn BGPsec updates are being
instead of the most recently propagated BGPsec updates. propagated instead of the most recently propagated BGPsec
Changing the BGPsec router signing key, distributing a new updates. Changing the BGPsec router signing key, distributing
BGPsec router certificate, and revoking the old BGPsec router a new BGPsec router certificate, and revoking the old BGPsec
certificate will invalidate the replayed BGPsec updates. router certificate will invalidate the replayed BGPsec updates.
In some of these cases it is possible to generate a new certificate In some of these cases it is possible to generate a new certificate
without changing the key pair. This practice simplifies the rollover without changing the key pair. This practice simplifies the rollover
process as the BGP speakers receiving BGPsec Updates do not even need process as the BGP speakers receiving BGPsec Updates do not even need
to be aware of the change of certificate. However, not replacing the to be aware of the change of certificate. However, not replacing the
certificate key for a long period of time increases the risk that a certificate key for a long period of time increases the risk that a
compromised router private key may be used by an attacker to deliver compromised router private key may be used by an attacker to deliver
unauthorized or false BGPsec Updates. Distributing the old public unauthorized or false BGPsec Updates. Distributing the old public
key in a new certificate is NOT RECOMMENDED when the rollover event key in a new certificate is NOT RECOMMENDED when the rollover event
is due to a compromised key, or when it is suspected that withdrawn is due to a compromised key, or when it is suspected that withdrawn
skipping to change at page 7, line 25 skipping to change at page 7, line 25
key). By re-keying, an AS is letting the BGPsec router certificate key). By re-keying, an AS is letting the BGPsec router certificate
validation time be a type of "timestamp" to mitigate replay attacks. validation time be a type of "timestamp" to mitigate replay attacks.
However, the use of frequent key rollovers comes with an additional However, the use of frequent key rollovers comes with an additional
administrative cost and risks if the process fails. As documented administrative cost and risks if the process fails. As documented
before, re-keying should be supported by automatic tools, and for the 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 great majority of the Internet it will be done with good lead time to
ensure that the public key corresponding to the new router ensure that the public key corresponding to the new router
certificate will be available to validate the corresponding BGPsec certificate will be available to validate the corresponding BGPsec
updates when received. updates when received.
For a transit AS that also originates BGPsec updates for its own If a transit AS also originates BGPsec updates for its own prefixes
prefixes, the key rollover process may generate a large number of and it wishes to mitigate replay attacks on those prefixes, then the
UPDATE messages (even the complete Default Free Zone or DFZ). For transit AS SHOULD be provisioned with two unique key pairs and
this reason, it is RECOMMENDED that routers in a transit AS that also certificates. One of the key pairs is used to sign BGPsec updates
originate BGPsec updates be provisioned with two certificates: one to for prefixes originated from the transit AS, and can have a replay
sign BGPsec updates in transit and a second one to sign BGPsec protection policy applied to it. The other key pair is used to sign
updates for prefixes originated from its AS. Only the second BGPsec updates in transit and SHOULD NOT have replay protection
certificate (for originating prefixes) should be rolled-over policy applied to it. Because the transit AS is not likely to know
frequently as a means of limiting replay attack windows. The router or care what is the policy of origin ASes elsewhere, there is no
certificate used for signing updates in transit is expected to live value for the transit AS to perform key rollovers to mitigate replay
longer than the one used for signing origination updates. attacks against prefixes originated elsewhere. If the transit AS
were instead to perform replay protection for all updates that it
signs, its key rollover process would generate a large number of
BGPsec UPDATE messages, even in the complete Default Free Zone (DFZ).
Therefore, it is best to let each AS independently manage the replay
attack vulnerability window for the prefixes it originates.
Advantages to re-keying as replay attack protection mechanism are as Advantages to re-keying as replay attack protection mechanism are as
follows: follows:
1. All expiration policies are maintained in the RPKI. 1. All expiration policies are maintained in the RPKI.
2. Much of the additional administrative cost is paid by the 2. Much of the additional administrative cost is paid by the
provider that wants to protect its infrastructure, as it bears provider that wants to protect its infrastructure, as it bears
the cost of creating and initiating distribution of new router the cost of creating and initiating distribution of new router
key pairs and BGPsec router certificates. (It is true that the key pairs and BGPsec router certificates. (It is true that the
skipping to change at page 9, line 17 skipping to change at page 9, line 22
window size is reduced to the propagation time of a CRL invalidating window size is reduced to the propagation time of a CRL invalidating
the certificate containing an old public key. For a discussion of the certificate containing an old public key. For a discussion of
the difficulties deploying a more effectual replay protection the difficulties deploying a more effectual replay protection
mechanism for BGPSEC, see mechanism for BGPSEC, see
[I-D.sriram-replay-protection-design-discussion]. [I-D.sriram-replay-protection-design-discussion].
7. Acknowledgments 7. Acknowledgments
Randy Bush, Kotikalapudi Sriram, Stephen Kent and Sandy Murphy each Randy Bush, Kotikalapudi Sriram, Stephen Kent and Sandy Murphy each
provided valuable suggestions resulting in an improved document. provided valuable suggestions resulting in an improved document.
Kotikalapudi Sriram contributed valuable guidance regarding the use
of key rollovers to mitigate BGP update replay attacks.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-sidr-rtr-keying]
Bush, R., Turner, S., and K. Patel, "Router Keying for
BGPsec", draft-ietf-sidr-rtr-keying-14 (work in progress),
October 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
8.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-sidr-rtr-keying] 8.2. Informative References
Bush, R., Turner, S., and K. Patel, "Router Keying for
BGPsec", draft-ietf-sidr-rtr-keying-14 (work in progress),
October 2017.
[I-D.sriram-replay-protection-design-discussion] [I-D.sriram-replay-protection-design-discussion]
Sriram, K. and D. Montgomery, "Design Discussion and Sriram, K. and D. Montgomery, "Design Discussion and
Comparison of Protection Mechanisms for Replay Attack and Comparison of Protection Mechanisms for Replay Attack and
Withdrawal Suppression in BGPsec", draft-sriram-replay- Withdrawal Suppression in BGPsec", draft-sriram-replay-
protection-design-discussion-09 (work in progress), protection-design-discussion-09 (work in progress),
October 2017. October 2017.
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification
Authority (CA) Key Rollover in the Resource Public Key Authority (CA) Key Rollover in the Resource Public Key
 End of changes. 12 change blocks. 
40 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/