idnits 2.17.1 draft-ietf-idr-flowspec-nvo3-11.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 (December 1, 2020) is 1241 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: May 31, 2021 December 1, 2020 11 BGP Dissemination of 12 Flow Specification Rules for Tunneled Traffic 13 draft-ietf-idr-flowspec-nvo3-11 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 74 Authors' Addresses........................................20 76 1. Introduction 78 BGP Flow Specification (flowspec [RFC5575bis]) is an extension to BGP 79 that supports the dissemination of traffic flow specification rules. 80 It uses the BGP control plane to simplify the distribution of Access 81 Control Lists (ACLs) and allows new filter rules to be injected to 82 all BGP peers simultaneously without changing router configuration. A 83 typical application of BGP flowspec is to automate the distribution 84 of traffic filter lists to routers for Distributed Denial of Service 85 (DDOS) mitigation. 87 BGP flowspec defines BGP Network Layer Reachability Information 88 (NLRI) formats used to distribute traffic flow specification rules. 89 AFI=1/SAFI=133 is for IPv4 unicast filtering. AFI=1/SAFI=134 is for 90 IPv4 BGP/MPLS VPN filtering [RFC5575bis]. [FlowSpecV6] and 91 [FlowSpecL2] extend the flowspec rules for IPv6 and Layer 2 Ethernet 92 packets respectively. None of these previously defined flow 93 specifications are suitable for matching in cases of tunneling or 94 encapsulation where there might be duplicates of a layer of header 95 such as two IPv6 headers in IP-in-IP [RFC2003] or a nested header 96 sequence such as the Layer 2 and 3 headers encapsulated in VXLAN 97 [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. 117 1.1 Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 The reader is assumed to be familiar with BGP terminology [RFC4271] 126 [RFC4760]. The following terms and acronyms are used in this document 127 with the meaning indicated: 129 ACL - Access Control List 131 DDoS - Distributed Denial of Service (Attack) 133 DSCP - Differentiated Services Code Point [RFC2474] 135 GRE - Generic Router Encapsulation [RFC2890] 137 L2TPv3 - Layer Two Tunneling Protocol - Version 3 [RFC3931] 139 NLRI - Network Layer Reachability Information [RFC4271] [RFC4760] 141 NVGRE - Network Virtualization Using Generic Routing Encapsulation 142 [RFC7637] 144 NVO3 - Network Virtual Overlay Layer 3 [RFC8014] 146 PE - Provider Edge 148 VN - virtual network 150 VXLAN - Virtual eXtensible Local Area Network [RFC7348] 152 2. Tunneled Traffic Flow Specification NLRI 154 The Flowspec rules specified in [RFC5575bis], [FlowSpecV6], and 155 [FlowSpecL2] cannot match or filter tunneled traffic based on the 156 tunnel type, any tunnel header fields, or headers past the tunnel 157 header. To enable flow specification of tunneled traffic, a new SAFI 158 (77) and NLRI encoding are specified. This encoding, shown in Figure 159 1, enables flow specification of more than one layer of header when 160 needed. 162 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 163 | Length 2 octets | 164 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 165 | Tunnel Type 2 octets | 166 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 167 Flags: 168 +--+--+--+--+--+--+--+--+ 169 | D| I| Reserved | 1 octet 170 +--+--+--+--+--+--+--+--+ 171 Optional Routing Distinguisher: 172 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 173 | | 174 + + 175 | | 176 + Routing Distinguisher 8 octets + 177 | | 178 + + 179 | | 180 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 181 Outer Flowspec: 182 +--+--+--+--+--+--+--+--+ 183 | Outer Flowspec Length ... 1 or 2 octets 184 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 185 | Outer Flowspec variable : 186 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 187 Tunnel Header Flowspec: 188 +--+--+--+--+--+--+--+--+ 189 | Tunnel Flowspec Length ... 1 or 2 octets 190 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 191 | Tunnel Header Flowspec variable : 192 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 193 Optional Inner Flowspec: 194 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 195 | Inner AFI 2 octets | 196 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 197 | Inner Flowspec Length ... 1 or 2 octets 198 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 199 | Inner Flowspec variable : 200 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 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 [RFC5575bis]. 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. This specifies matching criterion on tunnel 234 header fields as well as, implicitly, on the tunnel type which 235 is indicated by the Tunnel Type field above. For some types of 236 tunneling, such as IP-in-IP, there may be no tunnel header 237 fields. For other types of tunneling, there may be several 238 tunnel header fields on which matching can be specified with 239 this flowspec. 241 Inner AFI - Depending on the Tunnel Type, there may be an Inner AFI 242 that indicates the address family for the inner flow 243 specification. There is no need for a SAFI as the treatment of 244 this inner AFI and following flowspec is indicated by the outer 245 SAFI 77, the SAFI for a tunneled traffic flow specification. 247 Inner Flowspec / Length - Depending on the Tunnel Type, there may be 248 an inner flowspec for the header level encapsulated within the 249 outer header. The length is encoded as provided in Section 4.1 250 of [RFC5575bis]. 252 A Tunneled Traffic Flowspec matches if the Outer Flowspec, Tunnel 253 Type, and Tunnel Header Flowspec match and, in addition, each of the 254 following optional items that is present matches: 255 - Inner Flowspec, and 256 - Routing Distinguisher. 258 An omitted (as can be done for the Inner Flowspec) or null flowspec 259 is considered to always match. 261 2.1 The SAFI Code Point 263 Use of the tunneled traffic flow specification NLRI format is 264 indicated by SAFI=77. This is used in conjunction with the AFI for 265 the outer header, that is AFI=1 for IPv4, AFI=2 for IPv6, and AFI=6 266 for Layer 2. 268 2.2 Tunnel Header Component Code Points 270 For most cases of tunneled traffic, there are tunnel header fields 271 that can be tested by components that appear in the Tunnel Header 272 Flowspec field. The types for these components are specified in a 273 Tunnel Header Flowspec component registry (see Section 6) and the 274 initial entries in this registry are specified below. 276 All Tunnel Header field components defined below and all such 277 components added in the future have a TLV structure as follows: 278 - one octet of type followed by 279 - one octet giving the length as an unsigned integer number of 280 octets followed by 281 - the specific matching operations/values as determined by the 282 type. 284 Type 1 - VN ID 285 Encoding: . 287 Defines a list of {operation, value} pairs used to match the 288 24-bit VN ID that is used as the tenant identification in some 289 tunneling headers. For VXLAN encapsulation, the VN ID is the 290 VNI. For NVGRE encapsulation, the VN ID is the VSID. op is 291 encoded as specified in Section 4.2.3 of [RFC5575bis]. Values 292 are encoded as a 1, 2, or 4 octet quantity. If value is 293 24-bits, it is left-justified in the first 3 octets of the 294 value and the last value octet MUST be sent as zero and ignored 295 on receipt. 297 Type 2 - Flow ID 298 Encoding: 300 Defines a list of {operation, value} pairs used to match 8-bit 301 Flow ID fields which are currently only useful for NVGRE 302 encapsulation. op is encoded as specified in Section 4.2.3 of 303 [RFC5575bis]. Values are encoded as a 1-octet quantity. 305 Type 3 - Session 306 Encoding: 308 Defines a list of {operation, value} pairs used to match a 309 32-bit Session field. This field is called Key in GRE [RFC2890] 310 encapsulation and Session ID in L2TPv3 encapsulation. op is 311 encoded as specified in Section 4.2.3 of [RFC5575bis]. Values 312 are encoded as a 1, 2, or 4 octet quantity. 314 Type 4 - Cookie 315 Encoding: 317 Defines a list of {operation, value} pairs used to match a 318 variable length Cookie field. This is only useful in L2TPv3 319 encapsulation. op is encoded as specified in Section 4.2.3 of 320 [RFC5575bis]. Values are encoded as a 1, 2, 4, or 8 octet 321 quantity. If the Cookie does not fit exactly into the value 322 length, it is left justified and padded with following octets 323 that MUST be sent as zero and ignored on receipt. 325 Type 5 - Tunnel Header Flags 326 Encoding: 328 Defines a list of {operation, value} pairs used to match 329 against the tunnel header flags field. op is encoded as in 330 Section 4.2.9 of [RFC5575bis]. bitmask is encoded as 1 octet 331 for VXLAN-GPE and 2 octets for L2TP control messages. When 332 matching on L2TP control message flags, the 3-bit Version 333 subfield is treated as if it was zero. 335 Type 6 - L2TP Control Version 336 Encoding: 338 Defines a list of {operation, value} pairs used to match 339 against the L2TPv3 Control Message Version. op is encoded as in 340 Section 4.2.3 of [RFC5575bis]. Value is encoded as 1 octet. 342 Type 7 - L2TPv3 Control Connection ID 343 Encoding: 345 Defines a list of {operation, value} pairs used to match 346 against the L2TPv3 Control Connection ID. op is encoded as in 347 Section 4.2.3 of [RFC5575bis]. Value is encoded as 4 octets. 349 Type 8 - L2TPv3 Ns 350 Encoding: 352 Defines a list of {operation, value} pairs used to match 353 against the L2TPv3 control message Ns field. op is encoded as 354 in Section 4.2.3 of [RFC5575bis]. Value is encoded as 2 octets. 356 Type 9 - L2TPv3 Nr 357 Encoding: 358 Defines a list of {operation, value} pairs used to match 359 against the L2TPv3 control message Nr field. op is encoded as 360 in Section 4.2.3 of [RFC5575bis]. Value is encoded as 2 octets. 362 2.3 Specific Tunnel Types 364 The following subsections describe how to handle flow specification 365 for several specific tunnel types. 367 2.3.1 VXLAN 369 The headers on a VXLAN [RFC7348] data packet are an outer Ethernet 370 header, an outer IP header, a UDP header, the VXLAN header, and an 371 inner Ethernet header. This inner Ethernet header is frequently, but 372 not always, followed by an inner IP header. If the tunnel type is 373 VXLAN, the I flag MUST be set in the Tunneled Traffic Flow 374 Specification. 376 If the outer Ethernet header is not being matched, the version (IPv4 377 or IPv6) of the outer IP header is indicated by the AFI at the 378 beginning of the multiprotocol MP_REACH_NLRI or MP_UNREACH_NLRI 379 containing the Tunneled Traffic Flow Specification NLRI. The outer 380 Flowspec is used to filter the outer headers including, if desired, 381 the UDP header. 383 If the outer Ethernet header is being matched, then the initial AFI 384 is 6 [FlowSpecL2] and the Outer Flowspec can match the outer Ethernet 385 header, specify the IP version of the outer IP header, and match that 386 IP header including, if desired, the UDP header. 388 The Tunnel Header Flowspec can be used to filter on the VXLAN header 389 VN ID (VNI). 391 The Inner Flowspec can be used on the Inner Ethernet header 392 [FlowSpecL2] and any following IP header. If the inner AFI is 6, 393 then the inner Flowspec provides filtering of the Layer 2 header, 394 indicates whether filtering on a following IPv4 or IPv6 header is 395 desired, and if it is desired provides the Flowspec components for 396 that filtering. If the Inner AFI is 1 or 2, the Inner Ethernet 397 header is not matched and to match the Flowspec the Inner Ethernet 398 header must be followed by an IPv4 or IPv6 header, respectively, and 399 the inner Flowspec is used to filter that inner IP header. 401 The inner MAC/IP address is associated with the VN ID. In the NVO3 402 terminating into a VPN scenario, if multiple access VN IDs map to one 403 VPN instance, one shared VN ID can be carried in the flowspec rule to 404 enforce the rule on the entire VPN instance and the shared VN ID and 405 VPN correspondence should be configured on each VPN PE beforehand. In 406 this case, the function of the Layer 3 VN ID is the same as a Route 407 Distinguisher: it acts as the identification of the VPN instance. 409 2.3.2 VXLAN-GPE 411 VXLAN-GPE [GPE] is similar to VXLAN. The VXLAN-GPE header is the same 412 size as the VXLAN header but has been extended from the VXLAN header 413 by specifying a number of bits that are reserved in the VXLAN header. 414 In particular, a number of additional flag bits are specified and a 415 Next Protocol field is added that is valid if the P flag bit is set 416 in the VXLAN-GPE header. These flags bits can be tested using the 417 Tunnel Header Flags flowspec component defined above. VXLAN and 418 VXLAN-GPE are distinguished by the port number in the UDP header the 419 precedes the VXLAN or VXLAN-GPE headers. 421 If the VXLAN-GPE header P flag is zero, then that header is followed 422 by the same sequence as for VXLAN and the same flowspec choices apply 423 (see Section 2.3.1). 425 If the VXLAN-GPE header P flag is one and that header's next protocol 426 field is 1, then the VXLAN-GPE header is followed by an IPv4 header 427 (there is no Inner Ethernet header). The Inner Flowspec matches only 428 if the Inner AFI is 1 and the Inner Flowspec matches. 430 If the VXLAN-GPE header P flag is one and that header's next protocol 431 field is 2, then the VXLAN-GPE header is followed by an IPv6 header 432 (there is no Inner Ethernet header). The Inner Flowspec match only 433 if the Inner AFI is 2 and the Inner Flowspec matches. 435 2.3.3 NVGRE 437 NVGRE [RFC7637] is similar to VXLAN except that the UDP header and 438 VXLAN header immediately after the outer IP header are replaced by a 439 GRE (Generic Router Encapsulation) header. The GRE header as used in 440 NVGRE has no Checksum or Reserved1 field as shown in [RFC2890] but 441 there are Virtual Subnet ID and Flow ID fields in place of what is 442 labeled in [RFC2890] as the Key field. Processing and restrictions 443 for NVGRE are as in Section 2.3.1 eliminating references to a UDP 444 header and replacing references to the VXLAN header and its VN ID 445 with references to the GRE header and its VN ID (VSID) and Flow ID. 447 2.3.4 L2TPv3 449 The headers on an L2TPv3 [RFC3931] packets are an outer Ethernet 450 header, an outer IP header, the L2TPv3 header, an inner Ethernet 451 header, and possibly an inner IP header if indicated by the inner 452 Ethernet header EtherType. The Outer Flowspec operates on the outer 453 headers that precede the L2TP Session Header. The version of IP in 454 the outer IP header is specified by either the outer AFI at the 455 beginning of the MP_REACH_NLRI or MP_UNREACH_NLRI or, if that AFI is 456 6 (L2), optionally specified by the inner AFI within that L2 457 flowspec. 459 L2TPv3 data messages and control messages both start with a Session 460 ID and are distinguished by whether the Session ID is non-zero or 461 zero, respectively. Data message filtering is further specified in 462 Section 2.3.4.1 and control message filtering is further specified in 463 Section 2.3.4.2. 465 2.3.4.1 L2TPv3 Data Messages 467 For data messages, the L2TPv3 Session Header consists of a 32-bit 468 non-zero Session ID followed by a variable length Cookie (maximum 469 length 8 octets). A Tunnel Header flowspec is assumed to apply to 470 data messages unless the first component requires a zero Session ID. 472 The Session ID and Cookie can be filtered on by using the Session and 473 Cookie flowspec components in the Tunnel Header Flowspec. To filter 474 on Cookie or even be able to bypass Cookie and parse the remainder of 475 the L2TPv3 packet, the node implementing flowspec needs to know the 476 length and/or value of the Cookie fields of interest. This is 477 negotiated at L2TPv3 session establishment and it is out of scope for 478 this document how the node would learn this information. Of course, 479 if flowspec is being used for DDOS mitigation and the Cookie has a 480 fixed length and/or value in the DDOS traffic, this could be learned 481 by inspecting that traffic. 483 If the I flag bit is zero, then no filtering is done on data beyond 484 the L2TPv3 header. If the I flag is one, indicating the presence of 485 an Inner Flowspec, and the node implementing flowspec does not know 486 the length of the L2TPv3 header Cookie, the match fails. If that node 487 does know the length of that Cookie, the Inner Flowspec if matched 488 against the headers at the beginning of that data using the Inner 489 AFI. If that Inner AFI is 1 or 2, then an inner IP header is required 490 and filtering can be done on that IPv4 or IPv6 header respectively. 491 If the Inner AFI is 6, filtering is done on the inner Ethernet header 492 and, if an IPv4 or IPv6 inner AFI is specified within the inner L2 493 flowspec, done on the following IP header [FlowSpecL2]. 495 2.3.4.2 L2TPv3 Control Messages 497 Control messages are distinguished by starting with a zero 32-bit 498 Session ID. L2TPv3 control message flowspecs MUST start with a 499 Session component that requires Session to be zero. For L2TPv3 500 control messages, there is no Cookie but there are L2TPv3 flags, a 501 3-bit Version field, a 32-bit Control Connection ID, and 16-bit Ns 502 and Nr sequence numbers. These can be tested using the Tunnel Header 503 Flags, L2TP Control Version, L2TPv3 Control Connection ID, L2TPv3 Ns, 504 and L2TPv3 Nr flowspec components for the Tunnel Header Flowspec. 506 2.3.5 GRE 508 Generic Router Encapsulation (GRE [RFC2890]) is another type of 509 encapsulation. The Outer Flowspec operates on the outer headers that 510 precede the GRE header. The version of IP is specified by the outer 511 AFI at the beginning of the MP_REACH_NLRI or MP_UNREACH_NLRI. 513 If the I flag bit is zero, no filtering is done on data after the GRE 514 header. If the I flag bit is one in the tunnel flowspec, then there 515 is an inner AFI and inner flowspec and the Protocol Type field of the 516 GRE header must match the Inner AFI as follows for the tunnel 517 Flowspec to match: 519 GRE Protocol Type Inner AFI 520 ------------------- ----------- 521 0x0800 (IPv4) 1 522 0x86DD (IPv6) 2 523 0x6558 6 525 With the I flag a one and the Inner AFI and GRE Protocol Type fields 526 match, the Inner Flowspec is used to filter the inner IP headers 527 (Inner AFI=1 or 2) or the inner Ethernet header and optionally a 528 following IP header (Inner AFI=6). 530 2.3.6 IP-in-IP 532 IP-in-IP encapsulation [RFC2003] is indicated when an outer IP header 533 indicates an inner IP IPv4 or IPv6 header by the value of the outer 534 IP header's Protocol (IPv4) or Next Protocol (IPv6) field. 536 The IP version of the outer IP header (IPv4 or IPv6) matched is 537 indicated by an AFI of 1 or 2 at the beginning of the MP_REACH_NLRI 538 or MP_UNREACH_NLRI while if that AFI is 6, it indicates a match on 539 the out Ethernet header and, optionally, the following IP Header 540 [FlowSpecL2]. The IP version of the inner IP header is indicated by 541 the Inner AFI and the Inner Flowspec applies to the inner IP header. 543 There are no fields that can be matched by the Tunnel Header Flowspec 544 in the case of IP-in-IP. 546 2.4 Tunneled Traffic Actions 548 The traffic filtering actions previously specified in [RFC5575bis] 549 and [FlowSpecL2] are used for tunneled traffic. For Traffic Marking 550 in NVO3, only the DSCP in the outer header can be modified. 552 3. Order of Traffic Filtering Rules 554 The following rules determine which flowspec takes precedence where 555 one or more are applicable and at least one of the applicable 556 flowspecs is a tunneled traffic flowspec: 558 - In comparing an applicable tunneled traffic flow specification 559 with an applicable non-tunneled flow specification, the tunneled 560 specification has precedence. 562 - If comparing tunneled traffic flow specifications, if all are 563 applicable, the tunnel types will be the same. Any that have a 564 Routing Distinguisher will take precedence over those without a 565 Routing Distinguisher. Of those with a Routing Distinguisher, all 566 applicable flowspecs will have the same Routing Distinguisher. 568 - At this point in the process, all remaining contenders for the 569 highest precedence will either not have a Routing Distinguisher or 570 have equal Routing Distinguishers. If more than one contender 571 remain, those with an L2 Outer Flowspec take precedence over those 572 with an L3 Outer Flowspec. If the Outer Flowspec AFI is the same, 573 their order of precedence is determined by comparing the Outer 574 Flowspecs as described in [RFC5575bis] and [FlowSpecV6] for AFI 575 for 1 or 2 respectively or [FlowSpecL2] for AFI=6. 577 - If the Outer Flowspecs are equal, then the Tunnel Header Flowspecs 578 are compared using the usual sequential component comparison 579 process [RFC5575bis]. 581 - If the Tunnel Header Flowspecs are equal then compare the "I" 582 flag. Those with an Inner Flowspec take precedence over those 583 without an Inner Flowspec. If you get to this stage in the 584 ordering process, those without an Inner Flowspec are equal. For 585 those with an Inner Flowspec, check the Inner AFI. An L2 Inner AFI 586 (AFI=6) takes precedence over an L3 Inner AFI. 588 - If the Inner AFIs are equal, precedence is determined by comparing 589 the Inner Flowspecs as described in [FlowSpecL2] for L2 or 590 [RFC5575bis] for L3. 592 4. Flow Spec Validation 594 Flowspecs received over AFI=1/SAFI=77 or AFI=2/SFAI=77 are validated, 595 using only the Outer Flowspec, against routing reachability received 596 over AFI=1/SAFI=133 and AFI=2/SAFI=133 respectively, as modified by 597 [FlowSpecOID]. 599 5. Security Considerations 601 No new security issues are introduced to the BGP protocol by this 602 specification. 604 For general Flowspec security considerations, see [rfc5575bis]. 606 6. IANA Considerations 608 IANA has assigned the following SAFI: 610 Value Description Reference 611 ----- ------------------------------------------ --------------- 612 77 Tunneled Traffic Flowspec [This document] 614 IANA is requested to create a Tunnel Header Flow Spec Component Type 615 registry on the Flow Spec Component Types registries web page as 616 follows: 618 Name: Tunnel Flow Spec Component Types 619 Reference: [this document] 620 Registration Procedures: 621 0 Reserved 622 1-127 Specification Required 623 128-254 First Come First Served 624 255 Reserved 626 Initial contents: 627 Type Name Reference 628 ----- -------------- ----------------- 629 0 reserved [this document] 630 1 VN ID [this document] 631 2 Flow ID [this document] 632 3 Session [this document] 633 4 Cookie [this document] 634 5 Tunnel Header Flags [this document] 635 6 L2TP Control Version [this document] 636 7 L2TPv3 Control Connection ID 637 [this document] 638 8 L2TPv3 Ns [this document] 639 9 L2TPv3 Nr [this document] 640 10-254 unassigned [this document] 641 255 reserved [this document] 643 Normative References 645 [RFC2003] - Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 646 10.17487/RFC2003, October 1996, . 649 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 651 March 1997, . 653 [RFC2474] - Nichols, K., Blake, S., Baker, F., and D. Black, 654 "Definition of the Differentiated Services Field (DS Field) in 655 the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, 656 December 1998, . 658 [RFC2890] - Dommety, G., "Key and Sequence Number Extensions to GRE", 659 RFC 2890, DOI 10.17487/RFC2890, September 2000, 660 . 662 [RFC3931] - Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 663 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, 664 DOI 10.17487/RFC3931, March 2005, . 667 [RFC4271] - Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 668 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 669 10.17487/RFC4271, January 2006, . 672 [RFC4760] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 673 "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 674 10.17487/RFC4760, January 2007, . 677 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 678 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 679 eXtensible Local Area Network (VXLAN): A Framework for 680 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 681 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 684 [RFC7637] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network 685 Virtualization Using Generic Routing Encapsulation", RFC 7637, 686 DOI 10.17487/RFC7637, September 2015, . 689 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 690 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 691 2017, . 693 [FlowSpecL2] - W. Hao, et al, "Dissemination of Flow Specification 694 Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in 695 progress. 697 [FlowSpecOID] - J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P. 698 Mohapatra, "Revised Validation Procedure for BGP Flow 699 Specifications", draft-ietf-idr-bgp-flowspec-oid, work in 700 progress. 702 [FlowSpecV6] - R. Raszuk, et al, "Dissemination of Flow Specification 703 Rules for IPv6", draft-ietf-idr-flow-spec-v6, work in progress. 705 [RFC5575bis] - Hares, S., Loibl, C., Raszuk, R., McPherson, D., 706 Bacher, M., "Dissemination of Flow Specification Rules", 707 draft-ietf-idr-rfc5575bis, work in progress. 709 Informative References 711 [RFC8014] - Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 712 Narten, "An Architecture for Data-Center Network Virtualization 713 over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December 714 2016, . 716 [GPE] - P. Quinn, et al, "Generic Protocol Extension for VXLAN", 717 draft-ietf-nvo3-vxlan-gpe, work in progress. 719 Acknowledgments 721 The authors wish to acknowledge the important contributions of Jeff 722 Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, Robert Raszuk, 723 and Lucy Yong. 725 Authors' Addresses 727 Donald Eastlake 728 Futurewei Technologies 729 2386 Panoramic Circle 730 Apopka, FL 32703 USA 732 Tel: +1-508-333-2270 733 Email: d3e3e3@gmail.com 735 Weiguo Hao 736 Huawei Technologies 737 101 Software Avenue, 738 Nanjing 210012 China 740 Email: haoweiguo@huawei.com 742 Shunwan Zhuang 743 Huawei Technologies 744 Huawei Bld., No.156 Beiqing Rd. 745 Beijing 100095 China 747 Email: zhuangshunwan@huawei.com 749 Zhenbin Li 750 Huawei Technologies 751 Huawei Bld., No.156 Beiqing Rd. 752 Beijing 100095 China 754 Email: lizhenbin@huawei.com 756 Rong Gu 757 China Mobile 759 Email: gurong_cmcc@outlook.com 761 Copyright, Disclaimer, and Additional IPR Provisions 763 Copyright (c) 2020 IETF Trust and the persons identified as the 764 document authors. All rights reserved. 766 This document is subject to BCP 78 and the IETF Trust's Legal 767 Provisions Relating to IETF Documents 768 (http://trustee.ietf.org/license-info) in effect on the date of 769 publication of this document. Please review these documents 770 carefully, as they describe your rights and restrictions with respect 771 to this document. Code Components extracted from this document must 772 include Simplified BSD License text as described in Section 4.e of 773 the Trust Legal Provisions and are provided without warranty as 774 described in the Simplified BSD License.