idnits 2.17.1 draft-ietf-idr-shutdown-07.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2017) is 2604 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR J. Snijders 3 Internet-Draft NTT 4 Updates: 4486 (if approved) J. Heitz 5 Intended status: Standards Track Cisco 6 Expires: September 4, 2017 J. Scudder 7 Juniper 8 March 3, 2017 10 BGP Administrative Shutdown Communication 11 draft-ietf-idr-shutdown-07 13 Abstract 15 This document enhances the BGP Cease NOTIFICATION message 16 "Administrative Shutdown" and "Administrative Reset" subcodes for 17 operators to transmit a short freeform message to describe why a BGP 18 session was shutdown or reset. This document updates RFC 4486. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 4, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Shutdown Communication . . . . . . . . . . . . . . . . . . . 3 74 3. Operational Considerations . . . . . . . . . . . . . . . . . 3 75 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 78 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 4 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 81 8.2. Informative References . . . . . . . . . . . . . . . . . 5 82 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 85 1. Introduction 87 It can be troublesome for an operator to correlate a BGP-4 [RFC4271] 88 session teardown in the network with a notice that was transmitted 89 via off-line methods such email or telephone calls. This document 90 specifies a mechanism to transmit a short freeform UTF-8 [RFC3629] 91 message as part of a Cease NOTIFICATION message [RFC4486] to inform 92 the peer why the BGP session is being shutdown or reset. 94 2. Shutdown Communication 96 If a BGP speaker decides to terminate its session with a BGP 97 neighbor, then the BGP speaker MAY send to the neighbor a 98 NOTIFICATION message with the Error Code "Cease" and Error Subcode 99 "Administrative Shutdown" or "Administrative Reset" followed by a 100 length field and an UTF-8 encoded string. The contents of the string 101 are at the operator's discretion. 103 The Cease NOTIFICATION message with a Shutdown Communication is 104 encoded as below: 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Error code 6 | Subcode | Length | ... \ 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 111 \ \ 112 / ... Shutdown Communication ... / 113 \ \ 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 Subcode: the Error Subcode value MUST be one of the following 117 values: 2 ("Administrative Shutdown") or 4 ("Administrative 118 Reset"). 120 Length: this 8-bit field represents the length of the Shutdown 121 Communication field in octets. The length value MUST range from 0 122 to 128 inclusive. When the length value is zero, no Shutdown 123 Communication field follows. 125 Shutdown Communication: to support international characters, the 126 Shutdown Communication field MUST be encoded using UTF-8. A 127 receiving BGP speaker MUST NOT interpret invalid UTF-8 sequences. 128 Note that when the Shutdown Communication contains multibyte 129 characters, the number of characters will be less than the length 130 value. This field is not NUL terminated. 132 Mechanisms concerning the reporting of information contained in the 133 Shutdown Communication are implementation specific but SHOULD include 134 methods such as SYSLOG [RFC5424]. 136 3. Operational Considerations 138 Operators are encouraged to use the Shutdown Communication to inform 139 their peers of the reason for the shutdown of the BGP session and 140 include out-of-band reference materials. An example of a useful 141 Shutdown Communication would be: 143 "[TICKET-1-1438367390] software upgrade, back in 2 hours" 145 "[TICKET-1-1438367390]" is a ticket reference with significance to 146 both the sender and receiver, followed by a brief human readable 147 message regarding the reason for the BGP session shutdown followed by 148 an indication about the length of the maintenance. The receiver can 149 now use the string 'TICKET-1-1438367390' to search in their email 150 archive to find more details. 152 4. Error Handling 154 Any erroneous or malformed Shutdown Communication received SHOULD be 155 logged for the attention of the operator and then MAY be discarded. 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]. 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 operator are advised to review UNICODE TR36 [UTR36] to learn about 170 these issues. This document guards against the technical issues 171 outlined in UTR36 by REQUIRING "shortest form" encoding. However, 172 the visual spoofing due to character confusion still persists. This 173 specification minimizes the effects of visual spoofing by limiting 174 the length of the Shutdown Communication. 176 Users of this mechanism should be aware that unless a transport that 177 provides integrity (such as TCP-AO [RFC5925]) is used for the BGP 178 session in question, a Shutdown Communication message could be 179 forged. Unless a transport that provides confidentiality (such as 180 IPSec [RFC4303]) is used, a Shutdown Communication message could be 181 snooped by an attacker. These issues are common to any BGP message 182 but may be of greater interest in the context of this proposal since 183 the information carried in the message is generally expected to be 184 used for human-to-human communication. 186 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 188 This section records the status of known implementations of the 189 protocol defined by this specification at the time of posting of this 190 Internet-Draft, and is based on a proposal described in RFC7942. The 191 description of implementations in this section is intended to assist 192 the IETF in its decision processes in progressing drafts to RFCs. 193 Please note that the listing of any individual implementation here 194 does not imply endorsement by the IETF. Furthermore, no effort has 195 been spent to verify the information presented here that was supplied 196 by IETF contributors. This is not intended as, and must not be 197 construed to be, a catalog of available implementations or their 198 features. Readers are advised to note that other implementations may 199 exist. 201 As of today these vendors have produced an implementation of the 202 Shutdown Communication: 204 o ExaBGP 205 o pmacct 206 o OpenBGPD 207 o GoBGP 208 o FreeRangeRouting (frr) 209 o tcpdump (packet analyser) 210 o Wireshark (packet analyser) 212 8. References 214 8.1. Normative References 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, 218 DOI 10.17487/RFC2119, March 1997, 219 . 221 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 222 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 223 2003, . 225 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 226 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 227 DOI 10.17487/RFC4271, January 2006, 228 . 230 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 231 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 232 April 2006, . 234 8.2. Informative References 236 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 237 RFC 4303, DOI 10.17487/RFC4303, December 2005, 238 . 240 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 241 DOI 10.17487/RFC5424, March 2009, 242 . 244 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 245 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 246 June 2010, . 248 [UTR36] Davis, M. and M. Suignard, "Unicode Security 249 Considerations", Unicode Technical Report #36, August 250 2010, . 252 Appendix A. Acknowledgements 254 The authors would like to gratefully acknowledge Tom Scholl, David 255 Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John 256 Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares, 257 Saku Ytti, and Lou Berger. 259 Authors' Addresses 261 Job Snijders 262 NTT Communications 263 Theodorus Majofskistraat 100 264 Amsterdam 1065 SZ 265 The Netherlands 267 Email: job@ntt.net 269 Jakob Heitz 270 Cisco 271 170 West Tasman Drive 272 San Jose, CA 95054 273 USA 275 Email: jheitz@cisco.com 277 John Scudder 278 Juniper Networks 279 1194 N. Mathilda Ave 280 Sunnyvale, CA 94089 281 USA 283 Email: jgs@juniper.net