idnits 2.17.1 draft-sas-idr-maxprefix-inbound-03.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 (June 16, 2021) is 1043 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 293, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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: December 18, 2021 J. Snijders 7 Fastly 8 June 16, 2021 10 BGP Maximum Prefix Limits Inbound 11 draft-sas-idr-maxprefix-inbound-03 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 December 18, 2021. 44 Copyright Notice 46 Copyright (c) 2021 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 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Changes to RFC4271 Section 6 . . . . . . . . . . . . . . . . 2 63 3. Changes to RFC4271 Section 8 . . . . . . . . . . . . . . . . 3 64 4. Changes to RFC4271 Section 9 . . . . . . . . . . . . . . . . 3 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 68 8. Implementation status - RFC EDITOR: REMOVE BEFORE 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 Number of Prefixes Received | 123 +---------+---------------------------------------------------------+ 125 The speaker MAY also log this locally. 127 3. Changes to RFC4271 Section 8 129 This section updates Section 8 [RFC4271], the paragraph that starts 130 with "One reason for an AutomaticStop event is" and ends with "The 131 local system automatically disconnects the peer." is replaced with: 133 Possible reasons for an AutomaticStop event are: A BGP speaker 134 receives an UPDATE messages with a number of prefixes for a given 135 peer such that the total prefixes received exceeds the maximum 136 number of prefixes configured (either "Pre-Policy" or "Post- 137 Policy"). The local system automatically disconnects the peer. 139 4. Changes to RFC4271 Section 9 141 This section updates [RFC4271] by adding a subsection after 142 Section 9.4 (Originating BGP routes) to specify various events that 143 can lead up to AutomaticStop (Event 8) in the BGP FSM. 145 9.5 Maximum Prefix Limits 147 9.5.1 Pre-Policy Inbound Maximum Prefix Limits 149 The Adj-RIBs-In stores routing information learned from inbound 150 UPDATE messages that were received from another BGP speaker 151 Section 3.2 [RFC4271]. The pre-policy limit uses the number of 152 NLRIs per Address Family Identifier (AFI) per Subsequent 153 Address Family Identifier (SAFI) as input into its threshold 154 comparisons. For example, when an operator configures the pre- 155 policy limit for IPv4 Unicast to be 50 on a given EBGP session, 156 and the other BGP speaker announces its 51st IPv4 Unicast NLRI, 157 the session MUST be terminated. 159 Pre-policy limits are particularly useful to help dampen the 160 effects of full table route leaks and memory exhaustion when 161 the implementation stores rejected routes. 163 Operators SHOULD take special care when applying soft- 164 reconfiguration inbound, as it could still expose control plane 165 to exhaustion if no pre-policy limits are available or are not 166 configured. Implementations SHOULD provide means to configure 167 two thresholds for inbound limits. One before soft- 168 reconfiguration inbound and one after soft-reconfiguration 169 inbound. This is to prevent soft-reconfiguration inbound to 170 exhaust control plane resources. The threshold before soft- 171 reconfiguration inbound SHOULD be higher than the limit 172 configured after soft-reconfiguration inbound. 174 9.5.2 Post-Policy Inbound Maximum Prefix Limits 176 RFC4271 describes a Policy Information Base (PIB) that contains 177 local policies that can be applied to the information in the 178 Routing Information Base (RIB). The post-policy limit uses the 179 number of NLRIs per Address Family Identifier (AFI) per 180 Subsequent Address Family Identifier (SAFI), after application 181 of the Import Policy as input into its threshold comparisons. 182 For example, when an operator configures the post-policy limit 183 for IPv4 Unicast to be 50 on a given EBGP session, and the 184 other BGP speaker announces a hundred IPv4 Unicast routes of 185 which none are accepted as a result of the local import policy 186 (and thus not considered for the Loc-RIB by the local BGP 187 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 5. Security Considerations 195 Maximum Prefix Limits are an essential tool for routing operations 196 and SHOULD be used to increase stability for the global routing 197 ecosystem. 199 6. IANA Considerations 201 This memo requests that IANA updates the name of subcode "Maximum 202 Number of Prefixes Reached" to "Threshold exceeded: Maximum Number of 203 Prefixes Received" in the "Cease NOTIFICATION message subcodes" 204 registry under the "Border Gateway Protocol (BGP) Parameters" group. 206 7. Acknowledgments 208 The authors would like to thank Saku Ytti and John Heasley (NTT 209 Ltd.), Jeff Haas, Colby Barth and John Scudder (Juniper Networks), 210 Martijn Schmidt (i3D.net), Teun Vink (BIT), Sabri Berisha (eBay), 211 Martin Pels (Quanza), Steven Bakker (AMS-IX), Aftab Siddiqui (ISOC), 212 Yu Tianpeng, Ruediger Volk (Deutsche Telekom), Robert Raszuk (NTT), 213 Jakob Heitz (Cisco), Warren Kumari (Google), Ben Maddison 214 (Workonline), Randy Bush, Brian Dickson and Gyan Mishra (Verizon) for 215 their support, insightful reviews, and comments. 217 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 219 This section records the status of known implementations of the 220 protocol defined by this specification at the time of posting of this 221 Internet-Draft, and is based on a proposal described in RFC7942. The 222 description of implementations in this section is intended to assist 223 the IETF in its decision processes in progressing drafts to RFCs. 224 Please note that the listing of any individual implementation here 225 does not imply endorsement by the IETF. Furthermore, no effort has 226 been spent to verify the information presented here that was supplied 227 by IETF contributors. This is not intended as, and must not be 228 construed to be, a catalog of available implementations or their 229 features. Readers are advised to note that other implementations may 230 exist. 232 The below table provides an overview (as of the moment of writing) of 233 which vendors have produced implementation of inbound prefix limits. 234 Each table cell shows the applicable configuration keywords if the 235 vendor implemented the feature. 237 +--------------+----------------------+-----------------------------+ 238 | Vendor | Type A Pre-Policy | Type B Post-Policy | 239 +--------------+----------------------+-----------------------------+ 240 | Cisco IOS XR | | maximum-prefix | 241 +--------------+----------------------+-----------------------------+ 242 | Cisco IOS XE | | maximum-prefix | 243 +--------------+----------------------+-----------------------------+ 244 | Juniper | prefix-limit | accepted-prefix-limit, or | 245 | Junos OS | | prefix-limit combined with | 246 | | | 'keep none' | 247 +--------------+----------------------+-----------------------------+ 248 | Nokia SR OS | prefix-limit | | 249 +--------------+----------------------+-----------------------------+ 250 | NIC.CZ BIRD | 'import keep | 'import limit' or 'receive | 251 | | filtered' combined | limit' | 252 | | with 'receive limit' | | 253 +--------------+----------------------+-----------------------------+ 254 | OpenBSD | max-prefix | | 255 | OpenBGPD | | | 256 +--------------+----------------------+-----------------------------+ 257 | Arista EOS | maximum-routes | maximum-accepted-routes | 258 +--------------+----------------------+-----------------------------+ 259 | Huawei VRPv5 | peer route-limit | | 260 +--------------+----------------------+-----------------------------+ 261 | Huawei VRPv8 | peer route-limit | peer route-limit accept- | 262 | | | prefix | 263 +--------------+----------------------+-----------------------------+ 265 First presented by Snijders at [RIPE77] 267 Table 1: Maximum prefix limits capabilities per implementation 269 9. Appendix: Implementation Guidance 271 TBD 273 10. References 275 10.1. Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, 279 DOI 10.17487/RFC2119, March 1997, 280 . 282 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 283 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 284 DOI 10.17487/RFC4271, January 2006, 285 . 287 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 288 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 289 May 2017, . 291 10.2. Informative References 293 [I-D.ietf-idr-bgp-model] 294 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 295 YANG Model for Service Provider Networks", draft-ietf-idr- 296 bgp-model-10 (work in progress), November 2020. 298 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 299 and B. Dickson, "Problem Definition and Classification of 300 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 301 2016, . 303 [RIPE77] Snijders, J., "Robust Routing Policy Architecture", May 304 2018, . 307 Authors' Addresses 309 Melchior Aelmans 310 Juniper Networks 311 Boeing Avenue 240 312 Schiphol-Rijk 1119 PZ 313 The Netherlands 315 Email: maelmans@juniper.net 317 Massimiliano Stucchi 318 Independent 320 Email: max@stucchi.ch 321 Job Snijders 322 Fastly 323 Theodorus Majofskistraat 100 324 Amsterdam 1065 SZ 325 The Netherlands 327 Email: job@fastly.com