SIDR Operations I. van Beijnum Internet-Draft BGPexpert.com Updates: RFC 3779, RFC 8210 (if June 20, 2019 approved) Intended status: Experimental Expires: December 22, 2019 Path validation with RPKI draft-van-beijnum-sidrops-pathrpki-00 Abstract This memo adds the capability to validate the full BGP AS path to the RPKI mechanism. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 22, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Van Beijnum Expires December 22, 2019 [Page 1] Internet-Draft Path validation with RPKI June 2019 1. Introduction With RPKI, it's possible for BGP routers to validate the origin AS found in the BGP AS path attribute for a given IP prefix. However, RPKI can't validat the rest of the AS path, allowing for route leaks types 1 - 4 as described in RFC 7908 [RFC7908]. This specification extends RPKI to allow for validating the full BGP AS path, based on the observation that each AS in a valid AS path has either a trust relation with the origin AS or has a trust relation with the local AS (the AS performing validation). I.e., each intermediary AS provides transit service to either the origin AS or the local AS. An extension to RFC 3779 [RFC3779] allows for binding a list of allowed transit ASes to a set of IP addresses. Operators of RPKI [RFC6480] relying party software add to this their list of locally allowed transit ASes through manual configuration. An update to the RPKI-router protocol [RFC8210] lets relying party software propagate the thus created list of allowed ASes for the prefix(es) in question so BGP routers can validate the corresponding AS paths. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Changes to the ROA certificate format RFC 3779 [RFC3779] specifies an extension to X.509 certificates that contains a set of AS numbers: id-pe-autonomousSysIds. This is the set of valid origin ASes for a given set of IP addresses. This memo adds another extension to X.509 certificates with the name id-pe-autonomousSysIdsPath. id-pe-autonomousSysIdsPath is identical in syntax to the existing id-pe-autonomousSysIds, allowing for code reuse. An explicit specification of the id-pe-autonomousSysIdsPath extension will be added to a later version of this document. 3. Changes to the RPKI-router protocol This memo updates the RPKI-router protocol [RFC8210] by adding version 2 of the RPKI-router protocol. Version 2 is a superset of version 1; all implemenations that support version 2 MUST also support version 1. Version negotiation is performed as specified in Van Beijnum Expires December 22, 2019 [Page 2] Internet-Draft Path validation with RPKI June 2019 RFC 8210 [RFC8210], with the addition that version 2 may now be advertised and used if advertised by both sides. Version 2 extends the IPv4 Prefix PDU and IPv6 Prefix PDU. All version 1 PDUs (including the IPv4 and IPv6 Prefix PDUs) may also be used without changes by version 2, and are transmitted with version number 1. The format of the version 2 IPv4 Prefix PDU is as follows: 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | 2 | 4 | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | | Prefix | Max | | | Flags | Length | Length | zero | | | 0..32 | 0..32 | | +-------------------------------------------+ | | | IPv4 Prefix | | | +-------------------------------------------+ | | | Autonomous System Number 1 | | | +-------------------------------------------+ | | | Autonomous System Number ... | | | +-------------------------------------------+ | | | Autonomous System Number n | | | `-------------------------------------------' Version: 2 Length: the length of the PDU: 16 + 4 * the number of Autonomous System Numbers present. Van Beijnum Expires December 22, 2019 [Page 3] Internet-Draft Path validation with RPKI June 2019 Autonomous System Numbers: AS numbers allowed in the BGP AS path. See the section "path filter semantics" later in this document. At least one Autonomous System Number must be present. All other fields are the same as in version 1. The format of the version 2 IPv6 Prefix PDU is as follows: 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | 2 | 6 | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | | Prefix | Max | | | Flags | Length | Length | zero | | | 0..128 | 0..128 | | +-------------------------------------------+ | | +--- ---+ | | +--- IPv6 Prefix ---+ | | +--- ---+ | | +-------------------------------------------+ | | | Autonomous System Number 1 | | | +-------------------------------------------+ | | | Autonomous System Number ... | | | +-------------------------------------------+ | | | Autonomous System Number n | | | `-------------------------------------------' Version: 2 Length: the length of the PDU: 28 + 4 * the number of Autonomous System Numbers present. Van Beijnum Expires December 22, 2019 [Page 4] Internet-Draft Path validation with RPKI June 2019 Autonomous System Numbers: AS numbers allowed in the BGP AS path. See the section "path filter semantics" later in this document. At least one Autonomous System Number must be present. All other fields are the same as in version 1. For the purposes of determining uniqueness of IPvX PDUs, only the fields {Prefix, Len, Max-Len, ASN} are considered, as per RFC 8210 [RFC8210], where ASN is the first Autonomous System Number in a version 2 IPvX PDU. So for a given {Prefix, Len, Max-Len, ASN} either a version 1 IPvX PDU or a version 2 IPvX PDU may be transmitted, but not both. The relying party software generates a version 2 IPvX PDU when an id-pe- autonomousSysIdsPath with one or more ASes is present in a ROA and generates a version 1 IPvX PDU otherwise. 4. Path filter semantics The order in which allowed ASes appear in a ROA is relevant. This order, and the order of the locally allowed ASes, is retained in the list of ASes sent to routers using the RPKI-router protocol version 2. A BGP AS path validates when all unique AS numbers in the path are present in the filter in the same order, ignoring AS numbers present in the filter that are missing from the BGP AS path. If an AS path contains an AS_SET with more than one AS number in it and the implementation doesn't perform AS_SET sorting specified as an option in the BGP protocol specification [RFC4271] appendix F.4., then filtering behavior is undefined. Example: the ROA for 192.0.2.0/24 lists the ASes 200 100. The local relying party software is configured to allow the transit AS 800 and the local AS 900. (The local AS normally doesn't appear in AS paths but may be prepended and SHOULD therefore be listed in the filter.) This results in the following sequence of Autonomous System Numbers in the RPKI-router protocol IPv4 Prefix PDU: 100 200 800 900 Conceptually, this results in the following regular expression BGP AS path filter: ^(900_)*(800_)*(200_)*(100_)+$ However, filtering can be performed more efficiently as shown in the example code in the appendix. Van Beijnum Expires December 22, 2019 [Page 5] Internet-Draft Path validation with RPKI June 2019 5. Internet exchange route servers Many networks interconnect through internet exchanges. In many cases, rather than maintain a direct BGP neighbor relationship between the routers in both ASes, networks connected through an internet exchange interconnect through one or more route servers operated by the internet exchange. As there are many internet exchanges throughout the world and connectivity is subject to change, it would be difficult to add all possible route servers ASes to ROAs. However, in practice this many not be an issue as many route servers don't include their own AS in the AS path. 6. IANA Considerations This memo includes no request to IANA. 7. Security considerations When two organizations that communicate over the internet both fully implement this specification, they have the ability to make sure to avoid paths containing ASes that neither of them has authorized to carry their their communication, as long as the BGP AS path attribute is an accurate reflection of the actual communication path. In the absence of BGPsec [RFC8205], an AS that doesn't appear on the filter list may forge an AS path in order to reroute traffic through it. However, that AS must then transmit BGP updates with an AS path that doesn't match its own AS as configured by its neighbor. Some implementations check if the neighbor AS and the left most AS in AS paths are the same, as per the MAY in RFC 4271 [RFC4271] section 6.3. So these implementations would reject the forged AS path. Another way to accomplish the same result of a valid looking BGP AS path but an invalid communication path would be for a malicious network to connect to other networks by presenting a falsified AS number when setting up a BGP session. It is unclear to what degree networks make sure the AS numbers that new customers or peers claim to hold are legitimate. 8. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Van Beijnum Expires December 22, 2019 [Page 6] Internet-Draft Path validation with RPKI June 2019 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, "Problem Definition and Classification of BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 2016, . [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . [RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, . Appendix A. Appendix: filter code example #include struct pfxpdu { unsigned int version; unsigned int type; unsigned int length; unsigned int *path_filter; }; unsigned int path_filter[] = { 100, 200, 800, 900, 0 }; unsigned int as_path[] = { 900, 900, 800, 300, 200, 100, 0 }; char *filter_as_path(struct pfxpdu *pfxpdu, unsigned int *as_path, int as_path_length) { unsigned int path_filter_length = (pfxpdu->length - 16) / 4; int path_filter_index; Van Beijnum Expires December 22, 2019 [Page 7] Internet-Draft Path validation with RPKI June 2019 int as_path_index; // if the path filter is empty we return status unknown if (path_filter_length < 1) return("unknown"); // check the origin AS as per version 1 of the protocol if (as_path[as_path_length - 1] != pfxpdu->path_filter[0]) return("invalid"); // if the pfxpdu version == 2 then we check the entire path if (pfxpdu->version == 2) { path_filter_index = 0; for (as_path_index = as_path_length - 1; as_path_index >= 0; as_path_index--) { while (path_filter_index < path_filter_length && as_path[as_path_index] != pfxpdu->path_filter[path_filter_index]) path_filter_index++; if (path_filter_index >= path_filter_length) return("invalid"); } } return("valid"); } unsigned int count_length(unsigned int *asns) { unsigned int length = 0; while (asns[length] != 0) length++; return length; } int main() { int i; int as_path_length; struct pfxpdu pfxpdu; as_path_length = count_length(as_path); pfxpdu.version = 2; pfxpdu.type = 4; pfxpdu.length = 16 + 4 * count_length(path_filter); Van Beijnum Expires December 22, 2019 [Page 8] Internet-Draft Path validation with RPKI June 2019 pfxpdu.path_filter = path_filter; printf("Filter regexp: ^"); for (i = (pfxpdu.length - 16) / 4 - 1; i > 0; i--) printf("(%d_)*", pfxpdu.path_filter[i]); printf("(%d_)+$\n", pfxpdu.path_filter[0]); printf("AS path:"); for (i = 0; i < as_path_length; i++) printf(" %d", as_path[i]); printf("\n"); printf("RPKI status: %s\n", filter_as_path(&pfxpdu, as_path, as_path_length)); } Author's Address Iljitsch van Beijnum BGPexpert.com Email: iljitsch@muada.com van Beijnum Expires December 22, 2019 [Page 9]