Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh
updates
- rfc-8481 — Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)
Extracted elements (15)
Actual deployment of ROV with route refresh on new RPKI data was found to be 'very destructive,' causing de-peerings and operators turning off ROV in reaction; the problem scales with the in-degree of ROV-implementing speakers and will worsen with ASPA.
Early BGP speaker memory constraints caused implementations to not keep a full Adj-RIB-In; when new RPKI data arrive, these implementations must issue route refresh to recover dropped paths, imposing a serious resource burden on neighbors.
Other automated policy provisioning mechanisms with flux rates similar to ROV (on the order of minutes) could also cause the same route-refresh burden problem, so this solution is broadly applicable beyond ROV alone.
The operator control for retaining dropped routes must be global (not per-peer) to avoid inconsistent behavior across peers; a misconfigured neighbor could send a massive number of paths consuming memory, so pre-policy filtering is recommended.
If a BGP speaker does not implement these recommendations, the operator should enable the vendor's 'soft reconfiguration inbound' control to keep the full Adj-RIB-In, and should then measure to ensure no unnecessary route refresh requests are sent.
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 providing route servers should be aware that some members could cause undue route refresh load on the route servers and should take appropriate administrative and/or technical measures.
A route dropped by operator policy due to ROV MUST be kept in the Adj-RIB-In for potential future evaluation.
BGP speakers MUST either keep the full Adj-RIB-In or implement the specification in Section 4; conformance to this behavior is a mandatory capability for BGP speakers performing ROV.
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.
If the BGP speaker's equipment has insufficient resources to support either keeping a full Adj-RIB-In or retaining dropped routes, the equipment SHOULD either be replaced with capable equipment or SHOULD NOT be used for ROV.
RPKI-based policy (ROV, ASPA, BGPsec, etc.) MUST be run and dropped routes saved before non-RPKI policies are run, as the latter may change path attributes.
There MUST be a global operation, CLI, YANG, or other mechanism that allows the operator to enable the dropped-route retention feature; such an operator control MUST NOT be per peer, as this could cause inconsistent behavior.
The document defines two compliant strategies for avoiding route refresh on new RPKI data: (1) keeping the full Adj-RIB-In, or (2) retaining only paths dropped due to RPKI-based policy (ROV and similar checks) for future reevaluation.
This document describes a denial-of-service condition that ROV or other RPKI policy may place on a BGP neighbor by triggering excessive route refresh requests, and describes how it may be ameliorated by retaining dropped routes locally.