idnits 2.17.1 draft-ietf-sidrops-aspa-verification-05.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 (September 10, 2020) is 1296 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 (-10) exists of draft-ietf-grow-route-leak-detection-mitigation-00 == Outdated reference: A later version (-24) exists of draft-ietf-idr-bgp-open-policy-05 == Outdated reference: A later version (-17) exists of draft-ietf-sidrops-aspa-profile-00 == Outdated reference: A later version (-14) exists of draft-kumari-deprecate-as-set-confed-set-12 Summary: 1 error (**), 0 flaws (~~), 5 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 Yandex 4 Intended status: Standards Track E. Bogomazov 5 Expires: March 14, 2021 Qrator Labs 6 R. Bush 7 Internet Initiative Japan & Arrcus 8 K. Patel 9 Arrcus, Inc. 10 J. Snijders 11 NTT 12 September 10, 2020 14 Verification of AS_PATH Using the Resource Certificate Public Key 15 Infrastructure and Autonomous System Provider Authorization 16 draft-ietf-sidrops-aspa-verification-05 18 Abstract 20 This document defines the semantics of an Autonomous System Provider 21 Authorization object in the Resource Public Key Infrastructure to 22 verify the AS_PATH attribute of routes advertised in the Border 23 Gateway Protocol. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in BCP 30 14 [RFC2119] [RFC8174] when, and only when, they appear in all 31 capitals, as shown here. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 14, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Anomaly Propagation . . . . . . . . . . . . . . . . . . . . . 3 69 3. Autonomous System Provider Authorization . . . . . . . . . . 4 70 4. Customer-Provider Verification Procedure . . . . . . . . . . 4 71 5. AS_PATH Verification . . . . . . . . . . . . . . . . . . . . 5 72 5.1. Upstream Paths . . . . . . . . . . . . . . . . . . . . . 5 73 5.2. Downstream Paths . . . . . . . . . . . . . . . . . . . . 6 74 5.3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. Disavowal of Provider Authorizaion . . . . . . . . . . . . . 8 76 7. Siblings (Complex Relations) . . . . . . . . . . . . . . . . 9 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 10.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 The Border Gateway Protocol (BGP) was designed without mechanisms to 87 validate BGP attributes. Two consequences are BGP Hijacks and BGP 88 Route Leaks [RFC7908]. BGP extensions are able to partially solve 89 these problems. For example, ROA-based Origin Validation [RFC6483] 90 can be used to detect and filter accidental mis-originations, and 91 [I-D.ietf-grow-route-leak-detection-mitigation] can be used to detect 92 accidental route leaks. While these upgrades to BGP are quite 93 useful, they still rely on transitive BGP attributes, i.e. AS_PATH, 94 that can be manipulated by attackers. 96 BGPSec [RFC8205] was designed to solve the problem of AS_PATH 97 validation. Unfortunately, strict cryptographic validation brought 98 expensive computational overhead for BGP routers. BGPSec also proved 99 vulnerable to downgrade attacks that nullify the benefits of AS_PATH 100 signing. As a result, to abuse the AS_PATH or any other signed 101 transit attribute, an attacker merely needs to downgrade to 'old' 102 BGP-4. 104 An alternative approach was introduced with soBGP 105 [I-D.white-sobgp-architecture]. Instead of strong cryptographic 106 AS_PATH validation, it created an AS_PATH security function based on 107 a shared database of ASN adjacencies. While such an approach has 108 reasonable computational cost, the two side adjacencies don't provide 109 a way to automate anomaly detection without high adoption rate - an 110 attacker can easily create a one-way adjacency. SO-BGP transported 111 data about adjacencies in new additional BGP messages, which was 112 recursively complex thus significantly increasing adoption complexity 113 and risk. In addition, the general goal to verify all AS_PATHs was 114 not achievable given the indirect adjacencies at internet exchange 115 points. 117 Instead of checking AS_PATH correctness, this document focuses on 118 solving real-world operational problems - automatic detection of 119 malicious hijacks and route leaks. To achieve this a new AS_PATH 120 verification procedure is defined which is able to automatically 121 detect invalid (malformed) AS_PATHs in announcements that are 122 received from customers and peers. This procedure uses a shared 123 signed database of customer-to-provider relationships using a new 124 RPKI object - Autonomous System Provider Authorization (ASPA). This 125 technique provides benefits for participants even during early and 126 incremental adoption. 128 2. Anomaly Propagation 130 Both route leaks and hijacks have similar effects on ISP operations - 131 they redirect traffic, resulting in increased latency, packet loss, 132 or possible MiTM attacks. But the level of risk depends 133 significantly on the propagation of the anomalies. For example, a 134 hijack that is propagated only to customers may concentrate traffic 135 in a particular ISP's customer cone; while if the anomaly is 136 propagated through peers, upstreams, or reaches Tier-1 networks, thus 137 distributing globally, traffic may be redirected at the level of 138 entire countries and/or global providers. 140 The ability to constrain propagation of BGP anomalies to upstreams 141 and peers, without requiring support from the source of the anomaly 142 (which is critical if source has malicious intent), should 143 significantly improve the security of inter-domain routing and solve 144 the majority of problems. 146 3. Autonomous System Provider Authorization 148 As described in [RFC6480], the RPKI is based on a hierarchy of 149 resource certificates that are aligned to the Internet Number 150 Resource allocation structure. Resource certificates are X.509 151 certificates that conform to the PKIX profile [RFC5280], and to the 152 extensions for IP addresses and AS identifiers [RFC3779]. A resource 153 certificate is a binding by an issuer of IP address blocks and 154 Autonomous System (AS) numbers to the subject of a certificate, 155 identified by the unique association of the subject's private key 156 with the public key contained in the resource certificate. The RPKI 157 is structured so that each current resource certificate matches a 158 current resource allocation or assignment. 160 ASPA is digitally signed object that bind, for a selected AFI, a Set 161 of Provider AS numbers to a Customer AS number (in terms of BGP 162 announcements not business), and are signed by the holder of the 163 Customer AS. An ASPA attests that a Customer AS holder (CAS) has 164 authorized Set of Provider ASes (SPAS) to propagate the Customer's 165 IPv4/IPv6 announcements onward, e.g. to the Provider's upstream 166 providers or peers. The ASPA record profile is described in 167 [I-D.ietf-sidrops-aspa-profile]. For a selected Customer AS MAY 168 exist only single ASPA object. 170 4. Customer-Provider Verification Procedure 172 This section describes an abstract procedure that checks that a pair 173 of ASNs (AS1, AS2) is included in the set of signed ASPAs. The 174 semantics of its use is defined in next section. The procedure takes 175 (AS1, AS2, ROUTE_AFI) as input parameters and returns one of three 176 results: "valid", "invalid" and "unknown". 178 A relying party (RP) must have access to a local cache of the 179 complete set of cryptographically valid ASPAs when performing 180 customer-provider verification procedure. 182 1. Retrieve cryptographically valid ASPA in a selected AFI with a 183 customer value of AS1. If there is no valid ASPA record for AS1 184 the procedure exits with an outcome of "unknown." 186 2. If AS2 is included in the SPAS, then the procedure exits with an 187 outcome of "valid." 189 3. Otherwise, the procedure exits with an outcome of "invalid." 191 Since an AS1 may have different set providers in different AFI, it 192 should also have different PCAS in corresponding ASPAs. In this 193 case, the output of this procedure with input (AS1, AS2, ROUTE_AFI) 194 may have different output for different ROUTE_AFI values. 196 5. AS_PATH Verification 198 The AS_PATH attribute identifies the autonomous systems through which 199 an UPDATE message has passed. AS_PATH may contain two types of 200 components: ordered AS_SEQes and unordered AS_SETs, as defined in 201 [RFC4271]. 203 The value of each concatenated value of AS_SEQ components can be 204 described as set of pairs {(AS(I), prepend(I)), (AS(I-1), 205 prepend(I-1))...}, where AS(0) stands for originating AS. In this 206 case, the sequence {AS(I), AS(I-1),...} represents different ASNs, 207 that packet should pass towards the destination. 209 The bellow procedure is applicable only for 32-bit AS number 210 compatible BGP speakers. 212 5.1. Upstream Paths 214 When a route is received from a customer, a literal peer, or by a RS 215 at an IX, each pair (AS(I-1), AS(I)) MUST belong to customer-provider 216 or sibling relationship. If there are other types of relationships, 217 it means that the route was leaked or the AS_PATH attribute was 218 malformed. The goal of the procedure described bellow is to check 219 the correctness of this statement. 221 The following diagram and procedure describes the procedure that MUST 222 be applied on routes with ROUTE_AFI received from a customer, peer or 223 RS-client: 225 (AS(I-1),AS(I))=Valid 226 +-----+ 227 | I++ | 228 v | 229 +-+-----+-+ 230 | | (AS(I-1),AS(I))=Invalid 231 | Valid +----------------------------+ 232 | | | 233 +----+----+ | 234 | +----v----+ 235 | | | 236 I++|(AS(I-1),AS(I))=Unknown | Invalid | 237 | | | 238 | +----+----+ 239 +----v----+ ^ 240 | | | 241 | Unknown +----------------------------+ 242 | | (AS(I-1),(AS(I))=Invalid 243 +-+-----+-+ 244 ^ | 245 | I++ | 246 +-----+ 247 (AS(I-1),AS(I))!=Invalid 249 1. If the closest AS in the AS_PATH is not the receiver's neighbor 250 ASN then procedure halts with the outcome "invalid"; 252 2. If there is a pair (AS(I-1), AS(I)), and customer-provider 253 verification procedure (Section 4) with parameters (AS(I-1), 254 AS(I), ROUTE_AFI) returns "invalid" then the procedure also halts 255 with the outcome "invalid"; 257 3. If the AS_PATH has at least one AS_SET segment then procedure 258 halts with the outcome "unverifiable"; 260 4. If there is a pair (AS(I-1), AS(I)), and customer-provider 261 verification procedure (Section 4) with parameters (AS(I-1), 262 AS(I), ROUTE_AFI) returns "unknown" then the procedure also halts 263 with the outcome "unknown"; 265 5. Otherwise, the procedure halts with an outcome of "valid". 267 5.2. Downstream Paths 269 When route is received from provider or RS it may have both Upstream 270 and Downstream paths, where a Downstream follows an Upstream path. 271 If the path differs from this rule, e.g. the Downstream path is 272 followed by Upstream path it means that the route was leaked or the 273 AS_PATH attribute was malformed. The first pair (AS(I-1), AS(I)) 274 that has an "invalid" outcome of the customer-provider verification 275 procedure indicates the end of the Upstream path. All subsequent 276 reverse pairs (AS(I), AS(I-1)) MUST belong to a customer-provider or 277 sibling relationship, thus can be also verified using ASPA objects. 279 Additional caution should be exercised when processing prefixes that 280 are received from transparent IXes, as they don't add their ASN in 281 the ASPATH. 283 The following diagram and procedure describe the procedure that MUST 284 be applied on routes with ROUTE_AFI received from a provider or a RS: 286 (AS(I-1),AS(I))=Valid (AS(I),AS(I-1))=Valid 287 +-----+ +-----+ 288 | I++ | | I++ | 289 v | v | 290 +-+-----+-+ +-+-----+-+ 291 | |(AS(I-1),AS(I))=Invalid| |(AS(I),AS(I-1))=Invalid 292 | Valid +-----------------------> Valid +---------+ 293 | | I++ | | | 294 +----+----+ +----+----+ | 295 | | +---v-----+ 296 I++|(AS(I-1),AS(I))=Unknown | | | 297 | | | Invalid | 298 | (AS(I-1),AS(I)=Unknown|I++ | | 299 | | +---+-----+ 300 +----v----+ +----v----+ ^ 301 | | I++ | | | 302 | Unknown +-----------------------> Unknown +---------+ 303 | |(AS(I-1),AS(I))=Invalid| |(AS(I),AS(I-1))=Invalid 304 +-+-----+-+ +-+-----+-+ 305 ^ | ^ | 306 | I++ | | I++ | 307 +-----+ +-----+ 308 (AS(I-1),AS(I))!=Invalid (AS(I),AS(I-1))!=Invalid 310 1. If a route is received from a provider and the closest AS in the 311 AS_PATH is not the receiver's neighbor ASN, then the procedure 312 halts with the outcome "invalid"; 314 2. If there are two pairs (AS(I-1), AS(I)), (AS(J-1), AS(J)) with J 315 > I, and the customer-provider verification procedure (Section 4) 316 returns "invalid" for both (AS(I-1), AS(I), ROUTE_AFI) and 317 (AS(J), AS(J-1), ROUTE_AFI), then the procedure also halts with 318 the outcome "invalid"; 320 3. If the AS_PATH has at least one AS_SET segment then procedure 321 halts with the outcome "unverifiable"; 323 4. If there are two pairs (AS(I-1), AS(I)), (AS(J-1), AS(J)) with J 324 > I, and the customer-provider verification procedure (Section 4) 325 returns "invalid" for (AS(I-1), AS(I), ROUTE_AFI) and "unknown" 326 for (AS(J), AS(J-1), ROUTE_AFI), then the procedure also halts 327 with the outcome "unknown"; 329 5. If the customer-provider verification procedure (Section 4) 330 doesn't return "invalid" for any (AS(I-1), AS(I)), but at least 331 for one (AS(I-1), AS(I)) returns "unknown", then the procedure 332 also halts with the outcome "unknown"; 334 6. Otherwise, the procedure halts with an outcome of "valid". 336 5.3. Mitigation 338 If the output of the AS_PATH verification procedure is "invalid" the 339 route MUST be rejected. 341 If the output of the AS_PATH verification procedure is 'unverifiable' 342 it means that AS_PATH can't be fully checked. Such routes should be 343 treated with caution and SHOULD be processed the same way as 344 "invalid" routes. This policy goes with full correspondence to 345 [I-D.kumari-deprecate-as-set-confed-set]. 347 The above AS_PATH verification procedure is able to check routes 348 received from customers and peers. The ASPA mechanism combined with 349 BGP Roles [I-D.ietf-idr-bgp-open-policy] and ROA-based Origin 350 Validation [RFC6483] provide a fully automated solution to detect and 351 filter hijacks and route leaks, including malicious ones. 353 6. Disavowal of Provider Authorizaion 355 An ASPA is a positive attestation that an AS holder has authorized 356 its providers to redistribute received routes to the provider's 357 providers and peers. This does not preclude the provider ASes from 358 redistribution to its other customers. By creating an ASPA with 359 providers set of {0}, the customer indicates that no provider should 360 further announce its routes. Specifically, AS 0 is reserved to 361 identify provider-free networks, Internet exchange meshes, etc. 363 An ASPA with a providers set of {0} is a statement by the customer AS 364 that its routes should not be received by any relying party AS from 365 any of its customers or peers. 367 By convention, an ASPA with a provider set of {0} should be the only 368 ASPA issued by a given AS holder; although this is not a strict 369 requirement. A provider AS 0 may coexist with other provider ASes in 370 the same ASPA (or other ASPA records); though in such cases, the 371 presence or absence of the provider AS 0 in ASPA does not alter the 372 AS_PATH verification procedure. 374 7. Siblings (Complex Relations) 376 There are peering relationships which can not be described as 377 strictly simple peer-peer or customer-provider; e.g. when both 378 parties are intentionally sending prefixes received from each other 379 to their peers and/or upstreams. 381 In this case, two corresponding ASPA records (AS1, {AS2, ...}), (AS2, 382 {AS1, ...}) must be created by AS1 and AS2 respectively. 384 8. Security Considerations 386 The proposed mechanism is compatible only with BGP implementations 387 that can process 32-bit ASNs in the ASPATH. This limitation should 388 not have a real effect on operations - such legacy BGP routers a rare 389 and it's highly unlikely that they support integration with the RPKI. 391 ASPA issuers should be aware of the verification implication in 392 issuing an ASPA - an ASPA implicitly invalidates all routes passed to 393 upstream providers other than the provider ASs listed in the ASPA 394 record. It is the Customer AS's duty to maintain a correct set of 395 providers in ASPA record(s). 397 While it's not restricted, but it's highly recommended maintaining 398 for selected Customer AS a single ASPA object that covers all its 399 providers. Such policy should prevent race conditions during ASPA 400 updates that might affect prefix propagation. 402 While the ASPA is able to detect both mistakes and malicious activity 403 for routes received from customers, RS-clients, or peers, it provides 404 only detection of mistakes for routes that are received from upstream 405 providers and RS(s). 407 Since an upstream provider becomes a trusted point, it will be able 408 to send hijacked prefixes of its customers or send hijacked prefixes 409 with malformed AS_PATHs back. While it may happen in theory, it's 410 doesn't seem to be a real scenario: normally customer and provider 411 have a signed agreement and such policy violation should have legal 412 consequences or customer can just drop relation with such a provider 413 and remove the corresponding ASPA record. 415 9. Acknowledgments 417 The authors wish to thank authors of [RFC6483] since its text was 418 used as an example while writing this document. The also authors 419 wish to thank Iljitsch van Beijnum for giving a hint about Downstream 420 paths. 422 10. References 424 10.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 432 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 433 May 2017, . 435 10.2. Informative References 437 [I-D.ietf-grow-route-leak-detection-mitigation] 438 Sriram, K. and A. Azimov, "Methods for Detection and 439 Mitigation of BGP Route Leaks", draft-ietf-grow-route- 440 leak-detection-mitigation-00 (work in progress), April 441 2019. 443 [I-D.ietf-idr-bgp-open-policy] 444 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 445 Sriram, "Route Leak Prevention using Roles in Update and 446 Open messages", draft-ietf-idr-bgp-open-policy-05 (work in 447 progress), February 2019. 449 [I-D.ietf-sidrops-aspa-profile] 450 Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., 451 and R. Housley, "A Profile for Autonomous System Provider 452 Authorization", draft-ietf-sidrops-aspa-profile-00 (work 453 in progress), May 2019. 455 [I-D.kumari-deprecate-as-set-confed-set] 456 Kumari, W. and K. Sriram, "Deprecation of AS_SET and 457 AS_CONFED_SET in BGP", draft-kumari-deprecate-as-set- 458 confed-set-12 (work in progress), July 2018. 460 [I-D.white-sobgp-architecture] 461 White, R., "Architecture and Deployment Considerations for 462 Secure Origin BGP (soBGP)", draft-white-sobgp- 463 architecture-02 (work in progress), June 2006. 465 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 466 Addresses and AS Identifiers", RFC 3779, 467 DOI 10.17487/RFC3779, June 2004, 468 . 470 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 471 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 472 DOI 10.17487/RFC4271, January 2006, 473 . 475 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 476 Housley, R., and W. Polk, "Internet X.509 Public Key 477 Infrastructure Certificate and Certificate Revocation List 478 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 479 . 481 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 482 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 483 February 2012, . 485 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 486 Origination Using the Resource Certificate Public Key 487 Infrastructure (PKI) and Route Origin Authorizations 488 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 489 . 491 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 492 and B. Dickson, "Problem Definition and Classification of 493 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 494 2016, . 496 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 497 Specification", RFC 8205, DOI 10.17487/RFC8205, September 498 2017, . 500 Authors' Addresses 502 Alexander Azimov 503 Yandex 505 Email: a.e.azimov@gmail.com 506 Eugene Bogomazov 507 Qrator Labs 509 Email: eb@qrator.net 511 Randy Bush 512 Internet Initiative Japan & Arrcus 514 Email: randy@psg.com 516 Keyur Patel 517 Arrcus, Inc. 519 Email: keyur@arrcus.com 521 Job Snijders 522 NTT Communications 523 Theodorus Majofskistraat 100 524 Amsterdam 1065 SZ 525 The Netherlands 527 Email: job@ntt.net