idnits 2.17.1 draft-hao-idr-flowspec-redirect-tunnel-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([MPP], [TUNNELENCAPS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 128: '...r than the 'C' bit MUST be set to 0 by...' RFC 2119 keyword, line 138: '... MUST be encoded in the Remote Endpi...' RFC 2119 keyword, line 139: '...mber in the sub-TLV MUST be the number...' RFC 2119 keyword, line 151: '... community MUST have at least one BG...' RFC 2119 keyword, line 170: '... extended community SHOULD be ignored....' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 6, 2015) is 3123 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) -- Looks like a reference, but probably isn't: 'TUNNELENCAPS' on line 242 -- Looks like a reference, but probably isn't: 'MPP' on line 148 -- Looks like a reference, but probably isn't: 'RFC 5575' on line 238 -- Looks like a reference, but probably isn't: 'VALIDATE' on line 239 == Unused Reference: '1' is defined on line 283, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 287, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 291, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 295, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5575 (ref. '1') (Obsoleted by RFC 8955) == Outdated reference: A later version (-03) exists of draft-rosen-idr-tunnel-encaps-00 == Outdated reference: A later version (-04) exists of draft-li-idr-mpls-path-programming-01 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDR Working Group W. Hao 2 Z. Li 3 Y. Lucy 4 Internet Draft Huawei 5 Intended status: Standards Track 7 Expires: March 2016 October 6, 2015 9 BGP Flow-Spec Redirect to Tunnel action 10 draft-hao-idr-flowspec-redirect-tunnel-00.txt 12 Abstract 14 This draft defines a new flow-spec action, redirect-to-Tunnel, and a 15 new sub-TLV for the redirect extended community to provide 16 redirecting a flow to a tunnel. A BGP UPDATE for a flow-spec NLRI 17 can contain the extended community. When activated, the 18 corresponding flow packets will be encapsulated by a tunnel 19 encapsulation protocol and then be forward to the target IP address. 20 The redirected tunnel information and target IP address are encoded 21 in BGP Path Attribute [TUNNELENCAPS] [MPP] that is carried in the 22 BGP flow-spec UPDATE. The draft expends the tunnel encapsulation 23 attribute to apply to flow-spec SAFI, i.e. 133 and 134. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as 38 reference material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described in 57 Section 4.e of the Trust Legal Provisions and are provided without 58 warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ................................................ 2 63 2. Redirect to Tunnel Extended Community........................ 3 64 2.1. Validation Procedures................................... 6 65 3. Security Considerations...................................... 6 66 4. IANA Considerations ......................................... 6 67 4.1. Normative References.................................... 7 68 4.2. Informative References.................................. 7 69 5. Acknowledgments ............................................. 7 71 1. Introduction 73 BGP Flow-spec is an extension to BGP that allows for the 74 dissemination of traffic flow specification rules. It leverages the 75 BGP Control Plane to simplify the distribution of ACLs, new filter 76 rules can be injected to all BGP peers simultaneously without 77 changing router configuration. The typical application of BGP Flow- 78 spec is to automate the distribution of traffic filter lists to 79 routers for DDOS mitigation. 81 Every flow-spec route consists of a matching part (encoded in the 82 NLRI field) and an action part(encoded in one or more BGP extended 83 communities). The flow-spec standard [RFC 5575] defines widely-used 84 filter actions such as discard and rate limit; it also defines a 85 redirect-to-VRF action for policy-based forwarding. [Redirect to IP] 86 defines a new redirect-to-IP flow-spec action that provides a 87 simpler method of policy-based forwarding. In some cases like 88 service chaining, traffic steering and etc, the traffic needs to be 89 redirected to tunnel directly. Using the redirect-to-VRF action or 90 redirect-to-IP action for this will be complex and cumbersome. 92 This draft proposes a new redirect-to-tunnel flow-spec action that 93 provides a straightforward solution for policy-based forwarding. The 94 details of the redirected tunnel information are encoded in already 95 existing defined BGP Path Attributes. 97 2. Redirect to Tunnel Extended Community 99 To support ''Redirect to Tunnel'', besides the extended communities in 100 below per RFC5575, a new extended community of ''Redirect to Tunnel'' 101 is defined by this draft. This redirect extended community allows 102 the traffic to be redirected to a set of tunnel(s) that are 103 specified by BGP Tunnel Encapsulation Attribute [TUNNELENCAPS] 104 and/or BGP Extended Unicast Tunnel Attribute [MPP]. 106 +--------+--------------------+--------------------------+ 107 | type | extended community | RFC or Draft | 108 +--------+--------------------+--------------------------+ 109 | 0x8006 | traffic-rate | RFC5575 | 110 | 0x8007 | traffic-action | RFC5575 | 111 | 0x8008 | redirect | RFC5575 | 112 | 0x8009 | traffic-marking | RFC5575 | 113 | TBD | redirect to Tunnel | This draft | 114 +--------+--------------------+--------------------------+ 116 The new extended community for ''Redirect to Tunnel'' has a type 117 indicating it is transitive and ''Redirect to Tunnel'' [to be assigned 118 by IANA]. The sub-TLV has following format. 120 40 41 42 43 44 45 46 47 121 +---+---+---+---+---+---+---+---+ 122 | reserved | C | 123 +---+---+---+---+---+---+---+---+ 125 In this value field (6 bytes) the least-significant bit is defined 126 as the 'C' (or copy) bit. When the 'C' bit is set the redirection 127 applies to copies of the matching packets and not to the original 128 traffic stream. All bits other than the 'C' bit MUST be set to 0 by 129 the originating BGP speaker and ignored by the receiving BGP 130 speakers. 132 This draft extends BGP Tunnel Encapsulation Attribute to apply to 133 BGP flow-spec SAFI, i.e., SAFI=133,134. When a tunnel is specified 134 by BGP Tunnel Encapsulation Attribute, the tunnel type and 135 encapsulation information such as VXLAN, NVGRE, VXLAN-GPE are 136 encoded in the Tunnel Encapsulation Attribute Sub-TLVs. When 137 applying it to flow-spec safi, the target IP address, IPv4 or IPv6 138 MUST be encoded in the Remote Endpiont Sub-TLV with the 139 corresponding AFI. The AS number in the sub-TLV MUST be the number 140 of the AS to which the target IP address in the sub-TLV belongs. If 141 the redirect to tunnel end point is the BGP next hop, the AFI in the 142 sub-TLV should be filled with zero, and the address in the sub-TLV 143 should be omitted, and AS field should be filled with zero. 145 When a tunnel is specified by BGP Extended Unicast Tunnel Attribute 146 [MPP], the tunnel type and encapsulation information such as RSVP-TE, 147 LDP, Segment Routing Path are encoded in BGP Extended Unicast Tunnel 148 Attributes ([MPP]). 150 The flow-spec UPDATE carries the ''Redirect to Tunnel'' extended 151 community MUST have at least one BGP Path Attribute that specifies a 152 set of tunnel(s) that the flow packets can be redirected to. 154 The following of this Section specifies a flow-spec to be redirect 155 to the tunnel that is specified by BGP tunnel encapsulation 156 attribute [TUNNELENCAPS]. A flow-spec to be redirected to a tunnel 157 that is specified by the BGP extended unicast tunnel attribute will 158 be addressed in future version. 160 When a BGP speaker receives a flow-spec route with a 'redirect to 161 Tunnel' extended community and this route represents the one and 162 only best path, it installs a traffic filtering rule that matches 163 the packets described by the NLRI field and redirects them (C=0) or 164 copies them (C=1) towards the target IPv4 or IPv6 address encoded in 165 Remote Endpoint sub-TLV of Tunnel Encapsulation Attribute. The BGP 166 speaker is expected to do a longest-prefix-match lookup of the 167 'target address' in its forwarding information base (FIB) and 168 forward the tunneled redirected/copied packets based on the 169 resulting route (the 'target route'). If the 'target address' is 170 invalid or unreachable then the extended community SHOULD be ignored. 172 If a BGP speaker receives a flow-spec route with one 'Redirect to 173 Tunnel' extended community and one BGP Tunnel Encapsulation 174 Attribute that represents a set of tunnels to the same target 175 address, and all of them are considered best and usable paths 176 according to the BGP speaker's multipath configuration, the BGP 177 speaker SHOULD load-share the redirected packets across all the 178 tunnels. If the BGP speaker is not capable of redirecting and 179 copying the same packet it SHOULD ignore the extended communities 180 with C=0. If the BGP speaker is not capable of redirecting/copying a 181 packet towards multiple tunnels it SHOULD deterministically select 182 one tunnel to the 'target address' and ignore the others. 184 If a BGP speaker receives multiple flow-spec routes for the same 185 flow-spec NLRI and all of them are considered best and usable paths 186 according to the BGP speaker's multipath configuration and each one 187 carries one 'Redirect to Tunnel' extended community and one Tunnel 188 Encapsulation Attribute, the BGP speaker SHOULD load-share the 189 tunneled redirected/copied packets across all the tunnels, with the 190 same fallback rules as discussed in the previous paragraph. Note 191 that this situation does not require the BGP speaker to have 192 multiple peers - i.e. Add-Paths could be used for the flow-spec 193 address family. 195 If a BGP speaker receives a flow-spec route with one 'Redirect to 196 Tunnel'' and one or more 'redirect to IP' extended communities; local 197 policy determines which 'redirect' should be used. 199 If a BGP speaker receives a flow-spec route with one 'Redirect to 200 Tunnel'' and one or more 'redirect to VRF' extended communities, and 201 this route represents the one and only best path, the 'Redirect to 202 Tunnel' actions described above should be applied in the context of 203 the 'target VRF' matching the 'redirect to VRF' extended community - 204 i.e. the 'target addresses' should be looked up in the FIB of the 205 'target VRF'. If there are multiple 'redirect to VRF' extended 206 communities in the route the 'target VRF' SHOULD be the one that 207 matches the 'redirect to VRF' extended community with the highest 208 numerical value. If the BGP speaker is not capable of 'redirect to 209 VRF' followed by 'Redirect to Tunnel' then it SHOULD give preference 210 to performing the 'redirect to VRF' action and doing only longest- 211 prefix-match forwarding in the 'target VRF'. 213 If a BGP speaker receives multiple flow-spec routes for the same 214 flow-spec NLRI and all of them are considered best and usable paths 215 according to the BGP speaker's multipath configuration and they 216 carry a combination of 'Redirect to Tunnel' and 'redirect to VRF' 217 extended communities, the BGP speaker SHOULD apply the 'Redirect to 218 Tunnel' actions in the context of the 'target VRF' as described 219 above. Note that this situation does not require the BGP speaker to 220 have multiple peers - i.e. Add-Paths could be used for the flow-spec 221 address family. 223 The redirected/copied flow packets will be encapsulated first. The 224 outer src address on the encapsulated packets MUST be filled with 225 the IP address of the forwarding router; the outer dst address on 226 the packets MUST be filled with the target IP address. If the flow 227 has multiple tunnels that have the 'target address' as remote tunnel 228 endpoint, the redirected/copied packets MAY be encapsulated 229 according to tunnel type and be load-shared across these tunnels 230 according to the router's ECMP configuration. 232 If the 'target route' has one or more tunnel next-hops then, in turn, 233 the tunneled redirect/copy packets SHOULD be encapsulated 234 appropriately again. 236 2.1. Validation Procedures 238 The validation check described in [RFC 5575] and revised in 239 [VALIDATE] SHOULD be applied by default to received flow-spec routes 240 with a 'redirect to tunnel' extended community, as it is to all 241 types of flow-spec routes and the validation check described in 242 [TUNNELENCAPS] SHOULD be applied to the tunnel encapsulation 243 attribute. This means that a flow-spec route with a destination 244 prefix subcomponent SHOULD NOT be accepted from an EBGP peer unless 245 that peer also advertised the best path for the matching unicast 246 route. 248 BGP speakers that support the extended communities defined in this 249 draft MUST also, by default, enforce the following check when 250 receiving a flow-spec route from an EBGP peer: if the received flow- 251 spec route has a 'redirect to tunnel' extended community with a 252 'target address' X (in the remote endpoint sub-TLV) and the best 253 matching route to X is not a BGP route with origin AS matching the 254 peer AS then the extended community should be discarded and not 255 propagated along with the flow-spec route to other peers. It MUST be 256 possible to disable this additional validation check on a per-EBGP 257 session basis. 259 3. Security Considerations 261 A system that originates a flow-spec route with a 'redirect to 262 tunnel' extended community can cause many receivers of the flow-spec 263 route to send traffic to a single next-hop, overwhelming that next- 264 hop and resulting in inadvertent or deliberate denial-of-service. 265 This is particularly a concern when the 'redirect to tunnel' 266 extended community is allowed to cross AS boundaries. The validation 267 check described in section 2.1 significantly reduces this risk. 269 4. IANA Considerations 271 IANA is requested to update the reference for the following 272 assignment in the "BGP Extended Communities Type/sub-Type for 273 'Redirect to Tunnel' that is specified in this draft. 275 4.1. Normative References 277 [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 4.2. Informative References 283 [1] [RFC5575] P. Marques, N. Sheth, R. Raszuk, B. Greene, J.Mauch, 284 D. McPherson, "Dissemination of Flow Specification Rules", RFC 285 5575, August 2009. 287 [2] [Redirect to IP] J.Uttaro, etc, " BGP Flow-Spec Redirect to IP 288 Action ", draft-ietf-idr-flowspec-redirect-ip-02, February 289 2015. 291 [3] [TUNNELENCAPS] E. Rosen, etc, " Using the BGP Tunnel 292 Encapsulation Attribute without the BGP Encapsulation SAFI ", 293 draft-rosen-idr-tunnel-encaps-00, June 2015. 295 [4] [MPP] Z. Li, etc, " BGP Extensions for Service-Oriented MPLS 296 Path Programming (MPP) ", draft-li-idr-mpls-path-programming- 297 01, March 2015. 299 5. Acknowledgments 301 The authors wish to acknowledge the important contributions of 302 Shunwan Zhuang, Qiandeng Liang. 304 Authors' Addresses 306 Weiguo Hao 307 Huawei Technologies 308 101 Software Avenue, 309 Nanjing 210012 310 China 311 Email: haoweiguo@huawei.com 313 Zhenbin Li 314 Huawei Technologies 315 Huawei Bld., No.156 Beiqing Rd. 316 Beijing 100095 317 China 318 Email: lizhenbin@huawei.com 320 Lucy Yong 321 Huawei Technologies 322 Phone: +1-918-808-1918 323 Email: lucy.yong@huawei.com