draft-ietf-idr-bgp-extended-messages-36.txt   rfc8654.txt 
Network Working Group R. Bush Internet Engineering Task Force (IETF) R. Bush
Internet-Draft Arrcus & IIJ Request for Comments: 8654 Arrcus & IIJ
Updates: 4271 (if approved) K. Patel Updates: 4271 K. Patel
Intended status: Standards Track Arrcus, Inc. Category: Standards Track Arrcus, Inc.
Expires: February 17, 2020 D. Ward ISSN: 2070-1721 D. Ward
Cisco Systems Cisco Systems
August 16, 2019 October 2019
Extended Message support for BGP Extended Message Support for BGP
draft-ietf-idr-bgp-extended-messages-36
Abstract Abstract
The BGP specification mandates a maximum BGP message size of 4,096 The BGP specification (RFC 4271) mandates a maximum BGP message size
octets. As BGP is extended to support newer AFI/SAFIs and other of 4,096 octets. As BGP is extended to support new Address Family
features, there is a need to extend the maximum message size beyond Identifiers (AFIs), Subsequent AFIs (SAFIs), and other features,
4,096 octets. This document updates the BGP specification RFC4271 by there is a need to extend the maximum message size beyond 4,096
extending the maximum message size from 4,096 octets to 65,535 octets octets. This document updates the BGP specification by extending the
for all except the OPEN and KEEPALIVE messages. maximum message size from 4,096 octets to 65,535 octets for all
messages except for OPEN and KEEPALIVE messages.
Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 17, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8654.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. BGP Extended Message . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language
3. Extended Message Capability for BGP . . . . . . . . . . . . . 3 2. BGP Extended Message
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. BGP Extended Message Capability
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 4. Operation
6. Changes to RFC4271 . . . . . . . . . . . . . . . . . . . . . 5 5. Error Handling
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Changes to RFC 4271
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. References
10.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.1. Normative References
10.2. Informative References . . . . . . . . . . . . . . . . . 7 9.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Acknowledgments
Authors' Addresses
1. Introduction 1. Introduction
The BGP specification [RFC4271] mandates a maximum BGP message size The BGP specification [RFC4271] mandates a maximum BGP message size
of 4,096 octets. As BGP is extended to support newer AFI/SAFIs and of 4,096 octets. As BGP is extended to support new AFIs, SAFIs, and
newer capabilities (e.g., BGPsec [RFC8205] and BGP-LS [RFC7752]), other capabilities (e.g., BGPsec [RFC8205] and BGP - Link State (BGP-
there is a need to extend the maximum message size beyond 4,096 LS) [RFC7752]), there is a need to extend the maximum message size
octets. This draft provides an extension to BGP to extend its beyond 4,096 octets. This document provides an extension to BGP to
message size limit from 4,096 octets to 65,535 octets for all except extend the message size limit from 4,096 octets to 65,535 octets for
the OPEN and KEEPALIVE messages. all messages except for OPEN and KEEPALIVE messages.
1.1. Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. BGP Extended Message 2. BGP Extended Message
A BGP message over 4,096 octets in length is a BGP Extended Message. A BGP message over 4,096 octets in length is a BGP Extended Message.
BGP Extended Messages have a maximum message size of 65,535 octets. BGP Extended Messages have a maximum message size of 65,535 octets.
The smallest message that may be sent consists of a BGP KEEPALIVE The smallest message that may be sent is a BGP KEEPALIVE, which
which consists of 19 octets. consists of 19 octets.
3. Extended Message Capability for BGP 3. BGP Extended Message Capability
The BGP Extended Message Capability is a new BGP Capability [RFC5492] The BGP Extended Message Capability is a new BGP capability [RFC5492]
defined with Capability code 6 and Capability length 0. defined with Capability Code 6 and Capability Length 0.
To advertise the BGP Extended Message Capability to a peer, a BGP To advertise the BGP Extended Message Capability to a peer, a BGP
speaker uses BGP Capabilities Advertisement [RFC5492]. By speaker uses BGP Capabilities Advertisement [RFC5492]. By
advertising the BGP Extended Message Capability to a peer, a BGP advertising the BGP Extended Message Capability to a peer, a BGP
speaker conveys that it is able to receive and properly handle, see speaker conveys that it is able to receive and properly handle BGP
Section 4, BGP Extended Messages. Extended Messages (see Section 4).
Peers that wish to use the BGP Extended Message capability MUST Peers that wish to use the BGP Extended Message Capability MUST
support Error Handling for BGP UPDATE Messages per [RFC7606]. support error handling for BGP UPDATE messages per [RFC7606].
4. Operation 4. Operation
The Extended Message Capability applies to all messages except for The BGP Extended Message Capability applies to all messages except
the OPEN and KEEPALIVE messages. The former exception is to reduce for OPEN and KEEPALIVE messages. These exceptions reduce the
the complexity of providing backward compatibility. complexity of providing backward compatibility.
A BGP speaker that is capable of receiving BGP Extended Messages A BGP speaker that is capable of receiving BGP Extended Messages
SHOULD advertise the BGP Extended Message Capability to its peers SHOULD advertise the BGP Extended Message Capability to its peers
using BGP Capabilities Advertisement [RFC5492]. A BGP speaker MAY using BGP Capabilities Advertisement [RFC5492]. A BGP speaker MAY
send Extended Messages to a peer only if the Extended Message send BGP Extended Messages to a peer only if the BGP Extended Message
Capability was received from that peer. Capability was received from that peer.
An implementation that advertises the BGP Extended Message capability An implementation that advertises the BGP Extended Message Capability
MUST be capable of receiving a message with a Length up to and MUST be capable of receiving a message with a length up to and
including 65,535 octets. including 65,535 octets.
Applications generating information which might be encapsulated Applications generating information that might be encapsulated within
within BGP messages MUST limit the size of their payload to take the BGP messages MUST limit the size of their payload to take the maximum
maximum message size into account. message size into account.
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 Section 8.
If a BGP message with a Length greater than 4,096 octets is received 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 by a BGP listener who has not advertised the BGP Extended Message
Capability, the listener will generate a NOTIFICATION with the Error Capability, the listener will generate a NOTIFICATION with the Error
Subcode set to Bad Message Length ([RFC4271] Sec 6.1). Subcode set to Bad Message Length ([RFC4271], Section 6.1).
A BGP UPDATE will (policy, best path, etc., allowing) typically 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
set plus the NLRI is larger than 4,096 octets may cause lack of attribute set plus the NLRI is larger than 4,096 octets may cause
reachability. lack of reachability.
A BGP speaker that has advertised the BGP Extended Message capability A BGP speaker that has advertised the BGP Extended Message Capability
to its peers, may receive an UPDATE from one of its peers that to its peers may receive an UPDATE from one of its peers that
produces an ongoing announcement that is larger than 4,096 octets. produces an ongoing announcement that is larger than 4,096 octets.
When propagating that UPDATE onward to a neighbor which has not When propagating that UPDATE onward to a neighbor that has not
advertised the BGP Extended Message capability, the speaker SHOULD advertised the BGP Extended Message Capability, the speaker SHOULD
try to reduce the outgoing message size by removing attributes try to reduce the outgoing message size by removing attributes
eligible under the "attribute discard" approach of [RFC7606]. If the eligible under the "attribute discard" approach of [RFC7606]. If the
message is still too big, then it must not be sent to the neighbor message is still too big, then it must not be sent to the neighbor
([RFC4271], Section 9.2). Additionally, if the NLRI was previously ([RFC4271], Section 9.2). Additionally, if the NLRI was previously
advertised to that peer, it must be withdrawn from service advertised to that peer, it must be withdrawn from service
([RFC4271], Section 9.1.3). ([RFC4271], Section 9.1.3).
If an Autonomous System (AS) has multiple internal BGP speakers and If an Autonomous System (AS) has multiple internal BGP speakers and
also has multiple external BGP neighbors, to present a consistent also has multiple external BGP neighbors, care must be taken to
external view care must be taken to ensure a consistent view within ensure a consistent view within the AS in order to present a
the AS. In the context of BGP Extended Messages, a consistent view consistent external view. In the context of BGP Extended Messages, a
can only be guaranteed if all the iBGP speakers advertise the BGP consistent view can only be guaranteed if all the Internal BGP (iBGP)
Extended Message capability. If that is not the case, then the speakers advertise the BGP Extended Message Capability. If that is
operator should consider whether the BGP Extended Message capability not the case, then the operator should consider whether or not the
should be advertised to external peers or not. BGP Extended Message Capability should be advertised to external
peers.
During the incremental deployment of BGP Extended Messages and During the incremental deployment of BGP Extended Messages and use of
[RFC7606] in an iBGP mesh, or with eBGP peers, the operator should the "attribute discard" approach of [RFC7606] in an iBGP mesh or with
monitor any routes dropped and any discarded attributes. External BGP (eBGP) peers, the operator should monitor any routes
dropped and any discarded attributes.
5. Error Handling 5. Error Handling
A BGP speaker that has the ability to use Extended Messages but has A BGP speaker that has the ability to use BGP Extended Messages but
not advertised the BGP Extended Messages capability, presumably due has not advertised the BGP Extended Message Capability, presumably
to configuration, MUST NOT accept an Extended Message. A speaker due to configuration, MUST NOT accept a BGP Extended Message. A
MUST NOT implement a more liberal policy accepting BGP Extended speaker MUST NOT implement a more liberal policy accepting BGP
Messages. Extended Messages.
A BGP speaker that does not advertise the BGP Extended Messages 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.
a speaker will follow the error handling procedures of [RFC4271] if Such a speaker will follow the error-handling procedures of [RFC4271]
it receives an Extended Message. Similarly, any speaker that treats if it receives a BGP Extended Message. Similarly, any speaker that
an improper Extended Message as a fatal error, MUST follow the error treats an improper BGP Extended Message as a fatal error MUST follow
handling procedures of [RFC4271]. the error-handling procedures of [RFC4271].
The UPDATE Message Error Handling, as specified in Section 6.3 of Error handling for UPDATE messages, as specified in Section 6.3 of
[RFC4271], is unchanged. However, if a NOTIFICATION is to be sent to [RFC4271], is unchanged. However, if a NOTIFICATION is to be sent to
a BGP speaker that has not advertised the BGP Extended Message a BGP speaker that has not advertised the BGP Extended Message
Capability, the size of the message MUST NOT exceed 4,096 octets. Capability, the size of the message MUST NOT exceed 4,096 octets.
It is RECOMMENDED that BGP protocol developers and implementers are It is RECOMMENDED that BGP protocol developers and implementers are
conservative in their application and use of Extended Messages. conservative in their application and use of BGP Extended Messages.
Future protocol specifications MUST describe how to handle peers Future protocol specifications MUST describe how to handle peers that
which can only accommodate 4,096 octet messages. can only accommodate 4,096 octet messages.
6. Changes to RFC4271 6. Changes to RFC 4271
[RFC4271] states "The value of the Length field MUST always be at [RFC4271] states "The value of the Length field MUST always be at
least 19 and no greater than 4,096." This document changes the least 19 and no greater than 4096." This document changes the latter
latter number to 65,535 for all except the OPEN and KEEPALIVE number to 65,535 for all messages except for OPEN and KEEPALIVE
messages. messages.
[RFC4271] Sec 6.1, specifies raising an error if the length of a Section 6.1 of [RFC4271] specifies raising an error if the length of
message is over 4,096 octets. For all messages except the OPEN a message is over 4,096 octets. For all messages except for OPEN and
message, if the receiver has advertised the BGP Extended Messages KEEPALIVE messages, if the receiver has advertised the BGP Extended
Capability, this document raises that limit to 65,535. Message Capability, this document raises that limit to 65,535.
7. IANA Considerations 7. IANA Considerations
The IANA has made an early allocation for this new BGP Extended IANA has made the following allocation in the "Capability Codes"
Message Capability referring to this document. registry:
Registry: Capability Codes +-------+----------------------+-----------+
| Value | Description | Reference |
+=======+======================+===========+
| 6 | BGP Extended Message | RFC 8654 |
+-------+----------------------+-----------+
Value Description Document Table 1: Addition to "Capability Codes"
----- ----------------------------------- ------------- Registry
6 BGP Extended Message [this draft]
8. Security Considerations 8. Security Considerations
This extension to BGP does not change BGP's underlying security This extension to BGP does not change BGP's underlying security
issues; [RFC4272]. issues [RFC4272].
Due to increased memory requirements for buffering, there may be 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. unintentional.
If a remote speaker is able to craft a large BGP Extended Message to 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 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 Messages, peers that support BGP Extended Messages may:
the outgoing message, see Section 4, and in 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 [RFC7606].
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 act to reduce
the outgoing message, see Section 4, and in doing so allow a
downgrade attack. This would only affect the attacker's message,
where 'downgrade' has questionable meaning.
If a remote speaker is able to craft a large BGP Extended Message to * act to reduce the outgoing message (see Section 4) and, in doing
send on a path where one or more peers do not support BGP Extended so, cause an attack by discarding attributes one or more of its
Messages, peers which support BGP Extended Messages may incur peers may be expecting. The attributes eligible under the
resource load (processing, message resizing, etc.) reformatting the "attribute discard" approach must have no effect on route
large messages. selection or installation [RFC7606].
9. Acknowledgments * act to reduce the outgoing message (see Section 4) and, in doing
so, allow a downgrade attack. This would only affect the
attacker's message, where 'downgrade' has questionable meaning.
The authors thank Alvaro Retana for an amazing review, Enke Chen, * incur resource load (processing, message resizing, etc.) when
Susan Hares, John Scudder, John Levine, and Job Snijders for their reformatting the large messages.
input; and Oliver Borchert and Kyehwan Lee for their implementations
and testing.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <http://www.rfc-editor.org/info/rfc5492>. 2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 9.2. Informative References
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006, RFC 4272, DOI 10.17487/RFC4272, January 2006,
<http://www.rfc-editor.org/info/rfc4272>. <https://www.rfc-editor.org/info/rfc4272>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>. 2017, <https://www.rfc-editor.org/info/rfc8205>.
Acknowledgments
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.
Authors' Addresses Authors' Addresses
Randy Bush Randy Bush
Arrcus & IIJ Arrcus & IIJ
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, WA 98110
US United States of America
Email: randy@psg.com Email: randy@psg.com
Keyur Patel Keyur Patel
Arrcus, Inc. Arrcus, Inc.
Email: keyur@arrcus.com Email: keyur@arrcus.com
Dave Ward Dave Ward
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US United States of America
Email: dward@cisco.com Email: dward@cisco.com
 End of changes. 53 change blocks. 
166 lines changed or deleted 158 lines changed or added

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