要約

  • RFC 9508 の Echo Reply は、フォワーダ管理名の完全一致、ローカルアプリケーションへの最長名前プレフィクス一致、Content Store 内オブジェクトの完全一致という三条件を区別する。
  • 64ビット nonce は PIT 集約を避けて要求と応答を一対一にする。応答の鮮度制御は過去の診断応答を排除するが、対象オブジェクトの版や鮮度までは保証しない。
  • 応答者名の署名は特定のすり替えを防げる。名前への権限、オブジェクトの出所、通常 Interest の配信、利用者結果は別の証拠である。

一つの名前に三つの終了点がある

IP の ping はアドレスと端点の組を想像させる。ICN の Interest は階層名で転送される。名前は一台の装置を指すとは限らず、プロデューサに向かう途中のストレージでも、ノードに接続されたアプリケーションでも満たされる。

RFC 9508 は、どの条件で転送を止めたかを Echo Reply Code に残す。T_ECHO_RETURN_FORWARDER は基底名がフォワーダの管理名に完全一致したことを表す。T_ECHO_RETURN_APPLICATION は最長名前プレフィクス検索がローカルアプリケーション向け face を得たことを表す。T_ECHO_RETURN_OBJECT は同名オブジェクトが当該フォワーダの Content Store に存在したことを表す。

管理名の一致は、その転送要素が自身について返答した証拠である。アプリケーション応答は、その時点でローカル face への関連があった証拠である。オブジェクト応答は、そのノードがコピーを持っていた証拠である。いずれも単独では、元のプロデューサが稼働中であること、通常要求が処理されること、コピーが望ましい最新版であること、読者が取得に成功することを示さない。

ダッシュボードが保存すべき最初の値は単なる成功フラグではなく応答コードである。コードを失えば、キャッシュ観測がオリジン監視に、ローカル face がアプリケーション実行に、管理名一致がコンテンツ可用性に置き換わってしまう。

nonce は測定を分離するが、権限は作らない

同名の Interest は Pending Interest Table の一項目に集約され得る。ネットワーク効率には有効だが、測定では後の要求が先の状態を共有し、RTT や経路の意味が変わる。RFC 9508 は診断名に64ビット nonce を付け、要求ごとの区別と応答照合を実現する。

一方、Content Store 検索では nonce と ping 接尾辞を除いた基底名を用いる。診断トランザクションは固有でなければならないが、調べるオブジェクト名は元のままである。このため object reply が示すのは、固有の一要求が一ノードで基底名のコピーに一致した事実である。

そのコピーのプロデューサ、署名、版、鮮度、信頼規則は別にある。フォワーダが署名した「hit の報告」は、フォワーダがオブジェクトを制作したことを意味しない。基底名、nonce、応答コード、応答者名に加え、取得オブジェクトの識別子と署名検証を残す必要がある。

非集約には PIT 状態の増加という負担もある。高頻度プローブは診断対象の資源圧迫を自ら作り得る。送信率、要求寿命、同時実行数、タイムアウト、PIT 使用量は RTT と同じ監査対象である。

新しい診断応答が古い内容を報告することはある

CCNx の Echo Reply は ExpiryTime がゼロである。NDN は要求に MustBeFresh、応答に FreshnessPeriod 一を使い、診断 Data をほぼ直ちに stale とする。古い Echo Reply が現在の観測として再利用されるのを避ける仕組みだ。

ただし、この鮮度は「hit を報告した応答」の鮮度であり、hit した Content Object の業務上の新しさではない。今生成された正しい報告でも、コピーの版が置換済み、プロデューサ鍵が更新済み、アプリが受理しない状態はあり得る。

オリジン障害中にキャッシュが読者を支えるなら、継続性という目的には成功である。しかしオリジン健全性テストとしては別種類の応答である。運用ポリシーは object reply、application reply、後続のオリジン専用確認をどの主張に使えるか事前に定めなければならない。

無応答もオリジン停止の直接証明ではない。No Route、要求または応答の損失、ポリシー破棄、署名失敗、ローカル名マッピング失敗、期限切れを区別する必要がある。

署名は発言者を認証し、全代理権は与えない

CCNx 応答は送信者名とその署名を含む。NDN の Data はプロデューサ署名を持つ。RFC 9508 の参考クライアント動作は、フォワーダ公開鍵を取得し、受信メッセージと含まれる名前を検証する。

狙いは明確である。侵害されたフォワーダが被害者の名前を応答に入れ、後続の管理トラフィックを被害者へ誘導する反射を防ぐ。署名は、検証者が正しい信頼規則を使う限り、名前と応答鍵を結び付ける。

それでも、その鍵を管理名へ認可した主体、信頼スキーマの現行性、アプリケーションのプレフィクス権限、キャッシュオブジェクトの署名者、鍵の失効やローテーションは別である。暗号検証の成功は署名文についての証拠であり、コンテンツ全体の委任状ではない。

証跡には応答者名、鍵識別子または指紋、信頼アンカーまたは規則、検証時刻、署名結果、応答コードを残す。「署名済み」だけを保存すると、正当なキャッシュ報告が正当なオリジン報告へ拡張される。

診断経路と通常配信は同じではない

Echo Reply は PIT の逆向き状態で戻る。RFC 9531 の Path Label は各 hop で更新され、後続 ping を似た枝へ誘導できる。省略すれば別枝を探索できる。これは再現性と探索の道具であって、全経路の証明ではない。

RFC 9507 は HopLimit を段階的に変える traceroute と経路多様性を扱う。本稿の対象は、RFC 9508 において一回の ping をどの種類の応答者が止めたかである。ローカルな終了理由をエンドツーエンド経路に拡張してはならない。

通常 Interest は ping 接尾辞や nonce を持たず、集約され、別のアプリケーションパラメータや転送戦略を用いる可能性がある。サービス主張が内容配信なら、ping の後に通常取得 canary を実行し、オブジェクト名またはダイジェスト、プロデューサ署名、版、アプリケーション受理、読者表示を確認する。

ローカル名にはマッピングの管理責任が加わる

名前がある領域内だけで routable な場合、RFC 9508 は署名 Link Object で外部プレフィクスを示す方式と、routable prefix を前置して境界で削除する方式を説明する。返信時には外側で必要なプレフィクスを復元する。

Link Object の取得方法は範囲外である。書換え方式は、境界が隣接領域名を知り、残ったローカル名が内部で routable だと判断できることを前提にする。複数領域・複数プレフィクスでは返信状態も増える。

マッピング物または規則、署名者、有効期間、書換え境界、変換前後の名前、返信復元を記録する。一回の成功は一鎖の実行を示すだけで、全領域の正しさを証明しない。

情報源