idnits 2.17.1 draft-sriram-sidrops-as-hijack-detection-01.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 147: '... 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 (January 14, 2021) is 1197 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-06 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: July 18, 2021 January 14, 2021 7 AS Hijack Detection and Mitigation 8 draft-sriram-sidrops-as-hijack-detection-01 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 July 18, 2021. 40 Copyright Notice 42 Copyright (c) 2021 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 a 86 REAP object, 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. It contains only an AS number that 132 belongs to the signer. By registering REAP, the AS operator is 133 declaring that they have ROA coverage for all prefixes originated by 134 their AS. REAP extends normal RPKI-OV processing to check if any 135 NotFound route has an origin AS with a valid REAP object. If so, the 136 NotFound result is changed to Invalid. 138 The algorithm to be followed in a receiving BGP router for validating 139 a route is as follows: 141 1. Perform the RPKI-OV process [RFC6811] as normal. 143 2. If the result of RPKI-OV is NotFound and the origin AS has a 144 valid (per X.509) REAP object, then replace NotFound with 145 Invalid. 147 The operator SHOULD apply policy to reject routes with Invalid 148 outcome in order to perform AS hijack mitigation along with prefix 149 hijack mitigation. 151 3. IANA Considerations 153 IANA is requested to register the following RPKI Signed Object: 155 Name OBJECT IDENTIFIER (OID) value Reference 156 ------- ----------------------------- --------- 157 REAP 1.2.840.113549.1.9.16.1.TBD [This document] 159 4. Security Considerations 161 The security considerations that apply to RPKI, ROAs, and RPKI-OV 162 (see [RFC6480] [RFC6482] [RFC6811]) also apply to the procedure 163 described in this document. 165 5. References 167 5.1. Normative References 169 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 170 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 171 February 2012, . 173 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 174 Origin Authorizations (ROAs)", RFC 6482, 175 DOI 10.17487/RFC6482, February 2012, 176 . 178 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 179 Austein, "BGP Prefix Origin Validation", RFC 6811, 180 DOI 10.17487/RFC6811, January 2013, 181 . 183 5.2. Informative References 185 [Cisco-IOS] 186 "Cisco IOS IP Routing: BGP Command Reference (enforce- 187 first-as)", Cisco IOS information webpage , , 188 . 192 [I-D.ietf-sidrops-aspa-verification] 193 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. 194 Snijders, "Verification of AS_PATH Using the Resource 195 Certificate Public Key Infrastructure and Autonomous 196 System Provider Authorization", draft-ietf-sidrops-aspa- 197 verification-06 (work in progress), November 2020. 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