[要約] RFC 9003は、BGPプロトコルにおける管理的なシャットダウン手順を拡張し、シャットダウンの理由を伝達するためのメカニズムを提供します。この拡張は、運用者間のコミュニケーションを改善し、問題解決を迅速化することを目的としています。利用場面としては、ネットワークメンテナンス、ポリシー違反の対応、セキュリティインシデントの際に有効です。
Internet Engineering Task Force (IETF) J. Snijders
Request for Comments: 9003 NTT
Obsoletes: 8203 J. Heitz
Updates: 4486 Cisco
Category: Standards Track J. Scudder
ISSN: 2070-1721 Juniper
A. Azimov
Yandex
January 2021
Extended BGP Administrative Shutdown Communication
拡張BGP管理シャットダウン通信
Abstract
概要
This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short free-form message to describe why a BGP session was shut down or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication of up to 255 octets to improve communication using multibyte character sets.
このドキュメントは、BGPセッションがシャットダウンまたはリセットされた理由を説明するために、短いフリーフォームメッセージを送信するためのBGPの中止通知メッセージ「管理停止」および「管理リセット」サブコードを強化します。この文書は、マルチバイト文字セットを使用した通信を改善するために最大255オクテットの拡張BGP管理シャットダウン通信を定義することによって、RFC 4486を更新し、RFC 8203を廃止します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9003.
この文書の現在の状況、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9003で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. Shutdown Communication
3. Operational Considerations
4. Error Handling
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Changes to RFC 8203
Acknowledgements
Authors' Addresses
It can be troublesome for an operator to correlate a BGP-4 [RFC4271] session teardown in the network with a notice that was transmitted via offline methods, such as email or telephone calls. This document updates [RFC4486] by specifying a mechanism to transmit a short free-form UTF-8 [RFC3629] message as part of a Cease NOTIFICATION message [RFC4271] to inform the peer why the BGP session is being shut down or reset. This document obsoletes [RFC8203]; the specific differences and rationale are discussed in detail in Appendix A.
オペレータが電子メールまたは電話のコールなどのオフラインメソッドを介して送信された通知をネットワーク内のBGP-4 [RFC4271]セッションの破損を相関させるのは面倒です。このドキュメントは、CEASE通知メッセージの一部として短いフリーフォームUTF-8 [RFC3629]メッセージを送信するメカニズムを指定して、BGPセッションがシャットダウンまたはリセットされている理由をピアに通知します。この文書は廃止されています[RFC8203]。特定の違いと理論的根拠については、付録Aで詳しく説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
If a BGP speaker decides to terminate its session with a BGP neighbor, and it sends a NOTIFICATION message with the Error Code "Cease" and Error Subcode "Administrative Shutdown" or "Administrative Reset" [RFC4486], it MAY include a UTF-8-encoded string. The contents of the string are at the operator's discretion.
BGPスピーカーがBGPネイバーとのセッションを終了することを決定し、エラーコード「中止」とエラーサブコード「管理停止」または「管理リセット」[RFC4486]を使用して通知メッセージを送信した場合は、UTF-8を含めることができます。符号化された文字列文字列の内容はオペレータの裁量にあります。
The Cease NOTIFICATION message with a Shutdown Communication is encoded as below:
シャットダウン通信での中止通知メッセージは以下のようにエンコードされています。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code 6 | Subcode | Length | ... \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
\ \
/ ... Shutdown Communication ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
図1
Subcode: The Error Subcode value MUST be one of the following values: 2 ("Administrative Shutdown") or 4 ("Administrative Reset").
サブコード：エラーサブコードの値は、2（「管理シャットダウン」）または4（「管理リセット」）の値のいずれかでなければなりません。
Length: This 8-bit field represents the length of the Shutdown Communication field in octets. When the length value is zero, no Shutdown Communication field follows.
長さ：この8ビットフィールドは、オクテット内のシャットダウン通信フィールドの長さを表します。長さ値がゼロの場合、シャットダウン通信フィールドは続きません。
Shutdown Communication: To support international characters, the Shutdown Communication field MUST be encoded using UTF-8. A receiving BGP speaker MUST NOT interpret invalid UTF-8 sequences. Note that when the Shutdown Communication contains multibyte characters, the number of characters will be less than the length value. This field is not NUL terminated. UTF-8 "Shortest Form" encoding is REQUIRED to guard against the technical issues outlined in [UTR36].
シャットダウン通信：国際的な文字をサポートするためには、シャットダウン通信フィールドはUTF-8を使用してエンコードする必要があります。受信BGPスピーカーは無効なUTF-8シーケンスを解釈してはいけません。シャットダウン通信にマルチバイト文字が含まれている場合、文字数は長さの値より小さくなります。このフィールドはNULでは終了しません。UTF-8「最短型」符号化は、[UTR36]で概説されている技術的な問題を保護するために必要です。
Mechanisms concerning the reporting of information contained in the Shutdown Communication are implementation specific but SHOULD include methods such as syslog [RFC5424].
シャットダウン通信に含まれる情報の報告に関するメカニズムは実装固有のものですが、Syslog [RFC5424]などのメソッドを含める必要があります。
Operators are encouraged to use the Shutdown Communication to inform their peers of the reason for the shutdown of the BGP session and include out-of-band reference materials. An example of a useful Shutdown Communication would be:
オペレータは、シャットダウンコミュニケーションを使用して、BGPセッションのシャットダウンの理由の仲間に通知し、帯域外の参照素材を含むことをお勧めします。便利なシャットダウン通信の例は次のとおりです。
"[TICKET-1-1438367390] software upgrade; back in 2 hours"
"【チケット-1-1438367390】ソフトウェアのアップグレード。2時間で戻って
"[TICKET-1-1438367390]" is a ticket reference with significance to both the sender and receiver, followed by a brief human-readable message regarding the reason for the BGP session shutdown followed by an indication about the length of the maintenance. The receiver can now use the string 'TICKET-1-1438367390' to search in their email archive to find more details.
「[チケット-1-1438367390]は、送信者と受信者の両方にとって重要なチケット参照、その後にBGPセッションのシャットダウンの理由についての短い人間が読めるメッセージが続き、その後にメンテナンスの長さに関する表示が続く。受信側では、String 'Ticket-1-1438367390'を使用して電子メールアーカイブを検索して詳細を見つけることができます。
If a Shutdown Communication longer than 128 octets is sent to a BGP speaker that implements [RFC8203], then that speaker will treat it as an error, the consequence of which should be a log message.
128オクテットを超えるシャットダウン通信が[RFC8203]を実装するBGPスピーカーに送信された場合、そのスピーカーはエラーとして扱い、その結果はログメッセージになるはずです。
If a Shutdown Communication of any length is sent to a BGP speaker that implements neither [RFC8203] nor this specification, then that speaker will treat it as an error, the consequence of which should be a log message.
いずれかの長さのシャットダウン通信が、RFC8203を実装していないBGPスピーカーに送信された場合、そのスピーカーはエラーとして扱います。その結果、その結果はログメッセージになります。
In any case, a receiver of a NOTIFICATION message is unable to acknowledge the receipt and correct understanding of any Shutdown Communication.
いずれにせよ、通知メッセージの受信者は、シャットダウン通信の受信および正しい理解を承認することができない。
Operators should not rely on Shutdown Communications as their sole form of communication with their peers for important events.
オペレータは、重要なイベントのためのピアとの唯一のコミュニケーションとしてのシャットダウンコミュニケーションに頼るべきではありません。
If it is known that the peer BGP speaker supports this specification, then a Shutdown Communication that is not longer than 255 octets MAY be sent. Otherwise, a Shutdown Communication MAY be sent, but it SHOULD NOT be longer than 128 octets.
ピアBGPスピーカーがこの仕様をサポートすることが知られている場合、255オクテット以下のシャットダウン通信を送信することができる。それ以外の場合は、シャットダウン通信が送信されることがありますが、128オクテットを超えるべきではありません。
If a Shutdown Communication with an invalid UTF-8 sequence is received, a message indicating this event SHOULD be logged for the attention of the operator. An erroneous or malformed Shutdown Communication itself MAY be logged in a hexdump format.
無効なUTF-8シーケンスとのシャットダウン通信が受信された場合、このイベントを示すメッセージはオペレータの注意を払います。誤ったまたは不正なシャットダウン通信自体がHEXDUMP形式で記録されてもよい。
IANA has referenced this document at subcodes "Administrative Shutdown" and "Administrative Reset" in the "BGP Cease NOTIFICATION message subcodes" registry under the "Border Gateway Protocol (BGP) Parameters" group in addition to [RFC4486].
IANAは、[RFC4486]に加えて、「BGP CEASE通知メッセージサブコード」グループの「BGP CEASE通知メッセージサブコード」レジストリのサブコードで、「管理停止」および「管理リセット」で参照しています。
This document uses UTF-8 encoding for the Shutdown Communication. There are a number of security issues with Unicode. Implementers and operators are advised to review Unicode Technical Report #36 [UTR36] to learn about these issues. UTF-8 "Shortest Form" encoding is REQUIRED to guard against the technical issues outlined in [UTR36].
この文書では、シャットダウン通信にUTF-8エンコードを使用しています。Unicodeにはいくつかのセキュリティ問題があります。これらの問題について学ぶために、実装者と事業者はUnicodeテクニカルレポート＃36 [UTR36]を確認することをお勧めします。UTF-8「最短型」符号化は、[UTR36]で概説されている技術的な問題を保護するために必要です。
As BGP Shutdown Communications are likely to appear in syslog output, 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. The 255-octet length limit on the BGP Shutdown Communication may help limit the ability to mount such an attack.
BGPシャットダウン通信がsyslog出力に表示される可能性があるため、慎重に構築されたシャットダウン通信がシステムを追加のsyslogメッセージとして表示させるようにシステムを受信してフォーマットされる可能性があるリスクがあります。BGPシャットダウン通信の255オクテット長の制限は、そのような攻撃をマウントする能力を制限するのに役立ちます。
Users of this mechanism should be aware that unless a transport that provides integrity is used for the BGP session in question, a Shutdown Communication message could be forged. Unless a transport that provides confidentiality is used, a Shutdown Communication message could be snooped by an attacker. These issues are common to any BGP message, but they may be of greater interest in the context of this proposal since the information carried in the message is generally expected to be used for human-to-human communication. Refer to the related considerations in [RFC4271] and [RFC4272].
このメカニズムのユーザーは、整合性を提供するトランスポートが問題のBGPセッションに使用されない限り、シャットダウン通信メッセージを偽造することができます。機密性を提供するトランスポートが使用されていない限り、シャットダウン通信メッセージは攻撃者によってスヌーピングされる可能性があります。これらの問題は任意のBGPメッセージに共通ですが、メッセージで実行されている情報は一般に人間から人間のコミュニケーションに使用されると予想されるため、この提案の文脈に大きな関心があるかもしれません。[RFC4271]と[RFC4272]の関連考慮事項を参照してください。
Users of this mechanism should consider applying data minimization practices as outlined in Section 6.1 of [RFC6973] because a received Shutdown Communication may be used at the receiver's discretion.
このメカニズムのユーザーは、受信したシャットダウン通信が受信機の判断で使用される可能性があるため、[RFC6973]のセクション6.1で概説されているデータ最小化方法の適用を検討する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] YERGEAU、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https：//www.rfc-editor.org/info/RFC3629>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<https://www.rfc-editor.org/info/rfc4271>。
[RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease Notification Message", RFC 4486, DOI 10.17487/RFC4486, April 2006, <https://www.rfc-editor.org/info/rfc4486>.
[RFC4486] Chen、E.およびV.Gillet、「BGP CEASE通知メッセージのサブコード」、RFC 4486、DOI 10.17487 / RFC4486、2006年4月、<https：//www.rfc-editor.org/info/rfc4486>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>.
[RFC4272] Murphy、S.、「BGPセキュリティ脆弱性分析」、RFC 4272、DOI 10.17487 / RFC4272、2006年1月、<https：//www.rfc-editor.org/info/rfc4272>。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <https://www.rfc-editor.org/info/rfc5424>.
[RFC5424] GERHARD、R.、「SYSLOGプロトコル」、RFC 5424、DOI 10.17487 / RFC5424、2009年3月、<https：//www.rfc-editor.org/info/rfc5424>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973]クーパー、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M.、R. Smith、「インターネットプロトコルのプライバシーに関する考察」、RFC 6973、DOI2017487 / RFC6973、2013年7月、<https：//www.rfc-editor.org/info/rfc6973>。
[RFC8203] Snijders, J., Heitz, J., and J. Scudder, "BGP Administrative Shutdown Communication", RFC 8203, DOI 10.17487/RFC8203, July 2017, <https://www.rfc-editor.org/info/rfc8203>.
[RFC8203] Snijders、J.、Heitz、J.、J.Scudder、「BGP管理シャットダウンコミュニケーション」、RFC 8203、DOI 10.17487 / RFC8203、2017年7月、<https：//www.rfc-editor.org/info/ RFC8203>。
[UTR36] Davis, M., Ed. and M. Suignard, Ed., "Unicode Security Considerations", Unicode Technical Report #36, August 2010, <http://unicode.org/reports/tr36/>.
[UTR36]デイビス、M.、ED。「Unicodeセキュリティに関する考慮事項」、「Unicodeセキュリティに関する考慮事項」、Unicodeテクニカルレポート＃36、2010年8月、<http://unicode.org/reports/tr36/>。
The maximum permitted length was changed from 128 to 255.
最大許容長は128から255に変更されました。
Feedback from operators based in regions that predominantly use multibyte character sets showed that messages similar in meaning to what can be sent in other languages using single-byte encoding failed to fit within the length constraints as specified by [RFC8203]. For example, the phrase "Planned work to add switch to stack. Completion time - 30 minutes" has a length of 65 bytes. Its translation in Russian has a length of 139 bytes.
マルチバイト文字セットを主に使用する領域をベースにしたオペレータからのフィードバックは、シングルバイトエンコーディングを使用して他の言語で送信できるものに似たメッセージが、[RFC8203]で指定された長さ制約内に適合しました。たとえば、「スイッチをスタックに追加するための計画作業」という語句。完了時間 - 30分の長さは65バイトです。ロシア語のその翻訳は139バイトの長さを持っています。
If a Shutdown Communication message longer than 128 octets is sent to a BGP speaker that implements [RFC8203], then that speaker will bring it to the attention of an operator but will otherwise process the NOTIFICATION message as normal.
128オクテットを超えるシャットダウン通信メッセージが[RFC8203]を実装するBGPスピーカーに送信された場合、そのスピーカーはそれをオペレータの注意を引くが、そうでなければ通知メッセージを通常どおりに処理します。
Acknowledgements
謝辞
The authors would like to gratefully acknowledge Tom Scholl, David Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares, Saku Ytti, Lou Berger, Alvaro Retana, and Adam Roach.
著者らは、Tom Scholl、David Freedman、Jared Mauch、Jeff Haas、Peter Hessler、Jahn heasleene、John Heasleene、Peter Van Dijk、Arjen Zonneveld、James Bensley、Susan Ytti、Lou Berger、Alvaro Retana、James Bensley、Jahn Heasleen、Jahn Heasley、Jahn Heasleen、Jahn Heasley、Jahn Heasleenアダムロハ。
The authors would like to thank Enke Chen and Vincent Gillet for their work on [RFC4486] and granting the related BCP 78 rights to the IETF Trust.
著者らは、[RFC4486]の仕事のためにChenとVincent Gilletに感謝し、関連するBCP 78権利をIETF信頼に付与したいと思います。
The authors would like to acknowledge Misha Grishin (MSK-IX) for raising awareness that the length specification of [RFC8203] was insufficient in context of multibyte character sets.
著者らは、MISHA GRISHIN（MSK-IX）を認識を高めるために、[RFC8203]の長さ仕様がマルチバイト文字セットのコンテキストでは不十分であったという認識を高めたいと思います。
Authors' Addresses
著者の住所
Job Snijders NTT Ltd. Theodorus Majofskistraat 100 1065 SZ Amsterdam Netherlands
ジョブ・スニジュースNTT Ltd. Theodorus Majofskistraat 100 1065 SZアムステルダムオランダ
Email: job@ntt.net
Jakob Heitz Cisco 170 West Tasman Drive San Jose, CA 95134 United States of America
Jakob Heitz Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ
Email: jheitz@cisco.com
John Scudder Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
John Scudder Juniper Networks 1133イノベーションウェイSunnyvale、CA 94089アメリカ合衆国
Email: jgs@juniper.net
Alexander Azimov Yandex Ulitsa Lva Tolstogo 16 Moscow 119021 Russian Federation
Alexander Azimov Yandex Ulitsa Lva Tolstogo 16 Moscow 119021ロシア連邦
Email: a.e.azimov@gmail.com