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 when receiving new RPKI data. A method
for avoiding doing so is described.
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 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 but 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 depoyed, 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, withdrawn,
or merely not chosn as best path due to RPKI-based policy (ROV,
ASPA, etc.), those paths MUST be saved and marked so that later
VRPs can reevaluate them against then current policy.
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.
Routers MUST either keep the full Adj-RIB-In or implement the
specification in .
Operators deploying ROV and/or other RPKI based policies SHOULD
ensure that the router implementation is not causing unnecessary
Route Refresh requests to neighbors.
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 this, 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.
Internet Exchange Points 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.
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 Ben Maddison and Nick Hilliard.