idnits 2.17.1 draft-ietf-idr-flowspec-redirect-ip-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 ([RFC5575]), 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 (Feb 2, 2015) is 3370 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) == Missing Reference: 'RFC 5575' is mentioned on line 212, but not defined ** Obsolete undefined reference: RFC 5575 (Obsoleted by RFC 8955) == Missing Reference: 'RFC-2119' is mentioned on line 118, but not defined == Unused Reference: 'RFC2119' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'RFC5575' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'IPV6-FLOW' is defined on line 266, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-00 == Outdated reference: A later version (-15) exists of draft-ietf-idr-bgp-flowspec-oid-00 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDR Working Group J. Uttaro 2 Internet-Draft AT&T 3 Intended status: Standards Track 4 Expires: Aug 2, 2015 J. Haas 5 Juniper Networks 7 M. Texier 8 Arbor Networks 10 A. Karch 11 A. Sreekantiah 12 S. Ray 13 Cisco Systems 15 A. Simpson 16 W. Henderickx 17 Alcatel-Lucent 19 Feb 2, 2015 21 BGP Flow-Spec Redirect to IP Action 22 draft-ietf-idr-flowspec-redirect-ip-02.txt 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on Aug 2, 2015. 47 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Abstract 64 Flow-spec is an extension to BGP that allows for the dissemination 65 of traffic flow specification rules. This has many possible 66 applications but the primary one for many network operators is the 67 distribution of traffic filtering actions for DDoS mitigation. The 68 flow-spec standard [RFC 5575] defines a redirect-to-VRF action for 69 policy-based forwarding but this mechanism can be difficult to use, 70 particularly in networks without L3 VPN infrastructure. 72 This draft defines a new redirect-to-IP flow-spec action that 73 provides a simpler method of policy-based forwarding. The details of 74 the action, including the IPv4 or IPv6 target address, are encoded 75 in newly defined BGP extended communities. 77 Table of Contents 79 1. Introduction...................................................3 80 2. Terminology....................................................3 81 3. Redirect to IP Extended Communities............................3 82 3.1. Validation Procedures.....................................5 83 4. Security Considerations........................................6 84 5. IANA Considerations............................................6 85 6. References.....................................................6 86 6.1. Normative References......................................6 87 6.2. Informative References....................................6 88 7. Contributors...................................................7 89 8. Acknowledgments................................................7 91 1. Introduction 93 Flow-spec is an extension to BGP that allows for the dissemination 94 of traffic flow specification rules. This has many possible 95 applications but the primary one for many network operators is the 96 distribution of traffic filtering actions for DDoS mitigation. 98 Every flow-spec route is effectively a rule, consisting of a 99 matching part (encoded in the NLRI field) and an action part 100 (encoded in one or more BGP extended communities). The flow-spec 101 standard [RFC 5575] defines widely-used filter actions such as 102 discard and rate limit; it also defines a redirect-to-VRF action for 103 policy-based forwarding. Using the redirect-to-VRF action for 104 redirecting traffic towards an alternate destination is useful for 105 DDoS mitigation but it can be complex and cumbersome, particularly 106 in networks without L3 VPN infrastructure. 108 This draft proposes a new redirect-to-IP flow-spec action that 109 provides a simpler method of policy-based forwarding. The details of 110 the action, including the IPv4 or IPv6 target address, are encoded 111 in newly defined BGP extended communities. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC-2119]. 119 3. Redirect to IP Extended Communities 121 This document defines two new BGP extended communities. The extended 122 communities have a type indicating they are transitive and IPv4- 123 address-specific or IPv6-address-specific, depending on whether the 124 redirection target address is IPv4 or IPv6. The sub-type value [to 125 be assigned by IANA] indicates that the global administrator and 126 local administrator fields encode a flow-spec 'redirect to IP' 127 action. In the new extended communities the 4-byte or 16-byte global 128 administrator field encodes the IPv4 or IPv6 address that is the 129 redirection target address and the 2-byte local administrator field 130 is formatted as shown in Figure 1. 132 Figure 1 : Local Administrator 134 0 1 135 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Reserved |C| 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 In the local administrator field the least-significant bit is 141 defined as the 'C' (or copy) bit. When the 'C' bit is set the 142 redirection applies to copies of the matching packets and not to the 143 original traffic stream. 145 All bits other than the 'C' bit in the local administrator field 146 MUST be set to 0 by the originating BGP speaker and ignored by 147 receiving BGP speakers. 149 When a BGP speaker receives a flow-spec route with a 'redirect to 150 IP' extended community and this route represents the one and only 151 best path, it installs a traffic filtering rule that matches the 152 packets described by the NLRI field and redirects them (C=0) or 153 copies them (C=1) towards the IPv4 or IPv6 address in the extended 154 community's global administrator field (the 'target address'). The 155 BGP speaker is expected to do a longest-prefix-match lookup of the 156 'target address' in its forwarding information base (FIB) and 157 forward the redirected/copied packets based on the resulting route 158 (the 'target route'). If the 'target route' has multiple ECMP next- 159 hops the redirected/copied packets SHOULD be load-shared across 160 these next-hops according to the router's ECMP configuration. If the 161 'target route' has one or more tunnel next-hops then the appropriate 162 encapsulations SHOULD be added to the redirected/copied packets. If 163 the 'target address' is invalid or unreachable then the extended 164 community SHOULD be ignored. 166 If a BGP speaker receives a flow-spec route with multiple 'redirect 167 to IP' extended communities and this route represents the one and 168 only best path, it SHOULD load-share the redirected/copied packets 169 across all the 'target addresses' according to its ECMP 170 configuration. If the BGP speaker is not capable of redirecting and 171 copying the same packet it SHOULD ignore the extended communities 172 with C=0. If the BGP speaker is not capable of redirecting/copying a 173 packet towards multiple 'target addresses' it SHOULD 174 deterministically select one 'target address' and ignore the others. 176 If a BGP speaker receives multiple flow-spec routes for the same 177 flow-spec NLRI and all of them are considered best and usable paths 178 according to the BGP speaker's multipath configuration and each one 179 carries one or more 'redirect to IP' extended communities, the BGP 180 speaker SHOULD load-share the redirected/copied packets across all 181 the 'target addresses', with the same fallback rules as discussed in 182 the previous paragraph. Note that this situation does not require 183 the BGP speaker to have multiple peers - i.e. Add-Paths could be 184 used for the flow-spec address family. 186 If a BGP speaker receives a flow-spec route with one or more 187 'redirect to IP' extended communities and one or more 'redirect to 188 VRF' extended communities, and this route represents the one and 189 only best path, the 'redirect to IP' actions described above should 190 be applied in the context of the 'target VRF' matching the 'redirect 191 to VRF' extended community - i.e. the 'target addresses' should be 192 looked up in the FIB of the 'target VRF'. If there are multiple 193 'redirect to VRF' extended communities in the route the 'target VRF' 194 SHOULD be the one that matches the 'redirect to VRF' extended 195 community with the highest numerical value. If the BGP speaker is 196 not capable of 'redirect to VRF' followed by 'redirect to IP' then 197 it SHOULD give preference to performing the 'redirect to VRF' action 198 and doing only longest-prefix-match forwarding in the 'target VRF'. 200 If a BGP speaker receives multiple flow-spec routes for the same 201 flow-spec NLRI and all of them are considered best and usable paths 202 according to the BGP speaker's multipath configuration and they 203 carry a combination of 'redirect to IP' and 'redirect to VRF' 204 extended communities, the BGP speaker SHOULD apply the 'redirect to 205 IP' actions in the context of the 'target VRF' as described above. 206 Note that this situation does not require the BGP speaker to have 207 multiple peers - i.e. Add-Paths could be used for the flow-spec 208 address family. 210 3.1. Validation Procedures 212 The validation check described in [RFC 5575] and revised in 213 [VALIDATE] SHOULD be applied by default to received flow-spec routes 214 with a 'redirect to IP' extended community, as it is to all types of 215 flow-spec routes. This means that a flow-spec route with a 216 destination prefix subcomponent SHOULD NOT be accepted from an EBGP 217 peer unless that peer also advertised the best path for the matching 218 unicast route. 220 BGP speakers that support the extended communities defined in this 221 draft MUST also, by default, enforce the following check when 222 receiving a flow-spec route from an EBGP peer: if the received flow- 223 spec route has a 'redirect to IP' extended community with a 'target 224 address' X (in the global administrator field) and the best matching 225 route to X is not a BGP route with origin AS matching the peer AS 226 then the extended community should be discarded and not propagated 227 along with the flow-spec route to other peers. It MUST be possible 228 to disable this additional validation check on a per-EBGP session 229 basis. 231 4. Security Considerations 233 A system that originates a flow-spec route with a 'redirect to IP' 234 extended community can cause many receivers of the flow-spec route 235 to send traffic to a single next-hop, overwhelming that next-hop and 236 resulting in inadvertent or deliberate denial-of-service. This is 237 particularly a concern when the 'redirect to IP' extended community 238 is allowed to cross AS boundaries. The validation check described in 239 section 3.1 significantly reduces this risk. 241 5. IANA Considerations 243 This document requests a new sub-type from the "Transitive IPv4- 244 Address-Specific" extended community registry. The sub-type name 245 shall be 'Flow-spec Redirect to IPv4'. 247 This document requests a new sub-type from the "Transitive IPv6- 248 Address-Specific" extended community registry. The sub-type name 249 shall be 'Flow-spec Redirect to IPv6'. 251 IANA is requested to deprecate the type 0x0800 type/sub-type. 253 6. References 255 6.1. Normative References 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, March 1997. 260 6.2. Informative References 262 [RFC5575] P. Marques, N. Sheth, R. Raszuk, B. Greene, J. 263 Mauch, D. McPherson, "Dissemination of Flow 264 Specification Rules", RFC 5575, August 2009. 266 [IPV6-FLOW] R. Raszuk, B. Pithawala, D. McPherson, 267 "Dissemination of Flow Specification Rules for 268 IPv6", draft-ietf-idr-flow-spec-v6-00, June 2011. 270 [VALIDATE] Uttaro, J., Filsfils, C., Mohapatra, P., Smith, D., 271 "Revised Validation Procedure for BGP Flow 272 Specifications", draft-ietf-idr-bgp-flowspec-oid- 273 00, June 2012. 275 7. Contributors 277 David Smith 278 Cisco 279 111 Wood Avenue South 280 Iselin, NJ 08830 281 USA 282 E-mail: djsmith@cisco.com 284 8. Acknowledgments 286 The authors would like to thank Han Nguyen and Robert Raszuk for 287 their feedback and suggestions. 289 This document was prepared using 2-Word-v2.0.template.dot. 291 Authors' Addresses 293 James Uttaro 294 AT&T 295 200 S. Laurel Avenue 296 Middletown, NJ 07748 297 USA 298 Email: ju1738@att.com 300 Jeffrey Haas 301 Juniper Networks 302 1194 N. Mathida Ave. 303 Sunnyvale, CA 94089 304 USA 305 Email: jhaas@juniper.net 307 Andy Karch 308 Cisco Systems 309 170 West Tasman Drive 310 San Jose, CA 95134 311 USA 312 Email: akarch@cisco.com 314 Saikat Ray 315 Cisco Systems, Inc. 316 170, West Tasman Drive 317 San Jose, CA 95134 318 USA 319 Email: sairay@cisco.com 321 Pradosh Mohapatra 322 Cumulus Networks 323 Email: pmohapat@cumulusnetworks.com 325 Wim Henderickx 326 Alcatel-Lucent 327 Copernicuslaan 50 328 2018 Antwerp, Belgium 329 Email: wim.henderickx@alcatel-lucent.be 331 Adam Simpson 332 Alcatel-Lucent 333 600 March Road 334 Ottawa, Ontario K2K 2E6 335 Canada 336 Email: adam.simpson@alcatel-lucent.com 337 Matthieu Texier 338 Arbor Networks 339 38 Rue de Berri 340 75008 Paris 341 Email: mtexier@arbor.net