はじめに

この記事では、BGP とブロックチェーンを掛け合わせたプロジェクトをまとめている調査論文を紹介します。この論文を読んでもわかるように、ブロックチェーンをネットワーク技術、とくに BGP に利用する論文がいくつか登場しています。BGP には何が欠けていて、ブロックチェーンを活用することによってどうやって解決しているのかが少しでもわかると嬉しいです。

オリジン検証

BGP では、ネットワークの全ての参加者は誠実であることを仮定しています。このことから、受信者は BGP 広告のオリジンも一貫性も検証しません。BGP に対する攻撃数が増えたことによって 2012 年から RPKI（Resource Public-Key Infrastructure）が始まりました。

RPKI 証明書の所有者は、IP プレフィックスと AS 番号を紐づけた Route Origin Authorisation（ROA）エントリに署名することができます。ROA はサードパーティが検証できる RPKI リポジトリに挿入されます。これによって、RPKI を利用している各 AS は、ネットワークに IP プレフィックスを広告する権利が自分にあることを証明できます。

しかし、RPKI には主に 2 つの問題点が指摘されています。1 つ目に、RPKI のデプロイが遅すぎる点です。グローバル RPKI デプロイモニターによると、グローバル・ルーティングテーブルには RPKI で検証できないプレフィックス / オリジンのペアは 68% 以上となっています。その理由として考えられるのは、RPKI の 2 つ目の問題点である「集中化」です。RPKI モデルでは、上位のエンティティは下位のエンティティによって発行された分配を編集することができます。実際、上位のエンティティが権力を濫用したり、第三者が上位のエンティティを攻撃した場合の単一障害点など、いくつかの問題のきっかけになります。これは、ネットワーク全体のルーティングに影響を与える可能性があります。

BGPsec

BGPsec は、AS がアナウンスされたアップデートの AS パスに正しい AS 番号のみを挿入することを保証するメカニズムです。 実際、アナウンスされたパスは、トラフィック転送に使用される実際の AS パスと正しく一致します。一方、BGPsecは、レコードに署名して検証するために各 AS に証明書を提供する RPKI サービスに依存しています。 AS が Update メッセージを受信した後、AS は署名を確認し、ネクストホップの AS 番号を挿入して、新しい Update メッセージに署名します。実際のシナリオでは、BGPsec ルーターは RPKI キャッシュサーバーを使用して、検証プロセスによって引き起こされる過負荷を排除できます。 RPKI キャッシュサーバーは発信元を確認し、Update メッセージのパスを検証してから、結果を AS 内のすべての BGP ルーターに配布します。 BGPsec は、ドメイン間ルーティングのセキュリティを向上させるように設計されていますが、ワームホールやモグラ攻撃などの脆弱性がまだあります。

パス検証

パス全体を検証するためには、パス上の全てのホップを調査する必要があります。これは各プロジェクトによって様々な手法が提案されています。

BGPCoin は、スマートコントラクト内のすべての AS に対して、許可された隣接 AS のリストを追加することにより、パスエンド認証をサポートしています。ホルダープレフィックスは、更新または削除トランザクションを送信することにより、AS のリストを変更できます。キャッシュは、受信したアナウンスの発信元 AS の許可リストを定期的に同期し、結果を BGP ルーターに送信します。広告されたパスのオリジン AS の前のエンドホップ AS が、許可されたオリジン AS のリストに存在しない場合、BGP ルーターはアナウンスを拒否します。ただし、これは、攻撃者がオリジン AS に直接接続していると主張できるパスのラストホップを狙った攻撃のみを排除します。

別プロジェクトでは、エンドツーエンドの経路検証を開発しています。基本的な原理は、学習したアナウンスを順番に調査することです。システムが学習した IP プレフィックスを近隣から伝搬すると、IP プレフィックス属性を持つトランザクションを公開する必要があります。公開されたトランザクションは、伝搬されるプレフィックス、トランザクションを初期化する AS の署名、プレフィックスを学習した AS のリスト、宛先 AS のリストという属性を含んでいます。その結果、プレフィックスに向かう信頼できるパスのセットが得られます。さらに、その出力はプレフィックスごとの有向 AS レベルグラフに変換されます。プレフィックスに関連するトポロジーに基づいて、ノードはアナウンスの発信者がプレフィックスへの有効なパスを持っているかどうかを検証することができます。

ポリシー検証

プロバイダーの中には、ルーティングのインポートおよびエクスポートポリシーを決定するさまざまなタイプのビジネス契約が存在します。

• Customer-Provider:
  AS 顧客は AS プロバイダーに料金を支払うことでアクセスすることができ、トラフィックを転送してもらえます。

• Peering:
  2 つの AS が支払いなしでトラフィックを転送します。

Customer-Provider の場合、顧客の経路はプロバイダーによってすべての近隣 AS に伝播される可能性があります。また、 Peering またはプロバイダー経路は、さらに顧客に伝播することしかできないとされています。

ISRchain では、システム内のすべての AS に ASI コントラクトがあり、ローカル AS に関する情報を保持しています。このスマートコントラクトの項目の 1 つはピアリングであり、すべてのペアが、隣接する AS がプロバイダーであるかどうかを示すフラグを持っています。AS がアナウンスを受信すると、AS パスの各ホップを調査して、ルートポリシーが満たされているかどうかを判断します。最終的に、AS はピアリング、顧客、プロバイダから経路を受信する 3 つの行動シナリオの正式な証明を提供します。

BRVM では、AS が隣接 AS に経路を伝播し、その署名で経路証明を構築します。さらに、AS 経路の長さを表す経路のクラスと、前の経路証明へのポインタを含みます。そして、経路検証システムに送られ、検証ノード間のコンセンサスを得た後、検証してブロックチェーンに挿入する必要があります。経路証明チェーンのおかげで、経路受信者は AS 間で合意が履行されているか、利用可能な最短経路を持つ経路を受信したかどうかを調査することができます。性能を評価するために、BRVM の著者らは階層型トポロジーと線形トポロジーで実験を行っています。同様に、検証プロセスを加速するために、ローカルキャッシュの使用も検証しています。

スケーラビリティ

BGP Updates による 1 日あたりの平均収束時間は約 50 秒かかります。ブロックチェーンを活用するには、攻撃を防ぐために、新しいブロックができるまでの期間は、この間隔よりも短く実行する必要があります。この論文で分析されたプロジェクトのほとんどは、この収束時間よりも低いレイテンシーに達しています。

最も困難な問題の 1 つは、ブロックチェーンの肥大化です。トランザクションを検証する場合、ノードはフルノードとして実行する必要があります。この場合、ノードは完全なデータセットをブロックチェーン履歴に保存します。チェーンのサイズは毎年大きくなっています。この論文で分析されたプロジェクトでは、2020 年にチェーンのサイズがどれだけ増加するかを推定しようとします。一部のプロジェクトでは、トランザクションのサイズや使用されている GAS（手数料）に関する情報が記載されていないため、すべてのプロジェクトを見積もることはできていません。トランザクションに使用される GAS を提供するプロジェクトでは、トランザクションのサイズ（バイト単位）を次のように概算できます。

$$
tx\_size = \frac{used\_gas}{avg\_gas\_limit} \times avg\_block\_size
$$

チェーンのサイズは以下のように表すことができます。

$$
chain\_size = 365 \times avg\_updated\_prefix\_per\_day \times tx\_size
$$

まとめ

今回は、ブロックチェーンを活用することによって既存の BGP を向上させるようなプロジェクトをまとめている論文を紹介しました。この論文で紹介されているプロジェクトの全てはここでは説明できませんでした。詳細が気になる方は、論文の Reference から各プロジェクトの詳細を探してみてください。