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