(57)【要約】【課題】ＩＭＳ／ＭＭＤアーキテクチャのためのセキュリティの最適化を図る。【解決手段】セキュリティ最適化システムＳ１００において、元のＰ−ＣＳＣＦは、モバイルノードから新たなＰ−ＣＳＣＦのアドレスを受信し、新たなＰ−ＣＳＣＦにセキュリティアソシエーション鍵を含むコンテキストを伝送し、新たなＰ−ＣＳＣＦは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなＰＤＳＮにおいてモバイルノードのためのゲートをオープンすることを特徴とする。【選択図】図１１
2008072694.tif 000002
【特許請求の範囲】
【請求項１】
ＩＭＳ／ＭＭＤアーキテクチャのためのセキュリティ最適化システムであって、
モバイルノードがハンドオーバする前の元のＰ−ＣＳＣＦと、新たなＰ−ＣＳＣＦとを備え、
元のＰ−ＣＳＣＦは、モバイルノードから新たなＰ−ＣＳＣＦのアドレスを受信し、新たなＰ−ＣＳＣＦにセキュリティアソシエーション鍵を含むコンテキストを伝送し、
新たなＰ−ＣＳＣＦは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなＰＤＳＮにおいてモバイルノードのためのゲートをオープンする、
ことを特徴とするセキュリティ最適化システム。
【請求項２】
ＩＭＳ／ＭＭＤアーキテクチャのためのセキュリティ最適化システムであって、
モバイルノードがハンドオーバする先の新たなＰ−ＣＳＣＦと、Ｓ−ＣＳＣＦとを備え、
Ｓ−ＣＳＣＦは、モバイルノードから新たなＰ−ＣＳＣＦのアドレスを受信し、新たなＰ−ＣＳＣＦにセキュリティアソシエーション鍵を含むコンテキストを伝送し、
新たなＰ−ＣＳＣＦは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなＰＤＳＮにおいてモバイルノードのためのゲートをオープンする、
ことを特徴とするセキュリティ最適化システム。
【請求項３】
ＩＭＳ／ＭＭＤアーキテクチャのためのセキュリティ最適化方法であって、
モバイルノードが、ハンドオーバする前の元のＰ−ＣＳＣＦに新たなＰ−ＣＳＣＦのアドレスを通知するステップと、
元のＰ−ＣＳＣＦが、新たなＰ−ＣＳＣＦにセキュリティアソシエーション鍵を含むコンテキストを伝送するステップと、
新たなＰ−ＣＳＣＦが、モバイルノードのためのセキュリティアソシエーションを確立し、新たなＰＤＳＮにおいてモバイルノードのためのゲートをオープンするステップと、
を含むことを特徴とするセキュリティ最適化方法。
【請求項４】
ＩＭＳ／ＭＭＤアーキテクチャのためのセキュリティ最適化方法であって、
モバイルノードが、ハンドオーバする先の新たなＰ−ＣＳＣＦのアドレスをＳ−ＣＳＣＦに通知するステップと、
Ｓ−ＣＳＣＦが、新たなＰ−ＣＳＣＦにセキュリティアソシエーション鍵を含むコンテキストを伝送するステップと、
新たなＰ−ＣＳＣＦが、モバイルノードのためのセキュリティアソシエーションを確立し、新たなＰＤＳＮにおいてモバイルノードのためのゲートをオープンするステップと、
を含むことを特徴とするセキュリティ最適化方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＭＳ／ＭＭＤ（IP Multimedia Subsystem/Multimedia Domain）アーキテクチャのためのセキュリティの最適化システムおよび方法に関する。
【背景技術】
【０００２】
ＩＭＳ／ＭＭＤセキュリティアーキテクチャの重点は、加入者とＩＭＳとの間のＳＩＰ（Session Initiation Protocol）シグナリングの保護である。ＩＭＳアーキテクチャは、加入者とＩＭＳとの間の相互認証の手段を定義し、かつＩＭＳネットワーク要素間のドメイン間通信およびドメイン内通信を安全にするためのメカニズムを指定する。
【０００３】
ＩＭＳセキュリティアーキテクチャ（図１）は、各種の要素間のセキュリティインタフェースに数字のラベルが付与されたＩＭＳ／ＭＭＤセキュリティアーキテクチャの高レベルの概観を表わす。ＩＭＳ  ＡＫＡ（Authentication and Key Agreement）（インタフェース１）は、ＵＥ（User Equipment（ユーザ装置））とホームネットワークとの間の認証に用いられ、ＩＭＳ／ＭＭＤにおけるその役割は以下で説明される。ＩＰＳｅｃは、ＵＥと第１ホップ（first-hop）のＰ−ＣＳＣＦ（Proxy Call Session Control Function）との間（インタフェース２）、ＩＭＳコアネットワーク要素間（インタフェース３、４、５）、ＩＭＳコア要素と外部ＩＰネットワークとの間（インタフェース６、７）のＳＩＰメッセージングを安全にするために用いられる。ＩＰＳｅｃは、通信が同じセキュリティドメイン内に存在するとき、または、セキュリティドメインをまたぐときの両方に適用可能である。ＩＭＳ／ＭＭＤにおけるＩＰＳｅｃの役割は、以下で説明される。
【非特許文献１】3GPP2 X.S0013-002-A v1.0: “All-IP Core Network Multimedia Domain; IP Multimedia Subsystem - Stage 2,” November 2005
【非特許文献２】3GPP2 X.S0013-004-A v1.0: “All-IP Core Network Multimedia Domain: IP Multimedia Call Control based on SIP and SDP - Stage 3,” November 2005
【発明の開示】
【発明が解決しようとする課題】
【０００４】
現在のＩＭＳ／ＭＭＤセキュリティアーキテクチャは、なりすましの脅威に取り組む。ここでは、攻撃者は、ネットワーク要素または権限を与えられたユーザのいずれかのふりをすることによって、権限なくサービスへのアクセスを取得することができる。ＡＫＡおよびＩＰＳｅｃによる加入者認証の組み込み、および、ＩＰＳｅｃを用いたネットワークノード認証は、その発生を防止する。
【０００５】
盗聴の問題も取り組まれている。ここでは、攻撃者は、シグナリングメッセージの機密性を危うくし、または、それらの危険でないトラフィック解析を行うことがありうる。ＩＰＳｅｃに基づく暗号は、このカテゴリーの脅威に取り組むために適用される。
【０００６】
セキュリティアーキテクチャは、本来、ＩＭＳサービスにアクセスするためのホームネットワークに基づく認証を可能とする。訪問先ネットワークは、ＵＥによって用いられるベアラリソースを制御するが、ＩＭＳの権限付与はホームネットワークにおいてＳ−ＣＳＣＦ（Serving Call Session Control Function）から取得されるのみである。
【課題を解決するための手段】
【０００７】
上記の課題を解決するために、本発明に係るセキュリティ最適化システムは、ＩＭＳ／ＭＭＤアーキテクチャのためのセキュリティ最適化システムであって、モバイルノードがハンドオーバする前の元のＰ−ＣＳＣＦと、新たなＰ−ＣＳＣＦとを備え、元のＰ−ＣＳＣＦは、モバイルノードから新たなＰ−ＣＳＣＦのアドレスを受信し、新たなＰ−ＣＳＣＦにセキュリティアソシエーション鍵を含むコンテキストを伝送し、新たなＰ−ＣＳＣＦは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなＰＤＳＮにおいてモバイルノードのためのゲートをオープンすることを特徴とする。
【０００８】
本発明に係るセキュリティ最適化システムは、ＩＭＳ／ＭＭＤアーキテクチャのためのセキュリティ最適化システムであって、モバイルノードがハンドオーバする先の新たなＰ−ＣＳＣＦと、Ｓ−ＣＳＣＦとを備え、Ｓ−ＣＳＣＦは、モバイルノードから新たなＰ−ＣＳＣＦのアドレスを受信し、新たなＰ−ＣＳＣＦにセキュリティアソシエーション鍵を含むコンテキストを伝送し、新たなＰ−ＣＳＣＦは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなＰＤＳＮにおいてモバイルノードのためのゲートをオープンすることを特徴とする。
【０００９】
本発明に係るセキュリティ最適化方法は、ＩＭＳ／ＭＭＤアーキテクチャのためのセキュリティ最適化方法であって、モバイルノードが、ハンドオーバする前の元のＰ−ＣＳＣＦに新たなＰ−ＣＳＣＦのアドレスを通知するステップと、元のＰ−ＣＳＣＦが、新たなＰ−ＣＳＣＦにセキュリティアソシエーション鍵を含むコンテキストを伝送するステップと、新たなＰ−ＣＳＣＦが、モバイルノードのためのセキュリティアソシエーションを確立し、新たなＰＤＳＮにおいてモバイルノードのためのゲートをオープンするステップとを含むことを特徴とする。
【００１０】
本発明に係るセキュリティ最適化方法は、ＩＭＳ／ＭＭＤアーキテクチャのためのセキュリティ最適化方法であって、モバイルノードが、ハンドオーバする先の新たなＰ−ＣＳＣＦのアドレスをＳ−ＣＳＣＦに通知するステップと、Ｓ−ＣＳＣＦが、新たなＰ−ＣＳＣＦにセキュリティアソシエーション鍵を含むコンテキストを伝送するステップと、新たなＰ−ＣＳＣＦが、モバイルノードのためのセキュリティアソシエーションを確立し、新たなＰＤＳＮにおいてモバイルノードのためのゲートをオープンするステップとを含むことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、ＩＭＳ／ＭＭＤアーキテクチャにおいて、モバイルノードがＰ−ＣＳＣＦハンドオフする際のセキュリティアソシエーションの再結合の間の遅延を軽減することができ、セキュリティの最適化を図ることができる。
【発明を実施するための最良の形態】
【００１２】
ＩＭＳ／ＭＭＤセキュリティアーキテクチャの重点は、加入者とＩＭＳとの間のＳＩＰシグナリングの保護である。ＩＭＳは、加入者とＩＭＳとの間の相互認証の手段を定義し、かつＩＭＳネットワーク要素間のドメイン間通信およびドメイン内通信を安全にするためのメカニズムを指定する。ＳＩＰのようなシグナリングトラフィックとＲＴＰのようなメディアトラフィックの両方についてセキュリティアソシエーションを確立することが可能である。ＩＭＳ／ＭＭＤアーキテクチャにおけるハンドオフ動作を最適化するために、セキュリティアソシエーションの設定に寄与する動作を最適化することが重要である。なぜなら、これらの動作の各々はハンドオフ遅延を引き起こすもととなるからである。一連のセキュリティ最適化の方法論は、セキュリティに関する動作に影響を与えるそれらのパラメータを考慮する必要がある。
【００１３】
ＩＰＳｅｃは、ＩＰレイヤのトラフィックのセキュリティを保証するために設計された一連のセキュリティプロトコルである。ＩＰＳｅｃ  ＥＳＰ（Encapsulating Security Payload）プロトコルは、ＩＰパケットペイロードの機密性および完全性の保護をサポートし、一方、ＩＰＳｅｃ  ＡＨ（Authentication Header）プロトコルは、ＩＰパケット全体の完全性の保護をサポートする。ＥＳＰおよびＡＨプロトコルサービスは、ＩＰＳｅｃが使用可能なネットワークノード間でセキュリティアソシエーション（ＳＡ（Security Association））を確立することによって提供される。他のパラメータの中で、ＳＡは、一組のノード間で使用される完全性の保護および暗号化アルゴリズム、および、これらのアルゴリズムによって使用される対称鍵を定義する。また、ＩＰＳｅｃは、鍵ネゴシエーションプロトコル（ＩＫＥ（Internet Key Exchange））を定義し、これはＥＳＰまたはＡＨのＳＡによって使用される対称鍵を安全に確立するために使用される。
【００１４】
ＩＰＳｅｃのＥＳＰおよびＡＨプロトコルは、トンネルモードまたはトランスポートモードのいずれにおいても動作する。トンネルモードにおいてはＩＰパケット全体が新たなＩＰパケット内にカプセル化され、一方、トランスポートモードにおいてはＩＰペイロードに追加または修正が行われる。パケットあたりのオーバーヘッドはトンネルモードにおいて幾分高く、通信ノード間に配置されたＩＰＳｅｃゲートウェイにおいて用いられるとき、トラフィック解析を避けることを第一に意図している。
【００１５】
ＩＰＳｅｃプロトコルはインターネットにおいて広く用いられている。プロトコル一式は、システムアーキテクチャを変更することなく新たな機密性および完全性保護アルゴリズムを組み込むことが可能であるという意味でモジュール方式である。ＩＰＳｅｃトラフィックは、下位の物理レイヤまたは相互接続トポロジーを変更することなく既存のＩＰインフラ上で伝送可能である。典型的に、ＩＰＳｅｃ動作はアプリケーションレイヤのエンティティに透過的である。ＩＭＳ／ＭＭＤフレームワークにおいて、ＩＰＳｅｃは、主として、ＵＥとＰ−ＣＳＣＦとの間（図１のインタフェース２）で交換されるＳＩＰメッセージに機密性および完全性の保護を提供するために用いられる。ＩＰＳｅｃ  ＥＳＰは、トランスポートモードで動作し、このコンテキストでの使用が必須である。ＵＥおよびＰ−ＣＳＣＦがお互いに相互認証に成功すると、ＩＰＳｅｃ  ＥＳＰトランスポートモードＳＡが、ＵＥとその対応するＰ−ＣＳＣＦとの間で確立される。ＩＰＳｅｃ  ＳＡ確立手順はＩＭＳ  ＡＫＡが受け持つ。
【００１６】
以下は、Ｐ−ＣＳＣＦとＵＥとの間で動作するＩＰＳｅｃの特徴のリストである。
・ＩＰＳｅｃ  ＥＳＰ処理は、Ｐ−ＣＳＣＦおよびＵＥにおいてＳＩＰアプリケーションに透過的であり、ＩＰＳｅｃモジュールによって実行される。ＳＩＰアプリケーションはＩＰＳｅｃモジュール内でＳＡを設定するが、これらのＩＰＳｅｃモジュールは、ＳＩＰアプリケーションの範囲外で動作する。
・ＩＰＳｅｃはＳＩＰメッセージのためのデータ認証を提供し、ＵＥにおいて受信されＩＰＳｅｃ  ＥＳＰによって保護されたメッセージは、（Ｐ−ＣＳＣＦおよびＵＥが危険にさらされていないと仮定して）Ｐ−ＣＳＣＦによって生成されたことが保証され、逆もまた同様である。さらに、メッセージは相手方によってリプレイされなかったことが保証される。
・また、ＩＰＳｅｃは、ＳＩＰメッセージにデータ機密性を提供する。危険にさらされていないＰ−ＣＳＣＦおよびＵＥを仮定して、ＩＰＳｅｃはそれらの間で生成されたメッセージに機密性を提供し、盗聴者は捕捉したどのパケットも復号化することができない。
・ＩＰＳｅｃ  ＥＳＰはＩＰヘッダの完全性を保護しないので、受信側ＳＩＰアプリケーションは、保護されたＳＩＰメッセージのコンタクトヘッダがパケットヘッダにおけるソースＩＰヘッダと合致することを検証する必要がある。
【００１７】
また、ＩＰＳｅｃは、単一の通信事業者ドメイン内で（ドメイン内で）、または、２つ以上の通信事業者ドメインにわたって（ドメイン間で）、相互作用するコアＩＭＳネットワーク要素間で用いることが可能である。ＩＰＳｅｃの様式は、関係する通信事業者の自由裁量に任されている。ドメイン間のセキュリティの提供は、Ｉ−ＣＳＣＦ（Interrogate Call State Control Function）とＰ−ＣＳＣＦとの間（図１のインタフェース４）、Ｓ−ＣＳＣＦとＰ−ＣＳＣＦとの間（図１のインタフェース４）、Ｓ−ＣＳＣＦとＳＩＰアプリケーションサーバを収容する外部ＩＰネットワークとの間（図１のインタフェース７）のＳＩＰメッセージングを安全にすることを含む。さらに、外部ＳＩＰアプリケーションサーバとＨＳＳ（Home Subscriber Server）との間（Ｃｘインタフェース）（図１のインタフェース６）のメッセージングを安全にすることも含む。全ての場合において、暗号化とともに完全性の保護を用いる（トランスポートモードまたはトンネルモードのいずれかにおける）ＩＰＳｅｃの使用が必須である。さらに、そのようなノード間でセキュリティアソシエーションをネゴシエーションするためのＩＫＥの使用が要求される。ＩＰＳｅｃに基づくドメイン間のセキュリティは次のような特徴を有する。
・ＩＫＥの使用は、通信ノード間で共有鍵の安全なネゴシエーションを可能とする。ＩＭＳ  ＡＫＡによって要求されるような鍵の事前配置は必要ない。
・ＩＫＥは、Diffie-Hellman交換を用いた共有鍵の算出のために公開鍵を用いる。Diffie-Hellman交換は中間者（man-in-the-middle）攻撃を受けやすいので、鍵の信憑性を保証するために公開鍵証明書の使用が必須である。
・通信事業者ネットワークをまたがるトンネルモードのセキュリティアソシエーションの使用は、通信事業者ネットワーク間でセキュリティゲートウェイの使用を可能とする。トンネルモードＳＡはＩＭＳノードにおいて生成されたパケットのＩＰヘッダを暗号化するので、トラフィック解析攻撃からの通信事業者ネットワークの保護を可能とする。
【００１８】
ドメイン内のセキュリティ（図１のインタフェース３および５）は、ドメインの管理権限に解放されている。特定の鍵配送／ネゴシエーションメカニズムまたはＳＡモードは必須ではないが、ＩＰＳｅｃに基づく機密性および完全性の保護はオプションである。
【００１９】
ＩＭＳ  ＡＫＡは、ＵＥとＨＳＳとの間で用いるために定義される認証プロトコルである。これはＳＩＰセキュリティメカニズム合意プロトコルに基づく。全てのセキュリティパラメータがＳＩＰを用いてＵＥとＨＳＳとの間で交換される。
【００２０】
図２は、ＵＥ、Ｐ−ＣＳＣＦ、Ｉ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、ＨＳＳを含む、ＩＭＳ  ＡＫＡを構成するＳＩＰメッセージフローを表わす。ＩＭＳ  ＡＫＡは、対応する鍵配送処理とともにＳＩＰ登録／応答メッセージの上に載せられる。２組の登録／応答メッセージが要求される。メッセージの第１の組の最後に、ＵＥとＰ−ＣＳＣＦとの間でＩＰＳｅｃ  ＳＡが確立される。ＵＥは、4xx Auth_Challengeメッセージを受信した後にネットワークを認証し、一方、ネットワークは、第２の登録メッセージを受信した後にＵＥを認証する。
【００２１】
ＩＭＳ／ＡＫＡの特徴は次の通りである。
・ＳＩＰメッセージングがサービング（訪問先ネットワーク）上で伝送されるときでも、認証はＵＥとそのホームネットワークとの間で実行される。訪問先ネットワークはＰＤＳ（Packet Data Service）上のベアラリソースの制御を有するが、これは、ＩＭＳリソースへのホームネットワークに基づくアクセス制御を可能とする。
・ＳＩＰ登録／応答メッセージはＩＭＳ／ＡＫＡプロトコルペイロードを伝送するために用いられる。これらのメッセージは、ＵＥからＳ−ＣＳＣＦに送信され、その逆も同様である。Ｓ−ＣＳＣＦはＨＳＳにＵＥについてのセキュリティ関連パラメータを取得することを要求する。
・ＵＥおよびＨＳＳはロングターム鍵（Ｋ）を共有する。この鍵はＩＭＳ／ＡＫＡプロトコル動作の間のみ使用され、ＵＥにおけるＩＰＳｅｃ処理の間は使用されない。
・ＩＭＳ／ＡＫＡはホームネットワークにＵＥが真正であることを証明するためにチャレンジレスポンスメカニズムを用いる。Ｐ−ＣＳＣＦを介してＳ−ＣＳＣＦによって送信されたチャレンジへの応答を計算するためにＫを用いる。Ｐ−ＣＳＣＦは、転送する要素として動作することを除いてチャレンジ生成において何の役割も果たさない。
・ＵＥは、Ｐ−ＣＳＣＦを介してＳ−ＣＳＣＦによって送信されたＭＡＣ（Message Authentication Code）の検証によって、ＵＥにネットワークが真正であることを証明される。ＭＡＣはＵＥにおいてＫを用いて検証される。
・ＩＭＳ  ＡＫＡに基づく登録処理の間に、ＵＥとその現在のＰ−ＣＳＣＦとの間にＩＰＳｅｃ  ＥＳＰ  ＳＡが確立される。ＨＳＳは、ＩＰＳｅｃ  ＳＡにおいて用いられる完全性鍵（ＩＫ）および暗号化鍵（ＣＫ）を導き出すためにＫを用いる。新たなＩＭＳ  ＡＫＡ手順がＵＥとその現在のＰ−ＣＳＣＦとの間で発生するときはいつでも、新たなＩＫ、ＣＫの組が新たなＩＰＳｅｃ  ＳＡを設定するために用いられる。
・ホームネットワークのＳ−ＣＳＣＦからのＳＩＰ応答メッセージを用いた一連のＩＭＳ  ＡＫＡ手順の間に、ＩＫ、ＣＫの組が訪問先Ｐ−ＣＳＣＦに伝送される。ＫはＰ−ＣＳＣＦに送信されず、従って、ＩＫ、ＣＫが特定のＳＡについて危険にさらされても、Ｋは危険にさらされない。
・ＩＰＳｅｃ  ＳＡは、常に、ＳＩＰ登録の有効期間よりわずかに長い有効期間を有する。これは、新たなＳＩＰ登録が、可能ならばいつでも以前から存在するＳＡの活用を可能とする。
【００２２】
ＵＥとＰ−ＣＳＣＦとの間で交換されるＳＩＰパケットは、一方向ＥＳＰ伝送モードＳＡの組を用いて保護される。従って、ＵＥは、Ｐ−ＣＳＣＦから受信されるパケットのためのインバウンドＳＡ、および、Ｐ−ＣＳＣＦに送信されるパケットのためのアウトバウンドＳＡを有する。また、Ｐ−ＣＳＣＦは、通信する各ＵＥのためのＳＡの類似する組を有する。これらのＳＡは、ＩＭＳ  ＡＫＡプロトコルを用いてＵＥとＰ−ＣＳＣＦとの間で確立される。
【００２３】
ＩＰｖ４についてのＩＰＳｅｃ  ＥＳＰのトランスポートモードの動作が図３に表わされている。図は、ＴＣＰペイロードの場合についてのＩＰＳｅｃ  ＥＳＰの動作を表わし、ＵＤＰペイロードについての動作は、パケットにおいてＴＣＰプロトコルの記号をＵＤＰプロトコルの記号に置き換えたものと同一である。ＳＩＰメッセージングはＵＤＰまたはＴＣＰ上で実行され、従って、ＳＩＰヘッダおよびペイロードは図３に表わすパケットのデータ部において伝送される。
【００２４】
ＳＡが確立されると、ＵＥからＰ−ＣＳＣＦに送信される全てのＳＩＰパケットはＩＰＳｅｃによって次のように処理される。
１．ＵＤＰ伝送を仮定すると、ＵＥにおいて生成されるＳＩＰパケットはＵＤＰペイロード内にカプセル化され、次に、ＩＰペイロード内にフレーム化される。このＩＰパケットは、ＵＥにおいてアウトバウンドＳＡによって処理される。
２．パッドバイトおよびペイロード情報を含むＥＳＰトレーラが（ＳＩＰデータグラムを含む）ＩＰペイロードに付加される。ＩＰペイロードおよびＥＳＰトレーラは、ＩＭＳ／ＭＭＤに必須のアルゴリズムの１つを用いて暗号化される。必須のアルゴリズムはＤＥＳ−ＥＤＥ３−ＣＢＣおよびＡＥＳ−ＣＢＣである。
３．ＳＡ固有情報を含むＥＳＰヘッダは、ＩＰペイロードと元のＩＰヘッダとの間に挿入される。
４．新たなＩＰペイロード（ＥＳＰヘッダからＥＳＰトレーラまで）は、ＩＭＳ／ＭＭＤの必須アルゴリズムの１つによって完全性が保護される。これらは、ＨＭＡＣ−ＭＤ５−９６またはＨＭＡＣ−ＳＨＡ−１−９６である。完全性保護情報は、ＩＰデータグラムの最後に付加されたＥＳＰ認証フィールドに格納される。
５．新たに付加されたＥＳＰフィールドとともにＩＰデータグラムは、ここで、ＰＤＳレイヤの上でＰ−ＣＳＣＦに送信される。
６．ＩＰデータグラムを受信すると、Ｐ−ＣＳＣＦは、ＥＳＰヘッダおよびＩＰヘッダの宛先ＩＰアドレスを調べることによって、使用するインバウンドＳＡを決定する。
７．まず、Ｐ−ＣＳＣＦは、ＥＳＰ認証ヘッダフィールドおよび選択されたＳＡによって指定された完全性保護鍵を用いることによってパケットの完全性を検査する。
８．完全性が検証されると、Ｐ−ＣＳＣＦは、ＩＰペイロードを復号化するために、ＳＡによって指定された復号鍵を用いる。復号化が完了すると、ＥＳＰ関連ヘッダは削除され、パケットはようやくＳＩＰアプリケーションに伝送される。
【００２５】
また、Ｐ−ＣＳＣＦからＵＥに送信されるＳＩＰパケットは、Ｐ−ＣＳＣＦにおける対応するアウトバウンドＳＡ、および、ＵＥにおけるインバウンドＳＡを用いて、同様な方法で処理される。
【００２６】
Ｐ−ＣＳＣＦは、ＵＥから受信したＳＩＰパケットを他のＩＭＳネットワーク要素に転送し、その逆も同様である。従って、ＳＩＰシグナリングパケットは、ＩＭＳコアネットワーク内を通過するときは保護される必要がある。これは、ドメイン間のネットワーク要素の間で交換されるシグナリングメッセージのためにドメイン間のセキュリティを実現するための手段としてＩＰＳｅｃを指定する。ＩＰＳｅｃが使用可能でない場合には、これはネットワーク要素間でホップ毎のセキュリティを実現する手段としてＴＬＳ（Transport Layer Security）の使用を提案する。ＩＭＳネットワーク要素が同じネットワーク事業者ドメイン内に存在する場合には、セキュリティメカニズムはネットワーク事業者の自由裁量に任される。
【００２７】
ＩＭＳ／ＭＭＤセキュリティフレームワークは、ＩＭＳレイヤにおいてメディアを安全にする手段を指定しない。重点はＳＩＰに基づくシグナリングメッセージを安全にすることにある。メディアセッションは、Ｐ−ＣＳＣＦ、Ｉ−ＣＳＣＦ、Ｓ−ＣＳＣＦのようなＩＭＳコアネットワーク要素を通して流れないので、範囲外である。ＩＰマルチメディアセッションは、ユーザデータパケットの形式でＰＤＳを移動する。図４に表わされているように、いくつかのセキュリティが、無線アクセス（ＲＡ）レベルおよびＩＰネットワークレベルにおいてデータパケットに提供される。
【００２８】
ＲＡレベルのセキュリティは、ネットワークプロバイダの自由裁量において、機密性の要件をサポートするために、エアインタフェース暗号を組み込む。しかし、これはメディアのエンドエンド間のセキュリティを提供しない。
【００２９】
ネットワーク事業者の自由裁量において、ホームエージェントとフォーリンエージェント（Foreign Agent）との間でＩＰＳｅｃがサポートされる。さらにまた、これはエンドエンド間のセキュリティを提供しない。
【００３０】
エンドエンド間のセキュリティはユーザの要求により追加されるが、これらのメカニズムは３ＧＰＰ２（3rd Generation Partnership Project 2）標準において指定されていない。エンドエンド間のセキュリティは、ネットワークセキュリティのメカニズムにおいてユーザが有する機密性のレベルまたはメディアコンテンツの特性に基づいて要求される。しかし、ある場合において、エンドエンド間のセキュリティは、適法に認可された電子的監視（Lawfully Authorized Electronic Surveillance）を要求する政府の規制に阻まれる。
【００３１】
エンドエンド間のセキュリティを実行するために代替のメカニズムが利用可能である。
・ＩＰＳｅｃ：ＵＥにおいて既に存在するＩＰＳｅｃサービスを用いることによってネットワークレイヤのエンドエンド間のセキュリティが提供される。この場合において、ＳＡはＵＥ間で直接に確立され、ＰＤＳからのサポートは要求されない。ＵＥにおいてアプリケーションが生成するメディアコンテンツは、ＩＰＳｅｃの導入によって影響を受けず、メディアストリーミングプロトコルもＩＰＳｅｃの存在を意識しない。
・ＳＲＴＰ：セキュアリアルタイムトランスポートプロトコルは、リアルタイムトランスポートプロトコル（ＲＴＰ）の一側面であり、ＲＴＰトラフィックおよびＲＴＰ制御トラフィックへの機密性、メッセージ認証、リプレイ保護を提供することが可能である。ＩＰＳｅｃと同様に、ＰＤＳのサポートは要求されない。しかし、アプリケーションが生成するメディアコンテンツは、ＳＲＴＰをサポートする必要がある。
【００３２】
ここで２つの異なる場合を検討する：それぞれの移動プロトコル（mobility protocol）としてＦＡモードにおいて、（１）ＭＩＰｖ６（Mobile IP version 6）が用いられる場合、（２）ＭＩＰｖ４（Mobile IP version 4）が用いられる場合である。図５はＭＩＰｖ６が配置されたシナリオを表わす。そのようなシナリオにおいて、移動ノードから２つのトンネルが要求され、１つはＭＮ（Mobile Node）とＨＡ（Home Agent）との間、他の１つはＭＮとＰ−ＣＳＣＦとの間のＭＩＰｖ６トンネルである。移動ノードは、ローミングするときにブートストラップするにせよ、Ｐ−ＣＳＣＦを変更するにせよ、ホームＰ−ＣＳＣＦとＩＰＳｅｃ  ＳＡを確立することを要求する。また、どのようにＳＡが生成されるかに応じて、ＭＮは、新たなＰＤＳＮ（Packet Data Serving Node）に変更するときに同じＰ−ＣＳＣＦと新たなＳＡを確立することを要求する。従って、（ＭＩＰｖ６トンネルに加えて）ＭＮにおいてより多くのトンネルオーバーヘッドを追加する。課題はそのようなオーバーヘッドを最小化することである。
【００３３】
移動ノードの位置およびアクセスネットワークの状態に応じて、ＩＰＳｅｃ  ＳＡの確立はハンドオフの性能にいくらかの影響を与える。メディアはＩＰＳｅｃ  ＳＡを介して交換されることを必要としないが、Ｐ−ＣＳＣＦは重要な経路に存在するので、登録を含む全てのＳＩＰシグナリングはＩＰＳｅｃ  ＳＡを介して交換されることが必要である。また、ＭＮが新たなＰＤＳＮに接続している間、セッションが維持されるように、ＩＰＳｅｃ  ＳＡの確立は十分早いことが必要である。従って、ハンドオフの間のいくつかの課題が見られ、そのようないくつかの課題を挙げると次の通りである。
・ＩＰＳｅｃ  ＳＡの確立の遅延
ＭＮが遠隔のネットワークにアクセスしているとき、ＩＰＳｅｃ  ＳＡの確立の遅延は大きい。これは、ブートストラップの間の課題ではないが、この遅延が大き過ぎるとハンドオフの性能に影響を与える。
・ＰＤＳＮを変更する間の新たなＳＡの確立
大部分の一般的な場合において、ＩＰＳｅｃ  ＳＡはインタフェースのＩＰアドレスに結合される。従って、インタフェースのＩＰアドレスが変更されると（ＭＮが他のＰＤＳＮに接続すると）、（ＳＡが恒久的な識別子に結合されていなければ、）新たなＩＰＳｅｃ  ＳＡの確立が必要である。
・ハンドオフの間のＰ−ＣＳＣＦの変更
訪問先ネットワークが異なるＰ−ＣＳＣＦを割り当てられているシナリオでは、ＭＮは、ネットワークを変更する間、新たなＩＰＳｅｃ  ＳＡを生成する必要がある。しかし、これは一般的なケースではない。
【００３４】
これらは、配置の間に適切に計画されなければ、ＩＰＳｅｃのためにコアネットワークにおいても（主としてシステムレベルで）いくらかの影響が存在する。
・ＩＰＳｅｃトンネルの数
大規模ネットワークにおいて、ホームネットワークとのシグナリング交換、メディア送信、管理データ交換のために、サービスセッションの間に設定されることが必要な多くの通信経路が存在する。注意深い計画なしでは、要求されるＩＰＳｅｃトンネルの数は、装置とともにより多くのアプリケーションが配置されるに従って増加する。従って、システムの性能は、システムにおいてオープンされる過度のＩＰＳｅｃトンネルの数のためにひどく劣化する。
・パケットの断片化
ＩＰレイヤ３におけるデータパケットにＩＰＳｅｃが適用されるとき、ＩＰＳｅｃアルゴリズムが起動される必要があることを受信側に知らせるために、ヘッダ、トレーラ、または、その両方がパケットに付加されることが必要である。これはパケットの長さを増大させ、送信のためにパケットが２つのパケットに分割されることを引き起こす（ＩＰの断片化として知られる）。例えば、元のパケットサイズが１４９０バイトであるならば、ＥＳＰ（カプセル化されたセキュリティペイロード）ヘッダ、トレーラ情報、ＭＡＣ（メッセージ認証コード）値が付加された後、１５４４バイトに増加する。従って、（イーサネット（登録商標）の場合）パケットは２つのパケットに断片化される必要がある。これらの追加のパケットはシステムに追加処理の負荷をかけ、従って、ネットワークの全体の性能を劣化させる。多数の要求が移動ノードから同時に生じるならば、これはかなりの遅延を与える。
【００３５】
一方、図６は、ＭＩＰｖ４の場合に要求されるトンネルを表わす。そのようなシナリオにおいて移動ノードから要求されるトンネルの数はただ１つの、例えば、（ＭＩＰトンネルはＦＡとＨＡとの間に存在するので、）ＭＮとＰ−ＣＳＣＦとの間のＩＰＳｅｃトンネルである。しかし、高速なＩＰＳｅｃ  ＳＡの確立は、よりよいハンドオフ性能を達成するために必要である。このアーキテクチャは、ＭＩＰｖ６の場合に上述したのと同じタイプのＩＰＳｅｃの課題を有する。
【００３６】
また、ここで２つの異なる場合を検討する：それぞれの移動プロトコルとしてＦＡモードにおいて、（１）ＭＩＰｖ６が用いられる場合、（２）ＭＩＰｖ４が用いられる場合である。図７はＭＩＰｖ６が配置されたシナリオを表わす。そのようなシナリオにおいて、移動ノードから２つのトンネルが要求され、１つはＭＮとＨＡとの間、他の１つはＭＮとＰ−ＣＳＣＦとの間のＭＩＰｖ６トンネルである。移動ノードは、ローミングするときにブートストラップするにせよ、Ｐ−ＣＳＣＦを変更するにせよ、訪問先Ｐ−ＣＳＣＦとＩＰＳｅｃ  ＳＡを確立することを要求する。前述のアーキテクチャとの唯一の相違は、Ｐ−ＣＳＣＦが全て訪問先ドメインに存在することである。
【００３７】
一方、図８は、ＭＩＰｖ４の場合に要求されるトンネルを表わす。そのようなシナリオにおいて移動ノードから要求されるトンネルの数は、前述のようにただ１つである。しかし、高速なＩＰＳｅｃ  ＳＡの確立は、よりよいハンドオフ性能を達成するために必要である。
【００３８】
ここでも２つの異なる場合を提示する：それぞれの移動プロトコルとしてＦＡモードにおいて、（１）ＭＩＰｖ６が用いられる場合、（２）ＭＩＰｖ４が用いられる場合である。図９はＭＩＰｖ６が配置されたシナリオを表わす。前述のように、移動ノードから２つのトンネルが要求され、１つはＭＮとＨＡとの間、他の１つはＭＮとＰ−ＣＳＣＦとの間のＭＩＰｖ６トンネルである。このアーキテクチャは、ＭＮが新たなサブネットに移動するごとに新たなＩＰＳｅｃ  ＳＡを確立することが必要であるという点で、前述の２つのアーキテクチャと大きな相違を有する。すなわち、ＰＤＳＮを変更するごとに、新たなＰ−ＣＳＣＦに接続する。従って、ＭＮにおいて次のような課題を有する。
・ＩＰＳｅｃ  ＳＡの確立の遅延
ＭＮが新たなサブネットに移動するごとに通常のＡＫＡ手順とともにＳＩＰ登録を実行しなければならないので、ＩＰＳｅｃ  ＳＡの確立の遅延は大きい。従って、認証が成功し、従って、ＭＮとＰ−ＣＳＣＦとの間でＳＡが確立されなければ、新たなＰＤＳＮを通してメディアが流れ始めないので、ハンドオフの性能に影響しうる。
【００３９】
これらは、配置の間に適切に計画されなければ、ＩＰＳｅｃのために訪問先ネットワークにおいても（主としてシステムレベルで）いくらかの影響が存在する。それは次の通りである。
・Ｐ−ＣＳＣＦにおけるＩＰＳｅｃトンネルの数
非常に混雑した訪問先ネットワークにおいて、ブートストラップの間またはサービスセッションのハンドオフの間に、ＩＰＳｅｃ  ＳＡを設定する必要がある多数の移動ノードが存在する。注意深い計画なしでは、要求されるＩＰＳｅｃトンネルの数は、加入者数の増加とともに大きな数に増加する。従って、システムの性能は、システムにおいてオープンされる過度のＩＰＳｅｃトンネルの数のためにひどく劣化する。結果として、これはＳＡ初期化の間により大きな遅延を与える。
・パケットの断片化
上述したのと同様である。
【００４０】
図１０は、ＭＩＰｖ４の場合に要求されるトンネルを表わす。そのようなシナリオにおいて移動ノードから要求されるトンネルの数は、前述のようにただ１つである。しかし、高速なＩＰＳｅｃ  ＳＡの確立は、よりよいハンドオフ性能を達成するために必要である。このアーキテクチャは上述したのと同じタイプのＩＰＳｅｃの課題を有する。しかし、ｗｉ−ｆｉ（Wireless Fidelity）ネットワークからアクセスするときを除いて、ただ１つのトンネルを確立することが必要であるので、ＭＮにおいてトンネルオーバーヘッドに関しての影響はより小さい。
【００４１】
Ｐ−ＣＳＣＦにおけるＩＰＳｅｃトンネルの確立の遅延は、ハンドオフの間のセッション移行におけるシグナリングおよびメディアの両方にかなりのオーバーヘッドを与えうる。特に、アーキテクチャＩＩｂは、各サブネットの変更の間にＭＮを登録することを要求する。なお、Ｐ−ＣＳＣＦを外部ネットワークに配置し、かつ、それぞれのサブネットワーク毎にＰ−ＣＳＣＦを配置した場合のアーキテクチャを「アーキテクチャＩＩｂ」と称している。登録のためのシグナリングおよびメディア伝送は移動ノードから同時に生じうるが、Ｐ−ＣＳＣＦとＭＮとの間でＳＡが確立されるまで、新たなＰＤＳＮを介してメディアを再開することができない。登録が新たな訪問先ネットワークにおいて成功すると、すなわち、ＭＮと新たなＰ−ＣＳＣＦとの間でＩＰＳｅｃ  ＳＡが確立されると、ＩＭＳ／ＭＭＤにより、訪問先ネットワークにおけるアクセス制御ポリシーは、新たなＰＤＳＮを介してメディアが流れることを可能とする。従って、メディアはＩＰＳｅｃ  ＳＡを介して保護されないが、ＳＩＰ登録とメディア伝送との間に暗黙の依存関係が存在する。しかし、ＭＩＰバインディング更新（binding update）手順は、ＨＡの位置に応じてメディアにかなりの遅延を与える。ＩＭＳ／ＭＭＤセキュリティフレームワークは、ＵＥ（すなわち、ＭＮ）とＰ−ＣＳＣＦとの間のセキュリティメカニズムを定義し、ＩＭＳ  ＡＫＡと呼ばれる。ＩＭＳ／ＭＭＤフレームワークにおけるＩＭＳ  ＡＫＡの役割を検討する。登録手順の間、Ｐ−ＣＳＣＦは、他のパラメータとともにＳ−ＣＳＣＦからＭＮごとに新たな一組の鍵（例えば、ＩＫおよびＣＫ）を受信する。これらの鍵は、新たなＵＥとＳＡを確立するために用いられる。ＵＥは、サブネットを変更するときに同じＳ−ＣＳＣＦとともに登録されるが、理想的には新たなＳ−ＣＳＣＦのために生成される鍵は異なるべきである。しかし、このネットワークにおいて、これらの鍵は、Ｐ−ＣＳＣＦを危うくするごくわずかの機会が同じく与えられる。
【００４２】
従って、上記手順は時間を要し、Ｐ−ＣＳＣＦのハンドオフの間にかなりの遅延を与えうることが明らかである。さらに、ＭＮにおける複数のトンネルは全体のハンドオフ手順に、より大きなオーバーヘッドを与える。従って、ＩＰＳｅｃの最適化が要求され、ＩＰＳｅｃの最適化とは、ＩＭＳ／ＭＭＤのセキュリティを危うくすることなく、あるアプリケーションによって要求されるならばメディアを保護する一方で、この遅延が最小化されうるメカニズムを意味する。ＩＰＳｅｃの最適化は２つの部分を有する：（１）ＳＡの再結合の間の遅延を軽減する、（２）ＭＮにおけるシグナリングおよびメディアのためのＩＰＳｅｃトンネルのオーバーヘッドを軽減する。以下、そのような課題がどのように軽減されるか検討し、あるアプリケーションにおいてメディアのセキュリティも要求されるならば用いられるいくつかの代替のメカニズムを提供する。
【００４３】
ＳＡの再結合の間の遅延を軽減するために、次の方法が適用される。これらの方法はアーキテクチャＩＩｂに適用可能である。
・元のＰ−ＣＳＣＦから新たなＰ−ＣＳＣＦにＳＡ鍵を伝送する
この場合のＩＰＳｅｃ最適化システム（Ｓ１００）が図１１に表わされている。
ＭＮが１つのサブネットから他のサブネットに移動するときにＰ−ＣＳＣＦにおいてＭＮごとに鍵が変更されないと仮定すると、ＭＮが物理的に新たなサブネットに移動する前にＳＡが確立されるように、鍵はあるコンテキスト伝送メカニズムを通して元のＰ−ＣＳＣＦから新たなＰ−ＣＳＣＦに伝送される。しかし、元のネットワークが、移動局が移動していることを認識し、かつ新たなＰ−ＣＳＣＦのＩＰアドレスを元のＰ−ＣＳＣＦに通知するメカニズムが必要である。これは移動管理メカニズムに新たな課題をもたらすが、プロアクティブな（proactive）ハンドオーバを行い、新たな宛先を予測することは可能である。鍵が利用可能になると、Ｐ−ＣＳＣＦは通常のＳＩＰ登録を並行して実行しながらＳＡを生成する。従って、ＳＡ鍵を取得するために完全なＡＫＡ手順への依存を最小化することができる。実際、アクセス制御ポリシーは、新たな訪問先ネットワークを通してＭＮがパケットを送信するとすぐにメディアが流れることを可能とする。いくつかのメカニズムは、鍵および他の呼状態パラメータを新たなＰ−ＣＳＣＦに伝送するために用いることが可能である。例えば、ＩＥＴＦ  ＣＸＴＰ（Context Transfer Protocol（コンテキスト伝送プロトコル））、ＳＩＰメソッド、例えば、ＭＥＳＳＡＧＥ、ＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹ等は、この目的のために使用することが可能である。
・呼の流れ
図１１は、ＩＰＳｅｃ  ＳＡ鍵が元のＰ−ＣＳＣＦから新たなＰ−ＣＳＣＦに伝送される最適化されたＩＰＳｅｃについての呼の流れを表わす。図において、この最適化された部分の間に要求される一連のステップを表わす。これらのメッセージ交換は、プロアクティブな、および、リアクティブな（reactive）ハンドオーバ時間の間に生じうる。ＭＩＰバインディング更新は、トロンボーンルーティングとしても知られるルーティングのループを避けるためにＳＡが確立される前にゲートを通過する必要がある。従って、新たなＰＤＳＮは、ＳＩＰ初期登録およびＭＩＰバインディング更新のポートを常にオープンし続けると仮定する。
図１１において、モバイルノード（ＭＮ）がハンドオーバする前の元のＰ−ＣＳＣＦと、新たなＰ−ＣＳＣＦとを備える。元のＰ−ＣＳＣＦは、モバイルノードから新たなＰ−ＣＳＣＦのアドレスを受信し、新たなＰ−ＣＳＣＦにセキュリティアソシエーション（ＳＡ）鍵を含むコンテキストを伝送する。新たなＰ−ＣＳＣＦは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなＰＤＳＮにおいてモバイルノードのためのゲートをオープンする。
【００４４】
・Ｓ−ＣＳＣＦから新たなＰ−ＣＳＣＦにＳＡ鍵を伝送する
この場合のＩＰＳｅｃ最適化システム（Ｓ２００）が図１２に表わされている。
この場合、ＭＮが物理的に新たなサブネットに移動する前にＳＡが確立されるように、十分に前もってあるコンテキスト伝送メカニズムを通してＳ−ＣＳＣＦによって新たなＰ−ＣＳＣＦにＳＡ鍵が伝送される。しかし、（前述の方法と同様に）Ｓ−ＣＳＣＦが（またはある移動管理エージェントを介して）、移動局が移動していることを認識し、新たなＰ−ＣＳＣＦのＩＰアドレスを元のＰ−ＣＳＣＦに通知するメカニズムが必要である。これはハンドオーバメカニズムによって可能である。鍵が利用可能になると、Ｐ−ＣＳＣＦはＳＩＰ登録を並行して実行しながらＳＡを生成することが可能である。従って、ＳＡ鍵を取得するために完全なＡＫＡ手順への依存を最小化することができる。従って、アクセス制御ポリシーは、新たな訪問先ネットワークを通してＭＮがパケットを送信するとすぐにメディアが流れることを可能とする。前述のように、いくつかのメカニズム、例えば、ＩＥＴＦ  ＣＸＴＰ、ＳＩＰ方式、例えば、ＭＥＳＳＡＧＥ、ＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹ等は、この目的のために使用することが可能である。
・呼の流れ
図１２は、ＳＡ鍵がＳ−ＣＳＣＦから新たなＰ−ＣＳＣＦに伝送される最適化されたＩＰＳｅｃについての呼の流れを表わす。図には、この最適化された部分の間に要求される一連のステップを表わす。
【００４５】
これらのメッセージ交換は、プロアクティブな、および、リアクティブなハンドオーバ時間の間に生じうる。しかし、プロアクティブなハンドオーバ技術は、リアクティブなハンドオーバより大きな範囲まで遅延を最小化することに役立ちうる。上述したように、ＭＩＰバインディング更新およびＳＩＰ初期登録のシグナリングポートが新たなＰＤＳＮにおいて常にオープンしていることが必要である。
図１２において、モバイルノード（ＭＮ）がハンドオーバする先の新たなＰ−ＣＳＣＦと、Ｓ−ＣＳＣＦとを備える。Ｓ−ＣＳＣＦは、モバイルノードから新たなＰ−ＣＳＣＦのアドレスを受信し、新たなＰ−ＣＳＣＦにセキュリティアソシエーション（ＳＡ）鍵を含むコンテキストを伝送する。新たなＰ−ＣＳＣＦは、モバイルノードのためのセキュリティアソシエーションを確立し、新たなＰＤＳＮにおいてモバイルノードのためのゲートをオープンする。
【００４６】
ＩＰＳｅｃトンネルのオーバーヘッドは、ＩＭＳ／ＭＭＤアーキテクチャにおける重要な課題である。図１３は、ＩＰＳｅｃによってエンドエンド間のセキュリティが提供され、ＭＮノードが移動管理のために、特にアーキテクチャＩＩｂのためにＭＩＰｖ６を用いる場合に要求されるトンネルの数を表わす。実際、これはより小さい組み込み機器についての課題である。
【００４７】
そのようなトンネルのオーバーヘッドを軽減することは容易ではない。しかし、課題を分類し、これに対応してそれらを軽減するいくつかの方法が存在する。
・まず、ＩＭＳ／ＭＭＤアーキテクチャにおいて、ＩＭ（Instant Messaging）サービスは、アクセスが許可される前に、移動局とＩＭＳとの間に新たなセキュリティアソシエーションを要求する。従って、ＭＮとＰ−ＣＳＣＦとの間のＳＩＰメッセージを保護しないので、ＭＮとＰ−ＣＳＣＦとの間の接続を緩和することはできない。ＩＰＳｅｃトンネルを無効にすることは可能であるが、（１）相互運用性および標準に非準拠、（２）登録されていないユーザがネットワークリソースを乱用する穴を空ける、等の他の影響を有する。一方、３ＧＰＰ  ＩＭＳは、シグナリングを安全にするために、ＴＬＳのような代わりのメカニズムを提供することによってそのような制約を緩和することを最近検討している。ＴＬＳはＩＭＳ／ＭＭＤ標準として受け入れられ、従って、そのようなトンネルのオーバーヘッドの課題を軽減することに役立ちうると考えられる。従って、トンネルのオーバーヘッドが課題である、より小型の機器についてＭＮとＰ−ＣＳＣＦとの間のシグナリングを保護するためにＩＰＳｅｃの代わりとしてＴＬＳの検討を推奨する。
・次に、ＭＩＰｖ６について、プロトコル動作はＭＮとＨＡとの間の最小値においてＩＰ−ＩＰトンネルを確立することを要求し、それによって、トロンボーンルーティングとしても知られるルーティングのループを生成する。ＰＤＳＮが（ＭＩＰｖ４におけるＦＡのような）プロキシＭＩＰｖ６クライアントとして動作するならば、ＭＮからのこのトンネルは軽減することが可能であり、ＭＮに代わってＨＡとのトンネルを生成する。しかし、ＰＤＳＮがＭＮと同じレイヤ２リンクに存在することを要求するので、全ての場合において実現可能とは限らず、相互運用性の問題を有する非標準の解決策である。他の代替は、シームレスな移動性をサポートするために他の移動メカニズム（例えば、ＳＩＰ）を用いることである。
・一方、エンドエンド間のセキュリティについて、メディアのセキュリティを危うくすることなく、（ＭＮとＨＡとの間の）ＩＰＳｅｃトンネルを、ＴＬＳ、ＳＲＴＰ、ＳＭＩＭＥのようなアプリケーションレイヤのセキュリティメカニズムと置換可能である。コンテンツのセキュリティのみが重要であるシナリオにおいて、ＳＲＴＰまたはＳＭＩＭＥのようなメカニズムがよりよい。そのような場合における鍵管理が課題でありうるが、現在のネットワークアーキテクチャについてこれは管理可能であるべきである（この段階において、プロバイダ間のローミングは要求されない）。また、ＩＰＳｅｃがＭＮとＨＡとの間のコンテンツのセキュリティのために用いられるならば、ＩＰＳｅｃの移動性は、ＳＡがＩＰアドレスと対応付けられるか否かに応じてもう１つの課題である。
【図面の簡単な説明】
【００４８】
【図１】ＩＭＳセキュリティアーキテクチャを表わす図である。
【図２】ＩＭＳ  ＡＫＡのメッセージの流れを表わす図である。
【図３】トランスポートモードにおけるＥＳＰを表わす図である。
【図４】ユーザデータのセキュリティを表わす図である。
【図５】（ＭＩＰｖ６の場合に）全てのＰ−ＣＳＣＦがホームネットワークに存在する場合に要求されるトンネルを表わす図である。
【図６】（ＭＩＰｖ４の場合に）全てのＰ−ＣＳＣＦがホームネットワークに存在する場合に要求されるトンネルを表わす図である。
【図７】（ＭＩＰｖ６の場合に）全てのＰ−ＣＳＣＦが訪問先ネットワークに存在する場合に要求されるトンネルを表わす図である。
【図８】（ＭＩＰｖ４の場合に）全てのＰ−ＣＳＣＦが訪問先ネットワークに存在する場合に要求されるトンネルを表わす図である。
【図９】（ＭＩＰｖ６の場合に）Ｐ−ＣＳＣＦが各サブネットに存在する場合に要求されるトンネルを表わす図である。
【図１０】（ＭＩＰｖ４の場合に）Ｐ−ＣＳＣＦが各サブネットに存在する場合に要求されるトンネルを表わす図である。
【図１１】最適化されたＩＰＳｅｃの呼の流れ（鍵はＰ−ＣＳＣＦによって伝送される）を表わす図である。
【図１２】最適化されたＩＰＳｅｃの呼の流れ（鍵はＳ−ＣＳＣＦによって伝送される）を表わす図である。
【図１３】（シグナリングおよびメディアのために）ＭＮから要求されるＩＰＳｅｃトンネルの数を表わす図である。
【符号の説明】
【００４９】
Ｓ１００，Ｓ２００…ＩＰＳｅｃ最適化システム
【図１】
2008072694.tif 000003
【図２】
2008072694.tif 000004
【図３】
2008072694.tif 000005
【図４】
2008072694.tif 000006
【図５】
2008072694.tif 000007
【図６】
2008072694.tif 000008
【図７】
2008072694.tif 000009
【図８】
2008072694.tif 000010
【図９】
2008072694.tif 000011
【図１０】
2008072694.tif 000012
【図１１】
2008072694.tif 000013
【図１２】
2008072694.tif 000014
【図１３】
2008072694.tif 000015