要約

  • draft-ietf-ippm-ioam-data-integrity-20 は、信頼されたValidatorがAES-GMACの累積計算を再現し、含まれた不変フィールドの改変を検出する方法を定める。
  • ICVが一致しても、期待したOption-Typeの欠落、侵害ノード自身の虚偽、輸出後の改変、遅延、非保護namespace、未採取トラフィックは否定できない。
  • 自動化の終端には、期待集合と観測集合、replay判定、Validatorの来歴、輸出の保管連鎖、母数、独立したサービス観測を含む受領証が必要だ。

最後の式は単純だ。Validatorが再計算したICVと、パケットが運んできたICVを比べる。一致すれば、指定された鍵・識別子・replay状態の下で、対象フィールドに改変を検出しなかったと言える。

ところが運用画面は、その限定文を「経路は信頼できる」に短縮しがちだ。短縮された部分にこそ、事故の余地がある。

2026年7月19日付のrevision 20は、IPPMワーキンググループのInternet-Draftであり、RFC Editor queueで最初の編集を待っている。IANA欄にはVersion Changed - Review Neededとある。標準化工程が進んでいても、実装、相互運用、鍵運用、カバレッジの実績を意味しない。

方式はPre-allocated Trace、Incremental Trace、Proof of Transit、E2Eに完全性保護版を用意する。チェーンを更新する各ノードは固有の対称鍵を持つ。12 octetのnonceにはKey ID、Encapsulating Node ID、64 bit counterが入る。封入ノードが最初のICVを作り、参加するtransit nodeは受け取ったICVと自分が追加する不変データから次のICVを作る。

運ばれるのは最新のICVだけだ。Validatorは受信記録に現れたノードを識別し、鍵を引き、同じ順序で計算を再現する。node_idと鍵の対応方法は範囲外である。したがって判定は、暗号の外側にあるローカルな身份台帳に依存する。

正しい鍵で書かれた虚偽

侵害されたノードは、別ノードへのなりすましや他者の保護済み寄与の改変を検出なしに行うことは難しい。一方、自分の鍵で自分の計測値を偽ることはできる。パケットを捨てることもできる。

偽のqueue depthを正規の鍵保有者がチェーンに入れれば、ICVは正しくなり得る。完全性は「誰が述べ、その後変わっていないか」を扱う。センサーの校正やソフトウェアの誠実さを証明しない。

受領証では、寄与の帰属が確認できたと計測が信頼できるを分離する。後者にはbuild、設定、attestation、別counter、別観測面との整合が必要だ。

Validator自身が最大の統制点になる

草案はValidatorをtrusted entityと呼ぶ。Validatorは鍵素材を持ち、ICVの最終判定を下す。同時に、侵害されたValidatorはIOAMデータを偽造・変更し、誤った結果を出せる。この方式ではその振る舞いを防げない。

これはアルゴリズムの欠陥ではなく、権限の境界である。期待参加者の定義、鍵map、判定、修復命令を一製品が握れば、観測・裁定・実行が同じ主体に集中する。GMACを使うだけで独立検証にはならない。

判定にはValidatorのdeployment identity、software build、config hash、key epoch、ID-key map version、policy versionを添える。重大な自動処置には、別の観測面か別権限の承認を要求する。

消された封筒は検証できない

on-path attackerはIOAM Option-Type header全体を削除できる。草案は、この攻撃を方式自身が緩和しないと明記する。保護Optionを通常Optionへ置き換えるdowngradeも、Validatorが本来のprotected namespaceとOption-Typeを知って初めて検出可能になる。

ゆえにICV検証より先に、期待集合を確定しなければならない。どのNamespace-ID、encapsulating node、Option-Type、参加ノードが必要か。期待と観測を照合し、その後にチェーンを検証する。

Optionが無い状態を「異常なし」にしてはいけない。未挿入、未sampling、strip、非参加、export失敗は異なる状態であり、判断も異なる。

有効サンプルは母集団ではない

保護Optionと非保護Optionは同じdomainで共存できる。namespaceごとに保護の有無も違い得る。処理負荷を抑えるため、対象trafficを一部に限定することもできる。

有効件数はcoverageを示さない。重要flowが一度も選ばれていなくても、選ばれた千件はすべてvalidになり得る。流量class、namespace、Option-Type、時間窓、policy generationごとに分母を保存する必要がある。

mutable header fieldも保護外だ。結果には対象fieldとmaskを明示し、「IOAM全体が完全」という表現を避ける。

Exportから別の証拠連鎖が始まる

management planeとexported dataの完全性は範囲外であり、それぞれ別のprotocolやformatに委ねられる。IOAM-Data-Fieldsを運ばないDirect Exportはこの方式を使ってはならない。

パケット内でICVがvalidでも、decapsulation、変換、転送、保存、集計でデータが変わる可能性がある。原始Option、validation receipt、各変換のhashと実行主体を残すべきだ。連鎖が切れたらexport integrity unprovenである。

validでも遅すぎることがある

選択的delay攻撃も方式の対象外だ。IOAM付きパケットだけを遅らせ、混雑のように見せても、bytesが変わらなければICVは有効だ。

freshnessにはcapture時刻、validation時刻、許容age、clock quality、独立したdelay/loss観測が要る。nonceの再利用を防ぐreplay保護と、意思決定に間に合うことは別である。

再起動でcounter状態を保存できなければ旧鍵を再利用してはならず、再開前にrotationが必要だ。replay windowは正当なreorderingの許容幅を決める。これらはvalidという一語に隠してよい実装詳細ではない。

判定を証拠の一項目に戻す

受領証はDomain、Namespace-ID、Option-Type、method、mask、packet/sample ID、selection rule、期待・観測したOptionとparticipantを記す。さらにnonce、公開識別子、key epoch、map version、replay disposition、Validatorのbuildとconfigを記す。

decapsulationからexport、storageまでをhashで結び、最後にdelay、loss、path corroboration、service metric、実行したaction、authority、rollback、outcomeを付ける。

状態はdeclared set内でvalid、expected option missing、identity mapping unknown、validator provenance unverified、coverage partial、export integrity unproven、service outcome pendingのように型を持たせる。