idnits 2.17.1 draft-sriram-sidrops-as-hijack-detection-03.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 (10 January 2022) is 834 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-08 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: 14 July 2022 10 January 2022 7 AS Hijack Detection and Mitigation 8 draft-sriram-sidrops-as-hijack-detection-03 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 a 16 REAP object, 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 14 July 2022. 40 Copyright Notice 42 Copyright (c) 2022 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 (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. AS Hijack Detection and Mitigation Method . . . . . . . . . . 3 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 62 5.2. Informative References . . . . . . . . . . . . . . . . . 4 63 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 AS hijacking occurs when one AS accidentally or maliciously uses of 69 another AS's AS number (ASN) as the origin ASN in a BGP announcement. 70 The offending AS typically inserts its own ASN as the second ASN in 71 the path after the hijacked origin ASN. The prefix in the 72 announcement may sometimes belong to the hijacker. But AS hijacking 73 is often done in conjunction with hijacking a third-party prefix. 74 The hijacker would typically choose a third-party prefix that does 75 not have Route Origin Authorization (ROA) [RFC6482] coverage. Then 76 the route would receive NotFound rather than Invalid validation 77 result when RPKI-based Origin Validation (RPKI-OV) [RFC6811] is 78 performed. This benefits the hijacker because NotFound routes are 79 commonly included in route selection by the receiver. 81 This document proposes a method for detection and mitigation of AS 82 hijacking. In this mechanism, an AS operator registers a new object 83 in the RPKI called 'ROAs Exist for All Prefixes (REAP)'. REAP is 84 digitally signed using the AS holder's certificate. By registering a 85 REAP object, the AS operator is declaring that they have Route Origin 86 Authorization (ROA) coverage for all prefixes originated by their AS. 87 A receiving AS will mark a route as Invalid if the prefix is not 88 covered by any Validated ROA Payload (VRP) and the route origin AS 89 has signed a REAP. Here Invalid means that the route is determined 90 to be an AS hijack. It is assumed that a router that supports REAP 91 is also RPKI [RFC6482] and RPKI-OV [RFC6811] capable. 93 To review some related work, the BGPsec protocol [RFC8205] 94 effectively prevents AS hijack attacks but its adoption does not seem 95 likely in the near future. The ASPA method 96 [I-D.ietf-sidrops-aspa-verification] is designed principally for 97 detection of route leaks. In conjunction with checking peer ASN with 98 BGP OPEN message (e.g., enforce-first-as [Cisco-IOS] or 99 "peer_lookup_with_open" [Quagga]), ASPA also addresses AS hijacking 100 in part. However, due to its vulnerability to cut and paste attacks 101 in partial deployment, ASPA will often label such attacks as Unknown 102 rather than Invalid. That gives leeway to an attacker to conduct AS 103 hijacks in partial deployment. Even when an AS creates its ASPA 104 object, if its transit provider does not, then the attacker can 105 conduct the cut and paste attacks involving the AS. On the other 106 hand, the proposed REAP method for detecting AS hijacks works much 107 better even in partial deployment. If AS A creates its REAP object, 108 then a REAP-enabled AS Z (anywhere in the Internet) can perform AS 109 hijack detection for AS A independent of the adoption status of any 110 other ASes. In other words, REAP can be deployed incrementally and 111 the benefits accrue immediately for the REAP object creator and the 112 ASes that have REAP-based AS hijack detection. Of course REAP and 113 ASPA work in a complementary manner. 115 RPKI-OV is known to be vulnerable to forged-origin hijacks (see 116 Section 4.3.1 in [NIST-800-189]), where a prefix and an origin AS 117 that appear in a ROA are used together. However, in that case the 118 attacker is likely competing with the legitimate Valid announcement 119 for the prefix, and that makes the attack more conspicuous. 120 Generally, the hijacker would seek to remain under the radar. So AS 121 hijacks occur more commonly with a third-party prefix that does not 122 have ROA coverage. The REAP method effectively detects and mitigates 123 this form of attack. 125 2. AS Hijack Detection and Mitigation Method 127 This document specifies a new RPKI object called 'ROAs Exist for All 128 Prefixes (REAP)'. As stated before, REAP is digitally signed using 129 the AS holder's certificate. It contains only an AS number that 130 belongs to the signer. By registering REAP, the AS operator is 131 declaring that they have ROA coverage for all prefixes originated by 132 their AS. REAP extends normal RPKI-OV processing to check if any 133 NotFound route has an origin AS with a valid REAP object. If so, the 134 NotFound result is changed to Invalid. 136 The algorithm to be followed in a receiving BGP router for validating 137 a route is as follows: 139 1. Perform the RPKI-OV process [RFC6811] as normal. 141 2. If the result of RPKI-OV is NotFound and the origin AS has a 142 valid (per X.509) REAP object, then replace NotFound with 143 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", Work in Progress, 195 Internet-Draft, draft-ietf-sidrops-aspa-verification-08, 196 25 August 2021, . 199 [NIST-800-189] 200 Sriram, K. and D. Montgomery, "Resilient Interdomain 201 Traffic Exchange: BGP Security and DDoS Mitigation", NIST 202 Special Publication NIST SP 800-189, , December 2019, 203 . 205 [Quagga] "LCOV - code coverage report (peer_lookup_with_open)", 206 Quagga information webpage , , . 209 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 210 Specification", RFC 8205, DOI 10.17487/RFC8205, September 211 2017, . 213 Acknowledgements 215 The authors wish to thank Oliver Borchert and Kyehwan Lee for their 216 review and comments. 218 Authors' Addresses 220 Kotikalapudi Sriram 221 USA National Institute of Standards and Technology 222 100 Bureau Drive 223 Gaithersburg, MD 20899 224 United States of America 226 Email: ksriram@nist.gov 228 Doug Montgomery 229 USA National Institute of Standards and Technology 230 100 Bureau Drive 231 Gaithersburg, MD 20899 232 United States of America 234 Email: dougm@nist.gov