RPKI-Based Policy Without Route Refresh

Memory constraints in early routers caused classic BGP implementations to not keep a full Adj-RIB-In (Sec. 1.1). When doing RPKI-based Route Origin Validation ( and ), 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 from its neighbors to recover the paths which 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.

It is assumed that the reader understands BGP, and Route Refresh , the RPKI , Route Origin Authorizations (ROAs), , The Resource Public Key Infrastructure (RPKI) to Router Protocol , RPKI-based Prefix Validation, , and Origin Validation Clarifications, .

As Route Origin Validation dropping Invalids has deployed, some router implementations have been found which, when receiving new RPKI data (VRPs, see ) issue a BGP Route Refresh to all sending BGP peers so that it can reevaluate the received paths aginst 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; and 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 routers. As ASPA () becomes used, the problem will increase.

Ameliorating this problem by keeping a full Adj-RIB-In can be a problem for resource constrained routers. In reality, only some data need be retained. When RPKI data cause one or more paths to be dropped due to ROV, those paths MUST NOT be evaluated for best path, but MUST be saved (either separately or marked) so they may be reevaluated with respect to new RPKI data. If new RPKI data arrive which invalidate the best path, and the router did not keep all alternatives, then it MUST issue a route refresh so those alternatives may be evaluated for best path. Policy which may drop paths due to RPKI-based checks such as ROV, ASPA, BGPsec , etc. MUST be run, and the dropped paths saved per the above paragraph, before non-RPKI policies are run, as the latter may change path attributes. As storing these paths could cause problems in resource constrained devices, there MUST be a knob allowing operator control of this feature. Such a knob MUST NOT be per peer, as this could cause inconsistent behavior. 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 path selection and in outbound signaling.

Operators deploying ROV and/or other RPKI based policies SHOULD ensure that the router implementation is not causing unnecessary Route Refresh requests to neighbors. Routers MUST either keep the full Adj-RIB-In or implement the specification in . If the router does not implement these recommendations, the operator SHOULD enable the vendor's knob 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 router has insufficient resources to support either of the two proposed options, it MUST not be used for Route Origin Validation. I.e. the knob in should only be used in very well known and controlled circumstances. Operators using the specification in should be aware that a misconfigured neighbor might erroneously send a massive number of paths, thus consuming a lot of memory. Pre-policy filtering such as described in SHOULD be used to reduce this exposure. Internet Exchange Points (IXPs)which provide Route Servers 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 routers as route servers should ensure that they are not generating excessive route refresh requests.

This document describes a denial of service which 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.

None

The authors wish to thank Ben Maddison, John Heasley, John Scudder, Matthias Waehlisch, Nick Hilliard, Saku Ytti, and Ties de Kock.