idnits 2.17.1 draft-ietf-idr-flowspec-nvo3-10.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 (September 30, 2020) is 1276 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 Mobil 9 Expires: March 29, 2021 September 30, 2020 11 BGP Dissemination of 12 Flow Specification Rules for Tunneled Traffic 13 draft-ietf-idr-flowspec-nvo3-10 15 Abstract 16 This draft specifies a Border Gateway Protocol (BGP) Network Layer 17 Reachability Information (NLRI) encoding format for flow 18 specifications (RFC 5575bis) 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 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at 43 http://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....................................8 52 2.2 Tunnel Header Component Code Points....................8 53 2.3 Specific Tunnel Types.................................10 54 2.3.1 VXLAN...............................................10 55 2.3.2 VXLAN-GPE...........................................11 56 2.3.3 NVGRE...............................................11 57 2.3.4 L2TPv3..............................................12 58 2.3.4.1 L2TPv3 Data Messages..............................12 59 2.3.4.2 L2TPv3 Control Messages...........................13 60 2.3.5 GRE.................................................13 61 2.3.6 IP-in-IP............................................13 62 2.4 Tunneled Traffic Actions..............................14 64 3. Order of Traffic Filtering Rules.......................15 65 4. Flow Spec Validation...................................16 67 5. Security Considerations................................16 68 6. IANA Considerations....................................17 70 Normative References......................................18 71 Informative References....................................19 73 Acknowledgments...........................................20 75 1. Introduction 77 BGP Flow Specification (flowspec [RFC5575bis]) is an extension to BGP 78 that supports the dissemination of traffic flow specification rules. 79 It uses the BGP control plane to simplify the distribution of Access 80 Control Lists (ACLs) and allows new filter rules to be injected to 81 all BGP peers simultaneously without changing router configuration. A 82 typical application of BGP flowspec is to automate the distribution 83 of traffic filter lists to routers for Distributed Denial of Service 84 (DDOS) mitigation. 86 BGP flowspec defines BGP Network Layer Reachability Information 87 (NLRI) formats used to distribute traffic flow specification rules. 88 AFI=1/SAFI=133 is for IPv4 unicast filtering. AFI=1/SAFI=134 is for 89 IPv4 BGP/MPLS VPN filtering [RFC5575bis]. [FlowSpecV6] and 90 [FlowSpecL2] extend the flowspec rules for IPv6 and Layer 2 Ethernet 91 packets respectively. None of these previously defined flow 92 specifications are suitable for matching in cases of tunneling or 93 encapsulation where there might be duplicates of a layer of header 94 such as two IPv6 headers in IP-in-IP [RFC2003] or a nested header 95 sequence such as the Layer 2 and 3 headers encapsulated in VXLAN 96 [RFC7348]. 98 In the cloud computing era, multi-tenancy has become a core 99 requirement for data centers. It is increasingly common to see 100 tunneled traffic with a field to distinguish tenants. An example is 101 the Network Virtualization Over Layer 3 (NVO3 [RFC8014]) overlay 102 technology that can satisfy multi-tenancy key requirements. VXLAN 103 [RFC7348] and NVGRE [RFC7637] are two typical NVO3 encapsulations. 104 Other encapsulations such as IP-in-IP or GRE may be encountered. 105 Because these tunnel / overlay technologies involving an additional 106 level of encapsulation, flow specification that can match on the 107 inner header as well as the outer header and fields in any tunneling 108 header are needed. 110 In summary, Flow Specifications should be able to include inner 111 nested header information as well as fields specific to the type of 112 tunneling in use such as virtual network / tenant ID. This draft 113 specifies methods for accomplishing this using SAFI=TBD1 and a new 114 NLRI encoding. 116 1.1 Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 The reader is assumed to be familiar with BGP terminology [RFC4271] 125 [RFC4760]. The following terms and acronyms are used in this document 126 with the meaning indicated: 128 ACL - Access Control List 130 DDoS - Distributed Denial of Service (Attack) 132 DSCP - Differentiated Services Code Point [RFC2474] 134 GRE - Generic Router Encapsulation [RFC2890] 136 L2TPv3 - Layer Two Tunneling Protocol - Version 3 [RFC3931] 138 NLRI - Network Layer Reachability Information [RFC4271] [RFC4760] 140 NVGRE - Network Virtualization Using Generic Routing Encapsulation 141 [RFC7637] 143 NVO3 - Network Virtual Overlay Layer 3 [RFC8014] 145 PE - Provider Edge 147 VN - virtual network 149 VXLAN - Virtual eXtensible Local Area Network [RFC7348] 151 2. Tunneled Traffic Flow Specification NLRI 153 The Flowspec rules specified in [RFC5575bis], [FlowSpecV6], and 154 [FlowSpecL2] cannot match or filter tunneled traffic based on the 155 tunnel type, any tunnel header fields, or headers past the tunnel 156 header. To enable flow specification of tunneled traffic, a new SAFI 157 (TBD1) and NLRI encoding are specified. This encoding, shown in 158 Figure 1, enables flow specification of more than one layer of header 159 when needed. 161 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 162 | Length 2 octets | 163 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 164 | Tunnel Type 2 octets | 165 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 166 Flags: 167 +--+--+--+--+--+--+--+--+ 168 | D| I| Reserved | 1 octet 169 +--+--+--+--+--+--+--+--+ 170 Optional Routing Distinguisher: 171 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 172 | | 173 + + 174 | | 175 + Routing Distinguisher 8 octets + 176 | | 177 + + 178 | | 179 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 180 Outer Flowspec: 181 +--+--+--+--+--+--+--+--+ 182 | Outer Flowspec Length ... 1 or 2 octets 183 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 184 | Outer Flowspec variable : 185 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 186 Tunnel Header Flowspec: 187 +--+--+--+--+--+--+--+--+ 188 | Tunnel Flowspec Length ... 1 or 2 octets 189 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 190 | Tunnel Header Flowspec variable : 191 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 192 Optional Inner Flowspec: 193 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 194 | Inner AFI 2 octets | 195 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 196 | Inner Flowspec Length ... 1 or 2 octets 197 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 198 | Inner Flowspec variable : 199 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 201 Figure 1. Tunneled Traffic Flowspec NLRI 203 Length - The NLRI Length including the Tunnel Type encoded as an 204 unsigned integer. 206 Tunnel Type - The type of tunnel using a value from the IANA BGP 207 Tunnel Encapsulation Attribute Tunnel Types registry. 209 Flags: D bit - Indicates the presence of the Routing Distinguisher 210 (see below). 212 Flags: I bit - Indicates the presence of the Inner AFI and the Inner 213 Flowspec (see below). 215 Flags: Reserved - Six bits that MUST be sent as zero and ignored on 216 receipt. 218 Routing Distinguisher - If the outer Layer 3 address belongs to a 219 BGP/MPLS VPN, the routing distinguisher is included to indicate 220 traffic filtering within that VPN. Because NVO3 outer layer 221 addresses normally belong to a public network, a Route 222 Distinguisher field is normally not needed for NVO3. 224 Outer Flowspec / Length - The flow specification for the outer 225 header. The length is encoded as provided in Section 4.1 of 226 [RFC5575bis]. The AFI for the Outer Flowspec is the AFI at the 227 beginning of the BGP multiprotocol MP_REACH_NLRI or 228 MP_UNREACH_NLRI containing the tunneled traffic flow 229 specification NLRI. 231 Tunnel Header Flowspec / Length - The flow specification for the 232 tunneling header. This specifies matching criterion on tunnel 233 header fields as well as, implicitly, on the tunnel type which 234 is indicated by the Tunnel Type field above. For some types of 235 tunneling, such as IP-in-IP, there may be no tunnel header 236 fields. For other types of tunneling, there may be several 237 tunnel header fields on which matching can be specified with 238 this flowspec. 240 Inner AFI - Depending on the Tunnel Type, there may be an Inner AFI 241 that indicates the address family for the inner flow 242 specification. There is no need for a SAFI as the treatment of 243 this inner AFI and following flowspec is indicated by the outer 244 SAFI TBD1, the SAFI for a tunneled traffic flow specification. 246 Inner Flowspec / Length - Depending on the Tunnel Type, there may be 247 an inner flowspec for the header level encapsulated within the 248 outer header. The length is encoded as provided in Section 4.1 249 of [RFC5575bis]. 251 A Tunneled Traffic Flowspec matches if the Outer Flowspec, Tunnel 252 Type, and Tunnel Header Flowspec match and, in addition, each of the 253 following optional items that is present matches: 254 - Inner Flowspec, and 255 - Routing Distinguisher. 257 An omitted (as can be done for the Inner Flowspec) or null flowspec 258 is considered to always match. 260 2.1 The SAFI Code Point 262 Use of the tunneled traffic flow specification NLRI format is 263 indicated by SAFI=TBD1. This is used in conjunction with the AFI for 264 the outer header, that is AFI=1 for IPv4, AFI=2 for IPv6, and AFI=6 265 for Layer 2. 267 2.2 Tunnel Header Component Code Points 269 For most cases of tunneled traffic, there are tunnel header fields 270 that can be tested by components that appear in the Tunnel Header 271 Flowspec field. The types for these components are specified in a 272 Tunnel Header Flowspec component registry (see Section 6) and the 273 initial entries in this registry are specified below. 275 All Tunnel Header field components defined below and all such 276 components added in the future have a TLV structure as follows: 277 - one octet of type followed by 278 - one octet giving the length as an unsigned integer number of 279 octets followed by 280 - the specific matching operations/values as determined by the 281 type. 283 Type 1 - VN ID 284 Encoding: . 286 Defines a list of {operation, value} pairs used to match the 287 24-bit VN ID that is used as the tenant identification in some 288 tunneling headers. For VXLAN encapsulation, the VN ID is the 289 VNI. For NVGRE encapsulation, the VN ID is the VSID. op is 290 encoded as specified in Section 4.2.3 of [RFC5575bis]. Values 291 are encoded as a 1, 2, or 4 octet quantity. If value is 292 24-bits, it is left-justified in the first 3 octets of the 293 value and the last value octet MUST be sent as zero and ignored 294 on receipt. 296 Type 2 - Flow ID 297 Encoding: 299 Defines a list of {operation, value} pairs used to match 8-bit 300 Flow ID fields which are currently only useful for NVGRE 301 encapsulation. op is encoded as specified in Section 4.2.3 of 302 [RFC5575bis]. Values are encoded as a 1-octet quantity. 304 Type 3 - Session 305 Encoding: 307 Defines a list of {operation, value} pairs used to match a 308 32-bit Session field. This field is called Key in GRE [RFC2890] 309 encapsulation and Session ID in L2TPv3 encapsulation. op is 310 encoded as specified in Section 4.2.3 of [RFC5575bis]. Values 311 are encoded as a 1, 2, or 4 octet quantity. 313 Type 4 - Cookie 314 Encoding: 316 Defines a list of {operation, value} pairs used to match a 317 variable length Cookie field. This is only useful in L2TPv3 318 encapsulation. op is encoded as specified in Section 4.2.3 of 319 [RFC5575bis]. Values are encoded as a 1, 2, 4, or 8 octet 320 quantity. If the Cookie does not fit exactly into the value 321 length, it is left justified and padded with following octets 322 that MUST be sent as zero and ignored on receipt. 324 Type 5 - Tunnel Header Flags 325 Encoding: 327 Defines a list of {operation, value} pairs used to match 328 against the tunnel header flags field. op is encoded as in 329 Section 4.2.9 of [RFC5575bis]. bitmask is encoded as 1 octet 330 for VXLAN-GPE and 2 octets for L2TP control messages. When 331 matching on L2TP control message flags, the 3-bit Version 332 subfield is treated as if it was zero. 334 Type 6 - L2TP Control Version 335 Encoding: 337 Defines a list of {operation, value} pairs used to match 338 against the L2TPv3 Control Message Version. op is encoded as in 339 Section 4.2.3 of [RFC5575bis]. Value is encoded as 1 octet. 341 Type 7 - L2TPv3 Control Connection ID 342 Encoding: 344 Defines a list of {operation, value} pairs used to match 345 against the L2TPv3 Control Connection ID. op is encoded as in 346 Section 4.2.3 of [RFC5575bis]. Value is encoded as 4 octets. 348 Type 8 - L2TPv3 Ns 349 Encoding: 351 Defines a list of {operation, value} pairs used to match 352 against the L2TPv3 control message Ns field. op is encoded as 353 in Section 4.2.3 of [RFC5575bis]. Value is encoded as 2 octets. 355 Type 9 - L2TPv3 Nr 356 Encoding: 357 Defines a list of {operation, value} pairs used to match 358 against the L2TPv3 control message Nr field. op is encoded as 359 in Section 4.2.3 of [RFC5575bis]. Value is encoded as 2 octets. 361 2.3 Specific Tunnel Types 363 The following subsections describe how to handle flow specification 364 for several specific tunnel types. 366 2.3.1 VXLAN 368 The headers on a VXLAN [RFC7348] data packet are an outer Ethernet 369 header, an outer IP header, a UDP header, the VXLAN header, and an 370 inner Ethernet header. This inner Ethernet header is frequently, but 371 not always, followed by an inner IP header. If the tunnel type is 372 VXLAN, the I flag MUST be set in the Tunneled Traffic Flow 373 Specification. 375 If the outer Ethernet header is not being matched, the version (IPv4 376 or IPv6) of the outer IP header is indicated by the AFI at the 377 beginning of the multiprotocol MP_REACH_NLRI or MP_UNREACH_NLRI 378 containing the Tunneled Traffic Flow Specification NLRI. The outer 379 Flowspec is used to filter the outer headers including, if desired, 380 the UDP header. 382 If the outer Ethernet header is being matched, then the initial AFI 383 is 6 [FlowSpecL2] and the Outer Flowspec can match the outer Ethernet 384 header, specify the IP version of the outer IP header, and match that 385 IP header including, if desired, the UDP header. 387 The Tunnel Header Flowspec can be used to filter on the VXLAN header 388 VN ID (VNI). 390 The Inner Flowspec can be used on the Inner Ethernet header 391 [FlowSpecL2] and any following IP header. If the inner AFI is 6, 392 then the inner Flowspec provides filtering of the Layer 2 header, 393 indicates whether filtering on a following IPv4 or IPv6 header is 394 desired, and if it is desired provides the Flowspec components for 395 that filtering. If the Inner AFI is 1 or 2, the Inner Ethernet 396 header is not matched and to match the Flowspec the Inner Ethernet 397 header must be followed by an IPv4 or IPv6 header, respectively, and 398 the inner Flowspec is used to filter that inner IP header. 400 The inner MAC/IP address is associated with the VN ID. In the NVO3 401 terminating into a VPN scenario, if multiple access VN IDs map to one 402 VPN instance, one shared VN ID can be carried in the flowspec rule to 403 enforce the rule on the entire VPN instance and the shared VN ID and 404 VPN correspondence should be configured on each VPN PE beforehand. In 405 this case, the function of the Layer 3 VN ID is the same as a Route 406 Distinguisher: it acts as the identification of the VPN instance. 408 2.3.2 VXLAN-GPE 410 VXLAN-GPE [GPE] is similar to VXLAN. The VXLAN-GPE header is the same 411 size as the VXLAN header but has been extended from the VXLAN header 412 by specifying a number of bits that are reserved in the VXLAN header. 413 In particular, a number of additional flag bits are specified and a 414 Next Protocol field is added that is valid if the P flag bit is set 415 in the VXLAN-GPE header. These flags bits can be tested using the 416 Tunnel Header Flags flowspec component defined above. VXLAN and 417 VXLAN-GPE are distinguished by the port number in the UDP header the 418 precedes the VXLAN or VXLAN-GPE headers. 420 If the VXLAN-GPE header P flag is zero, then that header is followed 421 by the same sequence as for VXLAN and the same flowspec choices apply 422 (see Section 2.3.1). 424 If the VXLAN-GPE header P flag is one and that header's next protocol 425 field is 1, then the VXLAN-GPE header is followed by an IPv4 header 426 (there is no Inner Ethernet header). The Inner Flowspec matches only 427 if the Inner AFI is 1 and the Inner Flowspec matches. 429 If the VXLAN-GPE header P flag is one and that header's next protocol 430 field is 2, then the VXLAN-GPE header is followed by an IPv6 header 431 (there is no Inner Ethernet header). The Inner Flowspec match only 432 if the Inner AFI is 2 and the Inner Flowspec matches. 434 2.3.3 NVGRE 436 NVGRE [RFC7637] is similar to VXLAN except that the UDP header and 437 VXLAN header immediately after the outer IP header are replaced by a 438 GRE (Generic Router Encapsulation) header. The GRE header as used in 439 NVGRE has no Checksum or Reserved1 field as shown in [RFC2890] but 440 there are Virtual Subnet ID and Flow ID fields in place of what is 441 labeled in [RFC2890] as the Key field. Processing and restrictions 442 for NVGRE are as in Section 2.3.1 eliminating references to a UDP 443 header and replacing references to the VXLAN header and its VN ID 444 with references to the GRE header and its VN ID (VSID) and Flow ID. 446 2.3.4 L2TPv3 448 The headers on an L2TPv3 [RFC3931] packets are an outer Ethernet 449 header, an outer IP header, the L2TPv3 header, an inner Ethernet 450 header, and possibly an inner IP header if indicated by the inner 451 Ethernet header EtherType. The Outer Flowspec operates on the outer 452 headers that precede the L2TP Session Header. The version of IP in 453 the outer IP header is specified by either the outer AFI at the 454 beginning of the MP_REACH_NLRI or MP_UNREACH_NLRI or, if that AFI is 455 6 (L2), optionally specified by the inner AFI within that L2 456 flowspec. 458 L2TPv3 data messages and control messages both start with a Session 459 ID and are distinguished by whether the Session ID is non-zero or 460 zero, respectively. Data message filtering is further specified in 461 Section 2.3.4.1 and control message filtering is further specified in 462 Section 2.3.4.2. 464 2.3.4.1 L2TPv3 Data Messages 466 For data messages, the L2TPv3 Session Header consists of a 32-bit 467 non-zero Session ID followed by a variable length Cookie (maximum 468 length 8 octets). A Tunnel Header flowspec is assumed to apply to 469 data messages unless the first component requires a zero Session ID. 471 The Session ID and Cookie can be filtered on by using the Session and 472 Cookie flowspec components in the Tunnel Header Flowspec. To filter 473 on Cookie or even be able to bypass Cookie and parse the remainder of 474 the L2TPv3 packet, the node implementing flowspec needs to know the 475 length and/or value of the Cookie fields of interest. This is 476 negotiated at L2TPv3 session establishment and it is out of scope for 477 this document how the node would learn this information. Of course, 478 if flowspec is being used for DDOS mitigation and the Cookie has a 479 fixed length and/or value in the DDOS traffic, this could be learned 480 by inspecting that traffic. 482 If the I flag bit is zero, then no filtering is done on data beyond 483 the L2TPv3 header. If the I flag is one, indicating the presence of 484 an Inner Flowspec, and the node implementing flowspec does not know 485 the length of the L2TPv3 header Cookie, the match fails. If that node 486 does know the length of that Cookie, the Inner Flowspec if matched 487 against the headers at the beginning of that data using the Inner 488 AFI. If that Inner AFI is 1 or 2, then an inner IP header is required 489 and filtering can be done on that IPv4 or IPv6 header respectively. 490 If the Inner AFI is 6, filtering is done on the inner Ethernet header 491 and, if an IPv4 or IPv6 inner AFI is specified within the inner L2 492 flowspec, done on the following IP header [FlowSpecL2]. 494 2.3.4.2 L2TPv3 Control Messages 496 Control messages are distinguished by starting with a zero 32-bit 497 Session ID. L2TPv3 control message flowspecs MUST start with a 498 Session component that requires Session to be zero. For L2TPv3 499 control messages, there is no Cookie but there are L2TPv3 flags, a 500 3-bit Version field, a 32-bit Control Connection ID, and 16-bit Ns 501 and Nr sequence numbers. These can be tested using the Tunnel Header 502 Flags, L2TP Control Version, L2TPv3 Control Connection ID, L2TPv3 Ns, 503 and L2TPv3 Nr flowspec components for the Tunnel Header Flowspec. 505 2.3.5 GRE 507 Generic Router Encapsulation (GRE [RFC2890]) is another type of 508 encapsulation. The Outer Flowspec operates on the outer headers that 509 precede the GRE header. The version of IP is specified by the outer 510 AFI at the beginning of the MP_REACH_NLRI or MP_UNREACH_NLRI. 512 If the I flag bit is zero, no filtering is done on data after the GRE 513 header. If the I flag bit is one in the tunnel flowspec, then there 514 is an inner AFI and inner flowspec and the Protocol Type field of the 515 GRE header must match the Inner AFI as follows for the tunnel 516 Flowspec to match: 518 GRE Protocol Type Inner AFI 519 ------------------- ----------- 520 0x0800 (IPv4) 1 521 0x86DD (IPv6) 2 522 0x6558 6 524 With the I flag a one and the Inner AFI and GRE Protocol Type fields 525 match, the Inner Flowspec is used to filter the inner IP headers 526 (Inner AFI=1 or 2) or the inner Ethernet header and optionally a 527 following IP header (Inner AFI=6). 529 2.3.6 IP-in-IP 531 IP-in-IP encapsulation [RFC2003] is indicated when an outer IP header 532 indicates an inner IP IPv4 or IPv6 header by the value of the outer 533 IP header's Protocol (IPv4) or Next Protocol (IPv6) field. 535 The IP version of the outer IP header (IPv4 or IPv6) matched is 536 indicated by an AFI of 1 or 2 at the beginning of the MP_REACH_NLRI 537 or MP_UNREACH_NLRI while if that AFI is 6, it indicates a match on 538 the out Ethernet header and, optionally, the following IP Header 539 [FlowSpecL2]. The IP version of the inner IP header is indicated by 540 the Inner AFI and the Inner Flowspec applies to the inner IP header. 542 There are no fields that can be matched by the Tunnel Header Flowspec 543 in the case of IP-in-IP. 545 2.4 Tunneled Traffic Actions 547 The traffic filtering actions previously specified in [RFC5575bis] 548 and [FlowSpecL2] are used for tunneled traffic. For Traffic Marking 549 in NVO3, only the DSCP in the outer header can be modified. 551 3. Order of Traffic Filtering Rules 553 The following rules determine which flowspec takes precedence where 554 one or more are applicable and at least one of the applicable 555 flowspecs is a tunneled traffic flowspec: 557 - In comparing an applicable tunneled traffic flow specification 558 with an applicable non-tunneled flow specification, the tunneled 559 specification has precedence. 561 - If comparing tunneled traffic flow specifications, if all are 562 applicable, the tunnel types will be the same. Any that have a 563 Routing Distinguisher will take precedence over those without a 564 Routing Distinguisher. Of those with a Routing Distinguisher, all 565 applicable flowspecs will have the same Routing Distinguisher. 567 - At this point in the process, all remaining contenders for the 568 highest precedence will either not have a Routing Distinguisher or 569 have equal Routing Distinguishers. If more than one contender 570 remain, those with an L2 Outer Flowspec take precedence over those 571 with an L3 Outer Flowspec. If the Outer Flowspec AFI is the same, 572 their order of precedence is determined by comparing the Outer 573 Flowspecs as described in [RFC5575bis] and [FlowSpecV6] for AFI 574 for 1 or 2 respectively or [FlowSpecL2] for AFI=6. 576 - If the Outer Flowspecs are equal, then the Tunnel Header Flowspecs 577 are compared using the usual sequential component comparison 578 process [RFC5575bis]. 580 - If the Tunnel Header Flowspecs are equal then compare the "I" 581 flag. Those with an Inner Flowspec take precedence over those 582 without an Inner Flowspec. If you get to this stage in the 583 ordering process, those without an Inner Flowspec are equal. For 584 those with an Inner Flowspec, check the Inner AFI. An L2 Inner AFI 585 (AFI=6) takes precedence over an L3 Inner AFI. 587 - If the Inner AFIs are equal, precedence is determined by comparing 588 the Inner Flowspecs as described in [FlowSpecL2] for L2 or 589 [RFC5575bis] for L3. 591 4. Flow Spec Validation 593 Flowspecs received over AFI=1/SAFI=TBD1 or AFI=2/SFAI=TBD1 are 594 validated, using only the Outer Flowspec, against routing 595 reachability received over AFI=1/SAFI=133 and AFI=2/SAFI=133 596 respectively, as modified by [FlowSpecOID]. 598 5. Security Considerations 600 No new security issues are introduced to the BGP protocol by this 601 specification. 603 For general Flowspec security considerations, see [rfc5575bis]. 605 6. IANA Considerations 607 IANA is requested to assign a new SAFI as follows: 609 Value Description Reference 610 ----- ------------------------------------------ --------------- 611 TBD1 Tunneled traffic flow specification rules [This document] 613 IANA is requested to create a Tunnel Header Flow Spec Component Type 614 registry on the Flow Spec Component Types registries web page as 615 follows: 617 Name: Tunnel Flow Spec Component Types 618 Reference: [this document] 619 Registration Procedures: 620 0 Reserved 621 1-127 Specification Required 622 128-254 First Come First Served 623 255 Reserved 625 Initial contents: 626 Type Name Reference 627 ----- -------------- ----------------- 628 0 reserved [this document] 629 1 VN ID [this document] 630 2 Flow ID [this document] 631 3 Session [this document] 632 4 Cookie [this document] 633 5 Tunnel Header Flags [this document] 634 6 L2TP Control Version [this document] 635 7 L2TPv3 Control Connection ID 636 [this document] 637 8 L2TPv3 Ns [this document] 638 9 L2TPv3 Nr [this document] 639 10-254 unassigned [this document] 640 255 reserved [this document] 642 Normative References 644 [RFC2003] - Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 645 10.17487/RFC2003, October 1996, . 648 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 650 March 1997, . 652 [RFC2474] - Nichols, K., Blake, S., Baker, F., and D. Black, 653 "Definition of the Differentiated Services Field (DS Field) in 654 the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, 655 December 1998, . 657 [RFC2890] - Dommety, G., "Key and Sequence Number Extensions to GRE", 658 RFC 2890, DOI 10.17487/RFC2890, September 2000, 659 . 661 [RFC3931] - Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 662 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, 663 DOI 10.17487/RFC3931, March 2005, . 666 [RFC4271] - Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 667 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 668 10.17487/RFC4271, January 2006, . 671 [RFC4760] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 672 "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 673 10.17487/RFC4760, January 2007, . 676 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 677 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 678 eXtensible Local Area Network (VXLAN): A Framework for 679 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 680 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 683 [RFC7637] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network 684 Virtualization Using Generic Routing Encapsulation", RFC 7637, 685 DOI 10.17487/RFC7637, September 2015, . 688 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 689 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 690 2017, . 692 [FlowSpecL2] - W. Hao, et al, "Dissemination of Flow Specification 693 Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in 694 progress. 696 [FlowSpecOID] - J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P. 697 Mohapatra, "Revised Validation Procedure for BGP Flow 698 Specifications", draft-ietf-idr-bgp-flowspec-oid, work in 699 progress. 701 [FlowSpecV6] - R. Raszuk, et al, "Dissemination of Flow Specification 702 Rules for IPv6", draft-ietf-idr-flow-spec-v6, work in progress. 704 [RFC5575bis] - Hares, S., Loibl, C., Raszuk, R., McPherson, D., 705 Bacher, M., "Dissemination of Flow Specification Rules", 706 draft-ietf-idr-rfc5575bis, work in progress. 708 Informative References 710 [RFC8014] - Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 711 Narten, "An Architecture for Data-Center Network Virtualization 712 over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December 713 2016, . 715 [GPE] - P. Quinn, et al, "Generic Protocol Extension for VXLAN", 716 draft-ietf-nvo3-vxlan-gpe, work in progress. 718 Acknowledgments 720 The authors wish to acknowledge the important contributions of Jeff 721 Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, Robert Raszuk, 722 and Lucy Yong. 724 Authors' Addresses 726 Donald Eastlake 727 Futurewei Technologies 728 2386 Panoramic Circle 729 Apopka, FL 32703 USA 731 Tel: +1-508-333-2270 732 Email: d3e3e3@gmail.com 734 Weiguo Hao 735 Huawei Technologies 736 101 Software Avenue, 737 Nanjing 210012 China 739 Email: haoweiguo@huawei.com 741 Shunwan Zhuang 742 Huawei Technologies 743 Huawei Bld., No.156 Beiqing Rd. 744 Beijing 100095 China 746 Email: zhuangshunwan@huawei.com 748 Zhenbin Li 749 Huawei Technologies 750 Huawei Bld., No.156 Beiqing Rd. 751 Beijing 100095 China 753 Email: lizhenbin@huawei.com 755 Rong Gu 756 China Mobile 758 Email: gurong_cmcc@outlook.com 760 Copyright, Disclaimer, and Additional IPR Provisions 762 Copyright (c) 2020 IETF Trust and the persons identified as the 763 document authors. All rights reserved. 765 This document is subject to BCP 78 and the IETF Trust's Legal 766 Provisions Relating to IETF Documents 767 (http://trustee.ietf.org/license-info) in effect on the date of 768 publication of this document. Please review these documents 769 carefully, as they describe your rights and restrictions with respect 770 to this document. Code Components extracted from this document must 771 include Simplified BSD License text as described in Section 4.e of 772 the Trust Legal Provisions and are provided without warranty as 773 described in the Simplified BSD License.