Inter-Domain Routing J. Haas Internet-Draft Juniper Networks Intended status: Standards Track S. Hares Expires: 29 October 2021 Hickory Hill Consulting S. Maduschke Verizon 27 April 2021 BGP Flowspec Explicit Term Ordering draft-haas-idr-flowspec-term-order-00 Abstract BGP Flowspec (RFC 8955) provides a mechanism for matching traffic flows. The ordering of the Flow Specifications defined by that RFC is provided by a sorting function that uses the contents of the received BGP NLRI; that NLRI does not contain an explicit ordering component. The RFC's sorting function permits for origination of Flowspec NLRI from multiple BGP Speakers and is generally appropriate for mitigating distributed denial-of-service (DDoS) attacks. There are circumstances where the implicit RFC 8955 sorting order is not appropriate. This document defines a mechanism that permits individual Flowspec NLRI to influence their sort order. 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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." Haas, et al. Expires 29 October 2021 [Page 1] Internet-Draft flowspec-term-order April 2021 This Internet-Draft will expire on 29 October 2021. Copyright Notice Copyright (c) 2021 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Term Order Component Type . . . . . . . . . . . . . . . . . . 3 2.1. Type 0 - Term Order . . . . . . . . . . . . . . . . . . . 3 2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Incremental Deployment . . . . . . . . . . . . . . . . . 4 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction BGP Flowspec [RFC8955] creates a mechanism for matching traffic flows and taking action upon them. The BGP Flowspec NLRI format defines multiple components that may be used to match such traffic. Traffic may be matched by more than one BGP Flowpec NLRI, either before or after the application of Traffic Filtering Actions (Section 7, [RFC8955]). Haas, et al. Expires 29 October 2021 [Page 2] Internet-Draft flowspec-term-order April 2021 [RFC8955] does not provide for a mechanism where the originator of a BGP Flowspec NLRI can influence its processing order. Section 5.1 of [RFC8955] provides for a sorting function on a BGP Speaker defining the processing order of received BGP Flowspec NLRI. That sorting mechanism permits multiple BGP Speakers in a Flowspec domain to originate Flowspec NLRI without coordinating the processing order at a given BGP Speaker. That sorting order is generally appropriate for mitigating distributed denial-of-service attacks (DDoS). Flow specification rules first match on related destinations, followed by sources, and then later a well-defined set of components. Longer sets of components are considered a better match, and thus "more specific" in many cases. While this sort order has generally worked well for DDoS mitigation, sometimes the implicit ordering is problematic. Some of these problems are implementation specific: Long rule sets might be better sorted into higher impact filters near the top of the list. Mixtures of rules that are otherwise independent are sorted in such a way that firewall optimizations are not efficiently run. Some initial discussion has begun for a version 2 of Flowspec in [I-D.hares-idr-flowspec-v2]. Part of that proposal is a mechanism to provide for explicit rule ordering as part of the Flowspec v2 NLRI. This document proposes an alternative mechanism to provide for such explicit rule ordering with a minor extension to Flowspec v1. 2. Term Order Component Type 2.1. Type 0 - Term Order Encoding: Defines the relative term order for this BGP Flowspec NLRI. The value of the length MUST be 1, 2, or 4. The length SHOULD be chosen to be the smallest possible value to properly encode the term order value. 2.2. Discussion The choice of Component Type 0, currently RESERVED by [RFC8955], is intended to be minimally disruptive to the sorting function and deployed code for BGP Flowspec. Consider the following text from Section 5.1 of that RFC: Haas, et al. Expires 29 October 2021 [Page 3] Internet-Draft flowspec-term-order April 2021 "The relative order of two Flow Specifications is determined by comparing their respective components. The algorithm starts by comparing the left-most components (lowest component type value) of the Flow Specifications. If the types differ, the Flow Specification with lowest numeric type value has higher precedence (and thus will match before) than the Flow Specification that doesn't contain that component type. If the component types are the same, then a type-specific comparison is performed (see below). If the types are equal, the algorithm continues with the next component." By using Component Type 0, the ability to bias sort order is provided without a change to the remaining sorting semantics used by [RFC8955] and other proposals. 3. Operation The term order value, when present in a BGP Flowspec NLRI, is intended to provide a logical order to that NLRI vs. other NLRI with that component. A lower term order value has a higher precedence than a higher term order value. A BGP Flowspec NLRI with no term order component is considered to be lower precedence versus a BGP Flowspec NLRI with a term order component. This is consistent with existing BGP Flowspec sorting rules. The same term order value MAY occur more than once in a set of BGP Flowspec NLRI. The term order value is not intended to supplant the ordering mechanism for a firewall implementation. Its only purpose is to provide for biasing the sorting of received BGP Flowspec NLRI. 3.1. Incremental Deployment [I-D.haas-flowspec-capability-bits] is required to deploy this feature for Flowspec v1. When a BGP Speaker wishes to use, originate, or propagate BGP Flowspec NLRI with the term order component, that BGP Speaker MUST advertise the BGP Flowspec Capability Bits with bit 0 set to a value of 1. 4. Error Handling A BGP Flowpsec Term Order Component with a length that is not 1, 2, or 4 is considered syntactically incorrect per Section 5.3 of [RFC7606]. Upon receiving such syntactically incorrect NLRI, the BGP session SHALL be reset by sending a NOTIFICATION message. Haas, et al. Expires 29 October 2021 [Page 4] Internet-Draft flowspec-term-order April 2021 5. Acknowledgements TBD. 6. Security Considerations All of the Security Considerations for [RFC8955] and [RFC8956] still apply. This feature provides for the ability to bias the installed filter order of BGP Flow Specification NLRI. The default sort order provided by [RFC8955] serves to cluster rules targeting traffic for a given destination and/or source. By providing an ability to alternatively order such rules, more general rules impacting more traffic may have precedence. Operators must take sufficient care to ensure that such more general rules are considered systematically in the deployment. This may include the ability to prohibit rules with a term order outside of a specific value range from being accepted. Operators may wish to prohibit other ASes from originating or propagating BGP Flowspec NLRI with the term order component, even while exercising the Validation Procedures of Section 6 of [RFC8955]. 7. IANA Considerations Upon approval of this document as an RFC, IANA is requested to assign Type Value 0 from the IANA Flow Spec Component Types registry (https://www.iana.org/assignments/flow-spec/flow-spec.xhtml). The IPv4 Name and IPv6 name for Type 0 will be "Term Order". The Reference will be this document. 8. References 8.1. Normative References [I-D.haas-flowspec-capability-bits] Haas, J., "BGP Flowspec Capability Bits", Work in Progress, Internet-Draft, draft-haas-flowspec-capability- bits-02, 9 April 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Haas, et al. Expires 29 October 2021 [Page 5] Internet-Draft flowspec-term-order April 2021 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, . [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, . 8.2. Informative References [I-D.hares-idr-flowspec-v2] Hares, S., "BGP Flow Specification Version 2", Work in Progress, Internet-Draft, draft-hares-idr-flowspec-v2-00, 25 June 2016, . Appendix A. Open Issues * After sufficient discussion has been given to this proposal, update the python pseudocode example to include interaction with this feature. Authors' Addresses Jeffrey Haas Juniper Networks Email: jhaas@juniper.net Susan Hares Hickory Hill Consulting Email: shares@ndzh.com Haas, et al. Expires 29 October 2021 [Page 6] Internet-Draft flowspec-term-order April 2021 Sven Maduschke Verizon Email: sven.maduschke@de.verizon.com Haas, et al. Expires 29 October 2021 [Page 7]