idnits 2.17.1 draft-hares-idr-flowspec-v2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 26, 2021) is 1002 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) == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-17 == Outdated reference: A later version (-19) exists of draft-ietf-idr-flowspec-nvo3-13 == Outdated reference: A later version (-11) exists of draft-ietf-idr-wide-bgp-communities-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group S. Hares 3 Internet-Draft Hickory Hill Consulting 4 Intended status: Standards Track D. Eastlake 5 Expires: January 27, 2022 Futurewei 6 July 26, 2021 8 BGP Flow Specification Version 2 9 draft-hares-idr-flowspec-v2-02 11 Abstract 13 BGP flow specification version 1 (RFC8955, RFC8956) describes the 14 distribution of traffic filter policy (traffic filters and actions) 15 which are distributed via BGP to BGP peers. Multiple applications 16 utilize the BGP distributed traffic filter policy. These 17 applications include: (1) mitigation of Denial of Service (DoS), (2) 18 enabling of traffic filtering in BGP/MPLS VPNS, and(3)centralized 19 traffic control for networks utilizing either SDN control of router 20 firewall functions. During the deployment of BGP flow specification 21 v1, the following issues were detected: 1) problems due to the lack 22 of clear TLV encoding for rules for flow specifications, 2) desire to 23 order filters rules, and 3) ordering of actions to provide 24 deterministic actions. Version 2 of the BGP flow specification 25 protocol addresses these features. 27 BGP Flow Specification v2 is encapsulated in a different NLRI which 28 encapsulates previous flow specification information. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 27, 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Flow Specification v1 Review . . . . . . . . . . . . . . 4 66 1.2. Ordering Flow Specification Data Proposed for v2 . . . . 6 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 7 69 2.2. RFC 2119 language . . . . . . . . . . . . . . . . . . . . 8 70 3. Dissemination of BGP Flow Specification v2 NLRI . . . . . . . 8 71 3.1. Encoding of BGP-FS v2 Filters . . . . . . . . . . . . . . 8 72 3.1.1. Encoding of Value field for Rule Identification 73 (Value = 00) . . . . . . . . . . . . . . . . . . . . 10 74 3.1.2. Encoding of Value field for default Action of Block 75 traffic . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.1.3. Encoding of Value field for default Action of Permit 77 traffic . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.1.4. Encoding of Value field filters plus actions(Value = 79 03) . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 3.1.5. Encoding of Value Fields filters passed in Wide 81 Communities . . . . . . . . . . . . . . . . . . . . . 14 82 3.1.6. Encoding of Value Fields filters for Tunnels (Value = 83 05) . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 4. Optional Security Additions . . . . . . . . . . . . . . . . . 17 85 4.1. BGP FS v2 and BGPSEC . . . . . . . . . . . . . . . . . . 17 86 4.2. BGP FS v2 with with ROA . . . . . . . . . . . . . . . . . 17 87 4.3. Revise Flow Specification Security for centralized Server 18 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 89 5.1. Flow Specificatoin V2 SAFIs . . . . . . . . . . . . . . . 18 90 5.2. BGP Capability Code . . . . . . . . . . . . . . . . . . . 19 91 5.3. New Registries . . . . . . . . . . . . . . . . . . . . . 19 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 95 7.2. Informative References . . . . . . . . . . . . . . . . . 21 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 98 1. Introduction 100 BGP ([RFC4271]) flow specification (see [RFC8955] and [RFC8956]) 101 describes the distribution of traffic filter policy (traffic filters 102 and actions) which are distributed via BGP to BGP peers. The traffic 103 filter policy is applied when packets are received on a router with 104 the flow specification function turned on. Multiple applications 105 utilize the BGP distributed traffic filter policy. These 106 applications include: (1) mitigation of Denial of Service (DoS), (2) 107 enabling of traffic filtering in BGP/MPLS VPNS, and (3)centralized 108 traffic control for networks utilizing either SDN control of router 109 firewall functions. During the deployment of BGP flow specification 110 v1, the following issues were detected: 112 o problems such as non-extensibility due to the lack of clear TLV 113 encoding, 115 o desire to order filtering rules, and 117 o desire to order actions to provide deterministic interactions of 118 actions. 120 Version 2 of the BGP flow specification protocol addresses these 121 features. 123 This document specifies six new BGP Flow Specification NLRI wit (3 124 AFIs (1, 2, and 6) with two SAFI (TBD1 and TBD2) that allow user- 125 ordered list of traffic match filters, and user-ordered traffic match 126 actions encoded in BGP Wide Communities. These NLRIs provide 127 encoding for both the ordinary and the VPN cases for IPv4, IPv6, and 128 layer 2 covering all the cases covered by [RFC8955], [RFC8956], 129 [I-D.ietf-idr-flowspec-l2vpn], and [I-D.ietf-idr-flowspec-nvo3]. 130 This document provides an overview in this section and the following 131 other sections provide additional detail: 133 o section 2 - Definitions, 135 o section 3 - Rules for dissemination of Flow Specification v2, 137 o section 4 - Optional Security, 139 o section 5 - IANA considerations, 141 o section 6 - security considerations. 143 This section reviews the existing flow specification and provides a 144 logical description of ordered flow specification. 146 1.1. Flow Specification v1 Review 148 If one considers the reception of the packet as an event, then BGP 149 flow specification describes a set of Event-MatchCondition-Action 150 (ECA) policies where the match-condition is defined in the BGP NLRI, 151 and the action is defined either by the default condition (accept 152 traffic) or actions defined in Extended BGP Community values 153 [RFC4360]. 155 The initial set of conditions [RFC8955] and [RFC8956] for this policy 156 includes 13 types of match filters encoded the following: specific 157 AFI/SAFIs for the IPv4 and IPv6 AFIs: 159 IPv4 traffic: AFI:1, SAFI:133; 161 IPv6 Traffic: AFI:2 SAFI:133 163 BGP/MPLS IPv4 VPN: AFI:1, SAFI: 134 165 BGP/MPLS IPv6 VPN: AFI:2, SAFI: 134 167 The 13 types of filters are the following: 169 o Type 1: Destination Prefix 171 o Type 2: Source Prefix 173 o Type 3: IP Protocol (v4,[RFC8955] ) or Upper Layer Protocol (v6, 174 [RFC8956]) 176 o Type 4: Port 178 o Type 5: Destination Port 180 o Type 6: Source Port 182 o Type 7: ICMPv4 Type (v4,[RFC8955] ) or ICMPv6 Type (v6, [RFC8956]) 184 o Type 8: ICMPv4 Code (v4,[RFC8955] ) or ICMPv6 code(v6, [RFC8956]) 186 o Type 9: TCP flags (v4,[RFC8955] ) 188 o Type 10: Packet length 190 o Type 11: DSCP marking 191 o Type 12: Fragment 193 o Type 13: Flow Label (v6, [RFC8956]) 195 The actions specified [RFC8955] and [RFC8956] for exclusion on 196 Extended Community (0xttss) are the following: 198 o Traffic rate limited by bytes (0x8006) [2 byte AS, 4 byte float] 200 o Traffic action (set by bitmask, bits 47 and 46 defined) (0x8007) 202 o rt-redirect IPv4 (0x8008) [2 byte AS, 4 octet value] 204 o rt-redirect IPv4 (0x8108) [4 byte IPv4 address, 2 octet value] 206 o rt-redirect IPv4 (0x8108) [4 byte AS, 2 octet value] 208 o traffic marking (0x8009) (DSCP value) 210 o Traffic rate limited by packets (0x800C) [2 byte AS, 4 byte float] 212 o rt-redirect IPv6 (0x820D) [2 byte AS, 4 octet value] 214 o rt-redirect IPv6 (0x810D) [4 byte IPv4 address, 2 octet value] 216 o rt-redirect IPv6 (0x820D) [4 byte AS, 2 octet value] 218 The flow specification filers and actions combine to make up flow 219 specification rules associated with an NRLI. The Extended 220 Communities for actions can be attached to a single rule or multiple 221 rules. Figure 1 shows a diagram of the flow specification data 222 structures. 224 +--------------------------------------+ 225 | Flow Specification (FS) | 226 | Policy | 227 +--------------------------------------+ 228 ^ ^ ^ 229 | | | 230 | | | 231 +--------^----+ +-------^-------+ +-------------+ 232 | FS Rule1 | | FS Rule | ... | FS rule | 233 +-------------+ +---------------+ +-------------+ 234 : : 235 : : 236 ...: :........ 237 : : 238 +---------V---------+ +----V-------------+ 239 | Rule Condition | | Rule Action | 240 | in BGP NLRIs | | in BGP extended | 241 | AFIs: 1 and 2 | | Communities | 242 | SAFI 133, 134 | | | 243 +-------------------+ +------------------+ 244 : : : : : : 245 .....: . :..... .....: . :..... 246 : : : : : : 247 +----V---+ +---V----+ +--V---+ +-V------+ +--V-----++--V---+ 248 | Match | | match | |match | | Action | | action ||action| 249 |Operator| |Variable| |Value | |Operator| |variable|| Value| 250 |*1 | | | | | |(subtype| | || | 251 +--------+ +--------+ +------+ +--------+ +--------++------+ 253 *1 match operator may be complex. 255 Figure 1: BGP Flow Specification Policy 257 1.2. Ordering Flow Specification Data Proposed for v2 259 An minimal ordering specification of the rules is an order indicator 260 per rule. The inclusion of names for each rule, match condition and 261 action allows for logical indirection. The existing extended 262 community which tags multiple NLRIs could be saved as an indirect 263 reference by name. For Flow specification v1 actions, the Extended 264 actions could be assigned default names. The actions could be linked 265 to many NLRIs. Figure 2 below provides a logical diagram of the 266 ordering of rules and the association of names per rule, rule match 267 action, and rule action. 269 Since many policies also group data flow specifications under rule 270 groups, many implementations may order set of rules under a 271 particular group policy. Network Management display of BGP filers 272 may use the Rule Grouping mechanism to display the filters. 274 +--------------------------------+ 275 | Rule Group | 276 +------------------------------ -+ 277 ^ ^ ^ 278 | ---------- | 279 | | ------ 280 | | | 281 +--------^-------+ +-------^-----+ +---^-----+ 282 | Rule1 | | Rule2 | ... | Rule-n | 283 +----------------+ +-------------+ +---------+ 284 : : : : 285 :.................: : : : 286 : |.........: : : 287 +--V--+ +--V--+ : : 288 | name| |order| .........: :..... 289 +-----+ +-----+ : : 290 : : 291 +----------------V----+ +-----V------- --+ 292 |Rule Match condition | | Rule Action | 293 +---------------------+ +-----------------+ 294 : : : : : : : : 295 +--V--+ : : : +--V--+ : : : 296 | name| : : : |name | : : : 297 +-----+ : : : +-----+ : : : 298 : : : : : :........... 299 : : : : : : 300 .....: . :..... ..: :..... : 301 : : : : : : 302 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+ 303 | Match | | match | |match | | Action || action ||action| 304 |Operator| |variable| |Value | |Operator||Variable|| Value| 305 +--------+ +--------+ +------+ +--------++--------++------+ 307 Figure 2: Order Flow Specification Data storage 309 2. Terminology 311 2.1. Definitions and Acronyms 313 BGPSEC - secure BGP [RFC8205] updated by [RFC8206] 315 BGP Session ephemeral state - state which does not survive the 316 loss of BGP peer, 317 Ephemeral state - state which does not survive the reboot of a 318 software module, or a hardware reboot. Ephemeral state can be 319 ephemeral configuration state or operational state. 321 configuration state - state which persist across a reboot of 322 software module within a routing system or a reboot of a hardware 323 routing device. 325 NETCONF: The Network Configuration Protocol [RFC6241]. 327 RESTCONF: The RESTCONF configuration Protocol [RFC8040] 329 ROA: Route Origin Authentication [RFC6482] 331 2.2. RFC 2119 language 333 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 334 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 335 document are to be interpreted as described in BCP 14 [RFC2119] 336 [RFC8174] 338 3. Dissemination of BGP Flow Specification v2 NLRI 340 The BGP Flow Specification version 2 (BGP-FS v2) uses an NRLI with 341 the format for AFIs for IPv4 (AFI = 1), IPv6 (AFI = 2), and L2VPN 342 (L2VPN = 6) with one of two following SAFIs (TBD1 for routes and TBD2 343 for VPN routes). This NLRI information is encoded using 344 MP_REACH_NLRI and MP_UNREACH_NLRI attributes defined in [RFC4760]. 345 When advertising Flow Specification, the length of the Next-Hop 346 Network Address MUST be set to 0. The Network Address of the Next- 347 Hop Field MUST be ignored. 349 Implementations wishing to exchange flow specification rules MUST use 350 BGP's Capability Advertisement facility to exchange the Multiprotocol 351 Extension Capability Code (Code 1) as defined in [RFC4760], and 352 indicate a capability for flow specification v2 (Code TBD3). 354 3.1. Encoding of BGP-FS v2 Filters 356 The AFI/SAFI NLRI for BGP Flow Specification has the format: 358 +---------------------------+ 359 |length (2 octets) | 360 +---------------------------+ 361 | Sub-TLVs (variable) | 362 | +=======================+ | 363 | | order (2 octets) | | 364 | +-----------------------+ | 365 | | type (2 octets) | | 366 | +-----------------------+ | 367 | | length-tlv(2 octets) | | 368 | +-----------------------+ | 369 | | value (variable) | | 370 | +=======================+ | 371 +---------------------------+ 373 Figure 3 -Flow Specification v2 format 375 where: 377 o length - is the value of the initial length of field in overall 378 bytes of the Sub-TLVs. 380 o order - is 2 octet field indicating the flow-specification global 381 rule order. 383 o type - is one of the following types 385 * identifier (value = 00), 387 * match rule (value = 01) with default action of block traffic, 389 * match rule (value = 02) with default action of permit traffic, 391 * match rule (value = 03) with action TLVs, 393 * match rule (value = 04) with Wide Communities Action TLVs, 395 * match rule (value = 05) with tunnel matching from 396 [I-D.ietf-idr-flowspec-l2vpn] 398 * match rule (value = 06) with tunnel matching from 399 [I-D.ietf-idr-flowspec-nvo3] 401 o length-tlv - is the length of the value part of the Sub-TLV, 403 o value is a series of sub-TLVs fields (TLV) depended on the type 404 value defined in the sections below. 406 Filters are processed in the order specified by the user. 408 3.1.1. Encoding of Value field for Rule Identification (Value = 00) 410 The BGP flow specification V2 identifier sub-TLVs use the following 411 format: 413 +------------------------+ 414 |length (2 octets) | 415 +------------------------+ 416 | Sub-TLVs (variable) | 417 | +====================+ | 418 | | order (2 octets) | | 419 | +--------------------+ | 420 | | type = 00 | | 421 | +--------------------+ | 422 | | length (n octets) | | 423 | +--------------------+ | 424 | | identifier for | | 425 | | rule (variable) | | 426 | +====================+ | 427 +------------------------+ 429 Figure 4 - NRLI revision 431 The identifier is a string of octets of variable length. 433 3.1.2. Encoding of Value field for default Action of Block traffic 435 The BGP flow specification V2 identifier sub-TLVs use the following 436 format: 438 +--------------------------+ 439 |length (2 octets) | 440 +--------------------------+ 441 | Sub-TLVs (variable) | 442 | +======================+ | 443 | | order (2 octets) | | 444 | +----------------------+ | 445 | | type = 01 | | 446 | +----------------------+ | 447 | | length (variable) | | 448 | +----------------------+ | 449 | | value field | | 450 | | AFI/SAFI field (4) | | 451 | | components (variable | | 452 | +======================+ | 453 +--------------------------+ 455 Figure 5 - Flow specification v2 456 with default Block traffic flow 458 Flow Specification v2 with a default Action of block traffic has AFI/ 459 SAFI at the beginning of the enclosing MP_REACH_NLRI or 460 MP_UNREACH_NLRI and the following sub-TLVs in the value field: 462 Component fields as defined in the following documents: 464 [RFC8955], 466 [RFC8956], 468 [I-D.ietf-idr-flowspec-l2vpn] 470 3.1.3. Encoding of Value field for default Action of Permit traffic 472 The BGP flow specification V2 identifier sub-TLVs use the following 473 format: 475 +--------------------------+ 476 |length (2 octets) | 477 +--------------------------+ 478 | Sub-TLVs (variable) | 479 | +======================+ | 480 | | order (2 octets) | | 481 | +----------------------+ | 482 | | type = 01 | | 483 | +----------------------+ | 484 | | length (variable) | | 485 | +----------------------+ | 486 | | value field | | 487 | | AFI/SAFI field (4) | | 488 | | components (variable | | 489 | +======================+ | 490 +--------------------------+ 492 Figure 6 - Flow specification v2 493 with default permit traffic flow 495 Flow Specification v2 with Filters and Default action of block 496 traffic has an AFI/SAFI at the beginning of the enclosing 497 MP_REACH_NLRI or MP_UNREAC_NLRI and the following sub-TLVs in the 498 value field: 500 a value of an AFI/SAFI field with 4 bytes [AFI 2 Bytes, SAFI 1 501 byte, 1 Byte reserved] 503 Component fields as defined in the following documents: 505 [RFC8955], 507 [RFC8956], 509 [I-D.ietf-idr-flowspec-l2vpn] 511 3.1.4. Encoding of Value field filters plus actions(Value = 03) 513 The BGP flow specification V2 identifier sub-TLVs use the following 514 format: 516 +----------------------------+ 517 |length (2 octets) | 518 +----------------------------+ 519 | Sub-TLVs (variable) | 520 | +=======================+ | 521 | | order (2 octets) | | 522 | +-----------------------+ | 523 | | type = 01 | | 524 | +-----------------------+ | 525 | | length (2 octets) | | 526 | +-----------------------+ | 527 | | value field | | 528 | | | | 529 | | Action length (4) | | 530 | | Action sub-TLVs (var) | | 531 | | number of filters | | 532 | | [filter 1] | | 533 | | AFI/SAFI field (4) | | 534 | | components (variable) | | 535 | | [filter 2] | | 536 | | AFI/SAFI field (4) | | 537 | | components (variable) | | 538 | | .... | | 539 | +=======================+ | 540 +----------------------------+ 542 Figure 7 - Flow Specification with 543 Actions encoded in NLRI 545 The Flow Specification v2 with action fields applies actions to the 546 AFI/SAFI field. The format of the field is 548 Action length (4 bytes) 550 Action SubTLVs (variable) in format Type (2 bytes), length (2 551 bytes), and value (variable). The types are: 553 Extended community (01) 555 Wide Community (02) 557 [Type (2 bytes)][Extended-Community-type (2 bytes)][6 bytes] 559 Figure 8 - Extended Community action type encoding 561 The Extended community types are the following: 563 Type 1: Traffic rate limited by bytes (0x8006) [2 byte AS, 4 564 byte float] 566 Type 2: Traffic action (set by bitmask, bits 47 and 46 defined) 567 (0x8007) 569 Type 3: rt-redirect IPv4 (0x8008) [2 byte AS, 4 octet value] 571 Type 4: rt-redirect IPv4 (0x8108) [4 byte IPv4 address, 2 octet 572 value] 574 Type 5: rt-redirect IPv4 (0x8108) [4 byte AS, 2 octet value] 576 Type 6: traffic marking (0x8009) (DSCP value) 578 Type 7: Traffic rate limited by packets (0x800C) [2 byte AS, 4 579 byte float] 581 Type 8: rt-redirect IPv6 (0x820D) [2 byte AS, 4 octet value] 583 Type 9: rt-redirect IPv6 (0x810D) [4 byte IPv4 address, 2 octet 584 value] 586 Type 10: rt-redirect IPv6 (0x820D) [4 byte AS, 2 octet value] 588 Component fields as defined in the following documents: 590 [RFC8955], 592 [RFC8956], 594 [I-D.ietf-idr-flowspec-l2vpn] 596 The BGP-FS version 2 actions are passed in a Wide Community 597 [I-D.ietf-idr-wide-bgp-communities] atom with the following format. 599 3.1.5. Encoding of Value Fields filters passed in Wide Communities 601 The BGP Flow specification version 2 actions are passed in a Wide 602 Community [I-D.ietf-idr-wide-bgp-communities] atom with the following 603 format: 605 +----------------------------+ 606 |length (2 octets) | 607 +----------------------------+ 608 | Sub-TLVs (variable) | 609 | +=======================+ | 610 | | order (2 octets) | | 611 | +-----------------------+ | 612 | | type = 01 | | 613 | +-----------------------+ | 614 | | length (2 octets) | | 615 | +-----------------------+ | 616 | | value field | | 617 | | | | 618 | | Action length(4) | | 619 | | Atom-id-1 (4) | | 620 | | Atom-id-2 (4) | | 621 | | number of filters | | 622 | | [filter 1] | | 623 | | AFI/SAFI field (4) | | 624 | | components (variable) | | 625 | | [filter 2] | | 626 | | AFI/SAFI field (4) | | 627 | | components (variable) | | 628 | | .... | | 629 | +=======================+ | 630 +----------------------------+ 632 Figure 9 - Flow Specification with 633 IDs for Wide Community Actions 635 The BGP Atom IDs in the Wide Community must contain: 637 +--------------------------+ 638 | Atom ID (4 octets) | 639 +--------------------------+ 640 | order (2 octets) | 641 +--------------------------+ 642 | Action type (2 octets) | 643 +--------------------------+ 644 | Action length (2 octets) | 645 +--------------------------+ 646 | Action Values (variable) | 647 | (multiples of 2 octets) | 648 +--------------------------+ 650 Figure 10 651 Wide Community Atom 652 where: 654 o Action type (2 octets) - is the type of action. These actions can 655 be standardized (0x0001 - 0x3ffff), vendor specific 656 (0x40000-0x7FFFF), or reserved (0x0, 0x80000-0xFFFFFFFF). 658 o Action length - length of actions including variable field, 660 o Action values - value of actions (variable) defined in individual 661 definitions. 663 The BGP Flow Specification (BGP-FS) atom can be part of the Wide 664 Community container (type 1) or the BGP Flow Specification Atom can 665 be part of the BGP Flow Specification container (type 2) which will 666 have: 668 +-----------------------------+ 669 | Source AS Number (4 octets)| 670 +-----------------------------+ 671 | list of atoms (variable) | 672 +-----------------------------+ 673 Figure 11: Atom format 675 3.1.6. Encoding of Value Fields filters for Tunnels (Value = 05) 677 AFter the initial order, type, and length the values for matching 678 tunneled packets are the format show in Figure 12. The Tunnel Type 679 field is a value from the IANA BGP Tunnel Encapsulation Attribute 680 Tunnel Types Registry. If it is desired to match the packeet headers 681 after the tunnel header, the Inner AFI field specifies the AFI for 682 that match which is ANDed with the Outer Flowspec match. An absent 683 Inner FlowSpec is consider to always match. The Inner flow 684 specification for tunnel filter can also include tunnel header field 685 components from [I-D.ietf-idr-flowspec-nvo3]. 687 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 688 | Tunnel Type 2 octets | 689 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 690 | Inner AFI 2 octets | 691 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 692 | Outer Flowspec Length 2 octets | 693 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 694 | Outer Flowspec Components variable : 695 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 696 Optional Inner Flowspec, present if Inner AFI non-zero 697 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 698 | Inner Flowspec Components variable : 699 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 701 Figure 12 703 4. Optional Security Additions 705 This section discusses the optional BGP Security additions for BGP-FS 706 v2 relating to BGPSEC [RFC8205] and ROA. 708 4.1. BGP FS v2 and BGPSEC 710 Flow specification v1 ([RFC8955] and [RFC8956]) do not BGP Flow 711 specifications to be passed BGPSEC [RFC8205] BGP Flow Specification 712 v2 can be passed in BGPSEC, but it is not required. 714 4.2. BGP FS v2 with with ROA 716 BGP Flow Specification v2 can utilize ROAs in the validation. If 717 BGP-FS v2 is used with BGPSEC and ROA, the first thing is to validate 718 the route within BGPSEC and second to utilize BGP ROA to validate the 719 route origin. 721 The BGP-FS peers using both ROA and BGP-FS validation determine that 722 a BGP Flow specification is valid if and only if one of the following 723 cases: 725 o If the BGP Flow Specification NLRI has a IPv4 or IPv6 address in 726 destination address match filter and the following is true: 728 * A BGP ROA has been received to validate the originator, and 730 * the route is the best-match unicast route for the destination 731 prefix embedded in the match filter; or 733 o If a BGP ROA has not been received that matches the IPv4 or IPv6 734 destination address in the destination filter, the match filter 735 must abide by the [RFC8955] and [RFC8956] validation rules of: 737 * The originator match of the flow specification matches the 738 originator of the best-match unicast route for the destination 739 prefix filter embedded in the flow specification", and 741 * No more specific unicast routes exist when compared with the 742 flow destination prefix that have been received from a 743 different neighboring AS than the best-match unicast route, 744 which has been determined in step A. 746 The best match is defined to be the longest-match NLRI with the 747 highest preference. 749 4.3. Revise Flow Specification Security for centralized Server 751 The distribution of Flow Specifications from a centralized server 752 supports mitigation of DoS attacks. [I-D.ietf-idr-bgp-flowspec-oid] 753 suggests the following redefined procedure for validation for this 754 case: 756 A route is valid if the following conditions holds true: 758 o The originator of the flow specification matches the originator of 759 the best-match unicast route for the destination prefix embedded 760 in the flow specification. 762 o The AS_PATH and AS4_PATH attribute of the flow specification are 763 empty (on originating AS) 765 o The AS_PATH and AS4_PATH attribute of the flow specification does 766 not contain AS_SET and AS_SEQUENCE segments (on originating AS 767 with AS Confederation) 769 This reduced validation mechanism can be used for BGP-FS v2 within a 770 single domain. 772 5. IANA Considerations 774 This section complies with [RFC7153] 776 5.1. Flow Specificatoin V2 SAFIs 778 IANA is required to assign two SAFI Values from the registry at 779 https://www.iana.org/assignments/safi-namespace from the Standard 780 Action Range as follows: 782 Value Description Reference 783 ----- ------------- --------------- 784 TBD1 BGP-FS V2 [This document] 785 TBD2 BGP-FS V2 VPN [this document] 787 5.2. BGP Capability Code 789 IANA is requested to assign a Capability Code from the registry at 790 https://www.iana.org/assignments/capability-codes/ from the IETF 791 Review range as follows: 793 Value Description Reference Controller 794 ----- --------------------- --------------- ---------- 795 TBD3 Flow Specification V2 [this document] IETF 797 5.3. New Registries 799 IANA is requested to create the following new registries: 801 Registry for BGP-FS v2 action types with the 803 0x00 - reserved 805 0x01 - 0x3FFFF - standards action 807 0x40000- 0x7FFFF - vendor specific filters 809 0x80000 -0xFFFFFFFF - reserved 811 0x80000 -0xFFFFFFFF - reserved 813 Registry for BGP-FS v2 action types with the following ranges: 815 0x0 - reserved 817 0x01 - 0x3ffff - standards action 819 0x40000 - 0x7ffff - vendor actions 821 0x80000 - 0xFFFFFFF - reserved 823 6. Security Considerations 825 The use of ROA improves on [RFC8955] to check the route origination 826 is valid can improve the validation sequence for a multiple-AS 827 environment. The use of BGPSEC [RFC8205] to secure the packet can 828 increase security of BGP flow specification information sent in the 829 packet. 831 The use of the reduced validation within an AS 832 [I-D.ietf-idr-bgp-flowspec-oid] can provide adequate validation for 833 distribution of flow specification within an single autonomous system 834 for prevention of DDOS. 836 Distribution of flow filters may provide insight into traffic being 837 sent within an AS, but this information should be composite 838 information that does not reveal the traffic patterns of individuals. 840 7. References 842 7.1. Normative References 844 [I-D.ietf-idr-bgp-flowspec-oid] 845 Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P. 846 Mohapatra, "Revised Validation Procedure for BGP Flow 847 Specifications", draft-ietf-idr-bgp-flowspec-oid-15 (work 848 in progress), June 2021. 850 [I-D.ietf-idr-flowspec-l2vpn] 851 Hao, W., Eastlake, D. E., Litkowski, S., and S. Zhuang, 852 "BGP Dissemination of L2 Flow Specification Rules", draft- 853 ietf-idr-flowspec-l2vpn-17 (work in progress), May 2021. 855 [I-D.ietf-idr-flowspec-nvo3] 856 Eastlake, D., Weiguo, H., Zhuang, S., Li, Z., and R. Gu, 857 "BGP Dissemination of Flow Specification Rules for 858 Tunneled Traffic", draft-ietf-idr-flowspec-nvo3-13 (work 859 in progress), February 2021. 861 [I-D.ietf-idr-wide-bgp-communities] 862 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 863 and P. Jakma, "BGP Community Container Attribute", draft- 864 ietf-idr-wide-bgp-communities-05 (work in progress), July 865 2018. 867 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 868 Requirement Levels", BCP 14, RFC 2119, 869 DOI 10.17487/RFC2119, March 1997, 870 . 872 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 873 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 874 DOI 10.17487/RFC4271, January 2006, 875 . 877 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 878 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 879 February 2006, . 881 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 882 "Multiprotocol Extensions for BGP-4", RFC 4760, 883 DOI 10.17487/RFC4760, January 2007, 884 . 886 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 887 Origin Authorizations (ROAs)", RFC 6482, 888 DOI 10.17487/RFC6482, February 2012, 889 . 891 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 892 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 893 March 2014, . 895 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 896 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 897 May 2017, . 899 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 900 Bacher, "Dissemination of Flow Specification Rules", 901 RFC 8955, DOI 10.17487/RFC8955, December 2020, 902 . 904 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 905 "Dissemination of Flow Specification Rules for IPv6", 906 RFC 8956, DOI 10.17487/RFC8956, December 2020, 907 . 909 7.2. Informative References 911 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 912 and A. Bierman, Ed., "Network Configuration Protocol 913 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 914 . 916 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 917 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 918 . 920 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 921 Specification", RFC 8205, DOI 10.17487/RFC8205, September 922 2017, . 924 [RFC8206] George, W. and S. Murphy, "BGPsec Considerations for 925 Autonomous System (AS) Migration", RFC 8206, 926 DOI 10.17487/RFC8206, September 2017, 927 . 929 Authors' Addresses 931 Susan Hares 932 Hickory Hill Consulting 933 7453 Hickory Hill 934 Saline, MI 48176 935 USA 937 Email: shares@ndzh.com 939 Donald Eastlake 940 Futurewei 941 FL 942 USA 944 Email: d3e3e3@gmail.com