idnits 2.17.1 draft-azimov-sidrops-aspa-verification-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 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 (October 22, 2018) is 1984 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 (-01) exists of draft-azimov-sidrops-aspa-profile-00 == Outdated reference: A later version (-24) exists of draft-ietf-idr-bgp-open-policy-02 == Outdated reference: A later version (-14) exists of draft-kumari-deprecate-as-set-confed-set-12 Summary: 1 error (**), 0 flaws (~~), 4 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: April 25, 2019 R. Bush 6 Internet Initiative Japan 7 K. Patel 8 Arrcus, Inc. 9 J. Snijders 10 NTT 11 October 22, 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-01 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 https://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 April 25, 2019. 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 (https://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. Anomaly Propagation . . . . . . . . . . . . . . . . . . . . . 3 68 3. Autonomous System Provider Authorization . . . . . . . . . . 4 69 4. Customer-Provider Verification Procedure . . . . . . . . . . 4 70 5. AS_PATH Verification . . . . . . . . . . . . . . . . . . . . 5 71 6. Disavowal of Provider Authorizaion . . . . . . . . . . . . . 6 72 7. Siblings (Complex Relations) . . . . . . . . . . . . . . . . 6 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 10.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 validation. Unfortunately, strict cryptographic validation brought 94 unaffordable computational overhead for BGP routers. BGPSec also 95 proved to be vulnerable to downgrade attacks that can nullify all the 96 work of AS_PATH signing. As a result, to abuse the AS_PATH or any 97 other signed transit attribute, an attacker merely needs to downgrade 98 to 'old' BGP-4. 100 An alternative approach was introduced with soBGP 101 [I-D.white-sobgp-architecture]. Instead of strong cryptographic 102 AS_PATH validation, it was suggested to create an AS_PATH security 103 function based on a shared database of ASN adjacencies. While such 104 an approach has reasonable computational cost, the two side 105 adjacencies don't provide a way to automate anomaly detection without 106 high adoption rate - an attacker can easily up a one-way adjacency. 107 SO-BGP suggested sharing data about adjacencies using additional BGP 108 messages, which is recursively complex thus significantly increasing 109 adoption complexity. In addition, the general goal to verify all 110 AS_PATHs was not achievable given the indirect adjacencies at 111 internet exchange points. 113 Instead of the general goal of checking AS_PATH correctness, this 114 document focuses on solving real-world operational problems - 115 automatic detection of malicious hijacks and route leaks. To achieve 116 this goal a new AS_PATH verification procedure is defined which is 117 able to automatically detect invalid (malformed) AS_PATHs in 118 announcements that are received from customers and peers. This 119 procedure uses a shared signed database of customer-to-provider 120 relationships that is built using a new RPKI object - Autonomous 121 System Provider Authorization (ASPA). This technique provides 122 benefits for the participants even in a state of early adoption. 124 2. Anomaly Propagation 126 Both route leaks and hijacks have similar effects on ISP operations - 127 they redirect traffic, resulting in increased latency, packet loss, 128 or possible MiTM attacks. But the level of risk depends 129 significantly on the propagation of these BGP anomalies. For 130 example, a hijack that is propagated only to customers may 131 concentrate traffic in a particular ISP's customer cone; while if the 132 anomaly is propagated through peers, upstreams, or reaches Tier-1 133 networks, thus distributing globally, traffic may be redirected at 134 the level of entire countries and/or global providers. 136 The ability to constrain propagation of BGP anomalies to upstreams 137 and peers, without requiring support from the source of the anomaly 138 (which is critical if source has malicious intent), should 139 significantly improve the security of inter-domain routing and solve 140 the majority of problems. 142 3. Autonomous System Provider Authorization 144 As described in [RFC6480], the RPKI is based on a hierarchy of 145 resource certificates that are aligned to the Internet Number 146 Resource allocation structure. Resource certificates are X.509 147 certificates that conform to the PKIX profile [RFC5280], and to the 148 extensions for IP addresses and AS identifiers [RFC3779]. A resource 149 certificate is a binding by an issuer of IP address blocks and 150 Autonomous System (AS) numbers to the subject of a certificate, 151 identified by the unique association of the subject's private key 152 with the public key contained in the resource certificate. The RPKI 153 is structured so that each current resource certificate matches a 154 current resource allocation or assignment. 156 ASPAs are digitally signed objects that bind a selected AFI Provider 157 AS number to a Customer AS number (in terms of BGP announcements not 158 business), and are signed by the holder of the Customer AS. An ASPA 159 attests that a Customer AS holder (CAS) has authorized a particular 160 Provider AS (PAS) to propagate the Customer's IPv4/IPv6 announcements 161 onward, e.g. to the Provider's upstream providers or peers. The ASPA 162 record profile is described in [I-D.azimov-sidrops-aspa-profile]. 164 4. Customer-Provider Verification Procedure 166 This section describes an abstract procedure that checks that pair of 167 ASNs (AS1, AS2) is included in the set of signed ASPAs. The 168 semantics of its usa are defined in next section. The procedure 169 takes (AS1, AS2, ROUTE_AFI) as input parameters and returns three 170 types of results: "valid", "invalid" and "unknown". 172 A relying party (RP) must have access to a local cache of the 173 complete set of cryptographically valid ASPAs when performing 174 customer-provider verification procedure. 176 1. Retrieve all cryptographically valid ASPAs in a selected AFI with 177 a customer value of AS1. This selection forms the set of 178 "candidate ASPAs." 180 2. If the set of candidate ASPAs is empty, then the procedure exits 181 with an outcome of "unknown." 183 3. If there is at least one candidate ASPA where the provider field 184 is AS2, then the procedure exits with an outcome of "valid." 186 4. Otherwise, the procedure exits with an outcome of "invalid." 188 Since an AS1 may have different set providers in different AFI, it 189 should also have different set of corresponding ASPAs. In this case, 190 the output of this procedure with input (AS1, AS2, ROUTE_AFI) may 191 have different output for different ROUTE_AFI values. 193 5. AS_PATH Verification 195 The AS_PATH attribute identifies the autonomous systems through which 196 an UPDATE message has passed. AS_PATH may contain two types of 197 components: ordered AS_SEQes and unordered AS_SETs, as defined in 198 [RFC4271]. 200 The value of each AS_SEQ component can be described as set of pairs 201 {(AS(I), prepend(I)), (AS(I-1), prepend(I-1))...}. In this case, the 202 sequence {AS(I), AS(I-1),...} represents different ASNs, that packet 203 should pass towards the destination. When a route is received from a 204 customer or a literal peer, each pair (AS(I-1), AS(I)) MUST belong to 205 customer-provider or sibling relationship. If there are other types 206 of relationships, it means that the route was leaked or the AS_PATH 207 attribute was malformed. The goal of the above procedure is to check 208 the correctness of this statement. 210 For 32-bit AS number compatible BGP speakers, if a route from 211 ROUTE_AFI address family is received from a customer or peer, its 212 AS_PATH MUST be verified as follows: 214 1. If the closest AS in the AS_PATH is not the receiver's neighbor 215 ASN then procedure halts with the outcome "invalid"; 217 2. If in one of AS_SEQ segments there is a pair (AS(I-1), AS(I)), 218 and customer-provider verification procedure (Section 4) with 219 parameters (AS(I-1), AS(I), ROUTE_AFI) returns "invalid" then the 220 procedure also halts with the outcome "invalid"; 222 3. If the AS_PATH has at least one AS_SET segment then procedure 223 halts with the outcome "unverifiable"; 225 4. Otherwise, the procedure halts with an outcome of "valid". 227 For BGP speakers that are not 32-bit AS compatible, the above 228 procedure is slightly different. In point 2 if at least one AS(I-1), 229 AS(I) is equal to AS_TRANS(23456), the corresponding pair must be 230 passed without check using the customer-provider verification 231 procedure. 233 If the output of the AS_PATH verification procedure is "invalid" the 234 LOCAL_PREF SHOULD be set to 0 or the route MAY be dropped. If an 235 "invalid" route has no alternative route(s) and it is propagated to 236 other ASes despite the above, it MUST be marked with the 237 GRACEFUL_SHUTDOWN community to avoid possible stable oscillations, 238 when an unchecked route received from a provider becomes preferred 239 over an invalid route received from a customer. This also allows 240 customers to detect malformed routes received from upstream 241 providers. 243 If the output of the AS_PATH verification procedure is 'unverifiable' 244 it means that AS_PATH can't be fully verified. Such routes should be 245 treated with caution and SHOULD be processed the same way as 246 "invalid" routes. This policy goes with full correspondence to 247 [I-D.kumari-deprecate-as-set-confed-set]. 249 The above AS_PATH verification procedure is able to check routes 250 received from customers and peers. The ASPA mechanism combined with 251 BGP Roles [I-D.ietf-idr-bgp-open-policy] and ROA-based Origin 252 Validation [RFC6483] provide a fully automated solution to detect and 253 filter hijacks and route leaks, including malicious ones. 255 6. Disavowal of Provider Authorizaion 257 An ASPA is a positive attestation that an AS holder has authorized 258 its provider to redistribute received routes to the provider's 259 providers and peers. This does not preclude the provider AS from 260 redistribution to its other customers. By creating an ASPA where the 261 provider AS is 0, the customer indicates that no provider should 262 further announce its routes. Specifically, AS 0 is reserved to 263 identify provider-free networks, Internet exchange meshes, etc. 265 An ASPA with a provider AS of 0 is a statement by the customer AS 266 that the its routes should not be received by any relying party AS 267 from any of its customers or peers. 269 By convention, an ASPA with a provider AS of 0 should be the only 270 ASPA issued by a given AS holder; although this is not a strict 271 requirement. A provider 0 ASPA may coexist with ASPAs that have 272 different provider AS values; though in such cases, the presence or 273 absence of the provider AS 0 ASPA does not alter the AS_PATH 274 verification procedure. 276 7. Siblings (Complex Relations) 278 There are peering relationships which can not be described as 279 strictly simple peer-peer or customer-provider; e.g. when both 280 parties are intentionally sending prefixes received from each other 281 to their peers and/or upstreams. 283 In this case, two symmetric ASPAs records {(AS1, AS2), (AS2, AS1)} 284 must be created by AS1 and AS2 respectively. 286 8. Security Considerations 288 ASPA issuers should be aware of the verification implication in 289 issuing an ASPA - an ASPA implicitly invalidates all routes passed to 290 upstream providers other than the provider ASs listed in the 291 collection of ASPAs. It is the Customer AS's duty to maintain a 292 correct set of ASPAs. 294 While the ASPA provides a check of an AS_PATH for routes received 295 from customers and peers, it doesn't provide full support for routes 296 that are received from upstream providers. So, this mechanism 297 guarantees detection of both malicious and accidental route leaks and 298 provides partial support for detection of malicious hijacks: upstream 299 transit ISPs will still be able to send hijacked prefixes with 300 malformed AS_PATHs to their customers. 302 9. Acknowledgments 304 The authors wish to thank authors of [RFC6483] since its text was 305 used as an example while writing this document. 307 10. References 309 10.1. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 317 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 318 May 2017, . 320 10.2. Informative References 322 [I-D.azimov-sidrops-aspa-profile] 323 Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., 324 and R. Housley, "A Profile for Autonomous System Provider 325 Authorization", draft-azimov-sidrops-aspa-profile-00 (work 326 in progress), June 2018. 328 [I-D.ietf-idr-bgp-open-policy] 329 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. 330 Sriram, "Route Leak Prevention using Roles in Update and 331 Open messages", draft-ietf-idr-bgp-open-policy-02 (work in 332 progress), January 2018. 334 [I-D.kumari-deprecate-as-set-confed-set] 335 Kumari, W. and K. Sriram, "Deprecation of AS_SET and 336 AS_CONFED_SET in BGP", draft-kumari-deprecate-as-set- 337 confed-set-12 (work in progress), July 2018. 339 [I-D.white-sobgp-architecture] 340 White, R., "Architecture and Deployment Considerations for 341 Secure Origin BGP (soBGP)", draft-white-sobgp- 342 architecture-02 (work in progress), June 2006. 344 [I-D.ymbk-idr-bgp-eotr-policy] 345 Azimov, A., Bogomazov, E., Bush, R., and K. Patel, "Route 346 Leak Detection and Filtering using Roles in Update and 347 Open messages", draft-ymbk-idr-bgp-eotr-policy-02 (work in 348 progress), March 2018. 350 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 351 Addresses and AS Identifiers", RFC 3779, 352 DOI 10.17487/RFC3779, June 2004, 353 . 355 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 356 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 357 DOI 10.17487/RFC4271, January 2006, 358 . 360 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 361 Housley, R., and W. Polk, "Internet X.509 Public Key 362 Infrastructure Certificate and Certificate Revocation List 363 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 364 . 366 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 367 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 368 February 2012, . 370 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 371 Origination Using the Resource Certificate Public Key 372 Infrastructure (PKI) and Route Origin Authorizations 373 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 374 . 376 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 377 and B. Dickson, "Problem Definition and Classification of 378 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 379 2016, . 381 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 382 Specification", RFC 8205, DOI 10.17487/RFC8205, September 383 2017, . 385 Authors' Addresses 387 Alexander Azimov 388 Qrator Labs 390 Email: aa@qrator.net 392 Eugene Bogomazov 393 Qrator Labs 395 Email: eb@qrator.net 397 Randy Bush 398 Internet Initiative Japan 400 Email: randy@psg.com 402 Keyur Patel 403 Arrcus, Inc. 405 Email: keyur@arrcus.com 407 Job Snijders 408 NTT Communications 409 Theodorus Majofskistraat 100 410 Amsterdam 1065 SZ 411 The Netherlands 413 Email: job@ntt.net