idnits 2.17.1 draft-shen-sidrops-regionalized-as-relationships-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 7, 2022) is 781 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) == Missing Reference: 'AS1 AS2' is mentioned on line 222, but not defined == Unused Reference: 'RFC7908' is defined on line 266, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7908 == Outdated reference: A later version (-17) exists of draft-ietf-sidrops-aspa-verification-08 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 C. Shen 3 Internet-Draft CAICT 4 Intended status: Standards Track S. Zhang 5 Expires: September 8, 2022 NNIX 6 Z. Li 7 S. Zhuang 8 S. Chen 9 H. Wang 10 Huawei 11 March 7, 2022 13 ASPA Verification in the Presence of Regionalized AS-Relationships 14 draft-shen-sidrops-regionalized-as-relationships-00 16 Abstract 18 This document proposes a method for ASPA verification in the Presence 19 of Regionalized AS-Relationships. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 8, 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4 63 3. Regionalized AS-Relationships . . . . . . . . . . . . . . . . 5 64 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 9.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 [RFC6811] defines a method for verifying the origin of BGP prefixes, 77 which can resolve the most common source AS hijacking. Autonomous 78 system provider authorisation (ASPA) 79 [I-D.ietf-sidrops-aspa-verification] is a methodology to validate the 80 entire AS path. ASPA verification procedures use a shared signed 81 database of customer-to-provider relationships using a new RPKI 82 object - Autonomous System Provider Authorization (ASPA). This 83 method relies heavily on the accuracy of the shared signed database 84 of customer-to-provider relationships. 86 Currently, two ASes may have different relationships at different 87 interconnection points. For example: 89 Europe 90 +----------------+ 91 /Customer Provider \ 92 / \ 93 AS1--+ +--AS2 94 \ / 95 \ Peer Peer/ 96 +----------------+ 97 Asia 99 Figure 1: Hybrid Relationship Case 1 101 Case 1) AS1 is AS2's customer in Europe, but AS1 and AS2 establish 102 P2P relationships in Asia; 104 Europe 105 +----------------+ 106 /Customer Provider \ 107 / \ 108 AS3--+ +--AS4 109 \ / 110 \ Provider Customer/ 111 +----------------+ 112 Asia 114 Figure 2: Hybrid Relationship Case 2 116 Case 2) AS3 is AS4's customer in Europe, on the contrary, AS4 is 117 AS3's customer in Asia; 119 There are some other examples, not fully listed in this draft. 121 For case 1, AS1 signs one record ASPA(AS1, AFI, [AS2, ...]) per 122 [I-D.ietf-sidrops-aspa-verification]. 124 Europe 125 +----------------+ 126 /Customer Provider \ 127 Route P1 / \ 128 Origin AS11 .. AS1--+ +--AS2-- ... Check Point 129 ---> \ / ----> 130 \ Peer Peer/ 131 +---------------+ 132 Asia 133 ----> 135 Figure 3: Problematic Use Case 137 As shown in Figure 3, the main processing steps per 138 [I-D.ietf-sidrops-aspa-verification] are as follows: 140 1) Check Point receives the Route P1, AS-Path: AS2 (via Asia Link) 141 AS1 ... AS11; 143 2) Check Point uses ASPA(AS1, AFI, [AS2, ...]) to validate AS-Pair 144 (AS1 AS2) Per the AS_PATH verification procedure defined in 145 [I-D.ietf-sidrops-aspa-verification], it will return the result 146 "Valid". 148 Actually here should return the result "Invalid", not the result 149 "Valid", because the AS-Relationship between AS1 and AS2 in Asia is 150 P2P, not C2P. 152 This problem arises because of the existence of regionalized AS- 153 Relationships. This document proposes a method for ASPA verification 154 in the Presence of Regionalized AS-Relationships. 156 2. Definitions and Acronyms 158 o ASPA: Autonomous system provider authorisation 160 o C2P: Customer to Provider 162 o OV: Origin Validation 164 o P2C: Provider to Customer 166 o P2P: Peer to Peer 168 o RP: Relying Party 170 o RPKI: Resource Public Key Infrastructure 172 3. Regionalized AS-Relationships 174 This section discusses how to obtain regionalized AS-Relationships on 175 routers. 177 Option 1: Add a Region ID field to ASPA Object 179 Each organization holds an AS number reports its C2P business 180 relationship information to the RIR where it is located. The key 181 information reported: the customer's AS number, the customer's 182 provider AS number list (one or more), the region identifier, the 183 region identifier is newly added by the present draft, and identifies 184 the customer's business relationship with the one or more of its 185 Providers in the same region is C2P. Each RIR maintains C2P business 186 relationship information like maintaining ROA related information, 187 when the region identifier is empty, it indicates that the business 188 relationship between the Customer and the one or more of its 189 Providers in all regions is C2P. 191 RP (Relying Party) obtains all the C2P business relationship 192 information from each RIR, and generates the ASPA Validation Database 193 entries. 195 RFC8210[RFC8210] RPKI-Router Protocol extension supports the ability 196 to carry region identifier when delivering the ASPA Validation 197 Database to routers, and delivers the enhanced ASPA Validation 198 Database from RP to routers. 200 Option 2: Local Management of the enhanced C2P business relationships 202 Locally, by analyzing the global Internet routing table and various 203 Internet public data, a regionalized C2P business relational database 204 is sorted out. 206 Option 3: TBD 208 By processing as above, AS1 signs one record ASPA(AS1, AFI, [AS2, 209 ...], Europe). 211 4. Operations 213 Once we get the Regionalized AS-Relationships, the main processing 214 steps in section 1 (Figure 3) will be changed as follows: 216 1) Check Point receives the Route P1, AS-Path: AS2 (via Asia Link) 217 AS1 ... AS11; 218 2) Check Point uses ASPA(AS1, AFI, [AS2, ...], Europe) to validate 219 AS-Pair (AS1 AS2) Per the AS_PATH verification procedure 220 [I-D.ietf-sidrops-aspa-verification], because the ASPA record 221 contains region identifier information, further confirm which region 222 the [AS1 AS2] connection is in (we can use various tools such as 223 TraceRoute etc. This needs to be described in detail in next 224 revision.), if we get the region identifier information of the latter 225 is different from the ASPA records (In current case, what we get is 226 Asia, not Europe), then the ASPA verification will return the result 227 "Invalid". 229 From the above processing results, we can see that the solution 230 proposed in this draft has worked and solved the problem described in 231 the second section. 233 5. IANA Considerations 235 No IANA actions are required for this document. 237 6. Security Considerations 239 This document does not change the security properties of RPKI and 240 ASPA. 242 7. Contributors 244 The following people made significant contributions to this document: 246 TBD 248 8. Acknowledgements 250 TBD. 252 9. References 254 9.1. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, 258 DOI 10.17487/RFC2119, March 1997, 259 . 261 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 262 Austein, "BGP Prefix Origin Validation", RFC 6811, 263 DOI 10.17487/RFC6811, January 2013, 264 . 266 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 267 and B. Dickson, "Problem Definition and Classification of 268 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 269 2016, . 271 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 272 Infrastructure (RPKI) to Router Protocol, Version 1", 273 RFC 8210, DOI 10.17487/RFC8210, September 2017, 274 . 276 9.2. Informative References 278 [I-D.ietf-sidrops-aspa-verification] 279 Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. 280 Snijders, "Verification of AS_PATH Using the Resource 281 Certificate Public Key Infrastructure and Autonomous 282 System Provider Authorization", draft-ietf-sidrops-aspa- 283 verification-08 (work in progress), August 2021. 285 Authors' Addresses 287 Chen Shen 288 CAICT 289 No.52, Hua Yuan Bei Road 290 Beijing 100191 291 China 293 Email: shenchen@caict.ac.cn 295 Shicong Zhang 296 NNIX 297 No. 198, Qidi Road, Xiaoshan District 298 Hangzhou 311200 299 China 301 Email: zsc@nnix.cn 303 Zhenbin Li 304 Huawei 305 156 Beiqing Road 306 Beijing 100095 307 China 309 Email: lizhenbin@huawei.com 310 Shunwan Zhuang 311 Huawei 312 156 Beiqing Road 313 Beijing 100095 314 China 316 Email: zhuangshunwan@huawei.com 318 Shuanglong Chen 319 Huawei 320 156 Beiqing Road 321 Beijing 100095 322 China 324 Email: chenshuanglong@huawei.com 326 Haibo Wang 327 Huawei 328 156 Beiqing Road 329 Beijing 100095 330 China 332 Email: rainsword.wang@huawei.com