2. Known Incompatibilities between NA(P)T and IPsec (NA(P)T と IPsec の間の既知の非互換性)

NA(P)T と IPsec の間の非互換性は, 3つのカテゴリに分けることができます:

本質的な NA(P)T 問題。これらの非互換性は, [RFC3022] で説明されている NA(P)T 機能から直接派生しています。したがって, これらの非互換性は任意の NA(P)T デバイスに存在します。
NA(P)T 実装の弱点。これらの非互換性は NA(P)T に本質的なものではありませんが, 多くの NA(P)T 実装に存在します。このカテゴリには, インバウンドまたはアウトバウンドフラグメントの処理における問題が含まれます。これらの問題は NA(P)T に本質的なものではないため, 原則として将来の NA(P)T 実装で対処できます。ただし, 実装の問題は広く普及しているように見えるため, NA(P)T トラバーサルソリューションで考慮する必要があります。
ヘルパー問題。これらの非互換性は, IPsec NA(P)T トラバーサルを提供しようとする NA(P)T デバイスに存在します。皮肉なことに, この "ヘルパー" 機能はさらなる非互換性を生み出し, すでに困難な問題をより解決しにくくしています。IPsec トラバーサル "ヘルパー" 機能はすべての NA(P)T に存在するわけではありませんが, これらの機能は十分に人気が高まっているため, NA(P)T トラバーサルソリューションでも考慮する必要があります。

2.1. Intrinsic NA(P)T Issues (本質的な NA(P)T 問題)

NA(P)T に本質的な非互換性には以下が含まれます:

a) IPsec AH [RFC2402] と NAT の間の非互換性。AH ヘッダーは鍵付きメッセージ完全性チェックに IP 送信元アドレスと宛先アドレスを組み込んでいるため, アドレスフィールドを変更する NAT または逆 NAT デバイスはメッセージ完全性チェックを無効にします。IPsec ESP [RFC2406] は鍵付きメッセージ完全性チェックに IP 送信元アドレスと宛先アドレスを組み込んでいないため, ESP ではこの問題は発生しません。

b) チェックサムと NAT の間の非互換性。TCP および UDP チェックサムは, 計算に "疑似ヘッダー" を含めることで IP 送信元アドレスと宛先アドレスに依存しています。その結果, チェックサムが計算され受信時にチェックされる場合, NAT または逆 NAT デバイスを通過することで無効になります。

その結果, IPsec カプセル化セキュリティペイロード (Encapsulating Security Payload, ESP) は, TCP/UDP プロトコルが関与していない場合 (IPsec トンネルモードまたは IPsec 保護された GRE の場合) またはチェックサムが計算されない場合 (IPv4 UDP で可能な場合) にのみ, NAT を妨げられずに通過できます。[RFC793] で説明されているように, IPv4 では TCP チェックサムの計算と検証が必要です。IPv6 では UDP/TCP チェックサムの計算と検証が必要です。

[RFC2960] および [RFC3309] で定義されているストリーム制御伝送プロトコル (Stream Control Transmission Protocol, SCTP) は, SCTP パケット (共通ヘッダー + チャンク) のみで計算される CRC32C アルゴリズムを使用するため, IP ヘッダーはカバーされません。その結果, NAT は SCTP CRC を無効にせず, 問題は発生しません。

トランスポートモード IPsec トラフィックは強力な暗号技術を使用して完全性が保護され認証されているため, UDP/TCP チェックサムをチェックする前にパケットへの変更を検出できることに注意してください。したがって, チェックサム検証は内部処理で行われたエラーに対する保証のみを提供します。

c) IKE アドレス識別子と NAT の間の非互換性。IP アドレスがインターネット鍵交換プロトコル (Internet Key Exchange Protocol, IKE) フェーズ 1 [RFC2409] またはフェーズ 2 で識別子として使用される場合, NAT または逆 NAT による IP 送信元アドレスまたは宛先アドレスの変更により, 識別子と IP ヘッダー内のアドレスの間に不一致が生じます。[RFC2409] で説明されているように, IKE 実装はそのようなパケットを破棄する必要があります。

IKE フェーズ 1 およびフェーズ 2 の識別子として IP アドレスの使用を避けるために, 代わりに userID および FQDN を使用できます。ユーザー認証が必要な場合, [RFC2407] で説明されているように ID_USER_FQDN の ID タイプを使用できます。マシン認証が必要な場合, ID_FQDN の ID タイプを使用できます。いずれの場合も, フェーズ 1 で証明書が交換される場合, 提案された識別子がエンドエンティティ証明書の処理の結果として認証されることを確認する必要があります。IKE 内で USER_FQDN または FQDN アイデンティティタイプの使用は可能ですが, この方法では対応できない使用シナリオ (たとえば, サブネットを記述するセキュリティポリシーデータベース (Security Policy Database, SPD) エントリ) があります。

フェーズ 2 識別子の送信元アドレスは完全な 5 タプルのインバウンド SA セレクタを形成するためによく使用されるため, インバウンド SA 処理を弱めないようにセレクタで宛先アドレス, プロトコル, 送信元ポート, および宛先ポートを使用できます。

d) 固定 IKE 送信元ポートと NAPT の間の非互換性。NAPT の背後にある複数のホストが同じレスポンダに対して IKE SA を開始する場合, NAPT がレスポンダからの着信 IKE パケットを逆多重化できるようにするメカニズムが必要です。これは通常, イニシエータからのアウトバウンドパケットの IKE UDP 送信元ポートを変換することで実現されます。したがって, レスポンダは 500 以外の UDP 送信元ポートからの IKE トラフィックを受け入れることができ, そのポートに応答する必要があります。鍵の再生成中に予測不可能な動作を避けるために注意する必要があります。フロートした送信元ポートが鍵の再生成の宛先ポートとして使用されない場合, NAT は鍵の再生成パケットを正しい宛先に送信できない可能性があります。

e) 重複する SPD エントリと NAT の間の非互換性。NAT の背後にあるイニシエーティングホストがフェーズ 2 識別子で送信元 IP アドレスを使用する場合, 同じレスポンダ IP アドレスで重複する SPD エントリをネゴシエートできます。レスポンダは間違った IPsec SA にパケットを送信する可能性があります。これは, レスポンダにとって IPsec SA が同等に見えるために発生します。これは, 同じエンドポイント間に存在し, 同じトラフィックを通過させるために使用できるためです。

f) IPsec SPI 選択と NAT の間の非互換性。IPsec ESP トラフィックは暗号化されているため NAT に対して不透明であり, NAT は着信 IPsec トラフィックを逆多重化するために IP および IPsec ヘッダーの要素を使用する必要があります。宛先 IP アドレス, セキュリティプロトコル (AH/ESP), および IPsec SPI の組み合わせが通常この目的で使用されます。

ただし, 送信 SPI と着信 SPI は独立して選択されるため, NAT がアウトバウンドトラフィックを検査するだけでどの着信 SPI がどの宛先ホストに対応するかを判断する方法はありません。したがって, NAT の背後にある 2 つのホストが同時に同じ宛先で IPsec SA を作成しようとすると, NAT が着信 IPsec パケットを誤った宛先に配信する可能性があります。

これは IPsec 自体との非互換性ではなく, 通常実装される方法との非互換性であることに注意してください。AH と ESP の両方で, 受信ホストは特定の SA に使用する SPI を指定します。この選択は受信者にのみ意味があります。現在, 宛先 IP, SPI, およびセキュリティプロトコル (AH, ESP) の組み合わせがセキュリティアソシエーション (Security Association) を一意に識別します。また, 1-255 の範囲の SPI 値は IANA に予約されており, 将来使用される可能性があります。これは, 同じ外部ホストまたはゲートウェイとネゴシエートする場合, 同じ NAPT の背後にある内部ホストが同じ SPI 値を選択できることを意味し, 1 つのホストのインバウンド SA が (SPI=470, Internal Dest IP=192.168.0.4) であり, 別のホストのインバウンド SA が (SPI=470, Internal Dest IP=192.168.0.5) である可能性があります。受信 NAPT は, SPI=470 のインバウンド IPsec パケットをどの内部ホストに転送すべきかを判断できません。

受信ホストが各ユニキャストセキュリティアソシエーションに一意の SPI を割り当てることも可能です。この場合, 宛先 IP アドレスは "このホストの任意の有効なユニキャスト IP" であるかをチェックするだけでよく, 送信ホストが使用する特定の宛先 IP アドレスであるかをチェックする必要はありません。この技術を使用すると, 2 つ以上のホストが同じ外部ホストと SA を確立した場合でも, NA(P)T はパケットを誤った内部ホストに転送する可能性が低いがゼロではないことを保証できます。

このアプローチは完全に後方互換性があり, 特定の受信ホストが SPI 割り当てと IPsec_esp_input() コードを変更するだけで済みます。ただし, NA(P)T デバイスは IKE ペイロードの解析に関連する問題なしにこの動作を検出できない可能性があります。また, ホストは割り当てられた目的のために IANA 予約範囲の SPI を使用する必要がある場合があります。

g) 埋め込み IP アドレスと NAT の間の非互換性。ペイロードは完全性が保護されているため, IPsec パケット内に含まれる IP アドレスは NAT によって変換できません。これにより, NAT 内に実装されたアプリケーション層ゲートウェイ (Application Layer Gateway, ALG) が無効になります。埋め込み IP アドレスを利用するプロトコルには, FTP, IRC, SNMP, LDAP, H.323, SIP, SCTP (オプション), および多くのゲームが含まれます。この問題に対処するには, IPsec カプセル化の前および IPsec カプセル解除の後にアプリケーショントラフィックで動作できる ALG をホストまたはセキュリティゲートウェイにインストールする必要があります。

h) NA(P)T の暗黙的な方向性。NA(P)T は多くの場合, インバウンドマッピング状態を作成するために初期アウトバウンドパケットがそれらを通過することを必要とします。方向性は NA(P)T の背後にあるホストへの IPsec SA の一方的な確立を禁止します。

i) インバウンド SA セレクタ検証。IKE がフェーズ 2 セレクタをネゴシエートすると仮定すると, インバウンド SA 処理はカプセル解除されたパケットをドロップします。これは, [RFC2401] がパケットの送信元アドレスが SA セレクタ値と一致することを要求しており, ESP パケットの NA(P)T 処理がこれを変更するためです。

2.2. NA(P)T Implementation Weaknesses (NA(P)T 実装の弱点)

多くの NA(P)T に存在する実装問題には以下が含まれます:

j) 非 UDP/TCP トラフィックを処理できないこと。一部の NA(P)T は非 UDP/TCP トラフィックを破棄するか, NAT の背後に 1 つのホストしかない場合にアドレスのみの変換を実行します。このような NAPT は SCTP, ESP (プロトコル 50), または AH (プロトコル 51) トラフィックを有効にできません。

k) NAT マッピングタイムアウト。NA(P)T はトラフィックがない場合に UDP マッピングが維持される時間が異なります。したがって, IKE パケットが正しく変換できる場合でも, 変換状態が早期に削除される可能性があります。

l) アウトゴーイングフラグメントを処理できないこと。ほとんどの NA(P)T は, IP パケットサイズがアウトゴーイングインターフェイスの MTU を超える場合にアウトゴーイング IP パケットを適切にフラグメント化できます。ただし, すでにフラグメント化されているアウトゴーイングパケットの適切な変換は困難であり, ほとんどの NAPT はこれを正しく処理しません。[RFC3022] のセクション 6.3 で述べられているように, 2 つのホストが同じ宛先にフラグメント化されたパケットを発信する場合, フラグメント識別子が重複する可能性があります。宛先ホストは再構成のためにフラグメント識別子とフラグメントオフセットに依存しているため, 結果はデータの破損になります。識別子の変換をサポートすることで識別子の衝突から保護する NA(P)T はほとんどありません。NAT がフラグメント化を実行する場合, フラグメント識別子は送信元/宛先 IP アドレスペア内で一意である必要があるだけなので, 識別子の衝突は問題になりません。

フラグメントは 68 オクテット [RFC791] と小さくなる可能性があるため, 最初のフラグメントに完全な TCP ヘッダーが含まれる保証はありません。したがって, TCP チェックサムを再計算しようとする NA(P)T は後続のフラグメントを変更する必要がある場合があります。フラグメントは並べ替えることができ, IP アドレスは埋め込まれ, フラグメント間で分割される可能性があるため, NA(P)T は変換を完了する前に再構成を実行する必要があります。これをサポートする NA(P)T はほとんどありません。

m) インカミングフラグメントを処理できないこと。通常, 最初のフラグメントのみが完全な IP/UDP/SCTP/TCP ヘッダーを含むため, NAPT は送信元/宛先 IP アドレスとフラグメント識別子のみに基づいて変換を実行できる必要があります。フラグメントは並べ替えることができるため, 後続のフラグメントが最初のフラグメントの前に到着した場合, 特定のフラグメント識別子のヘッダーがわからない可能性があり, ヘッダーがフラグメント間で分割されている可能性があります。その結果, NAPT は変換を完了する前に再構成を実行する必要がある場合があります。これをサポートする NAPT はほとんどありません。NAT の場合, 送信元/宛先 IP アドレスで変換を決定するのに十分であるため, これは発生しないことに注意してください。ただし, IPsec または IKE ヘッダーがフラグメント間で分割される可能性があるため, 再構成が必要になる場合があります。

2.3. Helper Incompatibilities (ヘルパー非互換性)

IPsec と NAT "ヘルパー" 機能の間の非互換性には以下が含まれます:

n) インターネットセキュリティアソシエーションおよび鍵管理プロトコル (Internet Security Association and Key Management Protocol, ISAKMP) ヘッダー検査。今日, 一部の NAT 実装は着信 IKE トラフィックを逆多重化するために IKE クッキーを使用しようとします。送信元ポート逆多重化と同様に, IKE クッキー逆多重化は鍵の再生成で問題を引き起こします。これは, フェーズ 1 の鍵の再生成が通常以前のトラフィックと同じクッキーを使用しないためです。

o) ポート 500 の特別な扱い。一部の IKE 実装は非 500 UDP 送信元ポートを処理できないため, 一部の NAT は UDP 送信元ポートが 500 のパケットを変換しません。これは, これらの NAT が宛先ゲートウェイごとに 1 つの IPsec クライアントに制限されることを意味します。ただし, クッキーを検査するために ISAKMP ヘッダーの詳細を検査する場合を除きます。これにより上記の問題が発生します。

p) ISAKMP ペイロード検査。ISAKMP ペイロードを解析しようとする NA(P)T 実装は, すべてのペイロード順序の組み合わせを処理できないか, IKE オプションネゴシエーション用の vendor_id ペイロードをサポートしていない可能性があります。