idnits 2.17.1 draft-sas-idr-maxprefix-outbound-02.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 (Using the creation date from RFC4271, updated by this document, for RFC5378 checks: 2006-01-13) -- 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 (February 18, 2021) is 1161 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: 'I-D.ietf-idr-bgp-model' is defined on line 388, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-sas-idr-maxprefix-inbound-01 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-10 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing M. Aelmans 3 Internet-Draft Juniper Networks 4 Updates: 4271 (if approved) M. Stucchi 5 Intended status: Standards Track Independent 6 Expires: August 22, 2021 J. Snijders 7 Fastly 8 February 18, 2021 10 Revised BGP Maximum Prefix Limits Outbound 11 draft-sas-idr-maxprefix-outbound-02 13 Abstract 15 This document updates RFC4271 by adding a control mechanism which 16 limits the negative impact of outbound route leaks (RFC7908) in order 17 to prevent resource exhaustion in Border Gateway Protocol (BGP) 18 implementations. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 24 "OPTIONAL" in this document are to be interpreted as described in BCP 25 14 [RFC2119] [RFC8174] when, and only when, they appear in all 26 capitals, as shown here. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 22, 2021. 45 Copyright Notice 47 Copyright (c) 2021 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 (https://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 respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Changes to RFC4271 Section 6 . . . . . . . . . . . . . . . . 3 64 3. Changes to RFC4271 Section 8 . . . . . . . . . . . . . . . . 4 65 4. Changes to RFC4271 Section 9 . . . . . . . . . . . . . . . . 4 66 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Internet use case . . . . . . . . . . . . . . . . . . . . 6 68 5.2. CE protection . . . . . . . . . . . . . . . . . . . . . . 6 69 5.3. PE-CE BGP session from operator side . . . . . . . . . . 6 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 73 9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 7 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 10.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 This document updates [RFC4271] by adding a control mechanism which 82 limits the negative impact of outbound route leaks [RFC7908] in order 83 to prevent resource exhaustion in Border Gateway Protocol (BGP) 84 implementations. [RFC4271] describes methods to tear down BGP 85 sessions or discard UPDATES after certain inbound thresholds are 86 exceeded. In addition to "inbound maximum prefix limits", this 87 document introduces a specification for "outbound maximum prefix 88 limits". [I-D.sas-idr-maxprefix-inbound] updates sections in 89 [RFC4271] to clarify "inbound maximum prefix limits". This documents 90 updates those sections again to add "outbound maximum prefix limits". 92 2. Changes to RFC4271 Section 6 94 This section updates [RFC4271] to specify what events can result in 95 AutomaticStop (Event 8) in the BGP FSM. 97 The following paragraph replaces the second paragraph of Section 6.7 98 (Cease), which starts with "A BGP speaker MAY support" and ends with 99 "The speaker MAY also log this locally.": 101 A BGP speaker MAY support the ability to impose a locally- 102 configured, upper bound on the number of address prefixes the 103 speaker is willing to accept from a neighbor (inbound maximum 104 prefix limit) or send to a neighbor (outbound prefix limit). The 105 limit on the prefixes accepted from a neighbor can be applied 106 before policy processing (Pre-Policy) or after policy processing 107 (Post-Policy). Outbound prefix limits MUST be measured after 108 policy, since the Policy (even a policy of "send all") is run 109 before determining what can be sent. When the upper bound is 110 reached, the speaker, under control of local configuration, 111 either: 113 A. Discards new address prefixes being sent to the neighbor while 114 maintaining the BGP connection with the neighbor. As these 115 prefixes are discared and their reachability information is 116 not sent to the neighbor it might lead to inconsistent routing 117 behaviour; 119 B. Sent all prefixes exceeding the threshold and generates a log; 121 C. Terminates the BGP session with the neighbor. This should be 122 done using a Hard Reset according to [RFC8538]. 124 If the BGP speaker uses option (b), where the limit causes a CEASE 125 Notification, then the CEASE error codes should use: 127 +---------+---------------------------------------------------------+ 128 | Subcode | Symbolic Name | 129 +---------+---------------------------------------------------------+ 130 | 1 | Threshold exceeded: Maximum Number of Prefixes Received | 131 | TBD | Threshold exceeded: Maximum Number of Prefixes Sent | 132 +---------+---------------------------------------------------------+ 134 The speaker MAY also log the event locally. 136 3. Changes to RFC4271 Section 8 138 This section updates Section 8 [RFC4271], the paragraph that starts 139 with "One reason for an AutomaticStop event is" and ends with "The 140 local system automatically disconnects the peer." is replaced with: 142 Possible reasons for an AutomaticStop event are: A BGP speaker 143 receives an UPDATE messages with a number of prefixes for a given 144 peer such that the total prefixes received exceeds the maximum 145 number of prefixes configured (either "Pre-Policy" or "Post- 146 Policy"), or announces more prefixes than through local 147 configuration allowed to. The local system automatically 148 disconnects the peer. 150 4. Changes to RFC4271 Section 9 152 This section updates [RFC4271] by adding a subsection after 153 Section 9.4 (Originating BGP routes) to specify various events that 154 can lead up to an AutomaticStop (Event 8) in the BGP FSM. 156 9.5 Maximum Prefix Limits 158 9.5.1 Pre-Policy Inbound Maximum Prefix Limits 160 The Adj-RIBs-In stores routing information learned from inbound 161 UPDATE messages that were received from another BGP speaker 162 Section 3.2 [RFC4271]. The pre-policy limit uses the number of 163 NLRIs per Address Family Identifier (AFI) per Subsequent 164 Address Family Identifier (SAFI) as input into its threshold 165 comparisons. For example, when an operator configures the pre- 166 policy limit for IPv4 Unicast to be 50 on a given EBGP session, 167 and the other BGP speaker announces its 51st IPv4 Unicast NLRI, 168 the session MUST be terminated. 170 Pre-policy limits are particularly useful to help dampen the 171 effects of full table route leaks and memory exhaustion when 172 the implementation stores rejected routes. 174 9.5.2 Post-Policy Inbound Maximum Prefix Limits 176 [RFC4271] describes a Policy Information Base (PIB) that 177 contains local policies that can be applied to the information 178 in the Routing Information Base (RIB). The post-policy limit 179 uses the number of NLRIs per Address Family Identifier (AFI) 180 per Subsequent Address Family Identifier (SAFI), after 181 application of the Import Policy as input into its threshold 182 comparisons. For example, when an operator configures the 183 post-policy limit for IPv4 Unicast to be 50 on a given EBGP 184 session, and the other BGP speaker announces a hundred IPv4 185 Unicast routes of which none are accepted as a result of the 186 local import policy (and thus not considered for the Loc-RIB by 187 the local BGP speaker), the session is not terminated. 189 Post-policy limits are useful to help prevent FIB exhaustion 190 and prevent accidental BGP session teardown due to prefixes not 191 accepted by policy anyway. 193 9.5.3 Outbound Maximum Prefix Limits 195 An operator MAY configure a BGP speaker to terminate its BGP 196 session with a neighbor when the number of address prefixes to 197 be advertised to that neighbor exceeds a locally configured 198 post-policy upper limit. The BGP speaker then MUST send the 199 neighbor a NOTIFICATION message with the Error Code "Cease" and 200 the Error Subcode "Threshold reached: Maximum Number of 201 Prefixes Sent". Implementations MAY support additional 202 actions. The Hard Cease action is defined in [RFC8538]. 204 Reporting when thresholds have been exceeded is an 205 implementation specific consideration, but SHOULD include 206 methods such as Syslog [RFC5424]. By definition, Outbound 207 Maximum Prefix Limits are Post-Policy. 209 The Adj-RIBs-Out stores information selected by the local BGP 210 speaker for advertisement to its neighbors. The routing 211 information stored in the Adj-RIBs-Out will be carried in the 212 local BGP speaker's UPDATE messages and advertised to its 213 neighbors Section 3.2 [RFC4271]. The Outbound Maximum Prefix 214 Limit uses the number of NLRIs per Address Family Identifier 215 (AFI) per Subsequent Address Family Identifier (SAFI), after 216 application of the Export Policy, as input into its threshold 217 comparisons. For example, when an operator configures the 218 Outbound Maximum Prefix Limit for IPv4 Unicast to be 50 on a 219 given EBGP session, and were about to announce its 51st IPv4 220 Unicast NLRI to the other BGP speaker as a result of the local 221 export policy, the session MUST be terminated. 223 Outbound Maximum Prefix Limits are useful to help dampen the 224 negative effects of a misconfiguration in local policy. In 225 many cases, it would be more desirable to tear down a BGP 226 session rather than causing or propagating a route leak. 228 5. Use cases 230 Egress maximum prefix limits are usefull in a variety of cases. Some 231 of those are outlined in this section. 233 5.1. Internet use case 235 In order to prevent the BGP speaker from leaking a full routing table 236 to its neighbor operators should implement proper routing policy and 237 preferably RFC8212. However, even when implementing both 238 measurements an operator could still (accidentaly) announce more 239 routes than intended. Setting a maximum prefix outbound value 240 prevents this. 242 5.2. CE protection 244 Residential and many business customers connected to the internet 245 using a 'simple' CPE and connected to a single Service Provider only 246 needs to accept a single default route and not the full internet 247 table. In order to prevent overloading the CPE Control Plane, 248 maximum outbound limits should be applied on the session on the PE 249 router. 251 5.3. PE-CE BGP session from operator side 253 -- Change this so it explains that it's extra protection towards the 254 PE so it won't kill the BGP session due to max prefix inbound -- 255 Internet providers PE side gateway PE-CE connections would would 256 generally set maximum prefix to disconnect if maximum prefix is 257 reached. This is a secondary protection mechanism as the primary is 258 prefix length and AS path checks. 260 6. Security Considerations 262 Maximum Prefix Limits are an essential tool for routing operations 263 and SHOULD be used to increase stability. They provide a first-line 264 mechanism to avoid route leaks and to avoid unintended routing 265 suggestions to happen between neighbors. Implementing this measures 266 is only one of the building blocks you need to provide full security, 267 but it is important to build a modular defense system. 269 Stability for the routing table is also an important aspect for 270 implementing the measures included in this draft. Ensuring that 271 neighbors will not receive an amount of routes that would overload 272 their routing platform contributes to the stability of 273 interconnections and of the Internet as a whole. 275 7. IANA Considerations 277 This memo requests that IANA assigns a new subcode named "Threshold 278 exceeded: Maximum Number of Prefixes Sent" in the "Cease NOTIFICATION 279 message subcodes" registry under the "Border Gateway Protocol (BGP) 280 Parameters" group. 282 8. Acknowledgments 284 The authors would like to thank Saku Ytti and John Heasley (NTT 285 Ltd.), Jeff Haas, Colby Barth and John Scudder (Juniper Networks), 286 Martijn Schmidt (i3D.net), Teun Vink (BIT), Sabri Berisha (eBay), 287 Martin Pels (Quanza), Steven Bakker (AMS-IX), Aftab Siddiqui (ISOC), 288 Yu Tianpeng, Ruediger Volk (Deutsche Telekom), Robert Raszuk 289 (Bloomberg), Jakob Heitz (Cisco), Warren Kumari (Google), Ben 290 Maddison (Workonline), Randy Bush, Brian Dickson and Gyan Mishra 291 (Verizon) for their support, insightful reviews, and comments. 293 9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 295 This section records the status of known implementations of the 296 protocol defined by this specification at the time of posting of this 297 Internet-Draft, and is based on a proposal described in RFC7942. The 298 description of implementations in this section is intended to assist 299 the IETF in its decision processes in progressing drafts to RFCs. 300 Please note that the listing of any individual implementation here 301 does not imply endorsement by the IETF. Furthermore, no effort has 302 been spent to verify the information presented here that was supplied 303 by IETF contributors. This is not intended as, and must not be 304 construed to be, a catalog of available implementations or their 305 features. Readers are advised to note that other implementations may 306 exist. 308 The table below provides an overview (as of the moment of writing) of 309 which vendors have produced implementations of inbound or outbound 310 maximum prefix limits. Each table cell shows the applicable 311 configuration keywords if the vendor implemented the feature. 313 +----------+-------------+---------------------+--------------------+ 314 | Vendor | Inbound | Inbound Post-Policy | Outbound | 315 | | Pre-Policy | | | 316 +----------+-------------+---------------------+--------------------+ 317 | Cisco | | maximum-prefix | | 318 | IOS XR | | | | 319 +----------+-------------+---------------------+--------------------+ 320 | Cisco | | maximum-prefix | | 321 | IOS XE | | | | 322 +----------+-------------+---------------------+--------------------+ 323 | Juniper | prefix- | accepted-prefix- | advertise-prefix- | 324 | Junos OS | limit | limit, or prefix- | limit * | 325 | | | limit combined with | | 326 | | | 'keep none' | | 327 +----------+-------------+---------------------+--------------------+ 328 | Nokia SR | prefix- | | | 329 | OS | limit | | | 330 +----------+-------------+---------------------+--------------------+ 331 | NIC.CZ | 'import | 'import limit' or | export limit | 332 | BIRD | keep | 'receive limit' | | 333 | | filtered' | | | 334 | | combined | | | 335 | | with | | | 336 | | 'receive | | | 337 | | limit' | | | 338 +----------+-------------+---------------------+--------------------+ 339 | OpenBSD | max-prefix | | | 340 | OpenBGPD | | | | 341 +----------+-------------+---------------------+--------------------+ 342 | Arista | maximum- | maximum-accepted- | | 343 | EOS | routes | routes | | 344 +----------+-------------+---------------------+--------------------+ 345 | Huawei | peer route- | | | 346 | VRPv5 | limit | | | 347 +----------+-------------+---------------------+--------------------+ 348 | Huawei | peer route- | peer route-limit | | 349 | VRPv8 | limit | accept-prefix | | 350 +----------+-------------+---------------------+--------------------+ 352 First presented by Job Snijders at [RIPE77] 354 Table 1: Maximum prefix limits capabilities per implementation 356 *In testing stage 358 10. References 360 10.1. Normative References 362 [I-D.sas-idr-maxprefix-inbound] 363 Aelmans, M., stucchi-lists@glevia.com, s., and J. 364 Snijders, "BGP Maximum Prefix Limits Inbound", draft-sas- 365 idr-maxprefix-inbound-01 (work in progress), October 2020. 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, 369 DOI 10.17487/RFC2119, March 1997, 370 . 372 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 373 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 374 DOI 10.17487/RFC4271, January 2006, 375 . 377 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 378 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 379 May 2017, . 381 [RFC8538] Patel, K., Fernando, R., Scudder, J., and J. Haas, 382 "Notification Message Support for BGP Graceful Restart", 383 RFC 8538, DOI 10.17487/RFC8538, March 2019, 384 . 386 10.2. Informative References 388 [I-D.ietf-idr-bgp-model] 389 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 390 YANG Model for Service Provider Networks", draft-ietf-idr- 391 bgp-model-10 (work in progress), November 2020. 393 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 394 DOI 10.17487/RFC5424, March 2009, 395 . 397 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 398 and B. Dickson, "Problem Definition and Classification of 399 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 400 2016, . 402 [RIPE77] Snijders, J., "Robust Routing Policy Architecture", May 403 2018, . 406 Authors' Addresses 408 Melchior Aelmans 409 Juniper Networks 410 Boeing Avenue 240 411 Schiphol-Rijk 1119 PZ 412 Netherlands 414 Email: maelmans@juniper.net 416 Massimiliano Stucchi 417 Independent 419 Email: max@stucchi.ch 421 Job Snijders 422 Fastly 423 Amsterdam 424 Netherlands 426 Email: job@fastly.com