diff --git a/draft-ietf-sidrops-rov-no-rr.xml b/draft-ietf-sidrops-rov-no-rr.xml new file mode 100644 index 0000000..0c17dc8 --- /dev/null +++ b/draft-ietf-sidrops-rov-no-rr.xml @@ -0,0 +1,312 @@ + + + + + + + + + + + + + + + + + + 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 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, withdrawn, + or merely not chosen as best path due to RPKI-based policy (ROV, + ASPA, etc.), those paths MUST be saved and marked (to not be used + for best path evaluation etc.) so that later VRPs can reevaluate + them against then current policy. + + + + 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. + + +
+ +
+ + + 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. + + + + 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, Nick + Hilliard, John Scudder, Matthias Waehlisch, and Saku Ytti. + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + +