idnits 2.17.1 draft-vandevelde-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2848 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 212 -- Looks like a reference, but probably isn't: 'I-D.sreekantiah-idr-segment-routing-te' on line 214 -- Looks like a reference, but probably isn't: 'RFC-To-Be' on line 409 ** Obsolete normative reference: RFC 5575 (ref. '2') (Obsoleted by RFC 8955) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 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 W. Henderickx 4 Intended status: Standards Track Nokia 5 Expires: January 9, 2017 K. Patel 6 A. Sreekantiah 7 Cisco Systems 8 Z. Li 9 S. Zhuang 10 N. Wu 11 Huawei Technologies 12 July 8, 2016 14 Flowspec Indirection-id Redirect 15 draft-vandevelde-idr-flowspec-path-redirect-03 17 Abstract 19 Flowspec is an extension to BGP that allows for the dissemination of 20 traffic flow specification rules. This has many possible 21 applications but the primary one for many network operators is the 22 distribution of traffic filtering actions for DDoS mitigation. The 23 flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for 24 policy-based forwarding but this mechanism is not always sufficient, 25 particularly if the redirected traffic needs to be steered into an 26 engineered path or into a service plane. 28 This document defines a new extended community known as redirect-to- 29 indirection-id (32-bit) flowspec action to provide advanced 30 redirection capabilities on flowspec clients. When activated, the 31 flowspec extended community is used by a flowspec client to find the 32 correct next-hop entry within a localised indirection-id mapping 33 table. 35 The functionality present in this draft allows a network controller 36 to decouple flowspec functionality from the creation and maintainance 37 of the network's service plane itself including the setup of tunnels 38 and other service constructs that could be managed by other network 39 devices. 41 Requirements Language 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119 [1]. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on January 9, 2017. 64 Copyright Notice 66 Copyright (c) 2016 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 82 2. indirection-id and indirection-id table . . . . . . . . . . . 3 83 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4 84 3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 4 85 3.2. Redirection to path-engineered tunnels . . . . . . . . . 4 86 3.3. Redirection to Next-next-hop tunnels . . . . . . . . . . 5 87 4. Redirect to indirection-id Community . . . . . . . . . . . . 6 88 5. Redirect using localised indirection-id mapping table . . . . 8 89 6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 8 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 95 10.2. Informative References . . . . . . . . . . . . . . . . . 10 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 98 1. Introduction 100 Flowspec RFC5575 [2] is an extension to BGP that allows for the 101 dissemination of traffic flow specification rules. This has many 102 possible applications, however the primary one for many network 103 operators is the distribution of traffic filtering actions for DDoS 104 mitigation. 106 Every flowspec policy route is effectively a rule, consisting of a 107 matching part (encoded in the NLRI field) and an action part (encoded 108 in one or more BGP extended communities). The flow-spec standard 109 RFC5575 [2] defines widely-used filter actions such as discard and 110 rate limit; it also defines a redirect-to-VRF action for policy-based 111 forwarding. Using the redirect-to-VRF action to steer traffic 112 towards an alternate destination is useful for DDoS mitigation but 113 using this technology can be cumbersome when there is need to steer 114 the traffic onto an engineered traffic path. 116 This draft proposes a new redirect-to-indirection-id flowspec action 117 facilitating an anchor point for policy-based forwarding onto an 118 engineered path or into a service plane. The flowspec client 119 consuming and utilizing the new flowspec indirection-id extended- 120 community finds the redirection information within a localised 121 indirection-id mapping table. The localised mapping table is a table 122 construct providing at one side the table key and at the other side 123 next-hop information. The table key consists out the combination of 124 indirection-id type and indirection-id 32-bit value. 126 The redirect-to-indirection-id flowspec action is encoded in a newly 127 defined BGP extended community. In addition, the type of redirection 128 can be configured as an extended community indirection-id type field. 130 This draft defines the indirection-id extended-community and the 131 wellknown indirection-id types. The specific solution to construct 132 the localised indirection-id mapping table are out-of-scope of this 133 document. 135 2. indirection-id and indirection-id table 137 An indirection-id is an abstract number (32-bit value) used as 138 identifier for a localised indirection decision. The indirection-id 139 will allow a flowspec client to redirect traffic into a service plane 140 or onto an engineered traffic path. e.g. When a BGP flowspec 141 controller signals a flowspec client the indirection-id extended 142 community, then the flowspec client uses the indirection-id to make a 143 recursive lookup to retrieve next-hop information found in a 144 localised indirection mapping table. 146 The indirection-id table is a router localised table. The 147 indirection-id table is constructed out of table keys mapped to 148 flowspec client localised redirection information. The table key is 149 created by the combination of the indirection-id type and the 150 indirection-id 32-bit value. Each entry in the indirection-table key 151 maps to sufficient information (parameters regarding encapsulation, 152 interface, QoS, etc...) to successfully redirect traffic. 154 3. Use Case Scenarios 156 This section describes use-case scenarios when deploying redirect-to- 157 indirection-id. 159 3.1. Redirection shortest Path tunnel 161 A first use-case is allowing a BGP Flowspec controller to send a 162 single flowspec policy route (i.e. flowspec_route#1) to many BGP 163 flowspec clients. This flowspec route signals the Flowspec clients 164 to redirect traffic onto a tunnel towards a single IP destination 165 address. 167 For this first use-case scenario, the flowspec client receives from 168 the flowspec controller a flowspec route (i.e. flowspec_route#1) 169 including the redirect-to-indirection-id extended community. The 170 redirect-to-indirection-id extended community contains the key 171 (indirection-id type + indirection-id 32-bit value) to select the 172 corresponding next-hop information from the flowpsec client localised 173 indirection-id table. The resulting next-hop information for this 174 use-case is a remote tunnel end-point IP address with accordingly 175 sufficient tunnel encapsulation information to forward the packet 176 accordingly. 178 For redirect to shortest path tunnel it is required that the tunnel 179 MUST be operational and allow packets to be exchanged between tunnel 180 head- and tail-end. 182 3.2. Redirection to path-engineered tunnels 184 For a second use-case, it is expected that the flowspec client 185 redirect traffic matches the flowspec rule, onto a path engineered 186 tunnel. The path engineered tunnel on the flowspec client SHOULD be 187 created by out-of-band mechanisms. Each path engineered tunnel 188 deployed for flowspec redirection, has a unque key as an identifier. 189 consequently, the key (=indirection-id type and indirection-id 32-bit 190 value) uniquely identifies a single path engineered tunnel on the 191 flowspec client. The localised indirection-id mapping table is the 192 collection of all keys corresponding all path engineered tunnels on 193 the flowspec client. 195 For this second use-case scenario, the flowspec controller sends a 196 flowspec route (i.e. flowspec_route#2) to the flowspec clients. The 197 flowspec clients, respectively receive the flowspec route. The 198 redirect-to-indirection-id extended community contains the key 199 (indirection type + indirection-id 32-bit value) to select the 200 corresponding next-hop information from the flowpsec client localised 201 indirection-id table. The resulting next-hop information for this 202 use-case is path engineered tunnel information and has sufficient 203 tunnel encapsulation information to forward the packet according the 204 expectations of the flowspec controller. 206 A concrete example of this use-case can be found in segment routed 207 networks where path engineered tunnels can be setup by means of a 208 controller signaling explicit paths to peering routers. In such a 209 case, the indirection-id references to a Segment Routing Binding SID, 210 while the indirection-id type references the Bindging SID semantic. 211 The Binding SID is a segment identifier value (as per segment routing 212 definitions in [I-D.draft-ietf-spring-segment-routing] [6]) used to 213 associate with an explicit path and can be setup by a controller 214 using BGP as specified in [I-D.sreekantiah-idr-segment-routing-te] 215 [5] or using PCE as detailed in draft-ietf-pce-segment-routing [7]. 216 When a BGP speaker receives a flow-spec route with a 'redirect to 217 Binding SID' extended community, it installs a traffic filtering rule 218 that matches the packets described by the NLRI field and redirects 219 them to the explicit path associated with the Binding SID. The 220 explicit path is specified as a set/stack of segment identifiers as 221 detailed in the previous documents. The stack of segment identifiers 222 is now imposed on packets matching the flow-spec rule to perform 223 redirection as per the explicit path setup prior. The encoding of 224 the Binding SID value is specified in section 4, with the 225 indirection-id field now encoding the associated value for the 226 binding SID. 228 3.3. Redirection to Next-next-hop tunnels 230 A Third use-case is when a BGP Flowspec controller sends a single 231 flowspec policy route to flowpsec clients to signal redirection 232 towards next-next-hop tunnels. In this use-case The flowspec rule is 233 instructing the Flowspec client to redirect traffic using a sequence 234 of indirection-id extended communities. The sequence of indirection- 235 ids is managed using Tunnel IDs (TID). i.e. a classic example would 236 be DDoS mitigation towards Segment Routing Central Egress Path 237 Engineering [4]. To steer DDoS traffic towards egress peer 238 engineering paths, a first indirection-id will steer traffic onto a 239 tunnel to an egress router, while a second indirection-id is used 240 steer the traffic at this egress router onto a particular interface 241 or towards a peer. The flowspec client will for this use-case 242 dynamically append all segment routing segments to steer the DDoS 243 traffic through the EPE path. 245 To achieve this type of redirection to next-next-hop tunnels, 246 multiple indirection-ids, each using a unique Tunnel ID are imposed 247 upon a the flowspec policy rule. The Tunnel ID will allow the 248 flowspec client to sequence the indirection-ids for correct next- 249 next-hop tunnel constructs. 251 4. Redirect to indirection-id Community 253 This document defines a new BGP extended community known as a 254 Redirect-to-indirection-id extended community. This extended 255 community is a new transitive extended community with the Type and 256 the Sub-Type field to be assigned by IANA. The format of this 257 extended community is show in Figure 1. 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | Sub-Type | Flags(1 octet)| Indirection ID| 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Generalized indirection_id | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 1 268 The meaning of the extended community fields are as follows: 270 Type: 1 octet to be assigned by IANA. 272 Sub-Type: 1 octet to be assigned by IANA. 274 Flags: 1 octet field. Following Flags are defined. 276 0 1 277 0 1 2 3 4 5 6 7 278 +-+-+-+-+-+-+-+-+ 279 | RES | TID |C| 280 +-+-+-+-+-+-+-+-+ 282 Figure 2 284 The least-significant Flag bit is defined as the 'C' (or copy) bit. 285 When the 'C' bit is set the redirection applies to copies of the 286 matching packets and not to the original traffic stream. 288 The 'TID' field identifies a 4 bit Table-id field. This field is 289 used to provide the flowspec client an indication how and where to 290 sequence the received indirection-ids to redirecting traffic. TID 291 value 0 indicates that Table-id field is NOT set and SHOULD be 292 ignored. 294 All bits other than the 'C' and 'TID' bits MUST be set to 0 by the 295 originating BGP speaker and ignored by receiving BGP speakers. 297 Indirection ID: 1 octet value. This draft defines following 298 indirection_id Types: 300 0 - Localised ID 302 1 - Node ID 304 2 - Agency ID 306 3 - AS (Autonomous System) ID 308 4 - Anycast ID 310 5 - Multicast ID 312 6 - Tunnel ID (Tunnel Binding ID ) 314 7 - VPN ID 316 8 - OAM ID 318 9 - ECMP (Equal Cost Multi-Path) ID 320 10 - QoS ID 322 11 - Bandwidth-Guarantee ID 323 12 - Security ID 325 13 - Multi-Topology ID 327 5. Redirect using localised indirection-id mapping table 329 When a BGP speaker receives a flowspec policy route with a 'redirect 330 to indirection-id' extended community and this route represents the 331 one and only best path or an equal cost multipath, it installs a 332 traffic filtering rule that matches the packets described by the NLRI 333 field and redirects them (C=0) or copies them (C=1) towards the 334 indirection-id local recursed path. To construct the local recursed 335 path, the flowspec client does a local indirection-id mapping table 336 lookup using the key comprised of the indirection-id 32-bit value and 337 indirection-id type to retrieve the correct redirection information. 339 6. Validation Procedures 341 The validation check described in RFC5575 [2] and revised in [3] 342 SHOULD be applied by default to received flow-spec routes with a 343 'redirect to indirection-id' extended community. This means that a 344 flow-spec route with a destination prefix subcomponent SHOULD NOT be 345 accepted from an EBGP peer unless that peer also advertised the best 346 path for the matching unicast route. 348 It is possible from a semenatics perspective to have multiple 349 redirect actions defined within a single flowspec rule. When a BGP 350 flowspec NLRI has a 'redirect to indirection-id' extended community 351 attached resulting in valid redirection then it MUST take priority 352 above all other redirect actions emposed. However, if the 'redirect 353 to indirection-id' does not result in a valid redirection, then the 354 flowspec rule must be processed as if the 'redirect to indirection- 355 id' community was not attached to the flowspec route and MUST provide 356 an indication within the BGP routing table that the respective 357 'redirect to indirection-id' resulted in an invalid redirection 358 action. 360 7. Security Considerations 362 A system using 'redirect-to-indirection-id' extended community can 363 cause during the redirect mitigation of a DDoS attack result in 364 overflow of traffic received by the mitigation infrastructure. 366 8. Acknowledgements 368 This document received valuable comments and input from IDR working 369 group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert 370 Raszuk, Jeff Haas, Susan Hares and Lucy Yong 372 9. IANA Considerations 374 This document requests a new type and sub-type for the Redirect to 375 indirection-id Extended community from the "Transitive Extended 376 community" registry. The Type name shall be "Redirect to 377 indirection-id Extended Community" and the Sub-type name shall be 378 'Flow-spec Redirect to 32-bit Path-id'. 380 In addition, this document requests IANA to create a new registry for 381 Redirect to indirection-id Extended Community INDIRECTION-IDs as 382 follows: 384 Under "Transitive Extended Community:" 386 Registry: "Redirect Extended Community indirection_id" 388 Reference: [RFC-To-Be] 390 Registration Procedure(s): First Come, First Served 392 Registry: "Redirect Extended Community indirection_id" 394 Value Code Reference 396 0 Localised ID [RFC-To-Be] 397 1 Node ID [RFC-To-Be] 398 2 Agency ID [RFC-To-Be] 399 3 AS (Autonomous System) ID [RFC-To-Be] 400 4 Anycast ID [RFC-To-Be] 401 5 Multicast ID [RFC-To-Be] 402 6 Tunnel ID (Tunnel Binding ID ) [RFC-To-Be] 403 7 VPN ID [RFC-To-Be] 404 8 OAM ID [RFC-To-Be] 405 9 ECMP (Equal Cost Multi-Path) ID [RFC-To-Be] 406 10 QoS ID [RFC-To-Be] 407 11 Bandwidth-Guarantee ID [RFC-To-Be] 408 12 Security ID [RFC-To-Be] 409 13 Multi-Topology ID [RFC-To-Be] 411 Figure 3 413 10. References 414 10.1. Normative References 416 [1] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, March 1997, 418 . 420 [2] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 421 and D. McPherson, "Dissemination of Flow Specification 422 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 423 . 425 10.2. Informative References 427 [3] Uttaro, J., Filsfils, C., Alcaide, J., and P. Mohapatra, 428 "Revised Validation Procedure for BGP Flow 429 Specifications", January 2014. 431 [4] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. 432 Afanasiev, "Segment Routing Centralized Egress Peer 433 Engineering", October 2015. 435 [5] Sreekantiah, A., Filsfils, C., Previdi, S., Sivabalan, S., 436 Mattes, P., and S. Lin, "Segment Routing Traffic 437 Engineering Policy using BGP", October 2015. 439 [6] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 440 Shakir, R., Bashandy, A., Horneffer, M., Henderickx, W., 441 Tantsura, J., Crabbe, E., Milojevic, I., and S. Ytti, 442 "Segment Routing Architecture", December 2015. 444 [7] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S., 445 Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J., 446 Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti, 447 "PCEP Extensions for Segment Routing", December 2015. 449 Authors' Addresses 451 Gunter Van de Velde (editor) 452 Nokia 453 Antwerp 454 BE 456 Email: gunter.van_de_velde@nokia.com 457 Wim Henderickx 458 Nokia 459 Antwerp 460 BE 462 Email: wim.henderickx@nokia.com 464 Keyur Patel 465 Cisco Systems 466 170 W. Tasman Drive 467 San Jose, CA 95134 468 USA 470 Email: keyupate@cisco.com 472 Arjun Sreekantiah 473 Cisco Systems 474 170 W. Tasman Drive 475 San Jose, CA 95134 476 USA 478 Email: asreekan@cisco.com 480 Zhenbin Li 481 Huawei Technologies 482 Huawei Bld., No. 156 Beiquing Rd 483 Beijing 100095 484 China 486 Email: lizhenbin@huawei.com 488 Shunwan Zhuang 489 Huawei Technologies 490 Huawei Bld., No. 156 Beiquing Rd 491 Beijing 100095 492 China 494 Email: zhuangshunwan@huawei.com 495 Nan Wu 496 Huawei Technologies 497 Huawei Bld., No. 156 Beiquing Rd 498 Beijing 100095 499 China 501 Email: eric.wu@huawei.com