idnits 2.17.1 draft-ietf-idr-bgp-flowspec-oid-07.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 draft header indicates that this document updates RFC5575, but the abstract doesn't seem to directly say this. It does mention RFC5575 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5575, updated by this document, for RFC5378 checks: 2007-08-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 5, 2018) is 1992 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) == Unused Reference: 'RFC4456' is defined on line 341, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Uttaro 3 Internet-Draft AT&T 4 Updates: 5575 (if approved) J. Alcaide 5 Intended status: Standards Track C. Filsfils 6 Expires: May 9, 2019 D. Smith 7 Cisco 8 P. Mohapatra 9 Sproute Networks 10 November 5, 2018 12 Revised Validation Procedure for BGP Flow Specifications 13 draft-ietf-idr-bgp-flowspec-oid-07 15 Abstract 17 This document describes a modification to the validation procedure 18 defined in RFC 5575 for the dissemination of BGP flow specifications. 19 RFC 5575 requires that the originator of the flow specification 20 matches the originator of the best-match unicast route for the 21 destination prefix embedded in the flow specification. This allows 22 only BGP speakers within the data forwarding path (such as autonomous 23 system border routers) to originate BGP flow specifications. Though 24 it is possible to disseminate such flow specifications directly from 25 border routers, it may be operationally cumbersome in an autonomous 26 system with a large number of border routers having complex BGP 27 policies. The modification proposed herein enables flow 28 specifications to be originated from a centralized BGP route 29 controller. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 9, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 66 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Revised Validation Procedure . . . . . . . . . . . . . . . . 5 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Requirements Language 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 2. Motivation 83 Step (a) of the validation procedure in [RFC5575], section 6 is 84 defined with the underlying assumption that the flow specification 85 NLRI traverses the same path, in the inter-domain and intra-domain 86 route distribution graph, as that of the longest-match unicast route 87 for the destination prefix embedded in the flow specification. 89 In the case of inter-domain traffic filtering, for example, the flow 90 specification originator at the egress border routers of ASN1 (RTR-D 91 and RTR-E in figure 1) matches the EBGP neighbor that advertised the 92 longest match destination prefix (RTR-F and RTR-G respectively). 93 Similarly, at the ingress border routers of ASN1 (RTR-A and RTR-B in 94 figure 1), the flow specification originator matches the egress IBGP 95 border routers that had advertised the unicast route for the best- 96 match destination prefix (RTR-D and RTR-E respectively). This is 97 true even when ingress border routers select paths from different 98 egress border routers as best path based upon IGP distance (as an 99 example, RTR-A chooses RTR-D's path as best; RTR-B chooses RTR-E as 100 the best path). 102 / - - - - - - - - - - - - - - 103 | ASN1 | 104 +-------+ +-------+ 105 | | | | | | 106 | RTR-A | | RTR-B | 107 | | | | | | 108 +-------+ +-------+ 109 | \ / | 110 IBGP \ / IBGP 111 | \ / | 112 +-------+ 113 | | | | 114 | RTR-C | 115 | | RC | | 116 +-------+ 117 | / \ | 118 / \ 119 | IBGP / \ IBGP | 120 +-------+ +-------+ 121 | | RTR-D | | RTR-E | | 122 | | | | 123 | | | | | | 124 +-------+ +-------+ 125 | | | | 126 - - -|- - - - - - - - -|- - -/ 127 | EBGP EBGP | 128 - - -|- - - - - - - - -|- - -/ 129 | | | | 130 +-------+ +-------+ 131 | | | | | | 132 | RTR-F | | RTR-G | 133 | | | | | | 134 +-------+ +-------+ 135 | ASN2 | 136 / - - - - - - - - - - - - - - 138 Figure 1 140 It is highly desirable that each ASN is able to protect itself 141 independently from network security attacks using the BGP flow 142 specification NLRI for intra-domain purposes only. Network operators 143 often deploy a dedicated Security Operations Center (SOC) within 144 their ASN to monitor and detect such security attacks. To mitigate 145 attacks in a scalable intra-domain manner, operators require the 146 ability to originate intra-domain flow specification NLRIs from a 147 central BGP route controller that is not within the data forwarding 148 plane. In this way, operators can direct border routers within their 149 ASN with specific attack mitigation actions (drop the traffic, 150 forward to a clean-pipe center, etc.). To originate a flow 151 specification NLRI, a central BGP route controller must set itself as 152 the originator in the flowspec NLRI. This is necessary given the 153 route controller is originating the flow specification not reflecting 154 it, and to avoid the complexity of having to determine the egress 155 border router whose path was chosen as the best in each of the 156 ingress border routers. It thus becomes necessary to modify step (a) 157 of the [RFC5575] validation procedure such that an IBGP peer that is 158 not within the data forwarding plane may originate flow specification 159 NLRIs. 161 3. Introduction 163 [RFC5575] defined a new BGP capability that can be used to distribute 164 traffic flow specifications amongst BGP speakers in support of 165 traffic filtering. The primary intention of [RFC5575] is to enable 166 downstream autonomous systems to signal traffic filtering policies to 167 upstream autonomous systems. In this way, traffic is filtered closer 168 to the source and the upstream autonomous system(s) avoid carrying 169 the traffic to the downstream autonomous system only to be discarded. 170 [RFC5575] also enables more granular traffic filtering based upon 171 upper layer protocol information (e.g., protocol port numbers) as 172 opposed to coarse IP destination prefix-based filtering. Flow 173 specification NLRIs received from a BGP peer are subject to validity 174 checks before being considered feasible and subsequently installed 175 within the respective Adj-RIB-In. The validation procedure defined 176 within [RFC5575] requires that the originator of the flow 177 specification NLRI matches the originator of the best-match unicast 178 route for the destination prefix embedded in the flow specification. 179 This allows only BGP speakers [RFC4271] within the data forwarding 180 path (such as autonomous system border routers) to originate BGP flow 181 specification NLRIs. Though it is possible to disseminate such flow 182 specification NLRIs directly from border routers, it may be 183 operationally cumbersome in an autonomous system with a large number 184 of border routers having complex BGP policies. This document 185 describes a modification to the [RFC5575] validation procedure 186 allowing flow specification NLRIs to be originated from a centralized 187 BGP route controller within the local autonomous system that is not 188 in the data forwarding path. While the proposed modification cannot 189 be used for inter-domain coordination of traffic filtering, it 190 greatly simplifies distribution of intra-domain traffic filtering 191 policies in an autonomous system with a large number of border 192 routers having complex BGP policies. By relaxing the validation 193 procedure for IBGP, the proposed modification allows flow 194 specifications to be distributed in a standard and scalable manner 195 throughout an autonomous system. 197 4. Revised Validation Procedure 199 Step (a) of the validation procedure specified in [RFC5575], section 200 6 is redefined as follows: 202 a. One of the following conditions MUST hold true. 204 * The originator of the flow specification matches the 205 originator of the best-match unicast route for the destination 206 prefix embedded in the flow specification. 208 * The AS_PATH attribute of the flow specification does not 209 contain AS_SET and/or AS_SEQUENCE segments. 211 An AS_PATH without AS_SET and/or AS_SEQUENCE segments indicates that 212 the flow specification was originated inside the local AS [RFC4271] 213 or inside the local confederation (in the case that the local AS 214 belongs to a confederation of ASes) [RFC5065]. With this 215 modification to the [RFC5575] validation procedure, it is now 216 possible for an IBGP peer that is not within the data forwarding path 217 to originate flow specification NLRIs. This applies whether the AS 218 belongs or not to a confederation of ASes. Checking the (newly 219 introduced) second condition above MAY be disabled by configuration 220 on a BGP speaker. However, it SHOULD be enabled by default. 221 Disabling the condition may be a good practice when the administrator 222 knows with certainty that there are not flow specification NLRI 223 originated inside the local AS (or local confederation). The default 224 behavior is thus to validate an empty AS_PATH. In this context, an 225 empty AS_PATH means that it does not have AS_SET and/or AS_SEQUENCE 226 segments. Optionally, an implementation MAY also validate a specific 227 non-empty AS_PATH. For instance, it could validate a flowspec NLRI 228 whose AS_PATH contains only an AS_SEQUENCE of ASes known (via 229 configuration) to belong to the same administrative domain. 231 Further, [RFC5575] states that "BGP (flow specification) 232 implementations MUST also enforce that AS_PATH attribute of a route 233 received via the External Border Gateway Protocol (EBGP) contains the 234 neighboring AS in the left-most position of the AS_PATH attribute". 235 This rule is not valid for all topologies. For example, it prevents 236 the exchange of BGP flow specification NLRIs at Internet exchanges 237 with BGP route servers. Therefore, this document also redefines the 238 [RFC5575] AS_PATH validation procedure referenced above as follows: 240 BGP flow specification implementations MUST enforce that the last AS 241 added within the AS_PATH attribute of a EBGP learned flow 242 specification NLRI MUST match the last AS added within the AS_PATH 243 attribute of the best-match unicast route for the destination prefix 244 embedded in the flow specification. This proposed modification 245 enables the exchange of BGP flow specification NLRIs at Internet 246 exchanges with BGP route servers while at the same time, for security 247 reasons, prevents an EBGP peer from advertising an inter-domain flow 248 specification for a destination prefix that it does not provide 249 reachability information for. Note, comparing only the last ASes 250 added is sufficient for EBGP learned flow specification NLRIs. 251 Requiring a full AS_PATH match would limit origination of inter- 252 domain flow specifications to the origin (or first) AS of the best- 253 match unicast route for the destination prefix embedded in the flow 254 specification only. As such, a full AS_PATH validity check may 255 prevent transit ASes from originating inter-domain flow 256 specifications, which is not desirable. 258 This document also clarifies proper handling when the BGP flow 259 specification does not embed a destination prefix component. The 260 default behavior SHOULD be not to perform any validation procedure. 261 Further, support for two-octet AS number space is out of the scope of 262 this document. 264 In this context, AS_PATH attribute is defined as the reconstructed AS 265 Path information (by combining AS_PATH and AS4_PATH attributes, if 266 the BGP speaker is a NEW speaker and receives the route from an OLD 267 speaker), according to section 4.2.3 of [RFC6793]. 269 [RFC5575] references "the best-match unicast route for the 270 destination prefix embedded in the flow specification". For clarity, 271 this route is defined hereby as the best path of the unicast network 272 that covers destination prefix embedded in the flow specification 273 with the longer prefix-length. In other words, we consider only the 274 best-match network and we do not consider unicast non-best paths 275 (even if it is received from the same peer than the flowspec route). 277 Note that, per [RFC5575], originator may refer to the BGP 278 ORIGINATOR_ID attribute or the transport address of the peer from 279 which we received the update. If the later, a network must be 280 designed so it has a congruent topology. Otherwise, using two 281 peering sessions between the same pair of BGP speakers, one for 282 unicast and one for flowspec, will cause the flowspec validation 283 procedure to fail. Consider, for example, the case where a BGP route 284 reflector receives the NLRIs from a route reflector client, thus not 285 receiving the ORIGINATOR_ID attribute. If the speaker belongs to a 286 confederation [RFC5065] and we are receiving a flowspec route from 287 different peers than its best match unicast route, the flowspec 288 validation procedure will fail as well. Consider also a 289 misconfiguration where flowspec address-family is not configured for 290 a particular peering between different member-AS (but it is 291 configured for unicast). Even if we receive the flowspec route via a 292 redundant peer, we may receive the unicast route and the flowspec 293 from different peers, and thus flowspec validation will fail. Thus, 294 with the (newly introduced) second condition above applied, 295 incongruent topologies are supported. 297 Note that if the flowspec NLRI is learned from another AS (and thus 298 the AS_PATH is not empty), the original validation procedures defined 299 in [RFC5575] still apply and incongruent topologies may cause 300 validation rules to fail. 302 5. IANA Considerations 304 This memo includes no request to IANA. 306 6. Security Considerations 308 No new security issues are introduced by relaxing the validation 309 procedure for IBGP learned flow specifications. With this proposal, 310 the security characteristics of BGP flow specifications remain 311 equivalent to the existing security properties of BGP unicast 312 routing. Traffic flow specifications learned from IBGP peers are 313 trusted, hence, it is not required to validate that the originator of 314 an intra-domain traffic flow specification matches the originator of 315 the best-match unicast route for the flow destination prefix. 316 Conversely, this proposal continues to enforce the validation 317 procedure for EBGP learned traffic flow specifications. In this way, 318 the security properties of [RFC5575] are maintained such that an EBGP 319 peer cannot cause a denial-of-service attack by advertising an inter- 320 domain flow specification for a destination prefix that it does not 321 provide reachability information for. 323 7. Acknowledgements 325 The authors would like to thank Han Nguyen for his direction on this 326 work as well as Waqas Alam, Keyur Patel, Robert Raszuk, Eric Rosen 327 and Shyam Sethuram for their review comments. 329 8. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, 333 DOI 10.17487/RFC2119, March 1997, 334 . 336 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 337 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 338 DOI 10.17487/RFC4271, January 2006, 339 . 341 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 342 Reflection: An Alternative to Full Mesh Internal BGP 343 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 344 . 346 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 347 System Confederations for BGP", RFC 5065, 348 DOI 10.17487/RFC5065, August 2007, 349 . 351 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 352 and D. McPherson, "Dissemination of Flow Specification 353 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 354 . 356 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 357 Autonomous System (AS) Number Space", RFC 6793, 358 DOI 10.17487/RFC6793, December 2012, 359 . 361 Authors' Addresses 363 James Uttaro 364 AT&T 365 200 S. Laurel Ave 366 Middletown, NJ 07748 367 USA 369 Email: ju1738@att.com 371 Juan Alcaide 372 Cisco 373 7100 Kit Creek Road 374 Research Triangle Park, NC 27709 375 USA 377 Email: jalcaide@cisco.com 378 Clarence Filsfils 379 Cisco 381 Email: cf@cisco.com 383 David Smith 384 Cisco 385 111 Wood Ave South 386 Iselin, NJ 08830 387 USA 389 Email: djsmith@cisco.com 391 Pradosh Mohapatra 392 Sproute Networks 394 Email: mpradosh@yahoo.com