要約

  • RFC 2908はマルチキャストアドレスの割り当てを、クライアントとサーバー、ドメイン内の調整、ドメイン間の割り当てという三層に分けた。実験仕様のRFC 2909はMASCを使い、各ドメインが一時的なアドレスプレフィックスを主張し、細分化したり下位ドメインへ委譲したりする仕組みを記した。
  • RFC 2909によれば、IPsecで二つのピアを保護しても、中継されたUPDATEの発信元までは認証できない。トポロジーの別の場所にいる信頼できないMASCノードが悪意ある更新を注入し得る。仕様が示した境界はピア選択における管理上の信頼であり、MASCの導入、攻撃、通信を証明するものではない。

2000年9月、マルチキャストアドレス割り当てには、混同しやすい二つの問いがあった。アプリケーションにグループアドレスを渡すのは誰か。そして、そのアドレスを選ぶ元となる範囲を確保するのは誰か。RFC 2908はこれを一つの処理にはしなかった。クライアントは割り当てサーバーにアドレスを求め、各ドメイン内ではサーバー同士が調整し、さらにドメイン間の仕組みが各ドメインへ範囲を渡す。第一層にはMADCAP、第二層にはAAPや手動設定、第三層にはMASCなどを使える構成だった。

この分割により、マルチキャスト割り当ては全世界で一つのカウンターを進める方式ではなくなった。通常は境界ルーターで動かす想定のMASCノードが、しばしば自律システムに相当するドメインを代表する。ノードは大きな範囲からプレフィックスを選び、設定済みのピアに主張を送り、競合がないか待つ。親子関係を使えば、取得した範囲を自ドメインの割り当てサーバー用に分けたり、子ドメインへさらに委譲したりできる。取得した範囲をマルチキャスト経路情報へ挿入し、別のルーティングプロトコルが使う場合もある。これらは関連する制御面だが、同じものではない。MASCの割り当てだけで経路、受信者のグループ参加、パケット配送が成立するわけではない。

主張には期限がある。プレフィックスには有効期間が設定され、使い続けるには期限前に更新しなければならない。更新できなければ、そのドメインは利用を止め、対応する経路状態を削除するよう仕様は求めている。委譲された範囲は、最初から永久のものではなかった。しかし割り当て、経路、アプリケーション利用のどれか一つしか見なければ、三者の状態は食い違い得る。制御面の記録はパケットキャプチャではない。

アドレスが不足する状況での設計上の妥協も明記されていた。厳格に範囲を分割すれば衝突を保証付きで防げるが、ネットワーク分断やフェイルオーバーに備える余白がアドレスプールを細切れにする。RFC 2908はその場合、衝突ゼロの保証より、空間の有効利用と継続的な可用性を重視した。衝突しない確率を非常に高くする一方、確率をゼロにはしない。MASCの主張、衝突比較、待機時間、競合時に別のプレフィックスを選ぶ処理は、この確率的な方針を実装するものであり、数学的な確実性ではない。

RFC 2909は、もう一つ別の境界、つまり更新の出所を取り上げる。UPDATEは最初に受信したピアで止まるとは限らない。MASCノードは更新を保存し、親、同階層、子、内部ピアへ転送する。RFC 2909は二つのピアノード間の安全確保にIPsecを使えるとしている。しかし、トポロジー内に信頼できないMASCノードが一つでも加わると、他のノードが悪意あると見抜けないUPDATEを注入される可能性がある。そのため仕様は、各ノードが信頼できるノードとのみピア関係を結ぶことを勧めた。再起動後の状態復元では、親または内部ピアから届いた情報は通常信頼できるものと扱う一方、兄弟や子を経由した自ドメインのUPDATEは破棄してもよいとしている。

これは「IPsecは役に立たない」という話ではない。リンク保護が守るのは特定の接続である。メッセージが次の区間へ転送された後は、隣のピアから受け取ったことは分かっても、誰が最初に作ったのか、各中継点が再送する権限を持っていたのかを独立に確認できるとは限らない。MASCのタイムスタンプや発信ノード識別子は競合する主張の比較に使われるが、RFC 2909はそれらを暗号学的な発信元認証とはしていない。また、実際の攻撃事例を記録しているわけでもない。脅威を示し、ピア構成という運用判断を管理者に委ねた文書である。

プレフィックスの主張が複数の割り当てサーバーに影響し得るため、この区別は重要だ。受理されて伝播した更新は、周囲の別の主張を制約し、アプリケーションがアドレスを求める前に経路状態へ入る可能性がある。RFC 2909が示す対策は、個々の主張を認証する世界的な中央機関ではない。信頼できるノードにピアを限り、転送されたUPDATEの経路を考慮するルールを設けることだった。つまり実質的な制御は、トポロジー設計と信頼関係の管理に置かれる。

RFCの位置づけも歴史的な結論を限定する。RFC 2908は情報提供文書で提案アーキテクチャを記し、RFC 2909はインターネット標準ではなく実験プロトコルとして公開された。ここから分かるのは、設計者が階層的な割り当てモデルとその危険を文章にしたことまでだ。何ネットワークがMASCを実装したか、広く運用されたか、悪意ある更新がサービスを妨げたかは分からない。RFC 3180の静的GLOP方式もRFC 3171のIANA登録も異なる選択であり、MASCの導入を証明しない。得られる教訓はより限定的だ。プレフィックスの主張、保護されたリンク、信頼できる発信元、経路、受信されたマルチキャストはそれぞれ別の事実である。安全な制御面は、どの証拠が次の状態への移行を許すのかを明示しなければならない。

出典