idnits 2.17.1 draft-sriram-sidrops-as-hijack-detection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '... The operator SHOULD apply policy to...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 6480 == Outdated reference: A later version (-17) exists of draft-ietf-sidrops-aspa-verification-04 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR and SIDR K. Sriram 3 Internet-Draft D. Montgomery 4 Intended status: Standards Track USA NIST 5 Expires: January 14, 2021 July 13, 2020 7 AS Hijack Detection and Mitigation 8 draft-sriram-sidrops-as-hijack-detection-00 10 Abstract 12 This document proposes a method for detection and mitigation of AS 13 hijacking. In this mechanism, an AS operator registers a new object 14 in the RPKI called 'ROAs Exist for All Prefixes (REAP)'. REAP is 15 digitally signed using the AS holder's certificate. By registering 16 REAP, the AS operator is declaring that they have Route Origin 17 Authorization (ROA) coverage for all prefixes originated by their AS. 18 A receiving AS will mark a route as Invalid if the prefix is not 19 covered by any Validated ROA Payload (VRP) and the route origin AS 20 has signed a REAP. Here Invalid means that the route is determined 21 to be an AS hijack. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 14, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. AS Hijack Detection and Mitigation Method . . . . . . . . . . 3 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 5.2. Informative References . . . . . . . . . . . . . . . . . 4 64 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 AS hijacking occurs when one AS accidentally or maliciously uses of 70 another AS's AS number (ASN) as the origin ASN in a BGP announcement. 71 The offending AS typically inserts its own ASN as the second ASN in 72 the path after the hijacked origin ASN. The prefix in the 73 announcement may sometimes belong to the hijacker. But AS hijacking 74 is often done in conjunction with hijacking a third-party prefix. 75 The hijacker would typically choose a third-party prefix that does 76 not have Route Origin Authorization (ROA) [RFC6482] coverage. Then 77 the route would receive NotFound rather than Invalid validation 78 result when RPKI-based Origin Validation (RPKI-OV) [RFC6811] is 79 performed. This benefits the hijacker because NotFound routes are 80 commonly included in route selection by the receiver. 82 This document proposes a method for detection and mitigation of AS 83 hijacking. In this mechanism, an AS operator registers a new object 84 in the RPKI called 'ROAs Exist for All Prefixes (REAP)'. REAP is 85 digitally signed using the AS holder's certificate. By registering 86 REAP, the AS operator is declaring that they have Route Origin 87 Authorization (ROA) coverage for all prefixes originated by their AS. 88 A receiving AS will mark a route as Invalid if the prefix is not 89 covered by any Validated ROA Payload (VRP) and the route origin AS 90 has signed a REAP. Here Invalid means that the route is determined 91 to be an AS hijack. It is assumed that a router that supports REAP 92 is also RPKI [RFC6482] and RPKI-OV [RFC6811] capable. 94 To review some related work, the BGPsec protocol [RFC8205] 95 effectively prevents AS hijack attacks but its adoption does not seem 96 likely in the near future. The ASPA method 98 [I-D.ietf-sidrops-aspa-verification] is designed principally for 99 detection of route leaks. In conjunction with checking peer ASN with 100 BGP OPEN message (e.g., enforce-first-as [Cisco-IOS] or 101 "peer_lookup_with_open" [Quagga]), ASPA also addresses AS hijacking 102 in part. However, due to its vulnerability to cut and paste attacks 103 in partial deployment, ASPA will often label such attacks as Unknown 104 rather than Invalid. That gives leeway to an attacker to conduct AS 105 hijacks in partial deployment. Even when an AS creates its ASPA 106 object, if its transit provider does not, then the attacker can 107 conduct the cut and paste attacks involving the AS. On the other 108 hand, the proposed REAP method for detecting AS hijacks works much 109 better even in partial deployment. If AS A creates its REAP object, 110 then a REAP-enabled AS Z (anywhere in the Internet) can perform AS 111 hijack detection for AS A independent of the adoption status of any 112 other ASes. In other words, REAP can be deployed incrementally and 113 the benefits accrue immediately for the REAP object creator and the 114 ASes that have REAP-based AS hijack detection. Of course REAP and 115 ASPA work in a complementary manner. 117 RPKI-OV is known to be vulnerable to forged-origin hijacks (see 118 Section 4.3.1 in [NIST-800-189]), where a prefix and an origin AS 119 that appear in a ROA are used together. However, in that case the 120 attacker is likely competing with the legitimate Valid announcement 121 for the prefix, and that makes the attack more conspicuous. 122 Generally, the hijacker would seek to remain under the radar. So AS 123 hijacks occur more commonly with a third-party prefix that does not 124 have ROA coverage. The REAP method effectively detects and mitigates 125 this form of attack. 127 2. AS Hijack Detection and Mitigation Method 129 This document specifies a new RPKI object called 'ROAs Exist for All 130 Prefixes (REAP)'. As stated before, REAP is digitally signed using 131 the AS holder's certificate. By registering REAP, the AS operator is 132 declaring that they have ROA coverage for all prefixes originated by 133 their AS. REAP extends normal RPKI-OV processing to check if any 134 NotFound route has an origin AS with a valid REAP object. If so, the 135 NotFound result is changed to Invalid. 137 The algorithm to be followed in a receiving BGP router for validating 138 a route is as follows: 140 1. Perfrom the RPKI-OV process [RFC6811] as normal. 142 2. If the result of RPKI-OV is NotFound and if the origin AS has 143 REAP, then replace NotFound with Invalid. 145 The operator SHOULD apply policy to reject routes with Invalid 146 outcome in order to perform AS hijack mitigation along with prefix 147 hijack mitigation. 149 3. IANA Considerations 151 IANA is requested to register the following RPKI Signed Object: 153 Name OBJECT IDENTIFIER (OID) value Reference 154 ------- ----------------------------- --------- 155 REAP 1.2.840.113549.1.9.16.1.TBD [This document] 157 4. Security Considerations 159 The security considerations that apply to RPKI, ROAs, and RPKI-OV 160 (see [RFC6480] [RFC6482] [RFC6811]) also apply to the procedure 161 described in this document. 163 5. References 165 5.1. Normative References 167 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 168 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 169 February 2012, . 171 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 172 Origin Authorizations (ROAs)", RFC 6482, 173 DOI 10.17487/RFC6482, February 2012, 174 . 176 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 177 Austein, "BGP Prefix Origin Validation", RFC 6811, 178 DOI 10.17487/RFC6811, January 2013, 179 . 181 5.2. Informative References 183 [Cisco-IOS] 184 "Cisco IOS IP Routing: BGP Command Reference (enforce- 185 first-as)", Cisco IOS information webpage , , 186 . 190 [I-D.ietf-sidrops-aspa-verification] 191 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. 192 Snijders, "Verification of AS_PATH Using the Resource 193 Certificate Public Key Infrastructure and Autonomous 194 System Provider Authorization", draft-ietf-sidrops-aspa- 195 verification-04 (work in progress), March 2020. 197 [NIST-800-189] 198 Sriram, K. and D. Montgomery, "Resilient Interdomain 199 Traffic Exchange: BGP Security and DDoS Mitigation", NIST 200 Special Publication NIST SP 800-189, , December 2019, 201 . 203 [Quagga] "LCOV - code coverage report (peer_lookup_with_open)", 204 Quagga information webpage , , . 207 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 208 Specification", RFC 8205, DOI 10.17487/RFC8205, September 209 2017, . 211 Acknowledgements 213 The authors wish to thank Oliver Borchert and Kyehwan Lee for their 214 review and comments. 216 Authors' Addresses 218 Kotikalapudi Sriram 219 USA National Institute of Standards and Technology 220 100 Bureau Drive 221 Gaithersburg, MD 20899 222 United States of America 224 Email: ksriram@nist.gov 226 Doug Montgomery 227 USA National Institute of Standards and Technology 228 100 Bureau Drive 229 Gaithersburg, MD 20899 230 United States of America 232 Email: dougm@nist.gov