idnits 2.17.1 draft-spaghetti-idr-bgp-sendholdtimer-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (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 20, 2021) is 1094 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: 'RFC8174' is defined on line 263, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR J. Snijders 3 Internet-Draft Fastly 4 Updates: 4271 (if approved) B. Cartwright-Cox 5 Intended status: Standards Track April 20, 2021 6 Expires: October 22, 2021 8 Border Gateway Protocol 4 (BGP-4) Send Hold Timer 9 draft-spaghetti-idr-bgp-sendholdtimer-00 11 Abstract 13 This document defines the SendHoldTimer session attribute for the 14 Border Gateway Protocol (BGP) Finite State Machine (FSM). A session 15 should be terminated if the TCP receive window is zero for the 16 duration of the Send Hold Timer, in this situation the peer is 17 expected to terminate the connection. For robustness, this document 18 specifies that the local system should also close the connection. 19 This document updates RFC4271. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 22, 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. Specification of the Send Hold Timer . . . . . . . . . . . . 3 63 2.1. Session Attributes . . . . . . . . . . . . . . . . . . . 3 64 2.2. SendHoldTimer_Expires Event Definition . . . . . . . . . 3 65 3. Send Hold Timer Expired Error Handling . . . . . . . . . . . 4 66 4. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 8.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 This document defines the SendHoldTimer session attribute for the 78 Border Gateway Protocol (BGP) [RFC4271] Finite State Machine (FSM) 79 defined in section 8. 81 As BGP runs over TCP [RFC0793] it is possible for hosts in the 82 ESTABLISHED state to encounter a BGP peer that is advertising a TCP 83 Receive Window (RCV.WND) of size zero and thus preventing the local 84 system from sending KEEPALIVE, CEASE, WITHDRAW, UPDATE, or other 85 critical messages across the wire. At the moment of writing, most 86 BGP implementations appear unable to handle this situation in a 87 robust fashion. 89 Not terminating a stuck BGP session can result in Denial Of Service, 90 the subsequent failure to generate and deliver BGP WITHDRAW messages 91 to other BGP peers of the local system is detrimental to all 92 participants of the inter-domain routing system. This phenomena is 93 theorised to have contributed to IP traffic backholing events in 94 global Internet routing system [l3outage] 95 This specification intends to improve this situation by requiring 96 sessions to be terminated if the TCP receive window is zero for the 97 duration of the Send Hold Timer. Through codification of the 98 aforementioned requirement, operators will benefit from consistent 99 behavior across different BGP implementations. 101 BGP speakers following this specification do not exclusively rely on 102 remote systems robustly closing connections, but will also locally 103 close connections. 105 2. Specification of the Send Hold Timer 107 BGP speakers are implemented following a conceptual model "BGP Finite 108 State Machine" (FSM), which is outlined in section 8 of [RFC4271]. 109 This specification updates the BGP FSM as following: 111 2.1. Session Attributes 113 The following mandatory session attributes are added to paragraph 6 114 of Section 8, before "The state session attribute indicates the 115 current state of the BGP FSM": 117 9) SendHoldTimer 119 10) SendHoldTime (an initial value of 4 minutes is recommended) 121 2.2. SendHoldTimer_Expires Event Definition 123 Section 8.1.3 [RFC4271] is extended as following: 125 Event XX: SendHoldTimer_Expires 126 Definition : An event generated when the SendHoldTimer expires. 127 Status: Mandatory 129 If the SendHoldTimer_Expires (Event XX), the local system: 131 - logs a message with the BGP Error Notification Code "Send Hold 132 Timer Expired", 134 - releases all BGP resources, 136 - sets the ConnectRetryTimer to zero, 138 - drops the TCP connection, 140 - increments the ConnectRetryCounter, 141 - (optionally) performs peer oscillation damping if the 142 DampPeerOscillations attribute is set to TRUE, and 144 - changes its state to Idle. 146 If the DelayOpenTimer_Expires event (Event 12) occurs in the Connect 147 state, the local system: 149 - sends an OPEN message to its peer, 151 - sets the HoldTimer to a large value, and 153 - sets the SendHoldTimer to a large value, and 155 - changes its state to OpenSent. 157 If the DelayOpen attribute is set to FALSE, the local system: 159 - stops the ConnectRetryTimer (if running) and sets the 160 ConnectRetryTimer to zero, 162 - completes BGP initialization 164 - sends an OPEN message to its peer, 166 - sets the HoldTimer to a large value, and 168 - changes its state to OpenSent. 170 A HoldTimer value of 4 minutes is suggested. 172 A SendHoldTimer value of 4 minutes is suggested. 174 3. Send Hold Timer Expired Error Handling 176 If a system does not send and receive successive KEEPALIVE, UPDATE, 177 and/or NOTIFICATION messages within the period specified in the Send 178 Hold Time, then the BGP connection is closed and a log message is 179 emitted. 181 4. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 183 This section records the status of known implementations of the 184 protocol defined by this specification at the time of posting of this 185 Internet-Draft, and is based on a proposal described in RFC 7942. 186 The description of implementations in this section is intended to 187 assist the IETF in its decision processes in progressing drafts to 188 RFCs. Please note that the listing of any individual implementation 189 here does not imply endorsement by the IETF. Furthermore, no effort 190 has been spent to verify the information presented here that was 191 supplied by IETF contributors. This is not intended as, and must not 192 be construed to be, a catalog of available implementations or their 193 features. Readers are advised to note that other implementations may 194 exist. 196 According to RFC 7942, "this will allow reviewers and working groups 197 to assign due consideration to documents that have the benefit of 198 running code, which may serve as evidence of valuable experimentation 199 and feedback that have made the implemented protocols more mature. 200 It is up to the individual working groups to use this information as 201 they see fit". 203 o OpenBGPD [openbgpd] 205 While not a BGP implementation, as a result of investigation into 206 this phenomena, the Linux TCP implementation TCP_USER_TIMEOUT option 207 was improved, allowing easier termination of TCP sessions which are 208 not progressing data [TCP_USER_TIMEOUT]. 210 5. Acknowledgements 212 The authors would like to thank William McCall for their helpful 213 review of this document. 215 6. Security Considerations 217 This specification addresses the vulnerability of a BGP speaker to a 218 potential attack whereby a BGP peer can pretend to be unable to 219 process BGP messages and in doing so create a scenario where the 220 local system is poisoned with stale routing information. 222 There are three detrimental aspects to the problem of not robustly 223 handling 'stuck' peers: 225 Failure to send BGP messages to a peer implies the peer is 226 operating based on stale routing information. 228 Failure to disconnect from a 'stuck' peer hinders the local 229 system's ability to construct a non-stale local Routing 230 Information Base (RIB). 232 Failure to disconnect from a 'stuck' peer hinders the local 233 system's ability to inform other BGP peers with current network 234 reachability information. 236 In other respects, this specification does not change BGP's security 237 characteristics. 239 7. IANA Considerations 241 This document requests IANA to assign a value named "Send Hold Timer 242 Expired" in the "BGP Error (Notification) Codes" sub-registry under 243 the "Border Gateway Protocol (BGP) Parameters" registry. 245 8. References 247 8.1. Normative References 249 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 250 RFC 793, DOI 10.17487/RFC0793, September 1981, 251 . 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, 255 DOI 10.17487/RFC2119, March 1997, 256 . 258 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 259 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 260 DOI 10.17487/RFC4271, January 2006, 261 . 263 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 264 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 265 May 2017, . 267 8.2. Informative References 269 [l3outage] 270 Reuters, "Level 3 problem sparks temporary outage for some 271 U.S. telecomms", August 2020, 272 . 275 [openbgpd] 276 Jeker, C., "bgpd send side hold timer", December 2020, 277 . 279 [TCP_USER_TIMEOUT] 280 Chen, E., "[Idr] TCP & BGP: Some don't send terminate BGP 281 when holdtimer expired, because TCP recv window is 0", 282 January 2021, . 285 Authors' Addresses 287 Job Snijders 288 Fastly 289 Amsterdam 290 Netherlands 292 Email: job@fastly.com 294 Ben Cartwright-Cox 295 London 296 United Kingdom 298 Email: ben@benjojo.co.uk