idnits 2.17.1 draft-ietf-idr-flowspec-path-redirect-03.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 20, 2017) is 2313 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 343 -- 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 23, 2018 Arrcus 6 Z. Li 7 Huawei Technologies 8 December 20, 2017 10 Flowspec Indirection-id Redirect 11 draft-ietf-idr-flowspec-path-redirect-03 13 Abstract 15 This document defines a new extended community known as flowspec 16 redirect-to-indirection-id. This extended community triggers 17 advanced redirection capabilities to flowspec clients. When 18 activated, this flowspec extended community is used by a flowspec 19 client to find the corresponding next-hop information within a 20 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 selected redirection path itself. 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 23, 2018. 49 Copyright Notice 51 Copyright (c) 2017 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 flow-spec 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 explicite 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 explicite 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 explicite 117 path by a flowspec client. 119 The indirection-id table is the table construct of indirection-id 120 values, ordered by indirection-id type. Each entry in this table 121 contains policy-based forwarding instructions. 123 The configuration of the indirection-id table on a flowspec client is 124 localised on each router and MAY happen out-of-band from BGP 125 flowspec. For some use-case scenarios the indirection-id type 126 provides additional (maybe even fully sufficient) context for a 127 flowspec client for policy based forwarding, making a localized 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 all 145 flowspec clients to redirect matching dataflows onto a shortest-path 146 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) indirection-id type. These two components 153 provide the flowspec client with sufficient information for policy 154 based forwarding to steer and encapsulate the data-packet accordingly 155 to a shortest path tunnel to a 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 be steered over the shortest 161 path between tunnel head- and tail-end. 163 Example: Indirection-ID community types to 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 type points towards a Segment 187 Routing Binding SID. The Binding SID is a segment identifier value 188 (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 corresponding 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 alternatly 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 flow-spec 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 be steered over the 205 engineered path between tunnel head- and tail-end. 207 Example: Indirection-ID community types 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 2 or 3 (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 explicite 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 may 232 use the Sequence-ID (S-ID) to sequence the flowspec redirect 233 information. A common 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 construction, 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, various indirection-id communities are imposed upon the 256 flowspec route and are sequenced using the Sequence ID (S-ID). For 257 redirect to complex dynamic engineered tunnels it is required that 258 the tunnel MUST be operational and allow packets to be steered over 259 the engineered path between tunnel head- and tail-end. 261 Example: Indirection-ID community types to be used: 263 o 0 (localised ID) with S-ID: When the intent is to construct a 264 dynamic engineered tunnel, then a sequence of localised 265 indirection-ids may be used. The Sequence ID (S-ID) MUST be used 266 to sequence multiple redirect-to-indirection-id actions to 267 construct a more complex path engineered tunnel. The construction 268 of the localised indirection-id table is done out-of-band and is 269 outside scope of this document. 271 4. redirect-to-indirection-id Community 273 This document defines a new BGP extended community known as a 274 Redirect-to-indirection-id extended community. This extended 275 community is a new transitive extended community with the Type and 276 the Sub-Type field to be assigned by IANA. The format of this 277 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)| Indirection ID| 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 Indirection ID: 1 octet value. This draft defines following 320 indirection-id Types: 322 0 - Localised ID (The flowspec client uses the received 323 indirection-id to lookup forwarding information within the 324 localised indirection-id table. The allocation and programming of 325 the localised indirection-id table is outside scope of the 326 document) 328 1 - Node ID with SID/index in MPLS-based Segment Routing (This 329 means indirection-id is mapped to an MPLS label using the index as 330 a global offset in the SID/label space) 331 2 - Node ID with SID/label in MPLS-based Segment Routing (This 332 means indirection-id is mapped to an MPLS label using the label as 333 global label) 335 3 - Binding Segment ID with SID/index in MPLS-based Segment 336 Routing (This means indirection-id is mapped to an MPLS binding 337 label using the index as a global offset in the SID/label space) 338 [I-D.draft-ietf-spring-segment-routing] [6] 340 4 - Binding Segment ID with SID/label in MPLS-based Segment 341 Routing (This means indirection-id is mapped to an MPLS binding 342 label using the index as a global offset in the SID/label space) 343 [I-D.draft-ietf-spring-segment-routing] [6] 345 5 - Tunnel ID (Tunnel ID is a global value in a network single 346 administrative domain identifying tunnel information. The 347 allocation of the Tunnel ID is out of the scope of the document.) 349 5. Redirect using localised indirection-id mapping table 351 When a BGP flowspec client receives a flowspec policy route with a 352 redirect-to-indirection-id extended community attached and the route 353 represents the best BGP path, it will install a flowspec policy-based 354 forwarding rule matching the tupples described by the flowpsec NLRI 355 field and consequently redirects the flow (C=0) or copies the flow 356 (C=1) using the information identified by the 'redirect-to- 357 indirection-id' community. 359 6. Validation Procedures 361 The validation check described in RFC5575 [2] and revised in [3] 362 SHOULD be applied by default by a flowspec client, for received 363 flowspec policy routes containing a 'redirect-to-indirection-id' 364 extended community. This means that a flow-spec route with a 365 destination prefix subcomponent SHOULD NOT be accepted from an EBGP 366 peer unless that peer also advertised the best path for the matching 367 unicast route. 369 While it MUST NOT happen, and is seen as invalid combination, it is 370 possible from a semantics perspective to have multiple clashing 371 redirect actions defined within a single flowspec rule. For best and 372 consistant with legacy implementations, the redirect functionality as 373 documented by RFC5575 MUST NOT be broken, and hence when a clash 374 occurs, then RFC5575 based redirect MUST take priority. 375 Additionally, if the 'redirect-to-indirection-id' does not result in 376 a valid redirection, then the flowspec rule MUST be processed as if 377 the 'redirect-to-indirection-id' community was not attached to the 378 flowspec route and MUST provide an indication within the BGP routing 379 table that the respective 'redirect-to-indirection-id' resulted in an 380 invalid redirection action. 382 7. Security Considerations 384 A system using 'redirect-to-indirection-id' extended community can 385 cause during the redirect mitigation of a DDoS attack result in 386 overflow of traffic received by the mitigation infrastructure. 388 8. Acknowledgements 390 This document received valuable comments and input from IDR working 391 group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert 392 Raszuk, Jeff Haas, Susan Hares and Lucy Yong. 394 9. Contributor Addresses 396 Below is a list of other contributing authors in alphabetical order: 398 Arjun Sreekantiah 399 Cisco Systems 400 170 W. Tasman Drive 401 San Jose, CA 95134 402 USA 404 Email: asreekan@cisco.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 type and sub-type for the redirect-to- 434 indirection-id Extended community from the "Transitive Extended 435 community" registry. The Type name shall be "Redirect-to- 436 indirection-id Extended Community" and the Sub-type name shall be 437 'Flow-spec Redirect to 32-bit Path-id'. 439 In addition, this document requests IANA to create a new registry for 440 redirect-to-indirection-id Extended Community INDIRECTION-IDs as 441 follows: 443 Under "Transitive Extended Community:" 445 Registry: "Redirect Extended Community indirection_id" 447 Reference: [RFC-To-Be] 449 Registration Procedure(s): First Come, First Served 451 Registry: "Redirect Extended Community indirection_id" 453 Value Code Reference 455 0 Localised ID [RFC-To-Be] 456 1 Node ID [RFC-To-Be] 457 2 Binding ID [RFC-To-Be] 458 3 Tunnel 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