idnits 2.17.1 draft-simpson-idr-flowspec-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 ([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 -- Couldn't find a document date in the document -- date freshness check skipped. 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 189, but not defined ** Obsolete undefined reference: RFC 5575 (Obsoleted by RFC 8955) == Missing Reference: 'RFC-2119' is mentioned on line 111, but not defined == Unused Reference: 'RFC2119' is defined on line 234, but no explicit reference was found in the text == Unused Reference: 'RFC5575' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'IPV6-FLOW' is defined on line 243, 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 Network Working Group James Uttaro 2 Internet Draft AT&T 3 Intended status: Standards Track Matthieu Texier 4 Nov 26, 2012 Arbor Networks 5 Expires: May 26, 2013 David Smith 6 Pradosh Mohapatra 7 Cisco Systems 8 Wim Henderickx 9 Adam Simpson 10 Alcatel-Lucent 12 BGP Flow-Spec Extended Community for Traffic Redirect to IP Next Hop 13 draft-simpson-idr-flowspec-redirect-02.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on May 26, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 Flow-spec is an extension to BGP that allows for the dissemination 56 of traffic flow specification rules. This has many possible 57 applications but the primary one for many network operators is the 58 distribution of traffic filtering actions for DDoS mitigation. The 59 flow-spec standard [RFC 5575] defines a redirect-to-VRF action for 60 policy-based forwarding but this mechanism can be difficult to use, 61 particularly in networks without L3 VPNs. 63 This draft proposes a new redirect-to-IP flow-spec action that 64 provides a simpler method of policy-based forwarding. This action is 65 indicated by the presence of a new BGP extended community in the 66 flow-spec route. Many routers already support a redirect-to-IP 67 filter action and, in this case, the only new functionality implied 68 by this draft is the ability to signal the action using flow-spec. 70 Table of Contents 72 1. Introduction...................................................3 73 2. Terminology....................................................3 74 3. Redirect to IP Extended Community..............................3 75 4. Security Considerations........................................5 76 5. IANA Considerations............................................6 77 6. References.....................................................6 78 6.1. Normative References......................................6 79 6.2. Informative References....................................6 80 7. Acknowledgments................................................6 82 1. Introduction 84 Flow-spec is an extension to BGP that allows for the dissemination 85 of traffic flow specification rules. This has many possible 86 applications but the primary one for many network operators is the 87 distribution of traffic filtering actions for DDoS mitigation. 89 Every flow-spec route is effectively a rule, consisting of a 90 matching part (encoded in the NLRI field) and an action part 91 (encoded as a BGP extended community). The flow-spec standard [RFC 92 5575] defines widely-used filter actions such as discard and rate 93 limit; it also defines a redirect-to-VRF action for policy-based 94 forwarding. Using the redirect-to-VRF action for redirecting traffic 95 towards an alternate destination is useful for DDoS mitigation but 96 it can be complex and cumbersome, particularly in networks without 97 L3 VPNs. 99 This draft proposes a new redirect-to-IP flow-spec action that 100 provides a simpler method of policy-based forwarding. This action is 101 indicated by the presence of a new BGP extended community in the 102 flow-spec route. Many routers already support a redirect-to-IP 103 filter action and, in this case, the only new functionality implied 104 by this draft is the ability to signal the action using flow-spec. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC-2119]. 112 3. Redirect to IP Extended Community 114 This document proposes a new BGP extended community called "Flow 115 spec redirect/mirror to IP next-hop" with type value 0x0800 116 (assigned from the "BGP Extended Communities Type - extended, 117 transitive" registry). The new extended community, simply called 118 "redirect to IP" in the remainder of this document, can be added to 119 any UPDATE message announcing the reachability of one or more flow- 120 spec NLRI. The encoding of the attribute is shown in Figure 1. In 121 the 6 bytes of data after the 2-byte type value the least- 122 significant bit is the 'C' (copy) bit. If 'C' is equal to 1 the 123 originator of the flow-spec route is requesting a mirror action: 124 routers that install this flow-spec route should create a copy of 125 every matching packet and forward the copies towards a specified 126 next-hop address while still forwarding the original packets 127 normally (i.e. based on longest-prefix-match forwarding table 128 lookups). If 'C' is equal to 0 the originator of the flow-spec route 129 is requesting a simple redirect action: routers that install this 130 flow-spec route should forward the matching packets (the original 131 versions, not copies) towards a new next-hop address. All bits other 132 than the 'C' bit in the 6-byte data portion of the extended 133 community should be set to 0 by the originating BGP speaker and 134 ignored by receiving BGP speakers. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | 0x08 | 0x00 | Reserved | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Set to zero and | 141 | ignored on receipt) |C| 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Flow-spec Redirect/Mirror to IP Next-hop Extended Community 146 Figure 1 148 The redirect-to-IP extended community is valid with any other set of 149 flow-spec extended communities except if that set includes a 150 redirect-to-VRF extended community (type 0x8008) and in that case 151 the redirect-to-IP extended community should be ignored. 153 When a BGP speaker receives an UPDATE message with the redirect-to- 154 IP extended community it is expected to create a traffic filtering 155 rule for every flow-spec NLRI in the message that has this path as 156 its best path. The filter entry matches the IP packets described in 157 the NLRI field and redirects them (C=0) or copies them (C=1) towards 158 the IPv4 or IPv6 address specified in the 'Network Address of Next- 159 Hop' field of the associated MP_REACH_NLRI. More specifically: if an 160 IPv4 [or IPv6] packet with destination address D that is normally 161 forwarded to a next-hop A matches a filter entry of the type 162 described above it MUST instead be redirected (C=0) or mirrored 163 (C=1) to next-hop B, where B is found by FIB lookup of the IPv4 [or 164 IPv6] address contained in the MP_REACH_NLRI next-hop field (i.e. a 165 longest-prefix-match lookup). Signaling and applying constraints 166 beyond longest-prefix-match on the types of interfaces or tunnels 167 that can be used as the redirection next-hop B are not precluded by 168 this specification but are nevertheless outside its scope. 170 If an MP_REACH_NLRI containing one or more flow-spec NLRI does not 171 have a valid IPv4 or IPv6 address in its next-hop field, or the 172 length of the next-hop is 0, then the redirect-to-IP extended 173 community, if present, should be ignored. 175 The scope of application (in terms of router interfaces/contexts) of 176 the filter rules derived from the redirect-to-IP extended community 177 is outside the scope of this specification except for noting that 178 filter rules derived from VPNv4 and VPNv6 flow-spec routes should 179 only be installed in the VRF contexts that import the routes. 181 The redirect-to-IP extended community is transitive across AS 182 boundaries. When a flow-spec route with this community is advertised 183 to an EBGP peer the next-hop address in the MP_REACH_NLRI SHOULD be 184 reset to an address of the advertising router by default, per normal 185 BGP procedures. Alternatively, the advertising router MAY be 186 configured to keep the next-hop unchanged, if it is known that the 187 destination AS has a valid route to the next-hop address. 189 The validation check described in [RFC 5575] and revised in 190 [VALIDATE] SHOULD be applied by default to received flow-spec routes 191 with the redirect-to-IP extended community, as it is to all types of 192 flow-spec routes. This means that a flow-spec route with a 193 destination prefix subcomponent SHOULD NOT be accepted from an EBGP 194 peer unless that peer also advertised the best path for the matching 195 unicast route. BGP speakers that support the redirect-to-IP extended 196 community MUST also, by default, enforce the following check when 197 receiving a flow-spec route from an EBGP peer: 199 . If the flow-spec route has an IP next-hop X and includes a 200 redirect-to-IP extended community, then the BGP speaker 201 SHOULD discard the redirect-to-ip extended community (and 202 not propagate it further with the flow-spec route) if the 203 last AS in the AS_PATH or AS4_PATH attribute of the longest 204 prefix match for X does not match the AS of the EBGP peer. 206 It MUST be possible to disable this additional validation check on a 207 per-EBGP session basis. 209 4. Security Considerations 211 A system that originates a flow-spec route with a redirect-to-IP 212 extended community can cause many receivers of the flow-spec route 213 to send traffic to a single next-hop, overwhelming that next-hop and 214 resulting in inadvertent or deliberate denial-of-service. This is 215 particularly a concern when the redirect-to-IP extended community is 216 allowed to cross AS boundaries. The validation check described in 217 section 3 significantly reduces this risk. 219 5. IANA Considerations 221 IANA is requested to update the reference for the following 222 assignment in the "BGP Extended Communities Type - extended, 223 transitive" registry: 225 Type value Name Reference 226 ---------- ---------------------------------------- --------- 227 0x0800 Flow spec redirect/mirror to IP next-hop [this 228 document] 230 6. References 232 6.1. Normative References 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, March 1997. 237 6.2. Informative References 239 [RFC5575] P. Marques, N. Sheth, R. Raszuk, B. Greene, J. 240 Mauch, D. McPherson, "Dissemination of Flow 241 Specification Rules", RFC 5575, August 2009. 243 [IPV6-FLOW] R. Raszuk, B. Pithawala, D. McPherson, 244 "Dissemination of Flow Specification Rules for 245 IPv6", draft-ietf-idr-flow-spec-v6-00, June 2011. 247 [VALIDATE] Uttaro, J., Filsfils, C., Mohapatra, P., Smith, D., 248 "Revised Validation Procedure for BGP Flow 249 Specifications", draft-ietf-idr-bgp-flowspec-oid- 250 00, June 2012. 252 7. Acknowledgments 254 The authors would like to thank Han Nguyen and Robert Raszuk for 255 their feedback and suggestions. 257 This document was prepared using 2-Word-v2.0.template.dot. 259 Authors' Addresses 261 James Uttaro 262 AT&T 263 200 S. Laurel Avenue 264 Middletown, NJ 07748 265 USA 266 Email: ju1738@att.com 268 Pradosh Mohapatra 269 Cisco 270 170 W. Tasman Drive 271 San Jose, CA 95134 272 USA 273 Email: pmohapat@cisco.com 275 David Smith 276 Cisco 277 111 Wood Avenue South 278 Iselin, NJ 08830 279 USA 280 E-mail: djsmith@cisco.com 282 Wim Henderickx 283 Alcatel-Lucent 284 Copernicuslaan 50 285 2018 Antwerp, Belgium 286 Email: wim.henderickx@alcatel-lucent.be 288 Adam Simpson 289 Alcatel-Lucent 290 600 March Road 291 Ottawa, Ontario K2K 2E6 292 Canada 293 Email: adam.simpson@alcatel-lucent.com 295 Matthieu Texier 296 Arbor Networks 297 38 Rue de Berri 298 75008 Paris 299 Email: mtexier@arbor.net