idnits 2.17.1 draft-vandevelde-idr-flowspec-path-redirect-01.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 (January 12, 2016) is 3026 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) ** Obsolete normative reference: RFC 5575 (ref. '2') (Obsoleted by RFC 8955) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: July 15, 2016 K. Patel 6 Cisco Systems 7 January 12, 2016 9 Flowspec Indirection-id Redirect 10 draft-vandevelde-idr-flowspec-path-redirect-01 12 Abstract 14 Flow-spec is an extension to BGP that allows for the dissemination of 15 traffic flow specification rules. This has many possible 16 applications but the primary one for many network operators is the 17 distribution of traffic filtering actions for DDoS mitigation. The 18 flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for 19 policy-based forwarding but this mechanism is not always sufficient, 20 particular if the redirected traffic needs to be steered into an 21 engineered path or into a service plane. 23 This document defines a new redirect-to-INDIRECTION_ID (32-bit or 24 128-bit) flow-spec action to provide advanced redirection 25 capabilities. When activated, the flowspec Indirection-id is used to 26 identify the next-hop redirect information within a router locallized 27 Indirection-id table. This allows a flowspec controller to signal 28 redirection towards a next-hop IP address, a shortest path tunnel, a 29 traffic engineered tunnel or a next-next-hop (traffic engineered) 30 tunnel egress interface. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [1]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on July 15, 2016. 55 Copyright Notice 57 Copyright (c) 2016 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. INDIRECTION_ID and INDIRECTION_ID Table . . . . . . . . . . . 3 74 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4 75 3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 4 76 3.2. Redirection to path-engineered tunnels . . . . . . . . . 4 77 3.3. Redirection to Next-next-hop tunnels . . . . . . . . . . 5 78 4. Redirect to INDIRECTION-ID Communities . . . . . . . . . . . 6 79 5. Redirect using locallized INDIRECTION_ID Router Mapping . . . 6 80 6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 7 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 86 10.2. Informative References . . . . . . . . . . . . . . . . . 8 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 89 1. Introduction 91 Flow-spec RFC5575 [2] is an extension to BGP that allows for the 92 dissemination of traffic flow specification rules. This has many 93 possible applications but the primary one for many network operators 94 is the distribution of traffic filtering actions for DDoS mitigation. 96 Every flow-spec route is effectively a rule, consisting of a matching 97 part (encoded in the NLRI field) and an action part (encoded in one 98 or more BGP extended community). The flow-spec standard RFC5575 [2] 99 defines widely-used filter actions such as discard and rate limit; it 100 also defines a redirect-to-VRF action for policy-based forwarding. 101 Using the redirect-to-VRF action for redirecting traffic towards an 102 alternate destination is useful for DDoS mitigation but using this 103 technology can be cumbersome when there is need to redirect the 104 traffic onto an engineered traffic path. 106 This draft proposes a new redirect-to-Indirection-id flow-spec action 107 facilitating an anchor point for policy-based forwarding onto an 108 engineered path or into a service plane. The router consuming and 109 utilizing the flowspec rule makes a local mapping between the 110 flowspec signalled redirect Indirection-id and locally available 111 redirection information referenced by the Indirection-id. This 112 locally available redirection information is derived from out-of-band 113 programming or signalling. 115 The redirect-to-Indirection-id is encoded in a newly defined BGP 116 extended Indirection_ID community. 118 The construction of the Indirection-id redirect table and the 119 technology used to create an engineered path are out-of-scope of this 120 document. 122 2. INDIRECTION_ID and INDIRECTION_ID Table 124 An INDIRECTION_ID is an abstract number (32-bit or 128-bit value) 125 used as identifier for a localised redirection decision. e.g. When a 126 BGP flowspec controller intends to redirect a flow using te redirect- 127 to-INDIRECTION_ID action then it has the ability to redirect the flow 128 to a destination abstracted as the INDIRECTION_ID. The device 129 receiving the BGP flowspec rule will use the INDIRECTION_ID to 130 identify the next-hop and the relevant tunnel encapsulations that 131 need to be pushed by a localised recursive lookup using information 132 located within the INDIRECTION_ID table. 134 The INDIRECTION_ID Table is a router localised table. The table 135 content is constructed out of INDIRECTION_IDs and corresponding 136 redirect information which may be of rescursive or non-recursive 137 nature. When the redirect information is non-recursive, then the 138 represented information MUST be sufficient to identify the local 139 egress interface and the corresponding required encapsulations. 140 However, if the information is recursive, then the represented 141 information MUST be sufficient to identify the local egress interface 142 and corresponding encapsulations using additional recursions. 144 3. Use Case Scenarios 146 This section describes use-case scenarios when deploying redirect-to- 147 INDIRECTION_ID. 149 3.1. Redirection shortest Path tunnel 151 A first use-case is allowing a BGP Flowspec controller send a single 152 flowspec policy message (redirect-to-INDIRECTION_ID#1) to many BGP 153 flowspec consuming routers. This message is instructing the Flowspec 154 recipient routers to redirect traffic onto a tunnel to a single IP 155 destination address. 157 For this use-case scenario, each flowspec recipient router has a 158 tunnel configured following the shortest path towards a tunnel IP 159 destination address. Each tunnel can have its own unique 160 encapsulation associated. Each tunnel is associated with an 161 INDIRECTION_ID, and for this example it is on all recipient routers 162 INDIRECTION_ID#1. Both manual and orchestrated tunnel provisioning 163 is supported, however for large scale deployment automation is 164 advisable. 166 When using this setup, a BGP flowspec controller can send a single 167 BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#1. This BGP 168 Flowspec NLRI is received by all recipient routers. Each of the 169 recipient routers performs a locallised recursive lookup for 170 INDIRECTION_ID#1 in the INDIRECTION_ID Table and identifies the 171 corresponding locallised tunnel redirect information. This 172 locallised tunnel information is now used to redirect traffic 173 matching the Flowspec policy towards a tunnel, each potentially using 174 its own unique tunnel encapsulation. 176 3.2. Redirection to path-engineered tunnels 178 A second use-case is allowing a BGP Flowspec controller send a single 179 flowspec policy message (redirect-to-INDIRECTION_ID#2) to many BGP 180 flowspec consuming routers. This message is instructing the Flowspec 181 recipient routers to redirect traffic onto a path engineered tunnel. 183 For this use-case scenario, each flowspec recipient router has a path 184 engineered tunnel configured. Each tunnel can have its own unique 185 encapsulation and engineerd path associated. Each tunnel is 186 associated with an INDIRECTION_ID, and for this example it is on all 187 recipient routers INDIRECTION_ID#2. Both manual and orchestrated 188 tunnel provisioning is supported, however for large scale deployment 189 automation is advisable. 191 When using this setup, a BGP flowspec controller can send a single 192 BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#2. This BGP 193 Flowspec NLRI is received by all recipient routers. Each of the 194 recipient routers performs a locallised recursive lookup for 195 INDIRECTION_ID#2 in the INDIRECTION_ID Table and identifies the 196 corresponding locallised tunnel redirect information. This 197 locallised tunnel information is now used to redirect traffic 198 matching the Flowspec policy towards a path engineered tunnel. 200 3.3. Redirection to Next-next-hop tunnels 202 A Third use-case is allowing a BGP Flowspec controller send a single 203 flowspec policy message (redirect-to-INDIRECTION_ID#3) to many BGP 204 flowspec consuming routers. This message is instructing the Flowspec 205 recipient routers to redirect traffic onto a shortest or engineered 206 path to a tunnel end-point and onwards to the next-hop-interface on 207 this end-point. This type of tunnel is used for example for Segment 208 Routing Central Egress Path Engineering [4]. 210 For this use-case scenario, each flowspec recipient router constructs 211 redirect information using two tunnel components. The first 212 component is a shortest or engineered path towards a network egress 213 router. The second component is the interface used on this network 214 egress router to which the redirected traffic needs to be steered 215 upon. The combination of these two components allows steering 216 towards the next-hop of the egress router, allowing for example the 217 Central Egress Path Engineering using BGP Flowspec [4]. 219 The redirection towards a next-next-hop tunnel can be done by using 220 either a single INDIRECTION_ID representing the combined path to the 221 egress router and steering the traffic to the egress interface, or by 222 using individual INDIRECTION_IDs each representing a tunnel component 223 (One INDIRECTION_ID value to identify the path towards the egress 224 router and another INDIRECTION_ID value to identify the egress 225 interface on this egress router towards the next-next-hop). When 226 using individual INDIRECTION_IDs it is required to use INDIRECTION_ID 227 community Tunnel IDs (TID) each identifying a component of the 228 complete redirect path attached to the NLRI. 230 i.e. when using next-next-hop tunnels, a BGP flowspec controller can 231 send a single BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#3. 232 This BGP Flowspec NLRI is received by all recipient routers. Each of 233 the recipient routers performs a locallised recursive lookup for 234 INDIRECTION_ID#3 in the INDIRECTION_ID Table and identifies the 235 corresponding locallised tunnel redirect information (=path to the 236 egress router and the next-hop egress interface on this router). 237 Traffic matching the flowspec policy is redirected towards the 238 recursively found redirection information. 240 4. Redirect to INDIRECTION-ID Communities 242 This document defines a new BGP extended community. The extended 243 communities have a type indicating they are transitive and IPv4- 244 address-specific or IPv6-address-specific, depending on whether the 245 INDIRECTION_ID is 32-bit or 128-bit. The sub-type value [to be 246 assigned by IANA] indicates that the global administrator and local 247 administrator fields encode a flow-spec 'redirect to INDIRECTION_ID' 248 action. In the new extended community the 4-byte or 16-byte global 249 administrator field encodes the 32-bit or 128-bit INDIRECTION_ID's 250 providing the INDIRECTION_ID to allow a local to the router mapping 251 reference to an engineered Path. The 2-byte local administrator 252 field is formatted as shown in Figure 1. 254 0 1 255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Reserved |TID|C| 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 1 262 In the local administrator field the least-significant bit is defined 263 as the 'C' (or copy) bit. When the 'C' bit is set the redirection 264 applies to copies of the matching packets and not to the original 265 traffic stream. 267 The 'TID' field identifies a 2 bit Table-id field. This field is 268 used to provide the router consuming the flowspec rule an indication 269 how and where to use the INDIRECTION_ID when redirecting traffic. 271 All bits other than the 'C' bit in the local administrator field MUST 272 be set to 0 by the originating BGP speaker and ignored by receiving 273 BGP speakers. 275 5. Redirect using locallized INDIRECTION_ID Router Mapping 277 When a BGP speaker receives a flow-spec route with a 'redirect to 278 INDIRECTION_ID' extended community and this route represents the one 279 and only best path, it installs a traffic filtering rule that matches 280 the packets described by the NLRI field and redirects them (C=0) or 281 copies them (C=1) towards the INDIRECTION_ID local recursed Path. 282 The BGP speaker is expected to do a local INDIRECTION_ID Table lookup 283 to identify the redirection information. 285 The router local INDIRECTION_ID table contains a list of 286 INDIRECTION_ID's each mapped to redirect information. The redirect 287 information can be non-recursive (i.e. there is only one option 288 available in the INDIRECTION_ID Table) or recursive (i.e. L3 VPN, L2 289 VPN, a pre-programmed routing topology, etc... ). 291 o When the redirect information is non-recursive then the packet is 292 redirected based upon the information found in the Table. 294 o In case of a next-hop tunnel, the traffic matching the flowspec 295 rule is redirected to the next-hop tunnel. This tunnel could be 296 instantiated through various means (i.e. manual configuration, 297 PCEP, RSVP-TE, WAN Controller, Segment Routing, etc...). 299 o In case of redirection to a local next-hop interface, the traffic 300 matching the flowspec rule is redirected to the local next-hop 301 interface. 303 o In case the INDIRECTION_ID Table lookup results in redirect 304 information identifying an additional layer of recursion, then 305 this will trigger the flow to be redirected based upon an 306 additional routing lookup within the realm of the additional layer 307 of recursion. 309 6. Validation Procedures 311 The validation check described in RFC5575 [2] and revised in [3] 312 SHOULD be applied by default to received flow-spec routes with a 313 'redirect to INDIRECTION_ID' extended community. This means that a 314 flow-spec route with a destination prefix subcomponent SHOULD NOT be 315 accepted from an EBGP peer unless that peer also advertised the best 316 path for the matching unicast route. 318 It is possible from a semenatics perspective to have multiple 319 redirect actions defined within a single flowspec rule. When a BGP 320 flowspec NLRI has a 'redirect to INDIRECTION_ID' extended community 321 attached resulting in valid redirection then it MUST take priority 322 above all other redirect actions emposed. However, if the 'redirect 323 to INDIRECTION_ID' does not result in a valid redirection, then the 324 flowspec rule must be processed as if the 'redirect to 325 INDIRECTION_ID' community was not attached to the flowspec route and 326 MUST provide an indication within the BGP routing table that the 327 'redirect to INDIRECTION_ID' resulted in an invalid redirection 328 action. 330 7. Security Considerations 332 A system using 'redirect-to-INDIRECTION_ID' extended community can 333 cause during the redirect mitigation of a DDoS attack result in an 334 overflow of traffic being received by the mitigation infrastructure. 336 8. Acknowledgements 338 This document received valuable comments and input from IDR working 339 group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert 340 Raszuk, Jeff Haas, Susan Hares and Lucy Yong 342 9. IANA Considerations 344 This document requests a new sub-type from the "Transitive IPv4- 345 Address-Specific" extended community registry. The sub-type name 346 shall be 'Flow-spec Redirect to 32-bit Path-id'. 348 This document requests a new sub-type from the "Transitive IPv6- 349 Address-Specific" extended community registry. The sub-type name 350 shall be 'Flow-spec Redirect to 128-bit Path-id'. 352 10. References 354 10.1. Normative References 356 [1] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, March 1997, 358 . 360 [2] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 361 and D. McPherson, "Dissemination of Flow Specification 362 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 363 . 365 10.2. Informative References 367 [3] Uttaro, J., Filsfils, C., Filsfils, C., Alcaide, J., and 368 P. Mohapatra, "Revised Validation Procedure for BGP Flow 369 Specifications", January 2014. 371 [4] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. 372 Afanasiev, "Segment Routing Centralized Egress Peer 373 Engineering", October 2015. 375 Authors' Addresses 377 Gunter Van de Velde (editor) 378 Alcatel-Lucent 379 Antwerp 380 BE 382 Email: gunter.van_de_velde@alcatel-lucent.com 384 Wim Henderickx 385 Alcatel-Lucent 386 Antwerp 387 BE 389 Email: wim.henderickx@alcatel-lucent.com 391 Keyur Patel 392 Cisco Systems 393 170 W. Tasman Drive 394 San Jose, CA 95134 395 USA 397 Email: keyupate@cisco.com