要約

  • NDNでは利用者が名前でデータを要求し、一致するDataパケットを持つキャッシュや別のノードが応答できるため、毎回元のサーバーへ戻る必要がない。
  • 署名は完全性と来歴を支えるが、その署名者が当該名を扱う権限を持つか、保存された版が十分に新しいかは別の判定である。
  • この分離は配信の自由を広げる一方、名前の設計、信頼スキーマ、鍵配布、キャッシュ方針を制度的な制御点にする。

ひとつの応答に隠れていた四つの問い

受講者が、名前の付いた講義映像の一断片を求める場面を考えよう。最も近いコピーは、すでにルーターのContent Storeにあるかもしれない。元のサーバーが再び応答する必要はなく、利用者がその保存場所のアドレスを知る必要もない。Interestの名前と一致するDataを持つノードが、要求によって作られた経路を逆向きに返せばよい。

アドレスを中心に考えると、これは重要な保証を失うように見える。期待したホストとの新しい接続を通っていないデータを、なぜ信用できるのか。Named Data Networking（NDN）は、別の万能印を置くのではなく、一つの事実に四つの仕事をさせないことで答える。

名前は何を求めたかを示す。転送と保存は一致するコピーをどこで見つけるかを決める。署名は返された名前と内容を鍵に結びつける。そしてアプリケーションの信頼モデルが、その鍵にこの名前について語る権限があるかを判断する。さらに、保存されたコピーを今使ってよいかは鮮度の規則が決める。

この切り分けこそ、Lixia ZhangのNDN研究の中心にある。彼女のUCLAでの略歴によれば、2010年から複数大学にまたがるプロジェクトの設計と開発を率いてきた。NDNはもちろん一人の発明ではない。論文の著者欄そのものが共同作業を示している。Zhangが保ち続けたのは、宛先アドレスを持つパケットを自然法則ではなく、再検討できる設計選択として扱う研究の場だった。

「どこ」から「何」へ

その前史は、2009年の「Networking Named Content」に明瞭に現れる。人がネットワークで求めるのは主にコンテンツなのに、ネットワークは機械同士の会話として動いている。アプリケーションは「何が欲しいか」を、まず「どのホストがどこにあるか」へ翻訳しなければならない。

Content-Centric Networkingは、名前を持つコンテンツを共通の基本単位に据えた。受信者は欲しいものをInterestで表す。転送ノードはローカルのData、同じ名前を待つ要求、そして候補となる供給元への経路の順に調べる。キャッシュに一致するDataがあれば、その場で応答できる。

この可動性から安全性の議論が生まれる。最も近いコピーを使えるようにするなら、信頼を「どのホストから、どんな接続で来たか」だけに結びつけられない。保護と来歴がコンテンツとともに移動しなければならない。

2014年の「Named Data Networking」は、この変更を新しい「細い腰」として描く。IPの共通サービスは、宛先アドレスへパケットを運ぶ。NDNが提案するサービスは、名前で識別されたデータを取得する。消費者がInterestに名前を入れ、ルーターが候補の生産者へ向けて転送し、適合するデータを持つ最初のノードが、名前・内容・生産者の署名を備えたDataパケットを返す。

この交換には送信元・宛先アドレスが要らない。ルーターは未解決のInterestを記憶し、その状態を使って応答を戻し、Dataを次の要求のために保存できる。元のサーバーが不要になった、という話ではない。誰かがデータを生産し、鍵を管理し、名前を到達可能にする必要は残る。消えたのは、信頼できる取得のたびに同じ機械との新しいエンドツーエンド接続を必須とする考え方である。

署名は判決ではない

「署名済み」は「信頼できる」と読み替えられやすい。しかし、有効な署名は内容の主張が真実だとは証明しない。署名者が制度上その名前を使う権限を持つとも、より新しい版が存在しないとも、元の生産者が今も稼働中だとも証明しない。

現在のNDN署名仕様は、その境界をはっきり書いている。SHA-256のダイジェストだけなら予期しない改変は検出できるが、来歴や原本の供給元は保証しない。公開鍵署名は、検証に成功すれば、主張された生産者が作成し途中で改変されていないことを強く裏づける。それでも、どの発行者がどのData名に署名してよいかは、アプリケーションの信頼モデルが定める。

だから2014年論文は、全Dataへの署名を安全性の完成形とは扱わず、使える信頼管理を研究課題とした。消費者には暗号計算の成功だけでなく、鍵の名前空間とデータの名前空間を結ぶ規則が要る。その後の信頼スキーマ研究は、どの鍵がどの名前に署名できるかをパターンとして表し、証明書の探索を助け、鍵を狭い範囲に限定する仕組みを示した。

認証はデータの近くへ移る。だが権限が暗号から自動的に生まれるわけではない。権限判断を明示的な方針として検査できるようになるのである。

「古い」と「無効」を分ける

キャッシュには別の誤読もある。古いデータは壊れたデータなのか。NDNはこの二つを分ける。Dataパケット仕様では、FreshnessPeriodが保存後いつ「non-fresh」と扱うかを示す。同時に、non-freshになってもData自体は有効であり、生産者が新しい版を出した可能性がある、という意味にすぎない。Interestパケット仕様のMustBeFreshを指定すれば、Content Storeはnon-freshなDataでその要求を満たしてはならない。

したがって検証は鎖になる。名前の一致は、要求した対象への応答かを問う。署名検証は、対象部分が完全で鍵と結びつくかを問う。信頼モデルは、その鍵がこの名前について許可されているかを問う。鮮度方針は、その保存版を今使えるかを問う。一つに合格しても、他の合格にはならない。

これは一個の緑色の鍵マークより誠実だが、アプリケーションには重い仕事を課す。予測可能な名前を作り、信頼アンカーを選び、証明書を取得・検証し、更新と失効を定め、映像断片、センサー値、ソフトウェア、制御命令ごとに許容できる古さを決めなければならない。

名前は自由であり、管轄でもある

NDNルーターは名前の構成要素の境界を認識するが、意味は解釈しない。2014年論文は名前をネットワークにとって不透明とし、アプリケーションが用途に合う命名法を選ぶ。版、分割番号、組織、作業文脈を名前に含めても、転送面がそれを理解する必要はない。

ただし命名は中立ではない。階層は、経路をどこまで集約できるか、利用者が次の名前を予測できるか、信頼規則が何に一致するか、どの組織が接頭辞を所有して見えるかを左右する。論文は名前空間の管理を基本アーキテクチャの外に置く。「外」は「重要でない」ではない。細い腰が決めないからこそ、組織と共同体が統治しなければならない領域である。

信頼スキーマも同じだ。規則を自動化できても、正当な規則を自動で選べない。信頼アンカー、証明書の名前空間、検証方針を管理する者は、ある署名者を受け入れ、別の署名者を排除できる。経路への依存を弱める分散性が、一つの変更不能な信頼根によって新たな集中へ変わる可能性もある。

置き換えの成否だけでは測れない

将来型アーキテクチャを、既存インターネットを置き換えたかだけで評価すると、NDN実験の価値を見失う。現在DNS、通信路の安全性、CDN、アプリケーション識別子、キャッシュ、更新規則に散らばる働きを一つの設計面へ置き、名前と署名を持つDataを共通単位にしたら何が変わるかを問い直したからだ。

答えは高速なキャッシュだけではない。元のサーバーは信頼を推定する唯一の場所ではなくなり、複数経路からの取得と安定したオブジェクト同一性が両立し、断続的な接続を保存済みパケットでつなげる。同時に、来歴、鮮度、権限が別々の問いとして表面に出る。

Zhangの仕事の歴史的な意味は、この問いを持続させたことにある。データをどこからでも得られるなら、何をデータ自身に付着させ、何を受信者の意識的な判断として残すべきか。NDNは信頼を消したのではない。信頼がどこに隠れていたかを可視化した。

参照資料