idnits 2.17.1 draft-ietf-idr-flowspec-nvo3-14.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 date (August 15, 2021) is 982 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) ** Downref: Normative reference to an Informational RFC: RFC 7348 ** Downref: Normative reference to an Informational RFC: RFC 7637 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Eastlake 2 Intended Status: Proposed Standard Futurewei Technologies 3 W. Hao 4 S. Zhuang 5 Z. Li 6 Huawei Technologies 7 R. Gu 8 China Mobile 9 Expires: February 14, 2022 August 15, 2021 11 BGP Dissemination of 12 Flow Specification Rules for Tunneled Traffic 13 draft-ietf-idr-flowspec-nvo3-14 15 Abstract 16 This draft specifies a Border Gateway Protocol (BGP) Network Layer 17 Reachability Information (NLRI) encoding format for flow 18 specifications (RFC 8955) that can match on a variety of tunneled 19 traffic. In addition, flow specification components are specified for 20 certain tunneling header fields. 22 Status of This Document 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Distribution of this document is unlimited. Comments should be sent 28 to the authors or the IDR Working Group mailing list . 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at 43 https://www.ietf.org/shadow.html. 45 Table of Contents 47 1. Introduction............................................3 48 1.1 Terminology............................................3 50 2. Tunneled Traffic Flow Specification NLRI................5 51 2.1 The SAFI Code Point....................................7 52 2.2 Tunnel Header Component Code Points....................7 53 2.3 Specific Tunnel Types..................................9 54 2.3.1 VXLAN................................................9 55 2.3.2 VXLAN-GPE...........................................10 56 2.3.3 NVGRE...............................................11 57 2.3.4 L2TPv3..............................................11 58 2.3.4.1 L2TPv3 Data Messages..............................12 59 2.3.4.2 L2TPv3 Control Messages...........................12 60 2.3.5 GRE.................................................12 61 2.3.6 IP-in-IP............................................13 62 2.3.7 Geneve..............................................14 63 2.4 Tunneled Traffic Actions..............................14 65 3. Order of Traffic Filtering Rules.......................15 66 4. Flow Spec Validation...................................16 68 5. Security Considerations................................16 69 6. IANA Considerations....................................17 71 Normative References......................................18 72 Informative References....................................19 74 Acknowledgments...........................................20 75 Authors' Addresses........................................20 77 1. Introduction 79 BGP Flow Specification (flowspec [RFC8955]) is an extension to BGP 80 that supports the dissemination of traffic flow specification rules. 81 It uses the BGP control plane to simplify the distribution of Access 82 Control Lists (ACLs) and allows new filter rules to be injected to 83 all BGP peers simultaneously without changing router configuration. A 84 typical application of BGP flowspec is to automate the distribution 85 of traffic filter lists to routers for Distributed Denial of Service 86 (DDOS) mitigation. 88 BGP flowspec defines BGP Network Layer Reachability Information 89 (NLRI) formats used to distribute traffic flow specification rules. 90 AFI=1/SAFI=133 is for IPv4 unicast filtering. AFI=1/SAFI=134 is for 91 IPv4 BGP/MPLS VPN filtering [RFC8955]. [RFC8956] and [FlowSpecL2] 92 extend the flowspec rules for IPv6 and Layer 2 Ethernet packets 93 respectively. None of these previously defined flow specifications 94 are suitable for matching in cases of tunneling or encapsulation 95 where there might be duplicates of a layer of header such as two IPv6 96 headers in IP-in-IP [RFC2003] or a nested header sequence such as the 97 Layer 2 and 3 headers encapsulated in VXLAN [RFC7348]. 99 In the cloud computing era, multi-tenancy has become a core 100 requirement for data centers. It is increasingly common to see 101 tunneled traffic with a field to distinguish tenants. An example is 102 the Network Virtualization Over Layer 3 (NVO3 [RFC8014]) overlay 103 technology that can satisfy multi-tenancy key requirements. VXLAN 104 [RFC7348] and NVGRE [RFC7637] are two typical NVO3 encapsulations. 105 Other encapsulations such as IP-in-IP or GRE may be encountered. 106 Because these tunnel / overlay technologies involving an additional 107 level of encapsulation, flow specification that can match on the 108 inner header as well as the outer header and fields in any tunneling 109 header are needed. 111 In summary, Flow Specifications should be able to include inner 112 nested header information as well as fields specific to the type of 113 tunneling in use such as virtual network / tenant ID. This draft 114 specifies methods for accomplishing this using SAFI=77 and a new NLRI 115 encoding. In addition, flow specification components are specified 116 for certain tunneling header fields. 118 1.1 Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 The reader is assumed to be familiar with BGP terminology [RFC4271] 127 [RFC4760]. The following terms and acronyms are used in this document 128 with the meaning indicated: 130 ACL - Access Control List 132 DDoS - Distributed Denial of Service (Attack) 134 DSCP - Differentiated Services Code Point [RFC2474] 136 GRE - Generic Router Encapsulation [RFC2890] 138 L2TPv3 - Layer Two Tunneling Protocol - Version 3 [RFC3931] 140 NLRI - Network Layer Reachability Information [RFC4271] [RFC4760] 142 NVGRE - Network Virtualization Using Generic Routing Encapsulation 143 [RFC7637] 145 NVO3 - Network Virtual Overlay Layer 3 [RFC8014] 147 PE - Provider Edge 149 VN - virtual network 151 VXLAN - Virtual eXtensible Local Area Network [RFC7348] 153 2. Tunneled Traffic Flow Specification NLRI 155 The Flowspec rules specified in [RFC8955], [RFC8956], and 156 [FlowSpecL2] cannot match or filter tunneled traffic based on the 157 tunnel type, any tunnel header fields, or headers past the tunnel 158 header. To enable flow specification of tunneled traffic, a new SAFI 159 (77) and NLRI encoding are specified. This encoding, shown in Figure 160 1, enables flow specification of more than one layer of header when 161 needed. 163 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 164 | Length 2 octets | 165 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 166 | Tunnel Type 2 octets | 167 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 168 Flags: 169 +--+--+--+--+--+--+--+--+ 170 | D| I| Reserved | 1 octet 171 +--+--+--+--+--+--+--+--+ 172 Optional Routing Distinguisher: 173 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 174 | | 175 + + 176 | | 177 + Routing Distinguisher 8 octets + 178 | | 179 + + 180 | | 181 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 182 Outer Flowspec: 183 +--+--+--+--+--+--+--+--+ 184 | Outer Flowspec Length ... 1 or 2 octets 185 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 186 | Outer Flowspec variable : 187 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 188 Tunnel Header Flowspec: 189 +--+--+--+--+--+--+--+--+ 190 | Tunnel Flowspec Length ... 1 or 2 octets 191 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 192 | Tunnel Header Flowspec variable : 193 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 194 Optional Inner Flowspec: 195 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 196 | Inner AFI 2 octets | 197 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 198 | Inner Flowspec Length ... 1 or 2 octets 199 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 200 | Inner Flowspec variable : 201 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 202 Figure 1. Tunneled Traffic Flowspec NLRI 204 Length - The NLRI Length including the Tunnel Type encoded as an 205 unsigned integer. 207 Tunnel Type - The type of tunnel using a value from the IANA BGP 208 Tunnel Encapsulation Attribute Tunnel Types registry. 210 Flags: D bit - Indicates the presence of the Routing Distinguisher 211 (see below). 213 Flags: I bit - Indicates the presence of the Inner AFI and the Inner 214 Flowspec (see below). 216 Flags: Reserved - Six bits that MUST be sent as zero and ignored on 217 receipt. 219 Routing Distinguisher - If the outer Layer 3 address belongs to a 220 BGP/MPLS VPN, the routing distinguisher is included to indicate 221 traffic filtering within that VPN. Because NVO3 outer layer 222 addresses normally belong to a public network, a Route 223 Distinguisher field is normally not needed for NVO3. 225 Outer Flowspec / Length - The flow specification for the outer 226 header. The length is encoded as provided in Section 4.1 of 227 [RFC8955]. The AFI for the Outer Flowspec is the AFI at the 228 beginning of the BGP multiprotocol MP_REACH_NLRI or 229 MP_UNREACH_NLRI containing the tunneled traffic flow 230 specification NLRI. 232 Tunnel Header Flowspec / Length - The flow specification for the 233 tunneling header. The length is encoded as provided in Section 234 4.1 of [RFC8955]. This specifies matching criterion on tunnel 235 header fields as well as, implicitly, on the tunnel type which 236 is indicated by the Tunnel Type field above. For some types of 237 tunneling, such as IP-in-IP, there may be no tunnel header 238 fields. For other types of tunneling, there may be several 239 tunnel header fields on which matching can be specified with 240 this flowspec. If a Tunnel Type has no tunnel header fields or 241 it is not desired to filter on header fields, the Tunnel 242 Flowspec length field is present but has value zero. 244 Inner AFI - Depending on the Tunnel Type, there may be an Inner AFI 245 that indicate the type of inner flow specification. The "Inner 246 SAFI" is implicitly 133 for flowspec. 248 Inner Flowspec / Length - Depending on the Tunnel Type, there may be 249 an inner flowspec for the header level encapsulated within the 250 outer header. The length is encoded as provided in Section 4.1 251 of [RFC8955]. 253 A Tunneled Traffic Flowspec matches if the Outer Flowspec, Tunnel 254 Type, and Tunnel Header Flowspec match and, in addition, each of the 255 following optional items that is present matches: 256 - Inner Flowspec, and 257 - Routing Distinguisher. 259 An omitted (as can be done for the Inner Flowspec) or null flowspec 260 is considered to always match. 262 2.1 The SAFI Code Point 264 Use of the tunneled traffic flow specification NLRI format is 265 indicated by SAFI=77. This is used in conjunction with the AFI for 266 the outer header, that is AFI=1 for IPv4, AFI=2 for IPv6, and AFI=6 267 for Layer 2. 269 2.2 Tunnel Header Component Code Points 271 For most cases of tunneled traffic, there are tunnel header fields 272 that can be tested by components that appear in the Tunnel Header 273 Flowspec field. The types for these components are specified in a 274 Tunnel Header Flowspec component registry (see Section 6) and the 275 initial entries in this registry are specified below. 277 All Tunnel Header field components defined below and all such 278 components added in the future have a TLV structure as follows: 279 - one octet of type followed by 280 - one octet giving the length of the value part as an unsigned 281 integer number of octets followed by 282 - the specific matching operations/values as determined by the 283 type. 285 Type 1 - VN ID 286 Encoding: . 288 Defines a list of {operation, value} pairs used to match the 289 24-bit VN ID that is used as the tenant identification in some 290 tunneling headers. For VXLAN and Geneve encapsulation, the VN 291 ID field is the VNI. For NVGRE encapsulation, the VN ID is the 292 VSID. op is encoded as specified in Section 4.2.3 of [RFC8955]. 293 Values are encoded as a 1, 2, or 4 octet quantity. If value is 294 24-bits, it is left-justified in the first 3 octets of the 295 value and the last value octet MUST be sent as zero and ignored 296 on receipt. 298 Type 2 - Flow ID 299 Encoding: 301 Defines a list of {operation, value} pairs used to match 8-bit 302 Flow ID fields which are currently only useful for NVGRE 303 encapsulation. op is encoded as specified in Section 4.2.3 of 304 [RFC8955]. Values are encoded as a 1-octet quantity. 306 Type 3 - Session 307 Encoding: 309 Defines a list of {operation, value} pairs used to match a 310 32-bit Session field. This field is called Key in GRE [RFC2890] 311 encapsulation and Session ID in L2TPv3 encapsulation. op is 312 encoded as specified in Section 4.2.3 of [RFC8955]. Values are 313 encoded as a 1, 2, or 4 octet quantity; if 1 or 2 octets are 314 provided, these are right justified and padded on the left with 315 zeros. 317 Type 4 - Cookie 318 Encoding: 320 Defines a list of {operation, value} pairs used to match a 321 variable length Cookie field. This is only useful in L2TPv3 322 encapsulation. op is encoded as specified in Section 4.2.3 of 323 [RFC8955]. Values are encoded as a 1, 2, 4, or 8 octet 324 quantity. If the Cookie does not fit exactly into the value 325 length, it is left justified and padded with following octets 326 that MUST be sent as zero and ignored on receipt. 328 Type 5 - Tunnel Header Flags 329 Encoding: 331 Defines a list of {operation, bitmask} pairs used to match 332 against the tunnel header flags field. op is encoded as in 333 Section 4.2.9 of [RFC8955]. bitmask is encoded as 1 octet for 334 VXLAN-GPE and Geneve and as 2 octets for L2TPv3 control 335 messages. When matching on L2TPv3 control message flags, the 336 3-bit Version subfield is treated as if it was zero. 338 Type 6 - L2TP Control Version 339 Encoding: 341 Defines a list of {operation, value} pairs used to match 342 against the L2TP Control Message Version. op is encoded as in 343 Section 4.2.3 of [RFC8955]. Value is encoded as 1 octet. 345 Type 7 - L2TPv3 Control Connection ID 346 Encoding: 348 Defines a list of {operation, value} pairs used to match 349 against the L2TPv3 Control Connection ID. op is encoded as in 350 Section 4.2.3 of [RFC8955]. Value is encoded as 4 octets. 352 Type 8 - L2TPv3 Ns 353 Encoding: 355 Defines a list of {operation, value} pairs used to match 356 against the L2TPv3 control message Ns field. op is encoded as 357 in Section 4.2.3 of [RFC8955]. Value is encoded as 2 octets. 359 Type 9 - L2TPv3 Nr 360 Encoding: 362 Defines a list of {operation, value} pairs used to match 363 against the L2TPv3 control message Nr field. op is encoded as 364 in Section 4.2.3 of [RFC8955]. Values are encoded as 2 octets. 366 Type 10 - Protocol Type 367 Encoding: 369 Defines a list of {operation, value} pairs used to match 370 against the GRE and Geneve Protocol Type fields. op is encoded 371 as in Section 4.2.3 of [RFC8955]. Values are encoded as 2 372 octets. 374 Type 11 - GRE Sequence 375 Encoding: 377 Defines a list of {operation, value} pairs used to match 378 against the GRE Sequence field. op is encoded as in Section 379 4.2.3 of [RFC8955]. Values are encoded as a 1, 2, or 4 octet 380 quantity; if 1 or 2 octets are provided, these are right 381 justified and padded on the left with zeros. 383 2.3 Specific Tunnel Types 385 The following subsections describe how to handle flow specification 386 for several specific tunnel types. 388 2.3.1 VXLAN 390 The headers on a VXLAN [RFC7348] data packet are an outer Ethernet 391 header, an outer IP header, a UDP header, the VXLAN header, and an 392 inner Ethernet header. This inner Ethernet header is frequently, but 393 not always, followed by an inner IP header. If the tunnel type is 394 VXLAN, the I flag MUST be set in the Tunneled Traffic Flow 395 Specification. 397 If the outer Ethernet header is not being matched, the version (IPv4 398 or IPv6) of the outer IP header is indicated by the AFI at the 399 beginning of the multiprotocol MP_REACH_NLRI or MP_UNREACH_NLRI 400 containing the Tunneled Traffic Flow Specification NLRI. The outer 401 Flowspec is used to filter the outer headers including, if desired, 402 the UDP header. 404 If the outer Ethernet header is being matched, then the initial AFI 405 is 6 [FlowSpecL2] and the Outer Flowspec can match the outer Ethernet 406 header, specify the IP version of the outer IP header, and match that 407 IP header including, if desired, the UDP header. 409 The Tunnel Header Flowspec can be used to filter on the VXLAN header 410 VN ID (VNI). 412 The Inner Flowspec can be used on the Inner Ethernet header 413 [FlowSpecL2] and any following IP header. If the inner AFI is 6, 414 then the inner Flowspec provides filtering of the Layer 2 header, 415 indicates whether filtering on a following IPv4 or IPv6 header is 416 desired, and if it is desired provides the Flowspec components for 417 that filtering. If the Inner AFI is 1 or 2, the Inner Ethernet 418 header is not matched and to match the Flowspec the Inner Ethernet 419 header must be followed by an IPv4 or IPv6 header, respectively, and 420 the inner Flowspec is used to filter that inner IP header. 422 The inner MAC/IP address is associated with the VN ID. In the NVO3 423 terminating into a VPN scenario, if multiple access VN IDs map to one 424 VPN instance, one shared VN ID can be carried in the flowspec rule to 425 enforce the rule on the entire VPN instance and the shared VN ID and 426 VPN correspondence should be configured on each VPN PE beforehand. In 427 this case, the function of the Layer 3 VN ID is the same as a Route 428 Distinguisher: it acts as the identification of the VPN instance. 430 2.3.2 VXLAN-GPE 432 VXLAN-GPE [GPE] is similar to VXLAN. The VXLAN-GPE header is the same 433 size as the VXLAN header but has been extended from the VXLAN header 434 by specifying a number of bits that are reserved in the VXLAN header. 435 In particular, a number of additional flag bits are specified and a 436 Next Protocol field is added that is valid if the P flag bit is set 437 in the VXLAN-GPE header. These flags bits can be tested using the 438 Tunnel Header Flags flowspec component defined above. VXLAN and 439 VXLAN-GPE are distinguished by the port number in the UDP header the 440 precedes the VXLAN or VXLAN-GPE headers. 442 If the VXLAN-GPE header P flag is zero, then that header is followed 443 by the same sequence as for VXLAN and the same flowspec choices apply 444 (see Section 2.3.1). 446 If the VXLAN-GPE header P flag is one and that header's next protocol 447 field is 1, then the VXLAN-GPE header is followed by an IPv4 header 448 (there is no Inner Ethernet header). The Inner Flowspec matches only 449 if the Inner AFI is 1 and the Inner Flowspec matches. 451 If the VXLAN-GPE header P flag is one and that header's next protocol 452 field is 2, then the VXLAN-GPE header is followed by an IPv6 header 453 (there is no Inner Ethernet header). The Inner Flowspec match only 454 if the Inner AFI is 2 and the Inner Flowspec matches. 456 2.3.3 NVGRE 458 NVGRE [RFC7637] is similar to VXLAN except that the UDP header and 459 VXLAN header immediately after the outer IP header are replaced by a 460 GRE (Generic Router Encapsulation) header. The GRE header as used in 461 NVGRE has no Checksum or Reserved1 field as shown in [RFC2890] but 462 there are Virtual Subnet ID and Flow ID fields in place of what is 463 labeled in [RFC2890] as the Key field. Processing and restrictions 464 for NVGRE are as in Section 2.3.1 eliminating references to a UDP 465 header and replacing references to the VXLAN header and its VN ID 466 with references to the GRE header and its VN ID (VSID) and Flow ID. 468 2.3.4 L2TPv3 470 The headers on an L2TPv3 [RFC3931] packets are an outer Ethernet 471 header, an outer IP header, the L2TPv3 header, an inner Ethernet 472 header, and possibly an inner IP header if indicated by the inner 473 Ethernet header EtherType. The Outer Flowspec operates on the outer 474 headers that precede the L2TPv3 Session Header. The version of IP in 475 the outer IP header is specified by either the outer AFI at the 476 beginning of the MP_REACH_NLRI or MP_UNREACH_NLRI or, if that AFI is 477 6 (L2), optionally specified by the inner AFI within that L2 478 flowspec. 480 L2TPv3 data messages and control messages both start with a Session 481 ID and are distinguished by whether the Session ID is non-zero or 482 zero, respectively. Data message filtering is further specified in 483 Section 2.3.4.1 and control message filtering is further specified in 484 Section 2.3.4.2. 486 2.3.4.1 L2TPv3 Data Messages 488 For data messages, the L2TPv3 Session Header consists of a 32-bit 489 non-zero Session ID followed by a variable length Cookie (maximum 490 length 8 octets). A Tunnel Header flowspec is assumed to apply to 491 data messages unless the first component requires a zero Session ID. 493 The Session ID and Cookie can be filtered on by using the Session and 494 Cookie flowspec components in the Tunnel Header Flowspec. To filter 495 on Cookie or even be able to bypass Cookie and parse the remainder of 496 the L2TPv3 packet, the node implementing tunneled traffic flowspec 497 needs to know the length and/or value of the Cookie fields of 498 interest. This is negotiated at L2TPv3 session establishment and it 499 is out of scope for this document how the node would learn this 500 information. Of course, if flowspec is being used for DDOS 501 mitigation and the Cookie has a fixed length and/or value in the DDOS 502 traffic, this could be learned by inspecting that traffic. 504 If the I flag bit is zero, then no filtering is done on data beyond 505 the L2TPv3 header. If the I flag is one, indicating the presence of 506 an Inner Flowspec, and the node implementing flowspec does not know 507 the length of the L2TPv3 header Cookie, the match fails. If that node 508 does know the length of that Cookie, the Inner Flowspec if matched 509 against the headers at the beginning of that data using the Inner 510 AFI. If that Inner AFI is 1 or 2, then an inner IP header is required 511 and filtering can be done on that IPv4 or IPv6 header respectively. 512 If the Inner AFI is 6, filtering is done on the inner Ethernet header 513 and, if an IPv4 or IPv6 inner AFI is specified within the inner L2 514 flowspec, done on the following IP header [FlowSpecL2]. 516 2.3.4.2 L2TPv3 Control Messages 518 Control messages are distinguished by starting with a zero value 519 32-bit Session ID. L2TPv3 control message flowspecs MUST start with a 520 Session component that requires Session to be zero. For L2TPv3 521 control messages, there is no Cookie but there are L2TPv3 flags, a 522 3-bit Version field, a 32-bit Control Connection ID, and 16-bit Ns 523 and Nr sequence numbers. These can be tested using the Tunnel Header 524 Flags, L2TP Control Version, L2TPv3 Control Connection ID, L2TPv3 Ns, 525 and L2TPv3 Nr flowspec components in the Tunnel Header Flowspec. 527 2.3.5 GRE 529 Generic Router Encapsulation (GRE [RFC2890]) is another type of 530 encapsulation. The Outer Flowspec operates on the outer headers that 531 precede the GRE header. The version of IP is specified by the outer 532 AFI at the beginning of the MP_REACH_NLRI or MP_UNREACH_NLRI. 534 The Tunnel Header Flags component can be used to match the first two 535 octets of the GRE header. The Protocol Type component can be used to 536 match the corresponding GRE header field. The Session and GRE 537 Sequence components can be used to match on the GRE Key and GRE 538 Sequence fields if those fields are present respectively. If either 539 of those fields is not present, a component to match on that field 540 fails. 542 If the I flag bit is zero, no filtering is done on data after the GRE 543 header. If the I flag bit is one in the tunnel flowspec, then there 544 is an inner AFI and inner flowspec and the Protocol Type field of the 545 GRE header must correspond to the Inner AFI as follows for the tunnel 546 Flowspec to match. Otherwise, the match fails. 548 GRE Protocol Type Inner AFI 549 ------------------- ----------- 550 0x0800 (IPv4) 1 551 0x86DD (IPv6) 2 552 0x6558 6 554 With the I flag a one and the Inner AFI and GRE Protocol Type fields 555 correspond, the Inner Flowspec is used to filter the inner IP headers 556 (Inner AFI=1 or 2) or the inner Ethernet header and optionally a 557 following IP header (Inner AFI=6). 559 2.3.6 IP-in-IP 561 IP-in-IP encapsulation [RFC2003] is indicated when an outer IP header 562 indicates an inner IP IPv4 or IPv6 header by the value of the outer 563 IP header's Protocol (IPv4) or Next Protocol (IPv6) field. 565 The IP version of the outer IP header (IPv4 or IPv6) matched is 566 indicated by an AFI of 1 or 2 at the beginning of the MP_REACH_NLRI 567 or MP_UNREACH_NLRI while if that AFI is 6, it indicates a match on 568 the out Ethernet header and, optionally, the following IP Header 569 [FlowSpecL2]. The IP version of the inner IP header is indicated by 570 the Inner AFI and the Inner Flowspec applies to the inner IP header. 572 There is no tunnel header so there are no fields that can be matched 573 by the Tunnel Header Flowspec in the case of IP-in-IP. 575 2.3.7 Geneve 577 The headers on a Geneve [RFC8926] encapsulated packet are an outer 578 Ethernet header, an outer IP header, a UDP header, the Geneve header, 579 and subsequent headers depending on the Geneve header Protocol Type 580 field. 582 If the outer Ethernet header is not being matched, the version (IPv4 583 or IPv6) of the outer IP header is indicated by the AFI at the 584 beginning of the multiprotocol MP_REACH_NLRI or MP_UNREACH_NLRI 585 containing the Tunneled Traffic Flow Specification NLRI. The outer 586 Flowspec is used to filter the outer headers including, if desired, 587 the UDP header. 589 If the outer Ethernet header is being matched, then the initial AFI 590 is 6 [FlowSpecL2] and the Outer Flowspec can match the outer Ethernet 591 header, specify the IP version of the outer IP header, and match that 592 IP header including, if desired, the UDP header. 594 The Tunnel Header Flowspec can be used to filter on the Protocol Type 595 field and/or the VNI field in the Geneve header. The flags octet of 596 the Geneve header, the second octet of that header, can be filtered 597 using the Tunnel Header Flags component. 599 If an Inner Flowspec is present, it is used to match the header(s) 600 after the Geneve header. The Protocol Type field in the Geneve header 601 must correspond to the Inner AFI as shown in the table in Section 602 2.3.5 above or the match fails. If the Inner AFI and GRE Protocol 603 Type fields correspond, the Inner Flowspec is used to filter the 604 inner IP headers (Inner AFI=1 or 2) or the inner Ethernet header and 605 optionally a following IP header (Inner AFI=6). 607 2.4 Tunneled Traffic Actions 609 The traffic filtering actions previously specified in [RFC8955] and 610 [FlowSpecL2] are used for tunneled traffic. For Traffic Marking in 611 NVO3, only the DSCP in the outer header can be modified. 613 3. Order of Traffic Filtering Rules 615 The following rules determine which flowspec takes precedence where 616 one or more are applicable and at least one of the applicable 617 flowspecs is a tunneled traffic flowspec: 619 - In comparing an applicable tunneled traffic flow specification 620 with an applicable non-tunneled flow specification, the tunneled 621 specification has precedence. 623 - If comparing tunneled traffic flow specifications, if all are 624 applicable, the tunnel types will be the same. Any that have a 625 Routing Distinguisher will take precedence over those without a 626 Routing Distinguisher. Of those with a Routing Distinguisher, all 627 applicable flowspecs will have the same Routing Distinguisher. 629 - At this point in the process, all remaining contenders for the 630 highest precedence will either not have a Routing Distinguisher or 631 have equal Routing Distinguishers. If more than one contender 632 remain, those with an L2 Outer Flowspec take precedence over those 633 with an L3 Outer Flowspec. If the Outer Flowspec AFI is the same, 634 their order of precedence is determined by comparing the Outer 635 Flowspecs as described in [RFC8955] and [RFC8956] for AFI for 1 or 636 2 respectively or [FlowSpecL2] for AFI=6. 638 - If the Outer Flowspecs are equal, then the Tunnel Header Flowspecs 639 are compared using the usual sequential component comparison 640 process [RFC8955]. 642 - If the Tunnel Header Flowspecs are equal then compare the "I" 643 flag. Those with an Inner Flowspec take precedence over those 644 without an Inner Flowspec. If you get to this stage in the 645 ordering process, those without an Inner Flowspec are equal. For 646 those with an Inner Flowspec, check the Inner AFI. An L2 Inner AFI 647 (AFI=6) takes precedence over an L3 Inner AFI. 649 - If the Inner AFIs are equal, precedence is determined by comparing 650 the Inner Flowspecs as described in [FlowSpecL2] for L2 or 651 [RFC8955] for L3. 653 4. Flow Spec Validation 655 Flowspecs received over AFI=1/SAFI=77 or AFI=2/SAFI=77 are validated, 656 using only the Outer Flowspec, against routing reachability received 657 over AFI=1/SAFI=133 and AFI=2/SAFI=133 respectively, as modified by 658 [FlowSpecOID]. 660 5. Security Considerations 662 No new security issues are introduced to the BGP protocol by this 663 specification. 665 For general Flowspec security considerations, see [RFC8955]. 667 6. IANA Considerations 669 IANA has assigned the following SAFI: 671 Value Description Reference 672 ----- ------------------------------------------ --------------- 673 77 Tunneled Traffic Flowspec [This document] 675 IANA is requested to create a Tunnel Header Flow Spec Component Type 676 registry on the Flow Spec Component Types registries web page as 677 follows: 679 Name: Tunnel Flow Spec Component Types 680 Reference: [this document] 681 Registration Procedures: 682 0 Reserved 683 1-127 Specification Required 684 128-254 First Come First Served 685 255 Reserved 687 Initial contents: 688 Type Name Reference 689 ------ -------------- ----------------- 690 0 reserved [this document] 691 1 VN ID [this document] 692 2 Flow ID [this document] 693 3 Session [this document] 694 4 Cookie [this document] 695 5 Tunnel Header Flags [this document] 696 6 L2TP Control Version [this document] 697 7 L2TPv3 Control Connection ID 698 [this document] 699 8 L2TPv3 Ns [this document] 700 9 L2TPv3 Nr [this document] 701 10 Protocol Type [this document] 702 11 GRE Sequence [this document] 703 12-254 unassigned [this document] 704 255 reserved [this document] 706 Normative References 708 [RFC2003] - Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 709 10.17487/RFC2003, October 1996, . 712 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 714 March 1997, . 716 [RFC2474] - Nichols, K., Blake, S., Baker, F., and D. Black, 717 "Definition of the Differentiated Services Field (DS Field) in 718 the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, 719 December 1998, . 721 [RFC2890] - Dommety, G., "Key and Sequence Number Extensions to GRE", 722 RFC 2890, DOI 10.17487/RFC2890, September 2000, 723 . 725 [RFC3931] - Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 726 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, 727 DOI 10.17487/RFC3931, March 2005, . 730 [RFC4271] - Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 731 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 732 10.17487/RFC4271, January 2006, . 735 [RFC4760] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 736 "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 737 10.17487/RFC4760, January 2007, . 740 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 741 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 742 eXtensible Local Area Network (VXLAN): A Framework for 743 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 744 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 747 [RFC7637] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network 748 Virtualization Using Generic Routing Encapsulation", RFC 7637, 749 DOI 10.17487/RFC7637, September 2015, . 752 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 753 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 754 2017, . 756 [RFC8926] - Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 757 "Geneve: Generic Network Virtualization Encapsulation", RFC 758 8926, DOI 10.17487/RFC8926, November 2020, . 761 [RFC8955] - Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 762 Bacher, "Dissemination of Flow Specification Rules", RFC 8955, 763 DOI 10.17487/RFC8955, December 2020, . 766 [RFC8956] - Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 767 "Dissemination of Flow Specification Rules for IPv6", RFC 8956, 768 DOI 10.17487/RFC8956, December 2020, . 771 [FlowSpecL2] - W. Hao, et al, "Dissemination of Flow Specification 772 Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in 773 progress. 775 [FlowSpecOID] - J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P. 776 Mohapatra, "Revised Validation Procedure for BGP Flow 777 Specifications", draft-ietf-idr-bgp-flowspec-oid, work in 778 progress. 780 Informative References 782 [RFC8014] - Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 783 Narten, "An Architecture for Data-Center Network Virtualization 784 over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December 785 2016, . 787 [GPE] - P. Quinn, et al, "Generic Protocol Extension for VXLAN", 788 draft-ietf-nvo3-vxlan-gpe, work in progress. 790 Acknowledgments 792 The authors wish to acknowledge the important contributions of the 793 following listed in alphabetic order: 795 Jeff Haas, Susan Hares, Yizhou Li, Qiandeng Liang, Greg Mirsky, 796 Nan Wu, Robert Raszuk, and Lucy Yong 798 Authors' Addresses 800 Donald Eastlake 801 Futurewei Technologies 802 2386 Panoramic Circle 803 Apopka, FL 32703 USA 805 Tel: +1-508-333-2270 806 Email: d3e3e3@gmail.com 808 Weiguo Hao 809 Huawei Technologies 810 101 Software Avenue, 811 Nanjing 210012 China 813 Email: haoweiguo@huawei.com 815 Shunwan Zhuang 816 Huawei Technologies 817 Huawei Bld., No.156 Beiqing Rd. 818 Beijing 100095 China 820 Email: zhuangshunwan@huawei.com 822 Zhenbin Li 823 Huawei Technologies 824 Huawei Bld., No.156 Beiqing Rd. 825 Beijing 100095 China 827 Email: lizhenbin@huawei.com 829 Rong Gu 830 China Mobile 832 Email: gurong_cmcc@outlook.com 834 Copyright, Disclaimer, and Additional IPR Provisions 836 Copyright (c) 2021 IETF Trust and the persons identified as the 837 document authors. All rights reserved. 839 This document is subject to BCP 78 and the IETF Trust's Legal 840 Provisions Relating to IETF Documents 841 (http://trustee.ietf.org/license-info) in effect on the date of 842 publication of this document. Please review these documents 843 carefully, as they describe your rights and restrictions with respect 844 to this document. Code Components extracted from this document must 845 include Simplified BSD License text as described in Section 4.e of 846 the Trust Legal Provisions and are provided without warranty as 847 described in the Simplified BSD License.