Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP 基準の検証

BGP の送信元の検証について

送信元の検証によって、意図しないルートの提供を防ぐことができます。ネットワーク管理者が、制御していないネットワークに対して誤ってルートをアドバタイズすることがあります。送信元の検証 (secure インタードメインルーティングとも呼ばれる) を構成することによって、このセキュリティーの問題を解決できます。送信元の検証とは、要求された自律システム (AS) からの発信元としてルートのアドバタイズを認証できるようにするメカニズムです。送信元検証は、1つ以上のリソース公開鍵インフラストラクチャ (RPKI) キャッシュサーバーを使用して、指定された BGP プレフィックスの認証を実行します。プレフィックスを認証するために、ルーター (BGP スピーカー) は検証されたプレフィックスツー AS のデータベースに対して、キャッシュサーバーからダウンロードしたものを照会し、プレフィックスが予期した AS からのものであることを確認します。

注:

RPKI 認証を有効にすると、Junos OS は通知なしで TCP ポート2222を自動的に開きます。フィルターを適用して、このポートをブロックしてセキュリティで保護することができます。

Junos OS は、IPv4 および IPv6 プレフィックスの基準検証をサポートしています。

図 1は、トポロジーの例を示しています。

図 1: 送信元検証用のサンプルトポロジ送信元検証用のサンプルトポロジ

サポートされる規格

Junos OS の実装元の検証では、以下の Rfc とドラフトがサポートされます。

  • RFC 6810, The Resource Public Key Infrastructure(RPKI)to Router Protocol

  • RFC 6811、BGP Prefix Origin Validation

  • インターネット ドラフト draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix Origin Validation State Extended Community( 一部サポート)

    拡張コミュニティー (送信元の検証状態) は、Junos OS ルーティングポリシーでサポートされています。ルート選択手順で指定された変更はサポートされていません。

送信元の検証の仕組み

RPKI および発行元検証では、X.509 証明書を使用し、RFC 3779、IP アドレスおよび AS 識別子の X.509 拡張で拡張が指定されています。

RPKI は、分散した情報の集合体で構成されています。各証明機関は、エンドエンティティ (EE) 証明書、証明書失効リスト (Crl)、署名付きオブジェクトを特定の場所で発行します。これらのリポジトリはすべて、すべての RPKI キャッシュサーバーで利用可能な完全な情報セットを形成します。

各 RPKI キャッシュサーバーは、ローカルキャッシュ内の各要素と元のリポジトリパブリケーションポイントを定期的に同期することで、分散リポジトリコレクション全体のローカルキャッシュを維持します。

ルーターでは、データベースエントリはルート検証 (RV) レコードとしてフォーマットされます。RV レコードは、「プレフィックス、最大長、起点としての基準」として、トリプルになります。このルートは、プレフィックス長が rv レコードで指定された最大長を超えず、送信元が RV レコードに指定された送信元と同じ場合に、プレフィックスの長さが、rv プレフィックスと一致します。

RV レコードは、ルート元認定 (roa)の簡素化されたバージョンです。ROA はデジタル署名されたオブジェクトで、IP アドレスブロックの所有者が、アドレスブロック内の1つまたは複数のプレフィックスへのルートを発信することを承認していることを確認する手段を提供します。ROAs は、ルート検証で直接使用されるわけではありません。キャッシュサーバーは、ROA の簡素化されたバージョンを、ルーターに RV レコードとしてエクスポートします。

最大長の値は、許可されたプレフィックスの長さ以上で、アドレスファミリの IP アドレスの長さ (ビット単位) 以下でなければなりません (IPv4 の場合は32、IPv6 の場合は 128)。最大長は、AS がアドバタイズを許可されている IP アドレスプレフィックスを定義します。

たとえば、IP アドレスプレフィックスが 200.4.66/24 で、最大長が26である場合、と AS は、200.4.66.0/24、200.4.66.0/25、200.4.66.128/25、200.4.66.0/26、200.4.66.64/26、200.4.66.128/26、200.4.66.192/26 のアドバタイズを許可されます。最大長が存在しない場合、AS は、RV で指定されたプレフィックスを正確に通知するようにのみ許可されます。

別の例として、RV は最大長が26で、最大長が28のプレフィックス 200.4.66.0/28 を使用して、プレフィックス 200.4.66/24 を含めることができます。この RV は、200.4.66 から始まるプリフィックスを提供するために、少なくとも23の長さと26個以上のプリフィックス 200.4.66.0/28 を使用していることを許可します。

ルートの起点は、AS_PATH 属性で数値として最も右に表示されます。送信元の検証では、送信元をルーティング更新として、承認された送信元を使用して、RV レコードに公開されているものと比較します。

送信元の検証によって提供されるセキュリティは、その攻撃者がソースになりすましたことを防ぐことができないため、特定された攻撃者に対して脆弱であることがわかっています。つまり、送信元の検証によって、偶発的なお知らせから効果的に保護することができます。

各ルーターを RPKI に直接参加させることで、送信元の検証を実装できますが、これは多大なリソース集約的性を備えています (RPKI データの検証には多くの公開鍵暗号化処理が必要になるため)。運用にも対応しています。各ルーターでの RPKI 構成の設定と維持に集中しています。このため、別の RPKI キャッシュサーバーは公開キーの検証を実行し、プレフィックスツー AS マッピングの検証済みデータベースを生成します。認証済みデータベースは、セキュアな TCP 接続を介してクライアントルーターにダウンロードされます。そのため、ルーターに必要なのは、RPKI インフラストラクチャに関する情報がほとんどなく、暗号化されたトランスポートパスワード以外の公開鍵暗号化の要件はありません。その後、ルーターは、ダウンロードされたデータを使用して、受信したルート更新を検証します。

サーバーセッションを構成すると、セッションをグループ化し、グループ内のセッションごとにセッションパラメーターを設定できます。ルーターは定期的に、キャッシュサーバーへの最大構成可能な接続数を設定しようとします。接続の設定が失敗した場合、新しい接続試行が定期的に行われます。

その間に、検証インポートポリシーが BGP セッションに適用された後、キャッシュセッションの状態 (up または down) と RV データベース (empty または empty) に関係なく、ルート検証が実行されます。RV データベースが空の場合、またはキャッシュサーバーセッションがどれも起動していない場合、受信した BGP プレフィックスを評価する RV レコードが存在しないため、各ルートの検証状態は unknown に設定されます。

再試行回数の期間は設定可能です。キャッシュサーバーへの接続が成功すると、ルーターは最新のデータベースシリアル番号を照会し、そのデータベースのバージョンに属するすべての RV エントリを RPKI キャッシュに送信するよう要求します。

各受信メッセージによって、RPKI キャッシュサーバーの liveliness タイマーがリセットされます。すべての更新を学習した後、ルーターは設定可能な間隔に基づいて定期的に liveliness チェックを実行します。これは、キャッシュサーバーが最新の通知 PDU で報告したものと同じシリアル番号を使用して、シリアルクエリプロトコルデータユニット (PDU) を送信することで実現されます。キャッシュサーバーは、ゼロ個以上の更新とデータ終端 (EOD) PDU を使用して応答し、キャッシュサーバーの liveliness 状態も更新し、レコード有効期限タイマーをリセットします。

外部の BGP (EBGP) ピアから受信したプレフィックスは、インポートポリシーによって検証され、有効、無効、不明、または未検証のいずれかのマークが付きます。

  • 有効 — プレフィックスとペアASがデータベースに見つかった場合を示します。

  • 無効 — プレフィックスが見つかったが、EBGP ピアから受信した対応する AS がデータベースに表示される AS ではなく、または BGP 更新メッセージ内のプレフィックス長さが、データベースで許可されている最大長よりも長いのいずれかを示します。

  • 不明 — プレフィックスがデータベース内のプレフィックスまたはプレフィックス範囲に含えられていないかどうかを示します。

  • 未検証 — プレフィックスの起点がデータベースに対して検証されないかどうかを示します。これは、データベースが作成され、BGP インポートポリシーで検証が呼び出されていないためです。送信元の検証が有効になっているか、BGP のピアに対して送信元の検証が有効になっていないことが原因です。

検証データベース内にルートに一致するものがある場合は、そのルートのいずれかを有効にする必要があります。それ以外の場合は無効です。このルートを有効にするには、一致する必要があります。最適な一致条件である必要はありません。一致する可能性がない場合のみ、ルートが不明であると見なされます。プレフィックス対 AS マッピング データベース ロジックの詳細については、 インターネット ドラフトの第 2 セクション 2 を参照してください draft-ietf-sidr-pfx-validate-01, BGP Prefix Origin Validation.

注:

RPKI 検証はプライマリ インスタンスでのみ実行できます。ルーティングインスタンスに対して RPKI 検証を設定した場合、RPKI 検証は失敗し、以下RV instance is not runningのエラーメッセージが表示されます。

BGP ルート検証データベースとの相互作用

ルート検証 (RV) データベースには、ルーターが RPKI キャッシュサーバーからダウンロードする RV レコードのコレクションが含まれています。RV データベースに RV レコードが設定されると、RV データベースは、リブローカルルーティングテーブルをスキャンして、データベース内の RV レコードによって影響を受ける可能性がある、リブ内のプレフィクスがあるかどうかを確認します。(リブローカルには、 show route protocol bgpコマンドの出力に表示される IPv4 および IPv6 ルートが含まれています)。

このプロセスにより、BGP インポートポリシー (エクスポートポリシーではない) の BGP 再評価がトリガーされます。

図 2は、プロセスを示しています。

図 2: BGP とルートの検証

インポートポリシーは、リブに適用されます。このことを理解するもう1つの方法は、インポートポリシーがshow route receive-protocol bgpコマンドの出力に表示されるルートに適用され、そのshow route advertising-protocol bgpコマンドによって表示されるルートにエクスポートポリシーが適用されるということです。

図 3示すように、インポートルーティングポリシーを使用してルーティングテーブル内のどこに BGP ルートを制御し、ルーティングポリシーをエクスポートしてルーティングテーブルから近隣にアドバタイズ BGP ルートを制御します。

図 3: ルーティングポリシーのインポートとエクスポートルーティングポリシーのインポートとエクスポート

ルート検証インポートポリシーを構成すると、ポリシー設定では照合条件validation-databaseが使用されます。この照合条件は、指定されたルーティングインスタンスのプレフィックスの検証状態について、RV データベース内のクエリをトリガーします。デフォルトの操作では、ルーティングインスタンスに一致する検証データベースが照会されます。ルート検証インスタンスが見つからなかった場合は、プライマリ インスタンスがクエリーを実行します。

以下のポリシー BGPでは、この状態によってルーターの RV データベースでの from validation-database ルックアップがトリガーされます。検証状態が有効な場合は、アクションが実行されます。そのためには、ルートを受け入れ、ルーティングvalidation-stateテーブルのを有効に設定します。

Community 属性は、RPKI 検証状態を IBGP 近隣に発表します。

プレフィックス検証は、外部 BGP (EBGP) の更新に対してのみ実行されます。AS 内では、すべての内部 BGP (IBGP) ルーターで RPKI セッションを実行する必要がない場合があります。代わりに、ibgp のすべてのスピーカーで一貫した情報を取得できるように、i BGP メッシュ全体で検証状態を実行する方法が必要です。これは、非推移性の拡張コミュニティーで検証状態を維持することで実現されます。コミュニティー属性は、IBGP 近隣ノード間のプレフィックスの検証状態をアナウンスして受け取ります。

Junos OS は、ルート検証の次の既知の拡張されたコミュニティをサポートしています。

  • 基準検証-状態-有効

  • 基準検証-状態-無効

  • 基準検証-状態-不明

次のサンプル BGP インポートポリシーは、RPKI サーバーとのセッションを備えたルーター上で構成されています。

RPKI セッションを使用したルーター

以下のサンプル BGP インポートポリシーは、RPKI サーバーとのセッションを持たない IBGP ピアルーター上に構成されています。

RPKI セッションなし IBGP ピアルーター

無着陸でアクティブなルーティングおよび送信元の検証

デュアル ルーティング エンジンとノンストップ アクティブ ルーティングが有効になっているルーターで、発生元検証を設定すると、プライマリ ルーティング エンジンとスタンバイ ルーティング エンジンの両方に RV データベースのコピーが追加されます。これらの2つの RV データベースは、相互に同期されたままです。

ルーターは、RPKI サーバーと同一の2つのセッションを維持しません。RPKI-RTR プロトコルはプライマリ プロトコルでのみルーティング エンジンします。スタンバイルーティングエンジンでは、RPKI キャッシュサーバーセッションは常に停止しています。

RV データベースは、RPKI サーバーとのセッションを通ルーティング エンジンプライマリ データベースによってアクティブに維持されます。このデータベースは、スタンバイルーティングエンジンに複製されます。セッションがスタンバイルーティングエンジンで停止しているにもかかわらず、複製された RV データベースには、RV レコードが含まれることになります。スタンバイのデバイスがルーティング エンジンプライマリ ネットワークになると、ルーティング エンジン完全に追加された RV データベースが追加されています。

2つのデータベースの内容を表示するにはshow validation databaseshow validation replication databaseおよびコマンドを使用します。

プレフィックス範囲を許可なしとしてマークする

ルート検証モデルには、1つの重大な欠点があります。正の更新のみが提供されます。それは、そのプレフィックスの正規の所有者として宣言できます。しかし、以下のように、負の更新を明示的に伝えることはできません。このプレフィックスは、AS で指定されているものではありません。この機能は、0を回避する方法を使用して、ある程度実現できます。

Junos OS 実装では、キャッシュからの入力を制限していません。たとえば、0としての送信元を持つ RV レコードは、他のものと同様にインストールされ、照合されます。これにより、0は AS が有効ではないため、アナウンスできないというプレフィックス範囲をマークする回避策が可能になります。RV レコード内の AS は、EBGP ピアから受信したものとは一致しません。したがって、一致するプレフィックスは無効としてマークされます。

BGP における導入基準検証のユースケースとメリット

自律システムの管理者が、他の企業の割り当てられたネットワークの全部または一部の広告を開始した場合、BGP には、そのエラーを認識して、サービス中断を回避する方法で対応するための組み込みメソッドはありません。

たとえば、顧客のネットワークの管理者が、トラフィックを誤って通知する (10.65.153.0/24 として) ことを、顧客のサービスプロバイダに1として説明しているとします。このルートは、実際のコンテンツプロバイダ (10.65.152.0/22) によって使用されるよりも具体的なルートであり、トラフィックは2として送られます。ルーターの動作によって、ほとんどのルーターはより多くの特定のルートを選択し、トラフィックを2ではなく1として送信します。

中継ルーターが、更新されたパス情報を伝達しているため、インターネット上でプレフィックスがハイジャックされています。無効なルートは、デフォルトの空きゾーン (DFZ) 内のルーターがハイジャックされたルートを送信する際に、インターネット全体に幅広く配信できます。最終的には、正確なパスが BGP ピアに復元されますが、サービス中断が予想されるようになります。

BGP は推移性の信頼モデルに依存しているため、顧客とプロバイダ間の検証が重要になります。上記の例では、サービスプロバイダは 10.65.153.0/24 の不具合のある広告を検証しませんでした。1が間違ったルートを伝達していたため、この提供情報を受け入れて、そのピアとプロバイダに readvertising します。このルートを1つ選択すると、ルーターはより具体的なルートとして選ばれていました。実際のコンテンツプロバイダは、ミスが発生する前に 10.65.152.0/22 を広告していました。/24 は、より小規模で、より具体的な広告を提供していました。通常の BGP ルート選択プロセスに従って、/24 が選択されており、ハイジャックが効果的に完了しています。

コンテンツプロバイダや他のプロバイダとの協力を迅速に検知して対応している場合でも、プレフィックスのサービスは、数分で数時間に中断することができます。システム停止の正確な継続時間は、インターネット上のシューティングポイントによって異なります。このようなイベントが発生した場合は、この脆弱性に対する解決策が更新されています。BGP は、プロバイダとの関係の基礎となるものであり、すぐには継続されません。この例では、送信元の検証を使用するソリューションについて説明します。このソリューションは、overtaxing のルーター Cpu を回避する分散型クライアント/サーバーモデルである BGP と、暗号化の拡張に依存しています。

発生元の検証は、プロバイダーが顧客から受信する提供情報を制限することで、推移性の信頼の脆弱性を克服するのに役立ちます。この仕組みには、拡張 BGP コミュニティー属性に基づいたルーティングポリシーの通信が含まれています。

例:BGP の送信元検証の設定

この例では、BGP ピア間での送信元の検証を設定する方法を示します。これにより、受信したルートアドバタイズが予期した自律システム (AS by) から送られてくることが保証されます。送信元が検証済みの場合、ポリシーでは、接頭辞が通知されるように指定できます。

要件

この例は、以下のハードウェアとソフトウェアの要件を満たしています。

  • リソース公開鍵インフラストラクチャ (RPKI) キャッシュサーバー、サードパーティー製ソフトウェアを使用して BGP プレフィックスを認証します。

  • TCP 接続を介してキャッシュサーバーと通信するルーティングデバイス上で実行されている Junos OS リリース12.2 以降。

概要

通信事業者のミスによって、ルートが意図せずアドバタイズされることがあります。このセキュリティの問題を回避するには、発信元を検証BGP、無効な通知をAS拒否する設定を行います。 この機能は、キャッシュサーバーを使用してプレフィックスまたはプレフィックス範囲を認証します。

次の構成文により、検証として基準を実現できます。

この例では、検証パラメーターにデフォルトの設定を使用しています。

利用可能な設定文のほとんどはオプションです。必要な設定は以下のとおりです。

[edit routing-options validation static]階層レベルを使用すると、ルーティングデバイスで静的レコードを設定して、rpki キャッシュサーバーから受信したレコードを上書きすることができます。

たとえば、以下のように記述します。

ルートプレフィックスの検証状態に基づいて動作するルーティングポリシーを設定できます。コミュニティー属性を使用して、外部 BGP (EBGP) と内部 BGP (IBGP) の両方のピア間のプレフィックスの検証状態を発表し、受信できます。ルーターによっては、RPKI サーバーとのセッションを構成するよりも、ルーティングポリシーを使用する方が便利な場合があります。この例では、IBGP ピア間で検証状態コミュニティー属性を使用する方法を示しています。

図 4に、トポロジーの例を示します。

図 4: 送信元検証用トポロジ送信元検証用トポロジ

この例では、デバイス R0 はデバイス R1 への IBGP 接続とデバイス R2 への EBGP 接続を備えています。デバイス R0 は、インターネット ドラフト draft-ietf-sidr-rpki-rtr-19、RV レコードを送信する RPKI/ ルーター プロトコルで定義されたプロトコルを使用して、キャッシュ サーバーからルート検証(RV)レコードを受信します。RPKI ルータープロトコルは TCP 上で動作します。RV レコードは、デバイス R0 によってローカル RV データベースを構築するために使用されます。デバイス R1 では、検証状態は検証状態と呼ばれる BGP コミュニティーに基づいて設定されます。これはルートとともに受信されます。

構成

CLI クイック構成

この例を簡単に構成するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除し、ネットワーク設定に一致する必要がある詳細情報を変更してから、コマンド[edit]を階層レベルで CLI にコピー & ペーストします。

デバイス R0

デバイス R1

デバイス R2

デバイス R0 の構成

順を追った手順

次の例では、構成階層のさまざまなレベルを移動する必要があります。デバイスのナビゲーションの詳細については、「 CLI ガイド 」の「 設定モードでの CLI Junos OS CLI エディター の使用 」 を参照してください

デバイス R0 を構成するには、次のようにします。

  1. インターフェイスを構成します。

  2. BGP を構成します。

    send-directエクスポートポリシーを適用して、ルーティングテーブルから BGP にダイレクトルートをエクスポートします。

    インポート ポリシーを適用して、デバイス R0 の EBGP ピアからインポート(または受信した)ルートすべてについて、検証状態と BGP コミュニティ属性を validation 設定します。

    デバイス R1 を使用して IBGP セッションを構成します。EBGP セッションをデバイス R2 で構成します。

  3. IBGP ピアとループバックインターフェイスを含むインターフェイス上で OSPF (またはその他の内部ゲートウェイプロトコル [IGP]) を構成します。

    注:

    IBGP neighborステートメントでループバックインターフェイスアドレスを使用する場合は、ループバックインターフェイス上で IGP を有効にする必要があります。それ以外の場合、IBGP セッションは確立されません。

  4. ルーティングテーブルから BGP に直接ルートをエクスポートするルーティングポリシーを設定します。

  5. 各 BGP ルートの検証状態に基づいて変更される属性を指定するルーティングポリシーを設定します。

  6. RPKI キャッシュサーバーを使用してセッションを構成します。

  7. 自律システム (AS) 番号を設定します。

結果

構成モードからshow interfaces、、、 show protocolsshow policy-options、およびshow routing-optionsコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

デバイスの設定が完了したら、設定commitモードから入力します。

デバイス R1 の構成

順を追った手順

次の例では、構成階層のさまざまなレベルを移動する必要があります。デバイスのナビゲーションの詳細については、「 CLI ガイド 」の「 設定モードでの CLI Junos OS CLI エディター の使用 」 を参照してください

デバイス R1 を構成するには、次のようになります。

  1. インターフェイスを構成します。

  2. BGP を構成します。

    インポート ポリシーを適用して、デバイスR1のIBGPピアから受信したルートすべてについて、検証状態と検証コミュニティ属性BGP validation-ibgp 属性を設定します。

    デバイス R0 を使用して IBGP セッションを構成します。

  3. OSPF を構成します。

  4. デバイス R0 から受信した BGP ルートの検証状態 BGP コミュニティー属性に基づいて、変更する属性を指定するルーティングポリシーを構成します。

  5. 自律システム (AS) 番号を設定します。

結果

構成モードからshow interfaces、、、 show protocolsshow policy-options、およびshow routing-optionsコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

デバイスの設定が完了したら、設定commitモードから入力します。

デバイス R2 の構成

順を追った手順

次の例では、構成階層のさまざまなレベルを移動する必要があります。デバイスのナビゲーションの詳細については、「 CLI ガイド 」の「 設定モードでの CLI Junos OS CLI エディター の使用 」 を参照してください

デバイス R2 を構成するには、次のようになります。

  1. インターフェイスを構成します。

    複数のアドレスがループバックインターフェイス上で設定され、デモンストレーション目的でのルートとして機能します。

  2. BGP を構成します。

  3. ルーティングポリシーを設定します。

  4. 自律システム (AS) 番号を設定します。

結果

構成モードからshow interfaces、、、 show protocolsshow policy-options、およびshow routing-optionsコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

デバイスの設定が完了したら、設定commitモードから入力します。

検証

構成が正常に機能していることを確認します。

変更した属性がルーティングテーブルに表示されていることを確認する

目的

デバイス R0 およびデバイス R1 上の BGP ルートに、予期される検証ステータスと予期されるローカルの基本設定があることを確認します。

アクション

動作モードから、 show routeコマンドを入力します。

ルートは、RPKI キャッシュサーバーから受け取った情報に基づいて、期待される検証状態とローカル設定値を持ちます。

トレース操作の使用

目的

送信元検証用のトレース操作を構成し、新たに提供されたルートの結果を監視します。

アクション
  • デバイス R0 でトレースを構成します。

  • デバイス R2 上で、ループバックインターフェイス上に別のアドレスを追加して、ルートを追加します。

  • デバイス R0 上で、トレースファイルを確認します。

ルートの検証は期待どおりに動作しています。

検証情報の表示

目的

さまざまな検証コマンドを実行します。

アクション