idnits 2.17.1 draft-khare-idr-bgp-flowspec-payload-match-03.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 (May 1, 2019) is 1819 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 502 -- Looks like a reference, but probably isn't: '2' on line 504 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-09 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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 J. Scudder 4 Intended status: Standards Track Juniper Networks, Inc. 5 Expires: November 2, 2019 L. Jalil 6 M. Gallagher 7 Verizon 8 K. Kasavchenko 9 NetScout 10 May 1, 2019 12 BGP FlowSpec Payload Matching 13 draft-khare-idr-bgp-flowspec-payload-match-03 15 Abstract 17 The rise in frequency, volume, and pernicious effects of DDoS attacks 18 has elevated them from fare for the specialist to generalist press. 19 Numerous reports detail the taxonomy of DDoS types, the varying 20 motivations of their attackers, as well as the resulting business and 21 reputation loss of their targets. 23 BGP FlowSpec (RFC 5575, "Dissemination of Flow Specification Rules") 24 can be used to rapidly disseminate filters that thwart attacks, being 25 particularly effective against the volumetric type. Operators can 26 use existing FlowSpec components to match on pre-defined packet 27 header fields. However recent enhancements to forwarding plane 28 filter implementations allow matches at arbitary locations within the 29 packet header and, to some extent, the payload. This capability can 30 be used to detect highly amplified attacks whose attack signature 31 remains relatively constant while values in the packet header vary, 32 as well as the burgeoning variety of tunneled traffic. 34 We define a new FlowSpec component, "Flexible Match Conditions", with 35 similar matching semantics to those of existing components. This 36 component will allow the operator to define bounded match conditions 37 using bit offsets and a variety of match types. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on November 2, 2019. 56 Copyright Notice 58 Copyright (c) 2019 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 75 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2.1. Machine analysis of DDoS attacks . . . . . . . . . . . . 4 77 2.1.1. Matching based on payload . . . . . . . . . . . . . . 4 78 2.1.2. Matching based on any protocol header field or across 79 fields . . . . . . . . . . . . . . . . . . . . . . . 4 80 2.2. Tunneled traffic . . . . . . . . . . . . . . . . . . . . 5 81 2.3. Non-IP traffic . . . . . . . . . . . . . . . . . . . . . 5 82 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 4. Defining the Search Boundary . . . . . . . . . . . . . . . . 6 84 4.1. Defining the Start of the Boundary . . . . . . . . . . . 6 85 4.2. Defining the End of the Boundary . . . . . . . . . . . . 7 86 5. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8 87 5.1. Value . . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 5.1.1. Match Boundary . . . . . . . . . . . . . . . . . . . 8 89 5.1.2. Match Type . . . . . . . . . . . . . . . . . . . . . 8 90 5.1.2.1. Bitmask match . . . . . . . . . . . . . . . . . . 9 91 5.1.2.2. Numeric range match . . . . . . . . . . . . . . . 9 92 5.1.2.3. ASCII-only regular expression string match . . . 9 93 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 9 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 99 10.2. Informative References . . . . . . . . . . . . . . . . . 10 100 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 103 1. Introduction 105 BGP FlowSpec [RFC5575] can be used to rapidly disseminate filters 106 that thwart attacks, being particularly effective against the 107 volumetric type. Operators can use existing FlowSpec components to 108 match on pre-defined packet header fields. However recent 109 enhancements to forwarding plane filter implementations allow matches 110 at arbitary locations within the packet header and, to some extent, 111 the payload. This capability can be used to detect highly amplified 112 attacks whose attack signature remains relatively constant, while 113 values in packet header vary. Varying values in packet headers 114 generally make it challenging to mitigate such attacks. 116 We define a new FlowSpec component, "Flexible Match Conditions", with 117 similar matching semantics to those of existing components. This 118 component will allow the operator to define bounded match conditions 119 using bit offsets and a variety of match types. 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2. Motivation 129 BGP FlowSpec couples both the advertisement of NLRI-specific match 130 conditions, as well as the forwarding instance to which the filter is 131 attached. This makes sense since BGP FlowSpec advertisements are 132 most commonly generated, or at least verified, by human operators. 133 The operator finds it intuitive to configure match conditions as 134 human-readable values, native to each address family. 136 It is much friendlier, for instance, to define a filter that matches 137 a source address of 192.168.1.1/32, than it is to work with the 138 equivalent binary representation of that IPv4 address. Further, it 139 is easier to use field names such as 'IPv4 source address' as part of 140 the match condition, than it is to demarc that field using byte and 141 bit offsets. 143 However, there are a number of use cases that benefit from the 144 latter, more machine-readable approach. 146 2.1. Machine analysis of DDoS attacks 148 Launching a DDoS is easier and more cost-effective than ever. The 149 will to attack matters more than wherewithal. Those with the 150 inclination can initiate one from the comfort of their homes [1], or 151 even buy DDoS-as-a-Service [2], complete with 24x7 support and 152 flexible payment plans. 154 Despite their effectiveness, such attacks are easily thwarted - once 155 identified. The challenge lies in fishing out a generally unvarying 156 attack signature from a data stream. Machine analysis may prove 157 superior here, given the size of input involved. The resulting 158 pattern may not lie within a well-defined field; even if it happens 159 to, it may be a more straight-forward workflow to have machine 160 analysis result in a machine-readable filter. 162 Below we illustrate the need for the suggested approach with two use 163 cases. 165 2.1.1. Matching based on payload 167 A vast majority of volumetric DDoS attacks are of reflection/ 168 amplification nature. They can often be identified by the UDP source 169 port of a service that reflects and amplifies the attack traffic. 170 However, there exist DDoS attack methodologies such as SSDP 171 Diffraction or Bittorent amplification where values in most of layer 172 3 and layer 4 header fields, including source and destination UDP 173 ports, are varied. That makes it challenging if not impossible to 174 classify and mitigate a DDoS attack based on existing Flow 175 Specification components. At the same time these attacks very often 176 have a constant pattern in payload. Using the pattern in payload as 177 a matching criteria would help in mitigating such DDoS attacks. 179 2.1.2. Matching based on any protocol header field or across fields 181 BGP FlowSpec [RFC5575] defines 12 Flow Specification component types 182 that can be used to match traffic. However, a DDoS attack might 183 result in illegitimate traffic of a specific pattern in a layer 3 or 184 layer 4 header, and this pattern would not have a respective 185 component type. Examples are Time to Live field of IP header or 186 Window field of TCP header. In order to avoid extending BGP FlowSpec 187 [RFC5575] with all theoretically possible component types, this 188 document proposes divorcing the search boundary from having to align 189 with header fields. This allows flexibly matching patterns 190 regardless of whether they have a currently matching component type 191 as well as patterns that span fields. 193 2.2. Tunneled traffic 195 Tunnels continue to proliferate due to the benefits they provide. 196 They can help reduce state in the underlay network. Tunnels allow 197 bypassing routing decisions of the transit network. Traffic that is 198 tunneled is often done so to obscure or secure. Common tunnel types 199 include IPsec [RFC4301], Generic Routing Encapsulation (GRE) 200 [RFC2890], Virtual eXtensible Local Area Network (VXLAN) [RFC7348], 201 GPRS Tunneling Protocol (GTP) [GTPv1-U], et al. 203 By definition, transit nodes that are not the endpoints of the tunnel 204 hold no attendant control or management plane state. These very 205 qualities make it challenging to filter tunneled traffic at non- 206 endpoints. Often though, the forwarding hardware at these transit- 207 only nodes is capable of reading the byte stream that comprises the 208 protocol being tunneled. Despite this capability, it is usually 209 infeasible to filter based on the content of this passenger 210 protocol's header since BGP FlowSpec does not provide the operator a 211 way to address arbitrary locations within a packet. 213 2.3. Non-IP traffic 215 Not all traffic is forwarded as IP packets. Layer 2 services abound, 216 including flavors of BGP-signaled Ethernet VPNs such as BGP-EVPN, 217 BGP-VPLS, FEC 129 VPWS (LDP-signaled VPWS with BGP Auto-Discovery). 219 Ongoing efforts such as [I-D.ietf-idr-flowspec-l2vpn] offer one 220 approach, which is to add layer 2 fields as additional match 221 conditions. This may suffice if a filter needs to be applied only to 222 layer 2, or only to layer 3 header fields. 224 3. Terminology 226 Header Subset of datagram or packet that contains information that 227 is required for delivery from source to destination. 229 Payload Remaining subset of datagram or packet that contains the 230 information that is being transported. 232 Field A priori defined subset of the header with established 233 semantics, acceptable value type and length. 235 Type How the encoded bits that comprise a field are interpreted. A 236 well-defined type can be used to enforce notions of ordering, 237 upper and lower bounds, and correctness. For instance, using a 238 signed integer type to count the number of packets received by a 239 given forwarding element could result in negative values. To 240 avoid that, the field should be typed as a zero-based counter. 242 In order to avoid premature rollover, the counter should be sized 243 appropriately. To prevent retrogression, the values should 244 always be accumulated as it is impossible to receive fewer 245 packets in toto. Defining this example field as an unsigned 246 64-bit field with monotonically incrementing values ensure it 247 meets the appropriate objectives. 249 Maximum Readable Length The packet length in bits that a forwarding 250 implementation can parse and make available for filtering. 251 Abbreviated as MRL. 253 4. Defining the Search Boundary 255 Based on this set of definitions, the flexible match operator 256 requires three inputs to demarcate the search extents and the search 257 term itself: 259 o Where the match should begin: Where in the datagram or packet the 260 search for matching values is initiated. This allows skipping 261 over parts of the packet that are not of interest. 263 o Where the match should end: Where in the datagram or packet the 264 search ends. 266 o What should be matched: A variety of search types, including exact 267 numeric matches, matching a range of numeric values, and string- 268 based matches. 270 4.1. Defining the Start of the Boundary 272 While intuitive to grasp, determining the search boundary requires 273 explication. A canonical forwarding engine parses an incoming packet 274 header and identifies it as belonging to a single Network Layer 275 Reachability Information (NLRI), or address family. The contents of 276 the header are parsed with address family specificity, in order to 277 extract a forwarding lookup key. In the case of IPv4 unicast 278 forwarding, this key is the IPv4 destination address. The key is 279 used to look up the corresponding action in an address family 280 specific forwarding table. 282 This does not preclude implementations from exposing additional 283 packet headers to the operator, both encapsulating and encapsulated, 284 to provide additional forwarding functionality. For instance, common 285 stateless load balancing techniques involve reading fields in 286 additional headers in order to increase entropy and preserve flow 287 ordering. As another example, in the case of Ethernet encapsulated 288 IPv4 packets, a forwarding engine could allow filtering using the 289 source or destination MAC address even though the forwarding decision 290 is ultimately based only on the IPv4 header. 292 As yet another example, consider that a Virtual eXtensible Local Area 293 Network (VXLAN) [RFC7348] packet has the following headers: 295 o Outer Ethernet Header: Source MAC address of the originating VXLAN 296 Tunnel End Point (VTEP). - Outer IPv4/IPv6 Header: Source IP 297 address of the originating VXLAN Tunnel End Point (VTEP). 299 o Outer UDP Header: Random source port used to generate entropy for 300 load balancing, and destined to the IANA-assigned VXLAN port 4789. 302 o VXLAN Header: Used to identify a specific VXLAN overlay network. 304 o Inner Ethernet Header and payload: Original MAC frame 305 encapsulated. 307 Forwarding at the tunnel midpoints, i.e., not the where tunnel 308 imposition or disposition occur, makes use of the outer IPv4 header. 309 In order to differentiate itself, a midpoint may provide the ability 310 to parse and take the VXLAN header into account. This functionality 311 could be used to implement access control or perform traffic 312 telemetry. 314 In order to normalize behavior across forwarding implementations, the 315 beginning of the search space MUST be aligned with the FlowSpec AFI/ 316 SAFI to which the flexible match rule belongs. For instance, with 317 FlowSpec for IPv4 traffic, the match can only start at the first bit 318 of the IPv4 header. Even if the forwarding implementation has the 319 capability to read outer and inner headers, the start of the search 320 extent is anchored at the IPv4 header. 322 4.2. Defining the End of the Boundary 324 Similarly, the end of the search boundary MUST be the lesser of 325 either the last bit in a packet or the Maximum Readable Length 326 (Section 3) that a forwarding implementation can parse from a packet 327 and make available for filtering. As the MRL will be implementation- 328 dependent, it needs to be known to the flexible filtering rules 329 engine. That can be communicated out-of-band via configuration or 330 signaled using future BGP or IGP extensions. 332 It is not required that all nodes in a flexible filtering domain be 333 required to have a common or minimum MRL. This does not obviate the 334 need for a rules engine to take MRL into account when creating 335 flexible filters. This is especially important as the rules engine 336 may not have direct BGP peering with all FlowSpec enforcers and may 337 not receive a BGP Notification if it advertises a flexible match that 338 exceeds the MRL of a given node. 340 5. Specification 342 We define a new FlowSpec component, Type TBD, named "Flexible Match 343 Conditions". 345 Encoding: 347 5.1. Value 349 The Value field contains the match boundary, match type, and term to 350 match. 352 Encoding: 355 5.1.1. Match Boundary 357 The match boundary is encoded as: 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 |u|bit o| byte offset | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 u - Currently unused. MUST be zero. 365 bit offset - The number of bits to ignore in the packet being 366 matched, from the start of the search boundary. 368 byte offset - The number of bytes to ignore. 370 5.1.2. Match Type 372 Currently the following match types are defined: 374 +-------+-----------------------------------------+ 375 | Value | Match Type | 376 +-------+-----------------------------------------+ 377 | 0 | Bitmask match | 378 | 1 | Numeric range match | 379 | 2 | Regular expression (regex) string match | 380 +-------+-----------------------------------------+ 382 Match Types 384 Match types 0 and 1 MUST be implemented. All other types are 385 optional. 387 5.1.2.1. Bitmask match 389 This is encoded as {prefix, mask}, of equal length. 391 prefix - Provides a bit string to be matched. The prefix and mask 392 fields are bitwise AND'ed to create a resulting pattern. 394 mask - Paired with the prefix field to create a bit string match. 395 An unset bit is treated as a 'do not care' bit in the 396 corresponding position in the prefix field. When a bit is set in 397 the mask, the value of the bit in the corresponding location in 398 the prefix field must match exactly. 400 5.1.2.2. Numeric range match 402 This is encoded as {low value, high value}, treated as an inclusive 403 range. 405 low - The low value of the desired numeric range. This value MUST 406 be numerically lower than the high value. 408 high - The high value of the desired numeric range. This value MUST 409 be numerically higher than the low value. 411 5.1.2.3. ASCII-only regular expression string match 413 Not every forwarding plane that supports filtering via FlowSpec is a 414 hardware-accelerated Network Processor Unit (NPU) or Application- 415 Specific Integrated Circuit (ASIC). Software-only forwarding planes, 416 while less performant, may be able to filter on more complex match 417 types. 419 There is a plethora of regular expression engines and their supported 420 flavor. The specific flavor this match type refers to is the 421 extended regular expression (ERE) as defined by [IEEE.1003-2.1992]. 423 6. Error Handling 425 Malicious, misbehaving, or misunderstanding implementations could 426 advertise semantically incorrect values. Care must be taken to 427 minimize fallout from attempting to parse such data. Any well- 428 behaved implementation SHOULD verify that the minimum packet length 429 undergoing a match equals (match start header length + byte offset + 430 bit offset + value length). 432 7. Security Considerations 434 This document introduces no additional security considerations beyond 435 those already covered in [RFC5575] . 437 8. IANA Considerations 439 IANA is requested to assign a type from the First Come First Served 440 range of the "Flow Spec Component Types" registry: 442 +------------+---------------------------+---------------+ 443 | Type Value | Name | Reference | 444 +------------+---------------------------+---------------+ 445 | TBD | Flexible Match Conditions | this document | 446 +------------+---------------------------+---------------+ 448 9. Acknowledgements 450 Thanks to Rafal Jan Szarecki, Sudipto Nandi, Ron Bonica, and Jeff 451 Haas for their valuable comments and suggestions on this document. 453 10. References 455 10.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, 459 DOI 10.17487/RFC2119, March 1997, 460 . 462 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 463 and D. McPherson, "Dissemination of Flow Specification 464 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 465 . 467 10.2. Informative References 469 [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling 470 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 471 September 2011. 473 [I-D.ietf-idr-flowspec-l2vpn] 474 Weiguo, H., Eastlake, D., Uttaro, J., Litkowski, S., and 475 S. Zhuang, "BGP Dissemination of L2VPN Flow Specification 476 Rules", draft-ietf-idr-flowspec-l2vpn-09 (work in 477 progress), January 2019. 479 [IEEE.1003-2.1992] 480 Institute of Electrical and Electronics Engineers, 481 "Information Technology - Portable Operating System 482 Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", 483 IEEE Standard 1003.2, 1992. 485 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 486 RFC 2890, DOI 10.17487/RFC2890, September 2000, 487 . 489 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 490 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 491 December 2005, . 493 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 494 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 495 eXtensible Local Area Network (VXLAN): A Framework for 496 Overlaying Virtualized Layer 2 Networks over Layer 3 497 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 498 . 500 10.3. URIs 502 [1] https://github.com/649/Memcrashed-DDoS-Exploit 504 [2] https://www.facebook.com/PutinStresser/photos/ 505 a.1687498801469198/2024483917770683/?type=3 507 Authors' Addresses 509 Anurag Khare (editor) 510 Juniper Networks, Inc. 511 2251 Corporate Park Drive 512 Herndon, Virginia 20171 513 US 515 Email: anuragk@juniper.net 517 John Scudder 518 Juniper Networks, Inc. 519 1133 Innovation Way 520 Sunnyvale, CA 94089 521 US 523 Email: jgs@juniper.net 524 Luay Jalil 525 Verizon 527 Email: luay.jalil@one.verizon.com 529 Michael Gallagher 530 Verizon 532 Email: michael.gallagher@verizon.com 534 Kirill Kasavchenko 535 NetScout 537 Email: Kirill.Kasavchenko@netscout.com