idnits 2.17.1 draft-khare-idr-bgp-flowspec-payload-match-08.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2021) is 1146 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) -- Looks like a reference, but probably isn't: '1' on line 477 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-16 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Khare, Ed. 3 Internet-Draft Ciena Corporation 4 Intended status: Standards Track P. Bergeon, Ed. 5 Expires: September 8, 2021 Nokia 6 V. Kestur 7 Juniper Networks, Inc. 8 L. Jalil 9 Verizon 10 K. Kasavchenko 11 March 7, 2021 13 BGP FlowSpec Payload Matching 14 draft-khare-idr-bgp-flowspec-payload-match-08 16 Abstract 18 The rise in frequency, volume, and pernicious effects of DDoS attacks 19 has elevated them from fare for the specialist to generalist press. 20 Numerous reports detail the taxonomy of DDoS attacks, the varying 21 motivations of their attackers, as well as the resulting impact for 22 their targets ranging from internet or business services to network 23 infrastrutures. 25 BGP FlowSpec (RFC 5575, "Dissemination of Flow Specification Rules") 26 can be used to rapidly disseminate filtering rules to mitigate 27 (distributed) denial-of-service (DoS) attacks. Operators can use 28 existing FlowSpec components to match typical n-tuple criteria in 29 pre-defined packet header fields such as IP protocol, IP prefix or 30 port number. Recent enhancements to IP Router forwarding plane 31 filter implementations also allow matches at arbitrary locations 32 within the packet header or payload. This capability can be used to 33 essentially match a signature for the attack traffic and can be 34 combined with traditional n-tuple filter criteria to mitigate 35 volumetric DDoS attacks and reduce false positive to a minimum. 37 To support this new filtering capability we define a new FlowSpec 38 component, "Flexible Match Conditions", with similar matching 39 semantics to those of existing components. This component will allow 40 the operator to define a new match condition using a combination of 41 offset and pattern values. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on September 8, 2021. 60 Copyright Notice 62 Copyright (c) 2021 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (https://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Definitions of Terms Used in This Memo . . . . . . . . . . . 3 79 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 3.1. Machine analysis of DDoS attacks . . . . . . . . . . . . 4 81 3.1.1. Matching based on payload . . . . . . . . . . . . . . 4 82 3.1.2. Matching based on any protocol header field or across 83 fields . . . . . . . . . . . . . . . . . . . . . . . 5 84 3.2. Tunneled traffic . . . . . . . . . . . . . . . . . . . . 5 85 3.3. Non-IP traffic . . . . . . . . . . . . . . . . . . . . . 5 86 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 87 4.1. Offset-type . . . . . . . . . . . . . . . . . . . . . . . 6 88 4.2. Offset-value . . . . . . . . . . . . . . . . . . . . . . 7 89 4.3. Pattern-type . . . . . . . . . . . . . . . . . . . . . . 7 90 4.4. Pattern-value . . . . . . . . . . . . . . . . . . . . . . 8 91 4.4.1. Bitmask match . . . . . . . . . . . . . . . . . . . . 8 92 4.4.2. Regular expression string match . . . . . . . . . . . 8 93 5. Flexible Match Conditions boundaries and additional 94 considerations . . . . . . . . . . . . . . . . . . . . . . . 8 95 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 9 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 101 10.2. Informative References . . . . . . . . . . . . . . . . . 10 102 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 105 1. Introduction 107 BGP FlowSpec [RFC5575] can be used to rapidly disseminate filtering 108 rules to mitigate (distributed) denial-of-service (DoS) attacks. 109 Operators can use existing FlowSpec components to match typical 110 n-tuple criteria in pre-defined packet header fields such as IP 111 protocol, IP prefix and port number. 113 Recent enhancements to IP Router forwarding plane filter 114 implementations also allow matches at arbitrary locations within the 115 packet header or payload. This capability can be used to essentially 116 match a signature for the attack traffic and can be combined with 117 traditional n-tuple filter criteria to mitigate volumetric DDoS 118 attacks and reduce false positive to a minimum. 120 To support this new filtering capability we define a new FlowSpec 121 component, "Flexible Match Conditions", with similar matching 122 semantics to those of existing components. This component will allow 123 the operator to define a new match condition using a combination of 124 offset and pattern values. 126 2. Definitions of Terms Used in This Memo 128 AFI - Address Family Identifier. 130 SAFI - Subsequent Address Family Identifier. 132 NLRI - Network Layer Reachability Information. 134 Flow specification controller - BGP speaker sending the flow 135 specification rules to the IP edge routers (e.g. DDoS 136 controllers). 138 Maximum Readable Length - The packet length in bits that a 139 forwarding implementation can parse and make available for 140 filtering. Abbreviated as MRL. 142 Maximum Pattern Length - The pattern length in bits that a 143 forwarding implementation can match against the packet header or 144 payload. Abbreviated as MPL. 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [RFC2119]. 150 3. Motivation 152 BGP FlowSpec couples both the advertisement of NLRI-specific match 153 conditions, as well as the forwarding instance to which the filter is 154 attached. This makes sense since BGP FlowSpec advertisements are 155 most commonly generated, or at least verified, by human operators. 156 The operator finds it intuitive to configure match conditions as 157 human-readable values, native to each address family. 159 It is much friendlier, for instance, to define a filter that matches 160 a source address of 192.168.1.1/32, than it is to work with the 161 equivalent binary representation of that IPv4 address. Further, it 162 is easier to use field names such as 'IPv4 source address' as part of 163 the match condition, than it is to demarc that field using byte and 164 bit offsets. 166 However, there are a number of use cases that benefit from the 167 latter, more machine-readable approach. 169 3.1. Machine analysis of DDoS attacks 171 Volumetric DDoS attacks can severely impact services and network 172 operator infrastructures but are also easily mitigated once 173 identified. The challenge lies in fishing out a generally unvarying 174 attack signature from a data stream. Machine analysis can be 175 particularly useful here given the size of input involved in order to 176 identify a pattern within the attack traffic flows. 178 Below we illustrate the need for the suggested approach with two use 179 cases. 181 3.1.1. Matching based on payload 183 Volumetric DDoS attacks can either directly send traffic to a target 184 or use reflection/amplification protocols to overload that target. 186 Reflection/amplification attacks are often identified by the UDP 187 source port of a service that reflects and amplifies the attack 188 traffic. However, blocking traffic based on source port can lead to 189 further service interruption and eventually complete the attack 190 especially in case of essential protocols such as NTP. There alo 191 exist DDoS attack methodologies such as SSDP Diffraction or BitTorent 192 amplification where values in most of layer 3 and layer 4 header 193 fields, including source and destination UDP ports, are varied. That 194 makes it challenging to mitigate based on existing Flow Specification 195 components. At the same time these attacks often have a constant 196 pattern in payload that can be used as matching criteria to further 197 mitigate such DDoS attacks. 199 Direct attacks may also use a constant pattern in payload which can 200 be used as a match criteria in filtering rules. 202 3.1.2. Matching based on any protocol header field or across fields 204 BGP FlowSpec [RFC5575] defines 12 Flow Specification component types 205 that can be used to match traffic. However, a DDoS attack might 206 result in illegitimate traffic with a specific pattern in a layer 3 207 or layer 4 header, and this pattern may not have a respective 208 FlowSpec component type defined. The flexible match patterns defined 209 in this document avoid extending BGP FlowSpec [RFC5575] with all 210 theoretically possible header fields and allow matching across fields 211 for any bitmask combinations. 213 3.2. Tunneled traffic 215 Tunnels continue to proliferate due to the benefits they provide. 216 They can help reduce state in the underlay network. Tunnels allow 217 bypassing routing decisions of the transit network. Traffic that is 218 tunneled is often done so to obscure or secure. Common tunnel types 219 include IPsec [RFC4301], Generic Routing Encapsulation (GRE) 220 [RFC2890], et al. 222 By definition, transit nodes that are not the endpoints of the tunnel 223 hold no attendant control or management plane state. These very 224 qualities make it challenging to filter tunneled traffic at non- 225 endpoints and it is usually infeasible to filter based on the content 226 of this passenger protocol's header since BGP FlowSpec does not 227 provide the operator a way to address arbitrary locations within a 228 packet. 230 3.3. Non-IP traffic 232 Not all traffic is forwarded as IP packets. Layer 2 services abound, 233 including flavors of BGP-signaled Ethernet VPNs such as BGP-EVPN, 234 BGP-VPLS, FEC 129 VPWS (LDP-signaled VPWS with BGP Auto-Discovery). 236 Ongoing efforts such as [I-D.ietf-idr-flowspec-l2vpn] offer one 237 approach, which is to add layer 2 fields as additional match 238 conditions. This may suffice if a filter needs to be applied only to 239 layer 2, or only to layer 3 header fields. 241 4. Specification 243 We define a new FlowSpec component, Type TBD, named "Flexible Match 244 Conditions". 246 Encoding: 248 The length is a one octet unsigned integer field that contains the 249 length of the value field in octets. 251 The value field itself is encoded using offset-type, offset-value, 252 pattern-type and pattern-value. 254 Encoding: 257 The value field is 0 padded for byte alignment. 259 4.1. Offset-type 261 The combination of offset-type and offset-value defines where the 262 match should begin for the pattern-value. This document defines the 263 following offset types: 265 +-------+--------------------------+ 266 | Value | Offset Type | 267 +-------+--------------------------+ 268 | 0 | Layer 3 - IP Header | 269 | 1 | Layer 4 - IP Header Data | 270 | 2 | Payload - TCP/UDP Data | 271 +-------+--------------------------+ 273 Offset Types 275 The offset-type 0 for 'layer 3' is defined as the start of the IP 276 header. 278 The offset-type 1 for 'layer 4' is defined as the start of the data 279 portion of the IP header after the IP options. 281 The offset-type 2 for 'payload' is defined as start of the TCP or UDP 282 data. For TCP, the offset-type payload represents the beginning of 283 the TCP data after any TCP options. Note that Flow Specification 284 NLRI using the Flexible Match Condition component with offset-type 2 285 will result in not matching the pattern value in this component in 286 case of non-first fragmented packet or in case it is combined with 287 component type 2 IP Protocol other than 6 (TCP) and 17 (UDP). 289 4.2. Offset-value 291 The offset-value is a 2 octets unsigned integer field defining the 292 number of bytes to ignore in the packet from the offset-type to match 293 the pattern value. 295 Examples: 297 - The combination of offset-type 0 (Layer 3) and offset-value 0 298 defines an offset at the very beginning of the IP header. 300 - The combination of offset-type 1 (Layer 4) and offset-value 2 301 defines an offset two bytes after the beginning of the data portion 302 of the IP header (after any IP options). Example, in the case of a 303 UDP packet, this offset defines the beginning of the destination port 304 header field. 306 - The combination of offset-type 2 (Payload) and offset-value 10 307 defines an offset ten bytes after the beginning of the TCP/UDP data 308 payload. 310 4.3. Pattern-type 312 The pattern-type defines how the pattern value is matched. The 313 following pattern-types are defined: 315 +-------+-----------------------------------------------+ 316 | Value | Pattern Type | 317 +-------+-----------------------------------------------+ 318 | 0 | Bitmask match | 319 | 1 | POSIX Regular expression (regex) string match | 320 | 2 | PCRE Regular expression (regex) string match | 321 +-------+-----------------------------------------------+ 323 Pattern Types 325 Pattern-type 0 MUST be implemented. 327 Pattern-type 1 and 2 for regular expressions are typically dedicated 328 to hardware-accelerated and software-only forwarding planes or 329 appliances that may be able to filter on more complex criteria. 330 There is a plethora of regular expression engines and their supported 331 flavor. The two flavors introduced in this document are: 333 o POSIX regular expression string match: This type refers to 334 extended regular expression (ERE) as defined by 335 [IEEE.1003-2.1992]. 337 o PCRE regular expression string match: This type refers to Perl 338 compatible regular expression as defined by PCRE documentation 339 [1]. 341 4.4. Pattern-value 343 4.4.1. Bitmask match 345 If the pattern-type bitmask is selected, the pattern-value is encoded 346 as {prefix, mask}, of equal length. 348 prefix - Provides a bit string to be matched. The prefix and mask 349 fields are bitwise AND'ed to create a resulting pattern. 351 mask - Paired with the prefix field to create a bit string match. 352 An unset bit is treated as a 'do not care' bit in the 353 corresponding position in the prefix field. When a bit is set in 354 the mask, the value of the bit in the corresponding location in 355 the prefix field must match exactly. 357 4.4.2. Regular expression string match 359 If a regular expression pattern-type is selected, the pattern-value 360 is encoded following the appropriate regular expression string match. 362 5. Flexible Match Conditions boundaries and additional considerations 364 The beginning of the match boundary is aligned with the FlowSpec AFI/ 365 SAFI to which the flexible match rule belongs. For instance, with 366 FlowSpec for IPv4 traffic, the smallest offset can only start at the 367 first bit of the IPv4 header. 369 The end of the match boundary MUST be the lesser of either the last 370 bit in a packet or the Maximum Readable Length (Section 2) that a 371 forwarding implementation can parse from a packet and make available 372 for filtering. As the MRL will be implementation-dependent, it needs 373 to be known to the Flow Specification controller. That can be 374 communicated out-of-band via configuration or signaled using future 375 BGP or IGP extensions. 377 The Maximum Pattern Length (Section 2) for the pattern-value can also 378 be forwarding implementation dependant and may need to be known to 379 the Flow Specification controller or communicated out-of-band. 381 It is not required that all nodes in a filtering domain have a common 382 or minimum MRL and MPL. This does not remove the need for a Flow 383 Specification controller to take MRL and MPL into account when 384 creating flexible filters. This can be useful if the Flow 385 Specification controller does not have direct BGP peering with all 386 FlowSpec enforcers and may not receive a BGP Notification if it 387 advertises a flexible match that exceeds the MRL or MPL of a given 388 node. 390 6. Error Handling 392 Malicious, misbehaving, or misunderstanding implementations could 393 advertise semantically incorrect values. Care must be taken to 394 minimize fallout from attempting to parse such data. Any well- 395 behaved implementation SHOULD verify that the minimum packet length 396 undergoing a match equals (match from the offset + pattern-value 397 length). 399 7. Security Considerations 401 This document introduces no additional security considerations beyond 402 those already covered in [RFC5575] . 404 8. IANA Considerations 406 IANA is requested to assign a type from the First Come First Served 407 range of the "Flow Spec Component Types" registry: 409 +------------+---------------------------+---------------+ 410 | Type Value | Name | Reference | 411 +------------+---------------------------+---------------+ 412 | TBD | Flexible Match Conditions | this document | 413 +------------+---------------------------+---------------+ 415 Reference: this document 417 Registry Owner/Change Controller: IESG 419 Registration procedures: 421 +---------+-------------------------+ 422 | Range | Registration Procedures | 423 +---------+-------------------------+ 424 | 0-127 | IETF Review | 425 | 128-249 | First Come First Served | 426 | 250-254 | Experimental | 427 | 255 | Reserved | 428 +---------+-------------------------+ 430 Note: a separate "owner" column is not provided because the owner of 431 all registrations, once made, is "IESG". 433 9. Acknowledgements 435 We wish to thank John Scudder, Michael Gallagher, Ron Bonica, Jeff 436 Haas, Sudipto Nandi, Brian St Pierre and Rafal Jan Szarecki for their 437 valuable comments and suggestions on this document. 439 10. References 441 10.1. Normative References 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, 445 DOI 10.17487/RFC2119, March 1997, 446 . 448 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 449 and D. McPherson, "Dissemination of Flow Specification 450 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 451 . 453 10.2. Informative References 455 [I-D.ietf-idr-flowspec-l2vpn] 456 Weiguo, H., Eastlake, D., Litkowski, S., and S. Zhuang, 457 "BGP Dissemination of L2 Flow Specification Rules", draft- 458 ietf-idr-flowspec-l2vpn-16 (work in progress), November 459 2020. 461 [IEEE.1003-2.1992] 462 Institute of Electrical and Electronics Engineers, 463 "Information Technology - Portable Operating System 464 Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", 465 IEEE Standard 1003.2, 1992. 467 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 468 RFC 2890, DOI 10.17487/RFC2890, September 2000, 469 . 471 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 472 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 473 December 2005, . 475 10.3. URIs 477 [1] https://www.pcre.org/original/pcre.txt 479 Authors' Addresses 481 Anurag Khare (editor) 482 Ciena Corporation 484 Email: ak@ciena.com 486 Philippe Bergeon (editor) 487 Nokia 488 600 March Road 489 Ottawa, Ontario K2K2E6 490 CA 492 Email: philippe.bergeon@nokia.com 494 Vijay Kestur 495 Juniper Networks, Inc. 497 Email: vkestur@juniper.net 499 Luay Jalil 500 Verizon 502 Email: luay.jalil@one.verizon.com 504 Kirill Kasavchenko 506 Email: kkasavchenko.mail@gmail.com