idnits 2.17.1 draft-sas-idr-maxprefix-inbound-00.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 (April 15, 2020) is 1472 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) == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-08 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing J. Snijders 3 Internet-Draft NTT 4 Updates: 4271 (if approved) M. Aelmans 5 Intended status: Standards Track Juniper Networks 6 Expires: October 17, 2020 M. Stucchi 7 Independent 8 April 15, 2020 10 BGP Maximum Prefix Limits Inbound 11 draft-sas-idr-maxprefix-inbound-00 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 October 17, 2020. 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. BGP Yang Model Considerations - PERHAPS REMOVE BEFORE 65 PUBLICATION . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 5. Changes to RFC4271 Section 9 . . . . . . . . . . . . . . . . 4 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 70 9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 71 10. Appendix: Implementation Guidance . . . . . . . . . . . . . . 6 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 11.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 This document updates [RFC4271] by revising control mechanism which 80 limit the negative impact of route leaks [RFC7908] and/or resource 81 exhaustion in Border Gateway Protocol (BGP) implementations. While 82 [RFC4271] described methods to tear down BGP sessions or discard 83 UPDATES after certain thresholds are exceeded, some nuances in this 84 specification were missing resulting in inconsistencies between BGP 85 implementations. 87 2. Changes to RFC4271 Section 6 89 This section updates [RFC4271] to specify what events can result in 90 AutomaticStop (Event 8) in the BGP FSM. 92 The following paragraph replaces the second paragraph of Section 6.7 93 (Cease), which starts with "A BGP speaker MAY support" and ends with 94 "The speaker MAY also log this locally.": 96 A BGP speaker MAY support the ability to impose a locally- 97 configured, upper bound on the number of address prefixes the 98 speaker is willing to accept from a neighbor (inbound maximum 99 prefix limit). The limit on the prefixes accepted from a neighbor 100 can be applied before policy processing (Pre-Policy) or after 101 policy processing (Post-Policy). When the upper bound is reached, 102 the speaker, under control of local configuration, either: 104 A. Discards new address prefixes from the neighbor (while 105 maintaining the BGP connection with the neighbor). 107 B. Terminates the BGP connection with the neighbor. 109 If the BGP speaker decides to terminate its BGP connection with a 110 neighbor because the number of address prefixes received from the 111 neighbor exceeds the locally-configured, upper bound, then the 112 speaker MUST send the neighbor a NOTIFICATION message with the 113 Error Code Cease. 115 +---------+---------------------------------------------------------+ 116 | Subcode | Symbolic Name | 117 +---------+---------------------------------------------------------+ 118 | 1 | Threshold exceeded: Maximum Number of Prefixes Received | 119 +---------+---------------------------------------------------------+ 121 The speaker MAY also log this locally. 123 3. Changes to RFC4271 Section 8 125 This section updates Section 8 [RFC4271], the paragraph that starts 126 with "One reason for an AutomaticStop event is" and ends with "The 127 local system automatically disconnects the peer." is replaced with: 129 Possible reasons for an AutomaticStop event are: A BGP speaker 130 receives an UPDATE messages with a number of prefixes for a given 131 peer such that the total prefixes received exceeds the maximum 132 number of prefixes configured (either "Pre-Policy" or "Post- 133 Policy"). The local system automatically disconnects the peer. 135 4. BGP Yang Model Considerations - PERHAPS REMOVE BEFORE PUBLICATION 137 According to [I-D.ietf-idr-bgp-model], in the container 'prefix- 138 limit', a leaf named "max-prefixes" exists. The authors recommend 139 the BGP Yang Model to be revised to contain the following leaves: 141 max-prefixes-inbound-pre-policy 143 max-prefixes-inbound-post-policy 145 In addition to the above, the authors suggest that the BGP Yang Model 146 is extended in such a way that for each peer, for each AFI/SAFI pair, 147 an operator can specify whether to tear down the session or discard 148 received updates. 150 5. 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 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 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 6. 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 7. 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 8. 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 213 (Bloomberg) and Jakob Heitz (Cisco) for their support, insightful 214 reviews, and comments. 216 9. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 218 This section records the status of known implementations of the 219 protocol defined by this specification at the time of posting of this 220 Internet-Draft, and is based on a proposal described in RFC7942. The 221 description of implementations in this section is intended to assist 222 the IETF in its decision processes in progressing drafts to RFCs. 223 Please note that the listing of any individual implementation here 224 does not imply endorsement by the IETF. Furthermore, no effort has 225 been spent to verify the information presented here that was supplied 226 by IETF contributors. This is not intended as, and must not be 227 construed to be, a catalog of available implementations or their 228 features. Readers are advised to note that other implementations may 229 exist. 231 The below table provides an overview (as of the moment of writing) of 232 which vendors have produced implementation of inbound prefix limits. 233 Each table cell shows the applicable configuration keywords if the 234 vendor implemented the feature. 236 +--------------+----------------------+-----------------------------+ 237 | Vendor | Type A Pre-Policy | Type B Post-Policy | 238 +--------------+----------------------+-----------------------------+ 239 | Cisco IOS XR | | maximum-prefix | 240 +--------------+----------------------+-----------------------------+ 241 | Cisco IOS XE | | maximum-prefix | 242 +--------------+----------------------+-----------------------------+ 243 | Juniper | prefix-limit | accepted-prefix-limit, or | 244 | Junos OS | | prefix-limit combined with | 245 | | | 'keep none' | 246 +--------------+----------------------+-----------------------------+ 247 | Nokia SR OS | prefix-limit | | 248 +--------------+----------------------+-----------------------------+ 249 | NIC.CZ BIRD | 'import keep | 'import limit' or 'receive | 250 | | filtered' combined | limit' | 251 | | with 'receive limit' | | 252 +--------------+----------------------+-----------------------------+ 253 | OpenBSD | max-prefix | | 254 | OpenBGPD | | | 255 +--------------+----------------------+-----------------------------+ 256 | Arista EOS | maximum-routes | maximum-accepted-routes | 257 +--------------+----------------------+-----------------------------+ 258 | Huawei VRPv5 | peer route-limit | | 259 +--------------+----------------------+-----------------------------+ 260 | Huawei VRPv8 | peer route-limit | peer route-limit accept- | 261 | | | prefix | 262 +--------------+----------------------+-----------------------------+ 264 First presented by Snijders at [RIPE77] 266 Table 1: Maximum prefix limits capabilities per implementation 268 10. Appendix: Implementation Guidance 270 TBD 272 11. References 274 11.1. Normative References 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, 278 DOI 10.17487/RFC2119, March 1997, 279 . 281 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 282 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 283 DOI 10.17487/RFC4271, January 2006, 284 . 286 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 287 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 288 May 2017, . 290 11.2. Informative References 292 [I-D.ietf-idr-bgp-model] 293 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 294 YANG Model for Service Provider Networks", draft-ietf-idr- 295 bgp-model-08 (work in progress), February 2020. 297 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 298 and B. Dickson, "Problem Definition and Classification of 299 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 300 2016, . 302 [RIPE77] Snijders, J., "Robust Routing Policy Architecture", May 303 2018, . 306 Authors' Addresses 308 Job Snijders 309 NTT Ltd. 310 Theodorus Majofskistraat 100 311 Amsterdam 1065 SZ 312 The Netherlands 314 Email: job@ntt.net 316 Melchior Aelmans 317 Juniper Networks 318 Boeing Avenue 240 319 Schiphol-Rijk 1119 PZ 320 The Netherlands 322 Email: maelmans@juniper.net 323 Massimiliano Stucchi 324 Independent 326 Email: max@stucchi.ch