| Internet-Draft | AS Hijack Detection and Mitigation | January 2022 |
| Sriram & Montgomery | Expires 14 July 2022 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 14 July 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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) [RFC6482] coverage. Then the route would receive NotFound rather than Invalid validation result when RPKI-based Origin Validation (RPKI-OV) [RFC6811] 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 [RFC6482] and RPKI-OV [RFC6811] capable.¶
To review some related work, the BGPsec protocol [RFC8205] effectively prevents AS hijack attacks but its adoption does not seem likely in the near future. The ASPA method [I-D.ietf-sidrops-aspa-verification] is designed principally for detection of route leaks. In conjunction with checking peer ASN with BGP OPEN message (e.g., enforce-first-as [Cisco-IOS] or "peer_lookup_with_open" [Quagga]), 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 [NIST-800-189]), 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:¶
The operator SHOULD apply policy to reject routes with Invalid outcome in order to perform AS hijack mitigation along with prefix hijack mitigation.¶
IANA is requested to register the following RPKI Signed Object:¶
Name OBJECT IDENTIFIER (OID) value Reference
------- ----------------------------- ---------
REAP 1.2.840.113549.1.9.16.1.TBD [This document]
¶
The security considerations that apply to RPKI, ROAs, and RPKI-OV (see [RFC6480] [RFC6482] [RFC6811]) also apply to the procedure described in this document.¶
The authors wish to thank Oliver Borchert and Kyehwan Lee for their review and comments.¶