]> USA National Institute of Standards and Technology

ksriram@nist.gov

USA National Institute of Standards and Technology

oliver.borchert@nist.gov

USA National Institute of Standards and Technology

dougm@nist.gov

Routing SIDROPS Working Group BGP, Origin Validation, BGP Policy, BGP Security Deployment of Resource Public Key Infrastructure (RPKI) and Route Origin Authorizations (ROAs) is expected to occur gradually over several or many years. During the incremental deployment period, network operators would wish to have a meaningful policy for dropping Invalid routes. Their goal is to balance (A) dropping Invalid routes so hijacked routes can be eliminated, versus (B) tolerance for missing or erroneously created ROAs for customer prefixes. This document considers a Drop Invalid if Still Routable (DISR) policy that is based on these considerations. The key principle of DISR policy is that an Invalid route can be dropped if a Valid or NotFound route exists for a subsuming less specific prefix.

Deployment of Resource Public Key Infrastructure (RPKI) and Route Origin Authorizations (ROAs) is expected to occur gradually over several or many years. ROA-based BGP Origin Validation (OV) process and the OV states are defined in . During the incremental deployment period, network operators would wish to have a meaningful policy for dropping Invalid routes. Their goal is to balance (A) dropping Invalid routes so hijacked routes can be eliminated, versus (B) tolerance for missing or erroneously created ROAs for customer prefixes. This document considers a Drop Invalid if Still Routable (DISR) policy that is based on these considerations. The key principle of DISR policy is that an Invalid route can be dropped if a Valid or NotFound route exists for a subsuming less specific prefix. The DISR policy applies in addition to (1) preferring Valid when more than one route exists for the same prefix, and (2) always including NotFound routes in the best path selection process. Note that for a router performing OV, the existence of a NotFound route excludes the possibility of an alternate Valid or Invalid route for the same prefix or a subsuming less specific prefix. This document also provides an algorithm for best path selection policy that considers Origin Validation (OV) outcome and includes the DISR policy.

When BGP origin validation (OV) is performed on a BGP route, there are three possible outcomes: (1) Valid, (2) Invalid, or (3) NotFound. During partial/incremental deployment of RPKI and ROAs, it is natural to always include Valid and NotFound routes in the path selection decision process. Note that Valid and NotFound are mutually exclusive, i.e., at a validating router, there cannot be two routes for a prefix where one is Valid and the other is NotFound. Similarly, Invalid and NotFound are also mutually exclusive. If Invalid routes are always dropped from consideration, then there would be no tolerance for missing or erroneously created ROAs for customer prefixes. Then the question arises whether the following policy should be considered: Drop an Invalid route only if another Valid or NotFound route exists for a subsuming less specific prefix? This policy is called Drop Invalid if Still Routable (DISR). The existence of an AS0 ROA for a prefix means that the prefix or any more specific prefix subsumed in it are forbidden from routing except when there exists a different ROA with a normal ASN for the prefix or the more specific prefix. DISR policy MUST apply the following exception: If a route is Invalid due to an AS0 ROA, then always drop the route. Any routes for 0.0.0.0/0 (IPv4) or ::/0 (IPv6) in the routing table must be excluded from consideration in the DISR policy. (Author's note: Think this through with help from the WG.)

Consider these scenarios: Scenario 1: A transit ISP A (AS A) created a ROA for a /22 prefix they announce. They also announce a /24 prefix (subsumed in the /22) that is owned by directly-connected customer X (has no AS). But ISP A neglected to create a ROA for X's /24 prefix. Clearly, the announcement of X's /24 will be Invalid. ISP A happens to propagate to neighbors the /22 and the /24. Scenario 2: Customer X (AS X) announces a /22 prefix only to transit ISP A and a /24 prefix (subsumed in the /22) only to transit ISP B. X is attempting to do traffic engineering (TE). X created a ROA for the /22 but neglected to have ROA coverage for the /24. Clearly, X's announcement of the /24 will be Invalid. ISP B does not participate in OV and propagates the Invalid route to its neighbors. In each of the above scenarios, DISR policy (applied at routers elsewhere in the Internet) ensures that traffic for the more specific (/24) still reaches the correct destination, i.e., customer X (albeit possibly via a suboptimal / non-TE path). Any actual hijacks of the /24 prefix would be dropped at all eBGP routers that employ the DISR policy. Please see for analysis of several more scenarios. Measurements show that if OV were performed, there are 10,417 Invalid routes in the global Internet based on analysis of Routeviews/RPKI/ROA data from February 2018. Of these, 6846 routes are Invalid due to exceeding the maxlength. 6027 of the 6846 Invalid prefixes are seen to be routable via alternate Valid or NotFound routes for either the same prefix (as in the Invalid route) or a subsuming less specific prefix. Again, 5987 of the 6027 are routes for which the corresponding Valid or NotFound routes (with the same or subsuming less specific prefix) have the exact same origin AS as in the Invalid route in question. These measurements show that Scenarios 1 and 2 described above do occur in significant numbers currently. So, the data lends support to the efficacy of the DISR policy in terms of delivering the data traffic to the right destination though not necessarily via the optimal/TE path. Please see for more detailed results from the Routeviews/RPKI/ROA data measurement study. The following is recommended in BCP 185 : "Before issuing a ROA for a super-block, an operator MUST ensure that all sub-allocations from that block that are announced by other ASes, e.g., customers, have correct ROAs in the RPKI." However, as seen by the above measurement data, there are lapses in following this recommendation. Network operators who do not wish to drop Invalid routes outright in partial deployment SHOULD consider employing the DISR policy. It helps eliminate actual prefix hijacks, while incentivizing creation of required ROAs and the adherence to the above recommendation from BCP 185. The stick used here is the possibility of data traveling via a suboptimal path, while the more aggressive stick of dropping all Invalid routes is held in abeyance.

An algorithm for implementation of the DISR policy is as follows. Perform the following steps when a route is received: Perform BGP Origin Validation (OV) on the routes in the Adj-RIB-ins. Apply best path decision process including the results of OV. Include NotFound routes in the decision process. When there is a choice, prefer Valid over Invalid routes. Store the selected routes in the Loc-RIB. Apply the DISR policy. Process routes in the order of least specific to most specific. If a selected route in the Loc-RIB is Valid/NotFound, then add the route to FIB and Adj-RIB-outs; Else, if Invalid, then add the route to FIB and Adj-RIB-outs only if there is no existing Valid/NotFound route in the Loc-RIB for a subsuming Less Specific prefix. Additional steps in the algorithm that are performed in reaction to addition/withdrawal of routes that influence DISR policy decisions and due to changes in RPKI: When a Valid/NotFound route is added to Loc-RIB, check if there are any more specific prefixes in the FIB and Adj-RIB-Outs subsumed by the route prefix; If such more specific prefix route is Invalid, then remove it from the FIB and Adj-RIB-Outs. When a Valid/NotFound route is withdrawn from Loc-RIB, check if there are any more specifics prefixes in the Loc-RIB subsumed by the route prefix; If such more specific prefix route is Invalid, then add the route to FIB and Adj-RIB-outs. When the router is notified of RPKI state change, then list all the prefixes effected by it. Rerun route selection decision and DISR policy for those prefixes.

This document addresses some aspects of best common practices for origin validation and related BGP policy. The security considerations provided in RFC 6811 and BCP 185 also apply here.

&RFC4271; &RFC6811; &RFC6481; &RFC6482; &RFC7115;

The authors wish to thank Sebastian Spies, Saku Ytti, Jeffrey Haas, Tim Bruijnzeels, Keyur Patel, Warren Kumari, John Scudder, and Jay Borkenhagen for comments and discussion related to this work. Also, thanks are due to Lilia Hannachi for her insightful analysis of global RPKI and BGP data that has been helpful in this work.