idnits 2.17.1 draft-haas-idr-flowspec-term-order-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (27 April 2021) is 1094 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.haas-flowspec-capability-bits' == Outdated reference: A later version (-05) exists of draft-hares-idr-flowspec-v2-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing J. Haas 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track S. Hares 5 Expires: 29 October 2021 Hickory Hill Consulting 6 S. Maduschke 7 Verizon 8 27 April 2021 10 BGP Flowspec Explicit Term Ordering 11 draft-haas-idr-flowspec-term-order-00 13 Abstract 15 BGP Flowspec (RFC 8955) provides a mechanism for matching traffic 16 flows. The ordering of the Flow Specifications defined by that RFC 17 is provided by a sorting function that uses the contents of the 18 received BGP NLRI; that NLRI does not contain an explicit ordering 19 component. The RFC's sorting function permits for origination of 20 Flowspec NLRI from multiple BGP Speakers and is generally appropriate 21 for mitigating distributed denial-of-service (DDoS) attacks. 23 There are circumstances where the implicit RFC 8955 sorting order is 24 not appropriate. This document defines a mechanism that permits 25 individual Flowspec NLRI to influence their sort order. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in BCP 14 [RFC2119] 32 [RFC8174] when, and only when, they appear in all capitals, as shown 33 here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 29 October 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Term Order Component Type . . . . . . . . . . . . . . . . . . 3 69 2.1. Type 0 - Term Order . . . . . . . . . . . . . . . . . . . 3 70 2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Incremental Deployment . . . . . . . . . . . . . . . . . 4 73 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 79 8.2. Informative References . . . . . . . . . . . . . . . . . 6 80 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 83 1. Introduction 85 BGP Flowspec [RFC8955] creates a mechanism for matching traffic flows 86 and taking action upon them. The BGP Flowspec NLRI format defines 87 multiple components that may be used to match such traffic. Traffic 88 may be matched by more than one BGP Flowpec NLRI, either before or 89 after the application of Traffic Filtering Actions (Section 7, 90 [RFC8955]). 92 [RFC8955] does not provide for a mechanism where the originator of a 93 BGP Flowspec NLRI can influence its processing order. Section 5.1 of 94 [RFC8955] provides for a sorting function on a BGP Speaker defining 95 the processing order of received BGP Flowspec NLRI. That sorting 96 mechanism permits multiple BGP Speakers in a Flowspec domain to 97 originate Flowspec NLRI without coordinating the processing order at 98 a given BGP Speaker. 100 That sorting order is generally appropriate for mitigating 101 distributed denial-of-service attacks (DDoS). Flow specification 102 rules first match on related destinations, followed by sources, and 103 then later a well-defined set of components. Longer sets of 104 components are considered a better match, and thus "more specific" in 105 many cases. 107 While this sort order has generally worked well for DDoS mitigation, 108 sometimes the implicit ordering is problematic. Some of these 109 problems are implementation specific: Long rule sets might be better 110 sorted into higher impact filters near the top of the list. Mixtures 111 of rules that are otherwise independent are sorted in such a way that 112 firewall optimizations are not efficiently run. 114 Some initial discussion has begun for a version 2 of Flowspec in 115 [I-D.hares-idr-flowspec-v2]. Part of that proposal is a mechanism to 116 provide for explicit rule ordering as part of the Flowspec v2 NLRI. 118 This document proposes an alternative mechanism to provide for such 119 explicit rule ordering with a minor extension to Flowspec v1. 121 2. Term Order Component Type 123 2.1. Type 0 - Term Order 125 Encoding: 127 Defines the relative term order for this BGP Flowspec NLRI. 129 The value of the length MUST be 1, 2, or 4. The length SHOULD be 130 chosen to be the smallest possible value to properly encode the term 131 order value. 133 2.2. Discussion 135 The choice of Component Type 0, currently RESERVED by [RFC8955], is 136 intended to be minimally disruptive to the sorting function and 137 deployed code for BGP Flowspec. Consider the following text from 138 Section 5.1 of that RFC: 140 "The relative order of two Flow Specifications is determined by 141 comparing their respective components. The algorithm starts by 142 comparing the left-most components (lowest component type value) 143 of the Flow Specifications. If the types differ, the Flow 144 Specification with lowest numeric type value has higher precedence 145 (and thus will match before) than the Flow Specification that 146 doesn't contain that component type. If the component types are 147 the same, then a type-specific comparison is performed (see 148 below). If the types are equal, the algorithm continues with the 149 next component." 151 By using Component Type 0, the ability to bias sort order is provided 152 without a change to the remaining sorting semantics used by [RFC8955] 153 and other proposals. 155 3. Operation 157 The term order value, when present in a BGP Flowspec NLRI, is 158 intended to provide a logical order to that NLRI vs. other NLRI with 159 that component. A lower term order value has a higher precedence 160 than a higher term order value. 162 A BGP Flowspec NLRI with no term order component is considered to be 163 lower precedence versus a BGP Flowspec NLRI with a term order 164 component. This is consistent with existing BGP Flowspec sorting 165 rules. 167 The same term order value MAY occur more than once in a set of BGP 168 Flowspec NLRI. 170 The term order value is not intended to supplant the ordering 171 mechanism for a firewall implementation. Its only purpose is to 172 provide for biasing the sorting of received BGP Flowspec NLRI. 174 3.1. Incremental Deployment 176 [I-D.haas-flowspec-capability-bits] is required to deploy this 177 feature for Flowspec v1. When a BGP Speaker wishes to use, 178 originate, or propagate BGP Flowspec NLRI with the term order 179 component, that BGP Speaker MUST advertise the BGP Flowspec 180 Capability Bits with bit 0 set to a value of 1. 182 4. Error Handling 184 A BGP Flowpsec Term Order Component with a length that is not 1, 2, 185 or 4 is considered syntactically incorrect per Section 5.3 of 186 [RFC7606]. Upon receiving such syntactically incorrect NLRI, the BGP 187 session SHALL be reset by sending a NOTIFICATION message. 189 5. Acknowledgements 191 TBD. 193 6. Security Considerations 195 All of the Security Considerations for [RFC8955] and [RFC8956] still 196 apply. 198 This feature provides for the ability to bias the installed filter 199 order of BGP Flow Specification NLRI. The default sort order 200 provided by [RFC8955] serves to cluster rules targeting traffic for a 201 given destination and/or source. By providing an ability to 202 alternatively order such rules, more general rules impacting more 203 traffic may have precedence. 205 Operators must take sufficient care to ensure that such more general 206 rules are considered systematically in the deployment. This may 207 include the ability to prohibit rules with a term order outside of a 208 specific value range from being accepted. 210 Operators may wish to prohibit other ASes from originating or 211 propagating BGP Flowspec NLRI with the term order component, even 212 while exercising the Validation Procedures of Section 6 of [RFC8955]. 214 7. IANA Considerations 216 Upon approval of this document as an RFC, IANA is requested to assign 217 Type Value 0 from the IANA Flow Spec Component Types registry 218 (https://www.iana.org/assignments/flow-spec/flow-spec.xhtml). The 219 IPv4 Name and IPv6 name for Type 0 will be "Term Order". The 220 Reference will be this document. 222 8. References 224 8.1. Normative References 226 [I-D.haas-flowspec-capability-bits] 227 Haas, J., "BGP Flowspec Capability Bits", Work in 228 Progress, Internet-Draft, draft-haas-flowspec-capability- 229 bits-02, 9 April 2021, . 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 238 Patel, "Revised Error Handling for BGP UPDATE Messages", 239 RFC 7606, DOI 10.17487/RFC7606, August 2015, 240 . 242 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 243 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 244 May 2017, . 246 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 247 Bacher, "Dissemination of Flow Specification Rules", 248 RFC 8955, DOI 10.17487/RFC8955, December 2020, 249 . 251 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 252 "Dissemination of Flow Specification Rules for IPv6", 253 RFC 8956, DOI 10.17487/RFC8956, December 2020, 254 . 256 8.2. Informative References 258 [I-D.hares-idr-flowspec-v2] 259 Hares, S., "BGP Flow Specification Version 2", Work in 260 Progress, Internet-Draft, draft-hares-idr-flowspec-v2-00, 261 25 June 2016, . 264 Appendix A. Open Issues 266 * After sufficient discussion has been given to this proposal, 267 update the python pseudocode example to include interaction with 268 this feature. 270 Authors' Addresses 272 Jeffrey Haas 273 Juniper Networks 275 Email: jhaas@juniper.net 277 Susan Hares 278 Hickory Hill Consulting 280 Email: shares@ndzh.com 281 Sven Maduschke 282 Verizon 284 Email: sven.maduschke@de.verizon.com