idnits 2.17.1 draft-ietf-idr-bgp-extended-messages-30.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 (March 26, 2019) is 1856 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) ** Downref: Normative reference to an Informational RFC: RFC 4272 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 2 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 Internet Initiative Japan 4 Updates: 4271 (if approved) K. Patel 5 Intended status: Standards Track Arrcus, Inc. 6 Expires: September 27, 2019 D. Ward 7 Cisco Systems 8 March 26, 2019 10 Extended Message support for BGP 11 draft-ietf-idr-bgp-extended-messages-30 13 Abstract 15 The BGP specification mandates a maximum BGP message size of 4096 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 4096 octets. This document updates the BGP specification RFC4271 by 19 providing an extension to BGP to extend its current maximum message 20 size from 4096 octets to 65535 octets for all except the OPEN 21 message. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 27 be interpreted as described in [RFC2119] only when they appear in all 28 upper case. They may also appear in lower or mixed case as English 29 words, without normative meaning. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 27, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. BGP Extended Message . . . . . . . . . . . . . . . . . . . . 2 67 3. Extended Message Capability for BGP . . . . . . . . . . . . . 3 68 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 70 6. Changes to RFC4271 . . . . . . . . . . . . . . . . . . . . . 4 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 10.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 The BGP specification [RFC4271] mandates a maximum BGP message size 82 of 4096 octets. As BGP is extended to support newer AFI/SAFIs and 83 newer capabilities (e.g., BGPsec, [RFC8205], BGP-LS, [RFC7752]), 84 there is a need to extend the maximum message size beyond 4096 85 octets. This draft provides an extension to BGP to extend its 86 current message size limit from 4096 octets to 65535 octets for all 87 except the OPEN message. 89 2. BGP Extended Message 91 A BGP message over 4096 octets in length is a BGP Extended Message. 93 BGP Extended Messages have maximum message size of 65535 octets. The 94 smallest message that may be sent consists of a BGP header without a 95 data portion (19 octets). 97 3. Extended Message Capability for BGP 99 To advertise the BGP Extended Message Capability to a peer, a BGP 100 speaker uses BGP Capabilities Advertisement [RFC5492]. By 101 advertising the BGP Extended Message Capability to a peer, a BGP 102 speaker conveys that it is able to send, receive, and properly handle 103 BGP Extended Messages. 105 The BGP Extended Message Capability is a new BGP Capability [RFC5492] 106 defined with Capability code 6 and Capability length 0. 108 A peer which does not advertise this capability MUST NOT send BGP 109 Extended Messages, and BGP Extended Messages MUST NOT be sent to it. 111 4. Operation 113 A BGP speaker that is capable of sending and receiving BGP Extended 114 Messages SHOULD advertise the BGP Extended Message Capability to the 115 peer using BGP Capabilities Advertisement [RFC5492]. A BGP speaker 116 MAY send Extended Messages to its peer only if it has fully exchanged 117 the Extended Message Capability with that peer. 119 The Extended Message Capability applies to all messages except for 120 the OPEN message. This exception is made to reduce complexity of 121 providing backward compatibility 123 An implementation that advertises support for BGP Extended Messages 124 MUST be capable of receiving a message with a length up to and 125 including 65535 octets. 127 Applications generating information which might be encapsulated 128 within BGP messages MUST limit the size of their payload to take the 129 maximum message size into account. 131 If a BGP update with a payload longer than 4096 octets is received by 132 a BGP listener who has neither advertised nor agreed to accept BGP 133 Extended Messages, the listener MUST treat this as a malformed update 134 message, and MUST raise an UPDATE Message Error (see [RFC4271] Sec 135 6.3). 137 A BGP announcement will, in the normal case, propagate throughout the 138 BGP speaking Internet; and there will undoubtedly be BGP speakers 139 which do not have the Extended Message capability. Therefore, having 140 an attribute set which can not be decomposed to 4096 octets or less 141 in an Extended Message will likely raise errors. 143 A BGP speaker with a mixture of peers some of which have negotiated 144 BGP Extended Message capability and some which have not, MUST 145 o support [RFC7606], and 146 o "treat as withdraw" (see [RFC7606]) a BGP attribute/NLRI pair 147 (defined as BGP Route) which is too large to be sent to a peer 148 which does not support BGP Extended Messages. 150 The BGP speaker MAY remove some BGP attributes which are eligible to 151 use the Attribute discard approach in [RFC7606]. 153 In an iBGP mesh, all peers SHOULD support the BGP Extended Message 154 Capability and [RFC7606]. Only then is it consistent to deploy with 155 eBGP peers. 157 During the incremental deployment of BGP Extended Messages and 158 [RFC7606] in an iBGP mesh, or with eBGP peers, the operator should 159 monitor any routes dropped as "treat as withdraw". 161 It is RECOMMENDED that BGP protocol developers and implementers are 162 conservative in their application and use of Extended Messages. 163 Future protocol specifications will need to describe how to handle 164 peers which can only accommodate 4096 octet messages. 166 5. Error Handling 168 A BGP speaker that has the ability to use Extended Messages but has 169 not advertised the BGP Extended Messages capability, presumably due 170 to configuration, SHOULD NOT accept an Extended Message. A speaker 171 SHOULD NOT implement a more liberal policy accepting BGP Extended 172 Messages. 174 A BGP speaker that does not advertise the BGP Extended Messages 175 capability might also genuinely not support Extended Messages. Such 176 a speaker will follow the error handling procedures of [RFC4271] if 177 it receives an Extended Message. Similarly, any speaker that treats 178 an improper Extended Message as a fatal error, MUST treat it 179 similarly. 181 The inconsistency between the local and remote BGP speakers MUST be 182 flagged to the network operator through standard operational 183 interfaces. The information should include the NLRI and as much 184 relevant information as reasonably possible. 186 6. Changes to RFC4271 188 [RFC4271] states "The value of the Length field MUST always be at 189 least 19 and no greater than 4096." This document changes the latter 190 number to 65535 for all except the OPEN message. 192 [RFC4271] Sec 6.1, specifies raising an error if the length of a 193 message is over 4096 octets. For all messages except the OPEN 194 message, if the receiver has advertised the BGP Extended Messages 195 Capability, this document raises that limit to 65535. 197 7. IANA Considerations 199 The IANA has made an early allocation for this new BGP Extended 200 Message Capability referring to this document. 202 Registry: BGP Capability Code 204 Value Description Document 205 ----- ----------------------------------- ------------- 206 6 BGP-Extended Message [this draft] 208 8. Security Considerations 210 This extension to BGP does not change BGP's underlying security 211 issues; see [RFC4272]. 213 Section 5 allows a receiver to accept an Extended Message even though 214 it had not advertised the capability. This slippery slope could lead 215 to sloppy implementations sending Extended Messages when the receiver 216 is not prepared to deal with them, e.g. to peer groups. At best, 217 this will result in errors; at worst, buffer overflows. 219 Due to increased memory requirements for buffering, there may be 220 increased exposure to resource exhaustion, intentional or 221 unintentional. 223 As this draft requires support for [RFC7606] update error handling, 224 it inherits the security considerations of [RFC7606]. BGP peers may 225 avoid such issues by using Authenticated Encryption with additional 226 Data (AEAD) ciphers [RFC5116] and discard messages that do not 227 verify. 229 If a remote attacker is able to craft a large BGP Extended Message to 230 send on a path where one or more peers do not support BGP Extended 231 Messages, peers which support BGP Extended Messages may incur 232 resource load (processing, message resizing, etc.) reformatting the 233 large messages. Worse, ([RFC7606] "treat as withdraw" may 234 consistently withdraw announcements causing inconsistent routing. 236 BGP routes are filtered by policies set by the operators. 237 Implementations may provide policies to filter routes that would 238 cause the "treat as withdraw" from being passed by an extended 239 message speaker. 241 9. Acknowledgments 243 The authors thank Alvaro Retana, Enke Chen, Susan Hares, John 244 Scudder, John Levine, and Job Snijders for their input; and Oliver 245 Borchert and Kyehwan Lee for their implementations and testing. 247 10. References 249 10.1. Normative References 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, 253 DOI 10.17487/RFC2119, March 1997, 254 . 256 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 257 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 258 DOI 10.17487/RFC4271, January 2006, 259 . 261 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 262 RFC 4272, DOI 10.17487/RFC4272, January 2006, 263 . 265 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 266 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 267 . 269 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 270 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 271 2009, . 273 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 274 Patel, "Revised Error Handling for BGP UPDATE Messages", 275 RFC 7606, DOI 10.17487/RFC7606, August 2015, 276 . 278 10.2. Informative References 280 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 281 S. Ray, "North-Bound Distribution of Link-State and 282 Traffic Engineering (TE) Information Using BGP", RFC 7752, 283 DOI 10.17487/RFC7752, March 2016, 284 . 286 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 287 Specification", RFC 8205, DOI 10.17487/RFC8205, September 288 2017, . 290 Authors' Addresses 292 Randy Bush 293 Internet Initiative Japan 294 5147 Crystal Springs 295 Bainbridge Island, Washington 98110 296 United States of America 298 Email: randy@psg.com 300 Keyur Patel 301 Arrcus, Inc. 303 Email: keyur@arrcus.com 305 Dave Ward 306 Cisco Systems 307 170 W. Tasman Drive 308 San Jose, CA 95134 309 United States of America 311 Email: dward@cisco.com