RPKI Route Origin Validation 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 Route Origin Validation should
not issue Route Refresh to its neighbors when receiving new VRPs.
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 ), if such a BGP speaker receives new ROAs/VRPs,
it might not have kept paths previously marked as Invalid. Such
an implementation must then request a Route Refresh from its neighbors to recover the paths which
might be covered by these new VRPs. 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
Invalidated paths so the 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,
.
Routers MUST either keep the full Adj-RIB-In or implement this
specification.
Operators deploying ROV SHOULD ensure that the router
implementation is not causing unnecessary Route Refresh requests
to neighbors.
If the router does not implement the recommendations here, 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 ensure that this stops
unnecessary Route Refresh requests to neighbors.
If the router has insufficient resources to support this, it
MUST not be used for Route Origin Validation.
This document describes a denial of service Route Origin
Validation 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.