idnits 2.17.1 draft-ietf-idr-flowspec-interfaceset-05.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 : ---------------------------------------------------------------------------- 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 (November 18, 2019) is 1621 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) == Outdated reference: A later version (-27) exists of draft-ietf-idr-rfc5575bis-17 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing S. Litkowski 3 Internet-Draft Individual 4 Intended status: Standards Track A. Simpson 5 Expires: May 21, 2020 Nokia 6 K. Patel 7 Arrcus, Inc 8 J. Haas 9 Juniper Networks 10 L. Yong 11 Huawei 12 November 18, 2019 14 Applying BGP flowspec rules on a specific interface set 15 draft-ietf-idr-flowspec-interfaceset-05 17 Abstract 19 The BGP Flow Specification (flowspec) Network Layer Reachability 20 Information (BGP NLRI) extension (draft-ietf-idr-rfc5575bis) is used 21 to distribute traffic flow specifications into BGP. The primary 22 application of this extension is the distribution of traffic 23 filtering policies for the mitigation of distributed denial of 24 service (DDoS) attacks. 26 By default, flow specification filters are applied on all forwarding 27 interfaces that are enabled for use by the BGP flowspec extension. A 28 network operator may wish to apply a given filter selectively to a 29 subset of interfaces based on an internal classification scheme. 30 Examples of this include "all customer interfaces", "all peer 31 interfaces", "all transit interfaces", etc. 33 This document defines BGP Extended Communities (RFC4360) that allow 34 such filters to be selectively applied to sets of forwarding 35 interfaces sharing a common group identifier. The BGP Extended 36 Communities carrying this group identifier are referred to as the BGP 37 Flowspec "interface-set" Extended Communities. 39 Requirements Language 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 43 "OPTIONAL" in this document are to be interpreted as described in BCP 44 14 [RFC2119] [RFC8174] when, and only when, they appear in all 45 capitals, as shown here. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at https://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on May 21, 2020. 64 Copyright Notice 66 Copyright (c) 2019 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (https://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 82 2. Interface specific filtering using BGP flowspec . . . . . . . 3 83 3. Interface-set extended community . . . . . . . . . . . . . . 5 84 4. Scaling of per-interface rules . . . . . . . . . . . . . . . 6 85 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 86 5.1. Add-Paths . . . . . . . . . . . . . . . . . . . . . . . . 6 87 5.2. Inter-domain Considerations . . . . . . . . . . . . . . . 6 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 91 8.1. FlowSpec Transitive Extended Communities . . . . . . . . 7 92 8.2. FlowSpec Non-Transitive Extended Communities . . . . . . 7 93 8.3. FlowSpec interface-set Extended Community . . . . . . . . 8 94 8.4. Allocation Advice to IANA . . . . . . . . . . . . . . . . 8 96 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 99 1. Use case 101 While a network may provide connectivity to a homogenous class of 102 users, it often provides connectivity to different groups of users. 103 The nature of these different groups, and how they're classified, 104 varies based on the purpose of the network. In an enterprise 105 network, connectivity may exist between data centers, offices, and 106 external connectivity. In a virtual private networking (VPN) 107 network, it may consist of customers in different sites connected 108 through a VPN, the provider core network, and external networks such 109 as the Internet. In a traditional Internet service provider (ISP) 110 network, the network may consist of points of presence (POPs), 111 internal infrastructure networks, customer networks, peer networks, 112 and transit networks. 114 The BGP flowspec extension permits traffic filters to be distributed 115 to routers throughout a network. However, these filters often should 116 not be uniformly applied to all network interfaces. As an example, a 117 rate-limiting filter applied to the SMTP protocol may be applied to 118 customer networks, but not other networks. Similarly, a DDoS attack 119 on the SSH protocol may be deemed appropriate to drop at upstream 120 peering routers but not customer routers. 122 By default, BGP flowspec filters are applied at all interfaces that 123 permit flowspec filters to be installed. What is needed is a way to 124 selectively apply those filters to subsets of interfaces in a 125 network. 127 2. Interface specific filtering using BGP flowspec 129 The uses case detailed above require application of different BGP 130 flowspec rules on different sets of interfaces. 132 We propose to introduce, within BGP flowspec, a traffic filtering 133 scope that identifies a group of interfaces where a particular filter 134 should be applied. Identification of interfaces within BGP flowspec 135 will be done through group identifiers. A group identifier marks a 136 set of interfaces sharing a common administrative property. Like a 137 BGP community, the group identifier itself does not have any 138 significance. It is up to the network administrator to associate a 139 particular meaning to a group identifier value (e.g. group ID#1 140 associated to Internet customer interfaces). The group identifier is 141 a local interface property. Any interface may be associated with one 142 or more group identifiers using manual configuration. 144 When a filtering rule advertised through BGP flowspec must be applied 145 only to particular sets of interfaces, the BGP flowspec BGP UPDATE 146 will contain the identifiers associated with the relevant sets of 147 interfaces. In addition to the group identifiers, it will also 148 contain the direction the filtering rule must be applied in (see 149 Section 3). 151 Configuration of group identifiers associated to interfaces may 152 change over time. An implementation MUST ensure that the filtering 153 rules (learned from BGP flowspec) applied to a particular interface 154 are always updated when the group identifier mapping is changing. 156 As an example, we can imagine the following design : 158 o Internet customer interfaces are associated with group-identifier 159 1. 161 o VPN customer interfaces are associated with group-identifier 2. 163 o All customer interfaces are associated with group-identifier 3. 165 o Peer interfaces are associated with group-identifier 4. 167 o Transit interfaces are associated with group-identifier 5. 169 o All external provider interfaces are associated with group- 170 identifier 6. 172 o All interfaces are associated with group-identifier 7. 174 If the service provider wants to deploy a specific inbound filtering 175 on external provider interfaces only, the provider can send the BGP 176 flow specification using group-identifier 6 for the inbound 177 direction. 179 There are some cases where nodes are dedicated to specific functions 180 (Internet peering, Internet Edge, VPN Edge, Service Edge ...), in 181 this kind of scenario, there is an interest for a constrained 182 distribution of filtering rules that are using the interface specific 183 filtering. Without the constrained route distribution, all nodes 184 will received all the filters even if they are not interested in 185 those filters. Constrained route distribution of flowspec filters 186 would allow for a more optimized distribution. 188 3. Interface-set extended community 190 This document proposes a new BGP Route Target extended community 191 called the "flowspec interface-set". This document expands the 192 definition of the Route Target extended community to allow a new 193 value of high order octet (Type field) to be 0x07 for the transitive 194 flowspec interface-set extended community, or 0x47 for the non- 195 transitive flowspec interface-set extended community. These are in 196 addition to the values specified in [RFC4360]. 198 This new BGP Route Target extended community is encoded as follows : 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | 0x07 or 0x47 | 0x02 | Autonomous System Number : 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 : AS Number (cont.) |O|I| Group Identifier | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 The flags are : 210 o O : if set, the flow specification rule MUST be applied in 211 outbound direction to the interface set referenced by the 212 following group-identifier. 214 o I : if set, the flow specification rule MUST be applied in inbound 215 direction to the interface set referenced by the following group- 216 identifier. 218 Both flags can be set at the same time in the interface-set extended 219 community leading to flow rule to be applied in both directions. An 220 interface-set extended community with both flags set to zero MUST be 221 treated as an error and as consequence, the flowspec update MUST be 222 discarded. As having no direction indicated as no sense, there is no 223 need to propagate the filter informations in the network. 225 The Group Identifier is encoded as a 14-bit number, values 0..16383. 227 Multiple instances of the interface-set extended community may be 228 present in a BGP update. This may occur if the flowspec rule needs 229 to be applied to multiple sets of interfaces. 231 Multiple instances of the extended community in a BGP update MUST be 232 interpreted as a "OR" operation. For example, if a BGP UPDATE 233 contains two interface-set extended communities with group ID 1 and 234 group ID 2, the filter would need to be installed on interfaces 235 belonging to Group ID 1 or Group ID 2. 237 Similar to using a Route Target extended community, route 238 distribution of flowspec NLRI with interface-set extended communities 239 may be subject to constrained distribution as defined in [RFC4684]. 241 4. Scaling of per-interface rules 243 In the absence of an interface-set extended community, a flowspec 244 filter is applied to all flowspec enabled interfaces. When 245 interface-set extended communities are present, different interfaces 246 may have different filtering rules, with different terms and actions. 247 These differing rules may make it harder to share forwarding 248 instructions within the forwarding plane. 250 Flowspec implementations supporting the interface-set extended 251 community SHOULD take care to minimize the scaling impact in such 252 circumstances. How this is accomplished is out of the scope of this 253 document. 255 5. Deployment Considerations 257 5.1. Add-Paths 259 There are some cases where a particular BGP flowspec NLRI may be 260 advertised to different interface groups with a different action. 261 For example, a service provider may want to discard all ICMP traffic 262 from customer interfaces to infrastructure addresses and want to 263 rate-limit the same traffic when it comes from some internal 264 platforms. These particular cases require ADD-PATH ([RFC7911]) to be 265 deployed in order to ensure that all paths (NLRI+interface-set group- 266 id+actions) are propagated within the BGP control plane. Without 267 ADD-PATH, only a single "NLRI+interface-set group-id+actions" will be 268 propagated, so some filtering rules will never be applied. 270 5.2. Inter-domain Considerations 272 The Group Identifier used by the interface-set extended community has 273 local significance to its provisioning Autonomous System. While 274 [I-D.ietf-idr-rfc5575bis] permits inter-as advertisement of flowspec 275 NLRI, care must be taken to not accept these communities when they 276 would result in unacceptable filtering policies. 278 Filtering of interface-set extended communities at Autonomous System 279 border routers (ASBRs) may thus be desirable. 281 Note that the default behavior without the interface-set feature 282 would to have been to install the flowspec filter on all flowspec 283 enabled interfaces. 285 6. Security Considerations 287 This document extends the Security Considerations of 288 [I-D.ietf-idr-rfc5575bis] by permitting flowspec filters to be 289 selectively applied to subsets of network interfaces in a particular 290 direction. Care must be taken to not permit the inadvertant 291 manipulation of the interface-set extended community to bypass 292 expected traffic manipulation. 294 7. Acknowledgements 296 Authors would like to thanks Wim Hendrickx and Robert Raszuk for 297 their valuable comments. 299 8. IANA Considerations 301 8.1. FlowSpec Transitive Extended Communities 303 This document requests a new type from the "BGP Transitive Extended 304 Community Types" extended community registry from the First Come 305 First Served range. This type name shall be 'FlowSpec Transitive 306 Extended Communities'. IANA has assigned the value 0x07 to this 307 type. 309 This document requests creation of a new registry called "FlowSpec 310 Transitive Extended Community Sub-Types". This registry contains 311 values of the second octet (the "Sub-Type" field) of an extended 312 community when the value of the first octet (the "Type" field) is the 313 value allocated in this document. The registration procedure for 314 values in this registry shall be First Come First Served. 316 8.2. FlowSpec Non-Transitive Extended Communities 318 This document requests a new type from the "BGP Non-Transitive 319 Extended Community Types" extended community registry from the First 320 Come First Served range. This type name shall be 'FlowSpec Non- 321 Transitive Extended Communities'. IANA has assigned the value 0x47 322 to this type. 324 This document requests creation of a new registry called "FlowSpec 325 Non-Transitive Extended Community Sub-Types". This registry contains 326 values of the second octet (the "Sub-Type" field) of an extended 327 community when the value of the first octet (the "Type" field) is the 328 value allocated in this document. The registration procedure for 329 values in this registry shall be First Come First Served. 331 8.3. FlowSpec interface-set Extended Community 333 Within the two new registries above, this document requests a new 334 subtype (suggested value 0x02). This sub-type shall be named 335 "interface-set", with a reference to this document. 337 8.4. Allocation Advice to IANA 339 IANA is requested to allocate the values of the FlowSpec Transitive 340 and Non-Transitive Extended Communities such that their values are 341 identical when ignoring the second high-order bit (Transitive). See 342 section 2, [RFC4360]. 344 It is suggested to IANA that, when possible, allocations from the 345 FlowSpec Transitive/Non-Transitive Extended Community Sub-Types 346 registries are made for transitive or non-transitive versions of 347 features (section 2, [RFC4360]) that their code point in both 348 registries is identical. 350 9. Normative References 352 [I-D.ietf-idr-rfc5575bis] 353 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 354 Bacher, "Dissemination of Flow Specification Rules", 355 draft-ietf-idr-rfc5575bis-17 (work in progress), June 356 2019. 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, 360 DOI 10.17487/RFC2119, March 1997, 361 . 363 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 364 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 365 February 2006, . 367 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 368 R., Patel, K., and J. Guichard, "Constrained Route 369 Distribution for Border Gateway Protocol/MultiProtocol 370 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 371 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 372 November 2006, . 374 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 375 "Advertisement of Multiple Paths in BGP", RFC 7911, 376 DOI 10.17487/RFC7911, July 2016, 377 . 379 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 380 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 381 May 2017, . 383 Authors' Addresses 385 Stephane Litkowski 386 Individual 388 Email: slitkows.ietf@gmail.com 390 Adam Simpson 391 Nokia 393 Email: adam.1.simpson@nokia.com 395 Keyur Patel 396 Arrcus, Inc 398 Email: keyur@arrcus.com 400 Jeffrey Haas 401 Juniper Networks 403 Email: jhaas@juniper.net 405 Lucy Yong 406 Huawei 408 Email: lucy.yong@huawei.com