AHかESPか。パケットが守るべきものから決める

二つのIPsec提案が同じSHAベースの整合性アルゴリズムを挙げていても、要求する保護プロトコルは異なりうる。AHとESPは同じ認証設定の二つの綴りではない。まずプロトコルを読み、次にそのアルゴリズム、次にモードを読めば、曖昧さの大半は消える。AHは通過中に変わらないIPヘッダーのフィールドも含めてパケットを認証し、ESPはカプセル化した中身を認証・暗号化して外側のヘッダーには触れない。この違いが、どのハッシュ名よりも多くの導入を左右する。

AHが覆い、ESPが覆わないもの

AHは整合性、データ発信元の認証、および自ら定義する再送防止サービスを提供し、機密性は一切提供しない。その範囲には上位層のデータと、規則が不変とみなすIPヘッダーのフィールドが含まれる。これはESPがトランスポートモードで外に置く部分そのものである。IPヘッダー自体を認証すべきという要件があれば、それに応えるのはAHである。

この広さが、実運用でAHが脆い理由でもある。TTL、ヘッダーチェックサム、一部のオプションといった可変フィールドは、ルーターが書き換えうるため認証できない。そこでプロトコルは検査値の計算前にそれらをゼロにする。したがってアドレスを書き換えるものはポリシーだけでなく計算を壊す。

NATが選択を制約に変える

アドレス変換は、AHがたった今認証したIPヘッダーの送信元や宛先を書き換える。そのため整合性検査は遠端で失敗し、読めるメッセージではなくプロトコルエラーとして失敗する。ESPは外側のヘッダーを認証しないので、NAT越えのESPは機能し、NAT背後のAHは機能しない。両端が普通のルーターの背後にあるトンネルで、これが最初に現れる。したがって最初の問いはどちらが強いかではなく、両端の間に変換装置があるかどうかである。

あればAHは外れ、議論はESPとそのアルゴリズム選択に移る。これは好みではなく制約であり、だから判断の最後ではなく最初に置く。

モードが問いを倍にする

ESPはトランスポートモードで上位層のペイロードを守り、IPヘッダーには触れない。トンネルモードでは内側のIPヘッダーを含む内部パケット全体をカプセル化して守る。AHにも同じ二つのモードがあるので、AHかESPかは、アルゴリズムを選ぶ前の時点で実に四通りの組み合わせである。

複合モードのESPアルゴリズムは、二つ目のプロトコルなしで整合性を決める。AES-GCMとChaCha20-Poly1305は一つの構成で認証と暗号化を行うので、AHを上に足しても何も得られず、ヘッダーともう一回のネゴシエーションを費やすだけだ。アーキテクチャはAHとESPの併用を許すが、実務上の問いは、ゲートウェイとリリースがその組み合わせを支えるか、後で誰かが保守できるかである。

AHのみに対する正直な代替

整合性のみのESPはアルゴリズムを保ち、暗号化の主張を偽らずに手放し、しかもNATを越える。旧設計が機密性なしの認証のためにAHを使っていたなら、その種別が直接の翻訳であり、注記を付けた暗号化トンネルではない。

提案にESPがあることも暗号化の証拠ではない。暗号アルゴリズムを読むべきだ。NULLの項目は整合性のみ、複合モードの項目は両方を意味する。

三つの問いで決める

機密性が必要か、経路上に変換装置があるか、どのヘッダーフィールドを認証すべきかを問う。この三つの答えが一つのプロトコルと一つのモードを指し、書き留めるのは後でRFCを読み直すより短時間で済む。

次に、提案されたものではなく受け入れられたものを検証する。ip xfrm state は導入済みの関連のプロトコル、モード、アルゴリズムを示し、不一致なら何も導入されない。これは意図した保護なしに上がるトンネルより清潔な失敗である。

認証の失敗、セレクターの範囲、ルーティングの障害はこの選択と分けて考える。症状はそれぞれ異なり、セレクターの問題をプロトコルのせいにすると、理由もなくハッシュを替えて一日を費やす確実な方法になる。