idnits 2.17.1 draft-ietf-idr-shutdown-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 : ---------------------------------------------------------------------------- -- 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 19, 2017) is 2644 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) -- Looks like a reference, but probably isn't: '1' on line 236 -- Looks like a reference, but probably isn't: '2' on line 240 -- Looks like a reference, but probably isn't: '3' on line 243 -- Looks like a reference, but probably isn't: '4' on line 246 -- Looks like a reference, but probably isn't: '5' on line 249 -- Looks like a reference, but probably isn't: '6' on line 251 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 9 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: July 23, 2017 J. Scudder 7 Juniper 8 January 19, 2017 10 BGP Administrative Shutdown Communication 11 draft-ietf-idr-shutdown-03 13 Abstract 15 This document enhances the BGP Cease NOTIFICATION message 16 "Administrative Shutdown" subcode for operators to transmit a short 17 freeform message to describe why a BGP session was shutdown. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 23, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Shutdown Communication . . . . . . . . . . . . . . . . . . . 2 61 3. Operational Considerations . . . . . . . . . . . . . . . . . 3 62 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 3 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 4 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . 5 69 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 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. 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 the Error 87 Subcode "Administrative Shutdown" followed by a length field and an 88 UTF-8 encoded string. The contents of the string are at the 89 operator's discretion. 91 The Cease NOTIFICATION message with an Administrative Shutdown 92 Communication is 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 2 | Length | ... \ 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 99 \ \ 100 / ... Shutdown Communication ... / 101 \ \ 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 Length: this 8-bit field represents the length of the Shutdown 105 Communication field in octets. The length value MUST range from 0 106 to 128 inclusive. When the length value is zero, no Shutdown 107 Communication field follows. 109 Shutdown Communication: to support international characters, the 110 Shutdown Communication field MUST be encoded using UTF-8. A 111 receiving BGP speaker MUST NOT interpret invalid UTF-8 sequences. 112 Note that when the Shutdown Communication contains multibyte 113 characters, the number of characters will be less than the length 114 value. 116 Mechanisms concerning the reporting of information contained in the 117 Shutdown Communication are implementation specific but SHOULD include 118 methods such as SYSLOG [RFC5424]. 120 3. Operational Considerations 122 Operators are encouraged to use the Shutdown Communication to inform 123 their peers of the reason for the shutdown of the BGP session and 124 include out-of-band reference materials. An example of a useful 125 Shutdown Communication would be: 127 "[TICKET-1-1438367390] software upgrade, back in 2 hours" 129 "[TICKET-1-1438367390]" is a ticket reference with significance to 130 both the sender and receiver, followed by a brief human readable 131 message regarding the reason for the BGP session shutdown followed by 132 an indication about the length of the maintenance. The receiver can 133 now use the string 'TICKET-1-1438367390' to search in their email 134 archive to find more details. 136 4. Error Handling 138 Any erroneous or malformed Shutdown Communication received SHOULD be 139 logged for the attention of the operator and then MAY be discarded. 141 5. IANA Considerations 143 Per this document, IANA is requested to reference this document at 144 subcode "Administrative Shutdown" in the "Cease NOTIFICATION message 145 subcodes" registry under the "Border Gateway Protocol (BGP) 146 Parameters" group in addition to [RFC4486]. 148 6. Security Considerations 150 This document uses UTF-8 encoding for the Shutdown Communication. 151 There are a number of security issues with UNICODE. Implementers and 152 operator are advised to review UNICODE TR36 [UTR36] to learn about 153 these issues. This document guards against the technical issues 154 outlined in UTR36 by REQUIRING "shortest form" encoding. However, 155 the visual spoofing due to character confusion still persists. This 156 specification minimizes the effects of visual spoofing by limiting 157 the length of the Shutdown Communication. 159 Users of this mechanism should be aware that unless a transport that 160 provides integrity (such as TCP-AO [RFC5925]) is used for the BGP 161 session in question, a Shutdown Communication message could be 162 forged. Unless a transport that provides confidentiality (such as 163 IPSec [RFC4303]) is used, a Shutdown Communication message could be 164 snooped by an attacker. These issues are common to any BGP message 165 but may be of greater interest in the context of this proposal since 166 the information carried in the message is generally expected to be 167 used for human-to-human communication. 169 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 171 This section records the status of known implementations of the 172 protocol defined by this specification at the time of posting of this 173 Internet-Draft, and is based on a proposal described in RFC7942. The 174 description of implementations in this section is intended to assist 175 the IETF in its decision processes in progressing drafts to RFCs. 176 Please note that the listing of any individual implementation here 177 does not imply endorsement by the IETF. Furthermore, no effort has 178 been spent to verify the information presented here that was supplied 179 by IETF contributors. This is not intended as, and must not be 180 construed to be, a catalog of available implementations or their 181 features. Readers are advised to note that other implementations may 182 exist. 184 As of today these vendors have produced an implementation of the 185 Shutdown Communication: 187 o ExaBGP [1] 188 o pmacct [2] 189 o OpenBGPD [3] 190 o GoBGP 191 o Wireshark [4] (packet analyser) 192 o tcpdump [5], (alt) [6] (packet analyser) 194 8. References 196 8.1. Normative References 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, 200 DOI 10.17487/RFC2119, March 1997, 201 . 203 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 204 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 205 2003, . 207 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 208 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 209 DOI 10.17487/RFC4271, January 2006, 210 . 212 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 213 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 214 April 2006, . 216 8.2. Informative References 218 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 219 RFC 4303, DOI 10.17487/RFC4303, December 2005, 220 . 222 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 223 DOI 10.17487/RFC5424, March 2009, 224 . 226 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 227 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 228 June 2010, . 230 [UTR36] Davis, M. and M. Suignard, "Unicode Security 231 Considerations", Unicode Technical Report #36, August 232 2010, . 234 8.3. URIs 236 [1] https://github.com/Exa-Networks/exabgp/blob/d8b7cd24e835b9dabfddc 237 87d74e0161921165a50/lib/exabgp/bgp/message/ 238 notification.py#L112-L144 240 [2] https://github.com/pmacct/pmacct/compare/ed8df5820c9f0b8847a7b087 241 3ade3af8ab262113...9fd97a77d144b15bf42d4e55a4d861c499bb0cfc 243 [3] https://github.com/openbsd/src/ 244 commit/0561b344da393d4a962339c507c2e78057100ae1 246 [4] https://www.wireshark.org/lists/wireshark-commits/201612/ 247 msg00238.html 249 [5] https://github.com/the-tcpdump-group/tcpdump/pull/578 251 [6] http://marc.info/?l=openbsd-tech&m=148379081203084&w=2 253 Appendix A. Acknowledgements 255 The authors would like to gratefully acknowledge Tom Scholl, David 256 Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John 257 Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares, 258 and Saku Ytti. 260 Authors' Addresses 262 Job Snijders 263 NTT Communications 264 Theodorus Majofskistraat 100 265 Amsterdam 1065 SZ 266 The Netherlands 268 Email: job@ntt.net 270 Jakob Heitz 271 Cisco 272 170 West Tasman Drive 273 San Jose, CA 95054 274 USA 276 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