idnits 2.17.1 draft-ietf-idr-bgp-flowspec-oid-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 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 (March 13, 2017) is 2600 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: 'RFC6793' is defined on line 350, 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: September 14, 2017 D. Smith 7 Cisco 8 P. Mohapatra 9 Sproute Networks 10 March 13, 2017 12 Revised Validation Procedure for BGP Flow Specifications 13 draft-ietf-idr-bgp-flowspec-oid-04 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 http://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 September 14, 2017. 48 Copyright Notice 50 Copyright (c) 2017 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 (http://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 (or router reflector per [RFC4456]) that 148 is not within the data forwarding plane. In this way, operators can 149 direct border routers within their ASN with specific attack 150 mitigation actions (drop the traffic, forward to a clean-pipe center, 151 etc.). To originate a flow specification NLRI, a central BGP route 152 controller (or route reflector) must set itself as the originator in 153 the flowspec NLRI. This is necessary given the route controller is 154 originating the flow specification not reflecting it, and to avoid 155 the complexity of having to determine the egress border router whose 156 path was chosen as the best in each of the ingress border routers. 157 It thus becomes necessary to modify step (a) of the RFC 5575 158 validation procedure such that an IBGP peer that is not within the 159 data forwarding plane may originate flow specification NLRIs. 161 3. Introduction 163 RFC 5575 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 RFC 5575 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 RFC 5575 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 RFC 5575 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 RFC 5575 validation procedure 186 allowing flow specification NLRIs to be originated from a centralized 187 BGP route controller within the local autonomous system that is 188 neither in the data forwarding path nor serving as a BGP route 189 reflector [RFC4456]. While the proposed modification cannot be used 190 for inter-domain coordination of traffic filtering, it greatly 191 simplifies distribution of intra-domain traffic filtering policies in 192 an autonomous system with a large number of border routers having 193 complex BGP policies. By relaxing the validation procedure for IBGP, 194 the proposed modification allows flow specifications to be 195 distributed in a standard and scalable manner throughout an 196 autonomous system. 198 4. Revised Validation Procedure 200 Step (a) of the validation procedure specified in RFC 5575, section 6 201 is redefined as follows: 203 a. One of the following conditions MUST hold true. 205 * The originator of the flow specification matches the 206 originator of the best-match unicast route for the destination 207 prefix embedded in the flow specification. 209 * The AS_PATH attribute of the flow specification does not 210 contain AS_SET and AS_SEQUENCE segments. 212 An AS_PATH without AS_SET and AS_SEQUENCE segments indicates that the 213 flow specification was originated inside the local AS [RFC4271] or 214 inside the local confederation (in the case that the local AS belongs 215 to a confederation of ASes) [RFC5065]. With this modification to the 216 RFC 5575 validation procedure, it is now possible for an IBGP peer 217 that is not within the data forwarding path to originate flow 218 specification NLRIs. This applies whether the AS belongs or not to a 219 confederation of ASes. Checking the (newly introduced) second 220 condition above MAY be disabled by configuration on a BGP speaker. 221 However, it SHOULD be enabled by default. Disabling the condition 222 may be a good practice when the administrator knows with certainty 223 that there are not flow specification NLRI originated inside the 224 local AS (or local confederation). Optionally, an implementation 225 could be configured to allow only flow specification NLRIs containing 226 only a subset of ASes. This could be useful, for example, with 227 networks that consist of multiple ASes that operate under the same 228 administrative domain. 230 Further, RFC 5575 states that "BGP (flow specification) 231 implementations MUST also enforce that AS_PATH attribute of a route 232 received via the External Border Gateway Protocol (EBGP) contains the 233 neighboring AS in the left-most position of the AS_PATH attribute". 234 This rule is not valid for all topologies. For example, it prevents 235 the exchange of BGP flow specification NLRIs at Internet exchanges 236 with BGP route servers. Therefore, this document also redefines the 237 RFC 5575 AS_PATH validation procedure referenced above as follows. 239 BGP flow specification implementations MUST enforce that the last AS 240 added within the AS_PATH attribute of a EBGP learned flow 241 specification NLRI MUST match the last AS added within the AS_PATH 242 attribute of the best-match unicast route for the destination prefix 243 embedded in the flow specification. This proposed modification 244 enables the exchange of BGP flow specification NLRIs at Internet 245 exchanges with BGP route servers while at the same time, for security 246 reasons, prevents an EBGP peer from advertising an inter-domain flow 247 specification for a destination prefix that it does not provide 248 reachability information for. Note, comparing only the last ASes is 249 sufficient for EBGP learned flow specification NLRIs. Requiring a 250 full AS_PATH match would limit origination of inter-domain flow 251 specifications to the origin (or first) AS of the best-match unicast 252 route for the destination prefix embedded in the flow specification 253 only. As such, a full AS_PATH validity check may prevent transit 254 ASes from originating inter-domain flow specifications which is not 255 desirable. 257 This document also clarifies proper handling when the BGP flow 258 specification does not embed a destination prefix component. The 259 default behavior SHOULD be not to perform any validation procedure. 260 Further, support for two-octet AS number space is out of the scope of 261 this document. 263 In this context, AS_PATH attribute is defined as the reconstructed AS 264 Path information (by combining AS_PATH and AS4_PATH attributes, if 265 the BGP speaker is a NEW speaker and receives the route from an OLD 266 speaker), according to section 4.2.3 of RFC 6793. 268 RFC 5575 references "the best-match unicast route for the destination 269 prefix embedded in the flow specification". For clarity, this route 270 is defined hereby as the best path of the unicast network that covers 271 destination prefix embedded in the flow specification with the longer 272 prefix-length. In other words, we consider only the best-match 273 network and we do not consider unicast non-best paths (even if it is 274 received from the same peer than the flowspec route). 276 Note that, per RFC 5575, originator may refer to the BGP 277 ORIGINATOR_ID attribute or the transport address of the peer from 278 which we received the update. If the later, a network must be 279 designed so it has a congruent topology. Otherwise, using two 280 peering sessions between the same pair of BGP speakers, one for 281 unicast and one for flowspec, will cause the flowspec validation 282 procedure to fail. Consider, for example, the case where a BGP route 283 reflector receives the NLRIs from a route reflector client, thus not 284 receiving the ORIGINATOR_ID attribute. If the speaker belongs to a 285 confederation [RFC5065] and we are receiving a flowspec route from 286 different peers than its best match unicast route, the flowspec 287 validation procedure will fail as well. Consider also a 288 misconfiguration where flowspec address-family is not configured for 289 a particular peering between different member-AS (but it is 290 configured for unicast). Even if we receive the flowspec route via a 291 redundant peer, we may receive the unicast route and the flowspec 292 from different peers, and thus flowspec validation will fail. With 293 the (newly introduced) second condition above applied, uncongruent 294 topologies are supported. 296 5. IANA Considerations 298 This memo includes no request to IANA. 300 6. Security Considerations 302 No new security issues are introduced by relaxing the validation 303 procedure for IBGP learned flow specifications. With this proposal, 304 the security characteristics of BGP flow specifications remain 305 equivalent to the existing security properties of BGP unicast 306 routing. Traffic flow specifications learned from IBGP peers are 307 trusted, hence, it is not required to validate that the originator of 308 an intra-domain traffic flow specification matches the originator of 309 the best-match unicast route for the flow destination prefix. 310 Conversely, this proposal continues to enforce the validation 311 procedure for EBGP learned traffic flow specifications. In this way, 312 the security properties of RFC 5575 are maintained such that an EBGP 313 peer cannot cause a denial-of-service attack by advertising an inter- 314 domain flow specification for a destination prefix that it does not 315 provide reachability information for. 317 7. Acknowledgements 319 The authors would like to thank Han Nguyen for his direction on this 320 work as well as Waqas Alam, Keyur Patel, Robert Raszuk, Eric Rosen 321 and Shyam Sethuram for their review comments. 323 8. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, 327 DOI 10.17487/RFC2119, March 1997, 328 . 330 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 331 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 332 DOI 10.17487/RFC4271, January 2006, 333 . 335 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 336 Reflection: An Alternative to Full Mesh Internal BGP 337 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 338 . 340 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 341 System Confederations for BGP", RFC 5065, 342 DOI 10.17487/RFC5065, August 2007, 343 . 345 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 346 and D. McPherson, "Dissemination of Flow Specification 347 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 348 . 350 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 351 Autonomous System (AS) Number Space", RFC 6793, 352 DOI 10.17487/RFC6793, December 2012, 353 . 355 Authors' Addresses 357 James Uttaro 358 AT&T 359 200 S. Laurel Ave 360 Middletown, NJ 07748 361 USA 363 Email: ju1738@att.com 365 Juan Alcaide 366 Cisco 367 7100 Kit Creek Road 368 Research Triangle Park, NC 27709 369 USA 371 Email: jalcaide@cisco.com 373 Clarence Filsfils 374 Cisco 376 Email: cf@cisco.com 377 David Smith 378 Cisco 379 111 Wood Ave South 380 Iselin, NJ 08830 381 USA 383 Email: djsmith@cisco.com 385 Pradosh Mohapatra 386 Sproute Networks 388 Email: mpradosh@yahoo.com