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