ジュニパールーター上のBGPでのRPKI統合

この投稿では、RPKI認証システムに関するすべての情報をまとめたかったのですが、トピックはかなり広範囲であることが判明しました。さらに、インターネットのロシア語部分で、RPKIの原理を詳細に説明する記事（記事の最後にあるこれらの記事へのリンク）に出会いました。 ライブハードウェアでのRPKIのチューニングと適用の例では、事態はさらに悪化しています。 したがって、私はHOW-TOのスタイルで記事を作成することにしました。 この記事に記載されている情報は、プロバイダーがクライアントから受信したプレフィックスをチェックするプロセスを自動化し、フィルターのエラーを排除するのに役立ちます。 RPKIを使用して動的ルーティングを保護し、LinuxでRPKIキャッシュサーバーを構成することに関心がある人は、catの下でお願いします。

理論

まず、いくつかの用語：

RPKI（Resource Public Key Infrastructure）は、インターネット上のグローバルルーティングのセキュリティを確保するために設計された階層型公開キーシステム（PKI）です。 RPKIは、IPアドレスとAS番号（ RFC3779 ）の使用を許可する追加の拡張機能を備えたX.509 PKI証明書アーキテクチャ（ RFC5280 ）を使用します。 証明書の構造により、インターネットリソース（IPアドレスと自律システムの数）の分布を決定できます。 インターネットリソースは、IANAによって最初に地域インターネットレジストリ（RIR）を介して配信され、次にローカルインターネットレジストリ（LIR）に配信され、ローカルインターネットレジストリ（LIR）が顧客間でインターネットリソースを配信します。 RPKIシステムも同じ方法で構築されます。 インターネットリソースのその後の各配布には、「親」、つまりこれらのインターネットリソースを最初に提供した組織のキーで署名された証明書の作成が伴います。 各インターネットリソースに関連付けられたこのような証明書の全体がデータベースを構成し、それによって情報の正確性を検証できます。 このようなデータベースは、すべてのRIRのパブ​​リックRPKIリポジトリにあります。

ROA（ルートオリジン認証） -ルートを作成する許可。 仕様に従って、ROAには、許可されたASの番号、このASがアナウンスする許可を持っているIPプレフィックスのリスト、および対応する情報リソースを説明する証明書が含まれています。 認証システムの詳細については、記事「アドレス指定可能なインターネットリソースの認証」を参照してください。このリンクは投稿の最後にあります。

プレフィックスの検証は直接RPKIセッションで各ルーターによって個別に実行できますが、このアプローチはルーターリソース（RPKIデータを受信する際のリソース集約的な暗号化操作）の大きな支出を必要とするため推奨されません。 このデータを使用するには、ベースをパブリックRPKIリポジトリと同期するローカルRPKIキャッシュサーバーをサポートすることをお勧めします。 受信したデータは処理され、キャッシュサーバーでチェックされます。 次に、キャッシュサーバーはプレフィックスからASへのエントリを生成します。 生成されたデータベースは、RPKI-RTRプロトコルを使用した安全なTCP接続を介してルーターにアップロードされます。 したがって、ルーターは暗号化情報を処理し、RPKIデータを操作する必要がありません。 その後、ルーターは既製のテーブルを使用してプレフィックスをチェックします。

ルーターでは、データベースはRV（ルート検証）エントリの形式で表示されます。 RVデータベースには、RPKIキャッシュサーバーからルーターがダウンロードできるRVレコードのコレクションが含まれています。 RVレコードは、プレフィックス、最大プレフィックス長、ASソースで構成されます。 このレコードは、RVレコードプレフィックスフィールドが一致する各ルートをチェックするために使用されます。 また、RVレコードで指定された最大長とAS番号もチェックします。 RV記録は、ROA記録の簡略化された形式です。 ROAエントリ自体はルートの検証に使用されないため、キャッシュサーバーは既に生成されたRVエントリをルーターにエクスポートします。

RV記録のルートを確認する手順：

• RVレコードの最大プレフィックス長は、レコードが作成されたルートマスクの長さ以上でなければなりません。
• AS_PATHで示される最初の（右の）ASプレフィックスは、RVレコードのAS番号と一致する必要があります。

RVレコードのローカルデータベースの状態に関係なく、すべてのプレフィックスがルーターによってチェックされます。 検証時にデータベースが空の場合、データベースにはこのプレフィックスに関する情報がないため、すべてのプレフィックスにステータス不明が設定されます。 データベースが更新されるたびに、ルーターはキャッシュサーバーのタイマーをリセットするため、データベースの変更の参照ポイントが設定され、データベースのバージョンがメモリに保存されます。 再接続すると、ルーターはメモリ内にあるデータベースのバージョンをキャッシュサーバーに送信し、バージョンが最新でない場合は更新が行われます。

検証に基づいてeBGPが受信するプレフィックスには、次の3つの状態があります。

• 有効-プレフィックスとAS番号がデータベースにあることを示します
• 無効-プレフィックスがデータベースで見つかったが、プレフィックスのソースのAS番号がデータベースで指定されたAS番号と一致しないか、BGPメッセージのプレフィックス長がデータベースで指定された最大許容長を超えていることを示します
• 不明-プレフィックスがデータベースに見つからず、データベースのどのネットワークにも含まれていないことを示します

練習する

まず、ルーターが通信するRPKIキャッシュサーバーを構成する必要があります。 これらの目的のために、RIPE NCCは、UNIXに似たOS上で実行され、2つの部分で構成されるRPKI検証アプリケーションを開発しました。

1. RPKIデータベースを操作するためのWebインターフェイス
2. ルーターデーモン

Java 7をインストールする必要があります。RPKIバリデーターをインストールするための以降のすべての手順は、Ubuntu 12.04で実行されます。

Java 7をインストールします。

sudo apt-get remove openjdk* sudo add-apt-repository ppa:webupd8team/java sudo apt-get update sudo apt-get install oracle-java7-installer export JAVA_HOME=/usr/lib/jvm/java-7-oracle #    bashrc echo "export JAVA_HOME=/usr/lib/jvm/java-7-oracle" >> /etc/bash.bashrc 

RIPEページからバリデーター自体をインストールします。

 cd /tmp wget https://certification.ripe.net/content/static/validator/rpki-validator-app-2.15-dist.tar.gz tar -xzvf /tmp/rpki-validator-app-2.15-dist.tar.gz -O <_> 

バリデーターを開始します：

 cd <_> ./rpki-validator.sh start 

応答として、以下が表示されます。

 [ info ] Starting rpki-validator... [ info ] writing logs under log directory [ info ] Web user interface is available on port 8080 [ info ] Routers can connect on port 8282 [ info ] Writing PID 15860 to validator.pid 

メッセージからわかるように、検証デーモンは2つのポートを占有します。

• 8080-RPKI検証Web管理インターフェイス
• 8282-ルーターを接続するためのインターフェース

APIを使用してcurlを使用すると、RPKIバリデーターの動作を確認できます。

 curl http://localhost:8080/api/v1/validity/AS174/89.207.56.0/21 

AS174はAS番号、89.207.56.0 / 21は検証が必要なASプレフィックスです。 応答として、次のものを取得します

 { "validated_route":{ "route":{ "origin_asn":"AS174", "prefix":"89.207.56.0/21" }, "validity":{ "state":"Valid", "description":"At least one VRP Matches the Route Prefix", "VRPs":{ "matched":[{ "asn":"AS174", "prefix":"89.207.56.0/21", "max_length":21 }], "unmatched_as":[{ "asn":"AS3257", "prefix":"89.207.56.0/21", "max_length":21 },{ "asn":"AS41073", "prefix":"89.207.56.0/21", "max_length":21 }], "unmatched_length":[] } } } } 

ブラウザでアドレス<server_ip_address>：8080に移動すると、管理インターフェイスが表示されます。


[信頼アンカー]タブで、すべてのルートRPKIサーバーのリスト。


[ROA]タブで、インストールされたRPKI署名を持つすべてのプレフィックスのリスト（すべての既知のROA）。 このインターフェースでは、AS番号（AS174-Cogentプロバイダー）などの任意のパラメーターで検索できます。


[BGPプレビュー]タブで、ROAの有無にかかわらずすべてのプレフィックスのリスト。 このタブは、ASのすべてのプレフィックスをチェックするのに便利です。


このインターフェイスは、リモートデータ取得用のAPIも提供します。


次に、RPKIキャッシュサーバーと連携するようにJuniperルーター自体を構成します。

プレフィックスをチェックするために、RPKIキャッシュサーバーとのセッションを設定します。 この例では、RPKIバリデーターはサーバー192.168.0.10:8282で実行されており、ルーターはアドレス192.168.0.1からアクセスします：

 {master}[edit] user@router# show | compare [edit routing-options] + validation { + group RPKI-validator { + session 192.168.0.10 { + refresh-time 120; + hold-time 180; + port 8282; + local-address 192.168.0.1; + } + } + } 

JuniperルーターでRE保護を使用する場合は、RPKIキャッシュサーバーからのトラフィックを許可するルールも追加する必要があります。

 {master}[edit] user@router# show | compare | display omit [edit policy-options] + prefix-list RPKI-servers { + apply-path "routing-options validation group <*> session <*>"; + } + prefix-list RPKI-locals { + apply-path "routing-options validation group <*> session <*> local-address <*>"; + } [edit firewall family inet] + filter accept-rpki { + apply-flags omit; + interface-specific; + term accept-rpki { + from { + source-prefix-list { + RPKI-servers; + } + destination-prefix-list { + RPKI-locals; + } + protocol tcp; + } + then { + count accept-rpki; + accept; + } + } + } [edit interfaces lo0 unit 0 family inet filter] - input-list [ accept-bgp accept-common-services discard-all ]; + input-list [ accept-rpki accept-bgp accept-common-services discard-all ]; 

構成を適用すると、セッションが確立されます。

 {master}[edit] user@router# run show validation session detail Session 192.168.0.10, State: up, Session index: 2 Group: RPKI-validator, Preference: 100 Local IPv4 address: 192.168.0.1, Port: 8282 Refresh time: 120s Hold time: 180s Record Life time: 3600s Serial (Full Update): 16 Serial (Incremental Update): 16 Session flaps: 0 Session uptime: 00:00:16 Last PDU received: 00:00:14 IPv4 prefix count: 7061 IPv6 prefix count: 1109 

RVルーターデータベースが更新されます。

 user@router> show validation database | last 20 2a04:71c0::/29-32 200086 192.168.0.10 valid 2a04:81c0::/29-48 48526 192.168.0.10 valid 2a04:8400::/32-64 41887 192.168.0.10 valid 2a04:8d40::/29-32 50304 192.168.0.10 valid 2a04:8f00::/29-29 49531 192.168.0.10 valid 2a04:92c0::/29-29 62240 192.168.0.10 valid 2a04:93c0::/32-48 60251 192.168.0.10 valid 2a04:9fc0::/29-32 24904 192.168.0.10 valid 2a04:a5c0::/29-29 199789 192.168.0.10 valid 2c0f:f668::/32-32 37519 192.168.0.10 valid 2c0f:f970::/32-32 37596 192.168.0.10 valid 2c0f:f9b0::/32-32 37390 192.168.0.10 valid 2c0f:f9b8:a::/48-48 37674 192.168.0.10 valid 2c0f:f9b8:f::/48-48 16265 192.168.0.10 valid 2c0f:faf8::/32-32 37403 192.168.0.10 valid 2c0f:fbf0::/28-28 32653 192.168.0.10 valid 2c0f:fc00::/27-27 3741 192.168.0.10 valid 2c0f:feb0::/32-32 37100 192.168.0.10 valid IPv4 records: 7061 IPv6 records: 1109 

確立されたセッションは、RPKI検証Webインターフェイスでも確認できます。


ルータでプレフィックスをチェックするためのポリシーステートメントを設定します。 柔軟なプレフィックスフィルターを構築するために、ジュニパーネットワークスは特別なBGPコミュニティの作成を推奨しています。

• 起点検証状態有効
• 起源検証状態無効
• 起源検証状態不明

これにより、ルーターはスキャン結果に基づいてプレフィックスをマークできます。 このメカニズムは、eBGPを介して受信したプレフィックスを解析する境界ルーターで使用すると便利です。 たとえば、このようなエッジルーターはすべてのプレフィックスをそのようなコミュニティにマークでき、RPKIキャッシュサーバーを介した追加の確認なしで、iBGPを介して接続されたすべてのASルーターは、これらのコミュニティを信頼するルーティングテーブルを構築します。 この方法では、一部のルーターでのみRPKI-RTRセッションを構成できるため、RPKIキャッシュサーバーの負荷を軽減できます。 また、ポリシーは、チェックの結果に基づいてプレフィックスに異なるローカル設定を設定します。 これにより、 IETFの推奨事項を考慮してルーティングテーブルを構築し、テストに合格しなかったプレフィックスの最低優先度を設定できます。

ポリシーを作成します。

 {master}[edit] user@router# show | compare [edit policy-options] + policy-statement RPKI-validation { + term valid { + from { + protocol bgp; + validation-database valid; + } + then { + local-preference 110; + validation-state valid; + community add origin-validation-state-valid; + next policy; + } + } + term invalid { + from { + protocol bgp; + validation-database invalid; + } + then { + local-preference 90; + validation-state invalid; + community add origin-validation-state-invalid; + next policy; + } + } + term unknown { + from protocol bgp; + then { + local-preference 100; + validation-state unknown; + community add origin-validation-state-unknown; + next policy; + } + } + } [edit policy-options] + community origin-validation-state-invalid members 0x43:100:2; + community origin-validation-state-unknown members 0x43:100:1; + community origin-validation-state-valid members 0x43:100:0; 

コミュニティ構成では、AS番号は100です。AS番号に置き換える必要があります。

ルーターのルーティングテーブルを見てみましょう。

 {master} user@router> show route protocol bgp validation-state valid | last 12 2c0f:faf8::/32 *[BGP/170] 2d 01:27:30, localpref 110 AS path: 174 30844 37105 37403 37403 I, validation-state: valid > to 2001:978:2:b4::1:1 via ae0.12 2c0f:fbf0::/28 *[BGP/170] 2d 01:27:30, localpref 110 AS path: 174 6939 3741 32653 I, validation-state: valid > to 2001:978:2:b4::1:1 via ae0.12 2c0f:fc00::/27 *[BGP/170] 2d 01:27:30, localpref 110 AS path: 174 3356 3741 I, validation-state: valid > to 2001:978:2:b4::1:1 via ae0.12 2c0f:feb0::/32 *[BGP/170] 2d 01:27:30, localpref 110 AS path: 174 37100 ?, validation-state: valid > to 2001:978:2:b4::1:1 via ae0.12 {master} user@router> show route protocol bgp validation-state invalid | last 12 2a03:f85:1::/48 *[BGP/170] 2d 01:27:36, localpref 90 AS path: 174 34305 I, validation-state: invalid > to 2001:978:2:b4::1:1 via ae0.12 2a03:f86:4::/48 *[BGP/170] 2d 01:27:36, localpref 90 AS path: 174 174 54020 59692 I, validation-state: invalid > to 2001:978:2:b4::1:1 via ae0.12 2a03:f87:ffff::/48 *[BGP/170] 2d 01:27:36, localpref 90 AS path: 174 9002 57169 I, validation-state: invalid > to 2001:978:2:b4::1:1 via ae0.12 2a03:bb40::/32 *[BGP/170] 2d 01:27:36, localpref 90 AS path: 174 174 I, validation-state: invalid > to 2001:978:2:b4::1:1 via ae0.12 {master} user@router> show route protocol bgp validation-state unknown | last 12 2c0f:ff40::/26 *[BGP/170] 2d 01:29:56, localpref 100 AS path: 174 6939 10474 I, validation-state: unknown > to 2001:978:2:b4::1:1 via ae0.12 2c0f:ff90::/32 *[BGP/170] 2d 01:29:56, localpref 100 AS path: 174 174 6453 15808 I, validation-state: unknown > to 2001:978:2:b4::1:1 via ae0.12 2c0f:ffa0::/32 *[BGP/170] 01:39:27, localpref 100 AS path: 174 9498 37273 I, validation-state: unknown > to 2001:978:2:b4::1:1 via ae0.12 2c0f:ffd8::/32 *[BGP/170] 2d 01:29:56, localpref 100 AS path: 174 174 33762 I, validation-state: unknown > to 2001:978:2:b4::1:1 via ae0.12 

これらのコマンドの結果は、ルーティングテーブルで有効なルートに優先順位が与えられていることを示しています。

現実

残念ながら、現時点では、多くのプロバイダーがRPKIを使用するスキームを避けています。これは、世界のフルビュールーティングテーブルからのプレフィックスのほんの一部に証明書があるためです。 さらに、すべてのお客様がネットワークのROAレコードを構成したいわけではありません。 プロバイダーは、ほとんどの場合、whoisデータに基づいてプレフィックスフィルターを自動的に更新し、スクリプトを1日に1回または2回実行するための実績のあるスキームを使用します。 このようなスキームは、whoisデータベースへの完全な信頼を意味し、データベースは顧客自身によって更新され、RIRごとに異なる場合があります。 小規模な地域プロバイダーは、 ランダムピアフィルターに依存しているため、フィルターについてまったく心配する必要がないため、「 トラフィックアトラクション 」攻撃の原因になります。 状況は、RPKIキャッシュサーバーのインストールと保守のための追加コストの必要性によっても悪化します。 多くの人によると、実装コストは結果を返さないため、かなりの臨界質量に達するまで、この技術は「紙」の形のままになる可能性が高い。

参照資料

• アドレス指定可能なインターネット認証
• インターネットルーティングシステムのセキュリティ