A BGP speaker performing policy based on the Resource Public Key Infrastructure (RPKI) should not issue route refresh to its neighbors because it has received new RPKI data. This document updates RFC 8481 by describing how to avoid doing so by either keeping a full Adj-RIB-In or saving paths dropped due to ROV (Route Origin Validation) so they may be reevaluated with respect to new RPKI data.

This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. 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 (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Memory constraints in early BGP speakers caused classic BGP implementations [RFC 4271] to not keep a full Adj-RIB-In (Section 1.1 of RFC 4271). When doing RPKI-based Route Origin Validation (ROV) [RFC 6811] [RFC 8481] and similar RPKI-based policy, if such a BGP speaker receives new RPKI data, it might not have kept paths previously marked as Invalid, etc. Such an implementation must then request a route refresh [RFC 2918] [RFC 7313] from its neighbors to recover the paths that might be covered by these new RPKI data. This will be perceived as rude by those neighbors as it passes a serious resource burden on to them. This document recommends implementations keep and mark paths affected by RPKI-based policy, so route refresh is no longer needed.

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 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here.

It is assumed that the reader understands BGP [RFC 4271], route refresh [RFC 7313], the RPKI [RFC 6480], Route Origin Authorizations (ROAs) [RFC 6482], the Resource Public Key Infrastructure (RPKI) to Router Protocol [RPKI-ROUTER-PROT-v2], RPKI-Based Prefix Validation [RFC 6811], and Origin Validation Clarifications [RFC 8481]. Note that the term "RPKI-based Route Origin Validation" in this document means the same as the term "Prefix Origin Validation" used in [RFC 6811].

As Route Origin Validation dropping Invalids has deployed, some BGP speaker implementations have been found that, when receiving new RPKI data (Validated ROA Payloads (VRPs) [RPKI-ROUTER-PROT-v2]), issue a BGP route refresh [RFC 7313] to all sending BGP peers so that they can reevaluate the received paths against the new data. In actual deployment, this has been found to be very destructive, transferring a serious resource burden to the unsuspecting peers. In reaction, RPKI-based Route Origin Validation (ROV) has been turned off. There have been actual de-peerings. As RPKI registration and ROA creation have steadily increased, this problem has increased, not just proportionally, but on the order of the in-degree of ROV implementing BGP speakers. As Autonomous System Provider Authorization (ASPA) [AS_PATH-VER] becomes used, the problem will increase. Other mechanisms, such as automated policy provisioning, which have flux rates similar to ROV (i.e., on the order of minutes), could very well cause similar problems. Therefore, this document updates [RFC 8481] by describing how to avoid this problem.

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 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, considered ineligible to compete for the best route and MUST be kept in the Adj-RIB-In for potential future evaluation. Ameliorating the route refresh problem by keeping a full Adj-RIB-In can be a problem for resource-constrained BGP speakers. In reality, 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 due to ROV for potential future evaluation. As storing these routes could cause problems in resource-constrained devices, there MUST be a global operation, CLI, YANG, or other mechanism that allows the operator to enable this feature and store the dropped routes. Such an operator control MUST NOT be per peer, as this could cause inconsistent behavior. As a side note, policy that may drop routes due to RPKI-based checks such as ROV (and ASPA, BGPsec [RFC 8205], etc., in the future) MUST be run and the dropped routes saved per this section, before non-RPKI policies are run, as the latter may change path attributes.

Operators deploying ROV and/or other RPKI-based policies should ensure that the BGP speaker implementation is not causing route refresh requests to neighbors. BGP speakers MUST either keep the full Adj-RIB-In or implement the specification in Section 4. Conformance to this behavior is an additional, mandatory capability for BGP speakers performing ROV. If the BGP speaker does not implement these recommendations, the operator should enable the vendor's control to keep the full Adj-RIB-In, sometimes referred to as "soft reconfiguration inbound". The operator should then measure to ensure that there are no unnecessary route refresh requests sent to neighbors. If the BGP speaker's equipment has insufficient resources to support either of the two proposed options (keeping a full AdjRibIn or at least the dropped routes), the equipment SHOULD either be replaced with capable equipment or SHOULD NOT be used for ROV. The configuration setting in Section 4 should only be used in very well-known and controlled circumstances where the scaling issues are well understood and anticipated. Operators using the specification in Section 4 should be aware that a misconfigured neighbor might erroneously send a massive number of paths, thus consuming a lot of memory. Hence, pre-policy filtering such as described in [MAXPREFIX-INBOUND] could be used to reduce this exposure. 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 selection and outbound signaling. Internet Exchange Points (IXPs) that provide route servers [RFC 7947] should be aware that some members could be causing an undue route refresh load on the route servers and take appropriate administrative and/or technical measures. IXPs using BGP speakers as route servers should ensure that they are not generating excessive route refresh requests.

This document describes a denial of service that Route Origin Validation or other RPKI policy may place on a BGP neighbor and describes how it may be ameliorated. Otherwise, this document adds no additional security considerations to those already described by the referenced documents.

This document has no IANA actions.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC2918]

E. Chen, "Route Refresh Capability for BGP-4", RFC 2918, DOI 10.17487/RFC2918, September 2000,
<https://www.rfc-editor.org/info/rfc2918>.

[RFC4271]

Y. Rekhter, T. Li, and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.

[RFC6811]

P. Mohapatra, J. Scudder, D. Ward, R. Bush, and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>.

[RFC7313]

K. Patel, E. Chen, and B. Venkatachalapathy, "Enhanced Route Refresh Capability for BGP-4", RFC 7313, DOI 10.17487/RFC7313, July 2014,
<https://www.rfc-editor.org/info/rfc7313>.

[RFC8174]

B. Leiba, "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>.

[RFC8481]

R. Bush, "Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)", RFC 8481, DOI 10.17487/RFC8481, September 2018,
<https://www.rfc-editor.org/info/rfc8481>.

[AS_PATH-VER]

USA National Institute of Standards and Technology, A. Azimov, E. Bogomazov, R. Bush, K. Patel, J. Snijders, and K. Sriram, "BGP AS_PATH Verification Based on Resource Public Key Infrastructure (RPKI) Autonomous System Provider Authorization (ASPA) Objects", Internet-Draft draft-ietf-sidrops-aspa-verification-11, October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-11>.

[MAXPREFIX-INBOUND]

Fastly, M. Aelmans, M. Stucchi, and J. Snijders, "BGP Maximum Prefix Limits Inbound", Internet-Draft draft-sas-idr-maxprefix-inbound-04, January 2022,
<https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-inbound-04>.

[RFC6480]

M. Lepinski, and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012,
<https://www.rfc-editor.org/info/rfc6480>.

[RFC6482]

M. Lepinski, S. Kent, and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.

[RFC7947]

E. Jasinska, N. Hilliard, R. Raszuk, and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016,
<https://www.rfc-editor.org/info/rfc7947>.

[RFC8205]

M. Lepinski, and K. Sriram, "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017,
<https://www.rfc-editor.org/info/rfc8205>.

[RPKI-ROUTER-PROT-v2]

Dragon Research Labs, R. Bush, and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2", Internet-Draft draft-ietf-sidrops-8210bis-10, June 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis-10>.

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.

Randy Bush

Keyur Patel

Philip Smith

Mark Tinka