idnits 2.17.1 draft-ietf-idr-bgp-extended-messages-31.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 107: '...tise this capability MUST NOT send BGP...' RFC 2119 keyword, line 108: '...xtended Messages MUST NOT be sent to i...' RFC 2119 keyword, line 120: '... Messages SHOULD advertise the BGP E...' RFC 2119 keyword, line 122: '... MAY send Extended Messages to its p...' RFC 2119 keyword, line 126: '... MUST be capable of receiving a mess...' (12 more instances...) -- 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 (June 30, 2019) is 1760 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) == Missing Reference: 'RFC2119' is mentioned on line 29, but not defined == Missing Reference: 'RFC8174' is mentioned on line 29, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4272 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft IIJ & Arrcus 4 Updates: 4271 (if approved) K. Patel 5 Intended status: Standards Track Arrcus, Inc. 6 Expires: January 1, 2020 D. Ward 7 Cisco Systems 8 June 30, 2019 10 Extended Message support for BGP 11 draft-ietf-idr-bgp-extended-messages-31 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 January 1, 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 To advertise the BGP Extended Message Capability to a peer, a BGP 99 speaker uses BGP Capabilities Advertisement [RFC5492]. By 100 advertising the BGP Extended Message Capability to a peer, a BGP 101 speaker conveys that it is able to send, receive, and properly 102 handle, see Section 4, BGP Extended Messages. 104 The BGP Extended Message Capability is a new BGP Capability [RFC5492] 105 defined with Capability code 6 and Capability length 0. 107 A peer which does not advertise this capability MUST NOT send BGP 108 Extended Messages, and BGP Extended Messages MUST NOT be sent to it. 110 Peers that wish to use the BGP Extended Message capability must 111 support Error Handling for BGP UPDATE Messages per [RFC7606]. 113 4. Operation 115 The Extended Message Capability applies to all messages except for 116 the OPEN and KEEPALIVE messages. The former exception is to reduce 117 the complexity of providing a backward compatibility 119 A BGP speaker that is capable of sending and receiving BGP Extended 120 Messages SHOULD advertise the BGP Extended Message Capability to its 121 peers using BGP Capabilities Advertisement [RFC5492]. A BGP speaker 122 MAY send Extended Messages to its peer only if both peers have 123 negotiated the Extended Message Capability with each other. 125 An implementation that advertises support for BGP Extended Messages 126 MUST be capable of receiving a message with a Length up to and 127 including 65,535 octets. 129 Applications generating information which might be encapsulated 130 within BGP messages MUST limit the size of their payload to take the 131 maximum message size into account. 133 If a BGP message with a Length lgreater than 4,096 octets is received 134 by a BGP listener who has not advertised the Extended Message 135 Capability, the listener MUST treat this as a malformed message, and 136 MUST generate a NOTIFICATION with the Error Subcode set to Bad 137 Message Length (see [RFC4271] Sec 6.1). 139 A BGP announcement will (policy, best path, etc., allowing) propagate 140 throughout the BGP speaking Internet; and hence to BGP speakers which 141 may not have the Extended Message capability. Therefore, an 142 announcement in an Extended Message where the size of the attribute 143 set plus the NLRI can not be decomposed to 4,096 octets or less may 144 cause lack of reachability. 146 A speaker capable of BGP Extended Messages having a mixture of peers 147 some of which have not exchanged the BGP Extended Message capability, 148 may receive an announcement from one of its capable peers that would 149 (due to the new AS on the path, new added attributes, etc.) produce 150 an ongoing announcement that would be over 4,096 octets. When 151 propagating that update onward to a neighbor with which it has not 152 negotiated the BGP Extended Message capability, the sender SHOULD try 153 to reduce the outgoing message size by downgrading BGPsec to BGP4, 154 decomposing a multi-NLRI update producing multiple updates with fewer 155 NLRI per update, removing attributes eligible under the attribute 156 discard approach of [RFC7606], etc. If the resulting message would 157 still be over the 4,096 octet limit, the sender SHOULD treat-as- 158 withdraw per [RFC7606]. 160 In an iBGP mesh, all peers SHOULD support the BGP Extended Message 161 Capability and [RFC7606]. Only then is it consistent to deploy with 162 eBGP peers. 164 During the incremental deployment of BGP Extended Messages and 165 [RFC7606] in an iBGP mesh, or with eBGP peers, the operator should 166 monitor any routes dropped as "treat-as-withdraw". 168 It is RECOMMENDED that BGP protocol developers and implementers are 169 conservative in their application and use of Extended Messages. 170 Future protocol specifications will need to describe how to handle 171 peers which can only accommodate 4,096 octet messages. 173 5. Error Handling 175 A BGP speaker that has the ability to use Extended Messages but has 176 not advertised the BGP Extended Messages capability, presumably due 177 to configuration, SHOULD NOT accept an Extended Message. A speaker 178 SHOULD NOT implement a more liberal policy accepting BGP Extended 179 Messages. 181 A BGP speaker that does not advertise the BGP Extended Messages 182 capability might also genuinely not support Extended Messages. Such 183 a speaker will follow the error handling procedures of [RFC4271] if 184 it receives an Extended Message. Similarly, any speaker that treats 185 an improper Extended Message as a fatal error, MUST treat it 186 similarly. 188 The inconsistency between the local and remote BGP speakers MUST be 189 flagged to the network operator through standard operational 190 interfaces. The information should include the NLRI and as much 191 relevant information as reasonably possible. 193 6. Changes to RFC4271 195 [RFC4271] states "The value of the Length field MUST always be at 196 least 19 and no greater than 4,096." This document changes the 197 latter number to 65,535 for all except the OPEN and KEEPALIVE 198 messages. 200 [RFC4271] Sec 6.1, specifies raising an error if the length of a 201 message is over 4,096 octets. For all messages except the OPEN 202 message, if the receiver has advertised the BGP Extended Messages 203 Capability, this document raises that limit to 65,535. 205 7. IANA Considerations 207 The IANA has made an early allocation for this new BGP Extended 208 Message Capability referring to this document. 210 Registry: BGP Capability Code 212 Value Description Document 213 ----- ----------------------------------- ------------- 214 6 BGP-Extended Message [this draft] 216 8. Security Considerations 218 This extension to BGP does not change BGP's underlying security 219 issues; see [RFC4272]. 221 Section 5 allows a receiver to accept an Extended Message even though 222 it had not advertised the capability. This slippery slope could lead 223 to sloppy implementations sending Extended Messages when the receiver 224 is not prepared to deal with them, e.g. to peer groups. At best, 225 this will result in errors; at worst, buffer overflows. 227 Due to increased memory requirements for buffering, there may be 228 increased exposure to resource exhaustion, intentional or 229 unintentional. 231 As this draft requires support for [RFC7606] update error handling, 232 it inherits the security considerations of [RFC7606]. BGP peers may 233 avoid such issues by using Authenticated Encryption with additional 234 Data (AEAD) ciphers [RFC5116] and discard messages that do not 235 verify. 237 If a remote attacker is able to craft a large BGP Extended Message to 238 send on a path where one or more peers do not support BGP Extended 239 Messages, peers which support BGP Extended Messages may act to reduce 240 the outgoing message, see Section 4, and in doing so produce a 241 downgrade attack, e.g. convert BGPsec to BGP4. 243 If a remote attacker is able to craft a large BGP Extended Message to 244 send on a path where one or more peers do not support BGP Extended 245 Messages, peers which support BGP Extended Messages may incur 246 resource load (processing, message resizing, etc.) reformatting the 247 large messages. Worse, ([RFC7606] "treat-as-withdraw" may 248 consistently withdraw announcements causing inconsistent routing. 250 BGP routes are filtered by policies set by the operators. 251 Implementations may provide policies to filter routes that would 252 cause the "treat-as-withdraw" from being passed by an extended 253 message speaker. 255 9. Acknowledgments 257 The authors thank Alvaro Retana for an amazing review, Enke Chen, 258 Susan Hares, John Scudder, John Levine, and Job Snijders for their 259 input; and Oliver Borchert and Kyehwan Lee for their implementations 260 and testing. 262 10. References 264 10.1. Normative References 266 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 267 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 268 DOI 10.17487/RFC4271, January 2006, 269 . 271 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 272 RFC 4272, DOI 10.17487/RFC4272, January 2006, 273 . 275 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 276 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 277 . 279 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 280 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 281 2009, . 283 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 284 Patel, "Revised Error Handling for BGP UPDATE Messages", 285 RFC 7606, DOI 10.17487/RFC7606, August 2015, 286 . 288 10.2. Informative References 290 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 291 S. Ray, "North-Bound Distribution of Link-State and 292 Traffic Engineering (TE) Information Using BGP", RFC 7752, 293 DOI 10.17487/RFC7752, March 2016, 294 . 296 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 297 Specification", RFC 8205, DOI 10.17487/RFC8205, September 298 2017, . 300 Authors' Addresses 302 Randy Bush 303 IIJ & Arrcus 304 5147 Crystal Springs 305 Bainbridge Island, Washington 98110 306 US 308 Email: randy@psg.com 310 Keyur Patel 311 Arrcus, Inc. 313 Email: keyur@arrcus.com 315 Dave Ward 316 Cisco Systems 317 170 W. Tasman Drive 318 San Jose, CA 95134 319 US 321 Email: dward@cisco.com