idnits 2.17.1 draft-sas-idr-maxprefix-outbound-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 : ---------------------------------------------------------------------------- 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 (October 16, 2020) is 1278 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 353, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-sas-idr-maxprefix-inbound-00 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-09 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: April 19, 2021 J. Snijders 7 NTT 8 October 16, 2020 10 Revised BGP Maximum Prefix Limits Outbound 11 draft-sas-idr-maxprefix-outbound-01 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 April 19, 2021. 45 Copyright Notice 47 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . 2 64 3. Changes to RFC4271 Section 8 . . . . . . . . . . . . . . . . 3 65 4. Changes to RFC4271 Section 9 . . . . . . . . . . . . . . . . 4 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 69 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 6 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 9.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 This document updates [RFC4271] by adding a control mechanism which 78 limits the negative impact of outbound route leaks [RFC7908] in order 79 to prevent resource exhaustion in Border Gateway Protocol (BGP) 80 implementations. [RFC4271] describes methods to tear down BGP 81 sessions or discard UPDATES after certain inbound thresholds are 82 exceeded. In addition to "inbound maximum prefix limits", this 83 document introduces a specification for "outbound maximum prefix 84 limits". [I-D.sas-idr-maxprefix-inbound] updates sections in 85 [RFC4271] to clarify "inbound maximum prefix limits". This documents 86 updates those sections again to add "outbound maximum prefix limits". 88 2. Changes to RFC4271 Section 6 90 This section updates [RFC4271] to specify what events can result in 91 AutomaticStop (Event 8) in the BGP FSM. 93 The following paragraph replaces the second paragraph of Section 6.7 94 (Cease), which starts with "A BGP speaker MAY support" and ends with 95 "The speaker MAY also log this locally.": 97 A BGP speaker MAY support the ability to impose a locally- 98 configured, upper bound on the number of address prefixes the 99 speaker is willing to accept from a neighbor (inbound maximum 100 prefix limit) or send to a neighbor (outbound prefix limit). The 101 limit on the prefixes accepted from a neighbor can be applied 102 before policy processing (Pre-Policy) or after policy processing 103 (Post-Policy). Outbound prefix limits MUST be measured after 104 policy since the Policy (even a policy of "send all") is run, 105 before determining what can be sent. When the upper bound is 106 reached, the speaker, under control of local configuration, 107 either: 109 A. Discards new address prefixes being sent to the neighbor while 110 maintaining the BGP connection with the neighbor. As these 111 prefixes are discared and their reachability information is 112 not sent to the neighbor it might lead to inconsistent routing 113 behaviour; 115 B. Sent all prefixes exceeding the threshold and generates a log; 117 C. Terminates the BGP session with the neighbor. This should be 118 done using a Hard Reset according to [RFC8538]. 120 If the BGP speaker uses option (b), where the limit causes a CEASE 121 Notification, then the CEASE error codes should use: 123 +---------+---------------------------------------------------------+ 124 | Subcode | Symbolic Name | 125 +---------+---------------------------------------------------------+ 126 | 1 | Threshold exceeded: Maximum Number of Prefixes Received | 127 | TBD | Threshold exceeded: Maximum Number of Prefixes Sent | 128 +---------+---------------------------------------------------------+ 130 The speaker MAY also log this locally. 132 3. Changes to RFC4271 Section 8 134 This section updates Section 8 [RFC4271], the paragraph that starts 135 with "One reason for an AutomaticStop event is" and ends with "The 136 local system automatically disconnects the peer." is replaced with: 138 Possible reasons for an AutomaticStop event are: A BGP speaker 139 receives an UPDATE messages with a number of prefixes for a given 140 peer such that the total prefixes received exceeds the maximum 141 number of prefixes configured (either "Pre-Policy" or "Post- 142 Policy"), or announces more prefixes than through local 143 configuration allowed to. The local system automatically 144 disconnects the peer. 146 4. Changes to RFC4271 Section 9 148 This section updates [RFC4271] by adding a subsection after 149 Section 9.4 (Originating BGP routes) to specify various events that 150 can lead up to an AutomaticStop (Event 8) in the BGP FSM. 152 9.5 Maximum Prefix Limits 154 9.5.1 Pre-Policy Inbound Maximum Prefix Limits 156 The Adj-RIBs-In stores routing information learned from inbound 157 UPDATE messages that were received from another BGP speaker 158 Section 3.2 [RFC4271]. The pre-policy limit uses the number of 159 NLRIs per Address Family Identifier (AFI) per Subsequent 160 Address Family Identifier (SAFI) as input into its threshold 161 comparisons. For example, when an operator configures the pre- 162 policy limit for IPv4 Unicast to be 50 on a given EBGP session, 163 and the other BGP speaker announces its 51st IPv4 Unicast NLRI, 164 the session MUST be terminated. 166 Pre-policy limits are particularly useful to help dampen the 167 effects of full table route leaks and memory exhaustion when 168 the implementation stores rejected routes. 170 9.5.2 Post-Policy Inbound Maximum Prefix Limits 172 [RFC4271] describes a Policy Information Base (PIB) that 173 contains local policies that can be applied to the information 174 in the Routing Information Base (RIB). The post-policy limit 175 uses the number of NLRIs per Address Family Identifier (AFI) 176 per Subsequent Address Family Identifier (SAFI), after 177 application of the Import Policy as input into its threshold 178 comparisons. For example, when an operator configures the 179 post-policy limit for IPv4 Unicast to be 50 on a given EBGP 180 session, and the other BGP speaker announces a hundred IPv4 181 Unicast routes of which none are accepted as a result of the 182 local import policy (and thus not considered for the Loc-RIB by 183 the local BGP speaker), the session is not terminated. 185 Post-policy limits are useful to help prevent FIB exhaustion 186 and prevent accidental BGP session teardown due to prefixes not 187 accepted by policy anyway. 189 9.5.3 Outbound Maximum Prefix Limits 191 An operator MAY configure a BGP speaker to terminate its BGP 192 session with a neighbor when the number of address prefixes to 193 be advertised to that neighbor exceeds a locally configured 194 post-policy upper limit. The BGP speaker then MUST send the 195 neighbor a NOTIFICATION message with the Error Code "Cease" and 196 the Error Subcode "Threshold reached: Maximum Number of 197 Prefixes Sent". Implementations MAY support additional 198 actions. The Hard Cease action is defined in [RFC8538]. 200 Reporting when thresholds have been exceeded is an 201 implementation specific consideration, but SHOULD include 202 methods such as Syslog [RFC5424]. By definition, Outbound 203 Maximum Prefix Limits are Post-Policy. 205 The Adj-RIBs-Out stores information selected by the local BGP 206 speaker for advertisement to its neighbors. The routing 207 information stored in the Adj-RIBs-Out will be carried in the 208 local BGP speaker's UPDATE messages and advertised to its 209 neighbors Section 3.2 [RFC4271]. The Outbound Maximum Prefix 210 Limit uses the number of NLRIs per Address Family Identifier 211 (AFI) per Subsequent Address Family Identifier (SAFI), after 212 application of the Export Policy, as input into its threshold 213 comparisons. For example, when an operator configures the 214 Outbound Maximum Prefix Limit for IPv4 Unicast to be 50 on a 215 given EBGP session, and were about to announce its 51st IPv4 216 Unicast NLRI to the other BGP speaker as a result of the local 217 export policy, the session MUST be terminated. 219 Outbound Maximum Prefix Limits are useful to help dampen the 220 negative effects of a misconfiguration in local policy. In 221 many cases, it would be more desirable to tear down a BGP 222 session rather than causing or propagating a route leak. 224 5. Security Considerations 226 Maximum Prefix Limits are an essential tool for routing operations 227 and SHOULD be used to increase stability. They provide a first-line 228 mechanism to avoid route leaks and to avoid unintended routing 229 suggestions to happen between neighbors. Implementing this measures 230 is only one of the building blocks you need to provide full security, 231 but it is important to build a modular defense system. 233 Stability for the routing table is also an important aspect for 234 implementing the measures included in this draft. Ensuring that 235 neighbors will not receive an amount of routes that would overload 236 their routing platform contributes to the stability of 237 interconnections and of the Internet as a whole. 239 6. IANA Considerations 241 This memo requests that IANA assigns a new subcode named "Threshold 242 exceeded: Maximum Number of Prefixes Sent" in the "Cease NOTIFICATION 243 message subcodes" registry under the "Border Gateway Protocol (BGP) 244 Parameters" group. 246 7. Acknowledgments 248 The authors would like to thank Saku Ytti and John Heasley (NTT 249 Ltd.), Jeff Haas, Colby Barth and John Scudder (Juniper Networks), 250 Martijn Schmidt (i3D.net), Teun Vink (BIT), Sabri Berisha (eBay), 251 Martin Pels (Quanza), Steven Bakker (AMS-IX), Aftab Siddiqui (ISOC), 252 Yu Tianpeng, Ruediger Volk (Deutsche Telekom), Robert Raszuk 253 (Bloomberg), Jakob Heitz (Cisco), Warren Kumari (Google), Ben 254 Maddison (Workonline), Randy Bush, Brian Dickson and Gyan Mishra 255 (Verizon) for their support, insightful reviews, and comments. 257 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 259 This section records the status of known implementations of the 260 protocol defined by this specification at the time of posting of this 261 Internet-Draft, and is based on a proposal described in RFC7942. The 262 description of implementations in this section is intended to assist 263 the IETF in its decision processes in progressing drafts to RFCs. 264 Please note that the listing of any individual implementation here 265 does not imply endorsement by the IETF. Furthermore, no effort has 266 been spent to verify the information presented here that was supplied 267 by IETF contributors. This is not intended as, and must not be 268 construed to be, a catalog of available implementations or their 269 features. Readers are advised to note that other implementations may 270 exist. 272 The table below provides an overview (as of the moment of writing) of 273 which vendors have produced implementations of inbound or outbound 274 maximum prefix limits. Each table cell shows the applicable 275 configuration keywords if the vendor implemented the feature. 277 +----------+-------------+---------------------+--------------------+ 278 | Vendor | Inbound | Inbound Post-Policy | Outbound | 279 | | Pre-Policy | | | 280 +----------+-------------+---------------------+--------------------+ 281 | Cisco | | maximum-prefix | | 282 | IOS XR | | | | 283 +----------+-------------+---------------------+--------------------+ 284 | Cisco | | maximum-prefix | | 285 | IOS XE | | | | 286 +----------+-------------+---------------------+--------------------+ 287 | Juniper | prefix- | accepted-prefix- | advertise-prefix- | 288 | Junos OS | limit | limit, or prefix- | limit * | 289 | | | limit combined with | | 290 | | | 'keep none' | | 291 +----------+-------------+---------------------+--------------------+ 292 | Nokia SR | prefix- | | | 293 | OS | limit | | | 294 +----------+-------------+---------------------+--------------------+ 295 | NIC.CZ | 'import | 'import limit' or | export limit | 296 | BIRD | keep | 'receive limit' | | 297 | | filtered' | | | 298 | | combined | | | 299 | | with | | | 300 | | 'receive | | | 301 | | limit' | | | 302 +----------+-------------+---------------------+--------------------+ 303 | OpenBSD | max-prefix | | | 304 | OpenBGPD | | | | 305 +----------+-------------+---------------------+--------------------+ 306 | Arista | maximum- | maximum-accepted- | | 307 | EOS | routes | routes | | 308 +----------+-------------+---------------------+--------------------+ 309 | Huawei | peer route- | | | 310 | VRPv5 | limit | | | 311 +----------+-------------+---------------------+--------------------+ 312 | Huawei | peer route- | peer route-limit | | 313 | VRPv8 | limit | accept-prefix | | 314 +----------+-------------+---------------------+--------------------+ 316 First presented by Job Snijders at [RIPE77] 318 Table 1: Maximum prefix limits capabilities per implementation 320 *In testing stage 322 9. References 324 9.1. Normative References 326 [I-D.sas-idr-maxprefix-inbound] 327 Snijders, J., Aelmans, M., and s. stucchi- 328 lists@glevia.com, "BGP Maximum Prefix Limits Inbound", 329 draft-sas-idr-maxprefix-inbound-00 (work in progress), 330 April 2020. 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, 334 DOI 10.17487/RFC2119, March 1997, 335 . 337 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 338 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 339 DOI 10.17487/RFC4271, January 2006, 340 . 342 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 343 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 344 May 2017, . 346 [RFC8538] Patel, K., Fernando, R., Scudder, J., and J. Haas, 347 "Notification Message Support for BGP Graceful Restart", 348 RFC 8538, DOI 10.17487/RFC8538, March 2019, 349 . 351 9.2. Informative References 353 [I-D.ietf-idr-bgp-model] 354 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 355 YANG Model for Service Provider Networks", draft-ietf-idr- 356 bgp-model-09 (work in progress), June 2020. 358 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 359 DOI 10.17487/RFC5424, March 2009, 360 . 362 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 363 and B. Dickson, "Problem Definition and Classification of 364 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 365 2016, . 367 [RIPE77] Snijders, J., "Robust Routing Policy Architecture", May 368 2018, . 371 Authors' Addresses 373 Melchior Aelmans 374 Juniper Networks 375 Boeing Avenue 240 376 Schiphol-Rijk 1119 PZ 377 The Netherlands 379 Email: maelmans@juniper.net 381 Massimiliano Stucchi 382 Independent 384 Email: max@stucchi.ch 386 Job Snijders 387 NTT Ltd. 388 Theodorus Majofskistraat 100 389 Amsterdam 1065 SZ 390 The Netherlands 392 Email: job@ntt.net