idnits 2.17.1 draft-khare-idr-bgp-flowspec-payload-match-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 : ---------------------------------------------------------------------------- == 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 (November 5, 2018) is 1993 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 416 -- Looks like a reference, but probably isn't: '2' on line 418 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-08 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: May 9, 2019 L. Jalil 6 M. Gallagher 7 Verizon 8 November 5, 2018 10 BGP FlowSpec Payload Matching 11 draft-khare-idr-bgp-flowspec-payload-match-02 13 Abstract 15 The rise in frequency, volume, and pernicious effects of DDoS attacks 16 has elevated them from fare for the specialist to generalist press. 17 Numerous reports detail the taxonomy of DDoS types, the varying 18 motivations of their attackers, as well as the resulting business and 19 reputation loss of their targets. 21 BGP FlowSpec (RFC 5575, "Dissemination of Flow Specification Rules") 22 can be used to rapidly disseminate filters that thwart attacks, being 23 particularly effective against the volumetric type. Operators can 24 use existing FlowSpec components to match on pre-defined packet 25 header fields. However recent enhancements to forwarding plane 26 filter implementations allow matches at arbitary locations within the 27 packet header and, to some extent, the payload. This capability can 28 be used to detect highly amplified attacks, whose attack signature 29 remains relatively constant. 31 We define a new FlowSpec component, "Flexible Match Conditions", with 32 similar matching semantics to those of existing components. This 33 component will allow the operator to define bounded match conditions 34 using offsets and bitmasks. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 9, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 72 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2.1. Volumetric attacks . . . . . . . . . . . . . . . . . . . 3 74 2.2. Tunneled traffic . . . . . . . . . . . . . . . . . . . . 4 75 2.3. Non-IP traffic . . . . . . . . . . . . . . . . . . . . . 4 76 3. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.1. Flexible Match Conditions . . . . . . . . . . . . . . . . 5 78 3.1.1. Operator . . . . . . . . . . . . . . . . . . . . . . 5 79 3.1.2. Value . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.1.2.1. String Comparison . . . . . . . . . . . . . . . . 6 81 3.1.2.2. Numeric Range Comparison . . . . . . . . . . . . 7 82 3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 7 83 3.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 84 3.3. Security Considerations . . . . . . . . . . . . . . . . . 8 85 3.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 8 86 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 87 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 89 5.2. Informative References . . . . . . . . . . . . . . . . . 9 90 5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 93 1. Introduction 95 BGP FlowSpec [RFC5575] can be used to rapidly disseminate filters 96 that thwart attacks, being particularly effective against the 97 volumetric type. Operators can use existing FlowSpec components to 98 match on pre-defined packet header fields. However recent 99 enhancements to forwarding plane filter implementations allow matches 100 at arbitary locations within the packet header and, to some extent, 101 the payload. This capability can be used to detect highly amplified 102 attacks whose attack signature remains relatively constant, or the 103 burgeoning variety of tunneled traffic. 105 We define a new FlowSpec component, "Flexible Match Conditions", with 106 similar matching semantics to those of existing components. This 107 component will allow the operator to define bounded match conditions 108 using offsets and bitmasks. 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119] . 116 2. Motivation 118 BGP FlowSpec couples both the advertisement of NLRI-specific match 119 conditions, as well as the forwarding instance to which the filter is 120 attached. This makes sense since BGP FlowSpec advertisements are 121 most commonly generated, or at least verified, by human operators. 122 The operator finds it intuitive to configure match conditions as 123 human-readable values, native to each address family. 125 It is much friendlier, for instance, to define a filter that matches 126 a source address of 192.168.1.1/32, than it is to work with the 127 equivalent binary representation of that IPv4 address. Further, it 128 is easier to use field names such as 'IPv4 source address' as part of 129 the match condition, than it is to demarc that field using byte and 130 bit offsets. 132 However, there are a number of use cases that benefit from the 133 latter, more machine-readable approach. 135 2.1. Volumetric attacks 137 Launching a DDoS is easier and more cost-effective than ever. The 138 will to attack matters more than wherewithal. Those with the 139 inclination can initiate one from the comfort of their homes [1], or 140 even buy DDoS-as-a-Service [2], complete with 24x7 support and 141 flexible payment plans. 143 Despite their effectiveness, such attacks are easily thwarted - once 144 identified. The challenge lies in fishing out a generally unvarying 145 attack signature from a data stream. Machine analysis may prove 146 superior here, given the size of input involved. The resulting 147 pattern may not lie within a well-defined field; even if it happens 148 to, it may be a more straight-forward workflow to have machine 149 analysis result in a machine-readable filter. 151 2.2. Tunneled traffic 153 Tunnels continue to proliferate due to the benefits they provide. 154 They can help reduce state in the underlay network. Tunnels allow 155 bypassing routing decisions of the transit network. Traffic that is 156 tunneled is often done so to obscure or secure. Common tunnel types 157 include IPsec [RFC4301], Generic Routing Encapsulation (GRE) 158 [RFC2890], Virtual eXtensible Local Area Network (VXLAN) [RFC7348], 159 GPRS Tunneling Protocol (GTP) [3GPP.29.281], et al. 161 By definition, transit nodes that are not the endpoints of the tunnel 162 hold no attendant control or management plane state. These very 163 qualities make it challenging to filter tunneled traffic at non- 164 endpoints. Often though, the forwarding hardware at these transit- 165 only nodes is capable of reading the byte stream that comprises the 166 protocol being tunneled. Despite this capability, it is usually 167 infeasible to filter based on the content of this passenger 168 protocol's header since BGP FlowSpec does not provide the operator a 169 way to address arbitrary locations within a packet. 171 2.3. Non-IP traffic 173 Not all traffic is forwarded as IP packets. Layer 2 services abound, 174 including flavors of BGP-signaled Ethernet VPNs such as BGP-EVPN, 175 BGP-VPLS, FEC 129 VPWS (LDP-signaled VPWS with BGP Auto-Discovery). 177 Ongoing efforts such as [I-D.ietf-idr-flowspec-l2vpn] offer one 178 approach, which is to add layer 2 fields as additional match 179 conditions. This may suffice if a filter needs to be applied only to 180 layer 2, or only to layer 3 header fields. 182 3. Details 183 3.1. Flexible Match Conditions 185 We define a new FlowSpec component, Type TBD, named "Flexible Match 186 Conditions". 188 Encoding: 190 It contains a single {operator, value} tuple that is used to match 191 packets according to the rules given below. 193 3.1.1. Operator 195 The operator field is encoded as: 197 0 1 198 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 |v| a |u |bit o| byte offset | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 v - Type of value being matched, string comparison (Section 3.1.2.1) 204 if this bit is set, and numeric range (Section 3.1.2.2) if unset. 206 a - Anchor. A 2-bit unsigned integer whose value indicates where in 207 the packet the match should start. To avoid ambiguity with 208 tunneled packets, the match SHOULD be anchored at the outermost 209 header. An example is given below (Section 3.1.3). 211 +-------+---------------+-------------------------------------------+ 212 | Value | Symbolic Name | Match start | 213 +-------+---------------+-------------------------------------------+ 214 | 0 | d | Layer 2 (d)ata-link layer Ethernet header | 215 | 1 | i | Layer 3 (I)Pv4/IPv6 header | 216 | 2 | t | Layer 4 TCP/UDP (t)ransport header | 217 | 3 | p | Layer 4-specific (p)rotocol-specific | 218 | | | payload | 219 +-------+---------------+-------------------------------------------+ 221 Anchor Field Values 223 u - Reserved. MUST be set to 0. MUST be ignored on receipt. 225 bit offset - A 3-bit unsigned integer indicating how many bits to 226 ignore, following the byte offset. 228 byte offset - An 8-bit unsigned integer indicating how many bytes to 229 ignore, after the match start as determined by the first selected 230 anchor bit. 232 3.1.2. Value 234 The operator field indicates where to start matching; by contrast, 235 the value operand indicates what to match and where to stop matching. 236 The value operand MUST be of the type indicated by the 'v' bit, as 237 signaled in the operator. As a result it can take on one of two 238 forms - string vs. numeric range comparison. 240 The length of the numeric range is constant. It uses two 64-bit 241 fields. A string comparison uses two 128-bit fields. Its length 242 field indicates the extent of how much of the prefix and mask fields 243 to use in the AND operation. This is deemed sufficient for stateless 244 inspection and practical for efficient hardware forwarding plane 245 implementations. 247 3.1.2.1. String Comparison 249 0 1 2 3 250 0 1 2 3 251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | len | reserved | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | 256 + + 257 | | 258 + prefix + 259 | | 260 + + 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 + + 265 | | 266 + mask + 267 | | 268 + + 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 len - Indicates the number of corresponding bits in the prefix and 273 mask fields to read. This length field is interpreted as 274 (len + 1 << 1). This allows even unsigned values ranging 275 from 2-128. 277 prefix - Provides a bit string to be matched. The prefix and mask 278 fields are bitwise AND'ed to create a resulting pattern. 279 The number of bits used in the AND operation are indicated 280 by the preceding length field. 282 mask - Paired with the prefix field to create a bit string match. 283 An unset bit is treated as a 'do not care' bit in the 284 corresponding position in the prefix field. When a bit is 285 set in the mask, the value of the bit in the corresponding 286 location in the prefix field must match exactly. 288 Implementations MUST only extract the number of bits from the prefix 289 and mask fields as indicated by the preceding length field. 291 3.1.2.2. Numeric Range Comparison 293 0 1 2 3 294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 + low + 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 + high + 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 low - The low value of the desired inclusive numeric range. This 306 value MUST be numerically lower than the high value. 308 high - The high value of the desired inclusive numeric range. This 309 value MUST be numerically higher than the low value. 311 3.1.3. Example 313 As an example, consider that the canonical Virtual eXtensible Local 314 Area Network (VXLAN) [RFC7348] packet has the following headers: 316 o Outer Ethernet Header: Source MAC address of the originating VXLAN 317 Tunnel End Point (VTEP). 319 o Outer IPv4/IPv6 Header: Source IP address of the originating VXLAN 320 Tunnel End Point (VTEP). 322 o Outer UDP Header: Random source port used to generate entropy for 323 load balancing, and destined to the IANA-assigned VXLAN port 4789. 325 o VXLAN Header: Used to identify a specific VXLAN overlay network. 327 o Inner Ethernet Header and payload: Original MAC frame being 328 encapsulated. 330 The following table outlines where the match would start based on the 331 anchor setting: 333 +--------------+------------------------+ 334 | Anchor value | Match start | 335 +--------------+------------------------+ 336 | d | Outer Ethernet Header | 337 | i | Outer IPv4/IPv6 Header | 338 | t | Outer UDP Header | 339 | p | VXLAN Header | 340 +--------------+------------------------+ 342 3.2. Error Handling 344 Malicious, misbehaving, or misunderstanding implementations could 345 advertise semantically incorrect values. Care must be taken to 346 minimize fallout from attempting to parse such data. Any well- 347 behaved implementation SHOULD verify that the minimum packet length 348 undergoing a match equals (match start header length + byte offset + 349 bit offset + value length). 351 3.3. Security Considerations 353 This document introduces no additional security considerations beyond 354 those already covered in [RFC5575] . 356 3.4. IANA Considerations 358 IANA is requested to assign a type from the First Come First Served 359 range of the "Flow Spec Component Types" registry: 361 +------------+---------------------------+---------------+ 362 | Type Value | Name | Reference | 363 +------------+---------------------------+---------------+ 364 | TBD | Flexible Match Conditions | this document | 365 +------------+---------------------------+---------------+ 367 4. Acknowledgements 369 Thanks to Rafal Jan Szarecki, Sudipto Nandi, Ron Bonica, and Jeff 370 Haas for their valuable comments and suggestions on this document. 372 5. References 374 5.1. Normative References 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, 378 DOI 10.17487/RFC2119, March 1997, 379 . 381 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 382 and D. McPherson, "Dissemination of Flow Specification 383 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 384 . 386 5.2. Informative References 388 [3GPP.29.281] 389 3GPP, "General Packet Radio System (GPRS) Tunnelling 390 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 391 September 2011. 393 [I-D.ietf-idr-flowspec-l2vpn] 394 Weiguo, H., liangqiandeng, l., Uttaro, J., Litkowski, S., 395 and S. Zhuang, "Dissemination of Flow Specification Rules 396 for L2 VPN", draft-ietf-idr-flowspec-l2vpn-08 (work in 397 progress), July 2018. 399 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 400 RFC 2890, DOI 10.17487/RFC2890, September 2000, 401 . 403 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 404 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 405 December 2005, . 407 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 408 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 409 eXtensible Local Area Network (VXLAN): A Framework for 410 Overlaying Virtualized Layer 2 Networks over Layer 3 411 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 412 . 414 5.3. URIs 416 [1] https://github.com/649/Memcrashed-DDoS-Exploit 418 [2] https://www.facebook.com/PutinStresser/photos/ 419 a.1687498801469198/2024483917770683/?type=3 421 Authors' Addresses 423 Anurag Khare (editor) 424 Juniper Networks, Inc. 425 2251 Corporate Park Drive 426 Herndon, Virginia 20171 427 US 429 Email: anuragk@juniper.net 431 John Scudder 432 Juniper Networks, Inc. 433 1133 Innovation Way 434 Sunnyvale, CA 94089 435 US 437 Email: jgs@juniper.net 439 Luay Jalil 440 Verizon 442 Email: luay.jalil@one.verizon.com 444 Michael Gallagher 445 Verizon 447 Email: michael.gallagher@verizon.com