AS Hijack Detection and Mitigation

AS hijacking occurs when one AS accidentally or maliciously uses of another AS's AS number (ASN) as the origin ASN in a BGP announcement. The offending AS typically inserts its own ASN as the second ASN in the path after the hijacked origin ASN. The prefix in the announcement may sometimes belong to the hijacker. But AS hijacking is often done in conjunction with hijacking a third-party prefix. The hijacker would typically choose a third-party prefix that does not have Route Origin Authorization (ROA) coverage. Then the route would receive NotFound rather than Invalid validation result when RPKI-based Origin Validation (RPKI-OV) is performed. This benefits the hijacker because NotFound routes are commonly included in route selection by the receiver. This document proposes a method for detection and mitigation of AS hijacking. In this mechanism, an AS operator registers a new object in the RPKI called 'ROAs Exist for All Prefixes (REAP)'. REAP is digitally signed using the AS holder's certificate. By registering a REAP object, the AS operator is declaring that they have Route Origin Authorization (ROA) coverage for all prefixes originated by their AS. A receiving AS will mark a route as Invalid if the prefix is not covered by any Validated ROA Payload (VRP) and the route origin AS has signed a REAP. Here Invalid means that the route is determined to be an AS hijack. It is assumed that a router that supports REAP is also RPKI and RPKI-OV capable. To review some related work, the BGPsec protocol effectively prevents AS hijack attacks but its adoption does not seem likely in the near future. The ASPA method is designed principally for detection of route leaks. In conjunction with checking peer ASN with BGP OPEN message (e.g., enforce-first-as or "peer_lookup_with_open" ), ASPA also addresses AS hijacking in part. However, due to its vulnerability to cut and paste attacks in partial deployment, ASPA will often label such attacks as Unknown rather than Invalid. That gives leeway to an attacker to conduct AS hijacks in partial deployment. Even when an AS creates its ASPA object, if its transit provider does not, then the attacker can conduct the cut and paste attacks involving the AS. On the other hand, the proposed REAP method for detecting AS hijacks works much better even in partial deployment. If AS A creates its REAP object, then a REAP-enabled AS Z (anywhere in the Internet) can perform AS hijack detection for AS A independent of the adoption status of any other ASes. In other words, REAP can be deployed incrementally and the benefits accrue immediately for the REAP object creator and the ASes that have REAP-based AS hijack detection. Of course REAP and ASPA work in a complementary manner. RPKI-OV is known to be vulnerable to forged-origin hijacks (see Section 4.3.1 in ), where a prefix and an origin AS that appear in a ROA are used together. However, in that case the attacker is likely competing with the legitimate Valid announcement for the prefix, and that makes the attack more conspicuous. Generally, the hijacker would seek to remain under the radar. So AS hijacks occur more commonly with a third-party prefix that does not have ROA coverage. The REAP method effectively detects and mitigates this form of attack.

This document specifies a new RPKI object called 'ROAs Exist for All Prefixes (REAP)'. As stated before, REAP is digitally signed using the AS holder's certificate. It contains only an AS number that belongs to the signer. By registering REAP, the AS operator is declaring that they have ROA coverage for all prefixes originated by their AS. REAP extends normal RPKI-OV processing to check if any NotFound route has an origin AS with a valid REAP object. If so, the NotFound result is changed to Invalid. The algorithm to be followed in a receiving BGP router for validating a route is as follows: Perform the RPKI-OV process as normal. If the result of RPKI-OV is NotFound and the origin AS has a valid (per X.509) REAP object, then replace NotFound with Invalid. The operator SHOULD apply policy to reject routes with Invalid outcome in order to perform AS hijack mitigation along with prefix hijack mitigation.