【手続補正書】
【提出日】平成15年11月12日(2003.11.12)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の名称】  トンネリングおよび補償を使用するネットワーク・アドレス翻訳によりセキュリティを与えるための方法および装置
【特許請求の範囲】
【請求項１】  中間コンピュータ装置（183、187、305）を備えるパケット交換データ伝送ネットワーク（184）を通じて第一のコンピュータ装置（181、イニシエータ）と第二のコンピュータ装置（185、レスポンダ）の間でパケットを安全に通信する方法であって、前記コンピュータ装置のうち少なくとも1つがネットワーク・アドレス翻訳および／またはプロトコル変換を行い、当該方法が、
前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で伝送されるパケットに、もしあるならば、どのようなネットワーク・アドレス翻訳が行われるかを決定するステップと、
行われると決定されたネットワーク・アドレス翻訳をトラバース可能にするために、第一のプロトコルに従うパケットを取り上げ（301）、これをカプセル化して（302）、ネットワーク・アドレス翻訳をトラバースできる第二のプロトコルに従うパケットにするステップと、
前記第二のプロトコルに従う前記パケットを前記第一のコンピュータ装置から前記第二のコンピュータ装置に伝送するステップと、
ネットワーク・アドレス翻訳のトラバースを可能にするためになされたカプセル化を無効にするために、前記第二のプロトコルに従う前記伝送されたパケットをカプセル除去して（303）、前記第一のプロトコルに従うパケットにする（304）ステップと、
を含むことを特徴とする、パケットを安全に通信する方法。
【請求項２】  第一のプロトコルに従うパケットを取り上げ（301）、これをカプセル化して（302）第二のプロトコルに従うパケットにする前記ステップが、
インターネット・プロトコルに従うパケット（401、402）を取り上げるサブステップと、
IPSECプロトコル・セットに従って前記パケットを処理するサブステップと、
前記処理されたパケットをカプセル化して、ユーザ・データグラム・プロトコルに従うパケット（401’、403、404）にするサブステップと、
を含むことを特徴とする、請求項1に記載の方法。
【請求項３】  第一のプロトコルに従うパケットを取り上げ（301）、これをカプセル化して（302）第二のプロトコルに従うパケットにする前記ステップが、
インターネット・プロトコルに従うパケットを取り上げるサブステップと、
IPSECプロトコル・セットに従って前記パケットを処理するステップと、
前記処理されたパケットをカプセル化して、伝送制御プロトコルに従うパケットにするステップと、
を含むことを特徴とする、請求項1に記載の方法。
【請求項４】  前記方法が、さらに前記第一のコンピュータ装置から前記第二のコンピュータ装置に伝送されるパケットにおいて前記第二のプロトコルについてネットワーク・アドレス翻訳を補償するステップを含むことを特徴とする、請求項1に記載の方法。
【請求項５】  ネットワーク・アドレス翻訳を補償する前記ステップが、もしあるならば、前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で伝送されるパケットにどのようなネットワーク・アドレス翻訳が行われるかを決定する前記ステップにおいて入手される情報に基づいてアドレス翻訳を行うステップを含むことを特徴とする、請求項4に記載の方法。
【請求項６】  ネットワーク・アドレス翻訳を補償する前記ステップが、もしあるならば、さらに、前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で伝送されるパケットにどのようなネットワーク・アドレス翻訳が行われるかを決定する前記ステップにおいて入手される情報に基づいてポート番号翻訳を行うステップを含むことを特徴とする、請求項5に記載の方法。
【請求項７】  前記方法が、さらに、前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で伝送されるパケットに対して行われるネットワーク・アドレス翻訳が同じものであり続けるようにするために、前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で周期的にキープアライブ・パケットを伝送する（306、307）ステップを含むことを特徴とする、請求項1に記載の方法。
【請求項８】  中間コンピュータ装置（183、187、305）を備えるパケット交換データ伝送ネットワーク（184）を通じて第一のコンピュータ装置（181、イニシエータ）と第二のコンピュータ装置（185、レスポンダ）の間で安全な通信接続を条件付きでセットアップするための方法において、前記コンピュータ装置のうち少なくとも1つがネットワーク・アドレス翻訳および／またはプロトコル変換を行い、該方法が、
前記第二のコンピュータ装置がある通信方法をサポートするか否かを確認する（201’、201’）ステップであり、該ステップにおいて、もしあるならば、前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で伝送されるパケットについてどのようなネットワーク・アドレス翻訳が行われるかが決定され、第一のプロトコルに従うパケットが取り上げられ、カプセル化されて、ネットワーク・アドレス翻訳をトラバースできる第二のプロトコルに従うパケットにされ、前記第二のプロトコルに従う前記パケットが前記第一のコンピュータ装置から前記第二のコンピュータ装置に伝送され、前記第二のプロトコルに従う前記伝送されたパケットがカプセル除去されて、前記第一のプロトコルに従うパケットにされる、ステップと、
前記第二のコンピュータ装置が前記の通信方法をサポートすることを示す確認のステップに応答して、前記第一のコンピュータ装置と前記第二のコンピュータ装置の間の安全な通信接続をセットアップするステップであり、前記通信接続において前記通信方法が採用されるステップと、
前記第二のコンピュータ装置が前記通信方法をサポートしないことを示す確認のステップに応答して、前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で前記通信方法の使用を禁止するステップと、
を含むことを特徴とする、請求項1記載の方法。
【請求項９】  中間コンピュータ装置（183、187、305）を備えるパケット交換データ伝送ネットワーク（184）を通じて第一のコンピュータ装置（181、イニシエータ）と第二のコンピュータ装置（185、レスポンダ）の間でパケットをトンネリングするための方法において、前記コンピュータ装置のうち少なくとも1つがネットワーク・アドレス翻訳および／またはプロトコル変換を行い、該方法が、
安全な通信プロトコルに従うパケットを交換することによって前記第一のコンピュータ装置と前記第二のコンピュータ装置の間に双方向トンネリング・モードを確立するステップと、
第一のプロトコルに従うパケットを取り上げ（301）、これを第一のコンピュータ装置においてカプセル化して（302）、ネットワーク・アドレス翻訳をトラバースできる第二のプロトコルに従うパケットにするステップと、
前記第二のプロトコルに従う前記パケットを前記第一のコンピュータ装置から前記第二のコンピュータ装置に伝送するステップと、
前記第二のコンピュータ装置において前記第二のプロトコルに従う前記伝送されたパケットをカプセル除去して（303）、前記第一のプロトコルに従うパケットにする（304）ステップと、
前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で伝送されるパケットについて行われたアドレス翻訳に関する情報を入手するステップと、
前記入手された情報を使って、前記第一のコンピュータ装置と前記第二のコンピュータ装置に確立された双方向トンネリング・モードを修正するステップと、
を含むことを特徴とする、請求項1記載の方法。
【請求項１０】  前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で伝送されるパケットについて行われたアドレス翻訳に関する情報を入手する前記ステップが、
前記第一のコンピュータ装置と前記第二のコンピュータ装置の間でヘッダ部分およびペイロード部分を含むパケットを伝送するサブステップと、
−前記ヘッダ部分において伝送されるネットワーク・アドレスにどのような変化が生じたか確認するために前記ペイロード部分において伝送されるネットワーク・アドレスを前記ヘッダ部分において伝送されるネットワーク・アドレスと比較するサブステップと、
を含むことを特徴とする、請求項9に記載の方法。
【請求項１１】  前記方法が、さらに、もしあるならば、前記第一のコンピュータと前記第二のコンピュータ装置の間で伝送されるパケットについて行われるネットワーク・アドレス翻訳が同じものであり続けるようにするために、前記第一のコンピュータ装置と前記第二のコンピュータ装置の間でキープアライブ・パケットを周期的に伝送する（306、307）ステップを含むことを特徴とする、請求項9に記載の方法。
【請求項１２】  前記入手された情報を使ってパケットのトンネリング操作を修正する前記ステップが、前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で伝送されるパケットについて行われるネットワーク・アドレス翻訳を補償するために、パケットのカプセル化（302）前にアドレス翻訳を導入するサブステップを含むことを特徴とする、請求項9に記載の方法。
【請求項１３】  前記入手された情報を使ってパケットのトンネリング操作を修正する前記ステップが、前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で伝送されるパケットについて行われるネットワーク・アドレス翻訳を補償するために、パケットのカプセル除去（303）後にアドレス翻訳を導入するサブステップを含むことを特徴とする、請求項9に記載の方法。
【請求項１４】  中間コンピュータ装置（183、187、305）を備えるパケット交換データ伝送ネットワーク（184）を通じて第一のコンピュータ装置（181、イニシエータ）と第二のコンピュータ装置（185、レスポンダ）の間でパケットをトンネリングするための方法であり、前記データ伝送ネットワークにおいて、キー管理パケットのために特定のパケット・フォーマットを採用するキー管理接続を備えるセキュリティ・プロトコルが存在し、該方法が、
−キー管理パケットではないデータ・パケットをキー管理パケットのための前記特定のパケット・フォーマットにカプセル化するステップと、
前記特定のパケット・フォーマットにカプセル化された前記データ・パケットを前記第一のコンピュータ装置から前記第二のコンピュータ装置に伝送するステップと、
前記第二のコンピュータ装置において、前記特定のパケット・フォーマットにカプセル化された前記データ・パケットを実際のキー管理パケットから区別するステップと、
前記特定のパケット・フォーマットにカプセル化された前記データ・パケットをカプセル除去するステップと、
を含むことを特徴とする、請求項1記載の方法。
【請求項１５】  キー管理パケットではないデータ・パケットをカプセル化する前記ステップが、
−キー管理パケットではないデータ・パケットを、特定のイニシエータ・クッキー・フィールドを定義するインターネット・キー交換プロトコルによって指定されるキー管理パケット・フォーマットにカプセル化するサブステップと、
−カプセル化されたデータ・パケットの前記イニシエータ・クッキー・フィールドに、前記カプセル化されたパケットがキー管理パケットではなくデータ・パケットであることを指示する値を挿入するサブステップと、
を含むことを特徴とする、請求項14に記載の方法。
【請求項１６】  キー管理接続を含むセキュリティ・プロトコルが存在し、前記方法が、
前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で伝送されるパケットについて、もしあるならば、どのようなネットワーク・アドレス翻訳が行われるかを決定し、前記セキュリティ・プロトコルに従って前記第一のコンピュータ装置と前記第二のコンピュータ装置の間にキー管理接続を確立し、共に前記第一のコンピュータ装置および前記第二のコンピュータ装置のネットワーク・アドレスを含むヘッダ部分およびペイロード部分を有するインディケータ・パケットを、前記パケットを構成するノードが見るとおりに構成し、前記キー管理接続内で前記インディケータ・パケットを送受し、受信したインディケータ・パケットにおいて前記ヘッダ部分に含まれるアドレスと前記ペイロード部分に含まれるアドレスを比較するステップと、
前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で安全にパケットを通信するために、決定されたネットワーク・アドレス翻訳の発生に関する情報を使用するステップと、
を含むことを特徴とする、請求項1記載の方法。
【請求項１７】  前記セキュリティ・プロトコルが、キー管理接続のための標準ポート番号を決定し、該方法がさらに、前記受信されたインディケータ・パケットにおいてソース・ポート番号をキー管理接続のための前記標準ポート番号と比較するステップを含むことを特徴とする、請求項16に記載の方法。
【請求項１８】  送受のためにパケットのトランスポート・モード処理を決定するセキュリティ・プロトコルが確認され、かつ該方法において、高レベル・プロトコル・チェックサムが受信パケットの無欠性をチェックするために決定されており、該方法が、
前記第一のコンピュータ装置において、前記第二のコンピュータ装置に伝送されるパケットのトランスポート・モード処理を行うステップと、
−前記第二のコンピュータ装置において、前記第一のコンピュータ装置から受信されるパケットのトランスポート・モード処理を行うステップであり、前記トランスポート・モード処理が受信パケットのカプセル除去を含む、ステップと、
前記第二のコンピュータ装置において、ネットワーク・アドレス翻訳によって変化が生じた場合にはこれを補償するためにカプセル除去されたパケットの高レベル・チェックサムをアップデートするステップと、
を含むことを特徴とする、請求項1記載の方法。
【請求項１９】  前記方法において、
前記第一のコンピュータ装置において前記第二のコンピュータに伝送されるパケットのトランスポート・モード処理を行う前記ステップが、IPSECプロトコル・セットにおいて決定されるトランスポート・モード処理を行う形をとり、
−前記第二のコンピュータ装置において前記第一のコンピュータ装置から受信されるパケットのトランスポート・モード処理を行う前記ステップが、IPSECプロトコル・セットにおいて決定されるトランスポート・モード処理を行う形をとる、
ことを特徴とする、請求項18に記載の方法。
【請求項２０】  前記方法が、さらに、
前記第一のコンピュータ装置において、前記第二のコンピュータ装置に伝送されるパケットのトランスポート・モード処理を行った後に、前記処理済みのパケットをカプセル化して、ネットワーク・アドレス翻訳をトラバースできる第二のプロトコルに従うパケットにするステップと、
−前記第二のコンピュータ装置において、前記第一のコンピュータ装置から受信されるパケットのトランスポート・モード処理を行う前に、前記第二のプロトコルに従うパケットから受信パケットをカプセル除去して、カプセル除去されたパケットの中の多数のネットワーク・アドレスを、カプセル除去前に受信パケットから得られた対応する数のネットワーク・アドレスと置き換えるステップと、
を含むことを特徴とする、請求項18に記載の方法。
【請求項２１】  高レベル・プロトコル・チェックサムを更新する前記ステップが、トランス・モード処理されたパケットのチェックサムを再計算する形をとることを特徴とする、請求項18に記載の方法。
【請求項２２】  前記方法が、さらに、ネットワーク・アドレス翻訳の前後に前記第一および第二のコンピュータ装置のネットワーク・アドレスに関する情報を入手するステップを含み、かつ高レベル・プロトコル・チェックサムを更新する前記ステップが、ネットワーク・アドレス翻訳の前後に前記第一および第二のコンピュータ装置のネットワーク・アドレスに関して入手された前記情報に基づいてチェックサムを増分更新する形をとることを特徴とする、請求項18に記載の方法。
【請求項２３】  パケット交換データ伝送ネットワーク（184）を通じて第一のコンピュータ装置（181、イニシエータ）と第二のコンピュータ装置（185、レスポンダ）の間で特定のアドレス情報と一緒に伝送されるカプセル化された実際のデータ・パケットに対してネットワーク・アドレス翻訳装置が行うアドレス翻訳の不変の形式を維持するための方法であり、該方法が、
−たとえ前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で通信されるパケットの一部がネットワークにおいて紛失しても、ネットワーク・アドレス翻訳装置が一貫してネットワーク・アドレス翻訳（305）のために使用されるマッピングを再使用するように、前記第一のコンピュータ装置および前記第二のコンピュータ装置のうち少なくとも一方が、十分に高い頻度で実際のデータ・パケットのアドレス情報と同一のアドレス情報と一緒にキープアライブ・パケットを他方のコンピュータ装置に伝送するようにするステップ、
を含むことを特徴とする、請求項1記載の方法。
【請求項２４】  中間コンピュータ装置（183、187、305）を備えるパケット交換データ伝送ネットワーク（184）を通じて第一のコンピュータ装置（181、イニシエータ）から第二のコンピュータ装置（185、レスポンダ）にパケットを安全に送信する方法であって、前記コンピュータ装置のうち少なくとも1つがネットワーク・アドレス翻訳および／またはプロトコル変換を行い、当該方法が、
前記第一のコンピュータ装置から前記第二のコンピュータ装置に送信されるパケットに、もしあるならば、どのようなネットワーク・アドレス翻訳が行われるかを決定するステップと、
行われると決定されたネットワーク・アドレス翻訳をトラバース可能にするために、第一のプロトコルに従うパケットを取り上げ（301）、これをカプセル化して（302）、ネットワーク・アドレス翻訳をトラバースできる第二のプロトコルに従うパケットにするステップと、
前記第二のプロトコルに従う前記パケットを前記第一のコンピュータ装置から前記第二のコンピュータ装置に伝送するステップと、
を備えることを特徴とする、パケットを安全に送信する方法。
【請求項２５】  中間コンピュータ装置（183、187、305）を備えるパケット交換データ伝送ネットワーク（184）を通じて第一のコンピュータ装置（181、イニシエータ）から第二のコンピュータ装置（185、レスポンダ）にパケットを安全に受信する方法であって、前記コンピュータ装置のうち少なくとも1つがネットワーク・アドレス翻訳および／またはプロトコル変換を行い、当該方法が、
前記第一のコンピュータ装置と前記第二のコンピュータ装置の間で送信されるパケットに、もしあるならば、どのようなネットワーク・アドレス翻訳が行われるかを決定するステップと、
ネットワーク・アドレス翻訳をトラバースできる第二のプロトコルに従うパケットを前記第一のコンピュータ装置から前記第二のコンピュータ装置に受信するステップと、
−ネットワーク・アドレス翻訳のトラバースを可能にするためになされたカプセル化（302）を無効にするために、前記第二のプロトコルに従う前記送信されたパケットをカプセル除去して（303）、前記第一のプロトコルに従うパケットにする（304）ステップと、
を備えることを特徴とする、パケットを安全に受信する方法。
【発明の詳細な説明】
〔技術分野〕
【０００１】
本発明は、一般的に言ってパケット交換データ伝送ネットワークにおけるコンピュータ間の安全な通信の分野に関するものである。より明確に言うと、本発明は、ネットワーク・アドレス翻訳またはプロトコル変換を通じて安全な通信をセットアップし維持する分野に関するものである。
〔背景技術〕
【０００２】
インターネット技術特別調査委員会（IETF）は、IPSEC（インターネット・プロトコル・セキュリティ）プロトコル・セットを標準化した。この規格は、付属参照文献リストに記載されるリクエスト・フォー・コメンツすなわちRFC文書番号RFC2401、RFC2402、RFC2406、RFC2407、RFC2408およびRFC2409から周知である。IPSECプロトコルは、RFC文書番号RFC791において規定されるIPすなわちインターネット・プロトコルにセキュリティを与える。IPSECは、新規のIPヘッダを生成し、パケットの前に認証ヘッダ（AH）またはカプセル化セキュリティ・ペイロード（ESP）ヘッダを付加することによって、パケット・レベルで認証および暗号化を行う。オリジナルのパケットは、暗号的に認証され、任意に暗号化される。パケットの認証および任意の暗号化に使用される方法は、AHおよびESPヘッダにおいて記憶されるセキュリティ・パラメータ・インデクス（SPI）値によって識別される。RFC文書番号RFC2401は、パケットのトランスポート・モードおよびトンネリングモードを規定している。本発明は、どちらのモードが使用されるかに関わりなく、応用可能である。
【０００３】
近年、ネットワーク・アドレス翻訳（NAT）を開始するベンダおよびインターネット・サービス・プロバイダが増えている。NATについて、少なくともRFC文書番号RFC1631並びに付属の参照文献リストにおいてSrisuresh98Terminology、SrisureshEgevang98、Srisuresh98Security、HoldregeSrisuresh99、TYS99、Rekhter99、LoBorella99およびBorellaLo99として明示される文書において言及されている。図1aおよび1bにおいてアドレス翻訳の主要な2つの形式が図解的に示されている。すなわちホストNAT 101およびポートNAT 151である。ホストNAT 101は、入パケット102のIPアドレスを単に翻訳するだけなので、出パケット103は別のIPアドレスを持つ。ポートNAT 151は、入パケット152のTCPおよびUDPポート番号（トラフィック制御プロトコル、ユーザ・データグラム・プロトコル）も処理して、出パケット153においていくつかのIPアドレスを単一のIPアドレスに多重化し、これに応じて、反対方向に向かうパケットについては単一IPアドレスをいくつかのIPアドレスにデマルチプレクスする（図には示されていない）。ポートNATは、特に、家庭内および小さなオフィス環境においては一般的である。NAT装置の入力接続と出力接続の物理的な分離は、図1aおよび1bにおいて図解を明確にするためにのみ示されている。実際には、物理的にNATを接続するために可能な方法は多様にある。
【０００４】
アドレス翻訳は、ローカル・ネットワークのエッジにおいて行われることがもっとも多い（すなわち、複数のローカル・プライベート・アドレスともっと少数の大域ルータブル・パブリック・アドレスの間の翻訳）。ポートNATが使用されて、大域ルータブル・アドレスが1つしかないことが、最も多い。ローカル・ネットワーク154は、図1bにおいて図解的に示されている。このような構成は、家庭内および小規模なオフィス市場において非常に一般的になって来ている。一部のインターネット・サービス・プロバイダは、カスタマにプライベート・アドレスを与え始めており、これらのアドレスのために自社のコア・ネットワークにおいてアドレス翻訳を行っている。一般的に言って、ネットワーク・アドレス翻訳は、インターネット技術特別調査委員会内部において例えばNAT作業委員会において広範に詳細に論じられてきた。NAT装置の動作原理は周知であり、無料で入手できるソース・コードのインプリメンテーションを含めて、複数のベンダから多数のインプリメンテーションを市場で入手できる。NATの典型的な動作は、IPアドレスとポートの組み合わせを別のIPアドレスとポートの組み合わせにマッピングするものとして説明できる。マッピングは、1回のネットワーク接続中一定であるが、時間とともに（ゆっくりと）変化するかもしれない。実際には、NATの機能は、ファイヤウォールまたはルータに組み込まれることが多い。
【０００５】
図1cは、送信ノード181が（第一のプライベート・ネットワークとしても知られている）第一のローカル・エリア・ネットワーク１８２に配置され、このネットワークがインターネットなど広域一般パケット交換ネットワーク184に接続するためにポートNAT 183を有するという、実際のネットワーク通信の状況例を示している。広域一般パケット交換ネットワークは、さまざまな方法で相互接続された非常に多数のノードによって構成される。受信ノード185は、同様にNAT 187を通じて広域ネットワークに結合される第二のローカル・エリア・ネットワークに配置される。ネットワーク・セキュリティ・サービスをセットアップするために必要な通信は双方向的なので、「送信ノード」および「受信ノード」という名称は多少誤解を招きやすい。送信ノードは通信を開始するノードである。送信ノードおよび受信ノードの代わりにそれぞれ「イニシエータ」および「レスポンダ」という用語も使用される。
【０００６】
図1cの目的は、通信ノードが、それが通信する際に使われる中間装置の数や性質も、また行われる変換の性質も意識しないという事実を強調することにある。NATの他に、インターネット上には、パケットが伝送されるときパケットを合法的に修正するその他のタイプの装置がある。その典型的な例はプロトコル・コンバータであり、その主な仕事は、通常の動作を妨害することなくパケットを異なるプロトコルに変換することである。これを使用すると、NATの場合と非常によく似た問題を引き起こす。かなり単純だが重要な例は、インターネット・プロトコルの異なるバージョンであるIPv4とIPv6の間の変換である。この種のコンバータは、近い将来非常に重要なありふれたものになるだろう。パケットはその伝播中にこの種のいくつかの変換を経て、通信の終点では実際に異なるプロトコルを使用する可能性がある。NATのように、プロトコル変換はルータおよびファイヤウォールで行われることがしばしばある。
【０００７】
IPSEC界では、IPSECプロトコルがネットワーク・アドレス翻訳を通すとうまく機能しないことは周知である。この問題については、少なくともHoldregeSrisuresh99およびRekhter99として示される参照文献において論じられている。
【０００８】
参照のために本明細書に組み込まれるフィンランド特許出願第974665号および対応PCT出願第FI98/01032号において、当該出願者は、IPSECアドレス翻訳を行うためのある種の方法およびパケットのルートにおいてアドレス変換およびプロトコル変換に対して無反応なパケット認証方法を提示した。さらに、前記出願において、当該出願者は、上記の方法を利用することができる送信ネットワーク装置および受信ネットワーク装置を提示した。しかし、ネットワーク・アドレス翻訳を通じてネットワーク・セキュリティ・サービスを提供する際のいくつかの問題点は、前記の以前の特許出願においては未解決のままである。
米国特許第57933763号はＮＡＴの原理にしたがってローカルＩＰアドレスを広域のユニークなＩＰアドレスに翻訳するシステム及び方法を提供している。インターネットから到来するパケットはアダプティブ・セキュリティ・アルゴリズム(adaptive security algorithm)により選別される。
国際公開WO-A-98/32065号は、保護されたクライアントとネットワークとの間にネットワーク・セキュリティ・デバイスがどのように接続されるかを示している。ネットワーク・セキュリティ・デバイスは任意の他のクライアントと暗号キーについて交渉をする。セキュリティ・デバイスはパケットをネットワークに送信する前及びネットワークからパケットを受信後に、クライアントのアドレスとそれ自身のアドレスとの間でアドレス翻訳を行う。
さらなる先行技術は、次の通りである。DATA COMMUNICATIONS, MCGRAW HILL, NEW YORK, US, Journal Article, Vol. 26, Nr. 16, November 97, pages 55-59, Rodney Thayer: “Bulletproof IP with authentication and encryption, IPSec adds a layer of armor to IP”; IEEE, COMPUTER, Vol. 31, Issue 9, September 1998, pages 43-47, Rolph Oppliger: “Security at the Internet Layer”, ISSN: 0018-9162; IETF, Internet Draft, 06.02.98, R.G. Moskowitz: “Network Address Translation issues with IPsec”, <URL:http://www.alternic.org/drafts/drafts-m-n/draft-moskowitz-net66-vpn-00.txt>; IETF, Internet Draft, 22.08.97, R.G. Moskowitz: “Network Address Translation issues with IPsec”, <URL:http://www.alternic.org/drafts/drafts-m-n/draft-moskowitz-net66-vpn-nat-00.txt>; and IETF, Internet Draft, 04.98, G. Tsirtis: “AATN Components & Mechanism”, <URL:http://www.alternic.org/drafts/drafts-t-u/draft-tsirtsis-aatn-mech-00.txt>. これらはパケット・データ・ネットワークにおけるＮＡＴの様々な知られた態様と確実な送信を記載している。
〔発明の開示〕
〔発明が解決しようとする課題〕
【０００９】
信頼でき有利な方法でネットワーク・アドレス翻訳を通じてネットワーク・セキュリティ・サービスを提供するための方法および対応する装置を提供することが、本発明の目的である。
〔課題を解決するための手段〕
【００１０】
従って、本発明の第一の態様に従って、中間コンピュータ装置を備えるパケット交換データ伝送ネットワークを通じて第一のコンピュータ装置と第二のコンピュータ装置の間でパケットを安全に通信するための方法が提供される。この方法において、前記コンピュータ装置のうち少なくとも1つがネットワーク・アドレス翻訳および／またはプロトコル変換を行う。この方法は：
第一のコンピュータ装置と第二のコンピュータ装置の間で伝送されるパケットに、もしあるならば、どのようなネットワーク・アドレス翻訳が行われるかを決定するステップ；
行われると決定されたネットワーク・アドレス翻訳をトラバース可能にするために、第一のプロトコルに従うパケットを取り上げ、これをカプセル化して、ネットワーク・アドレス翻訳をトラバースできる第二のプロトコルに従うパケットにするステップ；
前記第二のプロトコルに従う前記パケットを第一のコンピュータ装置から第二のコンピュータ装置に伝送するステップ；および
ネットワーク・アドレス翻訳のトラバースを可能にするためになされたカプセル化を無効にするために、前記第二のプロトコルに従う前記伝送されたパケットをカプセル除去して、前記第一のプロトコルに従うパケットにするステップを備えることを特徴とする。
【００１１】
本発明の第二の態様に従って、中間コンピュータ装置を備えるパケット交換データ伝送ネットワークを通じて第一のコンピュータ装置から第二のコンピュータ装置に安全にパケットを送信する方法が提供される。この方法は、前記コンピュータ装置のうち少なくとも1つがネットワーク・アドレス翻訳および／またはプロトコル変換を行う。この方法は：
第一のコンピュータ装置から第二のコンピュータ装置に伝送されるパケットに、もしあるならば、どのようなネットワーク・アドレス翻訳が行われるかを決定するステップ；
行われると決定されたネットワーク・アドレス翻訳をトラバース可能にするために、第一のプロトコルに従うパケットを取り上げ、これをカプセル化して、ネットワーク・アドレス翻訳をトラバースできる第二のプロトコルに従うパケットにするステップ；および
前記第二のプロトコルに従う前記パケットを第一のコンピュータ装置から第二のコンピュータ装置に伝送するステップを備えることを特徴とする。
【００１２】
本発明の第三の態様に従って、中間コンピュータ装置を備えるパケット交換データ伝送ネットワークを通じて第一のコンピュータ装置から第二のコンピュータ装置にパケットを安全に受信するための方法が提供される。この方法において、前記コンピュータ装置のうち少なくとも1つがネットワーク・アドレス翻訳および／またはプロトコル変換を行う。この方法は：
【００１３】
第一のコンピュータ装置と第二のコンピュータ装置の間に伝送されるパケットに、もしあるならば、どのようなネットワーク・アドレス翻訳が行われるかを決定するステップ；
【００１４】
第一のコンピュータ装置から、第二のコンピュータ装置に、ネットワーク・アドレス翻訳をトラバースすることが可能な第二のプロトコルに従うパケットを受信するステップ；および
ネットワーク・アドレス翻訳のトラバースを可能にするためになされたカプセル化を無効にするために、前記第二のプロトコルに従う送信されたパケットを、前記第一のプロトコルに従うパケットにカプセル除去するステップを備えることを特徴とする。
〔発明を実施するための最良の形態〕
【００１５】
本発明は、新規な発明的方法でUDP、IKEおよびIKE拡張メカニズムを通じてトンネリングするネットワーク・アドレス翻訳の方法をいくつか組み合わせ、これらを拡張して、ネットワーク・アドレス翻訳およびプロトコル変換を通じて安全に通信する方法を提供する。この方法は、完全に自動的でユーザに対してトランスペアレントにすることができる。
【００１６】
本発明の応用可能性に関するキーポイントは、本特許出願の優先日においては、一般的に言ってTCP（RFC793において説明されている）およびUDP（RFC768において説明されている）のみがNATに対して機能していることである。なぜなら、実際に使用されるNATのほとんどがポートNATであり、これが大域ルータブルIPアドレスの不足に関してもっとも有益なNATの形式である。しかしながら、本発明は本特許出願の優先日に既知であるUDPおよびTCPの使用に限定されない。一般的に言えば、UDPおよびTCPは、アドレス変換プロセスにおいて別の形式にマッピングされる接続識別情報（すなわちアドレス指定およびポート番号指定）を決定するプロトコルの例であるといえる。他の種類の通信プロトコルおよびアドレス変換が将来出現するものと思われる。
【００１７】
本発明のさまざまな態様は下記のことに関連する：
-本発明に従って典型的な安全な通信方法である特定の方法をリモート・ホストがサポートするか否かの決定（「方法のサポート」態様）；
-パケットがある場合に、パケットについてどのようなネットワーク・アドレス翻訳および／またはプロトコル変換が行われるかの決定（「翻訳の発生」態様）；
-パケットがNATを考察するように、特定の慎重に選択されたプロトコル、典型的にはUDPの内部でのパケットのトンネリング（「選択されたトンネリング」態様）；
-関与するNAT装置およびマッピングのためにタイムアウトを使用するその他の装置が通信ホストのためのマッピングを損失しないようにするための、キープアライブ方法の使用（「キープアライブ」態様）；
-AHパケットについてメッセージ認証コードを確認する前に行われる翻訳の補償（「補償/認証」態様）；および
-複数のホストが単一のパブリック・アドレスにマッピングされることを補償するための、送信ノードまたは受信ノードにおけるアドレス翻訳の実施（「補償/マッピング」態様）。
【００１８】
異なる論理ネットワークを通じて伝送するためにデータ・パケットをカプセル化するプロセスは、トンネリングと呼ばれる。一般には、IPプロトコルの場合、トンネリングには、オリジナルのパケットの前に新しいIPヘッダを付加すること、新しいヘッダにおいて適切にプロトコル・フィールドを設定することおよびパケットを目標の宛先（トンネルの終点）に送ること、が含まれる。オリジナルのパケットに関する十分な量の情報がこのプロセスにおいて保存されて、トンネルの終わりのパケットをトンネルの始めのオリジナルのパケットと十分に類似する形式に再構成できる限り、トンネリングは、オリジナルのパケットのヘッダ・フィールドを修正してまたはこれを異なるヘッダと置き換えることによっても、実現することができる。パケットと一緒に送る必要のある情報の正確な量はネットワーク・プロトコルによって左右され、情報は、明示的（トンネリングされるパケットの一部として）でも暗示的（決定されるコンテキストにより、例えば、事前に伝送されるパケットまたはトンネリングされるパケットにおけるコンテキスト識別子により）でも送ることができる。
【００１９】
ネットワークを通じてパケットをトンネリングする方法は技術上既知である。少なくともRFC1226、RFC1234、RFC1241、RFC1326、RFC1701、RFC1853、RFC2003、RFC2004、RFC2107、RFC2344、RFC2401、RFC2406、RFC2473およびRFC2529は、トンネリングのテーマを扱っている。例えば、RFC1234は、UDPを通じてIPXフレームをトンネリングする方法を提示している。この方法においては、パケットは、固定UDPポートおよびデキャプスレータのIPアドレスにトンネリングされる。
【００２０】
背景説明において言及されたIPSECプロトコルは、一般に通信当事者を相互に認証し、通信当事者のみに既知の共有の秘密を導出し、通信のために使用される認証および暗号化方法を取り決め、通信のために使用されるセキュリティ・パラメータ・インデクス（SPI）値および1組のセレクタについて合意するために、インターネット・キー交換すなわちIKEプロトコル（参照文献RFC2409、RFC2408およびRFC2407から既知）を使用する。IKEプロトコルは、以前はISAKMP/Oakleyとして知られていた。ISAKMPは、インターネット・セキュリティ・アソシエーション・キー管理プロトコルの略である。IKE標準において規定される通常のネゴシエーションの他に、IKEは、拡張のための特定のメカニズムをサポートする。参照文献RFC2408から既知であるベンダIDペイロードは、相手方が特定のプライベート拡張メカニズムをサポートするか否かを通信当事者が決定できるようにする。RFC2407として知られるIPSEC DOI（解釈のドメイン）は、この種のプライベート拡張のために特定の数値を確保する。
【００２１】
現在、周知のベンダIDは、図2aに示されるフォーマットを持つものとして定義される。ここで、カラム番号はビット・ポジションに一致する。本発明においては、ベンダIDフィールド201は、ベンダIDペイロードの一番重要な部分である。IKEプロトコルにおいては、リモート・ホストが安全なネットワーク通信を提供するための特定の方法をサポートするか否かのネゴシエーションは次のように行うことができる。ここで使用される用語は、IKEドキュメントから借用したものである。
【００２２】
IKEプロトコルは、イニシエータ（すなわち、相手側にパケットを最初に送信するノード）とレスポンダ（すなわちパケットを最初に受信するノード）の間の相互メッセージ交換のいわゆるフェーズ1を決定する。図3は、イニシエータとレスポンダの間の最初のフェーズ1メッセージの交換を図解している。本発明の「方法のサポート」態様に従えば、両方の装置は、特定のフェーズ1メッセージの中に特定のベンダIDペイロードを含み、これがその最初のフェーズ1メッセージであることが、もっとも有利である。このペイロードは、両方の装置が問題の方法をサポートすることを指示する。
【００２３】
図3において、イニシエータの最初の（またはその他の）フェーズ1メッセージに含まれるベンダIDフィールドは、図解的に201’として示されており、レスポンダの最初の（またはその他の）フェーズ1メッセージに含まれるベンダIDフィールドは、図解的に201''として示されている。特定の方法のサポートを示すために、ベンダIDペイロードの中のベンダIDフィールドは、基本的にその方法の識別子である。これは、例えば“SSH IPSEC NAT Traversal Version 1”など後端のゼロまたは改行のない以前から既知の識別ストリングのMD5ハッシュであることが、有利である。任意の文字シーケンスのMD5ハッシュの生成は、例えば参照文献リストに記載される刊行物RFC1321から技術上既知である。
【００２４】
次に、本発明の「翻訳の発生」態様について説明する。上記のフェーズ1に加えて、IKEプロトコルは、イニシエータとレスポンダの間の相互メッセージ交換のいわゆるフェーズ2を決定する。本発明の「翻訳の発生」態様に従えば、当事者は、特定のフェーズ2クイック・モード・メッセージのプライベート・ペイロードにおいて当事者が見るIPアドレスを含めることにより、どの翻訳が行われるかを決定することができる。フェーズ2クイック・モード・メッセージは最初のフェーズ2クイック・モード・メッセージであることが、有利である。このようなプライベート・ペイロードの使用を表すためにプライベート・ペイロード番号範囲のどのような未使用の番号でも使用することができる（例えば、本特許出願の優先日の時点では未使用の157）。
【００２５】
翻訳の発生を明らかにするために使用されるプライベート・ペイロードは、例えば、図2bに示されるフォーマットを持つことができる。フィールド211は、フィールド212および213に示されるアドレスのタイプを識別するタイプ・コードを含んでいる。フィールド212は、メッセージを送るノードが見るとおりのイニシエータのアドレスを含んでおり、フィールド213は、メッセージを送るノードが見るとおりのレスポンダのアドレスを含んでいる。図3は、イニシエータとレスポンダの間の（最初の）フェーズ2クイック・モード・メッセージの交換を示しているので、対応するフィールド211’、212’および213’は前者によって送られるメッセージに含まれており、フィールド211’’、212’’および213’’は後者によって送られるメッセージに含まれている。
【００２６】
既知の慣行に従って、イニシエータおよびレスポンダのアドレスは図2bのペイロードを含んでいるパケットのヘッダにも含まれる。ヘッダにおいて、これらのアドレスはアドレス翻訳およびその他の処理の影響を受けるが、プライベート・ペイロードにおいてはこの影響を受けない。図2bのペイロードを含むパケットが受信されると、ペイロードに含まれるアドレスは、パケット・ヘッダに含まれるアドレスと比較される。これが異なる場合、パケットにアドレス翻訳が行われたことになる。後に、本発明の応用と一緒に標準IKEポート番号500の使用について触れる。翻訳の発生を検出する付加的方法として、受信パケットのポート番号を標準IKEポート番号と比較して、ポート翻訳が行われたか否かを決定することができる。
【００２７】
アドレスを処理する際にかなり重要な点は、後で使用するためにパケットのUDPソース・ポートを保存できることである。通常であれば、これは、フェーズ1 ISAKMPセキュリティ・アソシエーションのためにデータ構造と一緒に保存され、フェーズ2 IPSECセキュリティ・アソシエーションのために補償処理をセットアップするために使用される。
【００２８】
上に説明される方法を本発明の「翻訳の発生」態様を実現するために使用するためには、ホストは、そのフェーズ2識別ペイロードを修正しなければならない。すなわち、図2bに示されるペイロードは、既存の標準においては未知である。1つの可能性は、ペイロードをID_IPV4_ADDRおよびID_IPV6_ADDRタイプに制限することである。これは、ホスト間動作に適するであろう。
【００２９】
次に、本発明の「トンネリングの選択」、「補償/認証」および「補償/マッピング」態様について説明する。本発明のこの態様に従えば、実際のデータ・パケットを通信接続のセキュリティ機構をセットアップするために使用されるのと同じ接続、例えばIKEに使用されるUDP接続を通じてトンネリングすることができる。これによって、実際のデータ・パケットは、翻訳が決定されたときIKEパケットが受けたのと同じ翻訳を受けることができる。IKEについて標準ポート番号500が決定されたとすると、これは、全てのパケットが、ソース・ポート500および宛先ポート500で送られることになり、カプセル化されたデータを含んでいるパケットから実IKEパケットを区別するための方法が必要となる。これを行う1つの可能な方法は、実IKEパケットに使用されるIKEヘッダがイニシエータ・クッキー・フィールドを含んでいるという事実を利用することである。すなわち、本発明のこの態様をサポートするイニシエータは決してその最初の4つのバイトが全てゼロであるクッキーを生成しない、と規定することができる。そうすると、該当する4つのバイトにおける値ゼロは、パケットをトンネリングされたデータ・パケットとして認識するために使用される。このようにして、トンネリングされたデータ・パケットは、UPDペイロードの始めに4つのゼロ・バイトを持つが、実IKEパケットはこれを持たない。
【００３０】
図4は、伝送のために実際のIPSECパケットをUPDにカプセル化するところを示している。基本的に、UDPヘッダ403および短い中間ヘッダ404は、すでにパケットの中にあるIPヘッダ401の後に挿入されている（プロトコル・フィールドは中間ヘッダにコピーされている）。IPヘッダ401は小修正されて、修正IPヘッダ401’となる。IPペイロード402はそのままである。左側のカプセル化されていないIPSECパケットの単純な図解を誤解してはならない。このパケットは、プレーンテキストではなく、UDPにカプセル化される前に送信ノードにおいてAHまたはESPまたはその他の対応する変換プロトコルに従ってすでに処理されている。
【００３１】
一般性を制限することなく、本明細書における提示においては、図4に従ったカプセル化は常にIPSEC処理を行う同じノード（終点ノードかVPN装置）によって行われると、仮定される。また、IPSECパケットをUDPにカプセル化する代わりに、これをTCPにカプセル化できることにも留意しなければならない。この代替方法の場合には、TCPプロトコルにおいて規定されるとおり最初のパケットがSYNビットを持ち最後のパケットがFINビットを持つように、偽（fake）・セッション開始および終了を使用する必要があるだろう。
【００３２】
図4に従って実際のデータ・パケットまたは「データグラム」をカプセル化する際、オリジナルのIPヘッダ401（RFC971において定義される）は、下記のとおり修正済みIPヘッダ401’を生成するように修正される：
*IPヘッダのプロトコル・フィールド（別個に図示されていない）は、RFC768に従ってUDPのためのプロトコル17に置き換えられる。
*IPヘッダの全長フィールド（別個に図示されていない）は、UDPおよび中間ヘッダの結合サイズ（合計16バイト）だけ増加される。
*IPヘッダのヘッダ・チェックサム・フィールド（別個に図示されていない）はRFC791に示されるルールに従って再計算される。
【００３３】
図4に示されるとおり、UDPヘッダ403（RFC768において定義される）および中間ヘッダは、IPヘッダの後に挿入される。UDPヘッダは8オクテット、中間ヘッダは8オクテットであり、合計で16オクテットである。これらのヘッダは、以下の論証において1つのものとして扱われる。結合ヘッダは、図2cに図解されるフォーマットを持つことが、もっとも有利である。このヘッダのフィールドは、以下のとおりに設定される：
*ソース・ポート・フィールド221は、500（IKEと同じ）に設定される。パケットがNATを経る場合、パケットが受信されるときこれが異なる可能性がある。
*宛先ポート・フィールド222は、相手側がパケットを送っていると思われるポート番号に設定される。パケットがNATを経る場合、受け手は異なるポート番号を見る可能性がある。
*UDP長さフィールド223はUDPヘッダの長さプラスUDPデータ・フィールドの長さである。この場合、このフィールドは、中間ヘッダも含む。値は、バイトで、16プラス、オリジナルのIPパケット・ペイロードとして計算される（オリジナルのIPヘッダは含まず、これはIPヘッダの長さフィールドに含まれる）。
*UDPチェックサム・フィールド224は、0に設定されることが、もっとも有利である。UDPチェックサムは、任意であり、このトンネリング・メカニズムを使ってこれを計算またはチェックしようとは、出願者は考えていない。データの無欠性は、トンネリングされるパケット内のAHまたはESPヘッダによって保護されると想定される。
*マスト・ビー・ゼロ・フィールド225：このフィールドは、事前に合意された固定値を含まなければならず、この値は全てゼロであることが、もっとも有利である。このフィールドは、実際のIKEヘッダにおけるイニシエータ・クッキー・フィールドの最初の4バイトとオーバーラップする。本発明のこの態様をサポートするイニシエータは、最初の4つのバイトがゼロであるクッキーを使用してはならない。このゼロのバイトは、トンネリングされたパケットを実ISAKMPパケットから分離するために使用される。当然、「全てゼロ」以外の他の固定を選択することは可能であるが、値は、この特定の用途について固定されなければならない。
*プロトコル・フィールド226：このフィールドの値は、オリジナルのIPヘッダにおける既知のプロトコル・フィールド（図4には示されていない）からコピーされる。
*予約フィールド227：全てゼロとして送られることが、もっとも有利である。受信時には無視される。
【００３４】
送り手は、NATの背景で宛先にトンネリングされるあらゆるパケットにこのヘッダを挿入する。NATが使用されるか否かについての情報は、ポリシー・マネージャにおいてSA（セキュリティ・アソシエーション）ごとに記憶することができる。図4において言及されるカプセル化は、新規の変換としてまたは既知のAHおよびESP変換の一部として実施することができる。
【００３５】
カプセル化操作は、IKEネゴシエーション中に決定されるリモート・ホストのIPアドレスおよびUDPポート番号を使用する。
【００３６】
受け手は、AHまたはESP処理を行う前にこのカプセル化されたパケットをカプセル除去する。カプセル除去は、このヘッダを取り除いて、IPヘッダのプロトコル・フィールド、長さフィールドおよびチェックサム・フィールドを更新する。構成データ（ポート番号など）はこの操作を必要としない。
【００３７】
カプセル除去は、以下のセレクタの全てが合致する場合しか行う必要はない：
*宛先アドレスがこのホストの宛先アドレスであり、
*ソース・アドレスがこのホストがこのトンネリングのために使用する相手として合意したホストのアドレスであり、
*プロトコル・フィールドがUDPを指示しており、
*宛先ポート・フィールドの値が500であり、かつ
*ソース・ポート・フィールド値が、このホストがこのトンネリングを使用する相手として合意したポートを指示している（このトンネリングは複数のソース・アドレスおよびポートのために行われる場合があることに注意すること。その各々が別個のセレクタ・セットによって処理される）。
【００３８】
カプセル除去中、受信パケットの中のソース・アドレスを、IKEネゴシエーション中受信される実ソース・アドレスと置き換えることができる。これは、AH MAC確認の補償を実現する。アドレスは、下に説明する事後処理段階において再び変更される。この補償により、標準AHおよびESP変換を無修正で使用することができる。
【００３９】
図3において、送信ノードにおけるAH/ESP処理は、図解的にブロック301として示されており、データグラムのUDPへのカプセル化は、図解的にブロック302として示され、データグラムのUDPからのカプセル除去は、図解的にブロック303として示され、受信ノードにおけるAH/ESP処理は、図解的にブロック304として示されている。
【００４０】
パケットがAHまたはESPからカプセル除去された後に付加的補償が行われなければならない。この付加的カプセル除去は、アウター・パケットは実際にはNATを経ている（図3においては図解的にブロック305として示される）ので、プレーンテキスト・パケットも同様の変換を経なければならないという事実に関係している。受け手は、NAT装置のアドレスをオリジナルの内部アドレスとしてではなくホストのアドレスとして見なければならない。その代わりに、パケットをAHまたはESPにカプセル化する前に、この補償をパケットの送り手が行うことも可能である。
【００４１】
この付加的補償については、さまざまな特殊なケースに関して下記のとおりいくつかの代替方法がある（最良の補償は個々の応用によって異なる）：*この処理のためにある範囲ネットワーク・アドレスを割り当てる（例えば、リンク・ローカルにおいて169.254.x.x.の範囲を使用する。実際の値は関係ない。基本的には、単に他の誰も使用していない任意のネットワークが欲しいだけである）。この範囲のあるアドレスが、各＜natip、ownip、natport、ownport＞組み合わせに割り当てられる。ここで、natipはNATのIPアドレスを意味し、ownipは処理装置自身のIPアドレスを意味し、natportはNATのポート番号を意味し、ownportは処理装置自身のポート番号を意味する。パケットにおけるリモート・アドレスは、パケットがプロトコル・スタックに送られる前にこのアドレスと置き換えられる。
*補償の一部として、ホスト・アドレスまたはポート番号が変更された場合内部ホストのTCPチェックサムを再計算しなければならない。TCPチェックサム計算は、RFC1071から既知のとおりインクリメンタルでもよい。ソース・ポートについてポートNATを行う必要があるかもしれない。
*互換性のないプライベート・アドレス・スペース（オーバーラップの可能性がある）を使用する2つのサイト間でVPNとして使用される場合、アドレスをローカル・アドレスと互換性を持つようにするためにアドレス翻訳を行わなければならない。
*互換性のある（オーバーラップしない）プライベート・アドレス・スペースを使用する2つのサイト間でVPNとして使用され、トンネル・モードが使用される場合、付加的補償は必要ない。
*FTP（RFC959から既知）またはH.323など特定のプロトコル・パケットの内容についてアドレス翻訳を行う必要がある場合がある。他の同様の問題については、HoldregeSrisuresh99として示される参照文献において論じられている。
*サーバでクライアントのためにランダム・アドレスを使用して、このアドレスにアドレス翻訳することも可能である。これにより、サーバが同一のNATの背景で複数のクライアントを区別できるようにすることができ、ローカル・アドレス・スペースの手動構成を避けることができる。
*補償操作は、UDPポート番号を確保するためにローカル・マシンにおいてTCP/IPスタックと対話してもしなくてもよい。
【００４２】
一般的に行って、本発明は、インナー・パケットのために使用される方法をアウター・ヘッドのために行われるNATに強要するものではない。この補償を行うための最適の方法は、実験により上記の代替方法の中から見つかるかも知れないし、他の最適の方法が提示されるかも知れない。
【００４３】
次に、本発明の「キープアライブ」態様、すなわち行われる翻訳が決定された後はネットワークにおいて行われるネットワーク・アドレス翻訳が変化しないようにする態様について述べる。ネットワーク・アドレス・トランスレータは、返答パケットのためにマッピングを逆転できるように、アドレス・マッピングに関する情報をキャッシュ・メモリに入れる。TCPが使用される場合、アドレス・トランスレータは、特定のマッピングをドロップできるときを決定するためにTCPヘッダのFINビットを見ることができる。しかし、UDPの場合、流れの明示的な終了の指示がない。そのため、多くのNATは、UDPについてはかなり速く（30秒ほど）マッピングをタイプアウトする。従って、マッピングを維持させることが必要となる。
【００４４】
マッピングを維持させるための可能な方法は、アドレス翻訳がキャッシュ・メモリにとどまるのに十分な頻度でキープアライブ・パケットを送ることである。要求される頻度を計算する際には、パケットがネットワークで紛失する可能性を考慮に入れなければならないので、NATがマッピングを忘れるかもしれない推定最短時間内に複数のキープアライブが送られなければならない。適切な頻度は、マッピングがキャッシュに保持されている時間と、ネットワークのパケット損失確率によって決まる。さまざまな状況での最適の頻度は実験によって見つけることができる。
【００４５】
キープアライブ・パケットは、キープアライブ・パケットが実際のデータ・パケットと同じように正確に処理されるようにするために、データ・パケット・ヘッダと等しい必要なヘッダ以外には意味のある情報を含む必要はない。キープアライブ・パケットは、これをデータ・パケットではなくキープアライブ・パケットとして識別するインディケータを含むことができる。ただし、意味のあるペイロード情報を含まない全てのパケットはキープアライブ・パケットとして解釈されると決定することもできる。図3において、キープアライブ・パケットの伝送は、図解的にブロック306で示されており、その受信および廃棄は図解的にブロック307で示される。実際のデータ・パケットが十分な頻度で伝送される場合および／または中間装置がそのキャッシュからマッピング情報を削除しそうもない短い時間しか（例えば数秒）接続を有効としない場合、キープアライブ・パケットの使用は、全く必要とされないことが、分かるはずである。キープアライブ・パケットは、双方向に伝送することもできるが、一方向にしか伝送する必要がない。双方向伝送の結果生じる欠点は、不必要なネットワーク・トラフィックが増大することである。本発明は、キープアライブ・パケットが伝送される方向を制限しない。
【００４６】
図5は、本発明に従ったネットワーク・アドレス翻訳を通じて安全な通信を行う方法に従ってイニシエータまたはレスポンダとして作用できるネットワーク装置500の単純化されたブロック図である。ネットワーク・インターフェイス501は、ネットワーク装置500を物理的にネットワークに接続する。アドレス管理ブロック502は、正確なネットワーク・アドレス、ポート番号およびその他ネットワーク装置500自体およびその同格物（図には示されていない）の両方に関する重要な公開識別情報を追跡する。IKEブロック503は、キー管理および秘密情報の交換に関係するその他のアクティビティを担当する。暗号化/暗号解読ブロック504は、IKEブロック503が秘密キーを入手した後データの暗号化および解読を実施する。補償ブロック505は、本発明に従って送受されるパケットにおいて許容される変換を補償するために使用される。ブロック504および505のどちらも、キープアライブ・パケットを送受し、廃棄するために使用できる。パケット・アセンブラ/ディセンブラ・ブロック506は、ブロック502から505までと物理的ネットワーク・インターフェイス501との間の中間ブロックである。全てのブロックは、制御ブロック507の監督の下で動作し、制御ブロックは、例えば、ディスプレイ装置（図には示されていない）を通じてユーザに情報を表示しキーボード（図には示されていない）を通じてユーザからコマンドを受けるために、他のブロックとネットワーク装置の残り部分との間の情報のルーティングも制御する。図5のブロックは、マイクロプロセッサの事前にプログラムされた動作手順として実現されることがもっとも有利であり、この実現は、当業者には既知である。本発明を実施するために、図に示される以外の配列も使用することができる。
【００４７】
本発明をIKE、およびIKEポートを使用するトンネリングに関連して紹介したが、本発明は異なるパケット・フォーマット化方法、異なるネゴシエーション細部、異なるキー交換プロトコルまたは異なるセキュリティ・プロトコルを使用する他の類似するケースにも応用されることが、分かるはずである。本発明は、適切な特性を有する非IPプロトコルにも応用できる。本発明は、IPv4およびIPv6プロトコルに等しく応用できる。本発明は、また、IPSECおよびIKEプロトコルの将来のバージョンに応用されることも予定している。
【００４８】
本発明は単なるアドレス翻訳だけでなくプロトコル翻訳にも応用できることが、分かるはずである。本発明をプロトコル翻訳に適合させることは、本明細書の説明および上に言及され参照により本明細書に組み込まれる同じ出願者の前の特許出願におけるプロトコル翻訳に関する論証を読めば、十分に当業者の能力の及ぶ範囲にあるだろう。
【表１】
2003502913.tif 000001
【表２】
2003502913.tif 000002
【表３】
2003502913.tif 000003
【表４】
2003502913.tif 000004
【表５】
2003502913.tif 000005
【図面の簡単な説明】
【図１ａ】
ホストNATの既知の使用法を示している。
【図１ｂ】
ポートNATの既知の使用法を示している。
【図１ｃ】
パケット交換ネットワークを通じて行われるノード間の既知の通信接続を示している。
【図２ａ】
本発明において応用可能な特定のベンダIDペイロードを示している。
【図２ｂ】
本発明において応用可能な特定のプライベート・ペイロードを示している。
【図２ｃ】
本発明において応用可能な特定の組み合わせヘッダ構造を示している。
【図３】
本発明の応用に関係する特定の方法のステップを示している。
【図４】
本発明の1つの態様に従ったヘッダ構造の変換を示している。
【図５】
本発明に従った方法を実現するために使用されるネットワーク装置の単純化されたブロック図を示している。