idnits 2.17.1 draft-sas-idr-maxprefix-inbound-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 ([RFC7908], [RFC4271]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4271, but the abstract doesn't seem to directly say this. It does mention RFC4271 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 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 (19 January 2022) is 828 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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: 23 July 2022 J. Snijders 7 Fastly 8 19 January 2022 10 BGP Maximum Prefix Limits Inbound 11 draft-sas-idr-maxprefix-inbound-04 13 Abstract 15 This document describes mechanisms to limit the negative impact of 16 route leaks [RFC7908] and/or resource exhaustion in BGP [RFC4271] 17 implementations. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 23 "OPTIONAL" in this document are to be interpreted as described in BCP 24 14 [RFC2119] [RFC8174] when, and only when, they appear in all 25 capitals, as shown here. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 23 July 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Changes to RFC4271 Section 6 . . . . . . . . . . . . . . . . 2 62 3. Changes to RFC4271 Section 8 . . . . . . . . . . . . . . . . 3 63 4. Changes to RFC4271 Section 9 . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 67 8. Implementation status - RFC EDITOR: REMOVE BEFORE 68 PUBLICATION . . . . . . . . . . . . . . . . . . . . . . . 5 69 9. Appendix: Implementation Guidance . . . . . . . . . . . . . . 6 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 10.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 This document updates [RFC4271] by revising control mechanism which 78 limit the negative impact of route leaks [RFC7908] and/or resource 79 exhaustion in Border Gateway Protocol (BGP) implementations. While 80 [RFC4271] described methods to tear down BGP sessions or discard 81 UPDATES after certain thresholds are exceeded, some nuances in this 82 specification were missing resulting in inconsistencies between BGP 83 implementations. 85 2. Changes to RFC4271 Section 6 87 This section updates [RFC4271] to specify what events can result in 88 AutomaticStop (Event 8) in the BGP FSM. 90 The following paragraph replaces the second paragraph of Section 6.7 91 (Cease), which starts with "A BGP speaker MAY support" and ends with 92 "The speaker MAY also log this locally.": 94 A BGP speaker MAY support the ability to impose a locally- 95 configured, upper bound on the number of address prefixes the 96 speaker is willing to accept from a neighbor (inbound maximum 97 prefix limit). The limit on the prefixes accepted from a neighbor 98 can be applied before policy processing (Pre-Policy) or after 99 policy processing (Post-Policy). When the upper bound is reached, 100 the speaker, under control of local configuration, either: 102 a. Discards new address prefixes from the neighbor, while 103 maintaining the BGP connection. As these prefixes are 104 discared, their reachability information is not stored on the 105 local router, which might lead to inconsistent routing 106 behaviour; 108 b. Receives all the new prefixes exceeding the threshold, accepts 109 them and generates a log of the event; 111 c. Terminates the BGP connection with the neighbor. 113 If the BGP speaker decides to terminate its BGP connection with a 114 neighbor because the number of address prefixes received from the 115 neighbor exceeds the locally-configured, upper bound, then the 116 speaker MUST send the neighbor a NOTIFICATION message with the 117 Error Code Cease. 119 +=========+=========================================================+ 120 | Subcode | Symbolic Name | 121 +=========+=========================================================+ 122 | 1 | Threshold exceeded: Maximum | 123 | | Number of Prefixes Received | 124 +---------+---------------------------------------------------------+ 126 Table 1 128 The speaker MAY also log this locally. 130 3. Changes to RFC4271 Section 8 132 This section updates Section 8 [RFC4271], the paragraph that starts 133 with "One reason for an AutomaticStop event is" and ends with "The 134 local system automatically disconnects the peer." is replaced with: 136 Possible reasons for an AutomaticStop event are: A BGP speaker 137 receives an UPDATE messages with a number of prefixes for a given 138 peer such that the total prefixes received exceeds the maximum 139 number of prefixes configured (either "Pre-Policy" or "Post- 140 Policy"). The local system automatically disconnects the peer. 142 4. Changes to RFC4271 Section 9 144 This section updates [RFC4271] by adding a subsection after 145 Section 9.4 (Originating BGP routes) to specify various events that 146 can lead up to AutomaticStop (Event 8) in the BGP FSM. 148 9.5 Maximum Prefix Limits 150 9.5.1 Pre-Policy Inbound Maximum Prefix Limits 152 The Adj-RIB-In stores routing information learned from inbound 153 UPDATE messages that were received from another BGP speaker 154 Section 3.2 [RFC4271]. The pre-policy limit uses the number of 155 NLRIs per Address Family Identifier (AFI) per Subsequent 156 Address Family Identifier (SAFI) as input into its threshold 157 comparisons. For example, when an operator configures the pre- 158 policy limit for IPv4 Unicast to be 50 on a given EBGP session, 159 and the other BGP speaker announces its 51st IPv4 Unicast NLRI, 160 the session MUST be terminated. 162 Pre-policy limits are particularly useful to help dampen the 163 effects of full table route leaks and memory exhaustion when 164 the implementation stores rejected routes. 166 Operators SHOULD take special care when utilizing methods where 167 the router maintains a table of all the received updates pre- 168 policy, as this could still expose control plane to exhaustion 169 if no pre-policy limits are available or are not configured. 170 Implementations SHOULD provide means to configure two 171 thresholds for inbound limits, one before policies are applied, 172 and one after. This is to prevent exhaustion of control plane 173 resources. The threshold before policy SHOULD be higher than 174 or equal to the limit configured after policy. 176 9.5.2 Post-Policy Inbound Maximum Prefix Limits 178 RFC4271 describes a Policy Information Base (PIB) that contains 179 local policies that can be applied to the information in the 180 Routing Information Base (RIB). The post-policy limit uses the 181 number of NLRIs per Address Family Identifier (AFI) per 182 Subsequent Address Family Identifier (SAFI), after application 183 of the Import Policy as input into its threshold comparisons. 184 For example, when an operator configures the post-policy limit 185 for IPv4 Unicast to be 50 on a given EBGP session, and the 186 other BGP speaker announces a hundred IPv4 Unicast routes of 187 which none are accepted as a result of the local import policy 188 (and thus not considered for the Loc-RIB by the local BGP 189 speaker), the session is not terminated. 191 Post-policy limits are useful to help prevent FIB exhaustion 192 and prevent accidental BGP session teardown due to prefixes not 193 accepted by policy anyway. 195 5. Security Considerations 197 Maximum Prefix Limits are an essential tool for routing operations 198 and SHOULD be used to increase stability for the global routing 199 ecosystem. 201 6. IANA Considerations 203 This memo requests that IANA updates the name of subcode "Maximum 204 Number of Prefixes Reached" to "Threshold exceeded: Maximum Number of 205 Prefixes Received" in the "Cease NOTIFICATION message subcodes" 206 registry under the "Border Gateway Protocol (BGP) Parameters" group. 208 7. Acknowledgments 210 The authors would like to thank Saku Ytti and John Heasley (NTT 211 Ltd.), Jeff Haas, Colby Barth and John Scudder (Juniper Networks), 212 Martijn Schmidt (i3D.net), Teun Vink (BIT), Sabri Berisha (eBay), 213 Martin Pels (Quanza), Steven Bakker (AMS-IX), Aftab Siddiqui (ISOC), 214 Yu Tianpeng, Ruediger Volk (Deutsche Telekom), Robert Raszuk (NTT), 215 Jakob Heitz (Cisco), Warren Kumari (Google), Ben Maddison 216 (Workonline), Randy Bush, Brian Dickson, Gyan Mishra (Verizon) and 217 John John Heasley (NTTA) for their support, insightful reviews, and 218 comments. 220 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 222 This section records the status of known implementations of the 223 protocol defined by this specification at the time of posting of this 224 Internet-Draft, and is based on a proposal described in RFC7942. The 225 description of implementations in this section is intended to assist 226 the IETF in its decision processes in progressing drafts to RFCs. 227 Please note that the listing of any individual implementation here 228 does not imply endorsement by the IETF. Furthermore, no effort has 229 been spent to verify the information presented here that was supplied 230 by IETF contributors. This is not intended as, and must not be 231 construed to be, a catalog of available implementations or their 232 features. Readers are advised to note that other implementations may 233 exist. 235 The below table provides an overview (as of the moment of writing) of 236 which vendors have produced implementation of inbound prefix limits. 237 Each table cell shows the applicable configuration keywords if the 238 vendor implemented the feature. 240 +==========+======================+==========================+ 241 | Vendor | Type A Pre-Policy | Type B Post-Policy | 242 +==========+======================+==========================+ 243 | Cisco | | maximum-prefix | 244 | IOS XR | | | 245 +----------+----------------------+--------------------------+ 246 | Cisco | | maximum-prefix | 247 | IOS XE | | | 248 +----------+----------------------+--------------------------+ 249 | Juniper | prefix-limit | accepted-prefix-limit, | 250 | Junos OS | | or prefix-limit combined | 251 | | | with 'keep none' | 252 +----------+----------------------+--------------------------+ 253 | Nokia SR | prefix-limit | | 254 | OS | | | 255 +----------+----------------------+--------------------------+ 256 | NIC.CZ | 'import keep | 'import limit' or | 257 | BIRD | filtered' combined | 'receive limit' | 258 | | with 'receive limit' | | 259 +----------+----------------------+--------------------------+ 260 | OpenBSD | max-prefix | | 261 | OpenBGPD | | | 262 +----------+----------------------+--------------------------+ 263 | Arista | maximum-routes | maximum-accepted-routes | 264 | EOS | | | 265 +----------+----------------------+--------------------------+ 266 | Huawei | peer route-limit | | 267 | VRPv5 | | | 268 +----------+----------------------+--------------------------+ 269 | Huawei | peer route-limit | peer route-limit accept- | 270 | VRPv8 | | prefix | 271 +----------+----------------------+--------------------------+ 273 Table 2: Maximum prefix limits capabilities per implementation 275 First presented by Snijders at [RIPE77] 277 9. Appendix: Implementation Guidance 279 TBD 281 10. References 283 10.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, 288 . 290 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 291 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 292 DOI 10.17487/RFC4271, January 2006, 293 . 295 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 296 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 297 May 2017, . 299 10.2. Informative References 301 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 302 and B. Dickson, "Problem Definition and Classification of 303 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 304 2016, . 306 [RIPE77] Snijders, J., "Robust Routing Policy Architecture", May 307 2018, . 310 Authors' Addresses 312 Melchior Aelmans 313 Juniper Networks 314 Boeing Avenue 240 315 1119 PZ Schiphol-Rijk 316 Netherlands 318 Email: maelmans@juniper.net 320 Massimiliano Stucchi 321 Independent 323 Email: max@stucchi.ch 325 Job Snijders 326 Fastly 327 Theodorus Majofskistraat 100 328 1065 SZ Amsterdam 329 Netherlands 330 Email: job@fastly.com