idnits 2.17.1 draft-azimov-sidrops-aspa-verification-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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2018) is 2128 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) == Outdated reference: A later version (-24) exists of draft-ietf-idr-bgp-open-policy-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Azimov 3 Internet-Draft E. Bogomazov 4 Intended status: Standards Track Qrator Labs 5 Expires: December 30, 2018 R. Bush 6 Internet Initiative Japan 7 K. Patel 8 Arrcus, Inc. 9 J. Snijders 10 NTT 11 June 28, 2018 13 Verification of AS_PATH Using the Resource Certificate Public Key 14 Infrastructure and Autonomous System Provider Authorization 15 draft-azimov-sidrops-aspa-verification-00 17 Abstract 19 This document defines the semantics of an Autonomous System Provider 20 Authorization object in the Resource Public Key Infrastructure to 21 verify the AS_PATH attribute of routes advertised in the Border 22 Gateway Protocol. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 28 "OPTIONAL" in this document are to be interpreted as described in BCP 29 14 [RFC2119] [RFC8174] when, and only when, they appear in all 30 capitals, as shown here. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 30, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Autonomous System Provider Authorization . . . . . . . . . . 3 68 3. Anomaly Propagation . . . . . . . . . . . . . . . . . . . . . 3 69 4. Customer-Provider Verification Procedure . . . . . . . . . . 4 70 5. AS_PATH Verification . . . . . . . . . . . . . . . . . . . . 4 71 6. Disavowal of Provider Authorizaion . . . . . . . . . . . . . 6 72 7. Siblings (Complex Relations) . . . . . . . . . . . . . . . . 6 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 10.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 The Border Gateway Protocol (BGP) was designed with no mechanisms to 83 validate BGP attributes. Two consequences are BGP Hijacks and BGP 84 Route Leaks [RFC7908]. BGP extensions are able to partially solve 85 these problems. For example, ROA-based Origin Validation [RFC6483] 86 can be used to detect and filter accidental mis-originations, and 87 [I-D.ymbk-idr-bgp-eotr-policy] can be used to detect accidental route 88 leaks. While these upgrades to BGP are quite useful, they still rely 89 on transitive BGP attributes, i.e. AS_PATH, that can be manipulated 90 by attackers. 92 BGPSec [RFC8205] was designed to solve the problem of AS_PATH 93 correctness. But ignoring the complexity of this extension, it has 94 backward support for 'old' BGP-4 that an attacker can use in a 95 downgrade attack to nullify all the work of AS_PATH signing. As a 96 result, to abuse the AS_PATH or any other transit attribute, an 97 attacker merely needs to downgrade to 'old' BGP-4. 99 This document defines the semantics of Autonomous System Provider 100 Authorization (ASPA) using the Resource Public Key Infrastructure 101 (RPKI) to verify the AS_PATH attribute of routes advertised in BGP. 102 It specifies AS_PATH verification procedures to allow a BGP listener 103 to detect and mitigate malicious hijacks and route leaks. 105 2. Autonomous System Provider Authorization 107 As described in [RFC6480], the RPKI is based on a hierarchy of 108 resource certificates that are aligned to the Internet Number 109 Resource allocation structure. Resource certificates are X.509 110 certificates that conform to the PKIX profile [RFC5280], and to the 111 extensions for IP addresses and AS identifiers [RFC3779]. A resource 112 certificate is a binding by an issuer of IP address blocks and 113 Autonomous System (AS) numbers to the subject of a certificate, 114 identified by the unique association of the subject's private key 115 with the public key contained in the resource certificate. The RPKI 116 is structured so that each current resource certificate matches a 117 current resource allocation or assignment. 119 ASPAs are digitally signed objects that bind a in a selected AFI 120 Provider AS number to a Customer AS number (in terms of BGP 121 announcements not business), and are signed by the holder of the 122 Customer AS. An ASPA attests that a Customer AS holder (CAS) has 123 authorized a particular Provider AS (PAS) to propagate the Customer's 124 IPv4/IPv6 announcements onward, e.g. to the Provider's upstream 125 providers or peers. The ASPA record profile is described in [#link]. 126 The ASPA mechanism combined with BGP Roles 127 [I-D.ietf-idr-bgp-open-policy] and ROA-based Origin Validation 128 [RFC6483] provide a fully automated solution to detect and filter 129 hijacks and route leaks, including malicious ones. 131 3. Anomaly Propagation 133 Both route leaks and hijacks have similar effects on ISP operations - 134 they redirect traffic, resulting in increased latency, packet loss, 135 or possible MiTM attacks. But the level of risk depends 136 significantly on the propagation of these BGP anomalies. For 137 example, a hijack that is propagated only to customers may 138 concentrate traffic in a particular ISP's customer cone; while if the 139 anomaly is propagated through peers, upstreams, or reaches Tier-1 140 networks, thus distributing globally, traffic may be redirected at 141 the level of entire countries and/or global providers. 143 The ability to constrain propagation of BGP anomalies to upstreams 144 and peers, without requiring support from the source of the anomaly 145 (which is critical if source has malicious intent), should 146 significantly improve the security of inter-domain routing and solve 147 the majority of problems. 149 4. Customer-Provider Verification Procedure 151 This section describes an abstract procedure that checks that pair of 152 ASNs (AS1, AS2) is included in the set of signed ASPAs. The 153 semantics of its usage is defined in next section. The procedure 154 takes (AS1, AS2, ROUTE_AFI) as input parameters and may return three 155 types of results: "valid", "invalid" and "unknown". 157 A relying party (RP) must have access to a local cache of the 158 complete set of cryptographically valid ASPAs when performing 159 customer-provider verification procedure. 161 1. Retrieve all cryptographically valid ASPAs in a selected AFI with 162 a customer value of AS1. This selection forms the set of 163 "candidate ASPAs." 165 2. If the set of candidate ASPAs is empty, then the procedure exits 166 with an outcome of "unknown." 168 3. If there is at least one candidate ASPA where the provider field 169 is AS2, then the procedure exits with an outcome of "valid." 171 4. Otherwise, the procedure exits with an outcome of "invalid." 173 Since an AS1 may have different set providers in different AFI, it 174 should also have different set of corresponding ASPAs. In this case, 175 the output of this procedure with input (AS1, AS2, ROUTE_AFI) may 176 have different output for different ROUTE_AFI values. 178 5. AS_PATH Verification 180 The AS_PATH attribute identifies the autonomous systems through which 181 an UPDATE message has passed. AS_PATH may contain two types of 182 components: ordered AS_SEQes and unordered AS_SETs, as defined in 183 [RFC4271]. 185 The value of each AS_SEQ component can be described as set of pairs 186 {(AS(I), prepend(I)), (AS(I-1), prepend(I-1))...}. In this case, the 187 sequence {AS(I), AS(I-1),...} represents different ASNs, that packet 188 should pass towards the destination. We can state that when a route 189 is received from a customer or a literal peer, each pair (AS(I-1), 190 AS(I)) MUST belong to customer-provider or sibling relationship. If 191 there are other types of relationships, it means that the route was 192 leaked or the AS_PATH attribute was malformed. The goal of the above 193 procedure is to check the correctness of this statement. 195 If a route from ROUTE_AFI address family is received from a customer 196 or peer, its AS_PATH MUST be verified as follows: 198 1. If the closest AS in the AS_PATH is not the receiver's neighbor 199 ASN then procedure halts with the outcome "invalid"; 201 2. If in one of AS_SEQ segments there is a pair (AS(I-1), AS(I)), 202 where both AS(I-1), AS(I) are not equal to AS_TRANS and customer- 203 provider verification procedure (Section 4) with parameters 204 (AS(I-1), AS(I), ROUTE_AFI) returns "invalid" then the procedure 205 also halts with the outcome "invalid"; 207 3. If in one of AS_PATH segments there is at least one AS_TRANS 208 (AS23456) then procedure halts with the outcome "unverifiable"; 210 4. If the AS_PATH has at least one AS_SET segment then procedure 211 halts with the outcome "unverifiable"; 213 5. Otherwise, the procedure halts with an outcome of "valid". 215 If the output of the AS_PATH verification procedure is "invalid" the 216 LOCAL_PREF SHOULD be set to 0 or the route MAY be dropped. If an 217 "invalid" route has no alternative route(s) and it is propagated to 218 other ASes despite the above, it MUST be marked with the 219 GRACEFUL_SHUTDOWN community to avoid possible stable oscillations, 220 when an unchecked route received from a provider becomes preferred 221 over an invalid route received from a customer. This also allows 222 customers to detect malformed routes received from upstream 223 providers. 225 If the output of the AS_PATH verification procedure is 'unverifiable' 226 it means that AS_PATH can't be fully verified. Such routes should be 227 treated with caution and MAY be processed the same way as "invalid" 228 routes. 230 The above AS_PATH verification procedure checks routes received from 231 customers and peers. The information about peering relations can be 232 automatically retrieved from BGP roles settings, thus improving 233 reliability and providing the possibility for full automation. 235 6. Disavowal of Provider Authorizaion 237 An ASPA is a positive attestation that an AS holder has authorized 238 its provider to redistribute received routes to the provider's 239 providers and peers. This does not preclude the provider AS from 240 redistribution to its other customers. By creating an ASPA where the 241 provider AS is 0, the customer indicates that no provider should 242 further announce its routes. Specifically, AS 0 is reserved to 243 identify provider-free networks, Internet exchange meshes, etc. 245 An ASPA with a provider AS of 0 is an statement by the customer AS 246 that the its routes should not be received by any relying party AS 247 from any of its customers or peers. 249 By convention, an ASPA with a provider AS of 0 should be the only 250 ASPA issued by a given AS holder; although this is not a strict 251 requirement. A provider 0 ASPA may coexist with ASPAs that have 252 different provider AS values; though in such cases, the presence or 253 absence of the provider AS 0 ASPA does not alter the AS_PATH 254 verification procedure. 256 7. Siblings (Complex Relations) 258 There are peering relationships which can not be described as 259 strictly simple peer-peer or customer-provider; e.g. when both 260 parties are intentionally sending prefixes received from each other 261 to their peers and/or upstreams. 263 In this case, two symmetric ASPAs records {(AS1, AS2), (AS2, AS1)} 264 must be created by AS1 and AS2 respectively. 266 8. Security Considerations 268 ASPA issuers should be aware of the verification implication in 269 issuing an ASPA - an ASPA implicitly invalidates all routes passed to 270 upstream providers other than the provider ASs listed in the 271 collection of ASPAs. It is the Customer AS's duty to maintain a 272 correct set of ASPAs. 274 While the ASPA provides a check of AS_PATH for routes received from 275 customers and peers, it doesn't provide full support for routes that 276 are received from upstream providers. So, this mechanism guarantees 277 detection of both malicious and accidental route leaks and provides 278 partial support for detection of malicious hijacks: upstream transit 279 ISPs will still be able to send hijacked prefixes with malformed 280 AS_PATHs to their customers. 282 9. Acknowledgments 284 The authors wish to thank authors of [RFC6483] since its text was 285 used as an example while writing this document. 287 10. References 289 10.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, . 296 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 297 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 298 May 2017, . 300 10.2. Informative References 302 [I-D.ietf-idr-bgp-open-policy] 303 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 304 Sriram, "Route Leak Prevention using Roles in Update and 305 Open messages", draft-ietf-idr-bgp-open-policy-02 (work in 306 progress), January 2018. 308 [I-D.ymbk-idr-bgp-eotr-policy] 309 Azimov, A., Bogomazov, E., Bush, R., and K. Patel, "Route 310 Leak Detection and Filtering using Roles in Update and 311 Open messages", draft-ymbk-idr-bgp-eotr-policy-02 (work in 312 progress), March 2018. 314 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 315 Addresses and AS Identifiers", RFC 3779, 316 DOI 10.17487/RFC3779, June 2004, . 319 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 320 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 321 DOI 10.17487/RFC4271, January 2006, . 324 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 325 Housley, R., and W. Polk, "Internet X.509 Public Key 326 Infrastructure Certificate and Certificate Revocation List 327 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 328 . 330 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 331 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 332 February 2012, . 334 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 335 Origination Using the Resource Certificate Public Key 336 Infrastructure (PKI) and Route Origin Authorizations 337 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 338 . 340 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 341 and B. Dickson, "Problem Definition and Classification of 342 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 343 2016, . 345 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 346 Specification", RFC 8205, DOI 10.17487/RFC8205, September 347 2017, . 349 Authors' Addresses 351 Alexander Azimov 352 Qrator Labs 354 Email: aa@qrator.net 356 Eugene Bogomazov 357 Qrator Labs 359 Email: eb@qrator.net 361 Randy Bush 362 Internet Initiative Japan 364 Email: randy@psg.com 366 Keyur Patel 367 Arrcus, Inc. 369 Email: keyur@arrcus.com 370 Job Snijders 371 NTT Communications 372 Theodorus Majofskistraat 100 373 Amsterdam 1065 SZ 374 The Netherlands 376 Email: job@ntt.net