Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

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、 リソース公開鍵インフラ (RPKI) からルータープロトコルまで

  • RFC 6811、 BGP 接頭辞基準検証

  • インターネットドラフトドラフト-ietf-sidr 発信元検証-00、 BGP プレフィックス送信元検証状態の拡張コミュニティー(部分的サポート)

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

送信元の検証の仕組み

RPKI および送信元の検証では、RFC 3779 で指定されている拡張機能を使用して、509の証明書に 509の IP アドレスおよび識別子としての拡張

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 ピアから受信したものがデータベースに表示されているのとは異なることを示します。または、BGP update メッセージのプレフィックス長がデータベースの最大許容長よりも長くなっています。

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

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

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

RPKI 検証は、master インスタンスでのみ使用できます。ルーティングインスタンスに対して 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 インポートポリシーでは、 from validation-databaseこの条件によってルーター’s RV データベースでルックアップがトリガーされます。検証状態が有効な場合は、アクションが実行されます。そのためには、ルートを受け入れ、ルーティング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 ピアから受信したものとは一致しません。したがって、一致するプレフィックスは無効としてマークされます。