[Docs] [txt|pdf] [Tracker] [Email] [Nits]



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
   likely in the near future.  The ASPA method



Sriram & Montgomery     Expires January 14, 2021                [Page 2]


Internet-Draft     AS Hijack Detection and Mitigation          July 2020


   [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.

2.  AS Hijack Detection and Mitigation Method

   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.  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:

   1.  Perfrom the RPKI-OV process [RFC6811] as normal.

   2.  If the result of RPKI-OV is NotFound and if the origin AS has
       REAP, then replace NotFound with Invalid.





Sriram & Montgomery     Expires January 14, 2021                [Page 3]


Internet-Draft     AS Hijack Detection and Mitigation          July 2020


   The operator SHOULD apply policy to reject routes with Invalid
   outcome in order to perform AS hijack mitigation along with prefix
   hijack mitigation.

3.  IANA Considerations

   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]


4.  Security Considerations

   The security considerations that apply to RPKI, ROAs, and RPKI-OV
   (see [RFC6480] [RFC6482] [RFC6811]) also apply to the procedure
   described in this document.

5.  References

5.1.  Normative References

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <https://www.rfc-editor.org/info/rfc6480>.

   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)", RFC 6482,
              DOI 10.17487/RFC6482, February 2012,
              <https://www.rfc-editor.org/info/rfc6482>.

   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,
              <https://www.rfc-editor.org/info/rfc6811>.

5.2.  Informative References

   [Cisco-IOS]
              "Cisco IOS IP Routing: BGP Command Reference (enforce-
              first-as)", Cisco IOS information webpage ,  ,
              <https://www.cisco.com/c/en/us/td/docs/ios-
              xml/ios/iproute_bgp/command/irg-cr-book/bgp-
              a1.html#wp1026344430>.





Sriram & Montgomery     Expires January 14, 2021                [Page 4]


Internet-Draft     AS Hijack Detection and Mitigation          July 2020


   [I-D.ietf-sidrops-aspa-verification]
              Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J.
              Snijders, "Verification of AS_PATH Using the Resource
              Certificate Public Key Infrastructure and Autonomous
              System Provider Authorization", draft-ietf-sidrops-aspa-
              verification-04 (work in progress), March 2020.

   [NIST-800-189]
              Sriram, K. and D. Montgomery, "Resilient Interdomain
              Traffic Exchange: BGP Security and DDoS Mitigation", NIST
              Special Publication NIST SP 800-189,  , December 2019,
              <https://doi.org/10.6028/NIST.SP.800-189>.

   [Quagga]   "LCOV - code coverage report (peer_lookup_with_open)",
              Quagga information webpage ,  , <https://nowhere.ws/dump/
              quagga-srcdest-coverage/bgpd/bgpd.c.func.html>.

   [RFC8205]  Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
              Specification", RFC 8205, DOI 10.17487/RFC8205, September
              2017, <https://www.rfc-editor.org/info/rfc8205>.

Acknowledgements

   The authors wish to thank Oliver Borchert and Kyehwan Lee for their
   review and comments.

Authors' Addresses

   Kotikalapudi Sriram
   USA National Institute of Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899
   United States of America

   Email: ksriram@nist.gov


   Doug Montgomery
   USA National Institute of Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899
   United States of America

   Email: dougm@nist.gov







Sriram & Montgomery     Expires January 14, 2021                [Page 5]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/