idnits 2.17.1 draft-ietf-idr-shutdown-02.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 14, 2017) is 2656 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 230 -- Looks like a reference, but probably isn't: '2' on line 234 -- Looks like a reference, but probably isn't: '3' on line 237 -- Looks like a reference, but probably isn't: '4' on line 240 -- Looks like a reference, but probably isn't: '5' on line 243 -- Looks like a reference, but probably isn't: '6' on line 245 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 18, 2017 J. Scudder 7 Juniper 8 January 14, 2017 10 BGP Administrative Shutdown Communication 11 draft-ietf-idr-shutdown-02 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 18, 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 . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 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. 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 freeform UTF-8 88 encoded string with a REQUIRED maximum length of 128 octets. The 89 contents of the string are at the operator's discretion. 91 The Shutdown Communication Cease NOTIFICATION message is encoded as 92 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 | ... Shutdown Communication ... | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | ... | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 The Length value can range from 0 to 128 and indicates how many 105 octets of Shutdown Communication follow. 107 To support international characters, the Shutdown Communication field 108 MUST be encoded using UTF-8. A receiving BGP speaker MUST NOT 109 interpret invalid UTF-8 sequences. 111 Mechanisms concerning the reporting of information contained in the 112 Shutdown Communication are implementation specific but SHOULD include 113 methods such as SYSLOG [RFC5424]. 115 3. Operational Considerations 117 Operators are encouraged to use the Shutdown Communication to inform 118 their peers of the reason for the shutdown of the BGP session and 119 include out-of-band reference materials. An example of a useful 120 Shutdown Communication would be: 122 "[TICKET-1-1438367390] software upgrade, back in 2 hours" 124 "[TICKET-1-1438367390]" is a ticket reference with significance to 125 both the sender and receiver, followed by a brief human readable 126 message regarding the reason for the BGP session shutdown followed by 127 an indication about the length of the maintenance. The receiver can 128 now use the string 'TICKET-1-1438367390' to search in their email 129 archive to find more details. 131 4. Error Handling 133 Any erroneous or malformed Shutdown Communication received SHOULD be 134 logged for the attention of the operator and then MAY be discarded. 136 5. IANA Considerations 138 Per this document, IANA is requested to reference this document at 139 subcode "Administrative Shutdown" in the "Cease NOTIFICATION message 140 subcodes" registry under the "Border Gateway Protocol (BGP) 141 Parameters" group. 143 6. Security Considerations 145 This document uses UTF-8 encoding for the Shutdown Communication. 146 There are a number of security issues with UNICODE. Implementers and 147 operator are advised to review UNICODE TR36 [UTR36] to learn about 148 these issues. This document guards against the technical issues 149 outlined in UTR36 by REQUIRING "shortest form" encoding. However, 150 the visual spoofing due to character confusion still persists. This 151 specification minimizes the effects of visual spoofing by limiting 152 the length of the Shutdown Communication. 154 Users of this mechanism should be aware that unless a transport that 155 provides integrity (such as TCP-AO [RFC5925]) is used for the BGP 156 session in question, a Shutdown Communication message could be 157 forged. Unless a transport that provides confidentiality (such as 158 IPSec [RFC4303]) is used, a Shutdown Communication message could be 159 snooped by an attacker. These issues are common to any BGP message 160 but may be of greater interest in the context of this proposal since 161 the information carried in the message is generally expected to be 162 used for human-to-human communication. 164 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 166 This section records the status of known implementations of the 167 protocol defined by this specification at the time of posting of this 168 Internet-Draft, and is based on a proposal described in RFC7942. The 169 description of implementations in this section is intended to assist 170 the IETF in its decision processes in progressing drafts to RFCs. 171 Please note that the listing of any individual implementation here 172 does not imply endorsement by the IETF. Furthermore, no effort has 173 been spent to verify the information presented here that was supplied 174 by IETF contributors. This is not intended as, and must not be 175 construed to be, a catalog of available implementations or their 176 features. Readers are advised to note that other implementations may 177 exist. 179 As of today these vendors have produced an implementation of the 180 Shutdown Communication: 182 o ExaBGP [1] 183 o pmacct [2] 184 o OpenBGPD [3] 185 o Wireshark [4] (packet analyser) 186 o tcpdump [5], (alt) [6] (packet analyser) 188 8. References 190 8.1. Normative References 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 198 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 199 2003, . 201 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 202 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 203 DOI 10.17487/RFC4271, January 2006, 204 . 206 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 207 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 208 April 2006, . 210 8.2. Informative References 212 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 213 RFC 4303, DOI 10.17487/RFC4303, December 2005, 214 . 216 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 217 DOI 10.17487/RFC5424, March 2009, 218 . 220 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 221 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 222 June 2010, . 224 [UTR36] Davis, M. and M. Suignard, "Unicode Security 225 Considerations", Unicode Technical Report #36, August 226 2010, . 228 8.3. URIs 230 [1] https://github.com/Exa-Networks/exabgp/blob/d8b7cd24e835b9dabfddc 231 87d74e0161921165a50/lib/exabgp/bgp/message/ 232 notification.py#L112-L144 234 [2] https://github.com/pmacct/pmacct/compare/ed8df5820c9f0b8847a7b087 235 3ade3af8ab262113...9fd97a77d144b15bf42d4e55a4d861c499bb0cfc 237 [3] https://github.com/openbsd/src/ 238 commit/0561b344da393d4a962339c507c2e78057100ae1 240 [4] https://www.wireshark.org/lists/wireshark-commits/201612/ 241 msg00238.html 243 [5] https://github.com/the-tcpdump-group/tcpdump/pull/578 245 [6] http://marc.info/?l=openbsd-tech&m=148379081203084&w=2 247 Appendix A. Acknowledgements 249 The authors would like to gratefully acknowledge Tom Scholl, David 250 Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John 251 Heasley, Peter van Dijk, and Arjen Zonneveld. 253 Authors' Addresses 255 Job Snijders 256 NTT Communications 257 Theodorus Majofskistraat 100 258 Amsterdam 1065 SZ 259 The Netherlands 261 Email: job@ntt.net 263 Jakob Heitz 264 Cisco 265 170 West Tasman Drive 266 San Jose, CA 95054 267 USA 269 Email: jheitz@cisco.com 271 John Scudder 272 Juniper Networks 273 1194 N. Mathilda Ave 274 Sunnyvale, CA 94089 275 USA 277 Email: jgs@juniper.net