メインコンテンツまでスキップ

2.23. NAT トラバーサル

2.23. NAT トラバーサル​

ネットワーク・アドレス変換 (NAT) ゲートウェイは議論のある主題です。このセクションでは, それらが何であるか, および IKE トラフィックに対してどのように作用する可能性があるかを簡単に説明します。多くの人は NAT は悪であり, それらがよりうまく機能するようにプロトコルを設計すべきではないと考えています。IKEv2 は, NAT がよりうまく機能する可能性が高くなるように, いくつかの直感的でない処理規則を指定しています。

NAT は主に IPv4 アドレスの不足のために存在しますが, 他の根拠もあります。NAT の「背後」にある IP ノードは, グローバルに一意ではない IP アドレスを持ちます。むしろ, NAT の背後のネットワーク内で一意な, しかし他の NAT の背後にあるノードによって再利用される可能性が高い空間から割り当てられたアドレスを持ちます。一般に, NAT の背後のノードは, 同じ NAT の背後の他のノードや, グローバルに一意なアドレスを持つノードとは通信できますが, 他の NAT の背後のノードとは通信できません。その規則には例外もあります。それらのノードが実際のインターネット上のノードへの接続を確立するとき,

NAT ゲートウェイは, ゲートウェイにルーティングし直されるアドレスに IP 送信元アドレスを「変換」します。インターネットからゲートウェイへのメッセージは, パケットを正しいエンドノードにルーティングする内部アドレスに宛先アドレスが「変換」されます。

NAT は, エンドノードに対して「透過的」であるように設計されています。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 からおよび宛てに送信されなければなりません (MUST) が, それらは任意のポートから来るものとして受け入れられなければならず (MUST), 応答はそれらが来たポートに送信されなければなります (MUST)。これは, パケットが NAT を通過するときにポートが変更される可能性があるためです。同様に, IKE エンドポイントの IP アドレスは, ペイロードが暗号学的に保護されており NAT によって透過的に変更できないため, 通常 IKE ペイロードには含まれません。

ポート 4500 は, UDP カプセル化された ESP および IKE のために予約されています。それとその通信相手との間に NAT が存在することを検出した (以下で説明) IPsec エンドポイントは, すべての後続のトラフィックをポート 4500 から送信しなければならず (MUST), NAT は (ポート 500 の場合のように) 特別に扱うべきではありません。

イニシエータは, NAT があるかどうかに関わらず, IKE の開始時でさえ, IKE と ESP の両方にポート 4500 を使用してもかまいません (MAY)。いずれかの側がポート 4500 を使用している場合, UDP カプセル化された ESP の送信は必須ではありませんが, 受信した UDP カプセル化 ESP パケットを理解することは必須です。UDP カプセル化はポート 500 上で行われてはならない (MUST NOT)。ネットワーク・アドレス変換トラバーサル (NAT-T) がサポートされている場合 (すなわち, IKE_SA_INIT 中に NAT_DETECTION_*_IP ペイロードが交換された場合), すべてのデバイスは, いつでも UDP カプセル化された ESP および非 UDP カプセル化 ESP パケットの両方を受信および処理できなければなります (MUST)。いずれの側も, 他方による選択とは無関係に, ESP に UDP カプセル化を使用するかどうかを決定できます。しかし, NAT が検出された場合, 両方のデバイスは ESP に UDP カプセル化を使用しなければならない (MUST)。

NAT トラバーサル [NATREQ] をサポートするための具体的な要件を以下に示します。NAT トラバーサルのサポートはオプションです。このセクションのみにおいて, MUST としてリストされた要件は, NAT トラバーサルをサポートする実装にのみ適用されます。

o IKE イニシエータおよびレスポンダの両方は, それらの IKE_SA_INIT パケットに, タイプ NAT_DETECTION_SOURCE_IP および NAT_DETECTION_DESTINATION_IP の Notify ペイロードを含めなければならない (MUST)。これらのペイロードは, ホスト間に NAT があるかどうか, およびどちらの端が NAT の背後にあるかを検出するために使用できます。IKE_SA_INIT パケット内のペイロードの位置は, Ni および Nr ペイロードの直後 (オプションの CERTREQ ペイロードの前) です。

o NAT_DETECTION_SOURCE_IP 通知に関連付けられたデータは, このパケットが送信された SPI (ヘッダに現れる順序), IP アドレス, およびポートの SHA-1 ダイジェストです。送信側がどのネットワーク接続を用いてパケットを送信するかわからない場合, メッセージ内に複数の NAT_DETECTION_SOURCE_IP ペイロードが存在してもかまいません (MAY)。

o NAT_DETECTION_DESTINATION_IP 通知に関連付けられたデータは, このパケットが送信された SPI (ヘッダに現れる順序), IP アドレス, およびポートの SHA-1 ダイジェストです。

o NAT_DETECTION_SOURCE_IP または NAT_DETECTION_DESTINATION_IP 通知の受信側は, 提供された値を, SPI, 送信元または受信側 IP アドレス (それぞれ), アドレス, およびポートの SHA-1 ハッシュと比較してもかまい (MAY) ず, それらが一致しない場合, NAT トラバーサルを有効にすべきです (SHOULD)。受信したすべての NAT_DETECTION_SOURCE_IP ハッシュが NAT_DETECTION_SOURCE_IP ハッシュと一致しない場合, 受信側は, NAT トラバーサルがサポートされていなければ, 接続試行を拒否してもかまいません (MAY)。一致しない NAT_DETECTION_DESTINATION_IP ハッシュの場合, それは NAT_DETECTION_DESTINATION_IP ペイロードを受信したシステムが NAT の背後にあることを意味し, そのシステムは [UDPENCAPS] で定義されたキープアライブ・パケットの送信を開始すべきです (SHOULD)。あるいは, NAT トラバーサルがサポートされていなければ, 接続試行を拒否してもかまいません (MAY)。

o 受信した NAT_DETECTION_SOURCE_IP ペイロード (複数可) のいずれもが, そのペイロードを含むパケットの IP ヘッダから見つかった送信元 IP およびポートの期待値と一致しない場合, それはこれらのペイロードを送信したシステムが NAT の背後にあることを意味します (すなわち, 経路のどこかが元のパケットの送信元アドレスを NAT ボックスのアドレスに一致するように変更した)。この場合, ペイロードを受信したシステムは, 後で説明するように, 他のシステムの IP アドレスの動的更新を許可すべきです (SHOULD)。

o IKE イニシエータは, NAT_DETECTION_SOURCE_IP または NAT_DETECTION_DESTINATION_IP ペイロード (存在する場合) をチェックしなければならず (MUST), それらが外部パケット内のアドレスと一致しない場合, この IKE SA に関連付けられたすべての将来の IKE および ESP パケットを UDP ポート 4500 経由でトンネリングしなければなりません (MUST)。

o UDP ポート 4500 経由で IKE パケットをトンネリングするには, IKE ヘッダの前に 4 オクテットのゼロを付加し, 結果は UDP ヘッダの直後に続きます。UDP ポート 4500 経由で ESP パケットをトンネリングするには, ESP ヘッダは UDP ヘッダの直後に続きます。ESP ヘッダの最初の 4 オクテットは SPI を含み, SPI は有効にゼロであってはならないため, ESP と IKE メッセージを常に区別できます。

o 実装は, NAT が検出されなかった場合でも, 受信した UDP カプセル化 ESP パケットを処理しなければならない (MUST)。

o トランスポート・モードの TCP および UDP パケットのチェックサム修正 ( [UDPENCAPS] 参照) に必要な元の送信元および送信先 IP アドレスは, 交換に関連付けられたトラフィック・セレクタから取得されます。トランスポート・モード NAT トラバーサルの場合, トラフィック・セレクタは正確に 1 つの IP アドレスを含まなければならず (MUST), その後それが元の IP アドレスとして使用されます。これについてはセクション 2.23.1 で詳しく説明します。

o NAT ボックスが, まだ生存しているマッピングを削除する (たとえば, キープアライブ間隔が長すぎる, または NAT ボックスが再起動された) 場合があります。これは, ホストが, 整合性保護が検証されるが, 検証されたパケット内でその SA に関連付けられていたものとは異なるポート, アドレス, またはその両方を持つパケットを受信した場合, ホストに明らかになります。そのような検証されたパケットが見つかったとき, IKEv2 Mobility and Multihoming (MOBIKE) [MOBIKE] などの他の回復方法をサポートせず, また NAT の背後にないホストは, すべてのパケット (再送パケットを含む) を検証されたパケット内の IP アドレスおよびポートに送信すべきであり (SHOULD), またそれを SA の新しいアドレスおよびポートの組み合わせとして格納すべきです (SHOULD) (すなわち, それらはアドレスを動的に更新すべきです)。NAT の背後のホストは, 検証されたパケットが異なるポートおよび/またはアドレス値を持つ場合, この種の動的アドレス更新を行うべきではありません (SHOULD NOT)。なぜなら, それは可能な DoS 攻撃 (たとえば, 攻撃者が単一のパケットで接続を切断できるようにする) を開くからです。さらに, 動的アドレス更新は, 新しいパケットへの応答としてのみ行われるべきです。そうでなければ, 攻撃者は古い再生パケットでアドレスを元に戻すことができます。このため, 動的更新は, リプレイ保護が有効な場合にのみ安全に実行できます。IKEv2 が MOBIKE と共に使用される場合, 上記の動的アドレス更新は, 同じ状況からの回復における MOBIKE の方法を妨げます。詳細については [MOBIKE] のセクション 3.8 を参照してください。

2.23.1. トランスポート・モード NAT トラバーサル​

NAT トラバーサルと共に使用されるトランスポート・モードは, IKEv2 で使用されるトラフィック・セレクタの特別な処理を必要とします。完全なシナリオは次のようになります:

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

(他のシナリオはこの複雑な場合の単純化であるため, この議論では完全なシナリオを使用します。)

このシナリオでは, 2 つのアドレス変換 NAT があります: NAT A と NAT B です。NAT A は, クライアントの送信元アドレス IP1 を IPN1 にマップする動的 NAT です。NAT B は, IPN2 アドレスに来る接続がゲートウェイのアドレス IP2 にマップされるように設定された静的 NAT です。すなわち, IPN2 宛先アドレスは IP2 にマップされます。これにより, クライアントは IPN2 への接続によりサーバーに接続できます。NAT B は必ずしも静的 NAT である必要はありませんが, クライアントはサーバーへの接続方法を知っている必要があり, それは NAT B の外部アドレス (すなわち IPN2 アドレス) を何らかの方法で知っている場合にのみ可能です。NAT B が静的 NAT の場合, そのアドレスはクライアントの設定に設定できます。別の選択肢は, DNS などの他のプロトコルを使用してそれを見つけることですが, それは IKEv2 の範囲外です。

このシナリオでは, クライアントとサーバーの両方が, クライアント・ノードから発信されサーバーに宛てられたトラフィックにトランスポート・モードを使用するように設定されています。

クライアントがサーバーへのトラフィック送信のための IKEv2 SA および Child SA の作成を開始するとき, 送信元 IP アドレスが IP1 で宛先 IP アドレスが IPN2 であるトリガー・パケットを持っているかもしれません。その Peer Authorization Database (PAD) および SPD は, それらのアドレス (またはそれらをカバーするワイルドカード・エントリ) に一致する設定を持つ必要があります。

これはトランスポート・モードであるため, トラフィック・セレクタおよび IKE パケットの外部 IP アドレスと全く同じアドレスを使用します。トランスポート・モードの場合, TSi および TSr ペイロード内で正確に 1 つの IP アドレスを使用しなければなります (MUST)。たとえばネゴシエートしたい複数のポート範囲がある場合, 複数のトラフィック・セレクタを持つことができますが, すべての TSi エントリは IP アドレスとして IP1-IP1 範囲を使用しなければならず, すべての TSr エントリは IP アドレスとして IPN2-IPN2 範囲を持たなければなりません。TSi および TSr の最初のトラフィック・セレクタは, トリガー・パケットからのものなど, プロトコルおよびポート番号を含む非常に具体的なトラフィック・セレクタを持つべきです (SHOULD)。

NAT A はその後 IKE パケットの送信元アドレスを IP1 から IPN1 に置き換え, NAT B は IKE パケットの宛先アドレスを IPN2 から IP2 に置き換えるため, パケットがサーバーに到着したとき, それは依然としてクライアントが送信した全く同じトラフィック・セレクタを持ちますが, IKE パケットの IP アドレスは IPN1 および IP2 に置き換えられています。

サーバーがこのパケットを受信すると, 通常は, ID に基づいて RFC 4301 [IPSECARCH] で説明された Peer Authorization Database (PAD) を調べ, 次にトラフィック・セレクタに基づいて SPD を検索します。IP1 はサーバーにとって実際には何の意味も持たない (それはクライアントが NAT の背後にあるアドレスである) ため, トランスポート・モードが使用される場合, それに基づく検索は無意味です。一方, サーバーは, 一致する SPD エントリを見つける前に, そのポリシーがトランスポート・モードを許可するかどうかを知ることができません。

この場合, サーバーは最初にイニシエータがトランスポート・モードを要求したかどうかをチェックし, 次にトラフィック・セレクタに対してアドレス置換を行うべきです (SHOULD)。最初に古いトラフィック・セレクタ IP アドレスを格納しておく必要があります (TSi 内の IP アドレスは元の送信元アドレスとして, TSr 内の IP アドレスは元の宛先アドレスとして格納できます)。その後, 他端が NAT の背後にあると検出された場合, サーバーは TSi ペイロード内の IP アドレスを, 受信した IKE パケットの送信元アドレスから取得した IP アドレスに置き換えます (すなわち, TSi 内の IP1 を IPN1 に置き換えます)。サーバーの端が NAT の背後にあると検出された場合, TSr ペイロード内の IP アドレスを, 受信した IKE パケットの宛先アドレスから取得した IP アドレスに置き換えます (すなわち, TSr 内の IPN2 を IP2 に置き換えます)。

このアドレス置換の後, トラフィック・セレクタと IKE UDP 送信元/宛先アドレスは同じように見え, サーバーはそれらの新しいトラフィック・セレクタに基づいて SPD 検索を行います。エントリが見つかり, それがトランスポート・モードを許可する場合, そのエントリが使用されます。エントリが見つかったがトランスポート・モードを許可しない場合, サーバーはアドレス置換を取り消して, 元のトラフィック・セレクタを使用して SPD 検索をやり直してもかまいません (MAY)。2 回目の検索が成功した場合, サーバーは, 他端から送信された実際のトラフィック・セレクタを使用してトンネル・モードで SA を作成します。

トランスポート・モードでのこのアドレス置換は, SPD がローカル・ホストが見るアドレスを使用して検索されるため必要です。これはまた, トンネル出口チェックおよび返送パケット用の Security Association Database (SAD) エントリが, ローカル・オペレーティング・システム・スタックが見るアドレスを使用して追加されることを保証します。

最も一般的なケースは, サーバーの SPD が任意のアドレスに一致するワイルドカード・エントリを含むことですが, これは異なる既知の NAT の外部アドレス用の異なる SPD エントリを作成することも許可します。

SPD 検索の後, サーバーは見つけた SPD エントリに基づいてトラフィック・セレクタの絞り込みを行います。それは再びすでに置換されたトラフィック・セレクタを使用するため, したがって IPN1 および IP2 を IP アドレスとして持つトラフィック・セレクタを返送します。それでもトラフィック・セレクタが使用するプロトコル番号またはポート範囲を絞り込むことはできます。Child SA 用に作成された SAD エントリは, サーバーが見るアドレス, すなわち IPN1 および IP2 を持ちます。

クライアントがサーバーからの Child SA への応答を受信すると, 同様の処理を行います。トランスポート・モード SA が作成された場合, クライアントは返送された元のトラフィック・セレクタを元の送信元および宛先アドレスとして格納できます。それはトラフィック・セレクタ内の IP アドレスを, IKE パケットの IP ヘッダからのアドレスに置き換えます: IPN1 を IP1 に, IP2 を IPN2 に置き換えます。次に, それは送信されたトラフィック・セレクタに対する SA の検証時, および SAD エントリのインストール時に, それらのトラフィック・セレクタを使用します。

トランスポート・モードの NAT トラバーサルの規則の要約は以下の通りです:

トランスポート・モードを提案するクライアントの場合:

  • TSi エントリは正確に 1 つの IP アドレスを持たなければならず (MUST), それは IKE SA の送信元アドレスと一致しなければなります (MUST)。
  • TSr エントリは正確に 1 つの IP アドレスを持たなければならず (MUST), それは IKE SA の宛先アドレスと一致しなければなります (MUST)。
  • 最初の TSi および TSr トラフィック・セレクタは, トリガー・パケットからのものなど, プロトコルおよびポート番号を含む非常に具体的なトラフィック・セレクタを持つべきです (SHOULD)。
  • 複数の TSi および TSr エントリがあってもかまいません (MAY)。
  • SA のトランスポート・モードが選択された場合 (すなわち, サーバーがその応答に USE_TRANSPORT_MODE 通知を含めた場合):
    • 元のトラフィック・セレクタを受信した送信元および宛先アドレスとして格納する。
    • サーバーが NAT の背後にある場合, TSi エントリ内の IP アドレスを IKE SA のリモート・アドレスに置き換える。
    • クライアントが NAT の背後にある場合, TSi エントリ内の IP アドレスを IKE SA のローカル・アドレスに置き換える。
    • これらのトラフィック・セレクタを, それらの元の内容を格納すること以外の用途に使用する前にアドレス置換を行う。これには, トラフィック・セレクタが他端によって正しく絞り込まれたことの検証, SAD エントリの作成などが含まれます。

レスポンダの場合, クライアントがトランスポート・モードを提案したとき:

  • アドレス置換の取り消しが必要な場合に備えて, [UDPENCAPS] で指定された「実際の送信元および宛先アドレス」として, および TCP/UDP チェックサム修正のために, 受信した元のトラフィック・セレクタ IP アドレスを送信元および宛先アドレスとして格納する。
  • クライアントが NAT の背後にある場合, TSi エントリ内の IP アドレスを IKE SA のリモート・アドレスに置き換える。
  • サーバーが NAT の背後にある場合, TSr エントリ内の IP アドレスを IKE SA のローカル・アドレスに置き換える。
  • ID および置換されたトラフィック・セレクタを使用して PAD および SPD 検索を行う。
  • SPD エントリが見つからない場合, または見つかった SPD エントリがトランスポート・モードを許可しない場合, トラフィック・セレクタ置換を取り消す。ID および元のトラフィック・セレクタを使用して PAD および SPD 検索を再度行い, 同時にトンネル・モード SPD エントリも検索する (すなわち, トンネル・モードへのフォールバック)。
  • ただし, トランスポート・モード SPD エントリが見つかった場合, 置換されたトラフィック・セレクタおよび SPD エントリに基づいて通常のトラフィック選択絞り込みを行う。SAD エントリの作成時, およびトラフィック・セレクタをクライアントに返送するときに, 結果のトラフィック・セレクタを使用する。