idnits 2.17.00 (12 Aug 2021) /tmp/idnits24228/draft-ietf-idr-flowspec-path-redirect-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 26, 2020) is 718 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) -- Looks like a reference, but probably isn't: 'I-D.draft-ietf-spring-segment-routing' on line 337 -- Looks like a reference, but probably isn't: 'RFC-To-Be' on line 454 == Unused Reference: '2' is defined on line 468, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group G. Van de Velde, Ed. 3 Internet-Draft Nokia 4 Intended status: Standards Track K. Patel 5 Expires: November 27, 2020 Arrcus 6 Z. Li 7 Huawei Technologies 8 May 26, 2020 10 Flowspec Indirection-id Redirect 11 draft-ietf-idr-flowspec-path-redirect-11 13 Abstract 15 This document defines a new extended community known as "FlowSpec 16 Redirect to indirection-id Extended Community". This extended 17 community triggers advanced redirection capabilities to flowspec 18 clients. When activated, this flowspec extended community is used by 19 a flowspec client to retrieve the corresponding next-hop and encoding 20 information within a localised indirection-id mapping table. 22 The functionality detailed in this document allows a network 23 controller to decouple the BGP flowspec redirection instruction from 24 the operation of the available paths. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [1]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 27, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. indirection-id and indirection-id table . . . . . . . . . . . 3 68 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 3 69 3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 3 70 3.2. Redirection to path-engineered tunnels . . . . . . . . . 4 71 3.3. Redirection to complex dynamically constructed tunnels . 5 72 4. Redirect to indirection-id Community . . . . . . . . . . . . 6 73 5. Redirect using localised indirection-id mapping table . . . . 8 74 6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 8 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 11.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 Flowspec is an extension to BGP that allows for the dissemination of 87 traffic flow specification rules. This has many possible 88 applications but the primary one for many network operators is the 89 distribution of traffic filtering actions for DDoS mitigation. The 90 flowspec standard rfc5575bis [3] defines a redirect-to-VRF action for 91 policy-based forwarding, but this mechanism is not always sufficient, 92 particularly if the redirected traffic needs to be steered onto an 93 explicit path. 95 Every flowspec policy route is effectively a rule, consisting of two 96 parts. The first part, encoded in the NLRI field, provides 97 information about the traffic matching the policy rule. the second 98 part, encoded in one or more BGP extended communities, provides 99 policy instructions for traffic handling on the flowspec client. The 100 flowspec standard rfc5575bis [3] defines widely-used filter actions 101 such as discard and rate limit; it also defines a redirect-to-VRF 102 action for policy-based forwarding. Using the redirect-to-VRF action 103 to steer traffic towards an alternate destination is useful for DDoS 104 mitigation, however using this methodology can be cumbersome when 105 there is need to steer the traffic onto an explicitely defined 106 traffic path. 108 This draft specifies a "Redirect to indirection-id" flowspec action 109 making use of a 32-bit indirection-id using a new extended community. 110 Each indirection-id serves as anchor point, for policy-based 111 forwarding onto an explicit path by a flowspec client. 113 2. indirection-id and indirection-id table 115 The indirection-id is a 32-bit unsigned number, used as anchor point 116 on a flowspec client for policy-based forwarding onto an explicit 117 path by a flowspec client. 119 The indirection-id table is the table construct of indirection-id 120 values, grouped by indirection-id "ID-Type". Each entry in this 121 table contains policy-based forwarding and encoding instructions. 123 The configuration of the indirection-id table on a flowspec client is 124 a localised operation on each router, and MAY happen out-of-band from 125 BGP flowspec. For some use-case scenarios the indirection-id "ID- 126 Type" provides additional (maybe even fully sufficient) context for a 127 flowspec client for policy based forwarding, making a localised 128 indirection-id table obsolete. For example, when the indirection-id 129 refers to a MPLS segment routing node-id [6], then the indirection-id 130 provides sufficient information for a segment routing lookup on the 131 flowspec client. 133 3. Use Case Scenarios 135 This section describes a few use-case scenarios when deploying 136 "Redirect to indirection-id". 138 3.1. Redirection shortest Path tunnel 140 Description: 142 The first use-case describes an example where a single flowspec route 143 is sent from a BGP flowspec controller to many BGP flowspec clients. 144 This BGP flowspec route carries the "Redirect to indirection-id" to 145 all flowspec clients with intent to redirect matching dataflows onto 146 a shortest-path tunnel pointing towards a single remote destination. 148 In this first use-case scenario, each flowspec client receives 149 flowspec routes. The received flowspec routes have the extended 150 "Redirect to indirection-id" community attached. Each "Redirect to 151 indirection-id" community embeds two relevant components: (1) 32-bit 152 indirection-id and (2) ID-type. These two components provide the 153 flowspec client with sufficient information for policy based 154 forwarding, with intent to steer and encapsulate the data-packet 155 accordingly upon a shortest path tunnel to a single remote end-point. 157 Requirements: 159 For redirect to shortest path tunnel it is required that the tunnel 160 MUST be operational and allow packets to flow between tunnel head- 161 and tail-end. 163 Example: Indirection-ID community "ID-Type" which can be used: 165 o 0 (localised ID): When the intent is to use a localised 166 Indirection-id table, configured through out-of-band procedures. 168 o 1 or 2 (Node ID's): This type can be used when the goal is to use 169 MPLS based Segment Routing towards a remote destination. In this 170 use-case scenario the flowspec rule contains a SR (Segment 171 Routing) node SID to steer traffic towards. 173 3.2. Redirection to path-engineered tunnels 175 Description: 177 The second use-case describes an example where a single flowspec 178 route is sent from a BGP flowspec controller to many BGP flowspec 179 clients. This BGP flowspec route carries policy information to steer 180 traffic upon a path-engineered tunnel. It is assumed that the path 181 engineered tunnels are configured using out-of-band from BGP 182 flowspec. 184 Segment Routing Example: 186 For this example the indirection-id "ID-Type" points towards a 187 Segment Routing Binding SID. The Binding SID is a segment identifier 188 value (as per segment routing definitions in [I-D.draft-ietf-spring- 189 segment-routing] [6]) used to associate an explicit path. The 190 Binding SID and the associated path engineered tunnel may for example 191 be setup by a controller using BGP as specified in [I-D.sreekantiah- 192 idr-segment-routing-te] [5] or alternately by using PCEP as detailed 193 in draft-ietf-pce-segment-routing [7]. To conclude, when a BGP 194 speaker at some point in time receives a flowspec route with an 195 extended "Redirect to indirection-id' community, it installs a 196 policy-based forwarding rule to redirect packets onto an explicit 197 path, associated with the corresponding Binding SID. The encoding of 198 the Binding SID within the "Redirect to indirection-id" extended 199 community is specified in section 4. 201 Requirements: 203 For redirect to path engineered tunnels it is required that the 204 tunnel MUST be operational and allow packets to flow over the 205 engineered path between tunnel head- and tail-end. 207 Example: Indirection-ID community "ID-Type" to be used: 209 o 0 (localised ID): When the intent is to policy-based steer traffic 210 using Indirection. The engineered path is configured through out- 211 of-band procedures and uses the 32-bit Indirection-id as local 212 anchor point on the local flowspec client. 214 o 3 or 4 (Binding Segment ID's): This type can be used when the goal 215 is to use MPLS based Segment Routing towards an out-of-band 216 configured explicit path. 218 o 5 (Tunnel ID): When the intent is to policy-based steer traffic 219 using a global tunnel-id. The engineered path is configured 220 through out-of-band procedures and uses the 32-bit Indirection-id 221 as global anchor point on the local flowspec client. 223 3.3. Redirection to complex dynamically constructed tunnels 225 Description: 227 A third use-case describes the application and redirection towards 228 complex dynamically constructed tunnels. For this use-case a BGP 229 flowspec controller injects a single flowspec route with two unique 230 "Redirect to indirection-id" communities attached, each community 231 tagged with a different Sequence-ID (S-ID). A flowspec client should 232 use the Sequence-ID (S-ID) to sequence the received flowspec redirect 233 information. A potential use-case scenario would for example be the 234 dynamic construction of Segment Routing Central Egress Path 235 Engineered tunnel [4] or next-next-hop tunnels. 237 Segment Routing Example: 239 i.e. a classic Segment Routing example using complex tunnels is found 240 in DDoS mitigation and traffic offload. Suspicious traffic (e.g. 242 dirty traffic flows) may be policy-based routed into a purpose built 243 Segment Routing Central Egress Path Engineered tunnel [4]. For this 244 complex dynamic redirect tunnel construct, a first "Redirect to 245 indirection-id" (i.e. S-ID=0) may be used to redirect traffic into a 246 tunnel towards a particular egress router, while a second "Redirect 247 to indirection-id" (i.e. S-ID=1) is used to steer traffic beyond the 248 particular egress router towards a pre-identified interface/peer. 249 From data-plane perspective, the principles documented by [4] are 250 valid for this use case scenario. 252 Requirements: 254 To achieve redirection towards complex dynamically constructed 255 tunnels, multiple "Redirect to indirection-id" communities are 256 imposed upon the flowspec route. The "Redirect to indirection-id" 257 communities should be sequenced using the Sequence ID (S-ID). For 258 redirect to complex dynamic engineered tunnels the tunnel MUST be 259 operational and allow packets to flow over the engineered path 260 between tunnel head- and tail-end. 262 Example: Indirection-ID community "ID-Type" to be used: 264 o 0 (localised ID) with S-ID: When the intent is to construct a 265 dynamic engineered tunnel, then a sequence of localised 266 indirection-ids may be used. The Sequence ID (S-ID) MUST be used 267 to sequence multiple "Redirect to indirection-id" actions to 268 construct a more complex engineered tunnel. The creation of the 269 localised indirection-id table is operationalised out-of-band and 270 is outside scope of this document. 272 4. Redirect to indirection-id Community 274 This document defines a new transitive BGP extended community known 275 as "FlowSpec Redirect to indirection-id Extended Community" with the 276 Type and the Sub-Type field to be assigned by IANA. The format of 277 this extended community is show in Figure 1. 279 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type | Sub-Type | Flags(1 octet)| ID-Type | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Generalized indirection_id | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 1 288 The meaning of the extended community fields are as follows: 290 Type: 1 octet to be assigned by IANA. 292 Sub-Type: 1 octet to be assigned by IANA. 294 Flags: 1 octet field. Following Flags are defined. 296 0 1 297 0 1 2 3 4 5 6 7 298 +-+-+-+-+-+-+-+-+ 299 | RES | S-ID |C| 300 +-+-+-+-+-+-+-+-+ 302 Figure 2 304 The least-significant Flag bit is defined as the 'C' (or copy) bit. 305 When the 'C' bit is set the redirection applies to copies of the 306 matching packets and not to the original traffic stream. 308 The 'S-ID' field identifies a 4 bit Sequence ID field. This field is 309 used to provide a flowspec client an indication how and where to 310 sequence the received indirection-ids. The Sequence ID value 0 311 indicates that Sequence ID field is NOT set and all other sequence 312 ID's SHOULD be ignored. A single flowspec rule MUST NOT have more as 313 one indirection-id per S-ID. On a flowspec client the indirection-id 314 with lowest S-ID MUST be imposed first for any given flowspec entry. 316 All bits other than the 'C' and 'S-ID' bits MUST be set to 0 by the 317 originating BGP speaker and ignored by receiving BGP speakers. 319 ID-Type: 1 octet value. This draft defines following Context Types: 321 0 - Localised ID (The flowspec client uses the received 32-bit 322 indirection-id to lookup forwarding information within the 323 localised indirection-id table. The allocation and programming of 324 the localised indirection-id table is outside scope of the 325 document) 327 1 - Node ID with SID/index in MPLS-based Segment Routing (This 328 means the 32-bit indirection-id is mapped to an MPLS label using 329 the index as a global offset in the SID/label space) 330 2 - Node ID with SID/label in MPLS-based Segment Routing (This 331 means the 32-bit indirection-id is mapped to an MPLS label using 332 the 32-bit indirection-id as global label) 334 3 - Binding Segment ID with SID/index in MPLS-based Segment 335 Routing (This means the 32-bit indirection-id is mapped to an MPLS 336 binding label using the indirection-id as index for global offset 337 in the SID/label space) [I-D.draft-ietf-spring-segment-routing] 338 [6] 340 4 - Binding Segment ID with SID/label in MPLS-based Segment 341 Routing (This means 32-bit indirection-id is mapped to an MPLS 342 binding label using the 32-bit indirection-id as global label) [I- 343 D.draft-ietf-spring-segment-routing] [6] 345 5 - Tunnel ID (Tunnel ID is within a single administrative domain 346 a 32-bit globally unique tunnel identifier. The allocation and 347 programming of the Tunnel ID within the localised indirection-id 348 table is outside scope of the document) 350 Generalized indirection_id: 32-bit identifier used as indirection_id 352 5. Redirect using localised indirection-id mapping table 354 When a BGP flowspec client receives a flowspec policy route with a 355 "Redirect to indirection-id" extended community attached, and the 356 route represents the best BGP path, it will install a flowspec 357 policy-based forwarding rule matching the tupples described by the 358 flowpsec NLRI field and consequently redirects the flow (C=0) or 359 copies the flow (C=1) using the information identified by the 360 "Redirect to indirection-id" community. 362 6. Validation Procedures 364 The validation check described in rfc5575bis [3] SHOULD be applied by 365 default by a flowspec client, for received flowspec policy routes 366 containing a "Redirect to indirection-id" extended community. This 367 results that a flowspec route with a destination prefix subcomponent 368 SHOULD NOT be accepted from an EBGP peer unless that peer also 369 advertised the best path for the matching unicast route. 371 While it MUST NOT happen, and is seen as invalid combination, it is 372 possible from a semantics perspective to have multiple clashing 373 redirect actions defined within a single flowspec rule. For best and 374 consistant compatibility with legacy implementations, the redirect 375 functionality as documented by rfc5575bis MUST NOT be broken, and 376 hence when a clash occurs, then rfc5575bis based redirect MUST take 377 priority. Additionally, if the "Redirect to indirection-id" does not 378 result in a valid redirection, then the flowspec rule MUST be 379 processed as if the "Redirect to indirection-id" community was not 380 attached to the flowspec route. In addition the flowspec client MUST 381 provide an indication that the respective "'Redirect to indirection- 382 id" resulted in an invalid redirection action. 384 7. Security Considerations 386 A system using "Redirect to indirection-id" extended community can 387 cause during the redirect mitigation of a DDoS attack overflow of 388 traffic received by the mitigation infrastructure. 390 8. Acknowledgements 392 This document received valuable comments and input from IDR working 393 group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert 394 Raszuk, Jeff Haas, Susan Hares and Lucy Yong. 396 9. Contributors 398 The following people contributed to the content of this document and 399 should be considered as co-authors: 401 Arjun Sreekantiah 402 USA 404 Email: arjunhrs@gmail.com 406 Nan Wu 407 Huawei Technologies 408 Huawei Bld., No. 156 Beiquing Rd 409 Beijing 100095 410 China 412 Email: eric.wu@huawei.com 414 Shunwan Zhuang 415 Huawei Technologies 416 Huawei Bld., No. 156 Beiquing Rd 417 Beijing 100095 418 China 420 Email: zhuangshunwan@huawei.com 422 Wim Henderickx 423 Nokia 424 Antwerp 425 BE 427 Email: wim.henderickx@nokia.com 429 Figure 3 431 10. IANA Considerations 433 This document requests a new Transitive Extended Community Type and a 434 new registery sub-type. The new Transitive Extended Community Type 435 name shall be "FlowSpec Redirect to indirection-id Extended Community 436 (Sub-Types are defined in the "FlowSpec Redirect to indirection-id 437 Extended Community Sub-Type" registery)". The name of the new Sub- 438 type registery shall be "FlowSpec Redirect to indirection-id Extended 439 Community Sub-Type" 441 Under "Transitive Extended Community:" 443 Registry: "FlowSpec Redirect to indirection-id Extended Community 444 (Sub-Types are defined in the "FlowSpec Redirect to indirection-id 445 Extended Community Sub-Type" registery)" 446 Registration Procedure(s): First Come, First Served 448 0x09 FlowSpec Redirect to indirection-id Extended Community 450 New Sub-Type Registry: "FlowSpec Redirect to indirection-id Extended 451 Community Sub-Type" 453 Value Code Reference 454 0x00 Flowspec Redirect to 32-bit Path-id [RFC-To-Be] 456 Figure 4 458 11. References 460 11.1. Normative References 462 [1] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, March 1997, 464 . 466 11.2. Informative References 468 [2] Uttaro, J., Filsfils, C., Alcaide, J., and P. Mohapatra, 469 "Revised Validation Procedure for BGP Flow 470 Specifications", January 2014. 472 [3] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 473 Bacher, "Dissemination of Flow Specification Rules", June 474 2019. 476 [4] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. 477 Afanasiev, "Segment Routing Centralized Egress Peer 478 Engineering", October 2015. 480 [5] Sreekantiah, A., Filsfils, C., Previdi, S., Sivabalan, S., 481 Mattes, P., and S. Lin, "Segment Routing Traffic 482 Engineering Policy using BGP", October 2015. 484 [6] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 485 Shakir, R., Bashandy, A., Horneffer, M., Henderickx, W., 486 Tantsura, J., Crabbe, E., Milojevic, I., and S. Ytti, 487 "Segment Routing Architecture", December 2015. 489 [7] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S., 490 Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J., 491 Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti, 492 "PCEP Extensions for Segment Routing", December 2015. 494 Authors' Addresses 496 Gunter Van de Velde (editor) 497 Nokia 498 Antwerp 499 BE 501 Email: gunter.van_de_velde@nokia.com 503 Keyur Patel 504 Arrcus 505 USA 507 Email: keyur@arrcus.com 509 Zhenbin Li 510 Huawei Technologies 511 Huawei Bld., No. 156 Beiquing Rd 512 Beijing 100095 513 China 515 Email: lizhenbin@huawei.com