idnits 2.17.00 (12 Aug 2021) /tmp/idnits15568/draft-ietf-idr-bgp-extended-messages-36.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 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 -- The document date (August 16, 2019) is 1002 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Arrcus & IIJ 4 Updates: 4271 (if approved) K. Patel 5 Intended status: Standards Track Arrcus, Inc. 6 Expires: February 17, 2020 D. Ward 7 Cisco Systems 8 August 16, 2019 10 Extended Message support for BGP 11 draft-ietf-idr-bgp-extended-messages-36 13 Abstract 15 The BGP specification mandates a maximum BGP message size of 4,096 16 octets. As BGP is extended to support newer AFI/SAFIs and other 17 features, there is a need to extend the maximum message size beyond 18 4,096 octets. This document updates the BGP specification RFC4271 by 19 extending the maximum message size from 4,096 octets to 65,535 octets 20 for all except the OPEN and KEEPALIVE messages. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 26 "OPTIONAL" in this document are to be interpreted as described in BCP 27 14 [RFC2119] [RFC8174] when, and only when, they appear in all 28 capitals, as shown here. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on February 17, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. BGP Extended Message . . . . . . . . . . . . . . . . . . . . 2 66 3. Extended Message Capability for BGP . . . . . . . . . . . . . 3 67 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 69 6. Changes to RFC4271 . . . . . . . . . . . . . . . . . . . . . 5 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 10.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 The BGP specification [RFC4271] mandates a maximum BGP message size 81 of 4,096 octets. As BGP is extended to support newer AFI/SAFIs and 82 newer capabilities (e.g., BGPsec [RFC8205] and BGP-LS [RFC7752]), 83 there is a need to extend the maximum message size beyond 4,096 84 octets. This draft provides an extension to BGP to extend its 85 message size limit from 4,096 octets to 65,535 octets for all except 86 the OPEN and KEEPALIVE messages. 88 2. BGP Extended Message 90 A BGP message over 4,096 octets in length is a BGP Extended Message. 92 BGP Extended Messages have a maximum message size of 65,535 octets. 93 The smallest message that may be sent consists of a BGP KEEPALIVE 94 which consists of 19 octets. 96 3. Extended Message Capability for BGP 98 The BGP Extended Message Capability is a new BGP Capability [RFC5492] 99 defined with Capability code 6 and Capability length 0. 101 To advertise the BGP Extended Message Capability to a peer, a BGP 102 speaker uses BGP Capabilities Advertisement [RFC5492]. By 103 advertising the BGP Extended Message Capability to a peer, a BGP 104 speaker conveys that it is able to receive and properly handle, see 105 Section 4, BGP Extended Messages. 107 Peers that wish to use the BGP Extended Message capability MUST 108 support Error Handling for BGP UPDATE Messages per [RFC7606]. 110 4. Operation 112 The Extended Message Capability applies to all messages except for 113 the OPEN and KEEPALIVE messages. The former exception is to reduce 114 the complexity of providing backward compatibility. 116 A BGP speaker that is capable of receiving BGP Extended Messages 117 SHOULD advertise the BGP Extended Message Capability to its peers 118 using BGP Capabilities Advertisement [RFC5492]. A BGP speaker MAY 119 send Extended Messages to a peer only if the Extended Message 120 Capability was received from that peer. 122 An implementation that advertises the BGP Extended Message capability 123 MUST be capable of receiving a message with a Length up to and 124 including 65,535 octets. 126 Applications generating information which might be encapsulated 127 within BGP messages MUST limit the size of their payload to take the 128 maximum message size into account. 130 During the years of incremental deployment, speakers that are capable 131 of Extended Messages should not simply pack as many NLRI in a message 132 as they can, or otherwise unnecessarily generate UPDATES above the 133 4,096 octet pre- Extended Message limit, so as not to require 134 downstream routers to decompose for peers that do not support 135 Extended Messages. See Section 8. 137 If a BGP message with a Length greater than 4,096 octets is received 138 by a BGP listener who has not advertised the Extended Message 139 Capability, the listener will generate a NOTIFICATION with the Error 140 Subcode set to Bad Message Length ([RFC4271] Sec 6.1). 142 A BGP UPDATE will (policy, best path, etc., allowing) typically 143 propagate throughout the BGP speaking Internet; and hence to BGP 144 speakers which may not support Extended Messages. Therefore, an 145 announcement in an Extended Message where the size of the attribute 146 set plus the NLRI is larger than 4,096 octets may cause lack of 147 reachability. 149 A BGP speaker that has advertised the BGP Extended Message capability 150 to its peers, may receive an UPDATE from one of its peers that 151 produces an ongoing announcement that is larger than 4,096 octets. 152 When propagating that UPDATE onward to a neighbor which has not 153 advertised the BGP Extended Message capability, the speaker SHOULD 154 try to reduce the outgoing message size by removing attributes 155 eligible under the "attribute discard" approach of [RFC7606]. If the 156 message is still too big, then it must not be sent to the neighbor 157 ([RFC4271], Section 9.2). Additionally, if the NLRI was previously 158 advertised to that peer, it must be withdrawn from service 159 ([RFC4271], Section 9.1.3). 161 If an Autonomous System (AS) has multiple internal BGP speakers and 162 also has multiple external BGP neighbors, to present a consistent 163 external view care must be taken to ensure a consistent view within 164 the AS. In the context of BGP Extended Messages, a consistent view 165 can only be guaranteed if all the iBGP speakers advertise the BGP 166 Extended Message capability. If that is not the case, then the 167 operator should consider whether the BGP Extended Message capability 168 should be advertised to external peers or not. 170 During the incremental deployment of BGP Extended Messages and 171 [RFC7606] in an iBGP mesh, or with eBGP peers, the operator should 172 monitor any routes dropped and any discarded attributes. 174 5. Error Handling 176 A BGP speaker that has the ability to use Extended Messages but has 177 not advertised the BGP Extended Messages capability, presumably due 178 to configuration, MUST NOT accept an Extended Message. A speaker 179 MUST NOT implement a more liberal policy accepting BGP Extended 180 Messages. 182 A BGP speaker that does not advertise the BGP Extended Messages 183 capability might also genuinely not support Extended Messages. Such 184 a speaker will follow the error handling procedures of [RFC4271] if 185 it receives an Extended Message. Similarly, any speaker that treats 186 an improper Extended Message as a fatal error, MUST follow the error 187 handling procedures of [RFC4271]. 189 The UPDATE Message Error Handling, as specified in Section 6.3 of 190 [RFC4271], is unchanged. However, if a NOTIFICATION is to be sent to 191 a BGP speaker that has not advertised the BGP Extended Message 192 Capability, the size of the message MUST NOT exceed 4,096 octets. 194 It is RECOMMENDED that BGP protocol developers and implementers are 195 conservative in their application and use of Extended Messages. 196 Future protocol specifications MUST describe how to handle peers 197 which can only accommodate 4,096 octet messages. 199 6. Changes to RFC4271 201 [RFC4271] states "The value of the Length field MUST always be at 202 least 19 and no greater than 4,096." This document changes the 203 latter number to 65,535 for all except the OPEN and KEEPALIVE 204 messages. 206 [RFC4271] Sec 6.1, specifies raising an error if the length of a 207 message is over 4,096 octets. For all messages except the OPEN 208 message, if the receiver has advertised the BGP Extended Messages 209 Capability, this document raises that limit to 65,535. 211 7. IANA Considerations 213 The IANA has made an early allocation for this new BGP Extended 214 Message Capability referring to this document. 216 Registry: Capability Codes 218 Value Description Document 219 ----- ----------------------------------- ------------- 220 6 BGP Extended Message [this draft] 222 8. Security Considerations 224 This extension to BGP does not change BGP's underlying security 225 issues; [RFC4272]. 227 Due to increased memory requirements for buffering, there may be 228 increased exposure to resource exhaustion, intentional or 229 unintentional. 231 If a remote speaker is able to craft a large BGP Extended Message to 232 send on a path where one or more peers do not support BGP Extended 233 Messages, peers which support BGP Extended Messages may act to reduce 234 the outgoing message, see Section 4, and in doing so cause an attack 235 by discarding attributes its peer may be expecting. The attributes 236 eligible under the "attribute discard" must have no effect on route 237 selection or installation [RFC7606]. 239 If a remote speaker is able to craft a large BGP Extended Message to 240 send on a path where one or more peers do not support BGP Extended 241 Messages, peers which support BGP Extended Messages may act to reduce 242 the outgoing message, see Section 4, and in doing so allow a 243 downgrade attack. This would only affect the attacker's message, 244 where 'downgrade' has questionable meaning. 246 If a remote speaker is able to craft a large BGP Extended Message to 247 send on a path where one or more peers do not support BGP Extended 248 Messages, peers which support BGP Extended Messages may incur 249 resource load (processing, message resizing, etc.) reformatting the 250 large messages. 252 9. Acknowledgments 254 The authors thank Alvaro Retana for an amazing review, Enke Chen, 255 Susan Hares, John Scudder, John Levine, and Job Snijders for their 256 input; and Oliver Borchert and Kyehwan Lee for their implementations 257 and testing. 259 10. References 261 10.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 269 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 270 DOI 10.17487/RFC4271, January 2006, 271 . 273 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 274 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 275 2009, . 277 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 278 Patel, "Revised Error Handling for BGP UPDATE Messages", 279 RFC 7606, DOI 10.17487/RFC7606, August 2015, 280 . 282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 284 May 2017, . 286 10.2. Informative References 288 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 289 RFC 4272, DOI 10.17487/RFC4272, January 2006, 290 . 292 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 293 S. Ray, "North-Bound Distribution of Link-State and 294 Traffic Engineering (TE) Information Using BGP", RFC 7752, 295 DOI 10.17487/RFC7752, March 2016, 296 . 298 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 299 Specification", RFC 8205, DOI 10.17487/RFC8205, September 300 2017, . 302 Authors' Addresses 304 Randy Bush 305 Arrcus & IIJ 306 5147 Crystal Springs 307 Bainbridge Island, Washington 98110 308 US 310 Email: randy@psg.com 312 Keyur Patel 313 Arrcus, Inc. 315 Email: keyur@arrcus.com 317 Dave Ward 318 Cisco Systems 319 170 W. Tasman Drive 320 San Jose, CA 95134 321 US 323 Email: dward@cisco.com