idnits 2.17.1 draft-hares-idr-flowspec-combo-01.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 (March 5, 2016) is 2968 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) == Unused Reference: 'RFC4360' is defined on line 1786, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 1805, but no explicit reference was found in the text == Unused Reference: 'RFC7223' is defined on line 1829, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-routing-cfg' is defined on line 1914, but no explicit reference was found in the text == Unused Reference: 'I-D.vandevelde-idr-flowspec-path-redirect' is defined on line 1957, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 1967, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7674 (Obsoleted by RFC 8955) == Outdated reference: A later version (-01) exists of draft-hao-idr-flowspec-redirect-tunnel-00 == Outdated reference: A later version (-03) exists of draft-hares-i2rs-fb-rib-data-model-02 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-13 == Outdated reference: A later version (-23) exists of draft-ietf-i2rs-ephemeral-state-02 == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-06 == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-03 == Outdated reference: A later version (-11) exists of draft-ietf-idr-wide-bgp-communities-01 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-09 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-06 == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-20 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-14 == Outdated reference: A later version (-05) exists of draft-li-idr-flowspec-rpd-01 == Outdated reference: A later version (-02) exists of draft-liang-idr-bgp-flowspec-label-01 == Outdated reference: A later version (-03) exists of draft-vandevelde-idr-flowspec-path-redirect-01 Summary: 4 errors (**), 0 flaws (~~), 21 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 Huawei 4 Intended status: Standards Track March 5, 2016 5 Expires: September 6, 2016 7 An Information Model for Basic Network Policy and Filter Rules 8 draft-hares-idr-flowspec-combo-01.txt 10 Abstract 12 BGP flow specification (RFC5575) describes the distribution policy 13 that contains filters and actions that apply when packets are 14 received on a router with the flow specification function turned on. 15 The popularity of these flow specification filters in deployment for 16 DoS and SDN/NFV has led to the requirement for more BGP flow 17 specification match filters in the NLRI and more BGP flow 18 specification actions. Two solutions exist for adding new filters: 19 1) expanding the BGP Flow Specification version 1 (NLRI match filters 20 and extended communities actions) to included limited number of 21 filters and actions, and 2) creating a BGP Flow Specification version 22 2 that allows for ordering filters and actions (using new NLRI and 23 wide-communities for actions). The two solutions can exist in 24 parallel. 26 This document contains an overview existing proposals for expansion 27 of BGP flow specification policy, proposals for BGP Flow 28 Specification v1 and a new BGP Flow specification version 2 that 29 supports order of filters and actions plus allowing more actions. 30 This document also provides rules for the interaction of IDR Flow 31 Specification policy (session ephemeral policy) with policy found in 32 I2RS (reboot ephemeral policy), and policy found in ACLs and Policy 33 routing (configuration policy). This document does not contain the 34 individual definitions of policy rule conditions or actions. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 6, 2016. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Overview of RFC5575 . . . . . . . . . . . . . . . . . . . 6 72 1.2. Flow Specifications: Ephemeral or not? . . . . . . . . . 7 73 1.3. Precedence between BGP Flow Specification and other 74 packet-ECA policies . . . . . . . . . . . . . . . . . . . 8 75 1.4. BGP Flow Specification and logging . . . . . . . . . . . 10 76 1.5. BGP Flow Specification and BGPSEC . . . . . . . . . . . . 10 77 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 2.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 10 79 2.2. RFC 2119 language . . . . . . . . . . . . . . . . . . . . 11 80 3. BGP Flow Specification Policy - Original and Expansions . . . 11 81 3.1. Packet Reception Event . . . . . . . . . . . . . . . . . 11 82 3.2. BGP Flow Specification Match Filters . . . . . . . . . . 11 83 3.2.1. Current Precedence logic . . . . . . . . . . . . . . 14 84 3.2.2. Why Current Match precedence Logic a problem . . . . 15 85 3.3. BGP Flow Specification Actions . . . . . . . . . . . . . 16 86 3.3.1. Proposals to extend these standardized actions . . . 17 87 3.3.2. Why ordering is needed . . . . . . . . . . . . . . . 19 88 4. Proposal to Expand BGP Flow Specification Security . . . . . 23 89 4.1. Validation for NLRI with L2VPN validation . . . . . . . . 24 90 4.2. Using ROA to validate BGP Flow Specification . . . . . . 24 91 4.3. Using BGPSec to validate AS Path . . . . . . . . . . . . 24 92 5. Minimal BGP-FS Additions (Option 1) . . . . . . . . . . . . . 24 93 5.1. Summary of Existing Flow Specification Formats . . . . . 25 94 5.2. New Validation Rules for BGP Flow Specification: 95 Precedence with ROA . . . . . . . . . . . . . . . . . . . 26 97 5.3. Match Condition Filters with Precedence Ordering . . . . 27 98 5.3.1. Table of Match Filters and Precedence . . . . . . . . 28 99 5.3.2. FCFS Flow Specification Match Condition Filter 100 Interaction . . . . . . . . . . . . . . . . . . . . . 29 101 5.4. Flow Specification Actions and Action Precedence . . . . 29 102 5.4.1. FCFS Extended Communities with BGP Flow Specification 103 Actions . . . . . . . . . . . . . . . . . . . . . . . 30 104 5.5. Precedence with other packet ECA policies . . . . . . . . 30 105 5.6. pros and cons of Minimal subset BGP-FS Additions (Option 106 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 6. BGP-FS-v2 (New NLRI and Wide Communities Approach)(option 2) 32 108 6.1. Format of New NLRI and Wide Communities . . . . . . . . . 33 109 6.2. security addition of ROA . . . . . . . . . . . . . . . . 34 110 6.3. Match Filters and precedence . . . . . . . . . . . . . . 34 111 6.3.1. Precedence in case of ties in order . . . . . . . . . 34 112 6.3.2. Precedence of filters among Routing Functions . . . . 36 113 6.3.3. Precedence for re-ordering Match Policy . . . . . . . 36 114 6.4. Actions and precedence of actions . . . . . . . . . . . . 36 115 6.5. Pro-Con of BGP-FS-v2 (option 2} . . . . . . . . . . . . . 37 116 7. Flow Specification Yang models . . . . . . . . . . . . . . . 38 117 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 118 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 119 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 120 10.1. Normative References . . . . . . . . . . . . . . . . . . 41 121 10.2. Informative References . . . . . . . . . . . . . . . . . 42 122 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45 124 1. Introduction 126 BGP flow specification (RFC5575) describes the distribution of 127 filters and actions that apply when packets are received on a router 128 with the flow specification function turned on. If one considers the 129 reception of the packet as an event, then BGP flow specification 130 describes a set of minimalistic Event-MatchCondition-Action (ECA) 131 policies. The initial set of policy (RFC5575 and RFC7674) for this 132 policy includes 12 types of match filters encoded in the NLRI for two 133 types of SAFIs (IP-only SAFI, 133; VPN SAFI, 134) for IPv4. The 134 popularity of these flow specification filters in deployment for DoS 135 and SDN/NFV has led to the requirement for more BGP flow 136 specification match filters in the NLRI and more BGP flow 137 specification actions. 139 Two solutions exist for adding new filters: 1) expanding the BGP Flow 140 Specification (NLRI match filters and extended communities actions) 141 for a limited number of filters and actions, and 2) creating a BGP 142 Flow Specification version 2 that allows for ordering filters and 143 actions (using new NLRI and wide-communities 144 [I-D.ietf-idr-wide-bgp-communities] for actions). The two solutions 145 can exist in parallel. This document contains an overview of both 146 solutions, rules for combining new flow specification policies which 147 support IPv6, L2, nvo03 and MPLS match filters and new actions, and 148 suggestions on how to expand yang modules to monitor both types. 149 This document also provides rules for the interaction of IDR Flow 150 Specification policy (session ephemeral policy) with policy found in 151 I2RS (reboot ephemeral policy), and policy found in ACLs and Policy 152 routing (configuration policy). This document does not contain the 153 individual definitions of policies whcih are contained in the other 154 specifications. 156 Section 1 of this draft contains an introduction to BGP flow 157 specification [RFC5575] and drafts expanding the RFC5575 state. 158 Section 2 contains the definitions related to this draft. Section 3 159 provides an overview of existing and proposed flow specification 160 policy rules decribed in terms of packet event, packet match 161 conditions, and actions (packet forwarding or packet match). The 162 flow specification policies reviewed include policy in RFCs 163 ([RFC5575], [RFC7674]), IDR WG documents 164 ([I-D.ietf-idr-flow-spec-v6], [I-D.ietf-idr-flowspec-l2vpn]), and the 165 following proposed IDR WG documents 167 o [I-D.eddy-idr-flowspec-packet-rate] (traffic limiting by packet 168 rate), 170 o [I-D.eddy-idr-flowspec-exp] (Extensions for BGP security and 171 others), 173 o [I-D.hao-idr-flowspec-nvo3] (flow specification for inner/outer 174 nv03 forwarding), 176 o [I-D.hao-idr-flowspec-redirect-tunnel] (redirect to tunnel), 178 o [I-D.liang-idr-bgp-flowspec-label] MPLS label related filters and 179 actions, 181 o [I-D.liang-idr-bgp-flowspec-time] Filters by time, 183 o [I-D.litkowski-idr-flowspec-interfaceset]Filters applied by order 184 for Interface group, and 186 o [I-D.vandevelde-idr-flowspec-path-redirect]Filters applied to 187 packet identifier, 189 Section 4 describes a proposal for an enhancement of BGP Flow 190 specification security for both proosal. This security enhancement 191 suggests using BGP ROA and allows the addition of BGP security to 192 validate the AS Path or AS Extended Communities and AS Wide 193 Communities. 195 Section 5 describes the minimal subset solution with: 197 o summary of NLRI and extended community formats (xection 5.1) 199 o security addition of ROA (section 5.2), 201 o match filter list and precedence of match filters (section 5.3), 203 o action list and precedence of actions(section 5.4), 205 o conflict with other Packet-reception Event-MatchCondition-Action 206 (ECA) policy (I2RS Filter-Based RIB and Policy-Based Routing 207 (n-tuple forwarding)) (section 5.9), 209 o pros-cons of this approach (section 5.10) 211 Section 6 contains the BGP Flow specification with the sub-sections 212 as section 4 except that section one summarizes the new NRLI with 213 ordering of filters, and wide community atoms. 215 Section 7 proposes changes to the proposed Flow Specification Yang 216 Module ([I-D.wu-idr-flowspec-yang-cfg]. yang modules in order to 217 provide common monitoring of BGP Flow Specification version 1 and 218 version 2. The changes suggest include changes to: 220 o local configuration of BGP Flow Specification to be distributed to 221 remote peers, 223 o storage of bgp policy received from remote BGP peers [operational 224 state], 226 o statistics on use of locally configured BGP Flow Specification and 227 remotely configured BGP Flow specification [operational state]. 229 In addition, this section suggests ways to store BGP Flow 230 Specification that will aid in comparing the BGP Flow Specification 231 with other packet-reception ECA policy. 233 Section 9 discusses the security considerations for all the BGP Flow 234 Specifications. 236 1.1. Overview of RFC5575 238 [RFC5575] describes the dissemination of flow specification rules via 239 groups BGP Multi-Protocol NLRIs and BGP communities. A flow 240 specification operates on packets received in a router when the flow 241 specification feature is configured. The flow specification 242 specifies match conditions for filters for packets received by a 243 router and actions to do based on a match of those filters. If one 244 considers the reception of a packet as an event, then a BGP flow 245 specifications can be considered a set of minimalistic Event-Match 246 Condition-Action policies (ECA policies). This set is minimalistic 247 because there is only one event - the reception of a packet. BGP 248 Flow specifications are BGP policy passed between peers. 250 The BGP flow specification policy is specified in filters contained 251 in the MP-BGP NLRIs and actions contained within BGP Extended 252 communities. The BGP peer propagates the flow-specifications between 253 domains in order to automate inter-domain coordination of traffic 254 filtering. Two applications that are using this are: distributed 255 denial of service attack suppression and traffic filtering in BGP/ 256 MPLS VPN service. BGP. BGP flow specifications use SAFI 133 non-VPN 257 flow specifications, and SAFI 134 for BGP VPN flow specificatinos. 259 BGP Flow specification are validated based on: 261 a) originator of flow specification matching the originator of the 262 best-match unicast route for the destination prefix embedded in 263 the flow specification, and 265 b) no more specific unicast routes, when compared with flow 266 destination prefix, that have been received from differenting 267 neighboring AS than the best-match unicast route 269 Originator is specified by BGP originator path attribute or transport 270 address of the BGP peer sending the BGP Flow specification. To 271 support BGP flow specification, implementations are required to 272 enforce the neighbor AS in the AS_PATH attribute is in the left-most 273 position of AS_PATH. 275 +-----------------------------+ 276 | Flow Specification (FS) | 277 | Policy | 278 +-----------------------------+ 279 ^ ^ 280 | | 281 | | 282 +--------^-------+ +-------^-------+ 283 | FS Rule | | FS Rule | 284 +----------------+ +---------------+ 285 : : 286 : : 287 ......: :..... 288 : : 289 +---------V---------+ +----V-------------+ 290 | Rule Condition | | Rule Action | 291 | in BGP NLRIs | | in BGP extended | 292 | SAFI 133, 134 | | Communities | 293 +-------------------+ +------------------+ 294 : : : : : : 295 .....: . :..... .....: . :..... 296 : : : : : : 297 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+ 298 | Match | | match | |match | | Action || action ||action| 299 |Operator| |Variable| |Value | |Operator||Variable|| Value| 300 |*1 | | | | | |(type-) || || | 301 +--------+ +--------+ +------+ +--------++--------++------+ 303 *1 match operator for Types 3-12. Match operator supports 304 pairs of matching operators. 306 Figure 1: BGP Flow Specification Policy 308 Match operators includes a sequence of match operations each with the 309 form [op, value] where match can match values greater, lessthan, or 310 equal to teh value. The sequence of match operators can be combined 311 as logical AND or ORs. 313 1.2. Flow Specifications: Ephemeral or not? 315 BGP Flow specification does not indicate what happens to the flow 316 specifications if a BGP peering session closes. [RFC5575] specifies 317 a link to received "best-match" unicast routes, but does not provide 318 any standard way of determining whether the flow specification sent 319 by the BGP peer is kept after the BGP session closes. It is unclear 320 whether BGP Flow specifications disappear when a BGP session closes 321 (denoted as BGP session ephemeral), or disapppear when the BGP 322 module's hardware or software reboots (reboot ephemeral), or it is 323 kept like configuration state that survives a reboot. 325 This document specifies that the default policy is that the BGP Flow 326 Specification received from remote peers like other BGP peer state 327 received from remote peers disappears when the BGP peer session 328 closes. Local BGP Peer configuration is like all local configuration 329 and persists while the BGP Peer is configured. 331 If an implementation decides to implement operator-applied policy 332 that retains remotely received BGP Flow Specification policy after 333 the BGP Peer closes, this action must be treated as if these BGP Flow 334 Specification policy was locally configured. Therefore, these two 335 actions are out of scope of this document. 337 1.3. Precedence between BGP Flow Specification and other packet-ECA 338 policies 340 Why is this precedence bewteen BGP Flow Specification and other 341 packet-ECA policies needed? 343 [RFC5575] states that Flow specification takes advantage of the "ACL" 344 feature (section 1), but it does not state how BGP Flow specification 345 interacts with ACL features. NETCONF [RFC6241] or RESTCONF 346 [I-D.ietf-netconf-restconf] can be used to set ACL configuration 347 state using the [I-D.ietf-netmod-acl-model] yang data module. 349 One of the proposals for a new BGP Flow specification action 350 ([I-D.litkowski-idr-flowspec-interfaceset]) proposes an action which 351 defines that a specific ordering of BGP flow-specifications and ACLs 352 interaction for a set of interfaces for the drop/forward actions (see 353 section 3 for details). This action proposals suggests a precedence 354 between these two filter actions. 356 ACL is not the only packet-ECA policy used as an alternative to 357 destination based routing. Two other n-tuple packet-reception ECA 358 modules exist: n-tuple policy-based RIB/FIB (aka policy routing) and 359 I2RS Filter-based RIB. The n-tuple policy based forwarding RIB/FIB 360 configured on specific interfaces, and forward based on the match of 361 an n-tuple filter that modifies, forwards, or drop n-tuples. If no 362 match exists, this packet-reception ECA RIB forward this to a default 363 RIB. A proposal for standardized yang model for this is in (draft- 364 rtgwg-hares-rtgwg-fb-rib-00.txt). 366 The I2RS Filter-Based RIB (FB-RIB) also specifies another way to do 367 flow filtering per packet/frame being received (n-tuple packet ECA 368 policy) ([I-D.kini-i2rs-fb-rib-info-model], 369 [I-D.hares-i2rs-fb-rib-data-model]) using a packet filter event- 370 match_condition-action policy [I-D.hares-i2rs-pkt-eca-data-model]. 371 The I2RS protocol allows a I2RS Client to talk to an I2RS Agent 372 within a routing device ([I-D.ietf-i2rs-architecture]) to set 373 ephemermal policy which is module ephemeral and box ephemeral. The 374 I2RS match_conditions examine frame/packet information (L1-L4, NV03, 375 and SFC), and I2RS match_actions that modify packet/frame 376 information. Figure 2 shows the structure of packet filtering ECA 377 rules from [I-D.hares-i2rs-fb-rib-data-model] which used by I2RS 378 Filter-Based RIB (FB-RIB). Note that these I2RS Filters have each 379 rule has policy rule name, policy rule order number, and rule status. 381 Section 5 compares the filters and actions between BGP Flow 382 Specification, I2RS Filter-Based RIB, Filter-RIB (aka Policy-Based 383 Routing), and the ACL. The I2RS packet filter rules also allow the 384 rule to be ordered and named. I2RS flow-based filters are ephemeral 385 state [I-D.ietf-i2rs-ephemeral-state] are stored as ephemeral state 386 which is lost upon a reboot. 388 +-----------+ +------------+ 389 |Rule Group | | Rule Group | 390 +-----------+ +------------+ 391 ^ ^ 392 | | 393 | | 394 +--------^-------+ +-------^-----------+ 395 | Rule | | Rule | 396 +----------------+ +-------------------+ 397 : : : : 398 :.................: : : : 399 : |.........: : : 400 +--V--+ +--V--+ : : 401 | name| |order| .........: :..... 402 +-----+ +-----+ : : 403 : : 404 +--------------V-------+ +--V------------+ 405 | Rule Match condition | | Rule Action | 406 +----------------------+ +---------------+ 407 : : : : : : 408 .....: . :..... .....: . :..... 409 : : : : : : 410 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+ 411 | Match | | match | |match | | Action || action ||action| 412 |Operator| |variable| |Value | |Operator||Variable|| Value| 413 +--------+ +--------+ +------+ +--------++--------++------+ 415 Figure 2: I2RS Filter-Based RIB Policy 417 1.4. BGP Flow Specification and logging 419 [RFC5575] specifies the Traffic Action Extended Community which 420 specifies a Terminal (T) action flag and Sampling (S) flag. The 421 sample flag indicates that "traffic sampling and logging" [is 422 enabled] for a set of flow specifications in a BGP packet. the 423 details of traffic sampling and logging are not specified in this 424 standard. Logging and sampling provide valuable information to 425 establish the impact of BGP Flow specification in order to automatic 426 intra-AS DoS prevention or inter-AS automation of DOS or VPN traffic 427 filters. [RFC5575] was written before the advent of yang modules 428 that specify operational state [I-D.ietf-netmod-opstate-reqs]. 429 [I-D.wu-idr-flowspec-yang-cfg] proposes a BGP Flow Specification Yang 430 Data model with BGP Flow Specification configuration, operational 431 state for BGP Flow specifications received from peers (BGP Session 432 Ephemeral state), and statistics on the use of filters, actions, and 433 dropped packets. Section 7 describes how the logging and 434 notifications for BGP Flow specifications can be added to this yang 435 module. 437 1.5. BGP Flow Specification and BGPSEC 439 [RFC5575] does not require BGP Flow specifications to be passed 440 BGPSEC [I-D.ietf-sidr-bgpsec-protocol]. [RFC5575] states "as long as 441 traffic filtering rules are restricted to match the corresponding 442 unicast routing paths for relevant prefixes, the security 443 characteristics of this protocol are equivalent to existing security 444 properties of BGP unicast properties", and "where this is not the 445 case, this would open the door to further denial of service attack" 446 (section 10). [I-D.eddy-idr-flowspec-exp] suggests passing BGP Flow 447 Specification in BGPSEC. Section 10 summarizes the security issues 448 with the current [RFC5575] and the enhancements described in this 449 draft, and discusses the proposed fixes that that 450 [I-D.eddy-idr-flowspec-exp] provides. 452 2. Definitions 454 2.1. Definitions and Acronyms 456 NETCONF: The Network Configuration Protocol [RFC6241]. 458 RESTconf - http programmatic protocol to access yang modules 459 [I-D.ietf-netconf-restconf] 461 BGPSEC - secure BGP [I-D.ietf-sidr-bgpsec-protocol]. 463 I2RS - Interface to Routing System [I-D.ietf-i2rs-architecture]. 465 ephemeral - state which does not survive a particular event. 467 BGP Session ephemeral state - state which does not survive the 468 loss of BGP peer, 470 Reboot ephemeral state - state which does not survive the reboot 471 of a software module, or a hardware reboot. 473 configuration state - state which persist across a reboot of 474 software module within a routing systsem or a reboot of a hardware 475 routing device. 477 2.2. RFC 2119 language 479 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 480 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 481 document are to be interpreted as described in [RFC2119]. 483 3. BGP Flow Specification Policy - Original and Expansions 485 3.1. Packet Reception Event 487 The reception of a packet is the event that causes the BGP policy to 488 enact. By default the BGP Flow specification applies to all 489 interfaces. This can be restricted by a BGP Flow Specification 490 Action or policy local to a node running the BGP peer session. 492 The definition of a packet is not limited to a IP packet (IPv4 or 493 IPv6) but also includes mpls packets, L2 frames (802.1Q), 494 encapsulated packets (NVGRE or VXLAN or any other NV03 495 encapsulation). 497 The same definition of the event is utilized by the I2RS Filter-based 498 RIBs ([I-D.kini-i2rs-fb-rib-info-model] and 499 [I-D.hares-i2rs-fb-rib-data-model] and the Filter-Based RIBs (draft- 500 hares-rtgwg-fb-rib-data-model), and ACL filters 501 [I-D.ietf-netmod-acl-model]. 503 These packet events are the standardized packet events. Additional 504 packet events for vendors may augment these standards events. 506 3.2. BGP Flow Specification Match Filters 508 [RFC5575] defines match conditions for IPv4 to be carried with the 509 NLRI format for 12 types of packet match events (see figure 3), and 510 that all filters specified must be combined by a "AND". The proposed 511 expansions to this filter list utilizing the Flow Specification NLRI 512 are listed in figure 4. [I-D.li-idr-flowspec-rpd] proposed a BGP 513 Attribute which contains additional flow specification filters, and 514 actions. Figure 5 contains the match filters from this draft. 516 The proposals to expand flow specification beyond [RFC5575] filter 517 specifications include: 519 Matches for the inner-outer header for encapsulated traffic for 520 being specified for the NV03 networks (MF-1, MF-2, MF-3) in 521 [I-D.hao-idr-flowspec-nvo3], 523 extended match filters carried in BGP attribute which includes 524 time (MF-5) for enacting flow-specification filter rules 525 ([I-D.li-idr-flowspec-rpd], [I-D.liang-idr-bgp-flowspec-time]). 527 One filter that seems obvious is the filter for the MPLS labels. 528 However, no proposal includes this Match filter for MPLS. 530 The precedence order for the match filter rules was specified in 531 [RFC5575] and expanded in [I-D.ietf-idr-flowspec-l2vpn]. The 532 combined precedence is shown in figure 4. 534 Table 1: IDR WG BGP Flow Specification Match Filter 535 +------+--------------------+-------------+-----------------------+ 536 |type# | Type Name | Match | Reference | 537 +======+====================+=============+=======================+ 538 | 1 | Destination Prefix | IPv4 Prefix | RFC5575 | 539 | | | IPv6 Prefix | ietf-idr-flow-spec-v6 | 540 | 2 | Source Prefix | IPv4 Prefix | RFC5575 | 541 | | | IPv6 Prefix | ietf-idr-flow-spec-v6 | 542 | 3 | IP protocol |IPv4 Protocol| RFC5575 | 543 | | | number | | 544 | 3 | Next Header |IPv6 protocol| ietf-idr-flow-spec-v6 | 545 | 4 | Port (source or | Port number | RFC5575 | 546 | | destination port) | | RFC5575 | 547 | 5 | Source port | Port number | RFC5575 | 548 | 6 | Destination port | Port number | RFC5575 | 549 | 7 | ICMP type | ICMP type | RFC5575 | 550 | 8 | ICMP code | ICMP code | RFC5575 | 551 | 9 | TCP Flags | 1 or 2 byte | RFC5575 | 552 | | | bitmask for | RFC5575 | 553 | | | TCP flags | | 554 | 10 | Packet length | # of bytes | RFC5575 | 555 | | (for IP packet) | | | 556 | 11 | DSCP | IPv4 DSCP | RFC5575 | 557 | | | (6 bit mask)| RFC5575 | 558 | 11 | Traffic class | IPv6 traffic| ietf-idr-flow-spec-v6 | 559 | | | (8 bit mask)| | 560 | 12 | IPv4 Fragment | 4 bit mask | RFC5575 | 561 | 13 | IPv6 Flow | 20 bit flow | ietf-idr-flow-spec-v6 | 562 | 14 | Ethernet type | 2 bytes |ietf-idr-flowspec-l2vpn| 563 | 15 | Source MAC | MAC address |ietf-idr-flowspec-l2vpn| 564 | 16 | Destination MAC | MAC Address |ietf-idr-flowspec-l2vpn| 565 | 17 | DSAP in LLC | 1 octet |ietf-idr-flowspec-l2vpn| 566 | 18 | SSAP in LLC | 1 octet |ietf-idr-flowspec-l2vpn| 567 | 19 | LLC Control field | 1 octet |ietf-idr-flowspec-l2vpn| 568 | 20 | SNAP | 5 octets |ietf-idr-flowspec-l2vpn| 569 | 21 | VLAN ID | 1 or 2 bytes|ietf-idr-flowspec-l2vpn| 570 | 22 | VLAN COS | 3 bit COS |ietf-idr-flowspec-l2vpn| 571 | 23 | Inner VLAN ID | 1 or 2 bytes|ietf-idr-flowspec-l2vpn| 572 | 24 | Inner VLAN COS | 1 or 2 bytes|ietf-idr-flowspec-l2vpn| 573 +======+====================+=============+=======================+ 575 Figure 3 577 Table 2: Proposed BGP Flow Specification Match Condition Filters 578 +------+--------------------+-------------+-----------------------+ 579 |type# | Type Name | Match | Reference | 580 +======+====================+=============+=======================+ 581 | MF-1 | Delimiter type | 2 bytes | hao-idr-flowspec-nv03 | 582 | | (Encapsulation type| | | 583 | | VXLAN or NVGRE) | | | 584 | | | | | 585 | MF-2 | VNID | 24 bit VN | hao-idr-flowspec-nv03 | 586 | |(virtual network ID)| | | 587 | | | | | 588 | MF-3 | Flow ID |8 bit flow ID| hoa-idr-flowspec-nv03 | 589 | | (NVGRE Flow ID ) | | | 590 | | | | | 591 | MF-4 | MPLS LSP | TBD | not specified | 592 | |(label 20 bits, | Label stack | | 593 | | EXP (3 bits), S Bit| | | 594 | | TTL (8 bits) | | | 595 | | | | | 596 | MF-5 | Interface | TBD | not specified | 597 | |(Group ID, intf id) | | | 598 +======+====================+=============+=======================+ 600 Figure 4 602 Table 3: Proposed BGP Flow Specifications Match in BGP Attribute 604 +------+--------------------+-------------+-----------------------+ 605 |type# | Type Name | Match | Reference | 606 +======+====================+=============+=======================+ 607 | MF-6 | Time | ?? | liang-idr-bgp-flowspec| 608 | | | | -time | 609 +======+====================+=============+=======================+ 610 Figure 5 612 3.2.1. Current Precedence logic 613 Precedence logic for BGP Flow Specifications 614 (RFC5575, draft-idr-bgp-flowspec-l2vpn) 616 flow-rule-cmp (a,b) 617 { 618 comp1 = next_component(a); 619 comp2 = next_component(b); 620 while (comp1 || comp2) { 621 // component_type returns infinity on end of list 622 if (component_type(comp1) < component_type(comp2)) { 623 return A_HAS_PRECEDENCE; 624 } 626 if (component_type(comp1) > component_type(comp2)) { 627 return B_HAS_PRECEDENCE; 628 } 630 // IP values) 631 if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) { 632 common = MIN(prefix_length(comp1),prefix_length(comp2)); 633 cmp = prefix_compare (comp1,comp2,common); 634 // not equal, lowest value has precedence 635 // equal, longest match has precedence; 636 } else if (component_type (comp1) == MAC_DESTINATION || 637 MAC_SOURCE) { 638 common = MIN(MAC_address_length(comp1), 639 MAC_address_length(comp2)); 640 cmp = MAC_Address_compare(comp1,comp2,common); 641 //not equal, lowest value has precedence 642 //equal, longest match has precedence 643 } else { 644 common = MIN(component_length(comp1), 645 component_length(comp2)); 646 cmp = memcmp(data(comp1), data(comp2), common); 647 //not equal, lowest value has precedence 648 //equal, longest string has precedence 649 } 650 } 651 } 653 Figure 6 655 3.2.2. Why Current Match precedence Logic a problem 657 The current precedence logic requires the following: 659 o destination address (0/0 is fine for destination match, 660 o components to go in numerical order, 662 o and the matches to be an "AND of all component matches. 664 This does not allow matching MPLS before IP address, or MAC Addresses 665 before IP addresses. This may make some n-tuple filter policies more 666 difficult or even impossible to express in this fasion. 668 3.3. BGP Flow Specification Actions 670 [RFC5575] also defines four actions which would be carried in BGP 671 extended communities: traffic rate (in bytes), traffic action, 672 redirect to IPv4 VPAN, and traffic marking. Traffic action has two 673 bits Terminal bit (T) and Sample (S) bit. If the Terminal Bit is 674 set, the the node apply all filter rules based as defined by "AND" 675 and precedence. If the terminal bit is clear, then the flow 676 specification process is to stop. The Sample bit implies that the 677 flow specification enables sampling and logging for this event. 679 Unfortunately, [RFC5575] was unclear about the "redirect to IP VPN 680 action" and did not handle IPv6. [RFC7674] was written to clarify 681 [RFC5575] by clearly specifying the 3 extended communities that "IPv4 682 VPN" needed to support AS 4 byte, and IPv4 address Routing 683 Distinguishers (RDs). [I-D.ietf-idr-flow-spec-v6] was written to 684 extend this work to IPv6 filters, and to include the IPv6 flow in the 685 filter set as figure 5 shows. 687 Table 4: BGP Flow Specifications in RFC5575 and RFC7674 688 +-------+--------------------+-------------+-----------------------+ 689 |type# | Action name | action | Reference | 690 +=======+====================+=============+=======================+ 691 |0x8006 | Traffic Rate | 2 octet AS | RFC5575 | 692 | | (in bytes ) |4 octet float| | 693 | | | | | 694 |0x8007 | Traffic Action |6 octet bit | RFC5575 | 695 | |(S:Sample and log, |mask:S,T bits| | 696 | | T:last flowspec | | | 697 |0x8008 | Redirect (IP VPN) |Route Target | RFC5575 and RFC7674 | 698 | | (RD: 2 octet AS, |(6 octet) | | 699 | | 4 octet value) | | | 700 |0x8108 | Redirect (IP VPN) |Route Target | RFC7674 | 701 | | (RD: 4 octet IPv4 |(6 octet) | | 702 | | address, 2 byte | | | 703 | | value) | | | 704 |0x8208 | Redirect (IP VPN) |Route Target | RFC7674 | 705 | | (RC: 4 byte AS, | | | 706 | | 2 byte value ) | | | 707 +=======+====================+=============+=======================+ 709 Figure 7 711 3.3.1. Proposals to extend these standardized actions 713 Proposals to extend the actions take upon a match include: 715 o (FA1) [I-D.eddy-idr-flowspec-packet-rate] specifies a traffic rate 716 limit by packets the number of packets forwarded, 718 o (FA2)[I-D.li-idr-flowspec-rpd] specifies an "R" bit for traffic 719 action that allows a BGP Attribute to pass additional BGP 720 Flowspecification match filters and actions, 722 o (FA3) [I-D.hao-idr-flowspec-redirect-tunnel] specifies a 723 redirection to a tunnel specified in 724 [I-D.rosen-idr-tunnel-encaps], 726 o (FA4)[I-D.ietf-idr-flowspec-l2vpn] specifie push, pop, or swap 727 VLANs before forwarding, 729 o (FA5) [I-D.ietf-idr-flowspec-l2vpn] specifies the ability to 730 replace TPIDs values with new values before forwarding, 732 o (FA6) [I-D.liang-idr-bgp-flowspec-label] specifies push/pop/swap 733 on MPLS labels before forwarding, 735 o (FA7)[I-D.litkowski-idr-flowspec-interfaceset] which specifies 736 that ACL filters plus BGP flow specification filters will 737 determine the acceptance/drop of inbound packet, and the 738 forwarding/drop of outbound packets. 740 Figure 8 shows these flow specifications. 742 Table 5: Proposed Flow Specification Actions 743 +----- -+--------------------+-------------+-----------------------+ 744 |type# | Action name | action | Reference | 745 +=======+====================+=============+=======================+ 746 | FA1 | Traffic Rate | 2 octet AS | eddy-idr-flowspec- | 747 | | (in packets) |4 octet float| packet-rate | 748 | | | | | 749 | FA2 | Extended Traffic | R bit | li-idr-flowspec-rpd | 750 | | Extension for R | P bit | Alternate action | 751 | | to take additional | | procedures(this draft)| 752 | | Flow specifications| | | 753 | | from BGP Flow spec | | | 754 | | Policy attribute | | | 755 | | | | | 756 | FA3 | Redirect to tunnel |6 octets | hao-idr-flowspec- | 757 | | (tunnel in |1 bit flag | redirect-to-tunnel | 758 | | BGP Attribute) |(C=applies to| | 759 | | | copies only)| | 760 | | | | | 761 | FA4 | VLAN-action | bitmask |idr-bgp-flowspec-l2vpn | 762 | |(push, pop, swap) | | | 763 | | | | | 764 | FA5 | TPID Action |6 octets |idr-bgp-flowspec-l2vpn | 765 | | (NVGRE Flow ID ) | | | 766 | | | | | 767 | FA6 | Label Action |MPLS Tag, |liang-idr-bgp-flowspec-| 768 | |(push/pop/swap MPLS |TTL(1 octet) | label-01 | 769 | |label uses Exp flag,| S bit | | 770 | |TTL, Stack flag (S))| | | 771 | | | | | 772 | FA7 | Alternate NLRI | validation |eddy-idr-flowspec-exp | 773 | | Validation | bit mask |(some functions) | 774 | | (mask for support | | | 775 | | of RFC5755, ROA | | | 776 | | and bgpsec-protocol| | | 777 | | AS path) and L2MAC | | | 778 | | NRLI for IP Address| | | 779 | | | | | 780 | FA8 | for Interface set | 4 Byte AS |litkowski-idr-flowspec-| 781 | | filter ACL + Flow | 2 byte | interfaceset | 782 | | specification rules| interface | | 783 | | | group ID | | 784 +=======+====================+=============+=======================+ 786 Note: FA8 is really a filer plus an action: 787 FA8-filter: Restrict processing for filters to set of interfaces 788 FA8-Action: Forward only if: ACL + Flow-Specification filters 789 suggest forwarding. 791 Figure 8 793 3.3.2. Why ordering is needed 795 One the probems with adding the actions is that precedence has not 796 been set for the actions, and some actions can conflict. (see 797 section 799 [RFC5575] indicates that the actions specified in the document 800 represent only the "subset of filtering actions that can be 801 interpreted across the network". As additional standardized actions 802 occur, the non-standard action will need to have a precedence below 803 the standardized actions. 805 To allow better security for Flow Specification NLRIs, the BGP 806 validation of prefixes using the Route Origination (ROAs) technology 807 ([RFC6483]) should be placed as the first action for a prefix. If 808 the path needs to be validated The bgp-sec protocol 809 [I-D.ietf-sidr-bgpsec-protocol] can be used to validate the AS path 810 and actions. These validations must be first, and this is not 811 allowed with the current actions. 813 One the probems with adding the actions is that precedence has not 814 been set for the actions, and some actions may conflict. Table 6 815 suggests an order with the fewest conflicts, but even there proposal 816 will need to be updated to handle these conflicts. 818 Table 6 - Action Precedence and Conflicts between Actions 819 +-----+---------------------+----------------------------------+ 820 |order| Action | Possible Conflicting Actions | 821 +=====+=====================+==================================+ 822 | FA7 | Alternate NLRI | none | 823 | 1 | Validation | | 824 | | (mask for support | | 825 | | of RFC5755, ROA | | 826 | | and bgpsec-protocol | | 827 | | AS path) | | 828 | | | | 829 | 2 | Traffic Rate(0x8006)| Traffic rate in packets (FA1) | 830 | | in bytes | | 831 | | | Default Conflict action: | 832 | | | Allow traffic monitoring by bytes| 833 | | | and packets, but process byte | 834 | | | rate limit checks first | 835 | | | | 836 | 3 | Traffic Rate (FA1) | traffic rate in bytes (0x8006) | 837 | | in packets | | 838 | | | Default Conflict action: same | 839 | | | as in Traffic Rate action | 840 | | | conflict | 841 | | | | 842 | 4 | Traffic Action | Extended Traffic action with | 843 | | (0x8007) | "R-Policy" bit(FA2), "TN-P" bit, | 844 | | | R-intf bit | 845 | | | | 846 | | | Default conflict action: Process | 847 | | | Traffic Action, then Extended | 848 | | | traffic action | 849 | | | | 850 | 5 | Extended Traffic | Traffic Action (0x8007) | 851 | | Action (FA2) |"R" bit(FA2), "TN-P" bit (above) | 852 | | | R-Intf bit | 853 | | | | 854 | | | Default conflict action: Process | 855 | | | Traffic action, then extended | 856 | | | traffic action | 857 | | | | 858 | 6 | Redirect to IP-VPN | Redirect to IP Tunnel (FA3) | 859 | | 0x8008: 2 byte AS RD| VLAN-action (FA4), | 860 | | 0x8108: 4 byte IP RD| TPID-action (FA5) | 861 | | 0x8208: 4 byte AS RD| Label-action (FA6) | 862 | | | interface set (FA7) | 863 | | | | 864 | | | Default Conflict action: | 865 | | | Process forward to IP-VPN first | 866 | | | and ignore other conflicting | 867 | | | actions unless TN-Mod bit set in | 868 | | | Extended action. 869 | | | If TN-Mod set then process the | 870 | | | conflict actions which change | 871 | | | the packet prior to forwarding | 872 | | | the packet via tunnel to IP-VPN. | 873 | | | | 874 | | | If I bit set, process interface | 875 | | | restriction's narraowing of scope| 876 | | | to certain interfaces before | 877 | | | processing other options, and | 878 | | | process interface restrictions | 879 | | | implied in outboudn direction | 880 | | | before sending packet. | 881 | | | outbound policy before any other | 882 | | | If "R" bit set use version 2 of | 883 | | | BGP Flow Specification handling | 884 | | | | 885 | 7 | Redirect to IP | Redirect to IP VPN (0x8008, | 886 | | Tunnel (FA3) | 0x8108, 0x8208) | 887 | | | VLAN-action (FA4), | 888 | | | TPID-action (FA5), | 889 | | | Label action (FA6), | 890 | | | interface set (FA7) | 891 | | | | 892 | | | Default Conflict actions: | 893 | | | Refer to processing in redirect | 894 | | | IP-VPN tunnel | 895 | | | | 896 | 8 | VLAN action (FM4) | Redirect to IP-VPN (0x8008, | 897 | | | 0x8108, 0x8208), | 898 | | | Redirect to tunnel (FA3), | 899 | | | VLAN-action (FA4), | 900 | | | TPID-action (FA5), | 901 | | | Label action (FA6), | 902 | | | interface set (FA7) | 903 | | | | 904 | | | Default Conflict actions: | 905 | | | Refer to processing in redirect | 906 | | | IP-VPN tunnel | 907 | | | | 908 | 9 | TPID action (FM5) | Redirect to IP-VPN (0x8008, | 909 | | | 0x8108, 0x8208), | 910 | | | Redirect to tunnel (FA3), | 911 | | | VLAN-action (FA4), | 912 | | | TPID-action (FA5), | 913 | | | Label action (FA6), | 914 | | | interface set (FA7) | 915 | | | | 916 | | | Default Conflict actions: | 917 | | | Refer to processing in redirect | 918 | | | IP-VPN tunnel | 919 | | | | 920 | 10 | Label Action (FM6) | Redirect to IP-VPN (0x8008, | 921 | | | 0x8108, 0x8208), | 922 | | | Redirect to tunnel (FA3), | 923 | | | VLAN-action (FA4), | 924 | | | TPID-action (FA5), | 925 | | | Label action (FA6), | 926 | | | interface set (FA7) | 927 | | | | 928 | | | Default Conflict actions: | 929 | | | Refer to processing in redirect | 930 | | | IP-VPN tunnel | 931 | | | | 932 | 11 | interface Set (FM8a)| Redirect to IP-VPN (0x8008, | 933 | | | 0x8108, 0x8208), | 934 | | | Redirect to tunnel (FA3), | 935 | | | VLAN-action (FA4), | 936 | | | TPID-action (FA5), | 937 | | | Label action (FA6), | 938 | | | | 939 | | | Default Conflict actions: | 940 | | | Refer to processing in redirect | 941 | | | IP-VPN tunnel | 942 | | | | 943 | 12 | Filter precedence | reorder default filter precedence| 944 | | (FM8b) | 0 = BGP Flow-Spec only | 945 | | [proposed] | 1 = ACL + BGP Flow-Spec | 946 | | | 2 = I2RS FB-RIB + BGP FS | 947 | | | 3 = ACL + I2RS FB-FIB + BGP FS | 948 | | | 4 = Config FB-RIB + BGP FS | 949 | | | 5 = ACL + config FB-RIB + BGP FS | 950 | | | 6 = Config FB-RIB + I2RS FB-RIB +| 951 | | | BGP FS | 952 | | | 7 = ACL + config FB-FIB + I2RS | 953 | | | | 954 |13-63| | Reserved for other standards | 955 | | | actions | 956 | | | | 957 |65+ | FCFS actions | FCFS Actions | 958 +=====+=====================+==================================+ 959 Figure 9 961 Conflict process may have an ordering of the conflict processes or 962 parallel processes. Due to this conflict processing also needs to 963 have common diagrams or a language for precedence that is common 964 across all rules. An example of a conflict diagram is below. 965 Conflict 1 and Conflict 2 are parallel conflict resolutions that are 966 run prior to conflict 3. 968 action precedence 1 precedence 2 969 +----------+ +-----------+ 970 | action 1 |-------|conflict 1 |----| 971 | | +-----------+ | +----------+ 972 | | |---|conflict 3| 973 | | +-----------+ | +----------+ 974 | |-------|conflict 2 |----| 975 +----------+ +-----------+ 977 precedence of conflicts for action 1 {} 978 precedence(1) = conflict 1 | conflict 2; 979 precedence(2) = conflict 3; 980 If precedence (1) found; continue 981 if precedence (3) found; exit; 982 } 984 Figure 10 986 4. Proposal to Expand BGP Flow Specification Security 988 [RFC5575] does not require BGP ROA [RFC6483] as the BGP ROA was not 989 standardized until after [RFC5575]. [RFC5575] states "as long as 990 traffic filtering rules are restricted to match the corresponding 991 unicast routing paths for relevant prefixes, the security 992 characteristics of this protocol are equivalent to existing security 993 properties of BGP unicast properties", and "where this is not the 994 case, this would open the door to further denial of service attack" 995 (section 10). 997 [RFC5575] requires an extension of the BGP route selection procedures 998 [RFC4271] in section 9.1.2 in order to validate the BGP flow 999 specification NLRI. The BGP Flow Specification NLRI is valid if and 1000 only if: 1002 o "the originator of the flow specification matches the orginator of 1003 the the best-match unicast route for the destination prefix 1004 embedded in the flow specification", 1006 o "no more specific unicast routes" exist "when compared with the 1007 flow destination prefix", that have been received from a different 1008 neighboring AS than the best-match unicast route, which has been 1009 determined in step A". 1011 This set of validation requirements also require that BGP 1012 implementations are required to enforce the AS_PATH attribute having 1013 the neighbor AS in the left-most position. 1015 4.1. Validation for NLRI with L2VPN validation 1017 These validation steps required a unicast IPv4 or IPv6 route be 1018 transmitted with L2VPN ([I-D.ietf-idr-flowspec-l2vpn]) and the NV03 1019 flow specifications [I-D.hao-idr-flowspec-nvo3] to validate the path. 1020 These specifications do not provide additional details on any 1021 additional validation needed for the L2VPN or NV03 Case. 1023 4.2. Using ROA to validate BGP Flow Specification 1025 Since [RFC5575] BGP Route Origin validation [RFC6482] has been 1026 standardized, and the BGPSEC protocol [I-D.ietf-sidr-bgpsec-protocol] 1027 has been developed. This document proposes that an action be created 1028 in both the proposals that has precedence over all other actions. 1030 [I-D.eddy-idr-flowspec-exp] specifies cryptographic enhancements that 1031 include: 1033 o creating a BGP identifier (in BGP attribute or in BGPSEC 1034 signature), 1036 o Expanding BGPSEC coverage for Route Orgination Authorization (ROA) 1037 to cover the orignator of the BGP Flow specification for the BGP 1038 Flow specification SAFIs. 1040 o Covering the BGP Extended Communities with BGP signature. 1042 While this work is interesting, the authors of 1043 [I-D.eddy-idr-flowspec-exp] consider it research into the use of BGP 1044 security. Therefore, this proposal suggest this addition be covered 1045 as an expansion to the ROA process. As this solitifies the ROA- 1046 action should be updated to include this functionality. 1048 4.3. Using BGPSec to validate AS Path 1050 The use of bgpsec protocol to validate the AS Path is orthongonal to 1051 the validation of the prefix to origin AS. Therefore, local 1052 configuration can determine if the bgpsec protocol is supported and 1053 required to validate the AS Path checked for the set of peers using 1054 BGP Flow Specification. If bgpsec is configured to be used, the BGP 1055 FLOW Specification SHOULD use the secured AS Path for its validation 1056 checks. 1058 5. Minimal BGP-FS Additions (Option 1) 1060 This section on minimal subset solution has: 1062 summary of NLRI and extended community formats (xection 5.1) 1063 security addition of ROA (section 5.2), 1065 match filter list and precedence of match filters (section 5.3), 1067 action list and precedence of actions(section 5.4), 1069 conflict with other Packet-reception Event-MatchCondition-Action 1070 (ECA) policy (I2RS Filter-Based RIB and Policy-Based Routing 1071 (n-tuple forwarding)) (section 5.9), 1073 pros-cons of this approach (section 5.10) 1075 It is important to note that BGP Flow Specification is not the only 1076 packet reception ECA policy in a system. BGP Flow specification is 1077 session ephemeral state which is not guaranteed to persist when the 1078 BGP peer session closes. I2RS Filter-Based RIB is reboot ephemeral 1079 state which will not persist when the routing entity reboots. Policy 1080 RIB (aka Filter Forwarding RIB) and ACLs are configuration state 1081 which can persist over the reboot of a system. In many systems, 1082 operator-applied policy may set the priority between these systems. 1083 In order to provide interoperability between BGP Flow Specificastion 1084 and current IETF management systems using yang-models accessed by 1085 netconf, restconf, and I2RS protocols, it important to define the 1086 default precedence between these different packet reception ECA 1087 policies. Section 5.9 provides the details on this proposals. 1089 5.1. Summary of Existing Flow Specification Formats 1091 The existing BGP Flow Specification is contained with the the BGP 1092 Flow Specification NLRI encoded using MP_REACH_NLRI and the 1093 MP_UNREACH_NLRI as defined in [RFC4760]. If the application does not 1094 require the next-hop field, it will be encoded as 0 length. The BGP 1095 FLow Specification NLRI is encoded as shown in figure 11. [RFC5575] 1096 specifies SAFI 133 for "dissemination of IPv4 flow specification", 1097 and SAFI 134 for "dissemination of VPNv4 Flow Specification". 1098 [I-D.ietf-idr-flow-spec-v6] expands the use of these SAFI to the IPv6 1099 AFI. [I-D.ietf-idr-flowspec-l2vpn] expands this use to L2VPN for the 1100 VPLS [RFC4761], EVPN and LDP-Based VPLS [RFC4762] with BGP auto- 1101 discovery [RFC6074]. 1103 +-------------------------+ 1104 | length (0xnn or 0xfn nn)| (1 or 2 octets depending on encoding) 1105 +-------------------------+ 1106 | NLRI Value (variable) | 1107 +-------------------------+ 1109 SAFI AFIs 1110 133 IPv4 (AFI=1), 1111 IPv6 (AFI=2) 1112 134 IPv4 VPNs (AFI=1), 1113 IPv6 VPNs(AFI=2), 1114 L2VPN (AFI=25) 1116 Figure 11 1118 The actions for the BGP Flow Specification are carried in 6 bytes of 1119 the BGP Extended Community. 1121 5.2. New Validation Rules for BGP Flow Specification: Precedence with 1122 ROA 1124 This precedence within BGP Session Ephemeral state depends on the 1125 preference associated with valid BGP Session flow specification NLRI 1126 received within a BGP State. Since [RFC5575] was published, 1127 additional mechanisms to validate originating prefixes with an AS 1128 with Prefix Orgin Validation (ROA), and the BGPSEC Secure Path have 1129 been standardized. The precedence of these mechanisms should be from 1130 BGP Security to ROA to [RFC5575]. The BGP peers determine that a BGP 1131 Flow specification is valid if and only if one of the following 1132 cases: 1134 o If the BGP Flow Specification NLRI has a IPv4 or IPv6 address in 1135 destination address match filter and the following is true: 1137 * A BGP ROA has been received to validate the originator, and 1139 * the route is the best-match unicast route for the destination 1140 prefix embedded in the match filter; or 1142 o If a BGP ROA has not been received that matches the IPv4 or IPv6 1143 destination address in the destination filter, the match filter 1144 must abide by the [RFC5575] validation rules of: 1146 * The originator match of the flow specification matches the 1147 originator of the best-match unicast route for the destination 1148 prefix filter embedded in the flow specification", and 1150 * No more specific unicast routes exist when compared with the 1151 flow destination prefix that have been received from a 1152 different neighboring AS than the best-match unicast route, 1153 which has been determined in step A. 1155 The best match is defined to be the longest-match NLRI with the 1156 highest preference. 1158 5.3. Match Condition Filters with Precedence Ordering 1160 Match conditions depends on an "AND" of all rules within a Flow 1161 Specification policy. A Flow specification policy is defined by a 1162 sequence of BGP Flow specification NLRIs with filter-match rules. 1163 The sequence of Flow Specification rules are terminate Traffic Action 1164 with a T-Bit flag set to zero. 1166 Match condition processing occurs in the following overall precedence 1167 ordered from IP protocol to 1169 1. IP Protocol (1-13), 1171 2. NV03-matches (MF-1 to MF-3), 1173 3. Other overlay matches (spring, SFC) 1175 4. L2VPN matches (14-24), 1177 5. MPLS matches (MF-4), 1179 6. L2VPN matches (currently 14-24), 1181 7. interfaces matches (MF-5), 1183 8. time matches (MF-6), and 1185 9. Non-Standardized (First-Come-First Serve(FCFS)) match conditions 1186 (see [RFC5575] section 11) 1188 Editorial note: This list is longer than many, and will be discussed 1189 on the IDR mail list. 1191 Table 6 in figure 9 shows the filter by filter precedence order. All 1192 flow specification filters combine as an "AND" of all filters. A re- 1193 ordering of match filters is only possible in the the proposed 1194 version 2 of BGP Flow specification. 1196 5.3.1. Table of Match Filters and Precedence 1198 Table 8: Flow Specification Match Filter Precedence Order 1199 +------+--------------------+-------------+-----------------------+ 1200 |type# | Type Name | Match | Reference | 1201 +======+====================+=============+=======================+ 1202 | 1 | Destination Prefix | IPv4 Prefix | RFC5575 | 1203 | | | IPv6 Prefix | ietf-idr-flow-spec-v6 | 1204 | 2 | Source Prefix | IPv4 Prefix | RFC5575 | 1205 | | | IPv6 Prefix | ietf-idr-flow-spec-v6 | 1206 | 3 | IP protocol |IPv4 Protocol| RFC5575 | 1207 | | | number | | 1208 | 3 | Next Header |IPv6 protocol| ietf-idr-flow-spec-v6 | 1209 | 4 | Port (source or | Port number | RFC5575 | 1210 | | destination port) | | RFC5575 | 1211 | 5 | Source port | Port number | RFC5575 | 1212 | 6 | Destination port | Port number | RFC5575 | 1213 | 7 | ICMP type | ICMP type | RFC5575 | 1214 | 8 | ICMP code | ICMP code | RFC5575 | 1215 | 9 | TCP Flags | 1 or 2 byte | RFC5575 | 1216 | | | bitmask for | RFC5575 | 1217 | | | TCP flags | | 1218 | 10 | Packet length | # of bytes | RFC5575 | 1219 | | (for IP packet) | | | 1220 | 11 | DSCP | IPv4 DSCP | RFC5575 | 1221 | | | (6 bit mask)| RFC5575 | 1222 | 11 | Traffic class | IPv6 traffic| ietf-idr-flow-spec-v6 | 1223 | | | (8 bit mask)| | 1224 | 12 | IPv4 Fragment |4 bit mask | RFC5575 | 1225 | 13 | IPv6 Flow |20 bit flow | ietf-idr-flow-spec-v6 | 1226 | 14 | Delimiter type | 2 bytes | hao-idr-flowspec-nv03 | 1227 | MF-1 | (Encapsulation type| | | 1228 | | VXLAN or NVGRE) | | | 1229 | | | | | 1230 | 15 | VNID | 24 bit VN | hao-idr-flowspec-nv03 | 1231 | MF-2 |(virtual network ID)| | | 1232 | | | | | 1233 | 16 | Flow ID |8 bit flow ID| hoa-idr-flowspec-nv03 | 1234 | MF-3 | (NVGRE Flow ID ) | | | 1235 | | | | | 1236 | 17 | Segment ID | | | 1237 |18-25 | Other packet ids | | | 1238 | | above MPLS | | | 1239 | 29 | MPLS LSP | TBD | not specified | 1240 | MF-4 |(label 20 bits, | Label stack | | 1241 | | EXP (3 bits), S Bit| | | 1242 | | TTL (8 bits) | | | 1243 | | | | | 1244 | | | | | 1245 | 30 | Ethernet type | 2 bytes |ietf-idr-flowspec-l2vpn| 1246 | 31 | Source MAC |MAC address |ietf-idr-flowspec-l2vpn| 1247 | 32 | Destination MAC |MAC Address |ietf-idr-flowspec-l2vpn| 1248 | 33 | DSAP in LLC | 1 octet |ietf-idr-flowspec-l2vpn| 1249 | 34 | SSAP in LLC | 1 octet |ietf-idr-flowspec-l2vpn| 1250 | 35 | Control in LLC |1 octet |ietf-idr-flowspec-l2vpn| 1251 | 36 | SNAP | 5 octet |ietf-idr-flowspec-l2vpn| 1252 | 37 | VLAN ID |1 or 2 bytes |ietf-idr-flowspec-l2vpn| 1253 | 38 | VLAN COS | 3 bit COS |ietf-idr-flowspec-l2vpn| 1254 | 39 | Inner VLAN ID |1 or 2 bytes |ietf-idr-flowspec-l2vpn| 1255 | 40 | Inner VLAN COS |1 or 2 bytes |ietf-idr-flowspec-l2vpn| 1256 | 41 | Interface | TBD | not specified | 1257 | |(Group ID, intf id) | | | 1258 | 42 |Time | | | 1259 | 65 |FCFS matches | | non-standard actions | 1260 +======+====================+=============+=======================+ 1261 Figure 12 1263 5.3.2. FCFS Flow Specification Match Condition Filter Interaction 1265 [RFC5575] allowed for non-IETF standardized Flow Specification 1266 filters and extended community actions. The beginning order of 1267 precedence for non-IETF standardized FCFS BGP Flow specification 1268 match filters is 65. The network management yang modules SHOULD 1269 store the BGP Flow Specification match type byte for both IETF 1270 Standardized BGP Flow Specification Match Filters, FCFS BGP BGP Flow 1271 Specification Match filters. 1273 5.4. Flow Specification Actions and Action Precedence 1275 Some BGP Flow Specification actions can conflict with other BGP Flow 1276 specification Actions. It will be the duty of each action 1277 specification to indicate how it interacts with the deafult 1278 precedence in Table 9 in figure 13 and the potential conflicts (shown 1279 in table 6 figure 9). 1281 Table 9 provides the default precedence for actions for the minimal 1282 subset. All Standards actions have precedence overall FCFS actions 1283 incoded in BGP Extended Communities. 1285 Table 9 - Action Precedence and Conflicts between Actions 1286 +-----+------------------------------------------------------+ 1287 |order| Action | 1288 +=====+======================================================+ 1289 | 1 | Alternate NLRI Validation (ROA, and future ROA) (FA7)| 1290 | 2 | Traffic Rate in bytes (0x8006) | 1291 | 3 | Traffic Rate in packets (FA1) | 1292 | 4 | Traffic Action (0x8007) (T or S bit) | 1293 | 5 | Redirect to IP-VPN (0x8008, 0x8108, 0x8208) | 1294 | | 0x8008: 2 byte AS RD| | 1295 | | 0x8108: 4 byte IP RD| | 1296 | | 0x8208: 4 byte AS RD| | 1297 | 6 | Redirect to IP Tunnel (FA3) | 1298 | 7 | VLAN action (FM4) | 1299 | 8 | TPID action (FM5) | 1300 | 9 | Label Action (FM6) | 1301 | 10 | Interface set (FM8a) | 1302 | 11 | packet-ECA policy interaction | 1303 | | 0 = BGP Flow-Specification (BGP FS) only | 1304 | | 1 = ACL + BGP FS | 1305 | | 2 = I2RS FB-RIB + BGP FS | 1306 | | 3 = ACL + I2RS FB-FIB + BGP FS | 1307 | | 4 = Config FB-RIB + BGP FS | 1308 | | 5 = ACL + config FB-RIB + BGP FS | 1309 | | 6 = Config FB-RIB + I2RS FB-RIB + BGP FS | 1310 | | 7 = ACL + config FB-FIB + I2RS | 1311 |12-64| Reserved for other standards actions | 1312 | | | 1313 |65+ | FCFS actions | 1314 +=====+======================================================+ 1315 Figure 13 1317 5.4.1. FCFS Extended Communities with BGP Flow Specification Actions 1319 [RFC7153]allows for FCFS (First Come First Serve) allocation of BGP 1320 transitive types. If an action is specified in the FCFS registry, 1321 the default precedence is after all standardized BGP Flow 1322 Specification actions(action 65+). The BGP Flow Specification Yang 1323 models should store the Extended Community value for the FCFS based 1324 Flow Specification action. If the precedence ordering has been 1325 changed by the FCFS, this should be stored in the configuration of 1326 BGP Flow Specification and in the operational state. 1328 5.5. Precedence with other packet ECA policies 1330 The BGP Flow Specification policy is currently handled as part of the 1331 route selection process within BGP. Between BGP and other n-tuple 1332 packet ECA policies, the precedence policies is handled by the 1333 operator-applied policies (which often have operator default) which 1334 assign order and preference of filters within within an order. The 1335 default assumption for BGP-FS is to assume the worst possible valid 1336 order if none is specified (e.g. 254 out of 255 ), and to assume the 1337 priority within that order as shown in table 10. BGP Flow 1338 Specification (BGP-FS) Flow Specification for 128.2/16 destination 1339 port 20 may conflict with the following: 1341 a) I2RS Flow Specification for destination address 128.2/16 with 1342 destination port 12, and 1344 b) ACL filter for 128.2/16 destination address 128.2/16 with 1345 destination port 12. 1347 In summmary, the precedence is least dynamic in configuration to most 1348 dynamic received. However, a BGP-FS action may signal a remote 1349 operator applied priority for a set of routes that allows the filters 1350 to combine certain filters (see table 11). 1352 Table 10 - Precedence within a single order 1353 +--------+---------------------------------------------------+ 1354 |priority| Filter source | 1355 +========+===================================================+ 1356 | 10 | BGP Flow Specification received from peer | 1357 | 9 | BGP Flow Specification from Peer + BGP-FS action | 1358 | 8 | BGP Flow Specification configured on local peer | 1359 | | that is installed and distributed | 1360 | | | 1361 | 7 | I2RS Flow Specification | 1362 | 5 | policy routing packet ECA filters configured | 1363 | 4 | ACLS configured | 1364 | 3 | policy configured in general routing table | 1365 | | (netmod-routing-cfg) | 1366 +------------------------------------------------------------+ 1367 Figure 14 1368 Table 11 - actions that combine packet ECA policy 1369 +-----+------------------------------------------------------+ 1370 |order| Action | 1371 +=====+======================================================+ 1372 | 11 | packet-ECA policy interaction action based | 1373 | | 0 = BGP Flow-Specification (BGP FS) only | 1374 | | 1 = ACL + BGP FS | 1375 | | 2 = I2RS FB-RIB + BGP FS | 1376 | | 3 = ACL + I2RS FB-FIB + BGP FS | 1377 | | 4 = Config FB-RIB + BGP FS | 1378 | | 5 = ACL + config FB-RIB + BGP FS | 1379 | | 6 = Config FB-RIB + I2RS FB-RIB + BGP FS | 1380 | | 7 = ACL + config FB-FIB + I2RS | 1381 |12-64| Reserved for other standards actions | 1382 | | | 1383 |65+ | FCFS actions | 1384 +=====+======================================================+ 1385 Figure 15 1387 5.6. pros and cons of Minimal subset BGP-FS Additions (Option 1) 1389 Pro - for Minimal subset (Option 1) 1391 Version 1's basic mechanism for BGP Flow Specification has been 1392 tested. Additions can be added incrementally. 1394 Con - for Minimal Subset (Option 1) 1396 The current version 1 of the Flow Specification does not have 1397 ordering of packet ECA policy rules, flow specification filters, or 1398 flow specification actions other than the default precedence. 1399 Current implementations of BGP flow specification are finding this 1400 lack of ordering to cause operational difficulties. 1402 6. BGP-FS-v2 (New NLRI and Wide Communities Approach)(option 2) 1404 This section on minimal subset solution has: 1406 summary of NLRI and extended community formats (xection 6.1) 1408 security addition of ROA (section 6.2), 1410 match filter list and precedence of match filters (section 6.3), 1412 action list and precedence of actions(section 6.4), 1413 conflict with other Packet-reception Event-MatchCondition-Action 1414 (ECA) policy (I2RS Filter-Based RIB and Policy-Based Routing 1415 (n-tuple forwarding)) (section 6.5), 1417 pros-cons of this approach (section 6.6) 1419 6.1. Format of New NLRI and Wide Communities 1421 The format of the NLRI TLVs would be replaced with: 1423 +------------------------+ 1424 |length (2 octets) | 1425 +------------------------+ 1426 | sub-TLVs (variable) | 1427 | +====================+ | 1428 | | order (2 octets) | | 1429 | +--------------------+ | 1430 | | type (2 octets) | | 1431 | +--------------------+ | 1432 | | length (2 octets) | | 1433 | +--------------------+ | 1434 | | value (variable) | | 1435 | |[multiples of | | 1436 | | 2 octets] | | 1437 | +====================+ | 1438 +------------------------+ 1440 Figure 16 - NRLI revision 1442 The Actions for BGP Flow Specification will be defined as an BGP Flow 1443 Specification Action atom within BGP Wide communities where the atom 1444 is defined as shown in figure 17. 1446 +--------------------------+ 1447 | order (2 octets) | 1448 +--------------------------+ 1449 | Action type (2 octets) | 1450 +--------------------------+ 1451 | Action length (2 octets) | 1452 +--------------------------+ 1453 | Action Values (variable) | 1454 | (multiples of 2 octets) | 1455 +--------------------------+ 1457 Wide Community Atom 1458 figure 17 1459 The BGP Flow Specification (BGP-FS) atom can be part of the Wide 1460 Community container (type 1) or the BGP Flow Specification Atom can 1461 be part of the BGP Flow Specification container (type 2) which will 1462 have: 1464 +-----------------------------+ 1465 | Source AS Number (4 octets)| 1466 +-----------------------------+ 1467 | list of atoms (variable) | 1468 +-----------------------------+ 1469 figure 18 1471 6.2. security addition of ROA 1473 The security for the ROA is required to be the first action (action 1474 order 1) for all actions. All additional BGP Security precede all 1475 other security additions in the ordering. 1477 6.3. Match Filters and precedence 1479 The precedence of the match filters is determined by the order. If 1480 two orders are the same, the precedence is dependent on the order 1481 specified in the table below. 1483 6.3.1. Precedence in case of ties in order 1485 Table 9: Flow Specification Match Filter Precedence Order 1486 +------+--------------------+-------------+-----------------------+ 1487 |type# | Type Name | Match | Reference | 1488 +======+====================+=============+=======================+ 1489 | 1 | Destination Prefix | IPv4 Prefix | RFC5575 | 1490 | | | IPv6 Prefix | ietf-idr-flow-spec-v6 | 1491 | 2 | Source Prefix | IPv4 Prefix | RFC5575 | 1492 | | | IPv6 Prefix | ietf-idr-flow-spec-v6 | 1493 | 3 | IP protocol |IPv4 Protocol| RFC5575 | 1494 | | | number | | 1495 | 3 | Next Header |IPv6 protocol| ietf-idr-flow-spec-v6 | 1496 | 4 | Port (source or | Port number | RFC5575 | 1497 | | destination port) | | RFC5575 | 1498 | 5 | Source port | Port number | RFC5575 | 1499 | 6 | Destination port | Port number | RFC5575 | 1500 | 7 | ICMP type | ICMP type | RFC5575 | 1501 | 8 | ICMP code | ICMP code | RFC5575 | 1502 | 9 | TCP Flags | 1 or 2 byte | RFC5575 | 1503 | | | bitmask for | RFC5575 | 1504 | | | TCP flags | | 1505 | 10 | Packet length | # of bytes | RFC5575 | 1506 | | (for IP packet) | | | 1507 | 11 | DSCP | IPv4 DSCP | RFC5575 | 1508 | | | (6 bit mask)| RFC5575 | 1509 | 11 | Traffic class | IPv6 traffic| ietf-idr-flow-spec-v6 | 1510 | | | (8 bit mask)| | 1511 | 12 | IPv4 Fragment |4 bit mask | RFC5575 | 1512 | 13 | IPv6 Flow |20 bit flow | ietf-idr-flow-spec-v6 | 1513 | 14 | Delimiter type | 2 bytes | hao-idr-flowspec-nv03 | 1514 | MF-1 | (Encapsulation type| | | 1515 | | VXLAN or NVGRE) | | | 1516 | | | | | 1517 | 15 | VNID | 24 bit VN | hao-idr-flowspec-nv03 | 1518 | MF-2 |(virtual network ID)| | | 1519 | | | | | 1520 | 16 | Flow ID |8 bit flow ID| hoa-idr-flowspec-nv03 | 1521 | MF-3 | (NVGRE Flow ID ) | | | 1522 | | | | | 1523 | 17 | Segment ID | | | 1524 |18-25 | Other packet ids | | | 1525 | | above MPLS | | | 1526 | 29 | MPLS LSP | TBD | not specified | 1527 | MF-4 |(label 20 bits, | Label stack | | 1528 | | EXP (3 bits), S Bit| | | 1529 | | TTL (8 bits) | | | 1530 | | | | | 1531 | | | | | 1532 | 30 | Ethernet type | 2 bytes |ietf-idr-flowspec-l2vpn| 1533 | 31 | Source MAC |MAC address |ietf-idr-flowspec-l2vpn| 1534 | 32 | Destination MAC |MAC Address |ietf-idr-flowspec-l2vpn| 1535 | 33 | DSAP in LLC | 1 octet |ietf-idr-flowspec-l2vpn| 1536 | 34 | SSAP in LLC | 1 octet |ietf-idr-flowspec-l2vpn| 1537 | 35 | Control filed in | 1538 | | LLC| |1 octet |ietf-idr-flowspec-l2vpn| 1539 | 36 | SNAP | 5 octet |ietf-idr-flowspec-l2vpn| 1540 | 37 | VLAN ID |1 or 2 bytes |ietf-idr-flowspec-l2vpn| 1541 | 38 | VLAN COS | 3 bit COS |ietf-idr-flowspec-l2vpn| 1542 | 39 | Inner VLAN ID |1 or 2 bytes |ietf-idr-flowspec-l2vpn| 1543 | 40 | Inner VLAN COS |1 or 2 bytes |ietf-idr-flowspec-l2vpn| 1544 | 41 | Interface | TBD | not specified | 1545 | |(Group ID, intf id) | | | 1546 | 42 |Time | | | 1547 | 65 |FCFS matches | | non-standard actions | 1548 +======+====================+=============+=======================+ 1549 Figure 19 1551 6.3.2. Precedence of filters among Routing Functions 1553 As discussed in the minimum sub-set (Option 1 for BGP-FS), there 1554 needs to be a precedence between n-tuple packet ECA policies. This 1555 precedence is determined by policy rule order and a preference among 1556 policy rules with the same order. Match Condition order is defined 1557 by the BGP-FS Filter order, and within the match the action order is 1558 defined by the BGP-FS. 1560 Precedence among policy rules from difference sources with the same 1561 order is commonly specified by operator-applied policies (which may 1562 be supplied by vendor defaults) where lower priority implies a better 1563 route. For example, a BGP Flow Specification Policy rule can be set 1564 to a priority of 150 where an static ACL policy might be set to a 1565 priority of 40. If the same two n-tuple packet ECA policies exist, 1566 then the lower priority rule within the the same order is selected to 1567 be active. 1569 The operator-applied policy can change these priorities globally or 1570 for a specific route. 1572 If any packet ECA related policy changes, then the BGP Flow 1573 specification must be re-evaluated per policy rule per order and 1574 priority. 1576 6.3.3. Precedence for re-ordering Match Policy 1578 Actions that change interact between levels of policy need to be 1579 defined in terms of policy actions in BGP Flow Specification. For 1580 example [I-D.litkowski-idr-flowspec-interfaceset] provides a 1581 definition of the following combination of filter rules between ACLs 1582 and BGP flow Specifications: 1584 1. Forward if both ACL forward and BGP Flow Specification Forward 1586 2. Drop if either ACL drops or BGP Flow Specification drops. 1588 6.4. Actions and precedence of actions 1590 The actions allowed for BGP are listed in Table 12 provides the 1591 default precedence for actions for the minimal subset. All Standards 1592 actions have precedence overall FCFS actions incoded in BGP Extended 1593 Communities. The default order for these actions are listed below. 1594 All drafts defining actions must deal with the conflicts between 1595 actions and the ordering (see section 4). 1597 Table 10 - Action Precedence and Conflicts between Actions 1598 +-----+------------------------------------------------------+ 1599 |order| Action | 1600 +=====+======================================================+ 1601 | 1 | Alternate NLRI Validation (ROA, and future ROA) (FA7)| 1602 | 2 | Alternate bgpsec validation | 1603 | 5 | Traffic Rate in bytes (0x8006) | 1604 | 6 | Traffic Rate in packets (FA1) | 1605 | 7 | Traffic Action (0x8007) (T or S bit) | 1606 | 8 | Extension to Traffic Actions | 1607 | -10 | | 1608 | 11 | Redirect to IP-VPN (0x8008, 0x8108, 0x8208) | 1609 | | 0x8008: 2 byte AS RD| | 1610 | | 0x8108: 4 byte IP RD| | 1611 | | 0x8208: 4 byte AS RD| | 1612 | 12 | Redirect to IP Tunnel (FA3) | 1613 |13-20} redirect actions (other) | 1614 | 21 | VLAN action (FM4) | 1615 | 22 | TPID action (FM5) | 1616 | 23 | Label Action (FM6) | 1617 | 30 | Interface set (FM8a) | 1618 | 40 | packet-ECA policy interaction | 1619 | | 0 = BGP Flow-Specification (BGP FS) only | 1620 | | 1 = ACL + BGP FS | 1621 | | 2 = I2RS FB-RIB + BGP FS | 1622 | | 3 = ACL + I2RS FB-FIB + BGP FS | 1623 | | 4 = Config FB-RIB + BGP FS | 1624 | | 5 = ACL + config FB-RIB + BGP FS | 1625 | | 6 = Config FB-RIB + I2RS FB-RIB + BGP FS | 1626 | | 7 = ACL + config FB-FIB + I2RS | 1627 | 50 | Time | 1628 |51-64| Reserved for other standards actions | 1629 | | | 1630 |65+ | FCFS actions | 1631 +=====+======================================================+ 1632 Figure 20 1634 6.5. Pro-Con of BGP-FS-v2 (option 2} 1636 Pro - for version 2 1638 The current version 1 of the Flow Specification does not have 1639 ordering of packet ECA policy rules, flow specification filters, or 1640 flow specification actions other than the default precedence. 1641 Current implementations of BGP flow specification are finding this 1642 lack of ordering to cause operational difficulties. 1644 Con - for version 2 1645 Version 2 must be coded. It can either be a BGP attribute with the 1646 policy rules (NLRI filters and actions) inside such as described in 1647 [I-D.li-idr-flowspec-rpd] or it can be a combination of a new BGP 1648 Flow Specification version 2 NLRI + Wide Community actions (with 1649 ordering). 1651 (Additional comments will be added here) 1653 7. Flow Specification Yang models 1655 The Flow Specification Yang models have configuration and operational 1656 state. BGP Flow Specification (BGP-FS) configuration have local 1657 configuration for BGP-FS and locally configured BGP-FS policy rules. 1658 Operational state has three components: 1660 1. Local node's BGP-FS Operational Configuration installed (if 1661 supported) 1663 2. BGP Flow specification rules received from peers, 1665 3. BGP Flow Specfication match statistics 1667 Comparison of the the BGP local configuration for BGP-FS policy rules 1668 with the BGP-FS policy rules, is aided by common yang definitions 1669 between these two functions. Comparison of the BGP-FS Policy rules 1670 (locally configured or received) with I2RS Filter-Based RIB (FB-RIB), 1671 packet-ECA policy, ACL policy rules, and routing table policy rules 1672 requires is aided by common yang definitions between packet-ECA 1673 filtesr. 1675 This section compares BGP Flow Specification yang model in 1676 [I-D.wu-idr-flowspec-yang-cfg] and the I2RS FB-RIB data model is 1677 described in [I-D.hares-i2rs-fb-rib-data-model] which uses the packet 1678 reception ECA policy data model found in 1679 [I-D.hares-i2rs-pkt-eca-data-model]. A comparison of the policy 1680 structures is given in table 8, and the operation status model is 1681 given in table 9. These models are similar. It would be helpful to 1682 use a common yang definitions found in 1683 [I-D.hares-i2rs-pkt-eca-data-model]. 1685 The packet reception ECA policy data model is also used to describe 1686 configured packet reception filter RIBs which (aka Policy Routing) 1687 described in (draft-hares-rtgwg-fb-rib-00.txt). 1689 Table 11 - comparison Yang Model Local Configuraoin 1690 +-------------+----------------------+-----------------------+ 1691 | component | BGP Flow Spec | I2RS FB-RIB + | 1692 | | Yang | Packet-ECA Yang | 1693 +==============+=====================+=======================+ 1694 |Policy |flowspec-policy* |group* [group-name] | 1695 | +-name | [policy-name] | | 1696 | +-vrf |+-rw vrf-name | +-rw vrf-name | 1697 | +-AFI |+-rw address-family | +-rw address-famil | 1698 | +-rules |+-rw flowspec-rule* | +-rw group-rule-list | 1699 | || [rule-name] | | [rule-name] | 1700 | +-rule-name ||+-rw rule-name | |+-rw rule-name | 1701 | +-rule-order||+-rw traffic-filters| |+-rw rule-order | 1702 | ||+-rw traffic-actions| +-rw eca-rules | 1703 | | | | [order-id rule-name]| 1704 | | | | +-rw installer | 1705 | | | | +-rw eca-matches | 1706 | | | | +-rw eca-qos-actions| 1707 | | | | +-rw eca-fwd-actions| 1708 +--------------+---------------------+-----------------------+ 1710 figure 21 - Comparison of Yang modules (Config state) 1712 Note:The Yang "traffic-filters" found are the same as eca-matches 1713 found in [I-D.wu-idr-flowspec-yang-cfg] are the same filters found in 1714 [I-D.hares-i2rs-pkt-eca-data-model]. The "traffic actions" found in 1715 [I-D.wu-idr-flowspec-yang-cfg] can be broken into modify actions and 1716 forwarding actions as [I-D.hares-i2rs-pkt-eca-data-model] does. 1718 Table 12 - comparison of Yang operational state 1719 +------------+----------------------+-------------------------+ 1720 | component | BGP Flow Spec | I2RS FB-RIB | 1721 | | Yang | Packet-ECA Yang | 1722 +============+======================+=========================+ 1723 |opstate |flowspec-state |ietf-fb-ribs-oper-status | 1724 | +-rib |+-ro flowspec-rib |+-ro fb-rib-oper-status* | 1725 | | | | +-ro fb-rib-name | 1726 | +-groups | | | +-ro group-status | 1727 | +-rules | +-ro flowspec-entry*| +-ro rules_opstate | 1728 | [index] | [index] | [rule-order, rule-name]| 1729 | | | | | 1730 |statistics | | | | 1731 | +-rules |+-ro flowspec-stats* | +-ro rules_opstats | 1732 | | | [rule-order, rule-name]| 1733 | | +-ro vrf-name | | 1734 | | +-ro address-family | | 1735 | | +-ro flowspec-rule- | | 1736 | | | stats | | 1737 | | | | | 1738 | | |+-ro traffic-filters| | 1739 | | |+-ro traffic-action | | 1740 | | |+-ro classified-pkts| | +--ro pkts-match | 1741 | | | | | +--ro pkts-modified | 1742 | | |+-ro drop-pkts | | +--ro pkts-dropped | 1743 | | |+-ro drop-bytes | | +--ro bytes-dropped | 1744 | | | | +--ro pkts-forwarded | 1745 | | | | +--ro bytes-forwarded| 1746 +------------+----------------------+-------------------------+ 1748 figure 22 - Comparison of Yang Models (Operation State) 1750 8. IANA Considerations 1752 This section complies with [RFC7153] 1754 TBD. There are a lot of assignments which will be filled in after 1755 the initial review of the technology. 1757 9. Security Considerations 1759 The new BGP Validation described in section 4.1 with the ROA improves 1760 on [RFC5575] security by improving the validation of the originating 1761 AS having permissions to send Flow specifcation for a prefix. The 1762 validation of the path attributes and/or path requires the BGPSEC 1763 [I-D.ietf-sidr-bgpsec-protocol]. [I-D.eddy-idr-flowspec-exp] 1764 contains suggestions on how to implement this with flow 1765 specification, but at this time the authors consider the technology 1766 described in [I-D.eddy-idr-flowspec-exp] so this draft does not 1767 suggest mandating it. However, it encourages the develop of such 1768 work that pairs BGP Flow Specification with BGPSEC protocol. When 1769 this work matures, this specification or BGP Flow Specification 1770 version 2 should implement it. 1772 10. References 1774 10.1. Normative References 1776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1777 Requirement Levels", BCP 14, RFC 2119, 1778 DOI 10.17487/RFC2119, March 1997, 1779 . 1781 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1782 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1783 DOI 10.17487/RFC4271, January 2006, 1784 . 1786 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1787 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1788 February 2006, . 1790 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1791 "Multiprotocol Extensions for BGP-4", RFC 4760, 1792 DOI 10.17487/RFC4760, January 2007, 1793 . 1795 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1796 LAN Service (VPLS) Using BGP for Auto-Discovery and 1797 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1798 . 1800 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1801 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1802 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1803 . 1805 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1806 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1807 DOI 10.17487/RFC5226, May 2008, 1808 . 1810 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1811 and D. McPherson, "Dissemination of Flow Specification 1812 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1813 . 1815 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1816 and A. Bierman, Ed., "Network Configuration Protocol 1817 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1818 . 1820 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 1821 Origin Authorizations (ROAs)", RFC 6482, 1822 DOI 10.17487/RFC6482, February 2012, 1823 . 1825 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 1826 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 1827 March 2014, . 1829 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1830 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 1831 . 1833 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 1834 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 1835 October 2015, . 1837 10.2. Informative References 1839 [I-D.eddy-idr-flowspec-exp] 1840 Eddy, W., Dailey, J., and G. Clark, "Experimental BGP Flow 1841 Specification Extensions", draft-eddy-idr-flowspec-exp-00 1842 (work in progress), August 2015. 1844 [I-D.eddy-idr-flowspec-packet-rate] 1845 Eddy, W., Dailey, J., and G. Clark, "BGP Flow 1846 Specification Packet-Rate Action", draft-eddy-idr- 1847 flowspec-packet-rate-00 (work in progress), November 2015. 1849 [I-D.hao-idr-flowspec-nvo3] 1850 Weiguo, H., Zhuang, S., Li, Z., and R. Gu, "Dissemination 1851 of Flow Specification Rules for NVO3", draft-hao-idr- 1852 flowspec-nvo3-03 (work in progress), December 2015. 1854 [I-D.hao-idr-flowspec-redirect-tunnel] 1855 Weiguo, H., Li, Z., and L. Yong, "BGP Flow-Spec Redirect 1856 to Tunnel action", draft-hao-idr-flowspec-redirect- 1857 tunnel-00 (work in progress), October 2015. 1859 [I-D.hares-i2rs-fb-rib-data-model] 1860 Hares, S., Kini, S., Dunbar, L., Krishnan, R., Bogdanovic, 1861 D., and R. White, "Filter-Based RIB Data Model", draft- 1862 hares-i2rs-fb-rib-data-model-02 (work in progress), 1863 February 2016. 1865 [I-D.hares-i2rs-pkt-eca-data-model] 1866 Hares, S., Wu, Q., and R. White, "Filter-Based Packet 1867 Forwarding ECA Policy", draft-hares-i2rs-pkt-eca-data- 1868 model-02 (work in progress), February 2016. 1870 [I-D.ietf-i2rs-architecture] 1871 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1872 Nadeau, "An Architecture for the Interface to the Routing 1873 System", draft-ietf-i2rs-architecture-13 (work in 1874 progress), February 2016. 1876 [I-D.ietf-i2rs-ephemeral-state] 1877 Haas, J. and S. Hares, "I2RS Ephemeral State 1878 Requirements", draft-ietf-i2rs-ephemeral-state-02 (work in 1879 progress), September 2015. 1881 [I-D.ietf-idr-flow-spec-v6] 1882 Raszuk, R., Pithawala, B., McPherson, D., and A. Andy, 1883 "Dissemination of Flow Specification Rules for IPv6", 1884 draft-ietf-idr-flow-spec-v6-06 (work in progress), 1885 November 2014. 1887 [I-D.ietf-idr-flowspec-l2vpn] 1888 Weiguo, H., Litkowski, S., and S. Zhuang, "Dissemination 1889 of Flow Specification Rules for L2 VPN", draft-ietf-idr- 1890 flowspec-l2vpn-03 (work in progress), November 2015. 1892 [I-D.ietf-idr-wide-bgp-communities] 1893 Raszuk, R., Haas, J., Lange, A., Amante, S., Decraene, B., 1894 Jakma, P., and R. Steenbergen, "Wide BGP Communities 1895 Attribute", draft-ietf-idr-wide-bgp-communities-01 (work 1896 in progress), November 2015. 1898 [I-D.ietf-netconf-restconf] 1899 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1900 Protocol", draft-ietf-netconf-restconf-09 (work in 1901 progress), December 2015. 1903 [I-D.ietf-netmod-acl-model] 1904 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 1905 "Network Access Control List (ACL) YANG Data Model", 1906 draft-ietf-netmod-acl-model-06 (work in progress), 1907 December 2015. 1909 [I-D.ietf-netmod-opstate-reqs] 1910 Watsen, K. and T. Nadeau, "Terminology and Requirements 1911 for Enhanced Handling of Operational State", draft-ietf- 1912 netmod-opstate-reqs-04 (work in progress), January 2016. 1914 [I-D.ietf-netmod-routing-cfg] 1915 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 1916 Management", draft-ietf-netmod-routing-cfg-20 (work in 1917 progress), October 2015. 1919 [I-D.ietf-sidr-bgpsec-protocol] 1920 Lepinski, M., "BGPsec Protocol Specification", draft-ietf- 1921 sidr-bgpsec-protocol-14 (work in progress), December 2015. 1923 [I-D.kini-i2rs-fb-rib-info-model] 1924 Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, 1925 R., Bogdanovic, D., and R. White, "Filter-Based RIB 1926 Information Model", draft-kini-i2rs-fb-rib-info-model-03 1927 (work in progress), February 2016. 1929 [I-D.li-idr-flowspec-rpd] 1930 Li, Z., Ou, L., Luo, Y., Lu, S., Zhuang, S., and N. Wu, 1931 "BGP FlowSpec Extensions for Routing Policy Distribution 1932 (RPD)", draft-li-idr-flowspec-rpd-01 (work in progress), 1933 October 2015. 1935 [I-D.liang-idr-bgp-flowspec-label] 1936 You, J., Raszuk, R., and d. danma@cisco.com, "Carrying 1937 Label Information for BGP FlowSpec", draft-liang-idr-bgp- 1938 flowspec-label-01 (work in progress), September 2015. 1940 [I-D.liang-idr-bgp-flowspec-time] 1941 You, J. and S. Zhuang, "BGP FlowSpec with Time 1942 Constraints", draft-liang-idr-bgp-flowspec-time-00 (work 1943 in progress), October 2015. 1945 [I-D.litkowski-idr-flowspec-interfaceset] 1946 Litkowski, S., Simpson, A., Patel, K., and J. Haas, 1947 "Applying BGP flowspec rules on a specific interface set", 1948 draft-litkowski-idr-flowspec-interfaceset-03 (work in 1949 progress), December 2015. 1951 [I-D.rosen-idr-tunnel-encaps] 1952 Rosen, E., Patel, K., and G. Velde, "Using the BGP Tunnel 1953 Encapsulation Attribute without the BGP Encapsulation 1954 SAFI", draft-rosen-idr-tunnel-encaps-03 (work in 1955 progress), August 2015. 1957 [I-D.vandevelde-idr-flowspec-path-redirect] 1958 Velde, G., Henderickx, W., and K. Patel, "Flowspec 1959 Indirection-id Redirect", draft-vandevelde-idr-flowspec- 1960 path-redirect-01 (work in progress), January 2016. 1962 [I-D.wu-idr-flowspec-yang-cfg] 1963 Wu, N., Zhuang, S., and A. Choudhary, "A YANG Data Model 1964 for Flow Specification", draft-wu-idr-flowspec-yang-cfg-02 1965 (work in progress), October 2015. 1967 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1968 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1969 . 1971 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 1972 "Provisioning, Auto-Discovery, and Signaling in Layer 2 1973 Virtual Private Networks (L2VPNs)", RFC 6074, 1974 DOI 10.17487/RFC6074, January 2011, 1975 . 1977 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 1978 Origination Using the Resource Certificate Public Key 1979 Infrastructure (PKI) and Route Origin Authorizations 1980 (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, 1981 . 1983 Author's Address 1985 Susan Hares 1986 Huawei 1987 7453 Hickory Hill 1988 Saline, MI 48176 1989 USA 1991 Email: shares@ndzh.com