🫷

RFC 9003: 拡張BGP管理シャットダウン通信

2024/03/03に公開

要旨

本文書では、BGPセッションをシャットダウンまたはリセットした理由を説明する短い自由形式のメッセージを、オペレータが送信できるように、BGP Cease NOTIFICATIONメッセージの「管理シャットダウン」(Administrative Shutdown)と「管理リセット」(Administrative Reset)サブコードを強化する。本文書は、マルチバイト文字セットを使用した通信を改善するために、最大255オクテットの拡張BGP管理シャットダウン通信を定義することで、RFC 4486を改訂し、RFC 8203を廃止する。

⚠️ BGP Cease NOTIFICATION

サブコード	名称
1	最大プレフィックス数に到達 (Maximum Number of Prefixes Reached)
2	管理シャットダウン (Administrative Shutdown)
3	ピアの設定を解除 (Peer De-configured)
4	管理リセット (Administrative Reset)
5	コネクション拒否 (Connection Rejected)
6	他の設定変更 (Other Configuration Change)
7	コネクションの衝突解決 (Connection Collision Resolution)
8	リソース不足 (Out of Resources)

本文書の位置付け

本文書は、インターネット標準化過程の文書である。

この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 7841のセクション 2を参照のこと。

本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9003 で入手できる。

著作権表示

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている改訂BSDライセンスのテキストを含まなければならず、改訂BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

ネットワーク上のBGP-4 [RFC4271]セッションの切断と、電子メールや電話などのオフラインの方法で送信された通知とを関連付けるのは、オペレータにとって面倒なことかもしれない。本文書は[RFC4486]を改訂し、Cease NOTIFICATIONメッセージ [RFC4271]の一部として短い自由形式のUTF-8 [RFC3629]メッセージを送信し、BGPセッションがシャットダウンまたはリセットされる理由をピアに通知するメカニズムを規定する。本文書は[RFC8203]を廃止する。具体的な相違点と理論的根拠は、付録 Aで詳しく説明する。

1.1.要件言語

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

2. シャットダウン通信

BGPスピーカーがBGPネイバーとのセッションを終了することを決定し、エラーコード「Cease」とエラー・サブコード「管理シャットダウン」または「管理リセット」[RFC4486]を持つNOTIFICATIONメッセージを送信する場合、UTF-8で符号化された文字列を含めてもよい(MAY)。文字列の内容はオペレータの裁量に任されている。

シャットダウン通信を伴うCease NOTIFICATIONメッセージは次のように符号化される。

fig1
図1

サブコード: エラー・サブコード値は、2(「Administrative Shutdown」)または4(「Administrative Reset」)のいずれかの値でなければならない。

長さ: この8ビットのフィールドは、シャットダウン通信フィールドの長さをオクテットで表す。長さの値がゼロの場合、シャットダウン通信フィールドは続かない。

シャットダウン通信: 国際文字をサポートするには、シャットダウン通信フィールドを UTF-8で符号化しなければならない(MUST)。受信側のBGPスピーカーは無効なUTF-8シーケンスを解釈してはならない(MUST NOT)。シャットダウン通信にマルチバイト文字が含まれる場合、文字数は長さの値よりも少なくなることに留意する。このフィールドはNULで終了しない。[UTR36]で概説されている技術的問題を防ぐために、UTF-8の「最短形式」(Shortest Form)符号化が必須である。

シャットダウン通信に含まれる情報の報告に関するメカニズムは実装に固有だが、syslog[RFC5424]などの方法を含む必要がある(SHOULD)。

3. 運用上の考慮事項

オペレータは、シャットダウン通信を使用して、BGPセッションのシャットダウンの理由をピアに通知し、帯域外の参考資料を含めることが推奨される。有用なシャットダウン通信の例は次のとおりである。

「[TICKET-1-1438367390] ソフトウェアのアップグレード; 2時間以内に復旧」

「[TICKET-1-1438367390]」は、送信者と受信者の両方にとって重要なチケット参照であり、BGPセッションのシャットダウンの理由に関する人間が判読できる短いメッセージと、メンテナンスの長さに関する表示が続く。受信者は、「TICKET-1-1438367390」という文字列を使って、電子メールのアーカイブから詳細を確認できる。

⚠️ BGP管理シャットダウンの実装について

cfig1

実装	実装状況
BIRD	RFC 8203
Cisco IOS-XR	不明
ExaBGP	RFC 8203
FRRouting	RFC 8203
GoBGP	RFC 8203
Juniper Junos OS	実装済 (R19.1以降)
Nokia SR OS	不明
OpenBPGD	実装済
pmacct.net / pmacct	RFC 8203
tcpdump.org / tcpdump	実装済
Wireshark Dissector	実装済

OpenBGP

OpenBGPDの場合、下記のコマンドでNOTIFICATIONを送ることができる。

# bgpctl neighbor 192.2.0.2 down "[TICKET-1-1438367390] software upgrade; back in 2 hours"

ログ(/var/log/messages)には以下のような記録が残る。

Mar  3 20:06:27 bgp3 bgpd[72492]: neighbor 192.168.243.130: received notification: Cease, administratively down
Mar  3 20:06:27 bgp3 bgpd[72492]: neighbor 192.168.243.130: received shutdown reason: "[TICKET-1-1438367390] software upgrade; back in 2 hours"

Junos

Junosの場合は、下記のコマンドでNOTIFICATIONを送ることができる。

[edit protocols bgp],
[edit protocols bgp group group-name],
[edit protocols bgp group group-name neighbor address],
shutdown {
    notify-message "[TICKET-1-1438367390] software upgrade; back in 2 hours";
}

Wireshark

NOTIFICATIONメッセージのパケットをデコードすると以下のように表示できる。

cfig2

[RFC8203]を実装しているBGPスピーカーに、128オクテットを超えるシャットダウン通信を送信した場合、そのスピーカーはそれをエラーとして扱い、その結果としてログ・メッセージが表示される。

[RFC8203]もこの仕様も実装していないBGPスピーカーに、任意の長さのシャットダウン通信を送信した場合、そのスピーカーはそれをエラーとして扱い、その結果はログ・メッセージが表示される。

いずれの場合でも、NOTIFICATIONメッセージの受信者は、シャットダウン通信の受信を確認したり、正しく理解することはできない。

オペレータは重要なイベントの場合、ピアとの唯一の通信手段として、シャットダウン通信に依存すべきではない。

ピアのBGPスピーカーがこの仕様をサポートしていることが分かっている場合、255オクテットを超えないシャットダウン通信を送信してもよい(MAY)。そうでなければ、シャットダウン通信を送信してもよい(MAY)が、128オクテットを超えてはならない(SHOULD NOT)。

4. エラー処理

無効なUTF-8シーケンスを含むシャットダウン通信を受信した場合、オペレーターの注意を促すために、このイベントを示すメッセージをログに記録する必要がある(SHOULD)。誤ったまたは不正な形式のシャットダウン通信自体は、16進ダンプ形式でログに記録してもよい(MAY)。

5. IANA に関する考慮事項

IANAは、[RFC4486]に加えて、「ボーダー・ゲートウェイ・プロトコル(BGP)・パラメーター」グループの「BGP Cease NOTIFICATIONメッセージ・サブコード」レジストリのサブコード「管理シャットダウン」と「管理リセット」で本文書を参照した。

6. セキュリティに関する考慮事項

本文書では、シャットダウン通信にUTF-8符号化を使用している。Unicodeには多くのセキュリティ問題がある。実装者とオペレータは、これらの問題について学ぶためにUnicode Technical Report #36[UTR36]を参照することが推奨される。[UTR36]に概説されている技術的問題を防ぐために、UTF-8の「最短形式」(Shortest Form)符号化が必須である。

BGPシャットダウン通信はsyslog出力に表示される可能性があるため、慎重に組み立てられたシャットダウン通信が受信システムによって追加のsyslogメッセージとして表示されるように初期化される危険性がある。BGPシャットダウン通信における255オクテットの長さ制限は、そのような攻撃を制限するのに役立つかもしれない。

このメカニズムのユーザは、完全性を提供するトランスポートが問題のBGPセッションに使用されない限り、シャットダウン通信メッセージが偽造される可能性があることに留意する必要がある。機密性を提供するトランスポートを使用しない限り、シャットダウン通信メッセージが攻撃者に盗み見される可能性もある。これらの問題はどのBGPメッセージにも共通するものだが、メッセージに含まれる情報が一般的に人間同士の通信に使われることが想定されるため、この提案の文脈ではより大きな関心を集める可能性がある。[RFC4271]と[RFC4272]の関連する考慮事項を参照のこと。

受信したシャットダウン通信は受信者の裁量で使用することができるため、このメカニズムのユーザは、[RFC6973]のセクション6.1に概説されているように、データ最小化慣行の適用を検討する必要がある。

7. 参考文献

7.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.

[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.

[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.

[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.

[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.

7.2. 参考規格

[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, 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.

[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.

[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.

[UTR36] Davis, M., Ed. and M. Suignard, Ed., "Unicode Security Considerations", Unicode Technical Report #36, August 2010, http://unicode.org/reports/tr36/.

付録A. RFC 8203との変更点

許可される最大長を128から255に変更した。

マルチバイト文字セットを主に使用する地域を拠点を置くオペレータからのフィードバックによると、シングルバイト符号化を使用する他の言語で送信できるメッセージと似たような意味のメッセージは、[RFC8203]で規定されている長さの制約内に収まらないことが示された。例えば、「Planned work to add switch to stack. Completion time - 30 minutes」(スイッチをスタックに追加する計画作業。完了時間 - 30分)というフレーズの長さは65バイトである。そのロシア語訳の長さは139バイトになる。

128オクテットを超えるシャットダウン通信メッセージが、[RFC8203]を実装するBGPスピーカーに送信された場合、そのスピーカーはオペレータにメッセージの注意を促すが、それ以外は通常どおりNOTIFICATIONメッセージを処理する。

謝辞

著者らは、トム・ショール、デビッド・フリードマ、ジャレッド・マウチ、ジェフ・ハース、ピーター・ヘスラー、ブルーノ・デクレーヌ、ジョン・ヒースリー、ピーター・ファン・ダイク、アルイェン・ゾンネフェルト、ジェームズ・ベンズレー、スーザン・ハレス、サク・イッティ、ルー・バーガー、アルバロ・レタナ、アダム・ローチに感謝の意を表する。

著者らは、[RFC4486]に関するエンケ・チェンとヴァンサン・ジレの取り組みと、関連する BCP 78の権利をIETFトラストに付与してくれたことに感謝する。

著者らは、[RFC8203]の長さの仕様がマルチバイト文字セットの文脈では不十分であるとことに気付かせてくれたミーシャ・グリシン(MSK-IX)に感謝の意を表する。

著者のアドレス

ジョブ・スナイデルス
NTT Ltd.
Theodorus Majofskistraat 100
1065 SZ Amsterdam
オランダ
メール：job@ntt.net

ヤコブ・ハイツ
Cisco
170 West Tasman Drive
San Jose, CA 95134
アメリカ合衆国
メール: jheitz@cisco.com

ジョン・スカダー
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
アメリカ合衆国
メール: jgs@juniper.net

アレクサンダー・アジモフ
Yandex
Ulitsa Lva Tolstogo 16
Moscow
119021
ロシア連邦
メール: a.e.azimov@gmail.com

更新履歴

2024.3.3

GitHubで編集を提案

要旨