Zenn
⛳

RFC 8097: BGPプレフィックス・オリジン検証状態の拡張コミュニティ

2024/02/26に公開
#
rfc
#
bgp
tech

要旨

本文書では、自律システム内部で発信元自律システム(AS)の検証状態を伝達するための新しいBGPのオペイク(不透明)な拡張コミュニティを定義する。この検証状態を受け取った内部BGP(IBGP)スピーカーは、決定プロセスに影響を与えるようなローカル・ポリシーを設定することができる。

本文書の位置付け

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

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc8097 で入手できる。

著作権表示

Copyright (c) 2017 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

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

1. はじめに

本文書では、自律システム内部で発信ASの検証状態を伝達するための新しいBGPのオペイクな拡張コミュニティを定義する。この検証状態を受け取ったIBGPスピーカーは、その決定プロセスに影響を与えるようなローカル・ポリシーを設定することができる。

1.1. 要件言語

本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[RFC2119]の記述にしたがって解釈される。

2. オリジン検証状態拡張コミュニティ

オリジン検証状態拡張コミュニティは、オペイクな拡張コミュニティ[RFC4360]で、以下のコード化を持つ:

fig1

拡張Typeフィールドの上位オクテット値は0x43で、非・推移型(non-transitive)であることを示す。IANAによって割り当てられた拡張Typeフィールドの下位オクテット値は0x00である。予約済みフィールドは0に設定され、このコミュニティの受信時には無視しなければならない(MUST)。拡張コミュニティの最後のオクテットは符号なし整数で、経路の検証状態[RFC6811]を示す。以下の値を取ることができる:

⚠️ transitive属性の日本語訳

BGP属性は、以下の4つのカテゴリに分類される

  1. well-known mandatory: すべてのBGPルータが認識すべき必須属性(無いとエラー)
  2. well-known discretionary: すべてのBGPルータが認識すべき裁量的属性(無くても良い)
  3. optional transitive: ルータは認識できなくてもいいが、他のルータに伝播する属性
  4. optional non-transitive: ルータは認識できなくてもいいが、他のルータに伝播しない属性

well-knownは周知でいいだろう。従って、周知必須属性、周知裁量属性となる。optionalは任意でいいだろう。transitiveをどう訳したらいいか? 今までは属性がBGPルータを越えて伝播する・しないを主において通過型・非通過型としていた。transitiveは「推移」とも訳せ、時が経つにつれて状態が変化することや、次々に移っていくことを意味する。通過型ではなく、任意推移型属性、任意非推移型属性の方が良いと思われる。

また、ウィキペディアで「推移関係」をみると、「集合Xの二項関係Rが推移的であるとは、Xの任意の元 a、b、cについて、aとbにRが成り立ち、bとcにRが成り立つとき、aとcにもRが成り立つことをいう。」とある。BGPは推移的信頼モデルで成り立っていると言えるし、PKIの証明書チェーンもそうである。

値 意味
0 検索結果 = 「有効」
1 検索結果 = 「見つからない」
2 検索結果 = 「無効」

本文書で定義されている拡張コミュニティをサポートするようにルータが設定されている場合、ルータは拡張コミュニティの最後のオクテットに算出された検証状態をマッピングすることで、IBGPピアに送信されるBGP UPDATEメッセージにオリジン検証状態拡張コミュニティを添付する必要がある(SHOULD)。同様に、受信側のBGPスピーカーは、ローカルデータに基づく検証状態がない場合でも、拡張コミュニティの最後のオクテットがあれば、そこから検証状態を導出する必要がある(SHOULD)。

実装は、複数のオリジン検証状態拡張コミュニティのインスタンスを送信してはならない(SHOULD NOT)。しかし、複数のインスタンスを受信した場合、実装は検証状態の値が数値的に最大のインスタンス以外のすべてのインスタンスを無視しなければならない(MUST)。実装は、受信した値が指定された最大値(2)より大きい場合、エラーのあるコミュニティを破棄し、さらなる分析のためにエラーをログに記録することで、属性破棄[RFC7606]と同様の戦略を適用しなければならない(MUST)。

デフォルトでは、実装は外部BGP(EBGP)ピアからオリジン検証状態拡張コミュニティを受信した場合、それ以上の処理を行わずにドロップしなければならない(MUST)。同様に、デフォルトでは、実装はEBGPピアにコミュニティを送ってはならない(SHOULD NOT)。しかし、許可されている場合、コミュニティを送ったり受け取ったりできるように実装を設定することが可能な必要がある(SHOULD)。コミュニティがEBGP ピアから受信したり、EBGPピアに送信したりする場合の例としては、2つの隣接するASが同じ管理下にある場合に行われる。2つ目の例は[SIDR-RPKI]に記載されている。

3. 導入に関する考慮事項

自律システム内のすべてのスピーカーが、本文書で定義されている拡張コミュニティをサポートするように改修されていない導入シナリオでは、オリジン検証拡張コミュニティで一致するポリシーを定義し、この拡張の実装と同じ方法で最適なパス選択に影響を与える別のBGP属性[RFC6811]を設定する必要がある。

⚠️ 代表的な実装について

Ciscoの実装

CiscoのRPKI検証の実装の特徴として、RPKI検証を有効にすると、RPKI的に無効となったアナウンスはBGP選択プロセスでは使われない(従って、無効なアナウンスはルーティング・テーブルに載ることはない)。

無効となったアナウンスをBGP経路選択プロセスに使うように変更することは可能で、IOS/IOX-XEの場合は「bgp bestpath prefix-validate allow-invalid」コマンド、IOS-XRの場合は「bgp bestpath origin-as allow invalid」コマンドを設定する。例えば、検証状態でポリシーを変更する場合は、このコマンドを設定しておく必要がある。

また、デフォルトでは、EBGPでのRPKI検証状態は、IBGPセッションに伝搬されない。以下のコマンドでRPKI検証状態が設定された拡張コミュニティを伝播させることができる。

IOS/IOS XEの場合、

router bgp 65000
 address-family ipv4 unicast
  neighbor 192.168.0.2 announce rpki state
  neighbor 192.168.0.2 announce send-community extended

IOS XRの場合、

router bgp 65000
 address-family ipv4 unicast
  bgp orgin as validation signal ibgp

IBGPピアは、RPKI拡張コミュニティを含むIBGP経路広告を受信すると、経路の検証状態を推測できるようになる。ここでも、受信したIBGPルータは、検証状態が無効なアナウンスは経路選択プロセスに使われないことに留意する。

Juniperの実装

Junos OSの場合、Ciscoのような専用コマンドはないが、ポリシーを柔軟に設定することができる。ただし、拡張コミュニティは以下のウェルノウン拡張コミュニティをサポートしている(コミュニティ値を設定する必要はない)。

  • origin-validation-state-valid
  • origin-validation-state-invalid
  • origin-validation-state-unknown

一般的な送信側のポリシーは以下の通り。

policy-statement ROUTE-VALIDATION {
    term valid {
        from {
            protocol bgp;
            validation-database valid;
        }
        then {
            validation-state valid;
            community add origin-validation-state-valid;
            accept;
        }
    }
    term invalid {
        from {
            protocol bgp;
            validation-database invalid;
        }
        then {
            validation-state invalid;
            community add origin-validation-state-invalid;
            accept;
        }
    }
    term unknown {
        from {
            protocol bgp;
            validation-database unknown;
        }
        then {
            validation-state unknown;
            community add origin-validation-state-unknown;
            accept;
        }
    }
}

RPKI Validatorと接続していないIBGPルータでは、下記ポリシーを設定することで、検証状態を推測することができる。

policy-statement ROUTE-VALIDATION-1 {
    term valid {
        from community origin-validation-state-valid;
        then validation-state valid;
    }
    term invalid {
        from community origin-validation-state-invalid;
        then validation-state invalid;
    }
    term unknown {
        from community origin-validation-state-unknown;
        then validation-state unknown;
    }
}
⚠️ ROVとRoute Reflector

規模の大きなネットワークの場合、IBGPフルメッシュ構成よりもRoute Reflector構成が一般的である。Route Reflector構成でのRPKIの適用についても考えておく必要がある。

4. IANAに関する考慮事項

IANAは、「BGP Origin Validation State Extended Community」(BGPオリジン検証状態拡張コミュニティ)という名前で、値 x00を「Non-Transitive Opaque Extended Community Sub-Types」(非・推移型オペイク拡張コミュニティのサブタイプ)レジストリに登録した。

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

[RFC4272]で説明しているようなセキュリティの考慮事項が引き続き適用される。本文書は一般的に経路選択に影響を与えるために使用される拡張コミュニティを導入するため、[RFC4593]のセクション 4.5 (「改ざん(Falsification)」)の分析が関連する。これらの問題は、新しいものでもなければ、オリジン検証拡張コミュニティに固有の問題でもない。

[RFC6811]で規定されているセキュリティ上の考慮事項は、このオリジン検証のアプリケーションにも同様に適用される。さらに、本文書では、ルータAがルータBに検証をアウトソーシングするスキームについて説明している。このスキームを使用する場合、参加ルータは適切な信頼関係を持つ必要がある。BがAを信頼するのは、両者が同じ管理下にあるためか、他の理由によるものである(例えば、[SIDR-RPKI]を考慮)。2つのルータ間のTCP接続のセキュリティ特性も考慮する必要がある。TCP接続の保護に関するアドバイスについては、[RFC7454]のセクション5.1を参照のこと。

6. 参考文献

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, http://www.rfc-editor.org/info/rfc2119.

[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, http://www.rfc-editor.org/info/rfc4360.

[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, http://www.rfc-editor.org/info/rfc6811.

6.2. 参考規格

[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, http://www.rfc-editor.org/info/rfc4272.

[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, DOI 10.17487/RFC4593, October 2006, http://www.rfc-editor.org/info/rfc4593.

[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, http://www.rfc-editor.org/info/rfc7454.

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, http://www.rfc-editor.org/info/rfc7606.

[SIDR-RPKI] King, T., Kopp, D., Lambrianidis, A., and A. Fenioux, "Signaling Prefix Origin Validation Results from a Route- Server to Peers", Work in Progress, draft-ietf-sidrops-route-server-rpki-light-01, January 2017.

謝辞

著者らは、本文書に関するウェスリー・ジョージ、ロケ・ガリアーノ、ブルーノ・デクレーヌからの貴重なレビューと提案に感謝の意を表す。

著者のアドレス

プラドシュ・モハパトラ
Sproute Networks
電子メール: mpradosh@yahoo.com

ケユル・パテル
Arrcus, Inc.
電子メール: keyur@arrcus.com

ジョン・スカダー
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
アメリカ合衆国
電子メール: jgs@juniper.net

デイブ・ウォード
Cisco
170 W. Tasman Drive
San Jose, CA 95124
アメリカ合衆国
電子メール: dward@cisco.com

ランディ・ブッシュ
Internet Initiative Japan, Inc.
5147 Crystal Springs
Bainbridge Island, WA 98110
アメリカ合衆国
電子メール: randy@psg.com

更新履歴

  • 2024.2.26
  • 2024.3.1: CiscoとJuniperのコマンドを追加
  • 2024.3.14: transitive/non-transitive
  • 2024.3.22
GitHubで編集を提案

Discussion