idnits 2.17.1 draft-ietf-idr-flowspec-path-redirect-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 13, 2018) is 1933 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 458 ** Obsolete normative reference: RFC 5575 (ref. '2') (Obsoleted by RFC 8955) Summary: 1 error (**), 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: June 16, 2019 Arrcus 6 Z. Li 7 Huawei Technologies 8 December 13, 2018 10 Flowspec Indirection-id Redirect 11 draft-ietf-idr-flowspec-path-redirect-07 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 June 16, 2019. 49 Copyright Notice 51 Copyright (c) 2018 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 RFC5575 [2] 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 RFC5575 [2] defines widely-used filter actions such 101 as discard and rate limit; it also defines a redirect-to-VRF action 102 for policy-based forwarding. Using the redirect-to-VRF action to 103 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 RFC5575 [2] and revised in [3] 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 RFC5575 MUST NOT be broken, and hence 377 when a clash occurs, then RFC5575 based redirect MUST take priority. 379 Additionally, if the "Redirect to indirection-id" does not result in 380 a valid redirection, then the flowspec rule MUST be processed as if 381 the "Redirect to indirection-id" community was not attached to the 382 flowspec route. In addition the flowspec client MUST provide an 383 indication that the respective "'Redirect to indirection-id" resulted 384 in an invalid redirection action. 386 7. Security Considerations 388 A system using "Redirect to indirection-id" extended community can 389 cause during the redirect mitigation of a DDoS attack overflow of 390 traffic received by the mitigation infrastructure. 392 8. Acknowledgements 394 This document received valuable comments and input from IDR working 395 group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert 396 Raszuk, Jeff Haas, Susan Hares and Lucy Yong. 398 9. Contributor Addresses 400 Below is a list of other contributing authors in alphabetical order: 402 Arjun Sreekantiah 403 Cisco Systems 404 170 W. Tasman Drive 405 San Jose, CA 95134 406 USA 408 Email: asreekan@cisco.com 410 Nan Wu 411 Huawei Technologies 412 Huawei Bld., No. 156 Beiquing Rd 413 Beijing 100095 414 China 416 Email: eric.wu@huawei.com 418 Shunwan Zhuang 419 Huawei Technologies 420 Huawei Bld., No. 156 Beiquing Rd 421 Beijing 100095 422 China 424 Email: zhuangshunwan@huawei.com 426 Wim Henderickx 427 Nokia 428 Antwerp 429 BE 431 Email: wim.henderickx@nokia.com 433 Figure 3 435 10. IANA Considerations 437 This document requests a new Transitive Extended Community Type and a 438 new registery sub-type. The new Transitive Extended Community Type 439 name shall be "FlowSpec Redirect to indirection-id Extended Community 440 (Sub-Types are defined in the "FlowSpec Redirect to indirection-id 441 Extended Community Sub-Type" registery)". The name of the new Sub- 442 type registery shall be "FlowSpec Redirect to indirection-id Extended 443 Community Sub-Type" 445 Under "Transitive Extended Community:" 446 Registry: "FlowSpec Redirect to indirection-id Extended Community 447 (Sub-Types are defined in the "FlowSpec Redirect to indirection-id 448 Extended Community Sub-Type" registery)" 450 Registration Procedure(s): First Come, First Served 452 0x09 FlowSpec Redirect to indirection-id Extended Community 454 New Sub-Type Registry: "FlowSpec Redirect to indirection-id Extended 455 Community Sub-Type" 457 Value Code Reference 458 0x00 Flowspec Redirect to 32-bit Path-id [RFC-To-Be] 460 Figure 4 462 11. References 464 11.1. Normative References 466 [1] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, March 1997, 468 . 470 [2] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 471 and D. McPherson, "Dissemination of Flow Specification 472 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 473 . 475 11.2. Informative References 477 [3] Uttaro, J., Filsfils, C., Alcaide, J., and P. Mohapatra, 478 "Revised Validation Procedure for BGP Flow 479 Specifications", January 2014. 481 [4] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. 482 Afanasiev, "Segment Routing Centralized Egress Peer 483 Engineering", October 2015. 485 [5] Sreekantiah, A., Filsfils, C., Previdi, S., Sivabalan, S., 486 Mattes, P., and S. Lin, "Segment Routing Traffic 487 Engineering Policy using BGP", October 2015. 489 [6] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 490 Shakir, R., Bashandy, A., Horneffer, M., Henderickx, W., 491 Tantsura, J., Crabbe, E., Milojevic, I., and S. Ytti, 492 "Segment Routing Architecture", December 2015. 494 [7] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S., 495 Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J., 496 Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti, 497 "PCEP Extensions for Segment Routing", December 2015. 499 Authors' Addresses 501 Gunter Van de Velde (editor) 502 Nokia 503 Antwerp 504 BE 506 Email: gunter.van_de_velde@nokia.com 508 Keyur Patel 509 Arrcus 510 USA 512 Email: keyur@arrcus.com 514 Zhenbin Li 515 Huawei Technologies 516 Huawei Bld., No. 156 Beiquing Rd 517 Beijing 100095 518 China 520 Email: lizhenbin@huawei.com