IPsecのパケット構造
ESP と AH の各フィールドが、パケットのどこに置かれ、どの処理に使われるかを理解する。
IPsec でデータパケットを保護するプロトコルが ESP と AH である。IKE は ESP / AH が使う SA や鍵を準備する別のプロトコルであり、ESP / AH のパケット内には含まれない。
IPv4 ヘッダの Protocol、または IPv6 ヘッダの Next Header には、次に続くプロトコルが記録される。ESP は 50、AH は 51 である。NAT-T で ESP を UDP に入れた場合、外側の値は UDP を示す 17 になり、ESP は UDP ペイロード内に置かれる。
IPsecヘッダが入る位置
Section titled “IPsecヘッダが入る位置”
ESP transport mode
Section titled “ESP transport mode”transport mode では、元の IP ヘッダを残し、その後ろに ESP Header を挿入する。元の IP ペイロードである TCP / UDP ヘッダとデータは ESP の Payload Data に入り、ESP Trailer とともに暗号化される。
元の IP ヘッダは暗号化されない。IPv4 の Protocol または IPv6 の Next Header は、元の TCP や UDP ではなく ESP を示す 50 に変更される。
ESP tunnel mode
Section titled “ESP tunnel mode”tunnel mode では、元の IP パケット全体を ESP の Payload Data に入れ、外側に新しい IP ヘッダを付ける。内側 IP ヘッダ、TCP / UDP ヘッダ、データはまとめて保護される。
外側 IP ヘッダは IPsec ピア間の配送に使われる。外側ヘッダの宛先は IPsec ピアであり、内側ヘッダの宛先は保護対象となる元の通信相手である。
NAT-T では、ESP パケット全体を UDP ペイロードに入れる。外側 IP ヘッダの次には UDP ヘッダが続き、その後ろに通常の ESP Header、Payload Data、ESP Trailer、ICV が続く。UDP ヘッダは 8 バイトで、通常は UDP 4500 が使われる。送信元ポートは経路上の NAT によって別の値へ変換される場合がある。
UDP 4500 は ESP データと IKE の両方に使われる。UDP ヘッダ直後の 4 バイトが非ゼロなら、その値を ESP の SPI として処理する。4 バイトすべてがゼロなら Non-ESP Marker であり、その後ろを IKE メッセージとして処理する。ESP の SPI にはゼロを使用しないため、この区別が成立する。
NAT の変換状態を維持する NAT-Keepalive は、UDP ペイロードが 1 バイトの 0xFF だけで構成される。SPI や IKE Header は含まれない。
ESPパケットの形式
Section titled “ESPパケットの形式”
ESP パケットは、固定長の ESP Header、可変長の Payload Data、ESP Trailer、必要に応じて付加される ICV から構成される。図の実線枠は実際に送信されるフィールド、破線枠は変換方式に応じて存在するフィールド、点線枠は計算には使われても通常は送信されない値を表す。
ESP Header
Section titled “ESP Header”ESP Header は、32 ビットの SPI と 32 ビットの Sequence Number からなる。合計 8 バイトであり、暗号化されずに送信される。
SPI（Security Parameters Index）は、受信側が受信パケットに対応する SA を選ぶための 32 ビット値である。SPI 自体は暗号鍵ではなく、SAD に登録された暗号方式、鍵、モードなどを参照するための識別値である。
SPI は受信側が決定する。同じ SPI があらゆる通信で一意になるわけではなく、実装は SPI に加えて宛先 IP アドレスや IPsec プロトコルなどを使って受信 SA を特定できる。
Sequence Number
Section titled “Sequence Number”Sequence Number は、SA ごとに送信パケットへ順番に付ける番号である。受信側はこの値とリプレイウィンドウを使い、すでに受信した番号や許容範囲より古い番号を検出する。
通常のフィールドは 32 ビットである。ESN（Extended Sequence Number）を使用すると内部のカウンタは 64 ビットになるが、パケットで送信されるのは下位 32 ビットだけである。上位 32 ビットは送信側と受信側がそれぞれ管理し、リプレイ検査や完全性計算に使う。
Sequence Number が同じ SA で循環すると、リプレイ検査や nonce の一意性を維持できなくなる。循環する前に新しい SA と鍵へ切り替える必要がある。
Payload Data
Section titled “Payload Data”Payload Data には、transport mode では TCP / UDP などの上位レイヤプロトコルとそのデータ、tunnel mode では内側 IP パケット全体が入る。暗号化を選択した SA では、実際のペイロードと ESP Trailer が暗号文になる。
IVまたはnonce
Section titled “IVまたはnonce”暗号アルゴリズムがパケットごとの同期データを必要とする場合、その値は Payload Data の先頭に置かれる。CBC で使う明示 IV や、AES-GCM で使う明示的な nonce の一部が該当する。
IV は ESP Header の固定フィールドではない。長さと有無は SA で選択した暗号変換によって決まり、明示 IV を使う変換では送信され、implicit IV を使う変換では Sequence Number などから生成されるため送信されない。
明示 IV は通常、それ自体は暗号化されない。暗号化と完全性確認を別々に行う構成では、改ざんを防ぐため完全性計算の対象には含まれる。
TFC Padding
Section titled “TFC Padding”TFC（Traffic Flow Confidentiality）Padding は、実際のデータ長を推測しにくくするため、Payload Data の末尾へ追加する任意のダミーデータである。実際のペイロードの後、通常の Padding の前に置かれる。
TFC Padding を取り除くには、内側 IP ヘッダの長さなどから本来のペイロード末尾を判断できなければならない。このため、元の IP パケット全体を格納する tunnel mode で利用しやすい。
ESP Trailer
Section titled “ESP Trailer”送信される ESP Trailer は、Padding、Pad Length、Next Header からなる。暗号化を選択した場合、この3フィールドは Payload Data の実データとともに暗号化される。
Padding
Section titled “Padding”Padding は 0～255 バイトの可変長フィールドである。暗号アルゴリズムが要求するブロック境界に合わせることと、Pad Length と Next Header を 32 ビット境界の右端へ配置することに使われる。
Padding は暗号処理に必要な長さ調整であり、通信量の特徴を隠す TFC Padding とは目的が異なる。必要な Padding がない場合でも Pad Length フィールドは存在し、値は 0 になる。
Pad Length
Section titled “Pad Length”Pad Length は 8 ビットで、直前にある通常の Padding のバイト数を示す。TFC Padding の長さは含まない。
Next Header
Section titled “Next Header”Next Header は 8 ビットで、ESP から取り出した本来のペイロード種別を示す。transport mode で TCP を保護するなら 6、UDP なら 17 になる。tunnel mode で内側に IPv4 パケットを入れるなら 4、IPv6 パケットなら 41 になる。
この値は ESP の後ろに別のヘッダが続くことを示すのではなく、復号後の Payload Data をどのプロトコルとして処理するかを示す。
ICV（Integrity Check Value）は、受信側がパケットの改ざんを検出するための値である。長さと配置方法は SA で選択した完全性アルゴリズムまたは AEAD アルゴリズムによって決まる。
暗号化と完全性確認を別々のアルゴリズムで行う場合、ICV は ESP パケット末尾に置かれる。計算対象は SPI、Sequence Number、Payload Data、Padding、Pad Length、Next Header であり、ICV フィールド自体は含めない。ESN を使う場合は、送信されない上位 32 ビットも計算へ加える。
完全性サービスを使わない SA では ICV が存在しない。暗号化と完全性確認を一体で行うアルゴリズムでは、アルゴリズムの仕様によって明示的な ICV の有無と配置が決まる。
AES-CBCとHMACを組み合わせた場合
Section titled “AES-CBCとHMACを組み合わせた場合”AES-CBC では、Payload Data の先頭に AES のブロック長と同じ 16 バイトの明示 IV を置く。IV に続く実データ、TFC Padding、通常の Padding、Pad Length、Next Header が AES-CBC の暗号文になる。
HMAC は SPI から Next Header までを完全性保護するため、暗号化されずに送信される SPI、Sequence Number、明示 IV も改ざん検出の対象になる。HMAC の出力を規定の長さへ切り詰めた値が、パケット末尾の ICV に入る。
AES-GCMを使用した場合
Section titled “AES-GCMを使用した場合”AES-GCM は暗号化と完全性確認を一つの処理で行う AEAD アルゴリズムである。RFC 4106 の AES-GCM-ESP では、SA が保持する 4 バイトの salt と、パケットで送信する 8 バイトの明示 IV を組み合わせて nonce を作る。Payload Data の先頭にはその 8 バイトの明示 IV が置かれ、後ろに暗号文が続く。
SPI と Sequence Number は暗号化せず、AAD（Additional Authenticated Data）として認証する。AES-GCM が生成する Authentication Tag は ESP の ICV フィールドに置かれる。
implicit IV 用の変換を使う場合は、Sequence Number または ESN から IV を生成するため、8 バイトの明示 IV を送信しない。同じ AES-GCM でも、選択した変換によって送信パケットの長さが変わる。
AHパケットの形式
Section titled “AHパケットの形式”
AH は暗号化を行わず、パケットの完全性確認、送信元認証、リプレイ防止を提供する。AH より前にある IPv4 Protocol または IPv6 Next Header の値は 51 になる。
Next Header
Section titled “Next Header”Next Header は 8 ビットで、AH の後ろに続くペイロードの種類を示す。transport mode なら TCP、UDP などを示し、tunnel mode なら内側の IPv4 または IPv6 を示す。
Payload Len
Section titled “Payload Len”Payload Len は 8 ビットで、AH 自体の長さを 32 ビット単位で表した値から 2 を引いた値である。AH の後ろにあるアプリケーションデータの長さではない。
Reserved
Section titled “Reserved”Reserved は将来の利用のために確保された 16 ビットである。送信時はすべて 0 にし、受信時は値の意味を解釈しない。ただし、値そのものは AH ヘッダの一部として ICV 計算に含める。受信時に 0 へ置き換えて計算するフィールドではないため、経路上で Reserved が変更されると ICV の検証に失敗する。
SPIとSequence Number
Section titled “SPIとSequence Number”SPI と Sequence Number の役割は ESP と同じである。SPI は受信 SA の選択に使い、Sequence Number はリプレイ防止に使う。ESN を使う場合も、送信するフィールドは下位 32 ビットであり、上位 32 ビットは ICV 計算へ暗黙的に加える。
AH の ICV は可変長で、AH ヘッダが IPv4 では 32 ビット、IPv6 では 64 ビットの整数倍になるよう、必要最小限の明示的な Padding を含む場合がある。
ICV は、AH より前にある IP ヘッダのうち経路上で変化しないフィールド、または受信時の値を予測できるフィールド、ICV をゼロにした AH ヘッダ、AH より後ろのペイロードを対象に計算する。経路上で変化し、受信値も予測できない IP ヘッダフィールドは、計算時にゼロとして扱う。
ペイロードは暗号化されないため、パケットを取得した第三者も内容を読める。一方、保護対象を変更すると ICV の検証に失敗する。
パケットキャプチャで確認できる範囲
Section titled “パケットキャプチャで確認できる範囲”暗号化された ESP パケットでも、外側 IP ヘッダ、SPI、下位 32 ビットの Sequence Number、送信される明示 IV、暗号文、ICV はパケット上で確認できる。暗号化された実データ、Padding、Pad Length、Next Header の値は、復号しなければ確認できない。
NAT-T では、これらに外側 UDP ヘッダが加わる。UDP 4500 の直後を確認すると、非ゼロ SPI で始まる ESP データか、4 バイトのゼロで始まる IKE メッセージかを判別できる。
AH ではペイロードを含むパケット内容を確認できる。ICV は内容を隠すものではなく、保護対象が送信後に変更されていないことを検証するための値である。
パケットサイズの増加
Section titled “パケットサイズの増加”元のデータに対する ESP 固有の増加量は、次の要素の合計で決まる。
8 バイトの ESP Header+ 送信するIVまたはnonce用データ+ TFC Padding+ 通常のPadding+ 2 バイトの Pad Length と Next Header+ ICVまたはAuthentication TagIV、TFC Padding、通常の Padding、ICV の長さは、暗号変換、完全性変換、元のデータ長によって変わる。そのため、ESP の増加量は常に同じではない。
tunnel mode では、さらに外側 IP ヘッダが加わる。オプションや拡張ヘッダがなければ IPv4 ヘッダは 20 バイト、IPv6 ヘッダは 40 バイトである。NAT-T を使う場合は、これに 8 バイトの UDP ヘッダが加わる。