idnits 2.17.1 draft-simpson-idr-flowspec-redirect-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2011) is 4677 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-2119' is mentioned on line 123, but not defined == Missing Reference: 'IPv6-FLOW' is mentioned on line 127, but not defined == Unused Reference: 'RFC2119' is defined on line 230, 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 (-04) exists of draft-ietf-idr-optional-transitive-03 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Wim Henderickx 2 Internet Draft Adam Simpson 3 Intended status: Standards Track Alcatel-Lucent 4 July 4, 2011 July 4, 2011 5 Expires: Jan 4, 2012 7 Generalized Redirect Action in BGP Flow Specification Routes 8 draft-simpson-idr-flowspec-redirect-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on Jan 4, 2012. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the BSD License. 48 Abstract 50 Flowspec is an extension to BGP that allows for the dissemination of 51 traffic flow specifications. This has several applications, but one 52 of key interest to many network operators is network-wide 53 distribution of traffic filtering rules as part of a threat 54 mitigation strategy. 56 Every flowspec route is effectively a rule, consisting of a matching 57 part (encoded in the NLRI field) and an action part. The current 58 standards support common filter actions including discard, rate 59 limit, sample, etc. and all of these actions are encoded in BGP 60 extended communities. For policy-based forwarding the current 61 standards also define a redirect-to-VRF action (again encoded in a 62 BGP extended community), but for some flowspec applications this can 63 be complex to implement, particularly in networks where L3 VPNs are 64 not prevalent. 66 This draft proposes a generalized flowspec redirect action that 67 allows a more complete set of policy-based forwarding actions to be 68 signaled with a flowspec route. This generalized action is encoded in 69 a BGP path attribute and uses a TLV-style encoding for future 70 extensibility. Two redirect action TLVs are defined in this draft: 71 one for redirecting matched packets towards a remote IPv4 destination 72 and the other for redirecting matched packets towards a remote IPv6 73 destination. Many routers already support these filter actions in the 74 datapath and so the proposed flowspec extensions are simply filling a 75 control plane gap. 77 Table of Contents 79 1. Introduction...................................................3 80 2. Terminology....................................................3 81 3. The Generalized Flowspec Redirect Attribute....................3 82 4. Security Considerations........................................5 83 5. IANA Considerations............................................5 84 6. References.....................................................6 85 6.1. Normative References......................................6 86 6.2. Informative References....................................6 87 7. Acknowledgments................................................6 89 1. Introduction 91 Flowspec is an extension to BGP that allows for the dissemination of 92 traffic flow specifications. This has several applications, but one 93 of key interest to many network operators is network-wide 94 distribution of traffic filtering rules as part of a threat 95 mitigation strategy. 97 Every flowspec route is effectively a rule, consisting of a matching 98 part (encoded in the NLRI field) and an action part. The current 99 standards support common filter actions including discard, rate 100 limit, sample, etc. and all of these actions are encoded in BGP 101 extended communities. For policy-based forwarding the current 102 standards also define a redirect-to-VRF action (again encoded in a 103 BGP extended community), but for some flowspec applications this can 104 be complex to implement, particularly in networks where L3 VPNs are 105 not prevalent. 107 This draft proposes a generalized flowspec redirect action that 108 allows a more complete set of policy-based forwarding actions to be 109 signaled with a flowspec route. This generalized action is encoded in 110 a BGP path attribute and uses a TLV-style encoding for future 111 extensibility. Two redirect action TLVs are defined in this draft: 112 one for redirecting matched packets towards a remote IPv4 destination 113 and the other for redirecting matched packets towards a remote IPv6 114 destination. Many routers already support these filter actions in the 115 datapath and so the proposed flowspec extensions are simply filling a 116 control plane gap. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC-2119]. 124 3. The Generalized Flowspec Redirect Attribute 126 All of the actions defined in the current flowspec standards, 127 [RFC5575] and [IPv6-FLOW], are encoded using BGP extended 128 communities. While it would be desirable to define new BGP extended 129 communities for the new types of redirect action called for in this 130 document the maximum length of extended communities (7 octets of 131 data) makes this very limiting. 133 This document therefore proposes a new BGP path attribute called the 134 Generalized Flowspec Redirect Attribute. It is a transitive, optional 135 attribute of non-extended length. The value field of the path 136 attribute contains exactly one Redirect Action TLV, which has the 137 structure shown in Figure 1. 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Type | Length | | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 144 | ~ 145 ~ Value | 146 | | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Redirect Action TLV 151 Figure 1 153 The Redirect Action TLV has the following fields: 155 - Type: A single octet encoding the TLV Type. Only type 1, "Remote 156 IPv4 Address", and type 2 "Remote IPv6 Address" are defined in this 157 document. 159 - Length: A single octet encoding the length in octets of the TLV, 160 including the type and length fields. The length is encoded as an 161 unsigned binary integer. 163 - Value: A value field that contains type-dependent data. In a type 1 164 "Remote IPv4 Address" TLV the value field contains a 4-octet AS value 165 followed by a 4-octet IPv4 address. In a type 2 "Remote IPv6 Address" 166 TLV the value field contains a 4-octet AS value followed by a 16- 167 octet IPv6 address. 169 When a system originates a flowspec route with the intent to redirect 170 matched packets to a remote IPv4 address, it includes a Generalized 171 Flowspec Redirect Attribute containing a "Remote IPv4 Address" 172 Redirect Action TLV (type 1). The AS number in the TLV MUST be the AS 173 number of the associated IPv4 address (this will typically be the 174 same as the originator's AS number) or 0, if the AS number is unknown 175 to the originator. A 2-octet ASN is encoded in the low-order 2 octets 176 of the AS number field. The IPv4 address in the TLV is any routable 177 /32 unicast IPv4 address. 179 When a system originates a flowspec route with the intent to redirect 180 matched packets to a remote IPv6 address, it includes a Generalized 181 Flowspec Redirect Attribute containing a "Remote IPv6 Address" 182 Redirect Action TLV (type 2). The AS number in the TLV MUST be the AS 183 number of the associated IPv6 address (this will typically be the 184 same as the originator's AS number) or 0, if the AS number is unknown 185 to the originator. A 2-octet ASN is encoded in the low-order 2 octets 186 of the AS number field. The IPv6 address in the TLV is any routable 187 /128 unicast IPv6 address. 189 A flowspec route MUST NOT have more than one Generalized Flowspec 190 Redirect Attribute. Error handling must follow the procedures 191 outlined in [OPT-TRANS]. 193 A flowspec route that has a Generalized Flowspec Redirect Attribute 194 in addition to one or more of the BGP extended community actions 195 defined in [RFC5575] and [IPV6-FLOW] is valid but implementations MAY 196 choose to ignore some or all of the BGP extended community actions 197 when installing a filter entry for this type of route. 199 A router that receives a flowspec route with a Generalized Flowspec 200 Redirect Attribute MAY check that the AS number in the Redirect 201 Action TLV (if non-zero) is the origin AS associated with its route 202 to the indicated remote IP address. In this case, if the AS numbers 203 are found to be different the router SHOULD NOT install a filter 204 entry for the flowspec route. 206 When a router receives and installs a flowspec route with a 207 Generalized Flowspec Redirect Attribute the resultant filter entry 208 should forward matched packets to the interface that is the IP next- 209 hop towards the signaled "Remote IPv4 Address" or "Remote IPv6 210 Address". The remote address may be any number of IP forwarding next- 211 hops away from the router installing the flowspec route. In certain 212 deployments the IP next-hop towards the remote IP address may be an 213 IP or MPLS tunnel. 215 4. Security Considerations 217 TBD 219 5. IANA Considerations 221 This document requests that IANA allocate a new BGP path attribute 222 type number for the Generalized Flowspec Redirect Attribute. IANA 223 should also establish and maintain a registry for Redirect Action 224 TLVs and indicate the meaning of type 1 and type 2 in this context. 226 6. References 228 6.1. Normative References 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, March 1997. 233 6.2. Informative References 235 [RFC5575] P. Marques, N. Sheth, R. Raszuk, B. Greene, J. 236 Mauch, D. McPherson, "Dissemination of Flow 237 Specification Rules", RFC 5575, August 2009. 239 [IPV6-FLOW] R. Raszuk, B. Pithawala, D. McPherson, 240 "Dissemination of Flow Specification Rules for 241 IPv6", draft-ietf-idr-flow-spec-v6-00, June 2011. 243 [OPT-TRANS] J. Scudder, E. Chen, "Error Handling for Optional 244 Transitive BGP Attributes", draft-ietf-idr-optional- 245 transitive-03, Sept 2010. 247 7. Acknowledgments 249 This document was prepared using 2-Word-v2.0.template.dot. 251 Authors' Addresses 253 Wim Henderickx 254 Alcatel-Lucent 255 Copernicuslaan 50 256 2018 Antwerp, Belgium 257 Email: wim.henderickx@alcatel-lucent.be 259 Adam Simpson 260 Alcatel-Lucent 261 600 March Road 262 Ottawa, Ontario K2K 2E6 263 Canada 264 Email: adam.simpson@alcatel-lucent.com