SIDR Operations I. van Beijnum Internet-Draft BGPexpert.com Updates: 6811, 8210 (if approved) July 11, 2019 Intended status: Standards Track Expires: January 12, 2020 Extensions to the RPKI-Router protocol draft-van-beijnum-sidrops-rpki-rtr-ext-00 Abstract This memo extends the Resource Public Key Infrastructure (RPKI) to Router Protocol to allow for additional validation mechanisms in addition to BGP Prefix Origin Validation. 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 January 12, 2020. 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 January 12, 2020 [Page 1] Internet-Draft Extensions to the RPKI-Router protocol July 2019 1. Introduction As defined in RFC 8210 [RFC8210], the RPKI-Router protocol supports BGP Prefix Origin Validation (RFC 6811 [RFC6811]). This specification extends the RPKI-Router protocol with filtering options that may support additional validation mechanisms: most notably, validating the full AS path as seen from a particular vantage point, as well as a more generic prefix filtering mechanism. For this purpose, three additional PDU types are added to the RPKI-Router protocol (for both IPv4 and IPv6): 1. A PDU type with a semi-ordered list of AS numbers that may appear in a valid AS path. 2. A PDU type with a list of next hop AS numbers from which a given prefix will not be accepted. 3. A PDU type with a list of next hop AS numbers from which a given prefix will be accepted. How the contents of the three new PDU types are generated is beyond the scope of this memo; possible mechanisms for this could be AS_PATH Verification [I-D.azimov-sidrops-aspa-verification] (ASPA) and RPKI AS Cones [I-D.ietf-grow-rpki-as-cones], as well as any type of manual or automated configuration deemed useful by the operator of a local cache. This specification keeps the NotFound / Valid / Invalid validation states from RFC 6811 [RFC6811], but redefines their applicability. 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. RPKI-router protocol versions This memo updates the RPKI-router protocol [RFC8210] by adding versions 2 and 3 of the RPKI-router protocol. Version 2 is a superset of versions 0 and 1; version 3 is a superset of version 2. Version negotiation is performed as specified in RFC 8210 [RFC8210]. The following table lists all PDUs that are defined in one or more of the four versions of the protocol, and whether they MUST be supported in a given version. Van Beijnum Expires January 12, 2020 [Page 2] Internet-Draft Extensions to the RPKI-Router protocol July 2019 Name PDU type V 0 V 1 V 2 V 3 Serial Notify 0 + + + + Serial Query 1 + + + + Reset Query 2 + + + + Cache Response 3 + + + + IPv4 Prefix 4 + + + + IPv6 Prefix 6 + + + + End of Data 7 + + + + Cache Reset 8 + + + + Router Key 9 - + * + Error Report 10 + + + + Deny IPv4 Prefix 40 - - + * Allow IPv4 Prefix 41 - - + * IPv4 Path 42 - - - + Deny IPv6 Prefix 60 - - + * Allow IPv6 Prefix 61 - - + * IPv6 Path 62 - - - + A + means that the PDU type MUST be implemented in order to support the indicated version of the RPKI-Router protocol. A - means that the PDU type is not valid for the indicated version of the protocol and MUST NOT be sent when the indicated version of the protocol is negotiated. A * means that the PDU type is valid for the indicated protocol version and MAY be transmitted when the indicated version of the protocol is negotiated, but PDUs of that type MAY be silently ignored upon reception. All version 0 and version 1 PDUs are transmitted with version number 2 when version 2 of the protocol is negotiated and are transmitted with version numer 3 when version 3 of the protocol is negotiated. 3. Format of the new RPKI-router PDUs The format of the Deny IPv4 Prefix, Allow IPv4 Prefix and IPv4 Path PDUs is the same and as follows: Van Beijnum Expires January 12, 2020 [Page 3] Internet-Draft Extensions to the RPKI-Router protocol July 2019 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | | | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | | Prefix | Max | | | Flags | Length | Length | zero | | | 0..32 | 0..32 | | +-------------------------------------------+ | | | IPv4 Prefix | | | +-------------------------------------------+ | | | Autonomous System Number 1 | | | +-------------------------------------------+ | | | Autonomous System Number ... | | | +-------------------------------------------+ | | | Autonomous System Number n | | | `-------------------------------------------' Protocol Version: 2 or 3 for Deny IPv4 Prefix and Allow IPv4 Prefix, 3 for IPv4 Path. PDU Type: 40 for Deny IPv4 Prefix, 41 for Allow IPv4 Prefix, 42 for IPv4 Path. Length: the length of the PDU: 16 + 4 * the number of Autonomous System Numbers present. Autonomous System Numbers: a set of AS numbers. The semantics of this set of AS numbers for the different PDU types is discussed later in this document. All other fields are the same as in version 1. The format of the version 2 IPv6 Prefix PDU is as follows: Van Beijnum Expires January 12, 2020 [Page 4] Internet-Draft Extensions to the RPKI-Router protocol July 2019 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | | | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | | Prefix | Max | | | Flags | Length | Length | zero | | | 0..128 | 0..128 | | +-------------------------------------------+ | | +--- ---+ | | +--- IPv6 Prefix ---+ | | +--- ---+ | | +-------------------------------------------+ | | | Autonomous System Number 1 | | | +-------------------------------------------+ | | | Autonomous System Number ... | | | +-------------------------------------------+ | | | Autonomous System Number n | | | `-------------------------------------------' Protocol Version: 2 or 3 for Deny IPv6 Prefix and Allow IPv6 Prefix, 3 for IPv6 Path. PDU Type: 60 for Deny IPv6 Prefix, 61 for Allow IPv6 Prefix, 62 for IPv6 Path. Length: the length of the PDU: 28 + 4 * the number of Autonomous System Numbers present. Autonomous System Numbers: a set of AS numbers. The semantics of this set of AS numbers for the different PDU types is discussed later in this document. Van Beijnum Expires January 12, 2020 [Page 5] Internet-Draft Extensions to the RPKI-Router protocol July 2019 All other fields are the same as in version 1. 4. PDU uniqueness For the purposes of determining uniqueness of the new PDUs, the following applies: The cache server MUST ensure that at any given time, it has told the router client to have only one Deny IPvX Prefix PDU for a given {Prefix, Len, Max-Len}. The cache server MUST ensure that at any given time, it has told the router client to have only one Allow IPvX Prefix PDU for a given {Prefix, Len, Max-Len}. The cache server MUST ensure that at any given time, it has told the router client to have either one IPvX Prefix or one IPvX Path PDU for a given {Prefix, Len, Max-Len, ASN}. (Where ASN is the first Autonomous System Number in a IPvX Path PDU.) 5. IPvX Prefix and IPvX Path filter semantics If a prefix is a more specific prefix of a prefix for which an IPvX Prefix or IPvX Path PDU exists, and the prefix would be considered "Valid" as per below, except that the prefix length is longer than MaxLen in the IPvX Prefix or IPvX Path PDU, then the prefix is given state "Invalid". The IPv4 Path and IPv6 Path PDUs are used to convey the full set of ASes that may legitimately appear in the BGP AS path for a matching prefix (taking Max-Len into consideration). As such, if the AS path only contains those ASes, the prefix is given state "Valid". If other ASes appear in the AS path, the prefix is given state "Invalid". If for a given prefix, no matching IPv4 Path or IPv6 Path PDU is present, but an IPv4 Prefix or IPv6 Prefix is present and the BGP AS path only contains one or more instances of the origin AS ("ASN" in the IPvX Prefix PDU), then the prefix is given state "Valid". If for a given prefix, no matching IPv4 Path or IPv6 Path PDU is present, but an IPv4 Prefix or IPv6 Prefix is present and the BGP AS path contains additional AS numbers in addition to the origin AS, the prefix is validated as per RFC 6811 [RFC6811]. However, if the origin AS is valid, the prefix SHOULD be given state "NotFound" rather than state "Valid", as the full path couldn't be validated. (Client routers MAY have a configuration option to either retain the Van Beijnum Expires January 12, 2020 [Page 6] Internet-Draft Extensions to the RPKI-Router protocol July 2019 RFC 6811 behavior (Valid) rather than the behavior specified here (NotFound).) If a prefix couldn't be matched against the IPvX Prefix and IPvX Path PDU database, it is given state "NotFound". 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. In addition, the use of AS_SETs with RPKI origin validation may be problematic, and the use of AS_SETs is deprecated in RFC 6472 [RFC6472]. The order in which allowed ASes appear in an IPvX Path PDU is relevant. 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. 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. 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. Van Beijnum Expires January 12, 2020 [Page 7] Internet-Draft Extensions to the RPKI-Router protocol July 2019 6. Deny IPvX filter semantics When a client router receives a prefix over eBGP, it performs a longest match based on {Prefix, Len} with the received Deny IPvX PDUs. Then, a further match based on {Max-Len} is performed. As a result, if these two Deny IPv6 PDUs are present: PDU 1: Prefix = ::, Len = 0, Max-Len = 128 PDU 2: Prefix = 2001:db8::, Len = 32, Max-Len = 48 Then 2001:db8::dead:beef wouldn't match either PDU. Thus, a {Max-Len} other than {Len} or 32 or 128, for IPv4 and IPv6, respectively, will likely not be very useful. For a matching prefix, a check is performed whether the next hop AS matches any of the ASes listed in the Deny IPvX PDU. If there is a match, then the prefix is filtered out by default, even if the validation state is "Valid". Implementations SHOULD provide configuration options to disable this filtering completely, or to allow otherwise filtered prefixes if the validation state is "Valid". Implementations SHOULD have a configuration option to replace the next hop AS for the purposes of Deny IPvX and Allow IPvX filtering on a per-neighbor basis, and/or have a configuration option to add additional AS numbers that will be checked against the list of ASes in the Deny IPvX and Allow IPvX PDUs. 7. Allow IPvX filter semantics Unless configured explicitly to do otherwise, implementations SHOULD allow all prefixes with state "Valid", bypassing any restrictions imposed by Allow IPvX PDU filters. Allow IPvX filtering is not active by default. Implementations SHOULD have configuration options to filter out any prefixes that don't match an Allow IPvX PDU or have validation state "Valid", on a per-eBGP neighbor basis. The description below applies when such filtering is enabled for a given eBGP neighbor. Prefixes are matched against Allow IPvX PDUs the same way as they are matched against Deny IPvX PDUs. For a matching prefix, a check is performed whether the next hop AS matches any of the ASes listed in the Allow IPvX PDU. If there is a match, then the prefix is allowed through. Unless configured otherwise, prefixes with validation state is "Valid" are always allowed through. As mentioned earlier, implementations SHOULD have a configuration option to replace the next hop AS for the purposes of Deny IPvX and Allow IPvX filtering on a per-neighbor basis, and/or have a Van Beijnum Expires January 12, 2020 [Page 8] Internet-Draft Extensions to the RPKI-Router protocol July 2019 configuration option to add additional AS numbers that will be checked against the list of ASes in the Deny IPvX and Allow IPvX PDUs. 8. Applicability The rationale behind this work is to allow for innovation in making global routing more resilient against problems such as route leaks. The idea is that modifying BGP implementations based on new insights is very difficult, both because few organizations have the ability to change BGP implementations, and also because effective global routing requires stable implementations. So rather than implement new mechanisms directly on BGP routers, those new mechanisms may be added to cache servers, which then push out well-defined filter rules to BGP routers. One example of how BGP path validation could work is AS_PATH Verification [I-D.azimov-sidrops-aspa-verification], which adds customer-to-provider relationship records to RPKI and recursively builds full possible paths that could be used for filtering with IPvX Path PDUs. Another approach is RPKI AS Cones [I-D.ietf-grow-rpki-as-cones], which adds provider-to-customer relationship records to RPKI named "AS cones". By recursing these, filters may be created for individual peering partners. These filters could be sent to routers using Allow IPvX PDUs. A cache server could also have BGP feeds and monitor those for incorrect prefix advertisements or anomalous AS paths (for instance, paths that don't conform to the valley-freeness property), and then push out Deny IPvX PDUs to "poison" those routes. 9. IANA Considerations IANA is requested to add the following RPKI-Router protocol PDUs: Deny IPv4 Prefix 40 Allow IPv4 Prefix 41 IPv4 Path 42 Deny IPv6 Prefix 60 Allow IPv6 Prefix 61 Van Beijnum Expires January 12, 2020 [Page 9] Internet-Draft Extensions to the RPKI-Router protocol July 2019 IPv6 Path 62 10. Security considerations The mechanisms described in this document allow for central systems to push out filters to a large number of BGP routers. As such, if the central cache servers become corrupted, either by accident or through malicious action, the consequence could be a significant denail-of-service. 11. References [I-D.azimov-sidrops-aspa-verification] Azimov, A., Bogomazov, E., Bush, R., Patel, K., and J. Snijders, "Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization", draft-azimov-sidrops-aspa- verification-01 (work in progress), October 2018. [I-D.ietf-grow-rpki-as-cones] Snijders, J. and M. Stucchi, "RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering", draft-ietf-grow- rpki-as-cones-01 (work in progress), March 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, DOI 10.17487/RFC6472, December 2011, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . Van Beijnum Expires January 12, 2020 [Page 10] Internet-Draft Extensions to the RPKI-Router protocol July 2019 [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; 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"); Van Beijnum Expires January 12, 2020 [Page 11] Internet-Draft Extensions to the RPKI-Router protocol July 2019 } } 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); 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 January 12, 2020 [Page 12]