rfc8654xml2.original.xml   rfc8654.xml 
<?xml version="1.0"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" docName="draft-ietf-idr-bgp-extended-messages-36" ipr="trust 200902" updates="4271"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc comments="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8654" category="std"
<?rfc compact="yes"?> consensus="true" ipr="trust200902" docName="draft-ietf-idr-bgp-extended-mes
<?rfc inline="yes"?> sages-36"
<?rfc sortrefs="yes"?> updates="4271" obsoletes="" submissionType="IETF" xml:lang="en"
<?rfc subcompact="yes"?> sortRefs="true" symRefs="true" tocInclude="true" version="3">
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<!-- xml2rfc v2v3 conversion 2.27.0 -->
<front> <front>
<title abbrev="Extended Message Support for BGP">
Extended Message Support for BGP</title>
<title abbrev="Extended Message support for BGP"> <seriesInfo name="RFC" value="8654"/>
Extended Message support for BGP</title>
<author fullname="Randy Bush" initials="R." surname="Bush"> <author fullname="Randy Bush" initials="R." surname="Bush">
<organization>Arrcus &amp; IIJ</organization> <organization>Arrcus &amp; IIJ</organization>
<address> <address>
<postal> <postal>
<street>5147 Crystal Springs</street> <street>5147 Crystal Springs</street>
<city>Bainbridge Island</city> <city>Bainbridge Island</city>
<region>Washington</region> <region>WA</region>
<code>98110</code> <code>98110</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>randy@psg.com</email> <email>randy@psg.com</email>
</address> </address>
</author> </author>
<author fullname="Keyur Patel" initials="K" surname="Patel">
<author fullname="Keyur Patel" initials="K" surname="Patel"> <organization>Arrcus, Inc.</organization>
<organization>Arrcus, Inc.</organization> <address>
<address> <email>keyur@arrcus.com</email>
<email>keyur@arrcus.com</email> </address>
</address> </author>
</author> <author fullname="Dave Ward" initials="D." surname="Ward">
<author fullname="Dave Ward" initials="D." surname="Ward">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street>170 W. Tasman Drive</street> <street>170 W. Tasman Drive</street>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code>95134</code> <code>95134</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>dward@cisco.com</email> <email>dward@cisco.com</email>
</address> </address>
</author> </author>
<date/> <date month="October" year="2019" />
<abstract>
<t>The BGP specification mandates a maximum BGP message size of 4,096 <abstract>
octets. As BGP is extended to support newer AFI/SAFIs and other <t>The BGP specification (RFC 4271) mandates a maximum BGP message size of
4,096
octets. As BGP is extended to support new Address Family Identifiers
(AFIs), Subsequent AFIs (SAFIs), and other
features, there is a need to extend the maximum message size beyond features, there is a need to extend the maximum message size beyond
4,096 octets. This document updates the BGP specification RFC4271 by 4,096 octets. This document updates the BGP specification by
extending the maximum message size from 4,096 octets to 65,535 octets extending the maximum message size from 4,096 octets to 65,535 octets
for all except the OPEN and KEEPALIVE messages.</t> for all messages except for OPEN and KEEPALIVE messages.</t>
</abstract> </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> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t>The BGP specification <xref target="RFC4271" format="default"/> mandate
<t>The BGP specification <xref target="RFC4271"/> mandates a maximum s a maximum
BGP message size of 4,096 octets. As BGP is extended to support BGP message size of 4,096 octets. As BGP is extended to support
newer AFI/SAFIs and newer capabilities (e.g., BGPsec <xref new AFIs, SAFIs, and other capabilities (e.g., BGPsec <xref
target="RFC8205"/> and BGP-LS <xref target="RFC7752"/>), there is a target="RFC8205" format="default"/> and BGP - Link
State (BGP-LS) <xref target="RFC7752" format="default"/>), there is a
need to extend the maximum message size beyond 4,096 octets. This need to extend the maximum message size beyond 4,096 octets. This
draft provides an extension to BGP to extend its message size limit document provides an extension to BGP to extend the message size limit
from 4,096 octets to 65,535 octets for all except the OPEN and from 4,096 octets to 65,535 octets for all messages except for OPEN and
KEEPALIVE messages.</t> KEEPALIVE messages.</t>
</section> <section anchor="sec-term" numbered="true" toc="default">
<name>Requirements Language</name>
<section anchor="extmsg" title="BGP Extended Message">
<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 <t>
octets. The smallest message that may be sent consists of a BGP The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
KEEPALIVE which consists of 19 octets.</t> IRED</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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section title="Extended Message Capability for BGP">
<t>The BGP Extended Message Capability is a new BGP Capability <xref
target="RFC5492"/> defined with Capability code 6 and Capability
length 0.</t>
<t>To advertise the BGP Extended Message Capability to a peer, a BGP
speaker uses BGP Capabilities Advertisement <xref
target="RFC5492"/>. By advertising the BGP Extended Message
Capability to a peer, a BGP speaker conveys that it is able to
receive and properly handle, see <xref target="opns"/>, BGP
Extended Messages.</t>
<t>Peers that wish to use the BGP Extended Message capability MUST
support Error Handling for BGP UPDATE Messages per <xref
target="RFC7606"/>.</t>
</section> </section>
<section anchor="extmsg" numbered="true" toc="default">
<name>BGP Extended 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 sent is a BGP
KEEPALIVE, which consists of 19 octets.</t>
</section>
<section numbered="true" toc="default">
<name>BGP Extended Message Capability</name>
<t>The BGP Extended Message Capability is a new BGP capability <xref
target="RFC5492" format="default"/> defined with Capability Code 6 and
Capability Length 0.</t>
<t>To advertise the BGP Extended Message Capability to a peer, a BGP
speaker uses BGP Capabilities Advertisement <xref 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 properly
handle BGP Extended Messages (see <xref target="opns"
format="default"/>).</t>
<t>Peers that wish to use the BGP Extended Message Capability <bcp14>MUST<
/bcp14>
support error handling for BGP UPDATE messages per <xref target="RFC7606"
format="default"/>.</t>
<section anchor="opns" title="Operation"> </section>
<section anchor="opns" numbered="true" toc="default">
<name>Operation</name>
<t>The Extended Message Capability applies to all messages except <t>The BGP Extended Message Capability applies to all messages except
for the OPEN and KEEPALIVE messages. The former exception is to for OPEN and KEEPALIVE messages. These exceptions
reduce the complexity of providing backward compatibility.</t> reduce the complexity of providing backward compatibility.</t>
<t>A BGP speaker that is capable of receiving BGP
<t>A BGP speaker that is capable of receiving BGP Extended Messages <bcp14>SHOULD</bcp14> advertise the BGP Extended Message
Extended Messages SHOULD advertise the BGP Extended Message
Capability to its peers using BGP Capabilities Advertisement <xref Capability to its peers using BGP Capabilities Advertisement <xref
target="RFC5492"/>. A BGP speaker MAY send Extended Messages to a target="RFC5492" format="default"/>. A BGP speaker <bcp14>MAY</bcp14>
peer only if the Extended Message Capability was received from that send BGP Extended Messages to a
peer only if the BGP Extended Message Capability was received from that
peer.</t> peer.</t>
<t>An implementation that advertises the BGP Extended Message <t>An implementation that advertises the BGP Extended Message
capability MUST be capable of receiving a message with a Length up Capability <bcp14>MUST</bcp14> be capable of receiving a message with a leng
th up
to and including 65,535 octets.</t> to and including 65,535 octets.</t>
<t>Applications generating information which might be encapsulated <t>Applications generating information that might be encapsulated
within BGP messages MUST limit the size of their payload to take the within BGP messages <bcp14>MUST</bcp14> limit the size of their payload to t
ake the
maximum message size into account.</t> maximum message size into account.</t>
<t>During the years of incremental deployment, speakers that are <t>If a BGP message with a length greater than 4,096 octets is
capable of Extended Messages should not simply pack as many NLRI in received by a BGP listener who has not advertised the BGP Extended
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 a Length greater than 4,096 octets is
received by a BGP listener who has not advertised the Extended
Message Capability, the listener will generate a NOTIFICATION with Message Capability, the listener will generate a NOTIFICATION with
the Error Subcode set to Bad Message Length (<xref the Error Subcode set to Bad Message Length (<xref target="RFC4271"
target="RFC4271"/> Sec 6.1).</t> sectionFormat="comma" section="6.1"/>).</t>
<t>A BGP UPDATE will (policy, best path, etc., allowing) typically <t>A BGP UPDATE will (if allowed by policy, best path, etc.) typically
propagate throughout the BGP speaking Internet; and hence to BGP propagate throughout the BGP-speaking Internet and hence to BGP
speakers which may not support Extended Messages. Therefore, an speakers that may not support BGP Extended Messages. Therefore, an
announcement in an Extended Message where the size of the attribute announcement in a BGP Extended Message where the size of the attribute
set plus the NLRI is larger than 4,096 octets may cause lack of set plus the NLRI is larger than 4,096 octets may cause lack of
reachability.</t> reachability.</t>
<t>A BGP speaker that has advertised the BGP Extended Message
<t>A BGP speaker that has advertised the BGP Extended Message Capability to its peers may receive an UPDATE from one of its peers
capability to its peers, may receive an UPDATE from one of its peers
that produces an ongoing announcement that is larger than 4,096 that produces an ongoing announcement that is larger than 4,096
octets. When propagating that UPDATE onward to a neighbor which has octets. When propagating that UPDATE onward to a neighbor that has
not advertised the BGP Extended Message capability, the speaker not advertised the BGP Extended Message Capability, the speaker
SHOULD try to reduce the outgoing message size by removing <bcp14>SHOULD</bcp14> try to reduce the outgoing message size by removing
attributes eligible under the "attribute discard" approach of <xref attributes eligible under the "attribute discard" approach of <xref target="
target="RFC7606"/>. If the message is still too big, then it must RFC7606" format="default"/>. If the message is still too big, then it must
not be sent to the neighbor (<xref target="RFC4271"/>, Section 9.2). not be sent to the neighbor (<xref target="RFC4271" sectionFormat="comma"
section="9.2"/>).
Additionally, if the NLRI was previously advertised to that peer, it Additionally, if the NLRI was previously advertised to that peer, it
must be withdrawn from service (<xref target="RFC4271"/>, Section must be withdrawn from service (<xref target="RFC4271"
9.1.3).</t> sectionFormat="comma" section="9.1.3"/>).
</t>
<t>If an Autonomous System (AS) has multiple internal BGP speakers <t>If an Autonomous System (AS) has multiple internal BGP speakers
and also has multiple external BGP neighbors, to present a and also has multiple external BGP neighbors, care must be taken to ensure a
consistent external view care must be taken to ensure a consistent consistent view within the
view within the AS. In the context of BGP Extended Messages, a AS in order to present a consistent
consistent view can only be guaranteed if all the iBGP speakers external view. In the context of BGP Extended Messages, a
advertise the BGP Extended Message capability. If that is not the consistent view can only be guaranteed if all the Internal BGP (iBGP) speake
case, then the operator should consider whether the BGP Extended rs
Message capability should be advertised to external peers or advertise the BGP Extended Message Capability. If that is not the
not.</t> case, then the operator should consider whether or not the BGP Extended
Message Capability should be advertised to external peers.
</t>
<t>During the incremental deployment of BGP Extended Messages and <t>During the incremental deployment of BGP Extended Messages and
<xref target="RFC7606"/> in an iBGP mesh, or with eBGP peers, the use of the "attribute discard" approach of <xref target="RFC7606"
format="default"/> in an iBGP mesh or with
External BGP (eBGP) peers, the
operator should monitor any routes dropped and any discarded operator should monitor any routes dropped and any discarded
attributes.</t> attributes.</t>
</section> </section>
<section anchor="error" numbered="true" toc="default">
<name>Error Handling</name>
<section title="Error Handling" anchor="error"> <t>A BGP speaker that has the ability to use BGP Extended Messages but
has not advertised the BGP Extended Message Capability, presumably
<t>A BGP speaker that has the ability to use Extended Messages but due to configuration, <bcp14>MUST NOT</bcp14> accept a BGP Extended Message.
has not advertised the BGP Extended Messages capability, presumably A
due to configuration, MUST NOT accept an Extended Message. A speaker <bcp14>MUST NOT</bcp14> implement a more liberal policy accepting BG
speaker MUST NOT implement a more liberal policy accepting BGP P
Extended Messages.</t> Extended Messages.</t>
<t>A BGP speaker that does not advertise the BGP Extended Messages <t>A BGP speaker that does not advertise the BGP Extended Message
capability might also genuinely not support Extended Messages. Such Capability might also genuinely not support BGP Extended Messages. Such
a speaker will follow the error handling procedures of <xref a speaker will follow the error-handling procedures of <xref
target="RFC4271"/> if it receives an Extended Message. Similarly, target="RFC4271" format="default"/> if it receives a BGP Extended Message.
any speaker that treats an improper Extended Message as a fatal Similarly,
error, MUST follow the error handling procedures of <xref any speaker that treats an improper BGP Extended Message as a fatal
target="RFC4271"/>.</t> error <bcp14>MUST</bcp14> follow the error-handling procedures of <xref
target="RFC4271" format="default"/>.
</t>
<t> The UPDATE Message Error Handling, as specified in Section 6.3 <t>Error handling for UPDATE messages, as specified in
of <xref target="RFC4271"/>, is unchanged. However, if a <xref target="RFC4271" sectionFormat="of" section="6.3"/>, is unchanged. Ho
wever, if a
NOTIFICATION is to be sent to a BGP speaker that has not advertised NOTIFICATION is to be sent to a BGP speaker that has not advertised
the BGP Extended Message Capability, the size of the message MUST the BGP Extended Message Capability, the size of the message <bcp14>MUST
NOT exceed 4,096 octets.</t> NOT</bcp14> exceed 4,096 octets.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that BGP protocol developers and imple
<t>It is RECOMMENDED that BGP protocol developers and implementers menters
are conservative in their application and use of Extended Messages. are conservative in their application and use of BGP Extended Messages.
Future protocol specifications MUST describe how to handle peers Future protocol specifications <bcp14>MUST</bcp14> describe how to handle pe
which can only accommodate 4,096 octet messages.</t> ers
that can only accommodate 4,096 octet messages.</t>
</section> </section>
<section anchor="rfc4171" title="Changes to RFC4271"> <section anchor="rfc4171" numbered="true" toc="default">
<t><xref target="RFC4271"/> states "The value of the Length field <name>Changes to RFC 4271</name>
MUST always be at least 19 and no greater than 4,096.” This document <t><xref target="RFC4271" format="default"/> states "The value of the Leng
changes the latter number to 65,535 for all except the OPEN and th field
<bcp14>MUST</bcp14> always be at least 19 and no greater than 4096." This d
ocument
changes the latter number to 65,535 for all messages except for OPEN and
KEEPALIVE messages.</t> KEEPALIVE messages.</t>
<t><xref target="RFC4271"/> Sec 6.1, specifies raising an error if <t><xref target="RFC4271" sectionFormat="of" section="6.1"/> specifies
the length of a message is over 4,096 octets. For all messages raising an error if the length of a message is over 4,096 octets. For
except the OPEN message, if the receiver has advertised the all messages except for OPEN and KEEPALIVE messages, if the receiver has a
BGP Extended Messages Capability, this document raises that dvertised the
limit to 65,535.</t> BGP Extended Message Capability, this document raises that limit to
65,535.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has made the following allocation in the "Capability Codes"
registry:</t>
<section anchor="IANA" title="IANA Considerations"> <table anchor="ianaregistry" align="left">
<name>Addition to "Capability Codes" Registry</name>
<t>The IANA has made an early allocation for this new BGP Extended <thead>
Message Capability referring to this document.</t> <tr>
<figure> <th>Value</th>
<artwork> <th>Description</th>
Registry: Capability Codes <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>6</td>
<td>BGP Extended Message</td>
<td>RFC 8654</td>
</tr>
</tbody>
</table>
Value Description Document
6 BGP Extended Message [this draft]
</artwork>
</figure>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>This extension to BGP does not change BGP's underlying security
<t>This extension to BGP does not change BGP's underlying security issues <xref target="RFC4272" format="default"/>.</t>
issues; <xref target="RFC4272"/>.</t> <t>Due to increased memory requirements for buffering, there may be
<t>Due to increased memory requirements for buffering, there may be
increased exposure to resource exhaustion, intentional or increased exposure to resource exhaustion, intentional or
unintentional.</t> unintentional.</t>
<t>If a remote speaker is able to craft a large BGP Extended Message <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 to send on a path where one or more peers do not support BGP
Extended Messages, peers which support BGP Extended Messages may act Extended Messages, peers that support BGP Extended Messages may:
to reduce the outgoing message, see <xref target="opns"/>, and in </t>
doing so cause an attack by discarding attributes its peer may be
expecting. The attributes eligible under the "attribute discard”
must have no effect on route selection or installation <xref
target="RFC7606"/>.</t>
<t>If a remote speaker is able to craft a large BGP Extended <ul spacing="normal">
Message to send on a path where one or more peers do not support BGP
Extended Messages, peers which support BGP Extended Messages may act
to reduce the outgoing message, see <xref target="opns"/>, and in
doing so allow a downgrade attack. This would only affect the
attacker's message, where 'downgrade' has questionable meaning.</t>
<t>If a remote speaker is able to craft a large BGP Extended <li>act to reduce the outgoing message (see <xref target="opns"
Message to send on a path where one or more peers do not support BGP format="default"/>) and, in doing so, cause an attack by discarding
Extended Messages, peers which support BGP Extended Messages may attributes one or more of its peers may be expecting. The attributes eligib
incur resource load (processing, message resizing, etc.) le under the
reformatting the large messages.</t> "attribute discard" approach must have no effect on route selection or
installation <xref target="RFC7606" format="default"/>.</li>
</section> <li>act to reduce the outgoing message (see <xref target="opns"
format="default"/>) and, in doing so, allow a downgrade attack. This
would only affect the attacker's message, where 'downgrade' has
questionable meaning.</li>
<li>incur resource load (processing, message resizing, etc.)
when reformatting the large messages.</li>
</ul>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>The authors thank Alvaro Retana for an amazing 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> </section>
</middle> </middle>
<back>
<back> <references>
<name>References</name>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2119"?> <name>Normative References</name>
<?rfc include="reference.RFC.4271"?>
<?rfc include="reference.RFC.5492"?> <xi:include
<?rfc include="reference.RFC.7606"?> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<?rfc include="reference.RFC.8174"?>
</references> <xi:include
<references title="Informative References"> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
<?rfc include="reference.RFC.4272"?>
<?rfc include="reference.RFC.7752"?> <xi:include
<?rfc include="reference.RFC.8205"?> 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> </references>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgments</name>
</back> <t>The authors thank Alvaro Retana for an amazing 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>
</back>
</rfc> </rfc>
 End of changes. 59 change blocks. 
228 lines changed or deleted 264 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/