idnits 2.17.1 draft-ietf-idr-rfc8203bis-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4486, updated by this document, for RFC5378 checks: 2001-10-18) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 25, 2019) is 1799 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 8203 (Obsoleted by RFC 9003) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR J. Snijders 3 Internet-Draft NTT 4 Obsoletes: 8203 (if approved) J. Heitz 5 Updates: 4486 (if approved) Cisco 6 Intended status: Standards Track J. Scudder 7 Expires: October 27, 2019 Juniper 8 A. Azimov 9 Yandex 10 April 25, 2019 12 Extended BGP Administrative Shutdown Communication 13 draft-ietf-idr-rfc8203bis-03 15 Abstract 17 This document enhances the BGP Cease NOTIFICATION message 18 "Administrative Shutdown" and "Administrative Reset" subcodes for 19 operators to transmit a short freeform message to describe why a BGP 20 session was shutdown or reset. This document updates RFC 4486 and 21 obsoletes RFC 8203 by defining an Extended BGP Administrative 22 Shutdown Communication to improve communication using multibyte 23 character sets. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in BCP 30 14 [RFC2119] [RFC8174] when, and only when, they appear in all 31 capitals, as shown here. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 27, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Shutdown Communication . . . . . . . . . . . . . . . . . . . 2 69 3. Operational Considerations . . . . . . . . . . . . . . . . . 3 70 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 73 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 76 8.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 78 Appendix B. Changes to RFC 8203 . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 It can be troublesome for an operator to correlate a BGP-4 [RFC4271] 84 session teardown in the network with a notice that was transmitted 85 via offline methods such email or telephone calls. This document 86 updates [RFC4486] by specifying a mechanism to transmit a short 87 freeform UTF-8 [RFC3629] message as part of a Cease NOTIFICATION 88 message [RFC4271] to inform the peer why the BGP session is being 89 shutdown or reset. 91 2. Shutdown Communication 93 If a BGP speaker decides to terminate its session with a BGP 94 neighbor, and it sends a NOTIFICATION message with the Error Code 95 "Cease" and Error Subcode "Administrative Shutdown" or 96 "Administrative Reset" [RFC4486], it MAY include an UTF-8 encoded 97 string. The contents of the string are at the operator's discretion. 99 The Cease NOTIFICATION message with a Shutdown Communication is 100 encoded as below: 102 0 1 2 3 103 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Error code 6 | Subcode | Length | ... \ 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 107 \ \ 108 / ... Shutdown Communication ... / 109 \ \ 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 Figure 1 114 Subcode: the Error Subcode value MUST be one of the following 115 values: 2 ("Administrative Shutdown") or 4 ("Administrative 116 Reset"). 118 Length: this 8-bit field represents the length of the Shutdown 119 Communication field in octets. When the length value is zero, no 120 Shutdown Communication field follows. 122 Shutdown Communication: to support international characters, the 123 Shutdown Communication field MUST be encoded using UTF-8. A 124 receiving BGP speaker MUST NOT interpret invalid UTF-8 sequences. 125 Note that when the Shutdown Communication contains multibyte 126 characters, the number of characters will be less than the length 127 value. This field is not NUL terminated. 129 Mechanisms concerning the reporting of information contained in the 130 Shutdown Communication are implementation specific but SHOULD include 131 methods such as Syslog [RFC5424]. 133 3. Operational Considerations 135 Operators are encouraged to use the Shutdown Communication to inform 136 their peers of the reason for the shutdown of the BGP session and 137 include out-of-band reference materials. An example of a useful 138 Shutdown Communication would be: 140 "[TICKET-1-1438367390] software upgrade; back in 2 hours" 142 "[TICKET-1-1438367390]" is a ticket reference with significance to 143 both the sender and receiver, followed by a brief human-readable 144 message regarding the reason for the BGP session shutdown followed by 145 an indication about the length of the maintenance. The receiver can 146 now use the string 'TICKET-1-1438367390' to search in their email 147 archive to find more details. 149 4. Error Handling 151 If a Shutdown Communication with an invalid Length value, or an 152 invalid UTF-8 sequence is received, a message indicating this event 153 SHOULD be logged for the attention of the operator. An erroneous or 154 malformed Shutdown Communication itself MAY be logged in a hexdump 155 format. 157 5. IANA Considerations 159 Per this document, IANA is requested to reference this document at 160 subcode "Administrative Shutdown", and at subcode "Administrative 161 Reset" in the "Cease NOTIFICATION message subcodes" registry under 162 the "Border Gateway Protocol (BGP) Parameters" group in addition to 163 [RFC4486] and [RFC8203]. 165 6. Security Considerations 167 This document uses UTF-8 encoding for the Shutdown Communication. 168 There are a number of security issues with Unicode. Implementers and 169 operators are advised to review Unicode Technical Report #36 [UTR36] 170 to learn about these issues. UTF-8 "Shortest Form" encoding is 171 REQUIRED to guard against the technical issues outlined in [UTR36]. 173 As BGP Shutdown Communications are likely to appear in syslog output, 174 there is a risk that carefully constructed Shutdown Communication 175 might be formatted by receiving systems in a way to make them appear 176 as additional syslog messages. To limit the ability to mount such an 177 attack, the BGP Shutdown Communication is limited to 255 octets in 178 length. 180 Users of this mechanism should be aware that unless a transport that 181 provides integrity is used for the BGP session in question, a 182 Shutdown Communication message could be forged. Unless a transport 183 that provides confidentiality is used, a Shutdown Communication 184 message could be snooped by an attacker. These issues are common to 185 any BGP message but may be of greater interest in the context of this 186 proposal since the information carried in the message is generally 187 expected to be used for human-to-human communication. Refer to the 188 related considerations in [RFC4271] and [RFC4272]. 190 Users of this mechanism should consider applying data minimization 191 practices as outlined in Section 6.1 of [RFC6973] because a received 192 Shutdown Communication may be used at the receiver's discretion. 194 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 196 This section records the status of known implementations of the 197 protocol defined by this specification at the time of posting of this 198 Internet-Draft, and is based on a proposal described in RFC7942. The 199 description of implementations in this section is intended to assist 200 the IETF in its decision processes in progressing drafts to RFCs. 201 Please note that the listing of any individual implementation here 202 does not imply endorsement by the IETF. Furthermore, no effort has 203 been spent to verify the information presented here that was supplied 204 by IETF contributors. This is not intended as, and must not be 205 construed to be, a catalog of available implementations or their 206 features. Readers are advised to note that other implementations may 207 exist. 209 As of today these vendors have produced an implementation of the 210 Shutdown Communication: 212 o Juniper Junos 213 o OpenBSD OpenBGPD 214 o ... 216 8. References 218 8.1. Normative References 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, 222 DOI 10.17487/RFC2119, March 1997, 223 . 225 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 226 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 227 2003, . 229 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 230 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 231 DOI 10.17487/RFC4271, January 2006, 232 . 234 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 235 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 236 April 2006, . 238 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 239 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 240 May 2017, . 242 [RFC8203] Snijders, J., Heitz, J., and J. Scudder, "BGP 243 Administrative Shutdown Communication", RFC 8203, 244 DOI 10.17487/RFC8203, July 2017, 245 . 247 8.2. Informative References 249 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 250 RFC 4272, DOI 10.17487/RFC4272, January 2006, 251 . 253 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 254 DOI 10.17487/RFC5424, March 2009, 255 . 257 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 258 Morris, J., Hansen, M., and R. Smith, "Privacy 259 Considerations for Internet Protocols", RFC 6973, 260 DOI 10.17487/RFC6973, July 2013, 261 . 263 [UTR36] Davis, M. and M. Suignard, "Unicode Security 264 Considerations", Unicode Technical Report #36, August 265 2010, . 267 Appendix A. Acknowledgements 269 The authors would like to gratefully acknowledge Tom Scholl, David 270 Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John 271 Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares, 272 Saku Ytti, Lou Berger, Alvaro Retana, and Adam Roach. 274 The authors would like to thank Enke Chen and Vincent Gillet for 275 their work on [RFC4486] and granting the related BCP 78 rights to the 276 IETF Trust. 278 The authors would like to acknowledge Misha Grishin (MSK-IX) for 279 raising awareness that [RFC8203]'s length specification was 280 insufficient in context of multibyte character sets. 282 Appendix B. Changes to RFC 8203 284 Feedback from operators based in regions which predominantly use 285 multibyte character sets, showed that messages similar in meaning to 286 what can be send in other languages in using single-byte encoding, 287 failed to fit within the Length constraints as specified by 288 [RFC8203]. For example, the phrase: 'Planned work to add switch to 289 stack. Completion time - 30 minutes' has length 65 bytes. Its 290 translation in Russian 291 'Плановые 292 работы по д 293 86;бавлению к&# 294 1086;ммутатора& 295 #1074; 296 стек.Время 297 79;авершения - 298 30минут' (See PDF for non-ASCII 299 character string) has length 139 bytes. 301 Authors' Addresses 303 Job Snijders 304 NTT Communications 305 Theodorus Majofskistraat 100 306 Amsterdam 1065 SZ 307 The Netherlands 309 Email: job@ntt.net 311 Jakob Heitz 312 Cisco 313 170 West Tasman Drive 314 San Jose, CA 95134 315 United States of America 317 Email: jheitz@cisco.com 319 John Scudder 320 Juniper Networks 321 1194 N. Mathilda Ave 322 Sunnyvale, CA 94089 323 United States of America 325 Email: jgs@juniper.net 327 Alexander Azimov 328 Yandex 330 Email: a.e.azimov@gmail.com