AS Hijack Detection and Mitigation
draft-sriram-sidrops-as-hijack-detection-01
IDR and SIDR K. Sriram
Internet-Draft D. Montgomery
Intended status: Standards Track USA NIST
Expires: July 18, 2021 January 14, 2021
AS Hijack Detection and Mitigation
draft-sriram-sidrops-as-hijack-detection-01
Abstract
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.
Status of This Memo
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 July 18, 2021.
Copyright Notice
Copyright (c) 2021 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
Sriram & Montgomery Expires July 18, 2021 [Page 1]
Internet-Draft AS Hijack Detection and Mitigation January 2021
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. AS Hijack Detection and Mitigation Method . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Normative References . . . . . . . . . . . . . . . . . . 4
5.2. Informative References . . . . . . . . . . . . . . . . . 4
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
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
Show full document text