rfc9324.original   rfc9324.txt 
Network Working Group R. Bush Internet Engineering Task Force (IETF) R. Bush
Internet-Draft IIJ Research Lab & Arrcus, Inc. Request for Comments: 9324 IIJ Research Lab & Arrcus, Inc.
Updates: 8481 (if approved) K. Patel Updates: 8481 K. Patel
Intended status: Standards Track Arrcus, Inc. Category: Standards Track Arrcus, Inc.
Expires: 23 March 2023 P. Smith ISSN: 2070-1721 P. Smith
PFS Internet Development Pty Ltd PFS Internet Development Pty Ltd
M. Tinka M. Tinka
SEACOM SEACOM
19 September 2022 December 2022
RPKI-Based Policy Without Route Refresh Policy Based on the Resource Public Key Infrastructure (RPKI) without
draft-ietf-sidrops-rov-no-rr-08 Route Refresh
Abstract Abstract
A BGP Speaker performing RPKI-based policy should not issue Route A BGP speaker performing policy based on the Resource Public Key
Refresh to its neighbors because it has received new RPKI data. This Infrastructure (RPKI) should not issue route refresh to its neighbors
document updates [RFC8481] by describing how to avoid doing so by because it has received new RPKI data. This document updates RFC
either keeping a full Adj-RIB-In or saving paths dropped due to ROV 8481 by describing how to avoid doing so by either keeping a full
(Route Origin Validation) so they may be reevaluated with respect to Adj-RIB-In or saving paths dropped due to ROV (Route Origin
new RPKI data. Validation) so they may be reevaluated with respect to new RPKI data.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 23 March 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9324.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
3. ROV Experience . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Work
4. Keeping Partial Adj-RIB-In Data . . . . . . . . . . . . . . . 3 3. ROV Experience
5. Operational Recommendations . . . . . . . . . . . . . . . . . 4 4. Keeping Partial Adj-RIB-In Data
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Operational Recommendations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 6 8.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Acknowledgements
Authors' Addresses
1. Introduction 1. Introduction
Memory constraints in early BGP speakers caused classic [RFC4271] BGP Memory constraints in early BGP speakers caused classic BGP
implementations to not keep a full Adj-RIB-In (Sec. 1.1). When doing implementations [RFC4271] to not keep a full Adj-RIB-In (Section 1.1
RPKI-based Route Origin Validation (ROV) ([RFC6811] and [RFC8481]), of [RFC4271]). When doing RPKI-based Route Origin Validation (ROV)
and similar RPKI-based policy, if such a BGP speaker receives new [RFC6811] [RFC8481] and similar RPKI-based policy, if such a BGP
RPKI data, it might not have kept paths previously marked as Invalid speaker receives new RPKI data, it might not have kept paths
etc. Such an implementation must then request a Route Refresh, previously marked as Invalid, etc. Such an implementation must then
[RFC2918] and [RFC7313], from its neighbors to recover the paths request a route refresh [RFC2918] [RFC7313] from its neighbors to
which might be covered by these new RPKI data. This will be recover the paths that might be covered by these new RPKI data. This
perceived as rude by those neighbors as it passes a serious resource will be perceived as rude by those neighbors as it passes a serious
burden on to them. This document recommends implementations keep and resource burden on to them. This document recommends implementations
mark paths affected by RPKI-based policy, so Route Refresh is no keep and mark paths affected by RPKI-based policy, so route refresh
longer needed. is no longer needed.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Related Work 2. Related Work
It is assumed that the reader understands BGP, [RFC4271] and Route It is assumed that the reader understands BGP [RFC4271], route
Refresh [RFC7313], the RPKI [RFC6480], Route Origin Authorizations refresh [RFC7313], the RPKI [RFC6480], Route Origin Authorizations
(ROAs), [RFC6482], The Resource Public Key Infrastructure (RPKI) to (ROAs) [RFC6482], the Resource Public Key Infrastructure (RPKI) to
Router Protocol [I-D.ietf-sidrops-8210bis], RPKI-based Prefix Router Protocol [RPKI-ROUTER-PROT-v2], RPKI-Based Prefix Validation
Validation, [RFC6811], and Origin Validation Clarifications, [RFC6811], and Origin Validation Clarifications [RFC8481].
[RFC8481].
Note that the term "RPKI-based Route Origin Validation" in this
document means the same as the term "Prefix Origin Validation" used
in [RFC6811].
3. ROV Experience 3. ROV Experience
As Route Origin Validation dropping Invalids has deployed, some BGP As Route Origin Validation dropping Invalids has deployed, some BGP
speaker implementations have been found which, when receiving new speaker implementations have been found that, when receiving new RPKI
RPKI data (VRPs, see [I-D.ietf-sidrops-8210bis]) issue a BGP Route data (Validated ROA Payloads (VRPs) [RPKI-ROUTER-PROT-v2]), issue a
Refresh [RFC7313] to all sending BGP peers so that it can reevaluate BGP route refresh [RFC7313] to all sending BGP peers so that they can
the received paths against the new data. reevaluate the received paths against the new data.
In actual deployment this has been found to be very destructive, In actual deployment, this has been found to be very destructive,
transferring a serious resource burden to the unsuspecting peers. In transferring a serious resource burden to the unsuspecting peers. In
reaction, RPKI based Route Origin Validation (ROV) has been turned reaction, RPKI-based Route Origin Validation (ROV) has been turned
off. There have been actual de-peerings. off. There have been actual de-peerings.
As RPKI registration and ROA creation have steadily increased, this As RPKI registration and ROA creation have steadily increased, this
problem has increased, not just proportionally, but on the order of problem has increased, not just proportionally, but on the order of
the in-degree of ROV implementing BGP speakers. As ASPA the in-degree of ROV implementing BGP speakers. As Autonomous System
([I-D.ietf-sidrops-aspa-verification]) becomes used, the problem will Provider Authorization (ASPA) [AS_PATH-VER] becomes used, the problem
increase. will increase.
Other mechanisms, such as automated policy provisioning, which have Other mechanisms, such as automated policy provisioning, which have
flux rates similar to ROV (i.e. on the order of minutes), could very flux rates similar to ROV (i.e., on the order of minutes), could very
well cause similar problems. well cause similar problems.
Therefore this document updates [RFC8481] by describing how to avoid Therefore, this document updates [RFC8481] by describing how to avoid
this problem. this problem.
4. Keeping Partial Adj-RIB-In Data 4. Keeping Partial Adj-RIB-In Data
If new RPKI data arrive which cause operator policy to invalidate the If new RPKI data arrive that cause operator policy to invalidate the
best route, and the BGP speaker did not keep the dropped routes, then best route and the BGP speaker did not keep the dropped routes, then
it would issue a route refresh, which this feature aims to prevent. the BGP speaker would issue a route refresh, which this feature aims
to prevent.
A route that is dropped by operator policy due to ROV is, by nature, A route that is dropped by operator policy due to ROV is, by nature,
considered ineligible to compete for best route, and MUST be kept in considered ineligible to compete for the best route and MUST be kept
the Adj-RIB-In for potential future evaluation. in the Adj-RIB-In for potential future evaluation.
Ameliorating the Route Refresh problem by keeping a full Adj-RIB-In Ameliorating the route refresh problem by keeping a full Adj-RIB-In
can be a problem for resource constrained BGP speakers. In reality, can be a problem for resource-constrained BGP speakers. In reality,
only some data need be retained. If an implementation chooses not to only some data need be retained. If an implementation chooses not to
retain the full Adj-RIB-In, it MUST retain at least routes dropped retain the full Adj-RIB-In, it MUST retain at least routes dropped
due to ROV, for potential future evaluation. due to ROV for potential future evaluation.
As storing these routes could cause problems in resource constrained As storing these routes could cause problems in resource-constrained
devices, there MUST be a global operation, CLI, YANG, etc. allowing devices, there MUST be a global operation, CLI, YANG, or other
the operator to enable this feature, storing the dropped routes. mechanism that allows the operator to enable this feature and store
Such an operator control MUST NOT be per peer, as this could cause the dropped routes. Such an operator control MUST NOT be per peer,
inconsistent behavior. as this could cause inconsistent behavior.
As a side note: policy which may drop routes due to RPKI-based checks As a side note, policy that may drop routes due to RPKI-based checks
such as ROV (and ASPA, BGPsec [RFC8205], etc. in the future) MUST be such as ROV (and ASPA, BGPsec [RFC8205], etc., in the future) MUST be
run, and the dropped routes saved per this section, before non-RPKI run and the dropped routes saved per this section, before non-RPKI
policies are run, as the latter may change path attributes. policies are run, as the latter may change path attributes.
5. Operational Recommendations 5. Operational Recommendations
Operators deploying ROV and/or other RPKI based policies should Operators deploying ROV and/or other RPKI-based policies should
ensure that the BGP speaker implementation is not causing Route ensure that the BGP speaker implementation is not causing route
Refresh requests to neighbors. refresh requests to neighbors.
BGP Speakers MUST either keep the full Adj-RIB-In or implement the BGP speakers MUST either keep the full Adj-RIB-In or implement the
specification in Section 4. Conformance to this behavior is a specification in Section 4. Conformance to this behavior is an
additional, mandatory capability for BGP speakers performing ROV. additional, mandatory capability for BGP speakers performing ROV.
If the BGP speaker does not implement these recommendations, the If the BGP speaker does not implement these recommendations, the
operator should enable the vendor's control to keep the full Adj-RIB- operator should enable the vendor's control to keep the full Adj-RIB-
In, sometimes referred to as "soft reconfiguration inbound". The In, sometimes referred to as "soft reconfiguration inbound". The
operator should then measure to ensure that there are no unnecessary operator should then measure to ensure that there are no unnecessary
Route Refresh requests sent to neighbors. route refresh requests sent to neighbors.
If the BGP speaker's equipment has insufficient resources to support If the BGP speaker's equipment has insufficient resources to support
either of the two proposed options (keeping a full AdjRibIn or at either of the two proposed options (keeping a full AdjRibIn or at
least the dropped routes), the equipment SHOULD either be replaced least the dropped routes), the equipment SHOULD either be replaced
with capable equipment or SHOULD NOT be used for ROV. with capable equipment or SHOULD NOT be used for ROV.
The configuration setting in Section 4 should only be used in very The configuration setting in Section 4 should only be used in very
well known and controlled circumstances where the scaling issues are well-known and controlled circumstances where the scaling issues are
well understood and anticipated. well understood and anticipated.
Operators using the specification in Section 4 should be aware that a Operators using the specification in Section 4 should be aware that a
misconfigured neighbor might erroneously send a massive number of misconfigured neighbor might erroneously send a massive number of
paths, thus consuming a lot of memory. Hence pre-policy filtering paths, thus consuming a lot of memory. Hence, pre-policy filtering
such as described in [I-D.sas-idr-maxprefix-inbound] could be used to such as described in [MAXPREFIX-INBOUND] could be used to reduce this
reduce this exposure. exposure.
If Route Refresh has been issued toward more than one peer, the order If route refresh has been issued toward more than one peer, the order
of receipt of the refresh data can cause churn in both best route of receipt of the refresh data can cause churn in both best route
selection and in outbound signaling. selection and outbound signaling.
Internet Exchange Points (IXPs) which provide [RFC7947] Route Servers Internet Exchange Points (IXPs) that provide route servers [RFC7947]
should be aware that some members could be causing an undue Route should be aware that some members could be causing an undue route
Refresh load on the Route Servers and take appropriate administrative refresh load on the route servers and take appropriate administrative
and/or technical measures. IXPs using BGP speakers as route servers and/or technical measures. IXPs using BGP speakers as route servers
should ensure that they are not generating excessive route refresh should ensure that they are not generating excessive route refresh
requests. requests.
6. Security Considerations 6. Security Considerations
This document describes a denial of service which Route Origin This document describes a denial of service that Route Origin
Validation or other RPKI policy may place on a BGP neighbor, and Validation or other RPKI policy may place on a BGP neighbor and
describes how it may be ameliorated. describes how it may be ameliorated.
Otherwise, this document adds no additional security considerations Otherwise, this document adds no additional security considerations
to those already described by the referenced documents. to those already described by the referenced documents.
7. IANA Considerations 7. IANA Considerations
None This document has no IANA actions.
8. Acknowledgements
The authors wish to thank Alvaro Retana, Ben Maddison, Derek Yeung,
John Heasley, John Scudder, Matthias Waehlisch, Nick Hilliard, Saku
Ytti, and Ties de Kock.
9. References 8. References
9.1. Normative References 8.1. Normative References
[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, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
DOI 10.17487/RFC2918, September 2000, DOI 10.17487/RFC2918, September 2000,
<https://www.rfc-editor.org/info/rfc2918>. <https://www.rfc-editor.org/info/rfc2918>.
skipping to change at page 6, line 24 skipping to change at line 250
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based [RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based
on Resource Public Key Infrastructure (RPKI)", RFC 8481, on Resource Public Key Infrastructure (RPKI)", RFC 8481,
DOI 10.17487/RFC8481, September 2018, DOI 10.17487/RFC8481, September 2018,
<https://www.rfc-editor.org/info/rfc8481>. <https://www.rfc-editor.org/info/rfc8481>.
9.2. Informative References 8.2. Informative References
[I-D.ietf-sidrops-8210bis]
Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 2", Work
in Progress, Internet-Draft, draft-ietf-sidrops-8210bis-
10, 16 June 2022, <https://www.ietf.org/archive/id/draft-
ietf-sidrops-8210bis-10.txt>.
[I-D.ietf-sidrops-aspa-verification] [AS_PATH-VER]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
Snijders, "BGP AS_PATH Verification Based on Resource J., and K. Sriram, "BGP AS_PATH Verification Based on
Public Key Infrastructure (RPKI) Autonomous System Resource Public Key Infrastructure (RPKI) Autonomous
Provider Authorization (ASPA) Objects", Work in Progress, System Provider Authorization (ASPA) Objects", Work in
Internet-Draft, draft-ietf-sidrops-aspa-verification-09, Progress, Internet-Draft, draft-ietf-sidrops-aspa-
11 July 2022, <https://www.ietf.org/archive/id/draft-ietf- verification-11, 24 October 2022,
sidrops-aspa-verification-09.txt>. <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-verification-11>.
[I-D.sas-idr-maxprefix-inbound] [MAXPREFIX-INBOUND]
Aelmans, M., Stucchi, M., and J. Snijders, "BGP Maximum Aelmans, M., Stucchi, M., and J. Snijders, "BGP Maximum
Prefix Limits Inbound", Work in Progress, Internet-Draft, Prefix Limits Inbound", Work in Progress, Internet-Draft,
draft-sas-idr-maxprefix-inbound-04, 19 January 2022, draft-sas-idr-maxprefix-inbound-04, 19 January 2022,
<https://www.ietf.org/archive/id/draft-sas-idr-maxprefix- <https://datatracker.ietf.org/doc/html/draft-sas-idr-
inbound-04.txt>. maxprefix-inbound-04>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>. February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012, DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>. <https://www.rfc-editor.org/info/rfc6482>.
[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
"Internet Exchange BGP Route Server", RFC 7947, "Internet Exchange BGP Route Server", RFC 7947,
DOI 10.17487/RFC7947, September 2016, DOI 10.17487/RFC7947, September 2016,
<https://www.rfc-editor.org/info/rfc7947>. <https://www.rfc-editor.org/info/rfc7947>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>. 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RPKI-ROUTER-PROT-v2]
Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol, Version 2", Work
in Progress, Internet-Draft, draft-ietf-sidrops-8210bis-
10, 16 June 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-sidrops-8210bis-10>.
Acknowledgements
The authors wish to thank Alvaro Retana, Ben Maddison, Derek Yeung,
John Heasley, John Scudder, Matthias Waehlisch, Nick Hilliard, Saku
Ytti, and Ties de Kock.
Authors' Addresses Authors' Addresses
Randy Bush Randy Bush
IIJ Research Lab & Arrcus, Inc. IIJ Research Lab & Arrcus, Inc.
1856 SW Edgewood Dr 1856 SW Edgewood Dr
Portland, Oregon 97210 Portland, OR 97210
United States of America United States of America
Email: randy@psg.com Email: randy@psg.com
Keyur Patel Keyur Patel
Arrcus, Inc. Arrcus, Inc.
2077 Gateway Place, Suite #400 2077 Gateway Place, Suite #400
San Jose, CA 95119 San Jose, CA 95119
United States of America United States of America
Email: keyur@arrcus.com Email: keyur@arrcus.com
Philip Smith Philip Smith
PFS Internet Development Pty Ltd PFS Internet Development Pty Ltd
PO Box 1908 PO Box 1908
Milton QLD 4064 Milton QLD 4064
Australia Australia
Email: pfsinoz@gmail.com Email: pfsinoz@gmail.com
Mark Tinka Mark Tinka
SEACOM SEACOM
Building 7, Design Quarter District, Leslie Avenue, Magaliessig Building 7, Design Quarter District
Leslie Avenue, Magaliessig
Fourways, Gauteng Fourways, Gauteng
2196 2196
South Africa South Africa
Email: mark@tinka.africa Email: mark@tinka.africa
 End of changes. 42 change blocks. 
145 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.48.