<?xmlversion="1.0"?>version='1.0' encoding='utf-8'?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd">"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8654" category="std"docName="draft-ietf-idr-bgp-extended-messages-36"consensus="true" ipr="trust200902"updates="4271"> <?rfc comments="yes"?> <?rfc compact="yes"?> <?rfc inline="yes"?> <?rfc sortrefs="yes"?> <?rfc subcompact="yes"?> <?rfc symrefs="yes"?> <?rfc toc="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc tocompact="yes"?>docName="draft-ietf-idr-bgp-extended-messages-36" updates="4271" obsoletes="" submissionType="IETF" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version="3"> <!-- xml2rfc v2v3 conversion 2.27.0 --> <front> <title abbrev="Extended MessagesupportSupport for BGP"> Extended MessagesupportSupport for BGP</title> <seriesInfo name="RFC" value="8654"/> <author fullname="Randy Bush" initials="R." surname="Bush"> <organization>Arrcus & IIJ</organization> <address> <postal> <street>5147 Crystal Springs</street> <city>Bainbridge Island</city><region>Washington</region><region>WA</region> <code>98110</code><country>US</country><country>United States of America</country> </postal> <email>randy@psg.com</email> </address> </author> <author fullname="Keyur Patel" initials="K" surname="Patel"> <organization>Arrcus, Inc.</organization> <address> <email>keyur@arrcus.com</email> </address> </author> <author fullname="Dave Ward" initials="D." surname="Ward"> <organization>Cisco Systems</organization> <address> <postal> <street>170 W. Tasman Drive</street> <city>San Jose</city> <region>CA</region> <code>95134</code><country>US</country><country>United States of America</country> </postal> <email>dward@cisco.com</email> </address> </author><date/><date month="October" year="2019" /> <abstract> <t>The BGP specification (RFC 4271) mandates a maximum BGP message size of 4,096 octets. As BGP is extended to supportnewer AFI/SAFIsnew Address Family Identifiers (AFIs), Subsequent AFIs (SAFIs), and other features, there is a need to extend the maximum message size beyond 4,096 octets. This document updates the BGP specificationRFC4271by extending the maximum message size from 4,096 octets to 65,535 octets for all messages exceptthefor OPEN and KEEPALIVE messages.</t> </abstract><note title="Requirements Language"> <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> </note></front> <middle> <section anchor="introduction"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>The BGP specification <xreftarget="RFC4271"/>target="RFC4271" format="default"/> mandates a maximum BGP message size of 4,096 octets. As BGP is extended to supportnewer AFI/SAFIsnew AFIs, SAFIs, andnewerother capabilities (e.g., BGPsec <xreftarget="RFC8205"/>target="RFC8205" format="default"/> andBGP-LSBGP - Link State (BGP-LS) <xreftarget="RFC7752"/>),target="RFC7752" format="default"/>), there is a need to extend the maximum message size beyond 4,096 octets. Thisdraftdocument provides an extension to BGP to extenditsthe message size limit from 4,096 octets to 65,535 octets for all messages exceptthefor OPEN and KEEPALIVE messages.</t> <section anchor="sec-term" numbered="true" toc="default"> <name>Requirements Language</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> </section> <section anchor="extmsg"title="BGPnumbered="true" toc="default"> <name>BGP ExtendedMessage">Message</name> <t>A BGP message over 4,096 octets in length is a BGP Extended Message.</t> <t>BGP Extended Messages have a maximum message size of 65,535 octets. The smallest message that may be sentconsists ofis a BGPKEEPALIVEKEEPALIVE, which consists of 19 octets.</t> </section> <sectiontitle="Extendednumbered="true" toc="default"> <name>BGP Extended MessageCapability for BGP">Capability</name> <t>The BGP Extended Message Capability is a new BGPCapabilitycapability <xreftarget="RFC5492"/>target="RFC5492" format="default"/> defined with CapabilitycodeCode 6 and CapabilitylengthLength 0.</t> <t>To advertise the BGP Extended Message Capability to a peer, a BGP speaker uses BGP Capabilities Advertisement <xreftarget="RFC5492"/>.target="RFC5492" format="default"/>. By advertising the BGP Extended Message Capability to a peer, a BGP speaker conveys that it is able to receive and properlyhandle, see <xref target="opns"/>,handle BGP ExtendedMessages.</t>Messages (see <xref target="opns" format="default"/>).</t> <t>Peers that wish to use the BGP Extended Messagecapability MUSTCapability <bcp14>MUST</bcp14> supportError Handlingerror handling for BGP UPDATEMessagesmessages per <xreftarget="RFC7606"/>.</t>target="RFC7606" format="default"/>.</t> </section> <section anchor="opns"title="Operation">numbered="true" toc="default"> <name>Operation</name> <t>The BGP Extended Message Capability applies to all messages except fortheOPEN and KEEPALIVE messages.The former exception is toThese exceptions reduce the complexity of providing backward compatibility.</t> <t>A BGP speaker that is capable of receiving BGP Extended MessagesSHOULD<bcp14>SHOULD</bcp14> advertise the BGP Extended Message Capability to its peers using BGP Capabilities Advertisement <xreftarget="RFC5492"/>.target="RFC5492" format="default"/>. A BGP speakerMAY<bcp14>MAY</bcp14> send BGP Extended Messages to a peer only if the BGP Extended Message Capability was received from that peer.</t> <t>An implementation that advertises the BGP Extended Messagecapability MUSTCapability <bcp14>MUST</bcp14> be capable of receiving a message with aLengthlength up to and including 65,535 octets.</t> <t>Applications generating informationwhichthat might be encapsulated within BGP messagesMUST<bcp14>MUST</bcp14> limit the size of their payload to take the maximum message size into account.</t><t>During the years of incremental deployment, speakers that are capable of Extended Messages should not simply pack as many NLRI in a message as they can, or otherwise unnecessarily generate UPDATES above the 4,096 octet pre- Extended Message limit, so as not to require downstream routers to decompose for peers that do not support Extended Messages. See <xref target="Security"/>.</t><t>If a BGP message with aLengthlength greater than 4,096 octets is received by a BGP listener who has not advertised the BGP Extended Message Capability, the listener will generate a NOTIFICATION with the Error Subcode set to Bad Message Length (<xreftarget="RFC4271"/> Sec 6.1).</t>target="RFC4271" sectionFormat="comma" section="6.1"/>).</t> <t>A BGP UPDATE will(policy,(if allowed by policy, best path,etc., allowing)etc.) typically propagate throughout theBGP speaking Internet;BGP-speaking Internet and hence to BGP speakerswhichthat may not support BGP Extended Messages. Therefore, an announcement inana BGP Extended Message where the size of the attribute set plus the NLRI is larger than 4,096 octets may cause lack of reachability.</t> <t>A BGP speaker that has advertised the BGP Extended MessagecapabilityCapability to itspeers,peers may receive an UPDATE from one of its peers that produces an ongoing announcement that is larger than 4,096 octets. When propagating that UPDATE onward to a neighborwhichthat has not advertised the BGP Extended Messagecapability,Capability, the speakerSHOULD<bcp14>SHOULD</bcp14> try to reduce the outgoing message size by removing attributes eligible under the "attribute discard" approach of <xreftarget="RFC7606"/>.target="RFC7606" format="default"/>. If the message is still too big, then it must not be sent to the neighbor (<xreftarget="RFC4271"/>, Section 9.2).target="RFC4271" sectionFormat="comma" section="9.2"/>). Additionally, if the NLRI was previously advertised to that peer, it must be withdrawn from service (<xreftarget="RFC4271"/>, Section 9.1.3).</t>target="RFC4271" sectionFormat="comma" section="9.1.3"/>). </t> <t>If an Autonomous System (AS) has multiple internal BGP speakers and also has multiple external BGP neighbors,to present a consistent external viewcare must be taken to ensure a consistent view within theAS.AS in order to present a consistent external view. In the context of BGP Extended Messages, a consistent view can only be guaranteed if all theiBGPInternal BGP (iBGP) speakers advertise the BGP Extended Messagecapability.Capability. If that is not the case, then the operator should consider whether or not the BGP Extended MessagecapabilityCapability should be advertised to externalpeers or not.</t>peers. </t> <t>During the incremental deployment of BGP Extended Messages and use of the "attribute discard" approach of <xreftarget="RFC7606"/>target="RFC7606" format="default"/> in an iBGPmesh,mesh or witheBGPExternal BGP (eBGP) peers, the operator should monitor any routes dropped and any discarded attributes.</t> </section> <sectiontitle="Error Handling" anchor="error">anchor="error" numbered="true" toc="default"> <name>Error Handling</name> <t>A BGP speaker that has the ability to use BGP Extended Messages but has not advertised the BGP ExtendedMessages capability,Message Capability, presumably due to configuration,MUST NOT<bcp14>MUST NOT</bcp14> acceptana BGP Extended Message. A speakerMUST NOT<bcp14>MUST NOT</bcp14> implement a more liberal policy accepting BGP Extended Messages.</t> <t>A BGP speaker that does not advertise the BGP ExtendedMessages capabilityMessage Capability might also genuinely not support BGP Extended Messages. Such a speaker will follow theerror handlingerror-handling procedures of <xreftarget="RFC4271"/>target="RFC4271" format="default"/> if it receivesana BGP Extended Message. Similarly, any speaker that treats an improper BGP Extended Message as a fatalerror, MUSTerror <bcp14>MUST</bcp14> follow theerror handlingerror-handling procedures of <xreftarget="RFC4271"/>.</t> <t> Thetarget="RFC4271" format="default"/>. </t> <t>Error handling for UPDATEMessage Error Handling,messages, as specified inSection 6.3 of<xreftarget="RFC4271"/>,target="RFC4271" sectionFormat="of" section="6.3"/>, is unchanged. However, if a NOTIFICATION is to be sent to a BGP speaker that has not advertised the BGP Extended Message Capability, the size of the messageMUST NOT<bcp14>MUST NOT</bcp14> exceed 4,096 octets.</t> <t>It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that BGP protocol developers and implementers are conservative in their application and use of BGP Extended Messages. Future protocol specificationsMUST<bcp14>MUST</bcp14> describe how to handle peerswhichthat can only accommodate 4,096 octet messages.</t> </section> <section anchor="rfc4171"title="Changesnumbered="true" toc="default"> <name>Changes toRFC4271">RFC 4271</name> <t><xreftarget="RFC4271"/>target="RFC4271" format="default"/> states "The value of the Length fieldMUST<bcp14>MUST</bcp14> always be at least 19 and no greater than4,096.”4096." This document changes the latter number to 65,535 for all messages exceptthefor OPEN and KEEPALIVE messages.</t> <t><xreftarget="RFC4271"/> Sec 6.1,target="RFC4271" sectionFormat="of" section="6.1"/> specifies raising an error if the length of a message is over 4,096 octets. For all messages exceptthefor OPENmessage,and KEEPALIVE messages, if the receiver has advertised the BGP ExtendedMessagesMessage Capability, this document raises that limit to 65,535.</t> </section> <section anchor="IANA"title="IANA Considerations"> <t>The IANAnumbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA has madean earlythe following allocationfor this new BGP Extended Message Capability referring to this document.</t> <figure> <artwork> Registry: Capability Codes Value Description Document ----- ----------------------------------- ------------- 6 BGP Extended Message [this draft] </artwork> </figure>in the "Capability Codes" registry:</t> <table anchor="ianaregistry" align="left"> <name>Addition to "Capability Codes" Registry</name> <thead> <tr> <th>Value</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>6</td> <td>BGP Extended Message</td> <td>RFC 8654</td> </tr> </tbody> </table> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This extension to BGP does not change BGP's underlying securityissues;issues <xreftarget="RFC4272"/>.</t>target="RFC4272" format="default"/>.</t> <t>Due to increased memory requirements for buffering, there may be increased exposure to resource exhaustion, intentional or unintentional.</t> <t>If a remote speaker is able to craft a large BGP Extended Message to send on a path where one or more peers do not support BGP Extended Messages, peerswhichthat support BGP Extended Messagesmay actmay: </t> <ul spacing="normal"> <li>act to reduce the outgoingmessage, seemessage (see <xreftarget="opns"/>, andtarget="opns" format="default"/>) and, in doingsoso, cause an attack by discarding attributes one or more of itspeerpeers may be expecting. The attributes eligible under the "attributediscard”discard" approach must have no effect on route selection or installation <xreftarget="RFC7606"/>.</t> <t>If a remote speaker is able to craft a large BGP Extended Message to send on a path where one or more peers do not support BGP Extended Messages, peers which support BGP Extended Messages may acttarget="RFC7606" format="default"/>.</li> <li>act to reduce the outgoingmessage, seemessage (see <xreftarget="opns"/>, andtarget="opns" format="default"/>) and, in doingsoso, allow a downgrade attack. This would only affect the attacker's message, where 'downgrade' has questionablemeaning.</t> <t>If a remote speaker is able to craft a large BGP Extended Message to send on a path where one or more peers do not support BGP Extended Messages, peers which support BGP Extended Messages may incurmeaning.</li> <li>incur resource load (processing, message resizing, etc.) when reformatting the largemessages.</t>messages.</li> </ul> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5492.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8205.xml"/> </references> </references> <sectionanchor="Acknowledgments" title="Acknowledgments">anchor="acknowledgements" numbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors thank Alvaro Retana for an amazingreview,review; Enke Chen, Susan Hares, John Scudder, John Levine, and Job Snijders for their input; and Oliver Borchert and Kyehwan Lee for their implementations and testing.</t> </section></middle> <back> <references title="Normative References"> <?rfc include="reference.RFC.2119"?> <?rfc include="reference.RFC.4271"?> <?rfc include="reference.RFC.5492"?> <?rfc include="reference.RFC.7606"?> <?rfc include="reference.RFC.8174"?> </references> <references title="Informative References"> <?rfc include="reference.RFC.4272"?> <?rfc include="reference.RFC.7752"?> <?rfc include="reference.RFC.8205"?> </references></back> </rfc>