AS Hijack Detection and Mitigation
draft-sriram-sidrops-as-hijack-detection-00

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

IDR and SIDR                                                   K. Sriram
Internet-Draft                                             D. Montgomery
Intended status: Standards Track                                USA NIST
Expires: January 14, 2021                                  July 13, 2020

                   AS Hijack Detection and Mitigation
              draft-sriram-sidrops-as-hijack-detection-00

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
   REAP, 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 January 14, 2021.

Copyright Notice

   Copyright (c) 2020 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 January 14, 2021                [Page 1]
Internet-Draft     AS Hijack Detection and Mitigation          July 2020

   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
   REAP, 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