AH と NAPT の非互換
プライベートアドレスをもつホスト A と，インターネット上のホスト B との間の通信を IPsec のトランスポートモードで保護する。A と B の間には，送信元の IP アドレスとポート番号を変換する NAPT ルータがある。IPsec のプロトコルとして AH を用いた場合に B で起こることとして，適切なものはどれか。
- アNAPT が送信元 IP アドレスを書き換えるが，AH の ICV は送信元 IP アドレスなど IP ヘッダの不変フィールドも対象として計算されているので，B で完全性の検証に失敗し，パケットは破棄される。
- イAH の ICV は TTL を含む IP ヘッダ全体を対象として計算されているので，NAPT の有無にかかわらず，ルータを経由して TTL が減るたびに B で検証に失敗する。
- ウAH によってトランスポート層のヘッダが暗号化されているので，NAPT はポート番号を参照できず，パケットを B へ転送できない。
- エESP に切り替えても，ESP の ICV には IP ヘッダの送信元アドレスが含まれるので，AH と同じ理由で B での検証に失敗する。
正解と解説を見る
正解 ア
この問題の基礎知識
- IPsec の AH は完全性と送信元認証を提供するが，暗号化は行わない。ESP は暗号化による機密性に加えて，完全性と送信元認証も提供できる。
- トランスポートモードは元の IP ヘッダを残してペイロードを保護し，トンネルモードは元の IP パケット全体を新しい IP ヘッダでカプセル化して保護する。
- AH の ICV（完全性チェック値）は，送信元・宛先アドレスなど転送中に変わらない IP ヘッダのフィールドも計算対象とし，TTL など転送中に変わるフィールドは 0 として計算する。ESP の完全性保護は IP ヘッダを対象としない。
- NAPT は送信元の IP アドレスとポート番号を書き換えるので，IPsec と組み合わせると問題が生じることがある。ESP の暗号化でポート番号が見えなくなる問題には，UDP カプセル化（NAT トラバーサル）で対処する。
アNAPT が送信元 IP アドレスを書き換えるが，AH の ICV は送信元 IP アドレスなど IP ヘッダの不変フィールドも対象として計算されているので，B で完全性の検証に失敗し，パケットは破棄される。正解
AH の ICV は，送信元・宛先アドレスなど転送中に変化しない IP ヘッダのフィールドも対象とする。RFC 3715 は，アドレスを書き換える NA(P)T は AH の完全性検査を無効にするので，両者は本質的に両立しないとしている。
イAH の ICV は TTL を含む IP ヘッダ全体を対象として計算されているので，NAPT の有無にかかわらず，ルータを経由して TTL が減るたびに B で検証に失敗する。
TTL やヘッダチェックサムなど転送中に変化するフィールドは，ICV の計算時に 0 として扱われる（RFC 4302）。そのため，ルータを経由して TTL が減っても AH の検証は失敗しない。
ウAH によってトランスポート層のヘッダが暗号化されているので，NAPT はポート番号を参照できず，パケットを B へ転送できない。
AH は完全性と送信元認証を提供するが暗号化は行わないので，ポート番号は平文のまま参照できる。暗号化によってポート番号が見えなくなるのは ESP の場合であり，UDP カプセル化（RFC 3948）で対処する。
エESP に切り替えても，ESP の ICV には IP ヘッダの送信元アドレスが含まれるので，AH と同じ理由で B での検証に失敗する。
ESP の完全性保護は IP ヘッダのフィールドを対象としない。RFC 3715 でも，ESP は送信元・宛先アドレスを完全性検査に含めないので，AH のような問題は生じないとされている。
検証用の出典出典照合済み
RFC 4302 IP Authentication Header ／ RFC 3715 IPsec-Network Address Translation (NAT) Compatibility Requirements ／ RFC 3948 UDP Encapsulation of IPsec ESP Packets照合の根拠（5 件）
- ア（正解）: AH は送信元・宛先アドレスを完全性検査に含むので，アドレスを書き換える NA(P)T で検査が無効になる
Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT or reverse NAT devices making changes to address fields will invalidate the message integrity check.
RFC 3715 · Section 2.1（新しいタブで開きます） - ア（正解）: ICV の検証に失敗したパケットは B で破棄される
If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid.
RFC 4302 · Section 3.4.4（新しいタブで開きます） - イ（誤り）: TTL など転送中に変化するフィールドは 0 として ICV を計算する（同 3.3.3.1.1.1 で TTL は Mutable (zeroed) に分類）
If a field may be modified during transit, the value of the field is set to zero for purposes of the ICV computation.
RFC 4302 · Section 3.3.3.1（新しいタブで開きます） - ウ（誤り）: 暗号化（機密性）を提供するのは ESP であり，AH は暗号化しないのでポート番号は平文のまま
ESP may be used to provide the same anti-replay and similar integrity services, and it also provides a confidentiality (encryption) service.
RFC 4302 · Section 1（新しいタブで開きます） - エ（誤り）: ESP は IP アドレスを完全性検査に含めないので AH のような問題は生じない
Since IPsec ESP [RFC2406] does not incorporate the IP source and destination addresses in its keyed message integrity check, this issue does not arise for ESP.
RFC 3715 · Section 2.1（新しいタブで開きます）
NAPT が送信元アドレスを書き換えると，A が AH の ICV 計算に含めた送信元アドレスと B で受け取るアドレスが一致しなくなり，ICV 検証に失敗して破棄される。