2.23. NAT Traversal (NAT トラバーサル)

2.23. NAT Traversal (NAT トラバーサル)

ネットワークアドレス変換 (NAT) ゲートウェイは議論の的である. 本節ではそれが何か, IKE トラフィックにどう作用し得るかを簡潔に述べる. NAT は有害でありプロトコルをそれに合わせて設計すべきでないという意見もある. IKEv2 は NAT がより動作しやすくなるよう, 直感に反する処理規則をいくつか規定する.

NAT は主に IPv4 アドレス不足のために存在する. NAT の背後のノードの IP アドレスはグローバルに一意ではなく, NAT 背後の空間内では一意だが他の NAT 背後で再利用されやすい. 一般に同じ NAT 背後同士およびグローバル一意アドレスのノードとは通信できるが, 別 NAT 背後とはできない (例外あり). インターネット上のノードへ接続するとき, NAT ゲートウェイは送信元 IP をゲートウェイへルーティング戻るアドレスに "変換" する. インターネットからゲートウェイへのメッセージは, 正しいエンドノードへルーティングする内部アドレスに目的アドレスを "変換" する.

NAT はエンドノードに "透明" であるよう設計されている. 背後ノードもインターネット側ノードも NAT 越し通信のために改変を要しない. プロトコルによってはこの透明性の達成が難しい. ペイロード内にエンドポイント IP を含むプロトコルは, NAT がプロトコルを理解しヘッダと内部参照の両方を書き換えないと失敗する. その知識は本質的に信頼性に欠け, ネットワーク層違反となり, しばしば微妙な問題を生む.

NAT 越しの IPsec 接続には特別な問題がある. トランスポートモードでは IP アドレス変更でチェックサムが壊れ, NAT は暗号保護のためチェックサムを修正できない. トンネルモードでも, AH/ESP のアドレスを透明に変換するには NAT の特別な論理が必要で, それはヒューリスティックで信頼性に欠ける. そのため IKEv2 は IKE と ESP を UDP でカプセル化する. やや非効率だが NAT の処理は容易になる. ファイアウォールはプレーン ESP/AH ではなく UDP カプセル化 IPsec のみ通す設定もあり得る.

NAT は TCP/UDP ポートもアドレスと同様に変換し, 着信パケットのポートで内部ノードを決めることが多い. したがって IKE は UDP 500 または 4500 へ送受信しなければならないが, 任意のポートからの IKE を受け入れ, 応答は来たポートへ返さなければならない. NAT 通過でポートが変わり得るためである. 同様に IKE エンドポイント IP は一般に IKE ペイロードに含めない. ペイロードは暗号保護され NAT が透明変更できないためである.

ポート 4500 は UDP カプセル化 ESP と IKE 用に予約されている. 相手との間に NAT があると判明した IPsec エンドポイント (後述) は, 以降のすべてのトラフィックをポート 4500 から送らなければならない. NAT は 500 と同様に特別扱いしないはずである.

イニシエータは最初から NAT の有無に関わらず IKE と ESP の両方に 4500 を用いてよい. いずれかが 4500 を使う場合, ESP の UDP カプセル送信は必須でないが, 受信 UDP カプセル ESP の理解は必須である. ポート 500 では UDP カプセルをしてはならない. NAT トラバーサル (NAT-T) をサポートする場合 (IKE_SA_INIT で NAT_DETECTION_*_IP を交換した場合), すべてのデバイスは常に UDP カプセル ESP と非 UDP カプセル ESP の両方を受信処理できなければならない. ESP の UDP カプセルは相手の選択に依存してよい. ただし NAT が検出されたら双方は ESP に UDP カプセルを用いなければならない.

NAT トラバーサル [NATREQ] の要件を以下に列挙する. サポートは任意である. 本節のみ, MUST と書いた要件は NAT トラバーサルをサポートする実装にのみ適用される.

• IKE イニシエータとレスポンダは IKE_SA_INIT に NAT_DETECTION_SOURCE_IP と NAT_DETECTION_DESTINATION_IP 型の Notify を含めなければならない. ホスト間に NAT があるかどちらが NAT 背後かを検出するために用いる. ペイロード位置は Ni と Nr の直後 (任意 CERTREQ の前).

• NAT_DETECTION_SOURCE_IP のデータは, ヘッダ出現順の SPI, 送信元 IP とポートの SHA-1 ダイジェストである.

  どのネットワーク接続で送るか不明な場合, 複数の NAT_DETECTION_SOURCE_IP を含めてもよい.

• NAT_DETECTION_DESTINATION_IP のデータは, SPI (ヘッダ順), 宛先 IP とポートの SHA-1 ダイジェストである.

• いずれかの通知の受信者は, 供給値と (それぞれ) SPI, 送信元または宛先 IP とポートの SHA-1 を比較し, 一致しなければ NAT トラバーサルを有効にすべきである. NAT_DETECTION_SOURCE_IP のハッシュが受信したすべての当該ペイロードと一致しない場合, NAT トラバーサルをサポートしないなら接続を拒否してもよい. NAT_DETECTION_DESTINATION_IP の不一致は, そのペイロードを受け取るシステムが NAT 背後であることを意味し, [UDPENCAPS] の keepalive を送り始めるべきである. または NAT トラバーサル非サポートなら拒否してよい.

• 受信した NAT_DETECTION_SOURCE_IP のいずれも, ペイロードを含むパケットの IP ヘッダから得た送信元 IP/ポートの期待値と一致しない場合, それらペイロードを送ったシステムは NAT 背後である (経路上で元の送信元が NAT ボックスのアドレスに変えられた). この場合受信側は後述のとおり相手の IP アドレスの動的更新を許すべきである.

• IKE イニシエータは NAT_DETECTION_SOURCE_IP または NAT_DETECTION_DESTINATION_IP があれば検査し, 外側パケットのアドレスと一致しなければ, 本 IKE SA に関連する以降の IKE と ESP をすべて UDP 4500 でトンネルしなければならない.

• IKE を UDP 4500 でトンネルするには IKE ヘッダの前に 4 オクテットのゼロを付け, すぐ UDP ヘッダの後に続ける. ESP は UDP ヘッダ直後に ESP ヘッダ. ESP ヘッダ先頭 4 オクテットは SPI で, SPI はゼロになり得ないため IKE と ESP は常に区別できる.

• 実装は NAT が検出されなくても受信 UDP カプセル ESP を処理しなければならない.

• トランスポートモード TCP/UDP チェックサム修正に必要な元の送信元/目的 IP ([UDPENCAPS]) は交換に関連するトラフィックセレクタから得る. トランスポートモード NAT トラバーサルでは TS はちょうど 1 つの IP アドレスを含めなければならず, それを元の IP として用いる. 詳細は 2.23.1 節.

• NAT がまだ生存しているマッピングを削除する場合 (keepalive が長すぎる, NAT 再起動など) がある. 完全性が検証されたが SA に関連付けていたものとポートまたはアドレスが異なるパケットを受け取ればホストはそれに気づく. そのような検証済みパケットが見つかったとき, MOBIKE [MOBIKE] など他の回復手段をサポートせず NAT 背後でもないホストは, すべてのパケット (再送含む) を検証済みパケットの IP/ポートへ送り, SA の新しいアドレスとして保存すべきである (動的更新). NAT 背後のホストは, 検証済みでポート/アドレスが異なる場合にこの動的更新をしてはならない. 単一パケットで接続を破壊できる DoS などが開く. 動的更新は新しいパケットへの応答でのみ行う. 古いリプレイで攻撃者がアドレスを戻せるためである. よってリプレイ保護が有効な場合にのみ安全に動的更新できる. IKEv2 と MOBIKE 併用時, 上記動的更新は MOBIKE の回復と干渉する. [MOBIKE] 3.8 節参照.

2.23.1. Transport Mode NAT Traversal (トランスポートモード NAT トラバーサル)

NAT トラバーサルとトランスポートモードでは IKEv2 のトラフィックセレクタを特別に扱う. 完全なシナリオ:

+------+        +------+            +------+         +------+
|Client| IP1    | NAT  | IPN1  IPN2 | NAT  |     IP2 |Server|
|node  |<------>|  A   |<---------->|  B   |<------->|      |
+------+        +------+            +------+         +------+

(他シナリオは本複雑ケースの単純化である.)

アドレス変換 NAT が 2 つ: NAT A と B. NAT A はクライアントの送信元 IP1 を IPN1 に動的マップする. NAT B は IPN2 への接続をゲートウェイ IP2 に静的マップする, つまり目的 IPN2 を IP2 にマップする. クライアントは IPN2 に接続してサーバに届く. NAT B は静的でなくてもよいが, クライアントはサーバへの接続方法を知る必要があり, それは NAT B の外部アドレス IPN2 を何らかの方法で知る場合に限る. 静的ならクライアント設定に載せられる. DNS など別プロトコルもあるが IKEv2 の範囲外である.

クライアントとサーバはともに, クライアント発サーバ宛トラフィックにトランスポートモードを使うよう設定されている.

クライアントがサーバ向け IKEv2 SA と Child SA の作成を始めるとき, トリガパケットは送信元 IP1, 目的 IPN2 かもしれない. PAD と SPD はそれら (またはワイルドカード) に合う設定が必要である. トランスポートモードでは TS と IKE 外側 IP が同じアドレスである. TSi と TSr には厳密に 1 IP ずつでなければならない. 複数ポート範囲なら複数 TS もよいが, すべての TSi は IP1-IP1, すべての TSr は IPN2-IPN2 である. 最初の TSi/TSr はトリガパケット由来のプロトコルとポートを含む具体的なものにすべきである.

NAT A は IKE の送信元を IP1 から IPN1 に, NAT B は目的を IPN2 から IP2 に置換する. サーバに届くとき TS はクライアントが送ったのと同じだが IKE の IP は IPN1 と IP2 になっている.

サーバは通常 ID で PAD ([IPSECARCH] RFC 4301) を見てから TS で SPD を検索する. IP1 はサーバにとって意味がない (NAT 背後のクライアントアドレス) のでトランスポートモードではそれでの検索は無意味である. 一方, 一致 SPD を見つけるまでポリシーがトランスポートを許すかは分からない.

この場合サーバはまずイニシエータがトランスポートを要求したか確認し, TS にアドレス置換を行う. まず旧 TS IP を増分チェックサム修正用に保存する (TSi を元送信元, TSr を元目的として). その後相手が NAT 背後と検出されれば TSi の IP を受信 IKE の送信元 (IP1 を IPN1 に) に置換する. サーバ側が NAT 背後なら TSr を受信 IKE の宛先 (IPN2 を IP2 に) に置換する.

置換後 TS と IKE UDP 送受信は一致し, サーバは新 TS で SPD 検索する. 見つかりトランスポート許可ならそれを使う. 見つかるがトランスポート不可なら置換を元に戻し元 TS で SPD を再検索してもよい. 2 回目が成功すれば相手の実 TS でトンネルモード SA を作る.

トランスポートでの置換は, SPD がローカルホストが見るアドレスで検索されるために必要である. SAD のトンネル出口チェックと戻りパケットも OS スタックが見るアドレスで追加される.

サーバ SPD は任意アドレスにマッチするワイルドカードが一般的だが, 既知 NAT の外部アドレスごとに異なる SPD も可能である.

SPD 検索後サーバは見つかった SPD で TS を狭める. すでに置換した TS を用い, 返す TS の IP は IPN1 と IP2 になり, プロトコルやポートは狭めてよい. Child SA の SAD はサーバが見るアドレス IPN1 と IP2 になる.

クライアントは Child SA 応答で同様に処理する. トランスポート SA が作られたなら返却 TS を元送受信アドレスとして保存し, IKE パケット IP ヘッダのアドレスで TS の IP を置換する (IPN1 を IP1 に, IP2 を IPN2 に). それで SA を送信 TS と照合し SAD をインストールする.

トランスポートモード NAT トラバーサルの規則要約:

クライアント (トランスポート提案):

• TSi は厳密に 1 IP で IKE SA 送信元と一致しなければならない.

• TSr は厳密に 1 IP で IKE SA 宛先と一致しなければならない.

• 最初の TSi/TSr はトリガパケット由来の具体的なプロトコルとポートを含めるべきである.

• 複数 TSi/TSr があり得る.

• トランスポートが選ばれた場合 (応答に USE_TRANSPORT_MODE がある):

  • 元 TS を受信元/先アドレスとして保存する.

  • サーバが NAT 背後なら TSr の IP を IKE SA リモートアドレスに置換する.

  • クライアントが NAT 背後なら TSi の IP を IKE SA ローカルアドレスに置換する.

  • 元内容保存以外のあらゆる用途の前に置換する (相手の狭め検証, SAD 作成など).

レスポンダ (クライアントがトランスポート提案):

• 元 TS IP を保存する (置換取消, [UDPENCAPS] の実送受信アドレス, TCP/UDP チェックサム修正用).

• クライアントが NAT 背後なら TSi を IKE SA リモートに置換.

• サーバが NAT 背後なら TSr を IKE SA ローカルに置換.

• 置換後 TS と ID で PAD/SPD 検索.

• SPD が無いかトランスポート不許可なら置換を元に戻し, 元 TS と ID で再検索しトンネルモード SPD も探す (トンネルにフォールバック).

• トランスポート SPD が見つかったら置換 TS と SPD で通常の狭めを行い, 結果 TS で SAD 作成とクライアントへの TS 返送を行う.