要約

  • RFC 2402のAHは準備済みビューにICVを計算した。不変フィールドはそのまま、予測可能な可変フィールドは到着時の値に並べ、予測不能な可変内容は計算時にゼロへ置き換えた。
  • ICV一致は通信路上の全ビットが不変だった証明ではない。断片化は送信AH後、再構成は受信AH前であり、リプレイ検査はSAごとに無効化でき、ポリシーやアプリケーションの判断も後段に残った。

IPv4のTTLは、変化しなければネットワークが困り、変化すれば単純なバイト比較が困るフィールドである。RFC 2402は、この矛盾を「変化しなかった」と扱わなかった。実パケットのTTLは経路で減る一方、ICV計算用の位置にはゼロを置いた。

1998年11月のIP Authentication Headerは、コネクションレス完全性とデータ起源認証を提供し、受信側がSAごとに選ぶリプレイ防止を支えた。機密性は提供しない。上位層データと可能な限りのIPヘッダーを対象にしたが、文書自身がヘッダー保護を部分的と呼んだ。途中で変わる値は、そのままでは保護できないからだ。

AHにはNext Header、長さ、予約、SPI、Sequence Number、Authentication Dataがある。SPI、宛先、AHプロトコルで一方向SAを選び、そのSAからアルゴリズムと鍵を得る。Sequence Numberは常に送られ、受信側がリプレイ検査を使わない場合でも送信側は増分した。

ICV入力は三分類された。不変フィールドと上位層データは実値のまま入る。可変でも到着値を予測できるフィールドは、その最終状態に並べる。予測不能な可変内容はゼロで埋める。Authentication Data自身も、結果を格納する前の計算ではゼロでなければならない。

ゼロ化は削除ではない。オクテットを位置に残すことで整列を保ち、内容を保護しなくてもフィールド長は認証構造に残る。準備済みビューはパケットと同じ骨格を持つが、全位置の値は同じではない。「正規化」は説明用の後代語であり、RFCは不変、可変だが予測可能、可変という分類を用いた。

IPv4では、Version、IHL、Total Length、Identification、AHを示すProtocol、Source Address、通常のDestination Addressが含まれた。ソースルーティング時の宛先は可変だが予測可能だった。TOS、Flags、Fragment Offset、TTL、Header Checksumはゼロ化された。実際のルーターがTOSを変え、DFを設定し得て、TTLを減らし、その結果チェックサムも変えることが理由だった。

したがって、有効なICVと低下したTTLは両立する。ICVが示すのは、同じSA、鍵、準備規則の下で得た入力が一致したことであり、通信路上の像が静止していたことではない。対象外フィールドはパケットから消えず、AHの主張範囲から外れる。

IPv6でも同じ考え方が使われた。1998年モデルのClass、Flow Label、Hop Limitはゼロ化され、Routing Headerの影響を受ける宛先は予測可能とされた。Hop-by-HopとDestination Optionには途中変更可能性を示すビットがあり、可変Option Dataはゼロとして扱う一方、Option Typeと長さはICVに残った。新しいオプションは自らの可変性処理を定義する責任を負った。

パディングも計算像と送信像を分ける。Authentication Data内の明示パディングは送信され、ICVに含まれる。アルゴリズムがブロック境界を要求する場合、暗黙のゼロパディングも計算に加わるが、通信路には出ない。認証入力には、置換値だけでなく未送信オクテットも存在し得た。

断片化は検証単位を決めた。トランスポートモードAHは完全なIPデータグラムに適用され、その後で断片化する。ルーターが分割しても、受信側はAHの前に再構成する。まだ断片に見えるものがAHへ渡れば破棄し監査する。トンネルモードでは、外側AHが、すでに断片化された内側IPパケットをペイロードとして保護する場合があり、層を区別する必要がある。

受信側は同じビューを再構築する。SAを選び、受信ICVを保存し、Authentication Dataと予測不能フィールドをゼロ化し、必要な暗黙パディングを足し、再計算して比較する。リプレイ防止を有効にした場合、候補番号を先に選別できるが、ウィンドウ更新はICV成功後である。無効なら番号の存在はリプレイ判断を証明しない。

RFC 2402は、このAH段階で一致したデータグラムを有効とした。それでもRFC 2401の全体設計では転送や配送前の受信ポリシー確認が残り、アプリケーション判断はさらに後にある。SA、送信ビュー、ICV、断片、再構成、受信ビュー、比較、任意のリプレイ、ポリシー、アプリ結果を別々に保存すべきである。

これは歴史仕様である。RFC 1826を置き換え、後にRFC 4302とRFC 4305に置き換えられた。当時のHMAC-MD5／HMAC-SHA-1要件は現在の推奨ではない。RFC 4302は部分的ヘッダー保護を保ちながら、SA検索、拡張シーケンス番号、アルゴリズム管理を改めた。

Lu Hengの稼働コードと現実層に関する後世の議論を分析枠にすれば、認証ラベルの効力は実際に構築・比較されたビューに宿る。これはRFCの用語ではないが、除外フィールド、任意検査、未成立の下流結果を「認証済み」の一語に吸収させない。

出典