RPKI-Based Policy Without Route Refresh
IIJ Research Lab & Arrcus, Inc.
1856 SW Edgewood Dr
Portland
Oregon
97210
United States of America
randy@psg.com
Arrcus, Inc.
2077 Gateway Place, Suite #400
San Jose
CA
95119
United States of America
keyur@arrcus.com
PFS Internet Development Pty Ltd
PO Box 1908
Milton
QLD
4064
Australia
pfsinoz@gmail.com
SEACOM
Building 7, Design Quarter District, Leslie Avenue, Magaliessig
Fourways, Gauteng
2196
South Africa
mark@tinka.africa
A BGP Speaker performing RPKI-based policy should not issue Route
Refresh to its neighbors because it has received new RPKI data.
This document updates 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.
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 when, and only when, they appear in all
capitals, as shown here.
Memory constraints in early BGP speakers caused classic BGP implementations to not keep a full
Adj-RIB-In (Sec. 1.1). When doing RPKI-based Route Origin
Validation (ROV) ( 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, and , 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
BGP speaker 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 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 ASPA
() 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 by
describing how to avoid this problem.
If new RPKI data arrive which cause operator policy to invalidate
the best route, and the BGP speaker did not keep the dropped
routes, then it 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 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,
etc. allowing the operator to enable this feature, storing the
dropped routes. Such an operator control MUST NOT be per peer, as
this could cause inconsistent behavior.
As a side note: policy which may drop routes due to RPKI-based
checks such as ROV (and ASPA, BGPsec ,
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 . Conformance to this
behavior is a 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 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 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 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 in outbound signaling.
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 BGP speakers 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.
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.