idnits 2.17.00 (12 Aug 2021) /tmp/idnits57975/draft-haas-flowspec-capability-bits-02.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 draft header indicates that this document updates RFC8955, but the abstract doesn't seem to directly say this. It does mention RFC8955 though, so this could be OK. 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 (9 April 2021) is 400 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) == Outdated reference: A later version (-05) exists of draft-hares-idr-flowspec-v2-00 == Outdated reference: draft-ietf-idr-ext-opt-param has been published as RFC 9072 Summary: 0 errors (**), 0 flaws (~~), 4 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 Updates: 8955 (if approved) 9 April 2021 5 Intended status: Standards Track 6 Expires: 11 October 2021 8 BGP Flowspec Capability Bits 9 draft-haas-flowspec-capability-bits-02 11 Abstract 13 BGP Flowspec (RFC 8955) provides the ability to filter traffic using 14 various matching components. The NLRI format currently defined does 15 not permit incremental deployment of new BGP Flowspec components. 16 This draft defines a new BGP Capability to permit incremental 17 deployment of such new Flowspec component types. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in BCP 14 [RFC2119] 24 [RFC8174] when, and only when, they appear in all capitals, as shown 25 here. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 11 October 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. BGP Flowspec Capability Bits . . . . . . . . . . . . . . . . 3 62 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Propagation of Known Components and Mismatch with Local 64 Filtering Capabilities . . . . . . . . . . . . . . . . . 5 65 5. BGP Flowspec Implications for Filtered NLRI . . . . . . . . . 5 66 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 10.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Appendix A. Encoding of the Bit-String . . . . . . . . . . . . . 7 74 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 7 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 BGP Flowspec [RFC8955] provides a mechanism to distribute traffic 80 flow spcifications into BGP. One general purpose of these flow 81 specifications is for the distribution of firewall rules to receiving 82 routers, particularly for mitigating distributed denial of service 83 (DDoS) attacks. The flow specification rules are encoded as BGP NLRI 84 [RFC4271]. 86 The matching components of a flow specification NLRI is a serialized 87 set of optional components. The components are documented in 88 [RFC8955], Section 3. [RFC8956] defines IPv6-specific components. 89 The full set of Flowspec component types is maintained in an IANA 90 registry located at the IANA Flow Spec Component Types registry 91 (https://www.iana.org/assignments/flow-spec/flow-spec.xhtml). 93 Unknown Flowspec component types require treatment as a malformed 94 NLRI ([RFC8955], Section 4.2). This is due to the lack of a 95 mandatory length element for the components in the NLRI. Without 96 such a length, it is not possible to determine how to properly decode 97 unknown components in the Flowspec NLRI. 99 There has been active interest in the IDR Working Group to extend BGP 100 Flowspec for additional purposes. However, with this difficulty in 101 being able to handle unknown components, those new features are 102 unable to be deployed in a BGP Flowspec domain in an incremental 103 fashion. Either a carefully managed "flag day" deployment is 104 required to avoid disrupting existing sessions, or the Flowspec 105 domain is carefully managed such that devices with incompatible sets 106 of known/unknown components are carefully separated in a "ships in 107 the night" scenario. Both options are fragile and operationally 108 cumbersome. 110 Some initial discussion has begun for a version 2 of Flowspec in 111 [I-D.hares-idr-flowspec-v2]. That document may eventually address 112 this incremental deployment issue, along with a number of other 113 items. 115 This document proposes to address the issues of incremental 116 deployment of new BGP Flowspec component types via a new BGP 117 Capability [RFC5492], the BGP Flowpec Capability Bits. 119 2. BGP Flowspec Capability Bits 121 BGP Flowspec component types are one octet in length with values in 122 the range from 0..255. The BGP Flowspec Capability Bits encode a 123 bit-string where each supported component type has its respective bit 124 set when the BGP Speaker is willing to receive BGP Flowspec NLRI that 125 contain that component type. 127 The BGP Flowspec Capability Bits Capability is encoded as follows: 129 * Capability Code of (TBD). 131 * Capability Length of 1..32. 133 * Capability Value contains a bit-string where a bit is set if the 134 underlying BGP Flowspec component is willing to be accepted by BGP 135 Speaker advertising this capability. 137 Example encoding for Capability Value: 139 0 1 140 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 |0|1|1|1|1|1|1|1|1|1|1|1|1|1|0|0| 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Bit 0 set to 0, bits 1..13 set to 1 showing support for all 146 capabilities for IPv6 Flowspec, bits 14 and 15 are set to 0. 148 3. Operation 150 BGP Flowspec Capability Bits not advertised in the encoded bit-string 151 are treated as if they were sent with a value of zero for that bit. 153 The Capability Length reflects the number of octets it takes to 154 encode the BGP Flowspec Capability Bits. While the total number of 155 octets required to represent the entire range of component types is 156 only 32 octets, implementations SHOULD limit the number of octets 157 transmitted to those required to encode the final one-bit. Space in 158 BGP Capabilities may be limited in some implementations depending on 159 the number of capabilities to be sent. (See 160 [I-D.ietf-idr-ext-opt-param] for discussion on a feature to address 161 this point.) 163 Bit-values 0 and 255 SHOULD be set to zero as they are RESERVED. 165 The BGP Flowspec Capability Bits Capability SHOULD be sent by a BGP 166 Speaker utilizing any AFI/SAFI using BGP Flowspec encoding as defined 167 in [RFC8955], or [RFC8956]. 169 The BGP Flowspec Capability Bits Capability MUST be sent by a BGP 170 Speaker utilizing BGP Flowspec encoding with a component type not 171 defined in those documents previously mentioned. (I.e. component 172 types not in the range 1..13.) 174 A BGP Speaker that has received the BGP Flowspec Capability Bits 175 Capability MUST NOT originate or propagate a BGP Flowspec encoded 176 NLRI that contains a component types that is not present in the 177 received bit-string. 179 A BGP Speaker that has received a BGP Flowspec related AFI/SAFI 180 without this Capability MUST treat the absence as equivalent to 181 having received the Capability Bits covered by the base specification 182 for its defining RFC, [RFC8955] or [RFC8956]. 184 4. Propagation of Known Components and Mismatch with Local Filtering 185 Capabilities 187 There may be circumstances where a BGP Speaker is capable of parsing 188 Flowspec components that it is not capable of implementing as 189 filters. Section 4.2 of [RFC8955] specifies that: 191 "All combinations of components within a single Flow Specification 192 are allowed. However, some combinations cannot match any packets 193 (e.g., "ICMP Type AND Port" will never match any packets) and thus 194 SHOULD NOT be propagated by BGP." 196 This document updates that text to: 198 "All combinations of components within a single Flow Specification 199 are allowed. However, some combinations cannot match any packets 200 (e.g., "ICMP Type AND Port" will never match any packets) and thus 201 SHOULD NOT be propagated by BGP. 203 "When BGP Flowspec component types are understood and the operator 204 determines that deployment-wide filtering intent would not be 205 comporomised by propagating Flowepec routes that cannot match any 206 packets, it SHOULD propagate the route in BGP. This permits NLRI 207 with known components to be propagated to downstream BGP Speakers 208 in the deployment." 210 5. BGP Flowspec Implications for Filtered NLRI 212 BGP Flowspec NLRI encode match operations for traffic filtering 213 rules. Filtering is an ordered operation. Since the current 214 encoding of the NLRI does not supply explicit filtering order, the 215 protocol imposes a forwarding order based on the contents of the 216 NLRI. 218 When a BGP Flowspec NLRI is not propagated due to filtering by this 219 feature, or by user policy, there is the potential that the network- 220 wide filtering intent may be compromised by the missing rules. The 221 exact impact of this on filtering will depend on the relative 222 independence of the full set of BGP Flowspec routes in the BGP 223 Flowspec routing domain. 225 Operators must exercise care when deploying BGP Flowspec features 226 with new component types to understand the propagation of such routes 227 in their deployment, and the impact that filtering may have on the 228 routes they wish to originate. 230 6. Error Handling 232 If a BGP Speaker implementing this document has transmitted BGP 233 Flowspec Capability Bits to its peer and receives a BGP Flowspec NLRI 234 with an unacceptable component (not in its bit-string), it MAY 235 terminate the BGP session by sending a NOTIFICATION message. 237 7. Acknowledgements 239 Thanks to Aseem Choudhary, Jakob Heitz, Christoph Loibl, Robert 240 Raszuk for their comments on this proposal. 242 8. Security Considerations 244 All of the Security Considerations for [RFC8955] and [RFC8956] still 245 apply. 247 Additionally, the BGP Flowspec Capability Bits may cause implicit 248 filtering of some BGP Flowspec NLRI in a Flowspec domain. Depending 249 on the relative independence of the traffic matched by the BGP 250 Flowspec rules in the ordering required by their specifications, such 251 filtered NLRI may result in impact to the desired domain-wide 252 filtering behaviors. 254 9. IANA Considerations 256 IANA is requested to assign a new BGP Capability to the Capability 257 Codes registry from the First Come, First Served pool. The Reference 258 for the registration is this document. The Change Controller is 259 IETF. 261 10. References 263 10.1. Normative References 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, 267 DOI 10.17487/RFC2119, March 1997, 268 . 270 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 271 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 272 2009, . 274 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 275 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 276 May 2017, . 278 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 279 Bacher, "Dissemination of Flow Specification Rules", 280 RFC 8955, DOI 10.17487/RFC8955, December 2020, 281 . 283 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 284 "Dissemination of Flow Specification Rules for IPv6", 285 RFC 8956, DOI 10.17487/RFC8956, December 2020, 286 . 288 10.2. Informative References 290 [I-D.hares-idr-flowspec-v2] 291 Hares, S., "BGP Flow Specification Version 2", Work in 292 Progress, Internet-Draft, draft-hares-idr-flowspec-v2-00, 293 25 June 2016, . 296 [I-D.ietf-idr-ext-opt-param] 297 Chen, E. and J. Scudder, "Extended Optional Parameters 298 Length for BGP OPEN Message", Work in Progress, Internet- 299 Draft, draft-ietf-idr-ext-opt-param-09, 21 August 2020, 300 . 303 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 304 Schoenwaelder, Ed., "Structure of Management Information 305 Version 2 (SMIv2)", STD 58, RFC 2578, 306 DOI 10.17487/RFC2578, April 1999, 307 . 309 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 310 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 311 DOI 10.17487/RFC4271, January 2006, 312 . 314 Appendix A. Encoding of the Bit-String 316 IETF has a mixed history in terms of how bit numbering is described. 317 The format as used in this document, where the left-most bit sent on 318 the wire is bit zero, is consistent with IETF PDU diagrams and also 319 the SNMP BITS construct [RFC2578], Section 7.1.4. 321 That said, the author is aware of how annoying the code for that 322 construct can be. 324 Appendix B. Open Issues 325 * Are there circumstances where advertising capability bits for BGP 326 Flowspec NLRI that need to vary on a per AFI-SAFI basis? 327 Currently, the IANA registry is a single name space for all 328 supported and proposed BGP address families. As an example, the 329 Flowspec for NVO3 feature has components that are defined that do 330 not have incremental deployment issues due to being well formed 331 with a length field. However, since it still includes existing 332 Flowspec filtering for the outer and inner IP headers, the issues 333 addressed by this proposal still apply. 335 Author's Address 337 Jeffrey Haas 338 Juniper Networks 340 Email: jhaas@juniper.net