idnits 2.17.1 draft-simpson-idr-flowspec-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 ([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 (July 16, 2012) is 4303 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 172, 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 209, but no explicit reference was found in the text == Unused Reference: 'RFC5575' is defined on line 214, but no explicit reference was found in the text == Unused Reference: 'IPV6-FLOW' is defined on line 218, 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 Jim Uttaro 2 Internet Draft AT&T 3 Intended status: Standards Track Matthieu Texier 4 July 16, 2012 Arbor Networks 5 Expires: Jan 16, 2013 David Smith 6 Pradosh Mohapatra 7 Cisco Systems 8 Wim Henderickx 9 Adam Simpson 10 Alcatel-Lucent 11 July 16, 2012 13 BGP Flow-Spec Extended Community for Traffic Redirect to IP Next Hop 14 draft-simpson-idr-flowspec-redirect-01.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on Jan 16, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Abstract 56 Flow-spec is an extension to BGP that allows for the dissemination of 57 traffic flow specification rules. This has many possible applications 58 but the primary one for many network operators is the distribution of 59 traffic filtering actions for DDoS mitigation. The flow-spec standard 60 [RFC 5575] defines a redirect-to-VRF action for policy-based 61 forwarding but this mechanism can be difficult to use, particularly 62 in networks without L3 VPNs. 64 This draft proposes a new redirect-to-IP flow-spec action that 65 provides a simpler method of policy-based forwarding. This action is 66 indicated by the presence of a new BGP extended community in the 67 flow-spec route. Many routers already support a redirect-to-IP filter 68 action and, in this case, the only new functionality implied by this 69 draft is the ability to signal the action using flow-spec. 71 Table of Contents 73 1. Introduction...................................................3 74 2. Terminology....................................................3 75 3. Redirect to IP Extended Community..............................3 76 4. Security Considerations........................................5 77 5. IANA Considerations............................................5 78 6. References.....................................................5 79 6.1. Normative References......................................5 80 6.2. Informative References....................................5 81 7. Acknowledgments................................................6 83 1. Introduction 85 Flow-spec is an extension to BGP that allows for the dissemination of 86 traffic flow specification rules. This has many possible applications 87 but the primary one for many network operators is the distribution of 88 traffic filtering actions for DDoS mitigation. 90 Every flow-spec route is effectively a rule, consisting of a matching 91 part (encoded in the NLRI field) and an action part (encoded as a BGP 92 extended community). The flow-spec standard [RFC 5575] defines 93 widely-used filter actions such as discard and rate limit; it also 94 defines a redirect-to-VRF action for policy-based forwarding. Using 95 the redirect-to-VRF action for redirecting traffic towards an 96 alternate destination is useful for DDoS mitigation but it can be 97 complex and cumbersome, particularly in networks without 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 filter 103 action and, in this case, the only new functionality implied by this 104 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 spec 115 redirect-to-IP". IANA is requested to allocate a type value of 0x800b 116 for this purpose. This extended community can be added to any UPDATE 117 message announcing the reachability of one or more flow-spec NLRI. 118 The encoding of the attribute is shown in Figure 1; the 6 bytes of 119 data after the 2-byte type value is a reserved field and should be 120 set to 0 by the originating BGP speaker and ignored by receiving BGP 121 speakers. 123 The redirect-to-IP extended community is valid with any other set of 124 flow-spec extended communities except if that set includes a 125 redirect-to-VRF extended community (type 0x8008) and in that case the 126 redirect-to-IP extended community should be ignored. 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | 0x80 | 0x0b | Reserved | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Set to zero and | 133 | ignored on receipt) | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Flow-spec Redirect-to-IP Extended Community 138 Figure 1 140 When a BGP speaker receives an UPDATE message with the redirect-to-IP 141 extended community it is expected to create a traffic filtering rule 142 for every flow-spec NLRI in the message that has this path as its 143 best path. The filter entry matches the IP packets described in the 144 NLRI field and forwards them towards the IPv4 or IPv6 address 145 specified in the 'Network Address of Next-Hop' field of the 146 associated MP_REACH_NLRI. More specifically: if an IPv4 [or IPv6] 147 packet with destination address D that is normally forwarded to a 148 next-hop A matches a filter entry of the type described above it MUST 149 instead be forwarded to next-hop B, where B is found by FIB lookup of 150 the IPv4 [or IPv6] address contained in the MP_REACH_NLRI next-hop 151 field. 153 If an MP_REACH_NLRI containing one or more flow-spec NLRI does not 154 have a valid IPv4 or IPv6 address in its next-hop field, or the 155 length of the next-hop is 0, then the redirect-to-IP extended 156 community, if present, should be ignored. 158 The scope of application (in terms of router interfaces/contexts) of 159 the filter rules derived from the redirect-to-IP extended community 160 is outside the scope of this specification except for noting that 161 filter rules derived from VPNv4 and VPNv6 flow-spec routes should 162 only be installed in the VRF contexts that import the routes. 164 The redirect-to-IP extended community is transitive across AS 165 boundaries. When a flow-spec route with this community is advertised 166 to an EBGP peer the next-hop address in the MP_REACH_NLRI SHOULD be 167 reset to an address of the advertising router by default, per normal 168 BGP procedures. Alternatively, the advertising router MAY be 169 configured to keep the next-hop unchanged, if it is known that the 170 destination AS has a valid route to the next-hop address. 172 The validation check described in [RFC 5575] and revised in 173 [VALIDATE] SHOULD be applied by default to received flow-spec routes 174 with the redirect-to-IP extended community, as it is to all types of 175 flow-spec routes. This means that a flow-spec route with a 176 destination prefix subcomponent SHOULD NOT be accepted from an EBGP 177 peer unless that peer also advertised the best path for the matching 178 unicast route. BGP speakers that support the redirect-to-IP extended 179 community MUST also, by default, enforce the following check when 180 receiving a flow-spec route from an EBGP peer: if the flow-spec route 181 has an IP next-hop X and includes a redirect-to-IP extended community 182 then the BGP speaker SHOULD discard the redirect-to-ip extended 183 community (and not propagate it further with the flow-spec route) if 184 the last AS in the AS_PATH or AS4_PATH attribute of the longest 185 prefix match for X does not match the AS of the EBGP peer. It MUST be 186 possible to disable this additional validation check on a per-EBGP 187 session basis. 189 4. Security Considerations 191 A system that originates a flow-spec route with a redirect-to-IP 192 extended community can cause many receivers of the flow-spec route to 193 send traffic to a single next-hop, overwhelming that next-hop and 194 resulting in an inadvertent or deliberate denial-of-service. This is 195 particularly a concern when the redirect-to-IP extended community is 196 allowed to cross AS boundaries. The validation check described in 197 section 3 significantly reduces this risk. 199 5. IANA Considerations 201 This document requests that IANA allocate a new experimental use 202 extended community type value in the range 0x8000-0x8FFF for the flow 203 spec redirect-to-IP action. The proposed type value is 0x800b. 205 6. References 207 6.1. Normative References 209 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 210 Requirement Levels", BCP 14, RFC 2119, March 1997. 212 6.2. Informative References 214 [RFC5575] P. Marques, N. Sheth, R. Raszuk, B. Greene, J. 215 Mauch, D. McPherson, "Dissemination of Flow 216 Specification Rules", RFC 5575, August 2009. 218 [IPV6-FLOW] R. Raszuk, B. Pithawala, D. McPherson, 219 "Dissemination of Flow Specification Rules for 220 IPv6", draft-ietf-idr-flow-spec-v6-00, June 2011. 222 [VALIDATE] Uttaro, J., Filsfils, C., Mohapatra, P., Smith, D., 223 "Revised Validation Procedure for BGP Flow 224 Specifications", draft-ietf-idr-bgp-flowspec-oid-00, 225 June 2012. 227 7. Acknowledgments 229 This document was prepared using 2-Word-v2.0.template.dot. 231 Authors' Addresses 233 James Uttaro 234 AT&T 235 200 S. Laurel Avenue 236 Middletown, NJ 07748 237 USA 238 Email: ju1738@att.com 240 Pradosh Mohapatra 241 Cisco 242 170 W. Tasman Drive 243 San Jose, CA 95134 244 USA 245 Email: pmohapat@cisco.com 247 David Smith 248 Cisco 249 111 Wood Avenue South 250 Iselin, NJ 08830 251 USA 252 E-mail: djsmith@cisco.com 254 Wim Henderickx 255 Alcatel-Lucent 256 Copernicuslaan 50 257 2018 Antwerp, Belgium 258 Email: wim.henderickx@alcatel-lucent.be 260 Adam Simpson 261 Alcatel-Lucent 262 600 March Road 263 Ottawa, Ontario K2K 2E6 264 Canada 265 Email: adam.simpson@alcatel-lucent.com 267 Matthieu Texier 268 Arbor Networks 269 38 Rue de Berri 270 75008 Paris 271 Email: mtexier@arbor.net