idnits 2.17.1 draft-ietf-idr-shutdown-04.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 RFC4486, but the abstract doesn't seem to mention this, which it should. 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 (January 28, 2017) is 2635 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 (==), 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 Updates: 4486 (if approved) J. Heitz 5 Intended status: Standards Track Cisco 6 Expires: August 1, 2017 J. Scudder 7 Juniper 8 January 28, 2017 10 BGP Administrative Shutdown Communication 11 draft-ietf-idr-shutdown-04 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. 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 August 1, 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 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Shutdown Communication . . . . . . . . . . . . . . . . . . . 2 62 3. Operational Considerations . . . . . . . . . . . . . . . . . 3 63 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 4 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 8.2. Informative References . . . . . . . . . . . . . . . . . 5 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 It can be troublesome for an operator to correlate a BGP-4 [RFC4271] 76 session teardown in the network with a notice that was transmitted 77 via off-line methods such email or telephone calls. This document 78 specifies a mechanism to transmit a short freeform UTF-8 [RFC3629] 79 message as part of a Cease NOTIFICATION message [RFC4486] to inform 80 the peer why the BGP session is being shutdown or reset. 82 2. Shutdown Communication 84 If a BGP speaker decides to terminate its session with a BGP 85 neighbor, then the BGP speaker MAY send to the neighbor a 86 NOTIFICATION message with the Error Code "Cease" and Error Subcode 87 "Administrative Shutdown" or "Administrative Reset" followed by a 88 length field and an UTF-8 encoded string. The contents of the string 89 are at the operator's discretion. 91 The Cease NOTIFICATION message with a Shutdown Communication is 92 encoded as below: 94 0 1 2 3 95 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 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Error code 6 | Subcode | Length | ... \ 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 99 \ \ 100 / ... Shutdown Communication ... / 101 \ \ 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 Subcode: the Error Subcode value MUST be one of the following 105 values: 2 ("Administrative Shutdown") or 4 ("Administrative 106 Reset"). 108 Length: this 8-bit field represents the length of the Shutdown 109 Communication field in octets. The length value MUST range from 0 110 to 128 inclusive. When the length value is zero, no Shutdown 111 Communication field follows. 113 Shutdown Communication: to support international characters, the 114 Shutdown Communication field MUST be encoded using UTF-8. A 115 receiving BGP speaker MUST NOT interpret invalid UTF-8 sequences. 116 Note that when the Shutdown Communication contains multibyte 117 characters, the number of characters will be less than the length 118 value. 120 Mechanisms concerning the reporting of information contained in the 121 Shutdown Communication are implementation specific but SHOULD include 122 methods such as SYSLOG [RFC5424]. 124 3. Operational Considerations 126 Operators are encouraged to use the Shutdown Communication to inform 127 their peers of the reason for the shutdown of the BGP session and 128 include out-of-band reference materials. An example of a useful 129 Shutdown Communication would be: 131 "[TICKET-1-1438367390] software upgrade, back in 2 hours" 133 "[TICKET-1-1438367390]" is a ticket reference with significance to 134 both the sender and receiver, followed by a brief human readable 135 message regarding the reason for the BGP session shutdown followed by 136 an indication about the length of the maintenance. The receiver can 137 now use the string 'TICKET-1-1438367390' to search in their email 138 archive to find more details. 140 4. Error Handling 142 Any erroneous or malformed Shutdown Communication received SHOULD be 143 logged for the attention of the operator and then MAY be discarded. 145 5. IANA Considerations 147 Per this document, IANA is requested to reference this document at 148 subcode "Administrative Shutdown", and at subcode "Administrative 149 Reset" in the "Cease NOTIFICATION message subcodes" registry under 150 the "Border Gateway Protocol (BGP) Parameters" group in addition to 151 [RFC4486]. 153 6. Security Considerations 155 This document uses UTF-8 encoding for the Shutdown Communication. 156 There are a number of security issues with UNICODE. Implementers and 157 operator are advised to review UNICODE TR36 [UTR36] to learn about 158 these issues. This document guards against the technical issues 159 outlined in UTR36 by REQUIRING "shortest form" encoding. However, 160 the visual spoofing due to character confusion still persists. This 161 specification minimizes the effects of visual spoofing by limiting 162 the length of the Shutdown Communication. 164 Users of this mechanism should be aware that unless a transport that 165 provides integrity (such as TCP-AO [RFC5925]) is used for the BGP 166 session in question, a Shutdown Communication message could be 167 forged. Unless a transport that provides confidentiality (such as 168 IPSec [RFC4303]) is used, a Shutdown Communication message could be 169 snooped by an attacker. These issues are common to any BGP message 170 but may be of greater interest in the context of this proposal since 171 the information carried in the message is generally expected to be 172 used for human-to-human communication. 174 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 176 This section records the status of known implementations of the 177 protocol defined by this specification at the time of posting of this 178 Internet-Draft, and is based on a proposal described in RFC7942. The 179 description of implementations in this section is intended to assist 180 the IETF in its decision processes in progressing drafts to RFCs. 181 Please note that the listing of any individual implementation here 182 does not imply endorsement by the IETF. Furthermore, no effort has 183 been spent to verify the information presented here that was supplied 184 by IETF contributors. This is not intended as, and must not be 185 construed to be, a catalog of available implementations or their 186 features. Readers are advised to note that other implementations may 187 exist. 189 As of today these vendors have produced an implementation of the 190 Shutdown Communication: 192 o ExaBGP 193 o pmacct 194 o OpenBGPD 195 o tcpdump (packet analyser) 197 8. References 199 8.1. Normative References 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, 203 DOI 10.17487/RFC2119, March 1997, 204 . 206 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 207 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 208 2003, . 210 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 211 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 212 DOI 10.17487/RFC4271, January 2006, 213 . 215 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 216 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 217 April 2006, . 219 8.2. Informative References 221 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 222 RFC 4303, DOI 10.17487/RFC4303, December 2005, 223 . 225 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 226 DOI 10.17487/RFC5424, March 2009, 227 . 229 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 230 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 231 June 2010, . 233 [UTR36] Davis, M. and M. Suignard, "Unicode Security 234 Considerations", Unicode Technical Report #36, August 235 2010, . 237 Appendix A. Acknowledgements 239 The authors would like to gratefully acknowledge Tom Scholl, David 240 Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John 241 Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares, 242 and Saku Ytti. 244 Authors' Addresses 246 Job Snijders 247 NTT Communications 248 Theodorus Majofskistraat 100 249 Amsterdam 1065 SZ 250 The Netherlands 252 Email: job@ntt.net 254 Jakob Heitz 255 Cisco 256 170 West Tasman Drive 257 San Jose, CA 95054 258 USA 260 Email: jheitz@cisco.com 262 John Scudder 263 Juniper Networks 264 1194 N. Mathilda Ave 265 Sunnyvale, CA 94089 266 USA 268 Email: jgs@juniper.net