RFC 9324

Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh

📅 published December 2022, from ietf

RFC 9324: Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh 🦋

Okay bestie, let's get the basics down first 💅 This one is from the Internet Engineering Task Force (IETF), and it's a Standards Track doc, which means it's the real deal 👑 It was written by R. Bush (IIJ Research Lab & Arrcus, Inc.), K. Patel (Arrcus, Inc.), P. Smith (PFS Internet Development Pty Ltd), and M. Tinka (SEACOM). It came out in December 2022, the ISSN is 2070-1721, and it updates RFC 8481 ✨

Abstract 🌸

Okay, so a BGP speaker doing policy based on the RPKI shouldn't send route refresh to its neighbors just because it got new RPKI data 🙈 This doc explains how to skip that by either keeping a full Adj-RIB-In, or by saving the paths that got dropped due to ROV (Route Origin Validation) so they can be re-checked against the new RPKI data later 🫶

Status of This Memo 🧚

This is an Internet Standards Track document 💖

It's a product of the Internet Engineering Task Force (IETF), so it reflects what the IETF community agreed on. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 ✨

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9324 🦋

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they were on the day it was published. Please read those carefully, because they spell out your rights and restrictions for this doc 📜 If you extract Code Components from this doc, they have to include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no 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 ✨

Okay so, early BGP speakers didn't have a lot of memory 💀 Because of that, classic BGP implementations [RFC4271] didn't keep a full Adj-RIB-In (Section 1.1 of [RFC4271]). Now, when you do RPKI-based Route Origin Validation (ROV) [RFC6811] [RFC8481] and other similar RPKI-based policy, and that kind of BGP speaker gets new RPKI data, it might not have kept the paths it already marked as Invalid, etc. 😬 So it has to ask its neighbors for a route refresh [RFC2918] [RFC7313] to get back the paths that might be covered by that new RPKI data. Neighbors are gonna find this rude, because it puts a serious resource burden on them 🙈 This document recommends that implementations keep and mark the paths affected by RPKI-based policy, so route refresh isn't needed anymore 🫶

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 💅

It's assumed that you already get 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] 📚

Also, "RPKI-based Route Origin Validation" in this doc means the same thing as "Prefix Origin Validation" in [RFC6811] ✨

3. ROV Experience 💖

Once Route Origin Validation dropping Invalids got deployed, some BGP speaker implementations were found that, when they got new RPKI data (Validated ROA Payloads (VRPs) [RPKI-ROUTER-PROT-v2]), would issue a BGP route refresh [RFC7313] to all sending BGP peers so they could re-evaluate the received paths against the new data 😭

IRL, this turned out to be super destructive, dumping a serious resource burden onto unsuspecting peers 💀 In reaction, RPKI-based Route Origin Validation (ROV) got turned off. There have been actual de-peerings. 🙃

As RPKI registration and ROA creation keep going up, this problem has gotten worse, not just proportionally, but on the order of the in-degree of ROV implementing BGP speakers 📈 And once Autonomous System Provider Authorization (ASPA) [AS_PATH-VER] is used, the problem is gonna get bigger 👀

Other mechanisms, like automated policy provisioning, have flux rates similar to ROV (i.e., on the order of minutes), so they could very well cause similar problems 🌈

So, this document updates [RFC8481] to describe how to avoid this problem 🫶

4. Keeping Partial Adj-RIB-In Data 🎀

Here's the situation: if new RPKI data comes in that makes operator policy invalidate the best route, and the BGP speaker didn't keep the dropped routes, then the BGP speaker would issue a route refresh, which is exactly what this feature is trying to prevent 🛑

A route that's dropped by operator policy due to ROV is, by nature, considered ineligible to compete for the best route, and it MUST be kept in the Adj-RIB-In for potential future evaluation 💜

Keeping a full Adj-RIB-In can be a problem for resource-constrained BGP speakers, so it's not the only fix. Honestly, only some data really needs to be retained 🧚 If an implementation chooses not to retain the full Adj-RIB-In, it MUST retain at least the routes dropped due to ROV for potential future evaluation ✨

Storing these routes could cause problems on resource-constrained devices, so there MUST be a global operation, CLI, YANG, or other mechanism that lets the operator turn this feature on and store the dropped routes 🍓 That operator control MUST NOT be per peer, because that could cause inconsistent behavior 🙈

Side note, but it's important 📝 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, because the latter may change path attributes 💅

8.2. Informative References 📚✨

okay bestie, now we're in the bibliography era 💅 these are the extra receipts. The whole list is in one code block so every title, number, and DOI stays exactly as it is 🫶

   [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 want to give a huge shoutout to Alvaro Retana, Ben Maddison, Derek Yeung, John Heasley, John Scudder, Matthias Waehlisch, Nick Hilliard, Saku Ytti, and Ties de Kock. 💖 literally the dream team, thank you all 🌸

Authors' Addresses 💌

okay so here's how to find the authors, bestie 🦋 all their contact details are below, copied exactly 💅

   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
📦 where this page comes from