idnits 2.17.1 draft-van-beijnum-sidrops-pathrpki-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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC8210, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3779, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 134 has weird spacing: '... Number n ...' == Line 182 has weird spacing: '... Number n ...' (Using the creation date from RFC3779, updated by this document, for RFC5378 checks: 2002-02-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 20, 2019) is 1766 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 388 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR Operations I. van Beijnum 3 Internet-Draft BGPexpert.com 4 Updates: RFC 3779, RFC 8210 (if June 20, 2019 5 approved) 6 Intended status: Experimental 7 Expires: December 22, 2019 9 Path validation with RPKI 10 draft-van-beijnum-sidrops-pathrpki-00 12 Abstract 14 This memo adds the capability to validate the full BGP AS path to the 15 RPKI mechanism. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 22, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 With RPKI, it's possible for BGP routers to validate the origin AS 52 found in the BGP AS path attribute for a given IP prefix. However, 53 RPKI can't validat the rest of the AS path, allowing for route leaks 54 types 1 - 4 as described in RFC 7908 [RFC7908]. 56 This specification extends RPKI to allow for validating the full BGP 57 AS path, based on the observation that each AS in a valid AS path has 58 either a trust relation with the origin AS or has a trust relation 59 with the local AS (the AS performing validation). I.e., each 60 intermediary AS provides transit service to either the origin AS or 61 the local AS. 63 An extension to RFC 3779 [RFC3779] allows for binding a list of 64 allowed transit ASes to a set of IP addresses. Operators of RPKI 65 [RFC6480] relying party software add to this their list of locally 66 allowed transit ASes through manual configuration. An update to the 67 RPKI-router protocol [RFC8210] lets relying party software propagate 68 the thus created list of allowed ASes for the prefix(es) in question 69 so BGP routers can validate the corresponding AS paths. 71 1.1. Requirements Language 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 2. Changes to the ROA certificate format 79 RFC 3779 [RFC3779] specifies an extension to X.509 certificates that 80 contains a set of AS numbers: id-pe-autonomousSysIds. This is the 81 set of valid origin ASes for a given set of IP addresses. 83 This memo adds another extension to X.509 certificates with the name 84 id-pe-autonomousSysIdsPath. id-pe-autonomousSysIdsPath is identical 85 in syntax to the existing id-pe-autonomousSysIds, allowing for code 86 reuse. 88 An explicit specification of the id-pe-autonomousSysIdsPath extension 89 will be added to a later version of this document. 91 3. Changes to the RPKI-router protocol 93 This memo updates the RPKI-router protocol [RFC8210] by adding 94 version 2 of the RPKI-router protocol. Version 2 is a superset of 95 version 1; all implemenations that support version 2 MUST also 96 support version 1. Version negotiation is performed as specified in 97 RFC 8210 [RFC8210], with the addition that version 2 may now be 98 advertised and used if advertised by both sides. 100 Version 2 extends the IPv4 Prefix PDU and IPv6 Prefix PDU. All 101 version 1 PDUs (including the IPv4 and IPv6 Prefix PDUs) may also be 102 used without changes by version 2, and are transmitted with version 103 number 1. 105 The format of the version 2 IPv4 Prefix PDU is as follows: 107 0 8 16 24 31 108 .-------------------------------------------. 109 | Protocol | PDU | | 110 | Version | Type | zero | 111 | 2 | 4 | | 112 +-------------------------------------------+ 113 | | 114 | Length | 115 | | 116 +-------------------------------------------+ 117 | | Prefix | Max | | 118 | Flags | Length | Length | zero | 119 | | 0..32 | 0..32 | | 120 +-------------------------------------------+ 121 | | 122 | IPv4 Prefix | 123 | | 124 +-------------------------------------------+ 125 | | 126 | Autonomous System Number 1 | 127 | | 128 +-------------------------------------------+ 129 | | 130 | Autonomous System Number ... | 131 | | 132 +-------------------------------------------+ 133 | | 134 | Autonomous System Number n | 135 | | 136 `-------------------------------------------' 138 Version: 2 140 Length: the length of the PDU: 16 + 4 * the number of Autonomous 141 System Numbers present. 143 Autonomous System Numbers: AS numbers allowed in the BGP AS path. 144 See the section "path filter semantics" later in this document. 145 At least one Autonomous System Number must be present. 147 All other fields are the same as in version 1. 149 The format of the version 2 IPv6 Prefix PDU is as follows: 151 0 8 16 24 31 152 .-------------------------------------------. 153 | Protocol | PDU | | 154 | Version | Type | zero | 155 | 2 | 6 | | 156 +-------------------------------------------+ 157 | | 158 | Length | 159 | | 160 +-------------------------------------------+ 161 | | Prefix | Max | | 162 | Flags | Length | Length | zero | 163 | | 0..128 | 0..128 | | 164 +-------------------------------------------+ 165 | | 166 +--- ---+ 167 | | 168 +--- IPv6 Prefix ---+ 169 | | 170 +--- ---+ 171 | | 172 +-------------------------------------------+ 173 | | 174 | Autonomous System Number 1 | 175 | | 176 +-------------------------------------------+ 177 | | 178 | Autonomous System Number ... | 179 | | 180 +-------------------------------------------+ 181 | | 182 | Autonomous System Number n | 183 | | 184 `-------------------------------------------' 186 Version: 2 188 Length: the length of the PDU: 28 + 4 * the number of Autonomous 189 System Numbers present. 191 Autonomous System Numbers: AS numbers allowed in the BGP AS path. 192 See the section "path filter semantics" later in this document. 193 At least one Autonomous System Number must be present. 195 All other fields are the same as in version 1. 197 For the purposes of determining uniqueness of IPvX PDUs, only the 198 fields {Prefix, Len, Max-Len, ASN} are considered, as per RFC 8210 199 [RFC8210], where ASN is the first Autonomous System Number in a 200 version 2 IPvX PDU. 202 So for a given {Prefix, Len, Max-Len, ASN} either a version 1 IPvX 203 PDU or a version 2 IPvX PDU may be transmitted, but not both. The 204 relying party software generates a version 2 IPvX PDU when an id-pe- 205 autonomousSysIdsPath with one or more ASes is present in a ROA and 206 generates a version 1 IPvX PDU otherwise. 208 4. Path filter semantics 210 The order in which allowed ASes appear in a ROA is relevant. This 211 order, and the order of the locally allowed ASes, is retained in the 212 list of ASes sent to routers using the RPKI-router protocol version 213 2. A BGP AS path validates when all unique AS numbers in the path 214 are present in the filter in the same order, ignoring AS numbers 215 present in the filter that are missing from the BGP AS path. 217 If an AS path contains an AS_SET with more than one AS number in it 218 and the implementation doesn't perform AS_SET sorting specified as an 219 option in the BGP protocol specification [RFC4271] appendix F.4., 220 then filtering behavior is undefined. 222 Example: the ROA for 192.0.2.0/24 lists the ASes 200 100. The local 223 relying party software is configured to allow the transit AS 800 and 224 the local AS 900. (The local AS normally doesn't appear in AS paths 225 but may be prepended and SHOULD therefore be listed in the filter.) 226 This results in the following sequence of Autonomous System Numbers 227 in the RPKI-router protocol IPv4 Prefix PDU: 229 100 200 800 900 231 Conceptually, this results in the following regular expression BGP AS 232 path filter: 234 ^(900_)*(800_)*(200_)*(100_)+$ 236 However, filtering can be performed more efficiently as shown in the 237 example code in the appendix. 239 5. Internet exchange route servers 241 Many networks interconnect through internet exchanges. In many 242 cases, rather than maintain a direct BGP neighbor relationship 243 between the routers in both ASes, networks connected through an 244 internet exchange interconnect through one or more route servers 245 operated by the internet exchange. 247 As there are many internet exchanges throughout the world and 248 connectivity is subject to change, it would be difficult to add all 249 possible route servers ASes to ROAs. However, in practice this many 250 not be an issue as many route servers don't include their own AS in 251 the AS path. 253 6. IANA Considerations 255 This memo includes no request to IANA. 257 7. Security considerations 259 When two organizations that communicate over the internet both fully 260 implement this specification, they have the ability to make sure to 261 avoid paths containing ASes that neither of them has authorized to 262 carry their their communication, as long as the BGP AS path attribute 263 is an accurate reflection of the actual communication path. 265 In the absence of BGPsec [RFC8205], an AS that doesn't appear on the 266 filter list may forge an AS path in order to reroute traffic through 267 it. However, that AS must then transmit BGP updates with an AS path 268 that doesn't match its own AS as configured by its neighbor. Some 269 implementations check if the neighbor AS and the left most AS in AS 270 paths are the same, as per the MAY in RFC 4271 [RFC4271] section 6.3. 271 So these implementations would reject the forged AS path. 273 Another way to accomplish the same result of a valid looking BGP AS 274 path but an invalid communication path would be for a malicious 275 network to connect to other networks by presenting a falsified AS 276 number when setting up a BGP session. It is unclear to what degree 277 networks make sure the AS numbers that new customers or peers claim 278 to hold are legitimate. 280 8. References 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, 284 DOI 10.17487/RFC2119, March 1997, 285 . 287 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 288 Addresses and AS Identifiers", RFC 3779, 289 DOI 10.17487/RFC3779, June 2004, 290 . 292 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 293 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 294 DOI 10.17487/RFC4271, January 2006, 295 . 297 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 298 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 299 February 2012, . 301 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 302 and B. Dickson, "Problem Definition and Classification of 303 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 304 2016, . 306 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 307 Specification", RFC 8205, DOI 10.17487/RFC8205, September 308 2017, . 310 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 311 Infrastructure (RPKI) to Router Protocol, Version 1", 312 RFC 8210, DOI 10.17487/RFC8210, September 2017, 313 . 315 Appendix A. Appendix: filter code example 317 #include 319 struct pfxpdu 320 { 321 unsigned int version; 322 unsigned int type; 323 unsigned int length; 324 unsigned int *path_filter; 325 }; 327 unsigned int path_filter[] = { 100, 200, 800, 900, 0 }; 328 unsigned int as_path[] = { 900, 900, 800, 300, 200, 100, 0 }; 330 char *filter_as_path(struct pfxpdu *pfxpdu, unsigned int *as_path, 331 int as_path_length) 332 { 333 unsigned int path_filter_length = (pfxpdu->length - 16) / 4; 334 int path_filter_index; 335 int as_path_index; 337 // if the path filter is empty we return status unknown 338 if (path_filter_length < 1) 339 return("unknown"); 341 // check the origin AS as per version 1 of the protocol 342 if (as_path[as_path_length - 1] != pfxpdu->path_filter[0]) 343 return("invalid"); 345 // if the pfxpdu version == 2 then we check the entire path 346 if (pfxpdu->version == 2) 347 { 348 path_filter_index = 0; 349 for (as_path_index = as_path_length - 1; as_path_index >= 0; 350 as_path_index--) 351 { 352 while (path_filter_index < path_filter_length && 353 as_path[as_path_index] != 354 pfxpdu->path_filter[path_filter_index]) 355 path_filter_index++; 356 if (path_filter_index >= path_filter_length) 357 return("invalid"); 358 } 359 } 360 return("valid"); 361 } 363 unsigned int count_length(unsigned int *asns) 364 { 365 unsigned int length = 0; 367 while (asns[length] != 0) 368 length++; 369 return length; 370 } 372 int main() 373 { 374 int i; 375 int as_path_length; 376 struct pfxpdu pfxpdu; 378 as_path_length = count_length(as_path); 380 pfxpdu.version = 2; 381 pfxpdu.type = 4; 382 pfxpdu.length = 16 + 4 * count_length(path_filter); 383 pfxpdu.path_filter = path_filter; 385 printf("Filter regexp: ^"); 386 for (i = (pfxpdu.length - 16) / 4 - 1; i > 0; i--) 387 printf("(%d_)*", pfxpdu.path_filter[i]); 388 printf("(%d_)+$\n", pfxpdu.path_filter[0]); 390 printf("AS path:"); 391 for (i = 0; i < as_path_length; i++) 392 printf(" %d", as_path[i]); 393 printf("\n"); 395 printf("RPKI status: %s\n", filter_as_path(&pfxpdu, as_path, 396 as_path_length)); 397 } 399 Author's Address 401 Iljitsch van Beijnum 402 BGPexpert.com 404 Email: iljitsch@muada.com