見出し画像

BlockJack: 許可型ブロックチェーンを活用したBGPのセキュリティ向上プロトコル

しゅま

はじめに

この記事では、ブロックチェーンを用いた、ドメイン間ルーティングプロコトル（BGP）のプレフィックスハイジャック攻撃の予防策を提案した論文を紹介します。BlockJack と名付けられたこのプロコトルは、Hyperledger Fabric ブロックチェーンおよび Quagga ソフトウェアパッケージを使用しています。

RPKI

IETF は、IP プレフィックスハイジャックから BGP を保護するためのリソース公開鍵インフラストラクチャ（RPKI）を提供しています。BGP ハイジャックを防ぐために、IETF はルートオリジン権限（ROA）用の RFC 6482 とルートオリジン検証（ROV）用の RFC 6483 をリリースしています。 ROA は、AS がその管轄下で広告される多数のプレフィックスを承認し、IP プレフィックスのタプル（AS（所有者）、AS の最大長、および各 IP ブロックの有効期限）を格納するプロセスです。プレフィックスの乗っ取りを防ぐために、ROV プロセス中にタプルを使用して、AS が許可されたプレフィックスを広告しているかどうかを確認できます。

BlockJack

下図は、BlockJack の 3 つのモジュール、Blockchain、Profiler、Dispatcher を示しています。それぞれの役割は以下の通りです。

  • Profiler
    ルーターのプロファイルを作成し、Blockchain へのゲートウェイを容易にします。

  • Blockchain
    スマートコントラクト、CA プロバイダー、データストレージ（Ledger）、およびコンセンサスメカニズムを処理します。また、特定の AS 権限の下ですべてのルーター資格情報を保存するためのウォレットも提供します。

  • Dispatcher
    ルーティングテーブルを監視するためのルーチンタスクを実行し、BGP ルーティングテーブルに更新がある場合はフィルタリングコマンドをディスパッチします。

各モジュールについて詳しく説明します。

Blockchainモジュール

Blockchain モジュールには Hyperledger Fabric プラットフォームを活用しています。パブリックブロックチェーンとは異なり、Hyperledger Fabric は、信頼できる既知のコンソーシアムメンバーパーティのみがブロックチェーントランザクションやブロックの作成に関与できます。

Hyperledger Fabric は、マイナーやその他のパブリックベースのコンセンサスの役割を置き換え、Orderer、Endorser、Chaincode、Ledger 自体を含むいくつかのコンポーネントを追加することでコンセンサスメカニズムを処理しています。この研究では、BlockJack の必要に応じて、Chaincode を変更し、データベース構造を調整しています。Chaincode は、コンソーシアムメンバー間のトランザクションのビジネスロジックを処理するプログラムのコードです。Chaincode はスマートコントラクトとして機能し、Endorser がトランザクションを承認または却下するためのマトリックスとして使用します。一方、Ledger は、コンセンサスメカニズムによって承認されたすべてのトランザクションを格納し、承認されたエンティティにクエリ接続を提供するデータベースです。

Hyperledger Fabric では、2 つの異なるデータベース、World State とBlockchain で構成されています。World State は、一連の元帳状態の現在の値を格納するデータベースです。これによって、トランザクションログ全体の値を走査する必要なしに、トランザクション要求が「現在の値」に直接アクセスすることができます。トランザクションの状態が作成、更新、または削除されると、World State が動的に変化する場合があります。一方、Blockchain はすべての変更を記録し、現在の World State に表示され、トランザクションログに保存されます。コミット要求が発生するたびに、World State のトランザクションがブロック内に収集され、ブロックチェーンに追加されます。したがって、ブロックチェーンは変更された履歴で構成され、変更できない現在の World State になります。

この研究のために、対応するプレフィックスから取得された Chaincode とトランザクションキーに対応するように元帳を準備します。これにより、インデックス作成プロセスにより検索（取得）プロセスが高速化されます。プレフィックスの PREFIX、ASN、DOCUMENT TYPE、ACTIVESTATUS の 4 つの列で構成されるテーブルを作成しています。BGP テーブルで一時的な撤回が発生した場合は動的なステータスが必要です。したがって、プレフィックスの再アナウンスによって新しいトランザクションが作成されることはなく、プレフィックスのステータスが変更されるだけです。

おそらく、ACTIVESTATUS を変更することで動的な対応を可能にしている

Profilerモジュール

Profiler は、Dispatcher と Blockchain 間のインターフェースとして使用されます。下図は、Profiler モジュールが、Admin 機能、ルータープロファイラー機能、および Rest API 機能の 3 つの部分で構成されていることを示しています。

  • Admin 機能
    管理者がルータプロファイルを作成する前に、Blockchain 内の Fabric CA モジュールを呼び出すことにより、管理者の資格情報を作成するために使用される機能です。

  • ルータープロファイラー
    管理者が内部 AS から各ルーターのプロファイルを作成するために使用する機能です。プロファイルは、router-id と AS 番号で構成されます。router-id は、ルーターが資格証明書を作成するために、Fabric CA に送信されるルーターのユーザ名として使用されます。管理者とルーターのすべての資格情報がウォレットに保存されます。

  • Rest API サーバ
    Dispatcher から Blockchain へのゲートウェイとして使用できる Rest API サーバとしての機能です。Rest API サーバは、Blockchain にプレフィックスを追加し、Blockchain からプレフィックスをクエリする機能を提供します。これらの機能はプレフィックスの承認と検証のプロセスに役立ちます。この機能は、ルーターからの各 http クエリに認証ルーチンを提供し、Blockchain に送信される前に、対応するルーター資格情報をクエリに提供します。

Dispatcherモジュール

Router Dispatcher（Dispatcher）は、ルーターマシンと対話するために使用されます。これはルーターで機能しますが、Dispatcher 内のルーチンは BGP ルーティング信号から独立しています。このアプローチにより、通常のルーターは BlockJack を装備したルーターに接続できるため、ルーターソフトウェアの更新を最小限に抑えることができます。Dispatcher は、下図に示すように、監視（Monitor）、送信者（Sender）、検証者（Verifier）の 3 つのルーチンで構成されます。ローカル BGP モードでルーターによってアナウンスされた一時プレフィックスを格納するために使用されるローカル ROA と、隣接する AS によってアナウンスされた、一時的な格納に使用するローカル ROV の 2 つのローカルキャッシュもあります。

  • 監視（Monitor）ルーチン
    BGP ルーティングテーブルを監視しており、SSL コマンドを送信して BGP ルーティングテーブルを照会するシェルスクリプトで構成されます。このコマンドは、プレフィックスの送信元に到達するために使用可能な各ルートの network（プレフィックス）、ネクストホップ（next hop）、メトリック（metric）、ローカルプリファレンス（local preference）、重み（weight）、および AS パス（AS-path）の値を返します。 これらの戻り値から、BlockJack はネットワーク、ネクストホップ、および AS パスを取得します。次に、AS パスを分割して各プレフィックスのオリジン AS を見つけ、AS パスの残りの AS を排出し、プレフィックスとネクストホップと結合します。プレフィックスが内部 AS に由来する場合、組み合わせ値は ROA 変数に割り当てられ、そうでない場合は ROV 変数に割り当てられます。モニターはステータスが有効で、Blockchain への承認および検証プロセスを減らすのに最適なルートのみをキャプチャします。

  • 送信者（Sender）ルーチン
    後に紹介するプレフィックス認証処理をサポートします。Sender は Monitor ルーチンが生成した ROA 変数とローカル ROA キャッシュを比較し、内部 AS オリジンからのプレフィックスのアナウンスや撤回を求める機能で構成されます。新しいプレフィックスのアナウンスがあった場合、Sender は Profiler に HTTP(S) リクエストを送信し、新しいプレフィックスとそのオリジンを Blockchain に追加します。プレフィックスの取り下げが発生した場合、Sender は Blockchain 内のプレフィックス状態を更新するリクエストを送信します。

  • 検証者（Verifier）ルーチン
    後に紹介するプレフィックス検証処理をサポートします。Verifier ルーチンの主な機能は、ルータの近隣からアナウンスされた新しいプレフィックスを送信し、Blockchain に格納されたデータと照合することです。Verifier は Monitor が提供する ROV 変数を使用し、それをローカル ROV キャッシュと比較して、近隣から発表された新しいプレフィックスを見つけます。また、Verifier は、ルーティングテーブルの衝突源となるプレフィックスが確認された場合に、特定の近隣からの受信プレフィックスを制限する Inbound filter コマンドをルータに送信する機能で構成されています。

BlockJackのメカニズム

BlockJack は、Blockchain の初期化、管理者やルーターの登録などのサポートメカニズムと、プレフィックスの認証や検証などのメインメカニズムで構成されています。サポートメカニズムとは、Blockchain ネットワークを運用し、Blockchain と対話する管理者やルーターの認証情報を作成するために使用されるプロセスです。

プレフィックス認証

Blockchain を活用することで、AS はプレフィックス認証を使用して、プレフィックスの所有権を証明します。プレフィックス認証は、Dispatcher モジュールが BGP ルーティングテーブルを読み込む際に開始されます。Dispatcher の Monitor ルーチンは、内部 AS ルーターによるプレフィックスのルートアナウンスを読み込んで定義し、変数に保存しています。Monitor は、プレフィックスリストの数を減らすために、valid と best というステータスで現れるルートを捕捉します。次に、Sender ルーチンは Monitor から得られた値をローカル ROA キャッシュと比較し、新しいプレフィックス・アナウンスを見つけます。新しいプレフィックスが見つかった場合、Sender ルーチンは Profiler に https リクエストを送信し、Blockchain へのプレフィックス追加を要求します。Profilerでは、Rest API サーバーがリクエストを受信し、ルータープロファイルへのリクエストを認証します。認証されると、Profiler はルーターの資格をリクエストに追加し、Blockchain に送信します。

Blockchain では、Endorser が Chaincode に書かれたコントラクトに基づいてリクエストを検証します。スマートコントラクトは、新しいプレフィックスが Blockchain に以前から保存されている同じプレフィックスに違反していないかどうかをチェックします。リクエストがスマートコントラクトに適合すると、Endorser は Orderer にプレフィックスを送信し、Blockchain のコンセンサスメカニズムが起動されます。Orderer はコンソーシアムメンバー全員にリクエストを配布し、コンソーシアムメンバーの 50% 以上から承認を得ます。コンセンサスが得られたら、Orderer はコミッターにトランザクションをブロックに含める合図行い、Orderer は Blockchain に新しいブロックを追加します。Blockchain のトランザクションが終了すると、Orderer は新しいWorld State を作成し、コンソーシアムメンバーに配布して台帳の状態を更新します。

プレフィックスの追加と修正処理は、Hyperledger のコンセンサスメカニズムを呼び出してチェーンに新しいブロックを追加するため、BlockJack モデルで実施するにはどちらもコストがかかります。下の式に示すように、プレフィックス $${x}$$ を認証するコスト $${C_A(x)}$$ は、Profiler によるリクエストのレイテンシ（遅延）：$${L_R(x)}$$、各コンソーシアムメンバー $${i}$$ の少なくとも 50% の Endorsement 承認にかかるレイテンシの合計：$${L_E(x)}$$、さらに新しいブロックが作られ、$${N}$$ 個のコンソーシアムメンバーに分配するレイテンシ：$${L_D(x)}$$ の合計と等しくなっています。コミッターがトランザクションを成立させるための遅延は、Blockchain では単純な処理に過ぎないため、省略しています。プレフィックスの認証処理はコストがかかるが、各 AS は自分のプレフィックスを認証するだけでよいので、Blockchain にプレフィックスを追加する総コストはプレフィックス所有者に分散させることができます。

$$
C_A(x) = L_R(x) + \sum^{\frac{N}{2}}_{i = 1}L_E(x) + \sum^{N}_{i = 1}L_D(x)
$$

プレフィックス検証

プレフィックス検証は、ルーターが近隣から受信したアナウンスメントに、認証されたプレフィックスが含まれているかどうかをチェックすることを目的としています。このために、BlockJack はルーティングテーブルで見つかったプレフィックスと Blockchain に保存されているプレフィックスを比較します。プレフィックス検証の仕組みは、Dispatcher モジュールで開始されます。Monitor ルーチンは、ステータスが valid-best のプレフィックスルートをキャプチャし、近隣から広告されたプレフィックスを ROV 変数に代入します。次に Verifier ルーチンはこの変数とローカル ROV キャッシュに格納されたプレフィックスを比較し、新しいプレフィックスの広告を見つけます。新しいプレフィックスが広告された場合、Verifier は Profiler を通じて Blockchain に検証を要求します。Profiler モジュールでは、Rest API サーバーでリクエストを受け付け、ルーター資格情報に対して認証した後、Blockchain にリクエストを送信します。

Blockchain モジュールでは、Chaincode がスマートコントラクトへのリクエストの適合を検証し、Ledger にクエリを発行します。クエリ結果は、スマートコントラクトによって検証され、有効、無効、不明の 3 種類のシグナルが発行されます。有効シグナルは、Blockchain に送信するプレフィックスが利用可能で、正しい AS 番号に対応していることを示します。一方、無効シグナルは、Ledger にそのプレフィックスが存在するが、異なる AS 番号に対応していることを示します。この無効シグナルは、ネットワーク上で BGP プレフィックスハイジャックが発生していることを示す可能性があります。未知シグナルは、Ledger にプレフィックスと AS 番号の両方が存在しないことを示します。本研究では、非 BlockJack ルータがプレフィックスをアナウンスできるようにし、検証の誤検出を減らすために、未知シグナルは Dispatcher に有効なシグナルを返すことにしています。Verifier は無効シグナルを受け取ると、プレフィックスハイジャックの発信源と指摘された AS からのアナウンスをブロックする Inbound filter コマンドを生成します。Inbound フィルターは、検証前に Monitor ルーチンによって割り当てられた ROV 変数にあるネクストホップのパラメタを必要とします。

ルーターが資格証明書とスマートコントラクトに適合した後、他のコンソーシアムメンバーの承認なしに台帳のデータ検索を行うことができるなど、認証メカニズムと比較して、プレフィックス検証は簡単です。さらに、検証のために取り出された台帳は、対応する Blockchain ノード、より具体的には現在の World State データベースに含まれています。したがって、検証プロセスは承認よりもはるかに高速に行うことができます。

テストベッドと評価

論文の著者らはテストベッドを使用し、BlockJack の BGP ハイジャック攻撃に対する性能と回復力を評価するために、いくつかの実験セットを実施しています。

性能評価

BlockJack の性能は、プレフィックス認証およびプレフィックス検証クエリの処理時間という観点から評価することを目的としています。このため、2 組の実験を実施し、BlockJack の認証・検証メカニズムの処理時間を記録しています。具体的には、BlockJack のルーターからランダムなプレフィックスのセットを生成し、Blockchain に問い合わせ、提案するシステムで必要となる認証と検証の時間を測定しています。

プレフィックス認証の設定については、Dispatcher モジュールに機能を作成して、様々な数のプレフィックスを Blockchain に送り、プレフィックス認証処理における BlockJack の性能を測定しています。各プレフィックスの認証処理はコミット順に行われるため、プレフィックスを追加するたびに Blockchain にブロックが追加されることになります。実験の最後には、チェーン上に 1000 個のブロックが存在することになります。プレフィックス検証時間を測定するために、Dispatcher が様々な数のプレフィックスを送信し、1000 ブロックの Blockchain で検証できるようにスクリプトが作成されています。

耐障害性評価

耐障害性評価は、様々なシナリオでプレフィックスハイジャック攻撃を無効化する BlockJack の耐障害性を観察することを目的としています。そのために、Quagga と Docker を活用し、20～60 台の様々なルータ数のネットワークトポロジを複数作成しています。プレフィックスハイジャックの無効化を、「Prefix Prepending」と「Neutralization」の 2 段階で測定しています。Prefix Prepending は、プレフィックスが通過する AS ごとに、BGP テーブルの AS-path パラメータに ASN を追加する処理のことです。この実験では、プリペンディングの時間は、敵対プレフィックスが Dispatcher の存在するルーター（BlockJack ルーター）に到着するのに要する時間に等しく、元のプレフィックスを有効ベストの状態の経路として破壊します。一方、Neutralization は、BlockJack がハイジャックを検知、検証し、ルーターにフィルタコマンドを送信して中和する段階です。プリペンディング（BGP ハイジャック攻撃）時間と中和（ブロッキング）時間を測定することで、BGP ハイジャック攻撃の持続時間と BlockJack の攻撃無効化効率をそれぞれ判断しています。

この実験では、3 つのシナリオで検証しています。

  1. シングルパス攻撃シナリオ
    この最初のシナリオは、シングルパスから発生する攻撃を無効化する際の BlockJack の耐性を評価することを目的としています。二分木ネットワークトポロジーを作成し、ルートに位置するルーターにディスパッチャを常駐させます。このとき、最遠の枝に位置するルータが、木の葉に位置するルーターが広告するプレフィックスをハイジャックするために使用する 5 つの敵対的プレフィックスを用意しています。これらの攻撃は、BlockJack ルータ（ルート）に到達した時点でシングルパスを作成します。
    20〜60 の様々なルーター数で 5 つの実験セットを用意し、各セットで 5 つの実験を行い、各試行のプリペンディングと中和の時間を記録しています。各実験セットに公平な扱いをするため、実験設定ごとに Blockchain ネットワークを再起動しています。

  2. マルチパス攻撃シナリオ
    このシナリオは、BGP プレフィックスハイジャック時に発生するルーティングパスの変更を予測する BlockJack の回復力を検証するために設計されたものです。このシナリオでは、最初のシナリオの二分木ネットワークトポロジーを変更し、各ブランチに対して同じレベルの BGP ピアリングを設定します。これにより、広告された各プレフィックスは、ツリーのルートにある BlockJack ルータに到達する際に複数の経路を持つことになります。
    最初のシナリオと同様に、プレフィックス認証をバイパスするスクリプトも作成し、ルーター数を 20～60 に変化させたさまざまなセットアップで合計 25 回の実験を用意しています。

  3. ランダム攻撃シナリオ
    このシナリオは、非常にランダムな BGP 環境における BlockJack の回復力を検証するために設定されました。様々な数のルーター（20～60 台）で、いくつかのランダムなネットワークトポロジーを作成しています。各実験の接続レベルは 25% に設定され、これは 1 つのノードがネットワーク上の全ノードの 25% に接続される確率があることを示します。ただし、ルーター数が 20 の実験では、ネットワーク内で接続されていないノードが発生しないように 50% に設定されています。また、Dispatcher をランダムなノード（ルーター）に配置するスクリプトを作成し、各セットの実験でオリジナルのルータが広告するプレフィックスをハイジャックするために使用するランダムな敵対プレフィックスを 5 つ用意されています。
    各実験で BlockJack を 10 分間実行し、異なる数のルーターで 5 セットの実験結果を得ることを試みています。Dispatcher と敵対プレフィックスはランダムに割り当てられるため、Dispatcher が配置されたルータではハイジャック処理が影響しない可能性もあります。その場合、実験結果を破棄し、ルーティングテーブル内の少なくとも 1 つのプレフィックスがハイジャックの影響を受けることが判明するまで、再度実験が行われています。また、指定された時間内に敵対的なプレフィックスがルーティングテーブルに現れない場合は、ハイジャック処理が Dispatcher の置かれているルーティングテーブルに影響を与えないと仮定されています。

実験結果の分析

プレフィックス認証とプレフィックス検証の実行に要する平均時間および合計時間の測定結果を下図に示しています。表中のプレフィックス数は、各プレフィックス追加の後に必ず Blockchain に新しいブロックを追加することを意味するコミットコマンドが続くことを考慮し、Blockchain のブロック数に比例しています。

プレフィックス認証の分析

上の図より、Blockchain に送信されるプレフィックス数に応じて、プレフィックス認証時間が徐々に増加することがわかります。BlockJack は 1,000 個のプレフィックスを認可するのに 2,154.32 秒、平均認可時間は 2.16 秒で、これは 2 ノードの小さなブロックチェーン環境であってもかなり重いものです。これは、チェーンへのブロック追加時の複雑なコンセンサスメカニズムに起因するものです。

Cisco ルーターで設定された BGP メッセージについて、BGP UPDATE 間隔が 30 秒の場合、その間に認可できる最大プレフィックス数は 13 プレフィックスです。この 1 間隔あたりの 13 プレフィックスは、※1 で示された AS オリジンあたりの 12 プレフィックス平均アナウンスよりも高い値です。したがって、この場合、BlockJack は、ネットワークトラフィックの遅延を無視して、ローカル ROA キャッシュの補助なしに、1 つの BGP UPDATE メッセージ間隔で同時に実環境の平均プレフィックス広告を処理することができます。

※1

BlockJack では保守的なアプローチを採用したため、AS のプレフィックス保有数が最も多い場合のプレフィックス認証時間を算出します。※1 によると、AS が広告したプレフィックス数の最高値は AS8151 (Uninet S.A. de C.V., MX) で 8125 プレフィックスです。この場合、BlockJack が初めて実行されたとき、全プレフィックスを認証するために 625 個の BGP UPDATE 間隔、つまり 17,550 秒が必要となります。この結果は、Blockchain ノードがルーターマシンに存在し、BGP メッセージ信号に依存している場合、BGP UPDATE 間隔とプレフィックス認証の間に明らかにレースコンディションが発生していることを示しています。Blockchain にアクセスする時間は、BGP UPDATE メッセージの間隔をはるかに上回ります。したがって、Blockchain とルーティング環境を独立して動作させる BlocJack アプローチは、実世界の条件を考慮すると合理的です。

プレフィックス検証の分析

実験結果から、プレフィックス認証に比べ、プレフィックス検証処理は非常に軽量であることがわかります。BlockJack は 1000 個のプレフィックスを検証するために 92.12 秒を要し、1 プレフィックスあたり平均 0.09 秒になります。最悪のシナリオとして、1 日あたり 150 個のプレフィックスが同時期に出現することを想定し、同量のプレフィックスが同時期に離脱すると仮定すると、BlockJack は更新された 300 個のプレフィックスを検証するのに27秒しか必要としません。これは、BGP UPDATE メッセージの間隔である 30 秒を下回っています。また、コンソーシアムメンバーの承認がなくても、内部データベースに問い合わせるだけなので、コンソーシアムメンバーの増減が検証時間に影響を与えることはありません。さらに、Hyperledger Fabric は World State を提供しているため、BlockJack はデータ検索のためにすべてのログトランザクションをトレースする必要がありません。したがって、この場合、BlockJack はローカル ROV キャッシュの支援なしにプレフィックス検証を処理することができます。

しかし、グローバル BGP ルーティングテーブルの検証を 1 回の BGP UPDATE メッセージの間隔で行うのは、非常に困難です。グローバルなルーティングテーブルの数を 85 万個と仮定し、プレフィックスあたりの検証時間を 0.09 秒とすると、初回実行時に BlockJack がこれらのプレフィックスを検証するのに要する時間は合計 76,500 秒となります。この結果は、BGP UPDATE メッセージ間隔の 2,550 秒に相当します。したがって、BlockJackの動作中の検証要求を減らすには、ローカル ROV キャッシュの存在が不可欠です。ディスパッチャは、BGP ルーティングテーブルのエントリとローカル ROV キャッシュを比較して、新しいプレフィックスの広告や廃止の発生を見つけ、それらのプレフィックスを検証することができます。さらに、BGPメッセージ間隔を超える検証は、Dispatcher が BGP メッセージ信号に依存しないため、BlockJack に影響を与えることはありません。

耐障害性の分析

BlockJack は、BGP ルーティングテーブルを乱すすべての敵対的なプレフィックスを無効化することができます。BlockJack は以下の条件で敵対的プレフィックスを無視します。まず、敵対的プレフィックスがオリジナルのプレフィックスを引き継いで有効なベストパスとならない場合です。これは、オリジナル・プレフィックスの位置が敵対プレフィックスに近い場合や、BGP テーブルにあるオリジナル・プレフィックスのすべての属性値の累積が敵対プレフィックスより優れている場合に可能です。第二に、AS パスの敵対プレフィックスの位置が他の敵対プレフィックスと重複している場合です。これにより、AS パスが短い敵対プレフィックスが無力化されたときに、AS パスが長い敵対プレフィックスが自動的に無力化されることになります。

BlockJack の耐障害性評価結果を上図に示してます。シングルパス攻撃とマルチパス攻撃のシナリオでは、ルーターの追加に応じて平均プリペンディング時間が徐々に増加するのに対し、ランダム攻撃の場合は平均プリペンディング時間が変動しているように見えることがわかります。シングルパス、マルチパス、ランダムアタックシナリオのすべての実験セットの平均プリペンディング時間はそれぞれ、74.527 秒、80.9088 秒、54.9572 秒です。

中和時間は、平均 1.0484 秒を記録したランダム攻撃シナリオを除き、シングルパスシナリオで平均 0.1516 秒、マルチパスシナリオで 0.2362 秒とすべてのシナリオで一定のようです。ランダム攻撃シナリオでの中和時間は、マルチパスシナリオと比較して最大で 5 倍となっています。これは、ランダム攻撃シナリオの隣接数がマルチパスシナリオより多いためです。送信された 5 つの敵対的プレフィックスから、ランダムシナリオの平均攻撃回数は 10.08 回に達するのに対し、マルチパス攻撃シナリオで BlockJack ルーターが受けた攻撃回数は 4.52 回です。50 台のルーターを使用したランダム攻撃シナリオを例にとると、5 回の実験のうち 12.04 回の攻撃を中和するのに、BlockJack は平均 0.957 秒を必要とします。この記録は、1 つの攻撃を中和するのに 0.08 秒に相当します。

プリペンディング時間と中和時間の標準偏差も、シングルパスとマルチパスのシナリオで一定であり、プリペンディング時間は平均 8.2488 秒から 11.6154 秒、中和時間は 0.0162 秒から 0.0188 秒の範囲であることがわかります。一方、ランダム攻撃シナリオでは、プリペンディング時間と中和時間の平均標準偏差は、それぞれ 20.3712 秒と 0.8998 秒と記録されました。

まとめ

プレフィックス認証とプレフィックス検証の処理は、理想的には 1 つの BGP Update メッセージで処理できますが、いくつかの条件を満たすと、Blockchain 上で発生する処理と BGP 上で発生する処理の間でレースコンディションが発生することになります。そのため、BlockJack が採用している保守的なアプローチは、この問題に対処するのに適しています。また、BlockJack は、BGP の属性値の変化により、BGP ルーティングテーブルの最良の有効経路の決定が動的に変化することによる動的多重ハイジャックにも対応しています。

この記事が気に入ったらサポートをしてみませんか？