idnits 2.17.00 (12 Aug 2021) /tmp/idnits19675/draft-ietf-idr-bgp-extended-messages-21.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). -- The document date (March 5, 2017) is 1903 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 == Outdated reference: draft-ietf-sidr-bgpsec-protocol has been published as RFC 8205 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 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 6, 2017 D. Ward 7 Cisco Systems 8 March 5, 2017 10 Extended Message support for BGP 11 draft-ietf-idr-bgp-extended-messages-21 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, there is a 17 need to extend the maximum message size beyond 4096 octets. This 18 document updates the BGP specification RFC4271 by providing an 19 extension to BGP to extend its current maximum message size from 4096 20 octets to 65535 octets. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 26 be interpreted as described in [RFC2119] only when they appear in all 27 upper case. They may also appear in lower or mixed case as English 28 words, without normative meaning. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 6, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. BGP Extended Message . . . . . . . . . . . . . . . . . . . . 2 66 3. Extended message Capability for BGP . . . . . . . . . . . . . 3 67 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 3 69 6. Changes to RFC4271 . . . . . . . . . . . . . . . . . . . . . 4 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 75 10.2. Informative References . . . . . . . . . . . . . . . . . 5 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 78 1. Introduction 80 The BGP specification [RFC4271] mandates a maximum BGP message size 81 of 4096 octets. As BGP is extended to support newer AFI/SAFIs and 82 newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-protocol]), there is 83 a need to extend the maximum message size beyond 4096 octets. This 84 draft provides an extension to BGP to extend its current message size 85 limit from 4096 octets to 65535 octets. 87 2. BGP Extended Message 89 A BGP message over 4096 octets in length is a BGP Extended Message. 91 BGP Extended Messages have maximum message size of 65535 octets. The 92 smallest message that may be sent consists of a BGP header without a 93 data portion (19 octets). 95 Multi-octet fields MUST be in network byte order. 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 A peer which does not advertise this capability MUST NOT send BGP 106 Extended Messages, and BGP Extended Messages MUST NOT be sent to it. 108 The BGP Extended Message Capability is a new BGP Capability [RFC5492] 109 defined with Capability code 6 and Capability length 0. 111 4. Operation 113 A BGP speaker that is willing to send and receive BGP Extended 114 Messages with a peer SHOULD advertise the BGP Extended Message 115 Capability to the peer using BGP Capabilities Advertisement 116 [RFC5492]. A BGP speaker MAY send Extended Messages to its peer only 117 if it has received the Extended Message Capability from that peer. 119 Currently, the Extended Message Capability only applies to UPDATE 120 messages. 122 An implementation that advertises support for BGP Extended Messages 123 MUST be capable of receiving an UPDATE message with a length up to 124 and including 65535 octets. 126 Applications generating information which might be encapsulated 127 within BGP messages MUST limit the size of their payload to take the 128 maximum message size into account. 130 A BGP announcement will, in the normal case, propagate throughout the 131 BGP speaking Internet; and there will undoubtedly be BGP speakers 132 which do not have the Extended Message capability. Therefore putting 133 an attribute which can not be decomposed to 4096 octets or less in an 134 Extended Message is a sure path to routing failure. 136 5. Error Handling 138 A BGP speaker that has the ability to use Extended Messages but has 139 not advertised the BGP Extended Messages capability, presumably due 140 to configuration, SHOULD NOT accept an Extended Message. A speaker 141 MAY implement a more liberal policy and accept Extended Messages, 142 even from a peer to which it has not advertised the capability, in 143 the interest of preserving the BGP session if at all possible. 145 A BGP speaker that does not advertise the BGP Extended Messages 146 capability might also genuinely not support Extended Messages. Such 147 a speaker would be expected to follow the error handling procedures 148 of [RFC4271] if it receives an Extended Message. Similarly, any 149 speaker that treats an improper Extended Message as a fatal error, 150 MUST treat it similarly. 152 The inconsistency between the local and remote BGP speakers MUST be 153 flagged to the network operator through standard operational 154 interfaces. The information should include the NLRI and as much 155 relevant information as reasonably possible. 157 6. Changes to RFC4271 159 [RFC4271] states "The value of the Length field MUST always be at 160 least 19 and no greater than 4096." This document changes the latter 161 number to 65535 for UPDATE messages. 163 [RFC4271] Sec 6.1, specifies raising an error if the length of a 164 message is over 4096 octets. For UPDATE messages, if the receiver 165 has advertised the capability to receive Extended Messages, this 166 document raises that limit to 65535. 168 7. IANA Considerations 170 The IANA has made an early allocation for this new BGP BGP Extended 171 Message Capability referring to this document. 173 Registry: BGP Capability Code 175 Value Description Document 176 ----- ----------------------------------- ------------- 177 6 BGP-Extended Message [this draft] 179 8. Security Considerations 181 This extension to BGP does not change BGP's underlying security 182 issues; see [RFC4272]. 184 Section 5 allowed a receiver to accept an Extended Message even 185 though they had not advertised the capability. This slippery slope 186 will surely lead to sloppy implementations sending Extended Messages 187 when the receiver is not prepared to deal with them, e.g. to peer 188 groups. At best, this will result in errors; at worst, buffer 189 overflows. 191 9. Acknowledgments 193 The authors thank Alvaro Retana, Enke Chen, Susan Hares, John 194 Scudder, John Levine, and Job Snijders for their input; and Oliver 195 Borchert and Kyehwan Lee for their implementations and testing. 197 10. References 199 10.1. Normative References 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, March 1997. 204 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 205 Protocol 4 (BGP-4)", RFC 4271, January 2006. 207 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 208 RFC 4272, January 2006. 210 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 211 with BGP-4", RFC 5492, February 2009. 213 10.2. Informative References 215 [I-D.ietf-sidr-bgpsec-protocol] 216 Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- 217 sidr-bgpsec-protocol-07 (work in progress), February 2013. 219 Authors' Addresses 221 Randy Bush 222 Internet Initiative Japan 223 5147 Crystal Springs 224 Bainbridge Island, Washington 98110 225 US 227 Email: randy@psg.com 229 Keyur Patel 230 Arrcus, Inc. 232 Email: keyur@arrcus.com 233 Dave Ward 234 Cisco Systems 235 170 W. Tasman Drive 236 San Jose, CA 95134 237 USA 239 Email: dward@cisco.com