idnits 2.17.1 draft-sas-idr-maxprefix-inbound-01.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 (October 16, 2020) is 1288 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 282, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-09 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: April 19, 2021 J. Snijders 7 NTT 8 October 16, 2020 10 BGP Maximum Prefix Limits Inbound 11 draft-sas-idr-maxprefix-inbound-01 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 April 19, 2021. 44 Copyright Notice 46 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . 4 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 9.5.2 Post-Policy Inbound Maximum Prefix Limits 165 RFC4271 describes a Policy Information Base (PIB) that contains 166 local policies that can be applied to the information in the 167 Routing Information Base (RIB). The post-policy limit uses the 168 number of NLRIs per Address Family Identifier (AFI) per 169 Subsequent Address Family Identifier (SAFI), after application 170 of the Import Policy as input into its threshold comparisons. 171 For example, when an operator configures the post-policy limit 172 for IPv4 Unicast to be 50 on a given EBGP session, and the 173 other BGP speaker announces a hundred IPv4 Unicast routes of 174 which none are accepted as a result of the local import policy 175 (and thus not considered for the Loc-RIB by the local BGP 176 speaker), the session is not terminated. 178 Post-policy limits are useful to help prevent FIB exhaustion 179 and prevent accidental BGP session teardown due to prefixes not 180 accepted by policy anyway. 182 5. Security Considerations 184 Maximum Prefix Limits are an essential tool for routing operations 185 and SHOULD be used to increase stability for the global routing 186 ecosystem. 188 6. IANA Considerations 190 This memo requests that IANA updates the name of subcode "Maximum 191 Number of Prefixes Reached" to "Threshold exceeded: Maximum Number of 192 Prefixes Received" in the "Cease NOTIFICATION message subcodes" 193 registry under the "Border Gateway Protocol (BGP) Parameters" group. 195 7. Acknowledgments 197 The authors would like to thank Saku Ytti and John Heasley (NTT 198 Ltd.), Jeff Haas, Colby Barth and John Scudder (Juniper Networks), 199 Martijn Schmidt (i3D.net), Teun Vink (BIT), Sabri Berisha (eBay), 200 Martin Pels (Quanza), Steven Bakker (AMS-IX), Aftab Siddiqui (ISOC), 201 Yu Tianpeng, Ruediger Volk (Deutsche Telekom), Robert Raszuk 202 (Bloomberg), Jakob Heitz (Cisco), Warren Kumari (Google), Ben 203 Maddison (Workonline), Randy Bush, Brian Dickson and Gyan Mishra 204 (Verizon) for their support, insightful reviews, and comments. 206 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 208 This section records the status of known implementations of the 209 protocol defined by this specification at the time of posting of this 210 Internet-Draft, and is based on a proposal described in RFC7942. The 211 description of implementations in this section is intended to assist 212 the IETF in its decision processes in progressing drafts to RFCs. 213 Please note that the listing of any individual implementation here 214 does not imply endorsement by the IETF. Furthermore, no effort has 215 been spent to verify the information presented here that was supplied 216 by IETF contributors. This is not intended as, and must not be 217 construed to be, a catalog of available implementations or their 218 features. Readers are advised to note that other implementations may 219 exist. 221 The below table provides an overview (as of the moment of writing) of 222 which vendors have produced implementation of inbound prefix limits. 223 Each table cell shows the applicable configuration keywords if the 224 vendor implemented the feature. 226 +--------------+----------------------+-----------------------------+ 227 | Vendor | Type A Pre-Policy | Type B Post-Policy | 228 +--------------+----------------------+-----------------------------+ 229 | Cisco IOS XR | | maximum-prefix | 230 +--------------+----------------------+-----------------------------+ 231 | Cisco IOS XE | | maximum-prefix | 232 +--------------+----------------------+-----------------------------+ 233 | Juniper | prefix-limit | accepted-prefix-limit, or | 234 | Junos OS | | prefix-limit combined with | 235 | | | 'keep none' | 236 +--------------+----------------------+-----------------------------+ 237 | Nokia SR OS | prefix-limit | | 238 +--------------+----------------------+-----------------------------+ 239 | NIC.CZ BIRD | 'import keep | 'import limit' or 'receive | 240 | | filtered' combined | limit' | 241 | | with 'receive limit' | | 242 +--------------+----------------------+-----------------------------+ 243 | OpenBSD | max-prefix | | 244 | OpenBGPD | | | 245 +--------------+----------------------+-----------------------------+ 246 | Arista EOS | maximum-routes | maximum-accepted-routes | 247 +--------------+----------------------+-----------------------------+ 248 | Huawei VRPv5 | peer route-limit | | 249 +--------------+----------------------+-----------------------------+ 250 | Huawei VRPv8 | peer route-limit | peer route-limit accept- | 251 | | | prefix | 252 +--------------+----------------------+-----------------------------+ 254 First presented by Snijders at [RIPE77] 256 Table 1: Maximum prefix limits capabilities per implementation 258 9. Appendix: Implementation Guidance 260 TBD 262 10. References 264 10.1. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, 268 DOI 10.17487/RFC2119, March 1997, 269 . 271 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 272 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 273 DOI 10.17487/RFC4271, January 2006, 274 . 276 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 277 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 278 May 2017, . 280 10.2. Informative References 282 [I-D.ietf-idr-bgp-model] 283 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 284 YANG Model for Service Provider Networks", draft-ietf-idr- 285 bgp-model-09 (work in progress), June 2020. 287 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 288 and B. Dickson, "Problem Definition and Classification of 289 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 290 2016, . 292 [RIPE77] Snijders, J., "Robust Routing Policy Architecture", May 293 2018, . 296 Authors' Addresses 298 Melchior Aelmans 299 Juniper Networks 300 Boeing Avenue 240 301 Schiphol-Rijk 1119 PZ 302 The Netherlands 304 Email: maelmans@juniper.net 306 Massimiliano Stucchi 307 Independent 309 Email: max@stucchi.ch 310 Job Snijders 311 NTT Ltd. 312 Theodorus Majofskistraat 100 313 Amsterdam 1065 SZ 314 The Netherlands 316 Email: job@ntt.net