diff options
Diffstat (limited to 'doc/rfc/rfc9324.txt')
| -rw-r--r-- | doc/rfc/rfc9324.txt | 337 |
1 files changed, 337 insertions, 0 deletions
diff --git a/doc/rfc/rfc9324.txt b/doc/rfc/rfc9324.txt new file mode 100644 index 0000000..f85122a --- /dev/null +++ b/doc/rfc/rfc9324.txt @@ -0,0 +1,337 @@ + + + + +Internet Engineering Task Force (IETF) R. Bush +Request for Comments: 9324 IIJ Research Lab & Arrcus, Inc. +Updates: 8481 K. Patel +Category: Standards Track Arrcus, Inc. +ISSN: 2070-1721 P. Smith + PFS Internet Development Pty Ltd + M. Tinka + SEACOM + December 2022 + + + Policy Based on the Resource Public Key Infrastructure (RPKI) without + Route Refresh + +Abstract + + 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. + +Status of This Memo + + 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 Notice + + 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. + +Table of Contents + + 1. Introduction + 1.1. Requirements Language + 2. Related Work + 3. ROV Experience + 4. Keeping Partial Adj-RIB-In Data + 5. Operational Recommendations + 6. Security Considerations + 7. IANA Considerations + 8. References + 8.1. Normative References + 8.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + Memory constraints in early BGP speakers caused classic BGP + implementations [RFC4271] to not keep a full Adj-RIB-In (Section 1.1 + of [RFC4271]). When doing RPKI-based Route Origin Validation (ROV) + [RFC6811] [RFC8481] 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 [RFC2918] [RFC7313] 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. + +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 + + It is assumed that the reader understands BGP [RFC4271], route + refresh [RFC7313], the RPKI [RFC6480], Route Origin Authorizations + (ROAs) [RFC6482], the Resource Public Key Infrastructure (RPKI) to + Router Protocol [RPKI-ROUTER-PROT-v2], RPKI-Based Prefix Validation + [RFC6811], and Origin Validation Clarifications [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 + + 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 [RFC7313] 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 [RFC8481] by describing how to avoid + this problem. + +4. Keeping Partial Adj-RIB-In Data + + 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 [RFC8205], 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. + +5. Operational Recommendations + + 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 [RFC7947] + 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. + +6. Security Considerations + + 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. + +7. IANA Considerations + + This document has no IANA actions. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "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] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, + DOI 10.17487/RFC2918, September 2000, + <https://www.rfc-editor.org/info/rfc2918>. + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + <https://www.rfc-editor.org/info/rfc4271>. + + [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. + Austein, "BGP Prefix Origin Validation", RFC 6811, + DOI 10.17487/RFC6811, January 2013, + <https://www.rfc-editor.org/info/rfc6811>. + + [RFC7313] Patel, K., Chen, E., 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] 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>. + + [RFC8481] Bush, R., "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>. + +8.2. Informative References + + [AS_PATH-VER] + Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, + J., and K. Sriram, "BGP AS_PATH Verification Based on + Resource Public Key Infrastructure (RPKI) Autonomous + System Provider Authorization (ASPA) Objects", Work in + Progress, Internet-Draft, draft-ietf-sidrops-aspa- + verification-11, 24 October 2022, + <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops- + aspa-verification-11>. + + [MAXPREFIX-INBOUND] + Aelmans, M., Stucchi, M., and J. Snijders, "BGP Maximum + Prefix Limits Inbound", Work in Progress, Internet-Draft, + draft-sas-idr-maxprefix-inbound-04, 19 January 2022, + <https://datatracker.ietf.org/doc/html/draft-sas-idr- + maxprefix-inbound-04>. + + [RFC6480] Lepinski, M. 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] Lepinski, M., Kent, S., 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] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, + "Internet Exchange BGP Route Server", RFC 7947, + DOI 10.17487/RFC7947, September 2016, + <https://www.rfc-editor.org/info/rfc7947>. + + [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol + Specification", RFC 8205, DOI 10.17487/RFC8205, September + 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 + + Randy Bush + IIJ Research Lab & Arrcus, Inc. + 1856 SW Edgewood Dr + Portland, OR 97210 + United States of America + Email: randy@psg.com + + + Keyur Patel + Arrcus, Inc. + 2077 Gateway Place, Suite #400 + San Jose, CA 95119 + United States of America + Email: keyur@arrcus.com + + + Philip Smith + PFS Internet Development Pty Ltd + PO Box 1908 + Milton QLD 4064 + Australia + Email: pfsinoz@gmail.com + + + Mark Tinka + SEACOM + Building 7, Design Quarter District + Leslie Avenue, Magaliessig + Fourways, Gauteng + 2196 + South Africa + Email: mark@tinka.africa |