要約

  • IPComp は各データグラムを独立かつ可逆に処理する。損失や並べ替えが起きる IP では、前のパケットの辞書に依存できず、受信側は圧縮形と非圧縮形の両方を扱う。
  • 圧縮ペイロードに四オクテットの IPComp ヘッダーを加えても元より小さくならない場合、送信側は元の形を送り、IPComp ヘッダーを付けてはならない。
  • CPI は解凍側が選ぶ方向別・宛先文脈別の索引であり、資格情報でも世界共通のアルゴリズム識別子でもない。合意と個別実行は別の証拠である。

「使わない」が成功条件になるプロトコル

機能を合意した後に、その機能を使わないパケットが続けば、運用者は不具合を疑う。IPComp では、その観察だけで異常とは言えない。Association は圧縮形が届いた時の解釈を共有するが、あらゆるペイロードに変換を強制しない。

反復の多いデータは縮む。短い制御パケットは固定費で膨らむ。上位層で既に圧縮された内容は、CPU を使っても変わらないことがある。将来の入力を合意時点で決め打ちできないため、規格は「能力の成立」と「今回の実行」を切り離した。

外側の Protocol または Next Header が 108 なら、その位置で IPComp 形を宣言している。108 がなければ、そのパケットが元の形を選んだことまでは分かる。しかし、Association がない、交渉が失敗した、方針違反が起きた、のいずれも証明しない。

暗号化が構造を消す前に畳む

1998年の RFC 2393 は IPComp を IPsec と並べて説明した。暗号化後のデータはランダムに近く見えるため、下位層の圧縮は重複を見つけにくい。両方を行うなら圧縮が先でなければならない。

送信処理は圧縮、IP セキュリティ、フラグメント化の順になる。受信側では再構成と認証・復号が済んでから解凍する。圧縮が安全性を提供するのではない。安全処理より前の構造を扱い、受信時には安全境界を通過した後で元に戻す。

IPv4 の外側ヘッダーとオプションは圧縮しない。トンネルモードの内側 IP ヘッダーは外側のペイロードなので対象になり得る。IPv6 では経路上のノードが読むヘッダーを残し、Fragment Header と IPComp が共存すれば前者が先になる。

各データグラムは独立して復元可能である。直前のパケットが失われても次を読める。これはストリーム圧縮の効率より、IP の損失・順序変更という稼働条件を優先した設計だった。

四オクテットを含めて赤字なら送らない

RFC 3173 の非拡張ポリシーは、圧縮結果だけを比べない。圧縮ペイロードに IPComp ヘッダー四オクテットを足し、それでも元のペイロードより小さい場合だけ圧縮形を送る。同じか大きければ元の形を送り、ヘッダーは存在しない。

この規則は無駄な解凍を避けるだけではない。元は MTU 内だったパケットを、最適化の固定費で大きくしてフラグメント化する逆効果も防ぐ。

実装は比較前にも判断できる。小さいパケットを閾値で除外し、連続失敗後は数個を試さず、後で再試行できる。アルゴリズム固有の判定で処理を途中停止することもできる。回数、期間、閾値はローカルであり、ワイヤ形式には現れない。

DEFLATE を定める RFC 2394 は、非公式試験を根拠に 90 バイト未満を試さないよう勧告する。90 は IPComp 全体の不変条件ではない。別のアルゴリズム、CPU、回線、トラフィックにそのまま移せない。

したがって非圧縮形の理由をパケットだけから断定できない。小さすぎた、適応カウンターが休止中だった、圧縮不能と早期判断した、最後まで試して固定費を回収できなかった、という複数の枝が同じ外観になる。

CPI は相手が用意した引き出し番号

圧縮形の四オクテットは、元の Next Header、予約 Flags、16ビット CPI を運ぶ。解凍が成功すれば IPComp を外し、元の Next Header を復元して、再構成したペイロードを通常の処理へ戻す。

CPI の 0〜63 は既知の変換、別の範囲は交渉値と私用値に割り当てられる。しかし CPI 単独が世界共通の名前になるわけではない。各ノードは受信方向の値を独立に選び、送信側は解凍側が選んだ CPI を使う。宛先アドレスとの組み合わせで初めて必要な特性が決まる。

同じ既知 CPI を同一ノード間の複数セッションで再利用すると、寿命や適応カウンターの異なる Association を区別できない場合がある。RFC 3173 が必要に応じて交渉範囲を勧めるのはそのためだ。番号はローカル状態を引く索引であって、出所の証明ではない。

デフォルトを作らない相互運用

IPCA は CPI、モード、アルゴリズム、パラメータを含む。ノード間の全パケットに適用しても、選んだセッションだけでもよい。方向は別々に合意し、異なるアルゴリズムを使える。

既定アルゴリズムはなく、全実装に必須の圧縮方式もない。IPComp という名前から DEFLATE を推測してはならない。共通部分は明示的に選ぶ。

2001年の RFC 3173 は主として IKE 交渉を明確化した。IKEv2 では複数候補を提示できるが、応答が受け入れるのは一つまでで、提示・受理されていない方式を使えない。仮想圧縮 Association は対応する ESP/AH Child SA の外に独自の寿命を持たず、SA と共に消える。

それでも圧縮交渉と暗号パラメータ交渉は別である。同じ寿命を持つことは同じ権限を意味しない。CPI は鍵でも認証結果でもない。

小さくすると中間者の視界も変わる

IPsec なしの IPComp は、境界装置が使うフィールドの位置を変える。元の Protocol は IPComp 内に移り、ポートなどのトランスポートヘッダーは圧縮される。Association を共有しない装置は、以前の位置から単純に読めない。

圧縮は機密性ではない。問題は、ポリシーを実行する中間者に復元コンテキストがないことだ。全パケットのフィルタリングや会計が必要なら、RFC 3173 は Association を安全に伝える仕組みを求める。

運用証拠は、設定、交渉、試行、圧縮形の採用、CPI 参照、復元成功を分けるべきだ。「圧縮有効」はどれも単独では証明しない。

IPComp の歴史的な節度は、標準化された能力を実行命令にしなかった点にある。共通仕様は圧縮形を理解する最小条件を作った。今回使う価値があるかは、稼働するパケットに残した。

出典