要約

  • RFC 9507 は CCNx と NDN 向けの traceroute である。Interest は一意な宛先アドレスではなく名前で進み、Data は Pending Interest Table に残されたホップ単位の状態を逆にたどる。
  • nonce は診断要求の集約を避け、四つの応答コードはホップ、管理名、ローカルアプリ、キャッシュのどれが応答理由かを示す。Path Label は後続要求を観測済みの枝へ誘導できる。
  • 得られるのは条件付きの経路証拠である。同じ名前の別経路、別の生成元やキャッシュ、通常の配信、アプリケーション結果まで証明するものではない。

最も速い応答が、最も遠い生成元から来るとは限らない。ある運用者が名前を指定してトレースすると、三つ目のフォワーダーでセッションが終わった。そこに目的のオブジェクトがキャッシュされていたからだ。画面上では短い経路が成功している。

しかし、運用者が調べたかったのは生成アプリケーションへの到達性だった。利用者への応答は良好でありながら、生成元の障害は残りうる。一つの緑色の線が、二つの異なる問いを同じ答えにしてしまった。

RFC 9507 は、その混同を避けながら ICN を診断可能にする。2024年3月に IRTF ストリームの Experimental RFC として公開され、IETF の Standards Track ではない。CCNx と NDN に対し、要求、応答、フォワーダー処理、経路誘導、安全性を定める。観測する対象は「名前に向かう少なくとも一つの経路」であって、名前を単一ホストへ読み替えたものではない。

アドレスの発想を名前へ移植できない理由

IP の traceroute は TTL を一つずつ増やす。TTL が尽きたルーターは、送信元アドレスへ ICMP Time Exceeded を返す。フィルタリングや非対称性があっても、計測の基本座標は宛先アドレスである。

ICN の Interest には送信元アドレスがない。階層的な名前に基づいて転送され、返る Data は往路で各フォワーダーの PIT に作られた状態を使う。名前は一つの端点を示さない。アプリケーション、複数の生成元、中間の Content Store が同じ名前を満たしうる。連続した Interest が違う枝を選び、違う場所のコピーへ到達することも通常の動作である。

同名 Interest の集約も計測を変える。複数要求が一つの PIT エントリーを共有すれば、後から来た要求は先行要求の途中状態に合流する。配信効率としては望ましくても、独立した往復時間の実験にはならない。負荷が一定でも、PIT の寿命によって見える RTT が短くなる場合がある。

RFC 9507 はターゲット名へ nonce を付ける。CCNx では 64 ビットの型付き名前セグメント、NDN ではターゲット、nonce、traceroute 接尾辞を組み合わせる。これにより各プローブは PIT に対して固有になり、返信も要求と対応付けられる。一方、Content Store の照合時には nonce を無視し、本来の対象オブジェクトを探す。

診断の識別子とコンテンツの識別子はここで分かれる。nonce は一回の実験を区別するが、生成元を識別する証明ではない。

四つの終了理由を一つの成功へ潰さない

セッションは HopLimit 1 から始まり、値を増やしていく。フォワーダーは値を確認して減算し、まだ正なら Content Store 検索、PIT 作成、最長名前接頭辞一致、与えられた経路誘導を処理する。次ホップがなければ、CCNx は No Route、NDN はネットワーク NACK を返す。

HopLimit がゼロになったフォワーダーは管理名を含む応答を返す。応答コード 4 は、指定距離のフォワーダーへ達したという意味である。コンテンツやアプリケーションへの到達を意味しない。

残る三つは意味上の最終応答である。コード 1 は対象名がフォワーダーの管理名に一致した場合、コード 2 は FIB の最長一致がローカルアプリケーションの face を指す場合、コード 3 は Content Store 内のオブジェクト名と完全一致した場合である。クライアントはキャッシュヒットによる終了を拒否する設定もできる。

これらを単一の reachable に変換すると、プロトコルが届けた重要な情報が消える。キャッシュヒットは利用者の応答性を示しうるが、生成元の健全性は示さない。ローカル face への引き渡しはアプリ処理の完了ではない。管理名への到達は管理面の所在を示すだけで、データ所有を示さない。コード 4 は純粋にホップ境界である。

Path Label は観測の連続性を作る

マルチパスでは、HopLimit 2 の要求と HopLimit 3 の要求が別の枝を通りうる。そのまま並べれば、実際には一度も同じ経路に存在しなかったフォワーダー列が完成してしまう。

RFC 9507 は RFC 9531 の Path Steering を使う。応答生成元は空の Path Label を用意し、復路の各フォワーダーが自らの次ホップ選択を反映して更新する。クライアントは返された値を次の要求へ入れ、同じ枝へ誘導できる。別経路を探すなら、新しいセッションでラベルを省略する。

これは比較可能性を高める仕組みであり、経路の恒久証明ではない。ラベルはその時点の FIB、キャッシュ、戦略、トポロジーの判断を凝縮する。再利用は同じ枝を再現できるか試すだけであり、ラベルを外しても全ての代替路が列挙される保証はない。

記録すべき主張は「この時刻、この nonce とラベルのセッションが、この列と終了コードを観測した」である。「コンテンツの経路はこの一つだ」とするには証拠が足りない。

署名の範囲が信頼の範囲になる

応答には送信者の管理名が入り、クライアントは後から管理情報を問い合わせられる。偽の応答者が被害者名を入れれば、以後の管理トラフィックを被害者へ向ける反射攻撃になりうる。CCNx では応答生成者が含めた名前へ署名し、クライアントは公開鍵を取得して検証しなければならない。

名前署名は単純な被害者名の差し替えを防ぐ。ただし、経路上の侵害フォワーダーが以前の名前と署名を自分の有効な組へ置き換える攻撃までは防げない。応答全体への署名なら改変範囲を広く守れるが、全返信の暗号計算は計算量攻撃の標的にもなる。RFC は traceroute 処理を別のローカル管理アプリケーションへ分離することを勧める。

監査では、署名対象、信頼した鍵、鍵取得経路、検証結果、メッセージ全体の保護有無を残す必要がある。「署名済み」という一語では判断できない。

ローカル名の背後には境界処理がある

ローカルスコープの名前は、クライアント側から直接ルーティングできないことがある。一案は、ルーティング可能な接頭辞を含む署名付き NDN Link Object を Interest に付け、名前自体が使える地域まで運ぶ方法である。クライアントが Link Object をどう得るかは仕様の範囲外である。

もう一案は、ローカル名の前へルーティング可能な接頭辞を追加する。境界フォワーダーは地域へ入るとそれを外し、返信では外部へ戻すための文脈を復元する。この処理は追加状態を必要とし、Interest flooding の負担を増幅しうる。

最終的なローカル名だけを保存したトレースは、到達を可能にした橋を消してしまう。Link Object と署名、追加接頭辞、書き換え境界、地域遷移はホップ列と同じ証拠である。

RFC 9507 の意義は、名前転送を単純化して見せることではない。要求を固有にし、応答理由とフォワーダー名を示し、一つの枝を再現可能にする。コンテンツの出所、経路の網羅性、アプリケーションの完了、利用者の結果は、別の証拠が届くまで別の層に残る。

出典