draft-ietf-idr-shutdown-08.txt   draft-ietf-idr-shutdown-09.txt 
IDR J. Snijders IDR J. Snijders
Internet-Draft NTT Internet-Draft NTT
Updates: 4486 (if approved) J. Heitz Updates: 4486 (if approved) J. Heitz
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: November 6, 2017 J. Scudder Expires: November 25, 2017 J. Scudder
Juniper Juniper
May 5, 2017 May 24, 2017
BGP Administrative Shutdown Communication BGP Administrative Shutdown Communication
draft-ietf-idr-shutdown-08 draft-ietf-idr-shutdown-09
Abstract Abstract
This document enhances the BGP Cease NOTIFICATION message This document enhances the BGP Cease NOTIFICATION message
"Administrative Shutdown" and "Administrative Reset" subcodes for "Administrative Shutdown" and "Administrative Reset" subcodes for
operators to transmit a short freeform message to describe why a BGP operators to transmit a short freeform message to describe why a BGP
session was shutdown or reset. This document updates RFC 4486. session was shutdown or reset. This document updates RFC 4486.
Requirements Language Requirements Language
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 6, 2017. This Internet-Draft will expire on November 25, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 38 skipping to change at page 4, line 38
Reset" in the "Cease NOTIFICATION message subcodes" registry under Reset" in the "Cease NOTIFICATION message subcodes" registry under
the "Border Gateway Protocol (BGP) Parameters" group in addition to the "Border Gateway Protocol (BGP) Parameters" group in addition to
[RFC4486]. [RFC4486].
6. Security Considerations 6. Security Considerations
This document uses UTF-8 encoding for the Shutdown Communication. This document uses UTF-8 encoding for the Shutdown Communication.
There are a number of security issues with UNICODE. Implementers and There are a number of security issues with UNICODE. Implementers and
operator are advised to review UNICODE TR36 [UTR36] to learn about operator are advised to review UNICODE TR36 [UTR36] to learn about
these issues. UTF-8 "Shortest Form" encoding is REQUIRED to guard these issues. UTF-8 "Shortest Form" encoding is REQUIRED to guard
against the technical issues outlined in UTR36. However, the visual against the technical issues outlined in UTR36.
spoofing due to character confusion still persists. This
specification minimizes the effects of visual spoofing by limiting As BGP Shutdown Communications are likely to appear in syslog output,
the length of the Shutdown Communication. there is a risk that carefully constructed Shutdown Communication
might be formatted by receiving systems in a way to make them appear
as additional syslog messages. To limit the ability to mount such an
attack, the BGP Shutdown Communication is limited to 128 octets in
length.
Users of this mechanism should be aware that unless a transport that Users of this mechanism should be aware that unless a transport that
provides integrity is used for the BGP session in question, a provides integrity is used for the BGP session in question, a
Shutdown Communication message could be forged. Unless a transport Shutdown Communication message could be forged. Unless a transport
that provides confidentiality is used, a Shutdown Communication that provides confidentiality is used, a Shutdown Communication
message could be snooped by an attacker. These issues are common to message could be snooped by an attacker. These issues are common to
any BGP message but may be of greater interest in the context of this any BGP message but may be of greater interest in the context of this
proposal since the information carried in the message is generally proposal since the information carried in the message is generally
expected to be used for human-to-human communication. Refer to the expected to be used for human-to-human communication. Refer to the
related considerations in [RFC4271] and [RFC4272]. related considerations in [RFC4271] and [RFC4272].
skipping to change at page 6, line 34 skipping to change at page 6, line 39
[UTR36] Davis, M. and M. Suignard, "Unicode Security [UTR36] Davis, M. and M. Suignard, "Unicode Security
Considerations", Unicode Technical Report #36, August Considerations", Unicode Technical Report #36, August
2010, <http://unicode.org/reports/tr36/>. 2010, <http://unicode.org/reports/tr36/>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to gratefully acknowledge Tom Scholl, David The authors would like to gratefully acknowledge Tom Scholl, David
Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John
Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares, Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares,
Saku Ytti, Lou Berger, and Alvaro Retana. Saku Ytti, Lou Berger, Alvaro Retana, and Adam Roach.
Authors' Addresses Authors' Addresses
Job Snijders Job Snijders
NTT Communications NTT Communications
Theodorus Majofskistraat 100 Theodorus Majofskistraat 100
Amsterdam 1065 SZ Amsterdam 1065 SZ
The Netherlands The Netherlands
Email: job@ntt.net Email: job@ntt.net
Jakob Heitz Jakob Heitz
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95054 San Jose, CA 95134
USA USA
Email: jheitz@cisco.com Email: jheitz@cisco.com
John Scudder John Scudder
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
 End of changes. 7 change blocks. 
10 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/