idnits 2.17.1 draft-vandevelde-idr-flowspec-path-redirect-02.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 (March 17, 2016) is 2962 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 206 -- Looks like a reference, but probably isn't: 'I-D.sreekantiah-idr-segment-routing-te' on line 208 ** Obsolete normative reference: RFC 5575 (ref. '2') (Obsoleted by RFC 8955) Summary: 2 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 W. Henderickx 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: September 18, 2016 K. Patel 6 A. Sreekantiah 7 Cisco Systems 8 March 17, 2016 10 Flowspec Indirection-id Redirect 11 draft-vandevelde-idr-flowspec-path-redirect-02 13 Abstract 15 Flow-spec is an extension to BGP that allows for the dissemination of 16 traffic flow specification rules. This has many possible 17 applications but the primary one for many network operators is the 18 distribution of traffic filtering actions for DDoS mitigation. The 19 flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for 20 policy-based forwarding but this mechanism is not always sufficient, 21 particular if the redirected traffic needs to be steered into an 22 engineered path or into a service plane. 24 This document defines a new redirect-to-INDIRECTION_ID (32-bit or 25 128-bit) flow-spec action to provide advanced redirection 26 capabilities. When activated, the flowspec Indirection-id is used to 27 identify the next-hop redirect information within a router locallized 28 Indirection-id table. This allows a flowspec controller to signal 29 redirection towards a next-hop IP address, a shortest path tunnel, a 30 traffic engineered tunnel or a next-next-hop engineered tunnel 31 interface. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [1]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on September 18, 2016. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. INDIRECTION_ID and INDIRECTION_ID Table . . . . . . . . . . . 3 75 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4 76 3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 4 77 3.2. Redirection to path-engineered tunnels . . . . . . . . . 4 78 3.3. Redirection to Next-next-hop tunnels . . . . . . . . . . 5 79 4. Redirect to INDIRECTION-ID Communities . . . . . . . . . . . 6 80 5. Redirect using locallized INDIRECTION_ID Router Mapping . . . 7 81 6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 8 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 87 10.2. Informative References . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 90 1. Introduction 92 Flow-spec RFC5575 [2] is an extension to BGP that allows for the 93 dissemination of traffic flow specification rules. This has many 94 possible applications but the primary one for many network operators 95 is the distribution of traffic filtering actions for DDoS mitigation. 97 Every flow-spec route is effectively a rule, consisting of a matching 98 part (encoded in the NLRI field) and an action part (encoded in one 99 or more BGP extended community). The flow-spec standard RFC5575 [2] 100 defines widely-used filter actions such as discard and rate limit; it 101 also defines a redirect-to-VRF action for policy-based forwarding. 102 Using the redirect-to-VRF action for redirecting traffic towards an 103 alternate destination is useful for DDoS mitigation but using this 104 technology can be cumbersome when there is need to redirect the 105 traffic onto an engineered traffic path. 107 This draft proposes a new redirect-to-Indirection-id flow-spec action 108 facilitating an anchor point for policy-based forwarding onto an 109 engineered path or into a service plane. The router consuming and 110 utilizing the flowspec rule makes a local mapping between the 111 flowspec signalled redirect Indirection-id and locally available 112 redirection information referenced by the Indirection-id. This 113 locally available redirection information is derived from out-of-band 114 programming or signalling. 116 The redirect-to-Indirection-id is encoded in a newly defined BGP 117 extended Indirection_ID community. 119 The construction of the Indirection-id redirect table and the 120 technology used to create an engineered path are out-of-scope of this 121 document. 123 2. INDIRECTION_ID and INDIRECTION_ID Table 125 An INDIRECTION_ID is an abstract number (32-bit or 128-bit value) 126 used as identifier for a localised redirection decision. e.g. When a 127 BGP flowspec controller intends to redirect a flow using te redirect- 128 to-INDIRECTION_ID action then it has the ability to redirect the flow 129 to a destination abstracted as the INDIRECTION_ID. The device 130 receiving the BGP flowspec rule will use the INDIRECTION_ID to 131 identify the next-hop and the relevant tunnel encapsulations that 132 need to be pushed by a localised recursive lookup using information 133 located within the INDIRECTION_ID table. 135 The INDIRECTION_ID Table is a router localised table. The table 136 content is constructed out of INDIRECTION_IDs and corresponding 137 redirect information which may be of rescursive or non-recursive 138 nature. When the redirect information is non-recursive, then the 139 represented information MUST be sufficient to identify the local 140 egress interface and the corresponding required encapsulations. 141 However, if the information is recursive, then the represented 142 information MUST be sufficient to identify the local egress interface 143 and corresponding encapsulations using additional recursions. 145 3. Use Case Scenarios 147 This section describes use-case scenarios when deploying redirect-to- 148 INDIRECTION_ID. 150 3.1. Redirection shortest Path tunnel 152 A first use-case is allowing a BGP Flowspec controller send a single 153 flowspec policy message (redirect-to-INDIRECTION_ID#1) to many BGP 154 flowspec consuming routers. This message is instructing the Flowspec 155 recipient routers to redirect traffic onto a tunnel to a single IP 156 destination address. 158 For this use-case scenario, each flowspec recipient router has a 159 tunnel configured following the shortest path towards a tunnel IP 160 destination address. Each tunnel can have its own unique 161 encapsulation associated. Each tunnel is associated with an 162 INDIRECTION_ID, and for this example it is on all recipient routers 163 INDIRECTION_ID#1. Both manual and orchestrated tunnel provisioning 164 is supported, however for large scale deployment automation is 165 advisable. 167 When using this setup, a BGP flowspec controller can send a single 168 BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#1. This BGP 169 Flowspec NLRI is received by all recipient routers. Each of the 170 recipient routers performs a locallised recursive lookup for 171 INDIRECTION_ID#1 in the INDIRECTION_ID Table and identifies the 172 corresponding locallised tunnel redirect information. This 173 locallised tunnel information is now used to redirect traffic 174 matching the Flowspec policy towards a tunnel, each potentially using 175 its own unique tunnel encapsulation. 177 3.2. Redirection to path-engineered tunnels 179 A second use-case is allowing a BGP Flowspec controller send a single 180 flowspec policy message (redirect-to-INDIRECTION_ID#2) to many BGP 181 flowspec consuming routers. This message is instructing the Flowspec 182 recipient routers to redirect traffic onto a path engineered tunnel. 184 For this use-case scenario, each flowspec recipient router has a path 185 engineered tunnel configured. Each tunnel can have its own unique 186 encapsulation and engineered path associated. Each tunnel is 187 associated with an INDIRECTION_ID, and for this example it is on all 188 recipient routers INDIRECTION_ID#2. Both manual and orchestrated 189 tunnel provisioning is supported, however for large scale deployment 190 automation is advisable. 192 A first example using this setup, is when a BGP flowspec controller 193 sends a single BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#2. 194 This BGP Flowspec NLRI is received by all recipient routers. Each of 195 the recipient routers performs a locallised recursive lookup for 196 INDIRECTION_ID#2 in the INDIRECTION_ID Table and identifies the 197 corresponding locallised tunnel redirect information. This 198 locallised tunnel information is now used to redirect traffic 199 matching the Flowspec policy towards a path engineered tunnel. 201 A second example can be found in segment routed networks where path 202 engineered tunnels can be setup by means of a controller signaling 203 explicit paths to peering routers. In such a case, the 204 INDIRECTION_ID references to a Segment Routing Binding SID. The 205 Binding SID is a segment identifier value (as per segment routing 206 definitions in [I-D.draft-ietf-spring-segment-routing] [6]) used to 207 associate with a explicit path and can be setup by a controller using 208 BGP as specified in [I-D.sreekantiah-idr-segment-routing-te] [5] or 209 using PCE as detailed in draft-ietf-pce-segment-routing [7]. When a 210 BGP speaker receives a flow-spec route with a 'redirect to Binding 211 SID' extended community, it installs a traffic filtering rule that 212 matches the packets described by the NLRI field and redirects them to 213 the explicit path associated with the Binding SID. The explicit path 214 is specified as a set/stack of segment identifiers as detailed in the 215 previous documents. The stack of segment identifiers is now imposed 216 on packets matching the flow-spec rule to perform redirection as per 217 the explicit path setup prior. The encoding of the Binding SID value 218 is specified in section 4, with the indirection field now encoding 219 the associated value for the binding SID. 221 3.3. Redirection to Next-next-hop tunnels 223 A Third use-case is allowing a BGP Flowspec controller send a single 224 flowspec policy message (redirect-to-INDIRECTION_ID#3) to many BGP 225 flowspec consuming routers. This message is instructing the Flowspec 226 recipient routers to redirect traffic onto a shortest or engineered 227 path to a tunnel end-point and onwards to the next-hop-interface on 228 this end-point. This type of tunnel is used for example for Segment 229 Routing Central Egress Path Engineering [4]. 231 For this use-case scenario, each flowspec recipient router constructs 232 redirect information using two tunnel components. The first 233 component is a shortest or engineered path towards a network egress 234 router. The second component is the interface used on this network 235 egress router to which the redirected traffic needs to be steered 236 upon. The combination of these two components allows steering 237 towards the next-hop of the egress router, allowing for example the 238 Central Egress Path Engineering using BGP Flowspec [4]. 240 The redirection towards a next-next-hop tunnel can be done by using 241 either a single INDIRECTION_ID representing the combined path to the 242 egress router and steering the traffic to the egress interface, or by 243 using individual INDIRECTION_IDs each representing a tunnel component 244 (One INDIRECTION_ID value to identify the path towards the egress 245 router and another INDIRECTION_ID value to identify the egress 246 interface on this egress router towards the next-next-hop). When 247 using individual INDIRECTION_IDs it is required to use INDIRECTION_ID 248 community Tunnel IDs (TID) each identifying a component of the 249 complete redirect path attached to the NLRI. 251 i.e. when using next-next-hop tunnels, a BGP flowspec controller can 252 send a single BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#3. 253 This BGP Flowspec NLRI is received by all recipient routers. Each of 254 the recipient routers performs a locallised recursive lookup for 255 INDIRECTION_ID#3 in the INDIRECTION_ID Table and identifies the 256 corresponding locallised tunnel redirect information (=path to the 257 egress router and the next-hop egress interface on this router). 258 Traffic matching the flowspec policy is redirected towards the 259 recursively found redirection information. 261 4. Redirect to INDIRECTION-ID Communities 263 This document defines a new BGP extended community. The extended 264 communities have a type indicating they are transitive and IPv4- 265 address-specific or IPv6-address-specific, depending on whether the 266 INDIRECTION_ID is 32-bit or 128-bit. The sub-type value [to be 267 assigned by IANA] indicates that the global administrator and local 268 administrator fields encode a flow-spec 'redirect to INDIRECTION_ID' 269 action. In the new extended community the 4-byte or 16-byte global 270 administrator field encodes the 32-bit or 128-bit INDIRECTION_ID's 271 providing the INDIRECTION_ID to allow a local to the router mapping 272 reference to an engineered Path. The 2-byte local administrator 273 field is formatted as shown in Figure 1. 275 0 1 276 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Reserved |B|TID|C| 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 1 283 In the local administrator field the least-significant bit is defined 284 as the 'C' (or copy) bit. When the 'C' bit is set the redirection 285 applies to copies of the matching packets and not to the original 286 traffic stream. 288 The 'TID' field identifies a 2 bit Table-id field. This field is 289 used to provide the router consuming the flowspec rule an indication 290 how and where to use the INDIRECTION_ID when redirecting traffic. 292 Bit 2 is defined to be the 'B' (Binding) bit. When the 'B' bit is 293 set, the value encoded in the global administrator field is a Binding 294 Segment Identifier value the use of which is detailed in section 3.2. 296 All bits other than the 'C', 'TID' and 'B' bits in the local 297 administrator field MUST be set to 0 by the originating BGP speaker 298 and ignored by receiving BGP speakers. 300 5. Redirect using locallized INDIRECTION_ID Router Mapping 302 When a BGP speaker receives a flow-spec route with a 'redirect to 303 INDIRECTION_ID' extended community and this route represents the one 304 and only best path, it installs a traffic filtering rule that matches 305 the packets described by the NLRI field and redirects them (C=0) or 306 copies them (C=1) towards the INDIRECTION_ID local recursed Path. 307 The BGP speaker is expected to do a local INDIRECTION_ID Table lookup 308 to identify the redirection information. 310 The router local INDIRECTION_ID table contains a list of 311 INDIRECTION_ID's each mapped to redirect information. The redirect 312 information can be non-recursive (i.e. there is only one option 313 available in the INDIRECTION_ID Table) or recursive (i.e. L3 VPN, L2 314 VPN, a pre-programmed routing topology, etc... ). 316 o When the redirect information is non-recursive then the packet is 317 redirected based upon the information found in the Table. 319 o In case of a next-hop tunnel, the traffic matching the flowspec 320 rule is redirected to the next-hop tunnel. This tunnel could be 321 instantiated through various means (i.e. manual configuration, 322 PCEP, RSVP-TE, WAN Controller, Segment Routing, etc...). 324 o In case of redirection to a local next-hop interface, the traffic 325 matching the flowspec rule is redirected to the local next-hop 326 interface. 328 o In case the INDIRECTION_ID Table lookup results in redirect 329 information identifying an additional layer of recursion, then 330 this will trigger the flow to be redirected based upon an 331 additional routing lookup within the realm of the additional layer 332 of recursion. 334 6. Validation Procedures 336 The validation check described in RFC5575 [2] and revised in [3] 337 SHOULD be applied by default to received flow-spec routes with a 338 'redirect to INDIRECTION_ID' extended community. This means that a 339 flow-spec route with a destination prefix subcomponent SHOULD NOT be 340 accepted from an EBGP peer unless that peer also advertised the best 341 path for the matching unicast route. 343 It is possible from a semenatics perspective to have multiple 344 redirect actions defined within a single flowspec rule. When a BGP 345 flowspec NLRI has a 'redirect to INDIRECTION_ID' extended community 346 attached resulting in valid redirection then it MUST take priority 347 above all other redirect actions emposed. However, if the 'redirect 348 to INDIRECTION_ID' does not result in a valid redirection, then the 349 flowspec rule must be processed as if the 'redirect to 350 INDIRECTION_ID' community was not attached to the flowspec route and 351 MUST provide an indication within the BGP routing table that the 352 'redirect to INDIRECTION_ID' resulted in an invalid redirection 353 action. 355 7. Security Considerations 357 A system using 'redirect-to-INDIRECTION_ID' extended community can 358 cause during the redirect mitigation of a DDoS attack result in an 359 overflow of traffic being received by the mitigation infrastructure. 361 8. Acknowledgements 363 This document received valuable comments and input from IDR working 364 group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert 365 Raszuk, Jeff Haas, Susan Hares and Lucy Yong 367 9. IANA Considerations 369 This document requests a new sub-type from the "Transitive IPv4- 370 Address-Specific" extended community registry. The sub-type name 371 shall be 'Flow-spec Redirect to 32-bit Path-id'. 373 This document requests a new sub-type from the "Transitive IPv6- 374 Address-Specific" extended community registry. The sub-type name 375 shall be 'Flow-spec Redirect to 128-bit Path-id'. 377 10. References 378 10.1. Normative References 380 [1] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997, 382 . 384 [2] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 385 and D. McPherson, "Dissemination of Flow Specification 386 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 387 . 389 10.2. Informative References 391 [3] Uttaro, J., Filsfils, C., Alcaide, J., and P. Mohapatra, 392 "Revised Validation Procedure for BGP Flow 393 Specifications", January 2014. 395 [4] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. 396 Afanasiev, "Segment Routing Centralized Egress Peer 397 Engineering", October 2015. 399 [5] Sreekantiah, A., Filsfils, C., Previdi, S., Sivabalan, S., 400 Mattes, P., and S. Lin, "Segment Routing Traffic 401 Engineering Policy using BGP", October 2015. 403 [6] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 404 Shakir, R., Bashandy, A., Horneffer, M., Henderickx, W., 405 Tantsura, J., Crabbe, E., Milojevic, I., and S. Ytti, 406 "Segment Routing Architecture", December 2015. 408 [7] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S., 409 Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J., 410 Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti, 411 "PCEP Extensions for Segment Routing", December 2015. 413 Authors' Addresses 415 Gunter Van de Velde (editor) 416 Alcatel-Lucent 417 Antwerp 418 BE 420 Email: gunter.van_de_velde@alcatel-lucent.com 421 Wim Henderickx 422 Alcatel-Lucent 423 Antwerp 424 BE 426 Email: wim.henderickx@alcatel-lucent.com 428 Keyur Patel 429 Cisco Systems 430 170 W. Tasman Drive 431 San Jose, CA 95134 432 USA 434 Email: keyupate@cisco.com 436 Arjun Sreekantiah 437 Cisco Systems 438 170 W. Tasman Drive 439 San Jose, CA 95134 440 USA 442 Email: asreekan@cisco.com