idnits 2.17.1 draft-ietf-idr-flowspec-nvo3-09.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 (April 12, 2020) is 1446 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: October 11, 2020 April 12, 2020 11 BGP Dissemination of 12 Flow Specification Rules for Tunneled Traffic 13 draft-ietf-idr-flowspec-nvo3-09 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....................................7 52 2.2 Tunnel Header Component Code Points....................8 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.5 GRE.................................................12 59 2.3.6 IP-in-IP............................................12 60 2.4 Tunneled Traffic Actions..............................13 62 3. Order of Traffic Filtering Rules.......................14 63 4. Flow Spec Validation...................................15 65 5. Security Considerations................................15 66 6. IANA Considerations....................................15 68 Normative References......................................16 69 Informative References....................................17 71 Acknowledgments...........................................18 72 Authors' Addresses........................................18 74 1. Introduction 76 BGP Flow Specification (flowspec [RFC5575bis]) is an extension to BGP 77 that supports the dissemination of traffic flow specification rules. 78 It uses the BGP control plane to simplify the distribution of Access 79 Control Lists (ACLs) and allows new filter rules to be injected to 80 all BGP peers simultaneously without changing router configuration. A 81 typical application of BGP flowspec is to automate the distribution 82 of traffic filter lists to routers for Distributed Denial of Service 83 (DDOS) mitigation. 85 BGP flowspec defines BGP Network Layer Reachability Information 86 (NLRI) formats used to distribute traffic flow specification rules. 87 AFI=1/SAFI=133 is for IPv4 unicast filtering. AFI=1/SAFI=134 is for 88 IPv4 BGP/MPLS VPN filtering. [FlowSpecV6] and [FlowSpecL2] extend the 89 flowspec rules for IPv6 and Layer 2 Ethernet packets respectively. 90 None of these previously defined flow specifications are suitable for 91 matching in cases of tunneling or encapsulation where there might be 92 duplicates of a layer of header such as two IPv6 headers in IP-in-IP 93 or a nested header sequence such as the Layer 2 and 3 headers 94 encapsulated in VXLAN [RFC7348]. 96 In the cloud computing era, multi-tenancy has become a core 97 requirement for data centers. It is increasingly common to see 98 tunneled traffic with a field to distinguish tenants. An example is 99 the Network Virtualization Over Layer 3 (NVO3 [RFC8014]) overlay 100 technology that can satisfy multi-tenancy key requirements. VXLAN 101 [RFC7348] and NVGRE [RFC7637] are two typical NVO3 encapsulations. 102 Other encapsulations such as IP-in-IP or GRE may be encountered. 103 Because these tunnel / overlay technologies involving an additional 104 level of encapsulation, flow specification that can match on the 105 inner header as well as the outer header and fields in any tunneling 106 header are needed. 108 In summary, Flow Specifications should be able to include inner 109 nested header information as well as fields specific to the type of 110 tunneling in use such as virtual network / tenant ID. This draft 111 specifies methods for accomplishing this using SAFI=TBD1 and a new 112 NLRI encoding. 114 1.1 Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 The reader is assumed to be familiar with BGP terminology. The 123 following terms and acronyms are used in this document with the 124 meaning indicated: 126 ACL - Access Control List 128 DDoS - Distributed Denial of Service (Attack) 130 DSCP - Differentiated Services Code Point 132 GRE - Generic Router Encapsulation [RFC2890] 134 L2TPv3 - Layer Two Tunneling Protocol - Version 3 [RFC3931] 136 NLRI - Network Layer Reachability Information 138 NVGRE - Network Virtualization Using Generic Routing Encapsulation 139 [RFC7637] 141 NVO3 - Network Virtual Overlay Layer 3 [RFC8014] 143 PE - Provider Edge 145 VN - virtual network 147 VXLAN - Virtual eXtensible Local Area Network [RFC7348] 149 2. Tunneled Traffic Flow Specification NLRI 151 The Flowspec rules specified in [RFC5575bis], [FlowSpecV6], and 152 [FlowSpecL2] cannot match or filter tunneled traffic based on the 153 tunnel type, any tunnel header fields, or headers past the tunnel 154 header. To enable flow specification of tunneled traffic, a new SAFI 155 (TBD1) and NLRI encoding are introduced. This encoding, shown in 156 Figure 1, enables flow specification of more than one layer of header 157 when needed. 159 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 160 | Length 2 octets | 161 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 162 | Tunnel Type 2 octets | 163 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 164 Flags: 165 +--+--+--+--+--+--+--+--+ 166 | D| I| Reserved | 1 octet 167 +--+--+--+--+--+--+--+--+ 168 Optional Routing Distinguisher: 169 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 170 | | 171 + + 172 | | 173 + Routing Distinguisher 8 octets + 174 | | 175 + + 176 | | 177 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 178 Outer Flowspec: 179 +--+--+--+--+--+--+--+--+ 180 | Outer Flowspec Length : 1 or 2 octets 181 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 182 | Outer Flowspec variable : 183 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 184 Tunnel Header Flowspec: 185 +--+--+--+--+--+--+--+--+ 186 | Tunnel Flowspec Length: 1 or 2 octets 187 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 188 | Tunnel Header Flowspec variable : 189 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 190 Optional Inner Flowspec: 191 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 192 | Inner AFI 2 octets | 193 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 194 | Inner Flowspec Length : 1 or 2 octets 195 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 196 | Inner Flowspec variable : 197 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 199 Figure 1. Tunneled Traffic Flowspec NLRI 201 Length - The NLRI Length including the Tunnel Type encoded as an 202 unsigned integer. 204 Tunnel Type - The type of tunnel using a value from the IANA BGP 205 Tunnel Encapsulation Attribute Tunnel Types registry. 207 Flags: D bit - Indicates the presence of the Routing Distinguisher 208 (see below). 210 Flags: I bit - Indicates the presence of the Inner AFI and the Inner 211 Flowspec (see below). 213 Flags: Reserved - Six bits that MUST be sent as zero and ignored on 214 receipt. 216 Routing Distinguisher - If the outer Layer 3 address belongs to a 217 BGP/MPLS VPN, the routing distinguisher is included to indicate 218 traffic filtering within that VPN. Because NVO3 outer layer 219 addresses normally belong to a public network, a Route 220 Distinguisher field is normally not needed for NVO3. 222 Outer Flowspec / Length - The flow specification for the outer 223 header. The length is encoded as provided in Section 4.1 of 224 [RFC5575bis]. The AFI for the Outer Flowspec is the AFI at the 225 beginning of the BGP multiprotocol MP_REACH_NLRI or 226 MP_UNREACH_NLRI containing the tunneled traffic flow 227 specification NLRI. 229 Tunnel Header Flowspec / Length - The flow specification for the 230 tunneling header. This specifies matching criterion on tunnel 231 header fields. The tunnel type itself is indicated by the 232 Tunnel Type field above. For some types of tunneling, such as 233 IP-in-IP, there may be no tunnel header fields. For other types 234 of tunneling, there may be several tunnel header fields on 235 which matching can be specified with this flowspec. 237 Inner AFI - Depending on the Tunnel Type, there may be an Inner AFI 238 that indicates the address family for the inner flow 239 specification. There is no need for a SAFI as the treatment of 240 this inner AFI and following flowspec is indicated by the outer 241 SAFI TBD1, the SAFI for a tunneled traffic flow specification. 243 Inner Flowspec / Length - Depending on the Tunnel Type, there may be 244 an inner flowspec for the header level encapsulated within the 245 outer header. The length is encoded as provided in Section 4.1 246 of [RFC5575bis]. 248 A Tunneled Traffic Flowspec matches if the Outer Flowspec, Tunnel 249 Header Flowspec, and Inner Flowspec, if present, all match and the 250 Routing Distinguisher applies, if present. An omitted (as can be done 251 for the Inner Flowspec) or null flowspec is considered to always 252 match. 254 2.1 The SAFI Code Point 256 Use of the tunneled traffic flow specification NLRI format is 257 indicated by SAFI=TBD1. This is used in conjunction with the AFI for 258 the outer header, that is AFI=1 for IPv4, AFI=2 for IPv6, and AFI=6 259 for Layer 2. 261 2.2 Tunnel Header Component Code Points 263 For flowspec based on most tunneling, there are tunnel header fields 264 that can be tested by components that appear in the Tunnel Header 265 Flowspec field. The types for these components are specified in a 266 Tunnel Header Flowspec component registry (see Section 6). 268 All Tunnel Header field components defined below and all such 269 components added in the future have a TLV structure as follows: 270 - one octet of type followed by 271 - one octet giving the length as an unsigned integer number of 272 octets followed by 273 - the specific matching operations/values as determined by the 274 type. 276 Type 1 - VN ID 277 Encoding: . 279 Defines a list of {operation, value} pairs used to match the 280 24-bit VN ID that is used as the tenant identification in some 281 tunneling headers. For VXLAN encapsulation, the VN ID is the 282 VNI. For NVGRE encapsulation, the VN ID is the VSID. op is 283 encoded as specified in Section 4.2.3 of [RFC5575bis]. Values 284 are encoded as a 1, 2, or 4 octet quantity. If value is 285 24-bits, it is left-justified in the first 3 octets of the 286 value and the last value octet MUST be sent as zero and ignored 287 on receipt. 289 Type 2 - Flow ID 290 Encoding: 292 Defines a list of {operation, value} pairs used to match 8-bit 293 Flow ID fields which are currently only useful for NVGRE 294 encapsulation. op is encoded as specified in Section 4.2.3 of 295 [RFC5575bis]. Values are encoded as a 1-octet quantity. 297 Type 3 - Session 298 Encoding: 300 Defines a list of {operation, value} pairs used to match a 301 32-bit Session field. This field is called Key in GRE [RFC2890] 302 encapsulation and Session ID in L2TPv3 encapsulation. op is 303 encoded as specified in Section 4.2.3 of [RFC5575bis]. Values 304 are encoded as a 1, 2, or 4 octet quantity. 306 Type 4 - Cookie 307 Encoding: 309 Defines a list of {operation, value} pairs used to match a 310 variable length Cookie field. This is only useful in L2TPv3 311 encapsulation. op is encoded as specified in Section 4.2.3 of 312 [RFC5575bis]. Values are encoded as a 1, 2, 4, or 8 octet 313 quantity. If the Cookie does not fit exactly into the value 314 length, it is left justified, that is, padded with following 315 octets the MUST be sent as zero and ignored on receipt. 317 Type 5 - VXLAN-GPE Flags 318 Encoding: 320 Defines a list of {operation, value} pairs used to match 321 against the VXLAN-GPE flags field. op is encoded as in Section 322 4.2.9 of [RFC5575bis]. bitmask is encoded as 1 octet. 324 2.3 Specific Tunnel Types 326 The following subsections describe how to handle flow specification 327 for several specific tunnel types. 329 2.3.1 VXLAN 331 The headers on a VXLAN [RFC7348] data packet are an outer Ethernet 332 header, an outer IP header, a UDP header, the VXLAN header, and an 333 inner Ethernet header. This inner Ethernet header is frequently, but 334 not always, followed by an inner IP header. If the tunnel type is 335 VXLAN, the I flag MUST be set. 337 If the outer Ethernet header is not being matched, the version (IPv4 338 or IPv6) of the outer IP header is indicated by the AFI at the 339 beginning of the multiprotocol MP_REACH_NLRI or MP_UNREACH_NLRI 340 containing the tunneled traffic flow specification NLRI. The outer 341 Flowspec is used to filter the outer headers including, if desired, 342 the UDP header. 344 If the outer Ethernet header is being matched, then the initial AFI 345 is 6 [FlowSpecL2] and the Outer Flowspec can match the outer Ethernet 346 header, specify the IP version of the outer IP header, and match that 347 IP header including, if desired, the UDP header. 349 The Tunnel Header Flowspec can be used to filter on the VXLAN header 350 VN ID (VNI). 352 The Inner Flowspec can be used on the Inner Ethernet header 353 [FlowSpecL2] and any following IP header. If the inner AFI is 6, 354 then the inner Flowspec provides filtering of the Layer 2 header, 355 indicates whether filtering on a following IPv4 or IPv6 header is 356 desired, and if it is desired provides the Flowspec components for 357 that filtering. If the Inner AFI is 1 or 2, the Inner Ethernet 358 header is not matched and to match the Flowspec the Inner Ethernet 359 header must be followed by an IPv4 or IPv6 header, respectively, and 360 the inner Flowspec is used to filter that inner IP header. 362 The inner MAC/IP address is associated with the VN ID. In the NVO3 363 terminating into a VPN scenario, if multiple access VN IDs map to one 364 VPN instance, one shared VN ID can be carried in the flowspec rule to 365 enforce the rule on the entire VPN instance and the shared VN ID and 366 VPN correspondence should be configured on each VPN PE beforehand. In 367 this case, the function of the Layer 3 VN ID is the same as a Route 368 Distinguisher: it acts as the identification of the VPN instance. 370 2.3.2 VXLAN-GPE 372 VXLAN-GPE [GPE] is similar to VXLAN. The VXLAN-GPE header is the same 373 size as the VXLAN header but has been extended from the VXLAN header 374 by specifying a number of bits that are reserved in the VXLAN header. 375 In particular, a number of additional flag bits are specified and a 376 Next Protocol field is added that is valid if the P flag bit is set. 377 These flags bits can be tested using the VXLAN-GPE Flags flowspec 378 component defined above. VXLAN and VXLAN-GPE are distinguished by the 379 port number in the UDP header the precedes the VXLAN or VXLAN-GPE 380 headers. 382 If the VXLAN-GPE header P flag is zero, then that header is followed 383 by the same sequence as for VXLAN and the same flowspec choices apply 384 (see Section 2.3.1). 386 If the VXLAN-GPE header P flag is one and that header's next protocol 387 field is 1, then the VXLAN-GPE header is followed by an IPv4 header. 388 The Inner Flowspec matches only if the Inner AFI is 1 and the Inner 389 Flowspec matches. 391 If the VXLAN-GPE header P flag is one and that header's next protocol 392 field is 2, then the VXLAN-GPE header is followed by an IPv6 header. 393 The Inner Flowspec match only if the Inner AFI is 2 and the Inner 394 Flowspec matches. 396 2.3.3 NVGRE 398 NVGRE [RFC7637] is very similar to VXLAN except that the UDP header 399 and VXLAN header immediately after the outer IP header are replaced 400 by a GRE (Generic Router Encapsulation) header. The GRE header as 401 used in NVGRE has no Checksum or Reserved1 field as shown in 402 [RFC2890] but there are Virtual Subnet ID and Flow ID fields in place 403 of what is labeled in [RFC2890] as the Key field. Processing and 404 restrictions for NVGRE are as in Section 2.3.1 eliminating references 405 to a UDP header and replacing references to the VXLAN header and its 406 VN ID with references to the GRE header and its VN ID (VSID) and Flow 407 ID. 409 2.3.4 L2TPv3 411 The headers on an L2TPv3 [RFC3931] packets are an outer Ethernet 412 header, an outer IP header, the L2TPv3 header, an inner Ethernet 413 header, and possibly an inner IP header if indicated by the inner 414 Ethernet header EtherType. The Outer Flowspec operates on the outer 415 headers that precede the GRE header. The version of IP in the outer 416 IP header is specified by either the outer AFI at the beginning of 417 the MP_REACH_NLRI or MP_UNREACH_NLRI or, if that AFI is 6 (L2), 418 optionally specified by the inner AFI within that L2 flowspec. 420 The L2TPv3 header consists of a 32-bit Session ID followed by a 421 variable length Cookie (maximum length 8 octets). The Session ID and 422 Cookie can be filtered for by using the Session and Cookie flowspec 423 components in the Tunnel Header Flowspec. To filter on Cookie or even 424 be able to bypass Cookie and parse the remainder of the L2TPv3 425 packet, the node implementing flowspec needs to know the length 426 and/or value of the Cookie fields of interest. This is negotiated at 427 L2TPv3 session establishment and it is out of scope for this document 428 how the node would learn this information. Of course, if flowspec is 429 being used for DDOS mitigation and the Cookie has a fixed length 430 and/or value in the DDOS traffic, this could be learned by inspecting 431 that traffic. 433 If the I flag bit is zero, then no filtering is done on data beyond 434 the L2TPv3 header. If the I flag is one, indicating the presence of 435 an Inner Flowspec, and the node implementing flowspec does not know 436 the length of the L2TPv3 header Cookie, the match fails. If that node 437 does know the length of that Cookie, the Inner Flowspec if matched 438 against the headers at the beginning of that data using the Inner 439 AFI. If that Inner AFI is 1 or 2, then an inner IP header is required 440 and filtering can be done on the Ethernet header immediately after 441 the L2TPv3 header and the following IPv4 or IPv6 headers 442 respectively. If the Inner AFI is 6, filtering is done on the inner 443 Ethernet header and, if a non-zero inner AFI is specified within the 444 inner L2 flowspec, done on the following IP header [FlowSpecL2]. 446 2.3.5 GRE 448 Generic Router Encapsulation (GRE [RFC2890]) is another type of 449 encapsulation. The Outer Flowspec operates on the outer headers that 450 precede the GRE header. The version of IP is specified by the outer 451 AFI at the beginning of the MP_REACH_NLRI or MP_UNREACH_NLRI. 453 If the I flag bit is zero, no filtering is done on data after the GRE 454 header. If the I flag bit is one, then there is an inner AFI and 455 flowspec and the Protocol Type field of the GRE header must match the 456 Inner AFI as follows for the Flowspec to match: 458 GRE Protocol Type Inner AFI 459 ------------------- ----------- 460 0x0800 (IPv4) 1 461 0x86DD (IPv6) 2 462 0x6558 6 464 With the I flag a one and the Inner AFI and GRE Protocol Type fields 465 match, the Inner Flowspec is used to filter the inner IP headers 466 (Inner AFI=1 or 2) or the inner Ethernet header and optionally a 467 following IP header (Inner AFI=6). 469 2.3.6 IP-in-IP 471 IP-in-IP encapsulation is indicated when an outer IP header indicates 472 an inner IP IPv4 or IPv6 header by the value of the outer IP header's 473 Protocol (IPv4) or Next Protocol (IPv6) field. 475 The IP version of the outer IP header (IPv4 or IPv6) matched is 476 indicated by an AFI of 1 or 2 at the beginning of the MP_REACH_NLRI 477 or MP_UNREACH_NLRI while if that AFI is 6, it indicates a match on 478 the out Ethernet header and, optionally, the following IP Header 479 [FlowSpecL2]. The IP version of the inner IP header is indicated by 480 the Inner AFI and the Inner Flowspec applies to the inner IP header. 482 There are no fields that can be matched by the Tunnel Header Flowspec 483 in the case of IP-in-IP. 485 2.4 Tunneled Traffic Actions 487 The traffic filtering actions previously specified in [RFC5575bis] 488 and [FlowSpecL2] are used for tunneled traffic. For Traffic Marking 489 in NVO3, only the DSCP in the outer header can be modified. 491 3. Order of Traffic Filtering Rules 493 The following rules determine which flowspec takes precedence where 494 one or more are applicable and at least one of the applicable 495 flowspecs is a tunneled traffic flowspec: 497 - In comparing an applicable tunneled traffic flow specification 498 with an applicable non-tunneled flow specification, the tunneled 499 specification has precedence. 501 - If comparing tunneled traffic flow specifications, if all are 502 applicable, the tunnel types will be the same. Any that have a 503 Routing Distinguisher will take precedence over those without a 504 Routing Distinguisher. Of those with a Routing Distinguisher, all 505 applicable flowspecs will have the same Routing Distinguisher. 507 - At this point in the process, all remaining contenders for the 508 highest precedence will either not have a Routing Distinguisher or 509 have equal Routing Distinguishers. If more than one contender 510 remain, those with an L2 Outer Flowspec take precedence over those 511 with an L3 Outer Flowspec. If the Outer Flowspec AFI is the same, 512 their order of precedence is determined by comparing the Outer 513 Flowspecs as described in [RFC5575bis] and [FlowSpecV6] for AFI 514 for 1 or 2 respectively or [FlowSpecL2] for AFI=6. 516 - If the Outer Flowspecs are equal, then the Tunnel Header Flowspecs 517 are compared using the usual sequential component comparison 518 process [RFC5575bis]. 520 - If the Tunnel Header Flowspecs are equal then compare the "I" 521 flag. Those with an Inner Flowspec take precedence over those 522 without an Inner Flowspec. If you get to this stage in the 523 ordering process, those without an Inner Flowspec are equal. For 524 those with an Inner Flowspec, check the Inner AFI. An L2 Inner AFI 525 (AFI=6) takes precedence over an L2 Inner AFI. 527 - If the Inner AFIs are equal, precedence is determined by comparing 528 the Inner Flowspecs as described in [FlowSpecL2] for L2 or 529 [RFC5575bis] for L3. 531 4. Flow Spec Validation 533 Flowspecs received over AFI=1/SAFI=TBD1 or AFI=2/SFAI=TBD1 are 534 validated, using only the Outer Flowspec, against routing 535 reachability received over AFI=1/SAFI=133 and AFI=2/SAFI=133 536 respectively, as modified by [FlowSpecOID]. 538 5. Security Considerations 540 No new security issues are introduced to the BGP protocol by this 541 specification. 543 For general Flowspec security considerations, see [rfc5575bis]. 545 6. IANA Considerations 547 IANA is requested to assign a new SAFI as follows: 549 Value Description Reference 550 ----- ------------------------------------------ --------------- 551 TBD1 Tunneled traffic flow specification rules [This document] 553 IANA is requested to create a Tunnel Header Flow Spec Component Type 554 registry on the Flow Spec Component Types registries web page as 555 follows: 557 Name: Tunnel Flow Spec Component Types 558 Reference: [this document] 559 Registration Procedures: 560 0 Reserved 561 1-127 Specification Required 562 128-254 First Come First Served 563 255 Reserved 565 Initial contents: 566 Type Name Reference 567 ----- -------------- ----------------- 568 0 reserved [this document] 569 1 VN ID [this document] 570 2 Flow ID [this document] 571 3 Session [this document] 572 4 Cookie [this document] 573 5 VXLAN-GPE Flags [this document] 574 6-254 unassigned [this document] 575 255 reserved [this document] 577 Normative References 579 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 581 March 1997, . 583 [RFC2890] - Dommety, G., "Key and Sequence Number Extensions to GRE", 584 RFC 2890, DOI 10.17487/RFC2890, September 2000, 585 . 587 [RFC3931] - Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 588 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, 589 DOI 10.17487/RFC3931, March 2005, . 592 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 593 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 594 eXtensible Local Area Network (VXLAN): A Framework for 595 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 596 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 599 [RFC7637] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network 600 Virtualization Using Generic Routing Encapsulation", RFC 7637, 601 DOI 10.17487/RFC7637, September 2015, . 604 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 605 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 606 2017, . 608 [FlowSpecL2] - W. Hao, et al, "Dissemination of Flow Specification 609 Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in 610 progress. 612 [FlowSpecOID] - J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P. 613 Mohapatra, "Revised Validation Procedure for BGP Flow 614 Specifications", draft-ietf-idr-bgp-flowspec-oid, work in 615 progress. 617 [FlowSpecV6] - R. Raszuk, et al, "Dissemination of Flow Specification 618 Rules for IPv6", draft-ietf-idr-flow-spec-v6, work in progress. 620 [RFC5575bis] - Hares, S., Loibl, C., Raszuk, R., McPherson, D., 621 Bacher, M., "Dissemination of Flow Specification Rules", draft- 622 ietf-idr-rfc5575bis, Work in progress. 624 Informative References 626 [RFC8014] - Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 627 Narten, "An Architecture for Data-Center Network Virtualization 628 over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December 629 2016, . 631 [GPE] - P. Quinn, et al, "Generic Protocol Extension for VXLAN", 632 draft-ietf-nvo3-vxlan-gpe, work in progress. 634 Acknowledgments 636 The authors wish to acknowledge the important contributions of Jeff 637 Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, Robert Raszuk, 638 and Lucy Yong. 640 Authors' Addresses 642 Donald Eastlake 643 Futurewei Technologies 644 2386 Panoramic Circle 645 Apopka, FL 32703 USA 647 Tel: +1-508-333-2270 648 Email: d3e3e3@gmail.com 650 Weiguo Hao 651 Huawei Technologies 652 101 Software Avenue, 653 Nanjing 210012 China 655 Email: haoweiguo@huawei.com 657 Shunwan Zhuang 658 Huawei Technologies 659 Huawei Bld., No.156 Beiqing Rd. 660 Beijing 100095 China 662 Email: zhuangshunwan@huawei.com 664 Zhenbin Li 665 Huawei Technologies 666 Huawei Bld., No.156 Beiqing Rd. 667 Beijing 100095 China 669 Email: lizhenbin@huawei.com 671 Rong Gu 672 China Mobile 674 Email: gurong_cmcc@outlook.com 676 Copyright, Disclaimer, and Additional IPR Provisions 678 Copyright (c) 2020 IETF Trust and the persons identified as the 679 document authors. All rights reserved. 681 This document is subject to BCP 78 and the IETF Trust's Legal 682 Provisions Relating to IETF Documents 683 (http://trustee.ietf.org/license-info) in effect on the date of 684 publication of this document. Please review these documents 685 carefully, as they describe your rights and restrictions with respect 686 to this document. Code Components extracted from this document must 687 include Simplified BSD License text as described in Section 4.e of 688 the Trust Legal Provisions and are provided without warranty as 689 described in the Simplified BSD License.