Extended Message support for BGP
draft-ietf-idr-bgp-extended-messages-34
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8654.
|
|
|---|---|---|---|
| Authors | Randy Bush , Keyur Patel , David Ward | ||
| Last updated | 2019-07-30 | ||
| Replaces | draft-ymbk-bgp-extended-messages | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-33)
by Paul Kyzivat
Ready w/nits
RTGDIR Early review
(of
-11)
by Brian Weis
Has issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Susan Hares | ||
| Shepherd write-up | Show Last changed 2019-07-08 | ||
| IESG | IESG state | Became RFC 8654 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Needs a YES. Needs 7 more YES or NO OBJECTION positions to pass. |
||
| Responsible AD | Alvaro Retana | ||
| Send notices to | jgs@juniper.net, jie.dong@huawei.com, aretana.ietf@gmail.com | ||
| IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-idr-bgp-extended-messages-34
Bush, et al. Expires January 31, 2020 [Page 4] Internet-Draft Extended Message support for BGP July 2019 It is RECOMMENDED that BGP protocol developers and implementers are conservative in their application and use of Extended Messages. Future protocol specifications MUST describe how to handle peers which can only accommodate 4,096 octet messages. 6. Changes to RFC4271 [RFC4271] states "The value of the Length field MUST always be at least 19 and no greater than 4,096." This document changes the latter number to 65,535 for all except the OPEN and KEEPALIVE messages. [RFC4271] Sec 6.1, specifies raising an error if the length of a message is over 4,096 octets. For all messages except the OPEN message, if the receiver has advertised the BGP Extended Messages Capability, this document raises that limit to 65,535. 7. IANA Considerations The IANA has made an early allocation for this new BGP Extended Message Capability referring to this document. Registry: Capability Codes Value Description Document ----- ----------------------------------- ------------- 6 BGP Extended Message [this draft] 8. Security Considerations This extension to BGP does not change BGP's underlying security issues; [RFC4272]. Due to increased memory requirements for buffering, there may be increased exposure to resource exhaustion, intentional or unintentional. 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 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 Bush, et al. Expires January 31, 2020 [Page 5] Internet-Draft Extended Message support for BGP July 2019 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 send on a path where one or more peers do not support BGP Extended Messages, peers which support BGP Extended Messages may incur resource load (processing, message resizing, etc.) reformatting the large messages. 9. 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. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>. [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, <http://www.rfc-editor.org/info/rfc5492>. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>. Bush, et al. Expires January 31, 2020 [Page 6] Internet-Draft Extended Message support for BGP July 2019 10.2. Informative References [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>. [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <http://www.rfc-editor.org/info/rfc7752>. [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>. Authors' Addresses Randy Bush IIJ & Arrcus 5147 Crystal Springs Bainbridge Island, Washington 98110 US Email: randy@psg.com Keyur Patel Arrcus, Inc. Email: keyur@arrcus.com Dave Ward Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Email: dward@cisco.com Bush, et al. Expires January 31, 2020 [Page 7]