idnits 2.17.1 draft-vandevelde-idr-flowspec-path-redirect-00.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 (September 14, 2015) is 3141 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 3 Internet-Draft W. Henderickx 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: March 17, 2016 K. Patel 6 Cisco Systems 7 September 14, 2015 9 Flowspec Path-id Redirect 10 draft-vandevelde-idr-flowspec-path-redirect-00 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. 23 This document defines a new redirect-to-Path-id (32-bit or 128-bit) 24 flow-spec action to provide advanced redirection capabilities. When 25 activated, the flowspec signalled Path-id is used to identify the 26 next-hop redirect information within a localized to the router Path- 27 id redirect table. The Path-id redirect table is a table providing a 28 list of Path-id's and router local redirect information. This allows 29 a Flowspec signalled redirect towards a next-hop IP address, next-hop 30 local interface or next-hop (traffic engineered) tunnel 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 March 17, 2016. 55 Copyright Notice 57 Copyright (c) 2015 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. Redirect to Path-id Communities . . . . . . . . . . . . . . . 3 74 3. Redirect using localized Path-id Router Mapping . . . . . . . 4 75 4. Validation Procedures . . . . . . . . . . . . . . . . . . . . 4 76 5. Localized Path-id Table . . . . . . . . . . . . . . . . . . . 5 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 82 9.2. Informative References . . . . . . . . . . . . . . . . . 6 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 85 1. Introduction 87 Flow-spec RFC5575 [2] is an extension to BGP that allows for the 88 dissemination of traffic flow specification rules. This has many 89 possible applications but the primary one for many network operators 90 is the distribution of traffic filtering actions for DDoS mitigation. 92 Every flow-spec route is effectively a rule, consisting of a matching 93 part (encoded in the NLRI field) and an action part (encoded in one 94 or more BGP extended community). The flow-spec standard RFC5575 [2] 95 defines widely-used filter actions such as discard and rate limit; it 96 also defines a redirect-to-VRF action for policy-based forwarding. 97 Using the redirect-to-VRF action for redirecting traffic towards an 98 alternate destination is useful for DDoS mitigation but using this 99 technology can be cumbersome when there is need to redirect the 100 traffic onto an engineered traffic path. 102 This draft proposes a new redirect-to-Path-id flow-spec action 103 facilitating an anchor point for policy-based forwarding onto an 104 engineered path. The router consuming and utilizing the flowspec 105 rule makes a local mapping between the flowspec signalled redirect 106 Path-id and locally available redirection information referenced by 107 the Path-id. This locally available redirection information is 108 derived from out-of-band programming or signalling. 110 The redirect-to-Path-id is encoded in a newly defined BGP extended 111 Path-id community. 113 The construction of the Path-id redirect table and the technology 114 used to create an engineered path are out-of-scope of this document. 116 2. Redirect to Path-id Communities 118 This document defines a new BGP extended community. The extended 119 communities have a type indicating they are transitive and IPv4- 120 address-specific or IPv6-address-specific, depending on whether the 121 redirection Path-id is 32-bit or 128-bit. The sub-type value [to be 122 assigned by IANA] indicates that the global administrator and local 123 administrator fields encode a flow-spec 'redirect to Path-id' action. 124 In the new extended community the 4-byte or 16-byte global 125 administrator field encodes the 32-bit or 128-bit Path-id's providing 126 the redirection Path-id to allow a local to the router mapping 127 reference to an engineered Path. The 2-byte local administrator 128 field is formatted as shown in Figure 1. 130 0 1 131 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Reserved |TID|C| 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Figure 1 138 In the local administrator field the least-significant bit is defined 139 as the 'C' (or copy) bit. When the 'C' bit is set the redirection 140 applies to copies of the matching packets and not to the original 141 traffic stream. 143 The 'TID' field identifies a 2 bit Table-id field. This field is 144 used to provide the router consuming the flowspec rule an indication 145 how and where to use the Path-id when redirecting traffic. 147 All bits other than the 'C' bit in the local administrator field MUST 148 be set to 0 by the originating BGP speaker and ignored by receiving 149 BGP speakers. 151 3. Redirect using localized Path-id Router Mapping 153 When a BGP speaker receives a flow-spec route with a 'redirect to 154 Path-id' extended community and this route represents the one and 155 only best path, it installs a traffic filtering rule that matches the 156 packets described by the NLRI field and redirects them (C=0) or 157 copies them (C=1) towards the locally engineered Paths referenced by 158 the extended community's global administrator field. The BGP speaker 159 is expected to do a local Path-id table lookup and identify inside 160 this table a redirect path referenced by the Flowspec Path-id 161 community field. 163 The router local Path-id table contains a list of Path-id's mapped to 164 redirect information. The redirect information can be a next-hop IP 165 address, a local next-hop Interface or a next-hop tunnel. 167 o When the redirect information is a Next-hop IP address, then a 168 recursive routing lookup to this destination address is performed 169 and the traffic matching the flowspec rule is redirected to this 170 next-hop IP address. 172 o In case of redirection to a local next-hop interface, the traffic 173 matching the flowspec rule is redirected to the local next-hop 174 interface. 176 o In case of a next-hop tunnel, the traffic matching the flowspec 177 rule is redirected to the next-hop tunnel. This tunnel could be 178 instantiated through various means (i.e. manual configuration, 179 PCEP, RSVP-TE, WAN Controller, Segment Routing, etc...). 181 4. Validation Procedures 183 The validation check described in RFC5575 [2] and revised in [3] 184 SHOULD be applied by default to received flow-spec routes with a 185 'redirect to Path-id' extended community, as it is to all types of 186 flow-spec routes. This means that a flow-spec route with a 187 destination prefix subcomponent SHOULD NOT be accepted from an EBGP 188 peer unless that peer also advertised the best path for the matching 189 unicast route. 191 TBC (add what to check regarding Path-id and redirect-ip Next-hop 192 usage 194 5. Localized Path-id Table 196 Each router participating in the Path-id based Flowspec redirect has 197 a locallized Path-id indexed table. The exact nature on how this 198 table is populated is out of scope of this document. The Path-id 199 locallized table provides a list of Path-id's, each followed by a set 200 of Labels or encapsulation information to push for the traffic 201 matching the flowspec rule. If the flowspec rule signals multiple 202 Path-id communities, then it is a localized decision on the Flowspec 203 consuming device how the set of Path-id's will be pushed upon 204 Flowspec matching traffic. 206 6. Security Considerations 208 A system using 'redirect to Path-id' extended community can cause 209 during the redirect mitigation of a DDoS attack an overflow 210 of traffic being received by the mitigation infrastructure. 212 7. Acknowledgements 214 This document has been contributed by Adam Simpson, Mustapha 215 Aissaoui, Jan Mertens. 217 8. IANA Considerations 219 This document requests a new sub-type from the "Transitive IPv4- 220 Address-Specific" extended community registry. The sub-type name 221 shall be 'Flow-spec Redirect to 32-bit Path-id'. 223 This document requests a new sub-type from the "Transitive IPv6- 224 Address-Specific" extended community registry. The sub-type name 225 shall be 'Flow-spec Redirect to 128-bit Path-id'. 227 9. References 229 9.1. Normative References 231 [1] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, March 1997, 233 . 235 [2] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 236 and D. McPherson, "Dissemination of Flow Specification 237 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 238 . 240 9.2. Informative References 242 [3] Uttaro, J., Filsfils, C., Filsfils, C., Alcaide, J., and 243 P. Mohapatra, "Revised Validation Procedure for BGP Flow 244 Specifications", January 2014. 246 Authors' Addresses 248 Gunter Van de Velde 249 Alcatel-Lucent 250 Antwerp 251 BE 253 Email: gunter.van_de_velde@alcatel-lucent.com 255 Wim Henderickx 256 Alcatel-Lucent 257 Antwerp 258 BE 260 Email: wim.henderickx@alcatel-lucent.com 262 Keyur Patel 263 Cisco Systems 264 170 W. Tasman Drive 265 San Jose, CA 95134 266 USA 268 Email: keyupate@cisco.com