idnits 2.17.1 draft-ietf-idr-flowspec-path-redirect-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 19, 2019) is 1712 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 457 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: February 20, 2020 Arrcus 6 Z. Li 7 Huawei Technologies 8 August 19, 2019 10 Flowspec Indirection-id Redirect 11 draft-ietf-idr-flowspec-path-redirect-09 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 February 20, 2020. 49 Copyright Notice 51 Copyright (c) 2019 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. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 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 SHOULD be ignored. A 312 single flowspec rule MUST NOT have more as one indirection-id per 313 S-ID. On a flowspec client the indirection-id with lowest S-ID MUST 314 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] and revised in [2] 365 SHOULD be applied by default by a flowspec client, for received 366 flowspec policy routes containing a "Redirect to indirection-id" 367 extended community. This results that a flowspec route with a 368 destination prefix subcomponent SHOULD NOT be accepted from an EBGP 369 peer unless that peer also advertised the best path for the matching 370 unicast route. 372 While it MUST NOT happen, and is seen as invalid combination, it is 373 possible from a semantics perspective to have multiple clashing 374 redirect actions defined within a single flowspec rule. For best and 375 consistant compatibility with legacy implementations, the redirect 376 functionality as documented by rfc5575bis MUST NOT be broken, and 377 hence when a clash occurs, then rfc5575bis based redirect MUST take 378 priority. Additionally, if the "Redirect to indirection-id" does not 379 result in a valid redirection, then the flowspec rule MUST be 380 processed as if the "Redirect to indirection-id" community was not 381 attached to the flowspec route. In addition the flowspec client MUST 382 provide an indication that the respective "'Redirect to indirection- 383 id" resulted in an invalid redirection action. 385 7. Security Considerations 387 A system using "Redirect to indirection-id" extended community can 388 cause during the redirect mitigation of a DDoS attack overflow of 389 traffic received by the mitigation infrastructure. 391 8. Acknowledgements 393 This document received valuable comments and input from IDR working 394 group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert 395 Raszuk, Jeff Haas, Susan Hares and Lucy Yong. 397 9. Contributor Addresses 399 Below is a list of other contributing authors in alphabetical order: 401 Arjun Sreekantiah 402 Cisco Systems 403 170 W. Tasman Drive 404 San Jose, CA 95134 405 USA 407 Email: asreekan@cisco.com 409 Nan Wu 410 Huawei Technologies 411 Huawei Bld., No. 156 Beiquing Rd 412 Beijing 100095 413 China 415 Email: eric.wu@huawei.com 417 Shunwan Zhuang 418 Huawei Technologies 419 Huawei Bld., No. 156 Beiquing Rd 420 Beijing 100095 421 China 423 Email: zhuangshunwan@huawei.com 425 Wim Henderickx 426 Nokia 427 Antwerp 428 BE 430 Email: wim.henderickx@nokia.com 432 Figure 3 434 10. IANA Considerations 436 This document requests a new Transitive Extended Community Type and a 437 new registery sub-type. The new Transitive Extended Community Type 438 name shall be "FlowSpec Redirect to indirection-id Extended Community 439 (Sub-Types are defined in the "FlowSpec Redirect to indirection-id 440 Extended Community Sub-Type" registery)". The name of the new Sub- 441 type registery shall be "FlowSpec Redirect to indirection-id Extended 442 Community Sub-Type" 444 Under "Transitive Extended Community:" 445 Registry: "FlowSpec Redirect to indirection-id Extended Community 446 (Sub-Types are defined in the "FlowSpec Redirect to indirection-id 447 Extended Community Sub-Type" registery)" 449 Registration Procedure(s): First Come, First Served 451 0x09 FlowSpec Redirect to indirection-id Extended Community 453 New Sub-Type Registry: "FlowSpec Redirect to indirection-id Extended 454 Community Sub-Type" 456 Value Code Reference 457 0x00 Flowspec Redirect to 32-bit Path-id [RFC-To-Be] 459 Figure 4 461 11. References 463 11.1. Normative References 465 [1] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, March 1997, 467 . 469 11.2. Informative References 471 [2] Uttaro, J., Filsfils, C., Alcaide, J., and P. Mohapatra, 472 "Revised Validation Procedure for BGP Flow 473 Specifications", January 2014. 475 [3] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 476 Bacher, "Dissemination of Flow Specification Rules", June 477 2019. 479 [4] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. 480 Afanasiev, "Segment Routing Centralized Egress Peer 481 Engineering", October 2015. 483 [5] Sreekantiah, A., Filsfils, C., Previdi, S., Sivabalan, S., 484 Mattes, P., and S. Lin, "Segment Routing Traffic 485 Engineering Policy using BGP", October 2015. 487 [6] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 488 Shakir, R., Bashandy, A., Horneffer, M., Henderickx, W., 489 Tantsura, J., Crabbe, E., Milojevic, I., and S. Ytti, 490 "Segment Routing Architecture", December 2015. 492 [7] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S., 493 Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J., 494 Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti, 495 "PCEP Extensions for Segment Routing", December 2015. 497 Authors' Addresses 499 Gunter Van de Velde (editor) 500 Nokia 501 Antwerp 502 BE 504 Email: gunter.van_de_velde@nokia.com 506 Keyur Patel 507 Arrcus 508 USA 510 Email: keyur@arrcus.com 512 Zhenbin Li 513 Huawei Technologies 514 Huawei Bld., No. 156 Beiquing Rd 515 Beijing 100095 516 China 518 Email: lizhenbin@huawei.com