Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP送信元の検証

BGPのオリジン検証について

送信元の検証は、ルートの意図しないアドバタイズを防ぐのに役立ちます。ネットワーク管理者は、自分が管理していないネットワークに誤ってルートをアドバタイズすることがあります。このセキュリティの問題は、オリジン検証 (セキュリティで保護されたドメイン間ルーティングとも呼ばれます) を構成することで解決できます。送信元の検証とは、予想される自律システム(AS)からの発信としてルートのアドバタイズメントを認証できるようにするメカニズムです。オリジン検証では、1 つ以上のリソース公開キー基盤 (RPKI) キャッシュサーバーを使用して、指定された BGP プレフィックスの認証を実行します。プレフィックスを認証するために、ルーター(BGPスピーカー)は、キャッシュサーバーからダウンロードされた検証済みのプレフィックスツーASマッピングのデータベースに問い合わせ、プレフィックスが予想されるASからのものであることを確認します。

注:

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

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

図 1 サンプル トポロジーを示しています。

図 1: オリジン検証用のサンプルトポロジーオリジン検証用のサンプルトポロジー

サポートされている標準

起点検証のJunos OSの実装は、以下のRFCとドラフトをサポートしています。

  • RFC 6810、ルータープロトコルへのリソース公開キーインフラストラクチャ(RPKI)

  • RFC 6811、BGPプレフィックス原点の検証

  • インターネットドラフトdraft-ietf-sidr-origin-validation-signaling-00、 BGPプレフィックス起点検証ステートメント (部分サポート)

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

オリジン検証の仕組み

RPKIとオリジンの検証では、RFC 3779の IPアドレスとAS識別子のX.509拡張で指定された拡張子を持つX.509証明書を使用します。

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

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

ルータでは、データベース エントリは ルート検証(RV)レコードとしてフォーマットされます。RVレコードは(プレフィックス、最大長、送信元ASの)トリプルです。プレフィックスがRVプレフィックスと一致し、プレフィックス長がRVレコードで指定された最大長を超えず、送信元ASがRVレコードで指定された送信元ASと等しいルートに一致します。

RV レコードは、 ルート起点認証(ROA)の簡易バージョンです。ROAはデジタル署名されたオブジェクトで、IPアドレスブロックの所有者が、アドレスブロック内の1つまたは複数のプレフィックスに対するルート発信をASに承認していることを確認する手段を提供します。ROAはルート検証では直接使用されません。キャッシュサーバーは、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のプレフィックス200.4.66/24と、最大長28のプレフィックス200.4.66.0/28を含めることができます。このRVは、200.4.66で始まり、長さが24以上26以下のプレフィックスと、特定のプレフィックス200.4.66.0/28をアドバタイズすることをASに許可します。

ルートの起点は、AS_PATH属性の一番右にあるAS番号によって表されます。送信元の検証では、ルーティング更新内の送信元ASと、RVレコードに公開された承認済みのソースASを比較します。

送信元検証のみによって提供されるセキュリティは、ソースASに不正侵入している攻撃者などを防ぐことができないため、確定的な攻撃者に対して脆弱であることがわかっています。とはいえ、オリジン検証は、偶発的な発表に対する有用な保護を提供します。

送信元の検証は、各ルーターを RPKI に直接参加させることで実装できますが、(RPKI データの検証には多くの公開キー暗号化操作が必要なため)リソースを大量に消費するだけでなく、各ルーターで RPKI 構成を設定して維持するには運用負荷が高すぎると見なされます。このため、別のRPKIキャッシュサーバーは公開キーの検証を実行し、プレフィックスツーASマッピングの検証済みデータベースを生成します。検証されたデータベースは、安全なTCP接続を介してクライアントルーターにダウンロードされます。したがって、ルーターはRPKIインフラストラクチャに関する情報をほとんど必要とせず、暗号化されたトランスポートパスワード以外の公開キー暗号化要件もありません。その後、ルーターはダウンロードしたデータを使用して、受信したルート更新を検証します。

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

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

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

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

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

  • 有効—プレフィックスとASのペアがデータベースに存在することを示します。

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

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

  • 未検証—プレフィックスの発信元がデータベースに対して検証されていないことを示します。これは、オリジン検証が有効になっているか、BGPピアに対してオリジン検証が有効になっていないにもかかわらず、データベースにデータが入力され、BGPインポートポリシーで検証が呼び出されないためです。

検証データベース内のルートに一致する可能性がある場合、ルートが有効になるには、そのうちの 1 つと一致する必要があります。それ以外の場合は無効です。ルートを有効にするには、どの一致でも十分です。ベストマッチである必要はありません。一致する可能性のあるルートがない場合にのみ、ルートは不明と見なされます。プレフィックスからASへのマッピングデータベースロジックの詳細については、インターネットドラフトdraft-ietf-sidr-pfx-validate-01のセクション2、 BGPプレフィックス原点の検証を参照してください。

注:

RPKI 検証は、プライマリ インスタンスでのみ使用できます。ルーティング インスタンスに RPKI 検証を設定すると、RPKI 検証が失敗し、次のエラー メッセージが表示されます 。RV instance is not running

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

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

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

図 2 にプロセスを示します。

図 2: BGPとルート検証

インポートポリシーは RIB-In に適用されます。これを理解する別の方法は、インポート・ポリシーはコマンド の出力に表示されるルートに適用され、エクスポート・ポリシーは コマンドで示される ルートに適用されるということです。show route receive-protocol bgpshow route advertising-protocol bgp

に示すように 、 に示すように、インポート ルーティング ポリシーを使用して BGP がルーティング テーブルに配置するルートを制御し、エクスポート ルーティング ポリシーを使用して、BGP がルーティング テーブルからネイバーにアドバタイズするルートを制御します。図 3

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

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

次のBGPインポートポリシーでは、 条件によって ルーターのRVデータベースでの検索がトリガーされます。from validation-database 検証状態が有効な場合は、アクションが実行されます。アクションは、ルートを受け入れ、ルーティングテーブル内の を有効に設定 することです。validation-state

IBGPネイバーにRPKI検証状態を通知するコミュニティ属性

プレフィックス検証は、外部 BGP(EBGP)更新に対してのみ実行されます。AS内では、すべての内部BGP(IBGP)ルーターでRPKIセッションを実行しないようにすることがあります。代わりに、すべての IBGP スピーカーが一貫した情報を持つように、IBGP メッシュ間で検証状態を伝送する方法が必要です。これは、非移行性拡張コミュニティーで検証状態を伝送することによって実現されます。コミュニティ属性は、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がプレフィックスの正規所有者かを宣言できます。ただし、次のように、否定的な更新を明示的に伝えることはできません。このプレフィックスは、指定されたASから発信されることはありません。この機能は、AS 0の回避策を使用してある程度提供できます。

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

BGPのオリジン検証のユースケースとメリット

自律システム(AS)の管理者が他社に割り当てられたネットワークの全部または一部をアドバタイズし始めた場合、BGPにはエラーを認識し、サービスの中断を回避するような方法で応答する方法が組み込まれていません。

例えば、顧客ネットワークの管理者が誤ってルート(例えば10.65.153.0/24)をアドバタイズし、顧客のサービスプロバイダAS 1にトラフィックを誘導したとします。この/24ルートは、トラフィックをAS 2に転送する実際のコンテンツプロバイダ(10.65.152.0/22)が使用するルートよりも、より具体的なルートです。ルーターの仕組み上、ほとんどのルーターはより具体的なルートを選択し、AS 2ではなくAS 1にトラフィックを送信します。

ハイジャックされたプレフィックスは、トランジットルーターが更新されたパス情報を伝播するため、インターネット上で広く見られます。デフォルトのフリーゾーン(DFZ)のルーターがハイジャックされたルートを伝送するため、無効なルートはインターネット全体に広く配布される可能性があります。最終的には、正しいASパスがBGPピアに復元されますが、それまでは、サービスの中断が予想されます。

BGPは推移的な信頼モデルに依存しているため、顧客とプロバイダ間の検証が重要です。上記の例では、サービスプロバイダAS 1は、10.65.153.0/24の不具合のあるアドバタイズメントを検証しませんでした。このアドバタイズメントを受け取って、それをそのピアとプロバイダに再アドバタイズすることで、AS 1は間違ったルートを伝達していました。このルートをAS 1から受け取るルーターは、そのルートがより具体的なルートであるという理由でそれを選択しました。実際のコンテンツプロバイダーは、間違いが発生する前に10.65.152.0/22を宣伝していました。/24は、より小さな(そしてより具体的な)広告でした。通常のBGPルート選択プロセスに従って、/ 24が選択され、ハイジャックが事実上完了しました。

コンテンツプロバイダーの迅速な検出と反応、および他のプロバイダーとの協力があっても、それらのプレフィックスのサービスは、何分から数時間まで中断される可能性があります。停止の正確な期間は、インターネット上の見晴らしの良い場所によって異なります。この種のイベントが発生した場合、この脆弱性の解決策に新たな関心が寄せられます。BGPはプロバイダー関係の基本であり、すぐになくなることはありません。この例では、オリジン検証を使用するソリューションを示します。このソリューションは、BGPの暗号拡張と、ルーターCPUに過剰な負荷をかけない分散型クライアントサーバーモデルに依存しています。

オリジン検証は、プロバイダーが顧客から受け入れるアドバタイズを制限できるようにすることで、推移的な信頼の脆弱性を克服するのに役立ちます。メカニズムには、拡張BGPコミュニティ属性に基づくルーティングポリシーの通信が含まれます。

例:BGPのオリジン検証の設定

この例では、受信したルートアドバタイズメントが予想される自律システム(AS)から送信(発信)されるようにすることで、BGPピア間の送信元検証を設定する方法を示します。送信元ASが検証済みの場合、ポリシーでは、プレフィックスが同様にアドバタイズされるように指定できます。

要件

この例には、次のハードウェア要件とソフトウェア要件があります。

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

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

概要

オペレーターのエラーにより、意図せずにルートがアドバタイズされることがあります。このセキュリティ上の問題を防止するには、BGPを設定して、発信元のASを検証し、これらの無効なアナウンスを拒否します。 この機能は、キャッシュサーバーを使用してプレフィックスまたはプレフィックス範囲を認証します。

以下の設定ステートメントで、元のAS検証を有効にします。

この例では、検証パラメーターの既定の設定を使用します。

使用可能な設定ステートメントのほとんどはオプションです。必要な設定は次のとおりです。

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

たとえば、以下のように表示されます。

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

図 4サンプルのトポロジーを示しています。

図 4: 起点検証のトポロジー起点検証のトポロジー

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

設定

CLIクイック構成

この例をすばやく設定するには、次のコマンドをコピーしてテキストファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、[edit]階層レベルのCLIにコマンドをコピー&ペーストしてください。

デバイスR0

デバイスR1

デバイスR2

デバイス R0 の設定

ステップバイステップでの手順

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

Device R0を設定するには:

  1. インターフェイスを設定します。

  2. BGP を設定します。

    エクスポート ポリシーを適用して、ルーティング テーブルから BGP に直接ルートがエクスポートされるようにします。send-direct

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

    デバイスR1とのIBGPセッションを設定します。デバイスR2とのEBGPセッションを設定します。

  3. IBGPピアに面するインターフェイスとループバックインターフェイスにOSPF(または別の内部ゲートウェイプロトコル[IGP])を設定します。

    注:

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

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

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

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

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

結果

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

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

デバイスR1の設定

ステップバイステップでの手順

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

Device R1を設定するには:

  1. インターフェイスを設定します。

  2. BGP を設定します。

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

    デバイスR0とのIBGPセッションを設定します。

  3. OSPFを設定します。

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

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

結果

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

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

デバイスR2の設定

ステップバイステップでの手順

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

デバイスR2 を設定するには:

  1. インターフェイスを設定します。

    ループバックインターフェイスには、デモンストレーション用のルートとして機能するいくつかのアドレスが設定されています。

  2. BGP を設定します。

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

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

結果

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

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

検証

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

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

目的

デバイスR0とデバイスR1のBGPルートが、予期される検証状態と想定されるローカルプリファレンスを備えていることを確認します。

アクション

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

意味

ルートには、RPKIキャッシュサーバーから受信した情報に基づいて、予想される検証状態とローカルプリファレンス値があります。

トレース操作の使用

目的

起点検証のためのトレース操作を設定し、新たにアドバタイズされたルートの結果を監視します。

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

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

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

意味

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

検証情報の表示

目的

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

アクション