JP7188855B2 - セキュリティアソシエーションｓａのキー変更の方法、ネットワークデバイス、および、ネットワークシステム - Google Patents

Description

［関連出願の相互参照］
本願は、２０１８年１１月１５日出願の「Ｒｅｋｅｙｉｎｇ Ａ Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ ＳＡ」と題するインド特許出願第ＩＮ２０１８３１０４２９５５号の優先権を主張し、これは、その全体が参照により本明細書に組み込まれる。

本明細書の開示は、一般に、遠距離通信に関し、より具体的にはインターネットセキュリティプロトコル、さらにより具体的には、電力、帯域幅、および／または処理能力が限定されているモバイルデバイス用などのセキュリティアソシエーションをキー変更するための方法、デバイス、システムに関する。

インターネットキー交換バージョン２（ＩＫＥｖ２）は、ＲＦＣ７２９６により規定されるプロトコルであり、これは、本明細書の明示的な開示に反している場合を除いて、本明細書に完全に記載されているかのように全目的において参照により組み込まれる。本明細書で使用する用語は、本明細書の明示的な開示に反している場合を除いて、ＲＦＣ７２９６により与えられる意味を有する。

ＩＫＥｖ２は、ＩＰＳｅｃプロトコルスイートにおいてセキュリティアソシエーション（ＳＡ）をセットアップするために使用される。セキュリティアソシエーション（ＳＡ）は、ＩＫＥトンネルまたはＩＰｓｅｃトンネルであり得る。インターネットプロトコルセキュリティ（ＩＰＳｅｃ）は、ネットワークを介して送信されたデータのパケットを認証して暗号化するネットワークプロトコルスイートである。

ＩＫＥメッセージフローは、要求と、それに続く応答とを含む。信頼性を確保するのはリクエスタの責任である。タイムアウト間隔内に応答が受信されない場合、リクエスタは、要求を再送する（または接続を中止する）必要がある。ＩＫＥセッション（ＩＫＥ＿ＳＡ＿ＩＮＩＴ）のレクエスタおよびレスポンダとの間の第１の要求／応答メッセージ対は、ＩＫＥ＿ＳＡのためのセキュリティパラメータをネゴシエーションし、ノンスを送信し、Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ値を送信する。第２の要求／応答メッセージ対（ＩＫＥ＿ＡＵＴＨ）は、アイデンティティを伝送し、２つのアイデンティティに対応する秘密の知識を証明し、第１の（およびそれのみの場合が多い）認証ヘッダ（ＡＨ）および／またはカプセル化セキュリティペイロード（ＥＳＰ）ＣＨＩＬＤ＿ＳＡのためのＳＡをセットアップする。

ＩＫＥｖ２におけるＩＫＥキー変更手順は、ＲＦＣ７２９６に規定され、これは、本明細書の明示的な開示に反している場合を除いて、本明細書に完全に記載されているかのように全目的において参照により組み込まれる。本明細書で使用する用語は、本明細書の明示的な開示に反している場合を除いて、ＲＦＣ７２９６により与えられる意味を有する。

定義上、キー変更は、ＳＡが失効する前に失効するＳＡの代わりとなる新しいＳＡを作成することである。

例えば、リクエスタとレスポンダとの間のＩＫＥキー変更交換は、１または複数のＳＡペイロードを保持し、これらの１または複数のＳＡペイロード自体が１または複数の提案ペイロードを含む。各提案は、暗号スイートの単一の組（例えば、単一または複数の暗号スイート）を含む。通常、これらのスイートは、キー変更時に変更されない。ＳＡペイロードの最小サイズ（例えば、暗号スイートの単一の組の場合）は、典型的には、５２バイトである。ＩＫＥキー変更の場合、可能な最小サイズは４４バイトである。これは、４４バイトのＳＡペイロードサイズおよび４０バイトの提案サイズを含み得る。最小は、ＳＡペイロードにおいて選択されて送信される暗号スイートのタイプおよび数によって決定される。

ＳＡペイロード構造は、典型的には、ＳＡペイロード、提案、トランスフォーム、および属性を含む。ＳＡペイロード下では、プロトコルＩＤおよびＳＰＩを含む１つまたは２つ以上の提案ペイロードが存在し、提案ペイロード下では、暗号アルゴリズムを含むトランスフォーム、および任意にキー長を含む属性が存在する。例えば属性を指定することにより、特定の提案をさらに規定することで、ＳＡペイロードサイズが大きくなる。当業者は、従来のＳＡペイロードは、ＲＦＣ７２９６の３．３節に詳細に開示されていることを理解するであろう。

例えば、リクエスタとレスポンダとの間のＩＰＳｅｃキー変更交換はまた、暗号スイート（例えば、単一または複数の暗号スイート）と併せてＴＳペイロード（例えば、ＴＳｉおよびＴＳｒペイロード）を含むＳＡペイロードを保持する。ほとんどの場合、これらのペイロードはキー変更時に変更されず、これはＩＫＥキー変更手順と類似している。通常、ＳＡペイロードの最小サイズは４０バイトであり、各ＴＳサイズは２４バイトである（２×２４＝４８バイト）。

図１Ａは、従来のＳＡペイロードの構造のいくつかの例を提供する。第１のＳＡペイロードは属性を含まず、第２のＳＡペイロードは属性を含み、２つのＳＡペイロードの各々は１つの提案を含む。第３のＳＡペイロードは、各々が属性を含む２つの提案を含む。

ＩＫＥおよび／またはＩＰＳｅｃ ＳＡのキー変更において複数の暗号スイートについてペイロードサイズは比例関係で大きくなる。このキー変更は周期的にトリガされる。各キー変更は、これらのペイロードを処理するために帯域幅および電力を消費する。

この概要は、セキュリティアソシエーションをキー変更するための方法、デバイス、およびシステムに関する概念を導入するために提供される。さらに、既知のＳＡキー変更プロセスで交換される既存のタイプのメッセージは修正される。さらに、ＳＡキー変更プロセスのための新しいメッセージが導入される。本開示はＩＫＥｖ２を参照して議論されるものの、本発明は他のキー変更メカニズムに同等に適用され得ることが理解されるであろう。

第１の態様によれば、本願の一実施形態は、第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更する方法を提供し、第１のネットワークデバイスと第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）トンネルおよびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立される。本方法では、第１のネットワークデバイスは、ＳＡをキー変更するために第１のキー変更要求を第２のネットワークデバイスに送信する。第１のキー変更要求は、第１のセキュリティパラメータインデックス（ＳＰＩ）、および第１のネットワークデバイスに関連付けられる暗号スイートを保持する。その後、第１のネットワークデバイスは、第２のネットワークデバイスから第１のキー変更応答を受信する。第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更応答は、第２のＳＰＩを保持し、第２のネットワークデバイスに関連付けられる暗号スイートを保持しない。次に、第１のネットワークデバイスは、第１のＳＰＩ、第１のネットワークデバイスに関連付けられる暗号スイート、および第２のＳＰＩに応じてＳＡをキー変更する。

先述の技術的解決手段では、第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合にはキー変更応答内に暗号スイートを保持しないことにより、キー変更の場合においてペイロードのサイズが小さくなり、例えばＩＫＥ ＳＡキー変更またはＩＰｓｅｃ ＳＡキー変更のいずれかのためのＳＡキー変更の過程において帯域幅、より多くの処理時間、および電力が節約される。

第２の態様によれば、本願の一実施形態は、第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更する方法を提供し、第１のネットワークデバイスと第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）トンネルおよびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立される。本方法では、第２のネットワークデバイスは、ＳＡをキー変更するために第１のネットワークデバイスから第１のキー変更要求を受信し、第１のキー変更要求は、第１のセキュリティパラメータインデックス（ＳＰＩ）、および第１のネットワークデバイスに関連付けられる暗号スイートを保持する。その後、第２のネットワークデバイスは、第２のネットワークデバイスに関連付けられる暗号スイートに変更があるかどうかを決定する。次に、第２のネットワークデバイスは、第１のキー変更応答を第１のネットワークデバイスに送信し、第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更応答は、第２のＳＰＩを保持し、第２のネットワークデバイスに関連付けられる暗号スイートを保持しない。その後、第２のネットワークデバイスは、第１のＳＰＩおよび第２のＳＰＩに応じてＳＡをキー変更する。具体的には、第２のネットワークデバイスに関連付けられる現在使用中の暗号スイートは変更されず、ＳＡのために使用され、第１のキー変更要求に保持される第１のネットワークデバイスに関連付けられる暗号スイート内に存在している。キー変更は、第２のネットワークデバイスに関連付けられる現在使用中の暗号スイートにさらに応じたものである。

先述の技術的解決手段では、第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合にはキー変更応答内に暗号スイートを保持しないことにより、キー変更の場合においてペイロードのサイズが小さくなり、例えばＩＫＥ ＳＡキー変更またはＩＰｓｅｃ ＳＡキー変更のいずれかのためのＳＡキー変更の過程において帯域幅、より多くの処理時間、および電力が節約される。

第３の態様によれば、本願の一実施形態は、第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更するためのネットワークデバイスを提供し、第１のネットワークデバイスと第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）およびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立される。この態様では、ネットワークデバイスは第１のネットワークデバイスとして構成され、送信モジュール、受信モジュール、キー変更モジュールを含む。送信モジュールは、ＳＡをキー変更するために第１のキー変更要求を第２のネットワークデバイスに送信するように構成され、第１のキー変更要求は、第１のセキュリティパラメータインデックス（ＳＰＩ）、および第１のネットワークデバイスに関連付けられる暗号スイートを保持する。受信モジュールは、第２のネットワークデバイスから第１のキー変更応答を受信するように構成され、第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更応答は、第２のＳＰＩを保持し、第２のネットワークデバイスに関連付けられる暗号スイートを保持しない。キー変更モジュールは、第１のＳＰＩおよび第２のＳＰＩに応じてＳＡをキー変更するように構成される。

先述の技術的解決手段では、キー変更応答内に暗号スイートを保持しないことにより、キー変更の場合においてペイロードのサイズが小さくなり、例えばＩＫＥ ＳＡキー変更またはＩＰｓｅｃ ＳＡキー変更のいずれかのためのＳＡキー変更の過程において帯域幅、より多くの処理時間および電力が節約される。

第４の態様によれば、本願の一実施形態は、第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更するためのネットワークデバイスを提供し、第１のネットワークデバイスと第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）およびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立される。この態様では、ネットワークデバイスは第２のネットワークデバイスとして構成され、受信モジュール、決定モジュール、送信モジュール、およびキー変更モジュールを含む。受信モジュールは、ＳＡをキー変更するために第１のネットワークデバイスから第１のキー変更要求を受信するように構成され、第１のキー変更要求は、第１のセキュリティパラメータインデックス（ＳＰＩ）、および第１のネットワークデバイスに関連付けられる暗号スイートを保持する。決定モジュールは、第２のネットワークデバイスに関連付けられる暗号スイートに変更があるかどうかを決定するように構成される。送信モジュールは、第１のキー変更応答を第１のネットワークデバイスに送信するように構成され、第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更応答は、第２のＳＰＩを保持し、第２のネットワークデバイスに関連付けられる暗号スイートを保持しない。キー変更モジュールは、第１のＳＰＩおよび第２のＳＰＩに応じてＳＡをキー変更するように構成される。

先述の技術的解決手段では、キー変更応答内に暗号スイートを保持しないことにより、キー変更の場合においてペイロードのサイズが小さくなり、例えばＩＫＥ ＳＡキー変更またはＩＰｓｅｃ ＳＡキー変更のいずれかのためのＳＡキー変更の過程において帯域幅、より多くの処理時間および電力が節約される。

第５の態様によれば、本願の一実施形態は、第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更する方法を提供し、第１のネットワークデバイスと第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）トンネルおよびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立される。本方法では、第１のネットワークデバイスは、ＳＡをキー変更するために第１のキー変更要求を第２のネットワークデバイスに送信する。第１のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更要求は、第１のセキュリティパラメータインデックス（ＳＰＩ）を保持し、第１のネットワークデバイスに関連付けられる暗号スイートを保持しない。第１のネットワークデバイスは、第２のネットワークデバイスから第１のキー変更応答を受信する。第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更応答は、第２のＳＰＩを保持し、第２のネットワークデバイスに関連付けられる暗号スイートを保持しない。第１のネットワークデバイスは、第１のＳＰＩおよび第２のＳＰＩに応じてＳＡをキー変更する。

先述の技術的解決手段では、キー変更応答内に暗号スイートを保持しないことにより、キー変更の場合においてペイロードのサイズが小さくなり、例えばＩＫＥ ＳＡキー変更またはＩＰｓｅｃ ＳＡキー変更のいずれかのためのＳＡキー変更の過程において帯域幅、より多くの処理時間および電力が節約される。

第６の態様によれば、本願の一実施形態は、第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更する方法を提供し、第１のネットワークデバイスと第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）トンネルおよびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立される。本方法では、第２のネットワークデバイスは、ＳＡをキー変更するために第１のネットワークデバイスから第１のキー変更要求を受信する。第１のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更要求は、第１のセキュリティパラメータインデックス（ＳＰＩ）を保持し、第１のネットワークデバイスに関連付けられる暗号スイートを保持しない。第２のネットワークデバイスは、第１のキー変更応答を第１のネットワークデバイスに送信する。第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更応答は、第２のＳＰＩを保持し、第２のネットワークデバイスに関連付けられる暗号スイートを保持しない。第２のネットワークデバイスは、第１のＳＰＩおよび第２のＳＰＩに応じてＳＡをキー変更する。

先述の技術的解決手段では、キー変更要求およびキー変更応答内に暗号スイートを保持しないことにより、キー変更の場合においてペイロードのサイズが小さくなり、例えばＩＫＥ ＳＡキー変更またはＩＰｓｅｃ ＳＡキー変更のいずれかのためのＳＡキー変更の過程において帯域幅、より多くの処理時間および電力が節約される。ＩＫＥおよびＩＰｓｅｃ ＳＡキー変更シナリオの両方におけるキー変更の間、複数の暗号スイートの場合ではペイロードサイズは比例関係で小さくなる。

第７の態様によれば、本願の一実施形態は、第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更するためのネットワークデバイスを提供し、第１のネットワークデバイスと第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）およびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立される。この態様では、ネットワークデバイスは第１のネットワークデバイスとして構成され、送信モジュール、受信モジュール、およびキー変更モジュールを含む。送信モジュールは、ＳＡをキー変更するために第１のキー変更要求を第２のネットワークデバイスに送信するように構成され、第１のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更要求は、第１のセキュリティパラメータインデックス（ＳＰＩ）を保持し、第１のネットワークデバイスに関連付けられる暗号スイートを保持しない。受信モジュールは、第２のネットワークデバイスから第１のキー変更応答を受信するように構成され、第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更応答は、第２のＳＰＩを保持し、第２のネットワークデバイスに関連付けられる暗号スイートを保持しない。キー変更モジュールは、第１のＳＰＩおよび第２のＳＰＩに応じてＳＡをキー変更するように構成される。

先述の技術的解決手段では、キー変更応答内に暗号スイートを保持しないことにより、キー変更の場合においてペイロードのサイズが小さくなり、例えばＩＫＥ ＳＡキー変更またはＩＰｓｅｃ ＳＡキー変更のいずれかのためのＳＡキー変更の過程において帯域幅、より多くの処理時間および電力が節約される。

第８の態様によれば、本願の一実施形態は、第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更するためのネットワークデバイスを提供し、第１のネットワークデバイスと第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）およびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立される。この態様では、ネットワークデバイスは第２のネットワークデバイスとして構成され、受信モジュール、送信モジュール、およびキー変更モジュールを含む。受信モジュールは、ＳＡをキー変更するために第１のネットワークデバイスから第１のキー変更要求を受信するように構成される。第１のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更要求は、第１のセキュリティパラメータインデックス（ＳＰＩ）を保持し、第１のネットワークデバイスに関連付けられる暗号スイートを保持しない。送信モジュールは、第１のキー変更応答を前記第１のネットワークデバイスに送信するように構成される。第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更応答は、第２のＳＰＩを保持し、第２のネットワークデバイスに関連付けられる暗号スイートを保持しない。キー変更モジュールは、第１のＳＰＩおよび第２のＳＰＩに応じてＳＡをキー変更するように構成される。

先述の技術的解決手段では、キー変更応答内に暗号スイートを保持しないことにより、キー変更の場合においてペイロードのサイズが小さくなり、例えばＩＫＥ ＳＡキー変更またはＩＰｓｅｃ ＳＡキー変更のいずれかのためのＳＡキー変更の過程において帯域幅、より多くの処理時間および電力が節約される。

第９の態様によれば、本願の一実施形態は、セキュリティアソシエーション（ＳＡ）をキー変更するためのシステムを提供し、ネットワークシステムは、第３の態様による第１のネットワークデバイスおよび第４の態様による第２のネットワークデバイスを含む。

第１０の態様によれば、本願の一実施形態は、セキュリティアソシエーション（ＳＡ）をキー変更するためのシステムを提供し、ネットワークシステムは、第７の態様による第１のネットワークデバイスおよび第８の態様による第２のネットワークデバイスを含む。

先述の技術的解決手段では、キー変更要求およびキー変更応答内に暗号スイートを保持しないことにより、キー変更の場合においてペイロードのサイズが小さくなり、例えばＩＫＥ ＳＡキー変更またはＩＰｓｅｃ ＳＡキー変更のいずれかのためのＳＡキー変更の過程において帯域幅、より多くの処理時間および電力が節約される。ＩＫＥおよびＩＰｓｅｃ ＳＡキー変更シナリオの両方におけるキー変更の間、複数の暗号スイートの場合ではペイロードサイズは比例関係で小さくなる。

第１１の態様によれば、本願の一実施形態は、第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更するためのネットワークデバイスを提供する。第１のネットワークデバイスと第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）およびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立される。この態様では、ネットワークデバイスは、第１のネットワークデバイスとして構成される。ネットワークデバイスは、プロセッサおよびメモリを含む。メモリは、ソフトウェアの命令を格納するように構成される。プロセッサは、メモリ内のソフトウェアの命令を実行し、第２のネットワークデバイスに、上記の第１の態様または第５の態様による方法を実行させるように構成される。

第１２の態様によれば、本願の一実施形態は、第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更するためのネットワークデバイスを提供する。第１のネットワークデバイスと第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）およびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立される。この態様では、ネットワークデバイスは、第２のネットワークデバイスとして構成される。ネットワークデバイスは、プロセッサおよびメモリを含む。メモリは、ソフトウェアの命令を格納するように構成される。プロセッサは、メモリ内のソフトウェアの命令を実行し、第２のネットワークデバイスに、上記の第２の態様または第６の態様による方法を実行させるように構成される。

先述の技術的解決手段では、キー変更要求およびキー変更応答内に暗号スイートを保持しないことにより、キー変更の場合においてペイロードのサイズが小さくなり、例えばＩＫＥ ＳＡキー変更またはＩＰｓｅｃ ＳＡキー変更のいずれかのためのＳＡキー変更の過程において帯域幅、より多くの処理時間および電力が節約される。ＩＫＥおよびＩＰｓｅｃ ＳＡキー変更シナリオの両方におけるキー変更の間、複数の暗号スイートの場合ではペイロードサイズは比例関係で小さくなる。

第１３の態様によれば、本願の一実施形態は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、上述の第１の態様、第２の態様、第５の態様、および第６の態様のいずれか１つによる方法を実行するために使用されるコンピュータソフトウェア命令を格納するように構成される。

先述の技術的解決手段では、キー変更要求およびキー変更応答内に暗号スイートを保持しないことにより、キー変更の場合においてペイロードのサイズが小さくなり、例えばＩＫＥ ＳＡキー変更またはＩＰｓｅｃ ＳＡキー変更のいずれかのためのＳＡキー変更の過程において帯域幅、より多くの処理時間および電力が節約される。ＩＫＥおよびＩＰｓｅｃ ＳＡキー変更シナリオの両方におけるキー変更の間、複数の暗号スイートの場合ではペイロードサイズは比例関係で小さくなる。

添付の図面と合わせて本発明の具体的な実施形態の以下の説明を検討すれば、当業者には本発明の他の態様および特徴が明らかになるであろう。

詳細な説明は、添付の図面を参照して説明される。図面において、参照番号の最左端の数字は、その参照番号が最初に現れる図を識別する。図面全体にわたり、同様の特徴および構成要素を指すために同じ数字が使用される。

従来技術によるいくつかのＳＡペイロードの構造を例示する。

従来技術によるＩＫＥ ＳＡキー変更フローチャートを例示する。

削除要求の構造の一例を例示する。

従来技術によるＩＰｓｅｃ ＳＡキー変更を例示する。

本開示の実施形態による、イニシエータとレスポンダとの間の軽量キー変更のサポートをネゴシエーションするフローチャートを例示する。

通知ペイロードの構造の一例を例示する。

本開示の実施形態による、イニシエータとレスポンダとの間の軽量キー変更のサポートをネゴシエーションする別のフローチャートを例示する。

本開示の実施形態による、イニシエータとレスポンダとの間の軽量キー変更のサポートをネゴシエーションするさらに別のフローチャートを例示する。

本開示の一実施形態による軽量キー変更アプローチを使用したＳＡのキー変更のフローチャートを例示する。

本開示の一実施形態による軽量キー変更アプローチを使用したＩＫＥ ＳＡのキー変更のフローチャートを例示する。

ＩＫＥ ＳＡキー変更パケットフォーマットの一例を例示する。

ＩＫＥのためのＮＥＷ＿ＳＰＩペイロードの一例を例示する。

ＩＫＥのための軽量ＳＡペイロードの一例を例示する。

提案未選択通知ペイロードの構造の一例を例示する。

本開示の一実施形態による特定のシナリオにおけるＩＫＥ ＳＡのキー変更のフローチャートを例示する。

本開示の別の実施形態による軽量キー変更アプローチを使用したＩＫＥ ＳＡのキー変更の別のフローチャートを例示する。

本開示の一実施形態による軽量キー変更アプローチを使用したＩＰＳｅｃ ＳＡのキー変更のフローチャートを例示する。

ＩＰＳｅｃ ＳＡキー変更パケットフォーマットの一例を例示する。

ＡＨのためのＮＥＷ＿ＳＰＩペイロードの一例を例示する。

ＩＰＳｅｃ ＳＡのための新たに規定されたペイロードである軽量ＳＡの２つの例を例示する。

本開示の一実施形態による特定のシナリオにおけるＩＰＳｅｃ ＳＡのキー変更のフローチャートを例示する。

本開示の別の実施形態による軽量キー変更アプローチを使用したＩＰＳｅｃ ＳＡのキー変更の別のフローチャートを例示する。

本開示の一実施形態によるＳＡのキー変更のためのイニシエータとして動作するネットワークデバイスの概略図を例示する。

本開示の一実施形態によるＳＡのキー変更のためのレスポンダとして動作するネットワークデバイスの概略図を例示する。

本開示の別の実施形態によるＳＡのキー変更のためのレスポンダとして動作するネットワークデバイスの概略図を例示する。

本開示の実施形態によるＳＡのキー変更のためのイニシエータまたはレスポンダとして動作するネットワークデバイスの概略図を例示する。

本開示の実施形態によるＳＡのキー変更のためのネットワークシステムの概略図を例示する。

本発明は、プロセス、装置、システム、コンピュータ可読記憶媒体などのコンピュータ可読媒体、またはコンピュータネットワークとして数々の方法で実装され得、プログラム命令は、様々なタイプの、例えば光または電子通信リンクを介して送信される。本明細書では、これらの実装、または本発明が採り得る任意の他の形態は、技術と称され得る。一般的に、開示されるプロセスの段階の順序は、本発明の範囲内で変更され得る。

本発明の原理を例示する添付の図面と共に、本発明の１または複数の実施形態の詳細な説明が以下に提供される。本発明はそのような実施形態と関連して説明されるが、本発明はいかなる実施形態にも限定されない。本発明の範囲は特許請求の範囲のみによって限定され、本発明は、数々の代替物、修正、および等価物を包含する。数々の具体的な詳細は、本発明の完全な理解を提供するために以下の説明において記載される。これらの詳細は、例示の目的のために提供され、本発明は、これらの具体的な詳細の一部または全部を伴わずに、特許請求の範囲に従って実践され得る。明確性の目的のため、本発明が不必要に不明瞭とならないように、本発明が関連する技術分野で既知の技術的材料については詳細に説明しない。

以下の詳細な説明において、本発明の完全な理解を提供するために数々の具体的な詳細が記載される。しかしながら、当業者であれば、本開示がこれらの具体的な詳細を伴わずに実践され得ることを理解するであろう。他の例では、周知の方法、手順、ならびに構成要素、モジュール、ユニット、および／または回路については、本発明を不明瞭にしないために、詳細に説明しない。

本発明の実施形態はこの点では限定されないものの、例えば、「処理する」、「計算する」、「決定する」、「確立する」、「作成する」、または「確認する」などの用語を利用した議論は、コンピュータのレジスタおよび／またはメモリ内の物理（例えば、電子）として表されるデータを、物理量として同様に表されるコンピュータのレジスタおよび／またはメモリ内の他のデータへと操作および／または変換する、コンピュータ、コンピューティングプラットフォーム、コンピューティングシステム、または他の電子演算デバイス、または動作および／またはプロセスを実行するための命令を格納し得るまたは他の情報非一時的記憶媒体の動作および／または処理を指し得る。

図１Ｂに示されるように、キー変更フローチャートは、第１のネットワークデバイス（例えば、リクエスタ、またはイニシエータと呼ばれる場合もある）と第２のネットワークデバイス（例えば、レスポンダ）との間にＩＫＥおよびＩＰＳｅｃ ＳＡが確立された後に生じる。

本開示の実施形態では、第１のネットワークデバイスまたは第２のネットワークデバイスは、コンピュータ、モバイルデバイス（例えば、モバイル電話）、遠隔健康管理デバイス、ゲートウェイ、ルータ、サーバ、およびアクセスポイント（ＡＰ）デバイス埋込センサ、ＩＰスタックを有するホームデバイスまたはパーソナルデバイスの群からのいずれか１つを含み得る。特に、ネットワークデバイスのうちの１つは、電源、処理能力、または帯域幅能力が限定されているデバイスであり得る。そのような場合、ペイロードのサイズおよび／または数を全体的に低減することができ、それにより、処理電力、時間、およびしたがって電力消費が節約されるため、本発明は特に有利である。

また、本開示の実施形態では、ネットワークデバイスの他のものは、多くの複数のＩＫＥ／ＩＰｓｅｃトンネルをサポートすることができるセキュリティゲートウェイ／ｅＰＤＧまたはＣＲＡＮ／クラウドベースのデバイスであり得る。そのような場合、伝送されるデータを低減することにより、帯域幅およびパケット分割、ならびに結果として処理要件を低減することができる。

ＩＫＥ＿ＳＡ＿ＩＮＩＴおよびＩＫＥ＿ＡＵＴＨ交換を含む初期交換（動作１０２～１０８）が実行された後に、ＩＫＥ ＳＡおよびＩＰＳｅｃ ＳＡが確立される（動作１１０）。これらの初期交換は通常、４つのメッセージを含むが、いくつかのシナリオではその数字は大きくなり得る。第１のメッセージ対（ＩＫＥ＿ＳＡ＿ＩＮＩＴ）は、暗号スイートをネゴシエーションし、ノンスおよびＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ（ＤＨ）を交換する。第２のメッセージ対（ＩＫＥ＿ＡＵＴＨ）は、前のメッセージを認証し、アイデンティティおよび証明書を交換し、暗号スイートおよびトラフィックセレクタ（ＴＳ）をネゴシエーションし、第１の子ＳＡを確立する。これらのメッセージの一部は暗号化され、ＩＫＥ＿ＳＡ＿ＩＮＩＴ交換を通じて確立されたキーで完全性保護されている。初期交換に続くメッセージは、暗号アルゴリズムおよびＩＫＥ＿ＳＡ＿ＩＮＩＴ交換でネゴシエーションされたキーを使用して暗号保護されている。ＩＫＥ ＳＡおよびＩＰＳｅｃ ＳＡの各々について、秘密鍵は通常、限定された時間内に使用され、これはＳＡの有効期間と呼ばれ得る。有効期間が失効しそうになると、新しいＳＡを作成し、古いＳＡを削除することを通じて、ＳＡがキー変更される。初期交換の詳細な手順については、当業者は、本明細書の明示的な開示に反している場合を除いて本明細書に完全に記載されているかのように全目的において参照により組み込まれるＲＦＣ７２９６を参照されたい。

ＩＫＥ ＳＡおよびＩＰＳｅｃ ＳＡが確立された後（動作１１０）、ＩＫＥ ＳＡおよびＩＰＳｅｃ ＳＡのいずれか１つの有効期間が失効しそうな場合、第１のネットワークデバイスおよび第２のネットワークデバイスはＳＡキー変更手順を実行する。

第１のネットワークデバイスまたは第２のネットワークデバイスのいずれかが、ＳＡキー変更要求を開始することができ、これは、これらのデバイスの各々が自身の側でＳＡの有効期間を管理する有効期間ポリシーを維持し得るためであることを理解すべきである。別の実施形態では、両方の側が、共有するＳＡについて同じ有効期間を有し得る。第１のネットワークデバイスまたは第２のネットワークデバイスは、ＳＡキー変更を周期的にトリガし得る。他のシナリオでは、デバイスは、デバイスに関連付けられる各ＳＡの将来の失効を検出し、その後、デバイスが、ＩＫＥ ＳＡまたはＩＰＳｅｃ ＳＡの秘密鍵が失効しそうであることを検出した場合にＳＡキー変更プロセスを開始し得る。

その名称が示唆するように、ＳＡキー変更は、ポリシーが変更されていない限り、現在のＳＡと同じＳＡ属性を有する新しい鍵でＳＡを作成することを指す。ポリシーの変更とは、例えば、エンドユーザが暗号ポリシー（暗号スイートとも呼ばれ得る）および／もしくは暗号スイートの有効期間を変更した場合、または子ＳＡキー変更の場合にはフローポリシー（フロー情報とも呼ばれ得る）を変更した場合であり得る。フロー情報は、例えば、発信元および宛先ＩＰアドレス、ポート範囲、またはポート番号を含み得る。ＳＡのキー変更は、ＳＡのためのキーを再作成することを含み、すなわち、キーが変更され、確立されたＳＡの他の要素は変更されてもよいし、されなくてもよい。

ＩＫＥ ＳＡキー変更を開始する第１のネットワークデバイスを例にとる。第１のネットワークデバイスは、ＩＫＥ ＳＡをキー変更するためにキー変更要求を第２のネットワークデバイスに送信する。一実施形態では、ＩＫＥ ＳＡをキー変更するためにＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ交換が使用される。この交換は、要求／応答対を含む。この交換は、初期交換が完了した後に、ＩＫＥ ＳＡのいずれかのエンド（例えば、第１のネットワークデバイスまたは第２のネットワークデバイス）によって開始されてもよい。ＳＡキー変更を開始するエンドはイニシエータとみなされ得、イニシエータのピア側がレスポンダとしてみなされる。

一実施形態によれば、ＩＫＥ ＳＡのキー変更は、少なくとも以下の動作を含み得る。

動作１１２、イニシエータがＩＫＥ ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求をレスポンダに送信する。

ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、ＩＫＥヘッダ（ペイロードではない）であるＨＤＲ、およびペイロードを含む。ペイロードは、ＳＡペイロード、Ｎｉペイロード、およびＫＥｉペイロードを含む。ＳＡペイロードは、ＳＡオファー、例えば、イニシエータがサポートする１または複数の暗号スイートを含む。暗号スイートは、認証アルゴリズム、暗号化アルゴリズム、および／またはキー計算のためのＤＨ群を含み得る。さらに、ＳＡペイロードはまた、ＳＡペイロードのＳＰＩフィールドにおいて供給される、新しいイニシエータであるセキュリティパラメータインデックス（ＳＰＩ）を含み得る。ＳＡペイロード内の新しいイニシエータＳＰＩはレスポンダによって取得され、新しい鍵は、レスポンダ側で計算される。Ｎｉペイロードはノンスを含み、ＫＥｉペイロードはＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ値を含む。本開示では、「暗号スイート」という用語は、ＳＡを保護するために使用される一組のアルゴリズムを指す。ＩＰＳｅｃ ＳＡまたはＩＫＥ ＳＡの状況では、暗号スイートはまた、ある特定の状況下でＩＰＳｅｃ提案またはＩＫＥ提案を呼び出し得る。新しいイニシエータＳＰＩは、イニシエータ側でキー変更後の新しいＩＫＥ ＳＡを識別するために使用され得る。

動作１１４、ＩＫＥ ＳＡをキー変更する要求をレスポンダがいったん受信すると、レスポンダは、ＩＫＥ ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答をイニシエータに送信する。

ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＨＤＲおよびペイロードを含み、ペイロードは、ＳＡペイロード、Ｎｒペイロード、およびＫＥｒペイロードを含む。ＳＡペイロードは、ＳＡペイロードのＳＰＩフィールド内に新しいレスポンダＳＰＩを含む。ＳＡペイロードはまた、イニシエータのオファーからレスポンダによって選択された暗号スイートを含む。Ｎｒペイロードはノンスを含み、ＫＥｒペイロードは、選択された暗号スイートがその群を含む場合にＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ値を含む。新しいレスポンダＳＰＩは、レスポンダ側でキー変更後の新しいＩＫＥ ＳＡを識別するために使用され得る。そのようにして、新しいレスポンダＳＰＩと新しいイニシエータＳＰＩとの組み合わせは、新しいＩＫＥ ＳＡを識別するために使用される。加えて、ＳＡペイロード内の新しいレスポンダＳＰＩはイニシエータによって取得され、イニシエータ側で新しい鍵が計算される。

動作１１６、新しいＩＫＥ ＳＡが確立される。新しいＩＫＥ ＳＡは、ＩＫＥ制御パケットを保護するために使用される。

新しいＩＫＥ ＳＡ、すなわちキー変更されたＩＫＥ ＳＡは、ＩＫＥ ＳＡのすべての子ＳＡを継承し、これは、キー変更が成功した後に古いＩＫＥ ＳＡとリンクされた既存の子ＳＡが新しいＩＫＥ ＳＡに移動されることを意味する。

動作中１１２および１１４に示されるＩＫＥ ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ交換の後に、新しい鍵および選択された暗号スイートで新しいＩＫＥ ＳＡが作成され、新しいＩＫＥ ＳＡは、上記のようにＳＡペイロードにおいて交換される新しいイニシエータＳＰＩおよび新しいレスポンダＳＰＩで識別される。

動作１１８、古いＳＡを削除するために、イニシエータが古いＩＫＥ ＳＡの削除要求をレスポンダに送信する。

古いＩＫＥ ＳＡの削除要求は、ＨＤＲおよびＤペイロードを含み得る。Ｄペイロードは、削除すべきＳＡを示すプロトコル識別子（ＩＤ）などの情報を含み得る。ＳＡの削除は、ＲＦＣ７２９６に従って、イニシエータとレスポンダとの間のＩＮＦＯＲＭＡＴＩＯＮＡＬ交換を通じて実装され得る。一例として、図１Ｃは、ＲＦＣ７２９６に従って削除要求の構造の一例を例示する。

動作１２０、古いＩＫＥ ＳＡの削除要求を受信すると、レスポンダは、古いＩＫＥ ＳＡの削除応答をイニシエータに送信する。

古いＩＫＥ ＳＡの削除応答は、ＨＤＲおよびＤペイロードを含み得る。Ｄペイロードは、削除すべきＳＡを示すプロトコルＩＤなどの情報を含み得る。ＳＡの削除は、ＲＦＣ７２９６に従って、イニシエータとレスポンダとの間のＩＮＦＯＲＭＡＴＩＯＮＡＬ交換を通じて実装され得る。

図２を参照すると、図２は、第１のネットワークデバイスが子ＳＡまたはＩＰｓｅｃ ＳＡキー変更を開始する一実施形態を提供する。ＩＫＥ ＳＡキー変更と同じように、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ交換はまた、子ＳＡをキー変更するために使用され得る。

この実施形態によれば、ＩＫＥ ＳＡのキー変更は、少なくとも以下の動作を含み得る。

動作２０２～２１０は、動作１０２～１１０を参照し得る。

動作２１２、イニシエータは、子ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求をレスポンダに送信する。

ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、ＩＫＥヘッダであるＨＤＲ、およびペイロードを含む。ペイロードは、Ｎ（ＲＥＫＥＹ＿ＳＡ）ペイロード、ＳＡペイロード、Ｎｉペイロード、ＴＳｉ、およびＴＳｒペイロード、ならびに任意のＫＥｉペイロードを含む。

ＲＦＣ７２９６で規定されるＲＥＫＥＹ＿ＳＡペイロードは、既存の子ＳＡに対してキー変更が行われていることを他のピアに通知するために使用される。キー変更されている既存の子ＳＡのＳＰＩは、ＲＥＫＥＹ＿ＳＡペイロードのＳＰＩフィールドに追加され、レスポンダは、含まれるＳＰＩを使用してＳＡを識別することができる。さらに、ＲＥＫＥＹ＿ＳＡペイロードのプロトコルＩＤフィールドは、キー変更されるＳＡのプロトコルと一致するように、例えば、ＥＳＰの場合は３、ＡＨの場合には２に設定される。

ＳＡペイロードは、ＳＡオファー、例えば、イニシエータがサポートする１または複数の暗号スイートを含む。ＳＡペイロードはまた、ＳＡペイロードのＳＰＩフィールドにおいて供給される新しいイニシエータＳＰＩを含み得る。

新しいイニシエータＳＰＩは、キー変更後の新しいＩＰＳｅｃ ＳＡのためのイニシエータにおいてインバウンドＳＰＩとして使用され得、キー変更後の新しいＩＰＳｅｃ ＳＡのためのレスポンダにおいてアウトバウンドＳＰＩとして使用され得る。Ｎｉペイロードはノンスを含み、任意のＫＥｉペイロードはＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ値を含む。提案された子ＳＡのための提案されたトラフィックセレクタは、ＴＳｉおよびＴＳｒペイロードに含まれる。トラフィックセレクタは、トラフィック通信のためにイニシエータによって使用される、キー変更されるイニシエータに関連付けられるフロー情報、例えば、アドレス範囲（ＩＰｖ４またはＩＰｖ６）、ポート範囲、およびＩＰプロトコルＩＤを含む。

提案がレスポンダにとって許容可能であると仮定すると、レスポンダは同一のＴＳペイロードを送信し返す。別の場合では、レスポンダは、イニシエータによって提案されたトラフィックのサブセットを選択することができる。これは、例えば、２つのエンドのフロー構成が更新されているが、一方のエンドのみが新しい情報を受信しているときに生じ得る。２つのエンドは、異なるエンドユーザ、例えばネットワーク管理者によって構成され得るため、エラーがない場合であっても不適合性が長期間にわたって存続し得る。レスポンダが、イニシエータによって提案されたトラフィックのサブセットを選択すると、レスポンダは、トラフィックセレクタをイニシエータの提案のいくつかのサブセットに絞り込む（そのセットが空集合とならないことを条件とする）。

動作２１４：子ＳＡをキー変更する要求をレスポンダがいったん受信すると、レスポンダは、子ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答をイニシエータに送信する。

ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＨＤＲおよびペイロードを含み、ペイロードは、ＳＡペイロード、Ｎｒペイロード、ＴＳｉおよびＴＳｒペイロード、ならびに任意のＫＥｒペイロードを含む。

ＳＡペイロードは、ＳＡペイロードのＳＰＩフィールド内に新しいレスポンダＳＰＩを含む。新しいレスポンダＳＰＩは、キー変更後の新しいＩＰＳｅｃ ＳＡのためのレスポンダにおいてインバウンドＳＰＩとして使用され得、キー変更後の新しいＩＰＳｅｃ ＳＡのためのイニシエータにおいてアウトバウンドＳＰＩとして使用され得る。ＳＡペイロードはまた、イニシエータのオファーからレスポンダによって選択された暗号スイートを含む。Ｎｒペイロードはノンスを含み、ＫＥｒペイロードは、選択された暗号スイートがその群を含む場合にＤｉｆｆｉｅ－Ｈｅｌｌｍａｎ値を含む。

上記のように、レスポンダは、同一のＴＳペイロードをイニシエータに送信し返し得るか、または、イニシエータによって提案されたトラフィックのサブセットを選択してイニシエータに送信し返し得る。

一実施形態では、レスポンダは、以下のように絞り込みを実行する。

レスポンダのポリシーが、提案されたトラフィックセレクタのどの部分も承諾することを許容しない場合、レスポンダは、ＴＳ＿ＵＮＡＣＣＥＰＴＡＢＬＥ通知メッセージで応答する。

レスポンダのポリシーが、ＴＳｉおよびＴＳｒによってカバーされるトラフィックのセット全体を許容する場合、絞り込みは必要ではなく、レスポンダは、同じＴＳｉ値およびＴＳｒ値を返すことができる。

レスポンダのポリシーが、ＴＳｉおよびＴＳｒの第１のセレクタを承諾することを許容する場合、レスポンダは、トラフィックセレクタをイニシエータの第１の選択を含むサブセットに絞り込む。

レスポンダのポリシーが、ＴＳｉおよびＴＳｒの第１のセレクタを承諾することを許容しない場合、レスポンダは、ＴＳｉおよびＴＳｒの許容可能なサブセットに絞り込む。

動作２１６、新しいＩＰＳｅｃ ＳＡが作成される。

新しいＩＰＳｅｃ ＳＡが確立された後、キー変更されるＩＰＳｅｃ ＳＡに関連付けられるＩＫＥ ＳＡに新しいＩＰＳｅｃ ＳＡ、すなわち、キー変更されたＩＰＳｅｃ ＳＡが追加され、これは、ＩＫＥ ＳＡからそれに対応する子ＳＡへのリンクが存在することを意味する。つまり、キー変更後に作成された新しい子ＳＡが、ＩＫＥ ＳＡに追加される。

動作中２１２および２１４に示されるＩＫＥ ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ交換の後に、新しい鍵および選択された暗号スイートで新しいＩＰＳｅｃ ＳＡが作成され、新しいＩＰＳｅｃ ＳＡは、上記のようにＳＡペイロードにおいて交換される新しいイニシエータＳＰＩおよび新しいレスポンダＳＰＩで識別される。

動作２１８、古いＳＡを削除するために、イニシエータが古い子ＳＡの削除要求をレスポンダに送信する。

古い子ＳＡの削除要求は、ＨＤＲおよびＤペイロードを含み得る。Ｄペイロードは、削除すべきＳＡを示すプロトコル識別子（ＩＤ）などの情報を含み得る。ＳＡの削除は、ＲＦＣ７２９６に従って、イニシエータとレスポンダとの間のＩＮＦＯＲＭＡＴＩＯＮＡＬ交換を通じて実装され得る。

動作２２０、古い子ＳＡの削除要求を受信すると、レスポンダは、古い子ＳＡの削除応答をイニシエータに送信する。

古い子ＳＡの削除応答は、ＨＤＲおよびＤペイロードを含み得る。Ｄペイロードは、削除すべきＳＡを示すプロトコル識別子（ＩＤ）などの情報を含み得る。ＳＡの削除は、ＲＦＣ７２９６に従って、イニシエータとレスポンダとの間のＩＮＦＯＲＭＡＴＩＯＮＡＬ交換を通じて実装され得る。

図１Ｂおよび図２の上記の従来技術の方法から見ることできるように、ＩＫＥ ＳＡをキー変更の際には、イニシエータとレスポンダとの間の交換は、キー変更するＳＡに関連付けられる暗号ポリシー（例えば、暗号スイート）に変更がないにもかかわらず、単一または複数の暗号スイートを含むＳＡペイロードを含む。言い換えれば、イニシエータおよび／またはレスポンダがそれらと関連付けられる暗号スイートを変更しても、イニシエータとレスポンダとの間のキー変更交換は依然として、単一または複数の暗号スイートを含むＳＡペイロードを含む。ＩＰｓｅｃ ＳＡキー変更の場合、キー変更の際には、イニシエータとレスポンダとの間の交換は、キー変更するＳＡおよびフローポリシーに関連付けられる暗号ポリシーに変更がないにもかかわらず、単一または複数の暗号スイートを含むＳＡペイロードと併せてＴＳｉおよびＴＳｒペイロードを含む。

ＳＡキー変更は周期的にトリガされるため、これらのペイロードを処理するのに帯域幅および電力が消費される。この問題は、複数の暗号スイートの場合に、より深刻になり、これは、ＩＫＥ ＳＡおよびＩＰＳｅｃ ＳＡの両方における複数の暗号スイートについてペイロードサイズが比例関係で大きくなるためである。

例えば、低電力消費技術を利用するモノのインターネット（ＩｏＴ）デバイスの場合には、ＩＫＥｖ２メッセージのサイズを小さくすることが非常に望ましい。そのようなデバイスの一部では、ネットワークを介して余分なビットを伝送するための電力消費は非常に高い。そのようなデバイスの多くは、デバイスのライフサイクル（多くの場合、数年間）にわたって機能する、再充電または交換することができない電池で電力供給されている。この理由から、そのようなデバイスの場合に電力消費を低減するというタスクは非常に重要である。

さらに、大きいＵＤＰメッセージはまた、ＩＰレベルでの断片化を引き起こし得、これは、ネットワークアドレス変換器（ＮＡＴ）との不良な相互作用を起こし得る。特に、一部のＮＡＴは、ＴＣＰ／ＵＤＰポート番号を含まないＩＰ断片（初期のＩＰ断片ではない）をドロップする。ほとんどのＩＯＴデバイスは、単一の組のスイートを有するか、それらはキー変更の際に選択されたスイートを変更することを好まない。

一例では、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ交換でＩＫＥ ＳＡをキー変更する場合、（単一の組の暗号スイート）ＳＡペイロードの最小サイズは５２バイトである一方、本発明の実施形態では、これらのペイロードは、１６バイトのサイズであるＳＰＩを取得するための通知ペイロードＮ（ＮＥＷ＿ＳＰＩ）で置き換えられる。つまり、３６バイトが節約される。

別の例では、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ交換で子ＳＡをキー変更する場合、ＳＡペイロードの最小サイズは４０バイトであり、各ＴＳサイズは２４バイトであり（２×２４＝４８バイト）したがって、合計サイズは８８バイトである。一方で、本発明の実施形態では、これらのペイロードは、１２バイトのサイズである、ＳＰＩを取得するための通知ペイロードＮ（ＮＥＷ＿ＳＰＩ）で置き換えられ、つまり、合計で７６バイトが節約される。

本開示は、上述の問題に対処するために軽量キー変更の解決策を提供する。この解決策では、暗号ポリシーに変更がない場合に、イニシエータとレスポンダとの間の交換は、ＩＫＥキー変更およびＩＰＳｅｃ ＳＡキー変更手順のいずれかにおいてＳＡペイロードを保持しない。代わりに、本明細書で「ＮＥＷ＿ＳＰＩ通知」と呼ばれる新しい通知タイプのペイロード（既存のＳＡペイロードの代わりであり得る）、または本明細書で「軽量ＳＡペイロード」と呼ばれる新しいペイロード、またはＳＰＩを送信するための任意の他のペイロードなどにおいてＳＰＩが伝達される。ＮＥＷ＿ＳＰＩ通知は、既存のＳＡペイロードよりも少ないビットを使用する。伝送されるビットの追加的なさらなる節約において、フロー情報に変更がない場合には、イニシエータとレスポンダとの間の交換はまた、ＩＰｓｅｃ ＳＡキー変更においてＴＳペイロードを保持しない。一例として、「軽量ＳＡペイロード」フォーマットは、ＳＡペイロードヘッダおよび提案ペイロードのみを含み得る。そのため、Ｓａｉ１およびＳＡｒ１において送信されたものなどの従来のペイロードと比較して、ペイロードがトリミングされる。

軽量キー変更アプローチを実装するために、２つのエンドは、それらのそれぞれの軽量キー変更方法を実行する能力を交換し得る。この交換は、キー変更プロセスの前に、例えば、上記のようにＩＫＥまたはＩＰＳｅｃ ＳＡをセットアップするための初期交換中に実行され得る。

本開示の一実施形態によれば、軽量キー変更の能力の交換は、２つのピア間での以下の動作を含み得る。

イニシエータは、イニシエータが軽量キー変更をサポートする、例えば、キー変更任意ペイロードをサポートすることを示すために通知を第２のネットワークデバイスに送信する。

レスポンダは、レスポンダもまた、軽量キー変更をサポートする、例えば、キー変更任意ペイロードをサポートすることを示すために応答を送信する。

この初期のサポートプロセスを通じて、２つのエンドは、相手が軽量キー変更アプローチをサポートするかどうかを互いに知ることができる。

図３Ａ～５は、イニシエータとレスポンダとの間で軽量キー変更のサポートをネゴシエーションするための３つの異なる方法を例示する。３つの方法はすべて、初期交換プロセスを使用して、軽量キー変更ネゴシエーションを実装する。上述のように、本開示は、初期交換プロセスを使用して軽量キー変更ネゴシエーションを実装することのみに限定されず、本開示を読んだ後に当業者により他の方法が想起され得る。

図３Ａに例示される実施形態では、軽量キー変更をサポートする通知は、イニシエータによりレスポンダに送信されるＩＮＩＴ要求、例えばＩＫＥ＿ＳＡ＿ＩＮＩＴ要求メッセージ内の通知ペイロードに保持され、それに応じて、軽量キー変更のサポートの確認は、レスポンダからイニシエータに送信されるＩＮＩＴ応答、例えばＩＫＥ＿ＳＡ＿ＩＮＩＴ応答メッセージ内の通知ペイロードに保持される。一例として、図３Ｂは、通知ペイロードの構造を例示し、ここで、通知メッセージのタイプはＩＫＥＶ２＿ＲＥＫＥＹ＿ＯＰＴＩＯＮＡＬ＿ＰＡＹＬＯＡＤ＿ＳＵＰＰＯＲＴＥＤであり、これは、従来の通知ペイロードと比較して新しい「通知メッセージタイプ」である。新しい通知メッセージタイプ、例えばＩＫＥＶ２＿ＲＥＫＥＹ＿ＯＰＴＩＯＮＡＬ＿ＰＡＹＬＯＡＤ＿ＳＵＰＰＯＲＴＥＤは通知ペイロードに含まれ、イニシエータまたはレスポンダが軽量キー変更をサポートすることを示す。

図４に例示される実施形態では、軽量キー変更をサポートする通知は、イニシエータによりレスポンダに送信されるＡＵＴＨ要求、例えばＩＫＥ＿ＳＡ＿ＡＵＴＨ要求メッセージ内の通知ペイロードに保持され、それに応じて、軽量キー変更をサポートする通知は、レスポンダからイニシエータに送信されるＡＵＴＨ要求、例えばＩＫＥ＿ＳＡ＿ＡＵＴＨ応答メッセージ内の通知ペイロードに保持される。通知ペイロードのタイプは、ＩＫＥＶ２＿ＲＥＫＥＹ＿ＯＰＴＩＯＮＡＬ＿ＰＡＹＬＯＡＤ＿ＳＵＰＰＯＲＴＥＤペイロードであり得る。

図５に例示される実施形態では、軽量キー変更をサポートする通知は、イニシエータによりレスポンダに送信されるＩＮＩＴ要求、例えばＩＫＥ＿ＳＡ＿ＩＮＩＴ要求メッセージ内の通知ペイロードに保持され、それに応じて、軽量キー変更をサポートする通知は、レスポンダからイニシエータに送信されるＡＵＴＨ応答、例えばＩＫＥ＿ＳＡ＿ＡＵＴＨ応答メッセージ内の通知ペイロードに保持される。通知ペイロードのタイプは、ＩＫＥＶ２＿ＲＥＫＥＹ＿ＯＰＴＩＯＮＡＬ＿ＰＡＹＬＯＡＤ＿ＳＵＰＰＯＲＴＥＤペイロードであり得る。

軽量キー変更ネゴシエーションの能力は、キー変更プロセスの前、例えば、ＩＫＥ ＩＮＩＴまたはＡＵＴＨ中に実行されない場合があり、これは、両者がこれに合意しなかったことを意味し、イニシエータまたはレスポンダのいずれかがＮＥＷ＿ＳＰＩまたは軽量ＳＡペイロードを送信することを許容すべきでない場合には、他方がこれをドロップしてエラーとして扱うことができることに留意されたい。

図６を参照すると、図６は、軽量キー変更アプローチを使用したＳＡのキー変更のフローチャートを例示する。

イニシエータとレスポンダとの間でＩＫＥおよびＩＰＳｅｃ ＳＡが確立された後、各エンドのＳＡ有効期間ポリシーによるＩＫＥおよびＩＰＳｅｃ ＳＡのいずれか１つの有効期間の失効が近い場合、イニシエータは、以下の動作を含み得るキー変更プロセスを開始する。

動作６０２、イニシエータは、イニシエータに関連付けられる暗号スイートに変更があるかどうかを決定する。

本開示では、イニシエータに関連付けられる暗号スイートとは、暗号スイートがイニシエータによりサポートされ、イニシエータによって確立された特定のＳＡ、例えば、ＳＡキー変更状況におけるキー変更されたＳＡ（すなわち、新しいＳＡ）に使用されることを意味する。

弱い暗号スイートに関連付けられるＳＡが確立された後、ＳＡのいずれか１つの有効期間の失効が近い場合、イニシエータは、新しいＳＡを作成し、キー変更されたＳＡ（古いＳＡとも呼ばれ得る）を削除することによりＳＡを、古いＳＡに使用される（古いＳＡに関連付けられるものとも呼ばれ得る）暗号スイートの変更を伴ってまたは伴わずに、キー変更することを望む。言い換えれば、イニシエータに関連付けられる暗号スイートが変更されないことは、古いＳＡが使用した暗号スイートが依然として、キー変更されたＳＡ（すなわち、新しいＳＡ）に使用され得ることを意味する。イニシエータに関連付けられる暗号スイートが変更されることは、古いＳＡが関連付けられる暗号スイートが、イニシエータによってサポートされ、新しいＳＡに使用される（すなわち、新しいＳＡに関連付けられる）別の暗号スイートに変更されたことを意味する。以下では、イニシエータに関連付けられる暗号スイートの変更の場合のいくつかの状況を提供する。

１つの状況は、イニシエータによってサポートされる暗号スイートが変更される場合である。例えば、イニシエータは現在、第１の暗号スイート（例えば、弱い暗号スイート）のみをサポートする。古いＳＡが確立された後、イニシエータによる暗号スイートのサポートは、ネットワーク管理者により、ユーザインタフェースを介してイニシエータを構成することによって、何らかの理由で（例えば、イニシエータがより高いセキュリティ要件を有するより重要な役割を担う）第２の暗号スイート（強い暗号スイート）に変更される。暗号スイートが変更された後、イニシエータが古いＳＡをキー変更することを望む場合、イニシエータが現在は強い暗号スイートのみをサポートするため、イニシエータは新しいＳＡのために暗号スイートを変更する必要がある。

別の状況は、イニシエータによりサポートされる暗号スイートが変更されない場合である。例えば、イニシエータは現在、２つ以上の暗号スイートをサポートする。キー変更を行う場合、イニシエータは、何らかの理由で、例えば、ＳＡの要件が改善され、それにより新しいＳＡに使用される暗号スイートをより強くする必要があるなどの理由で、古いＳＡに関連付けられる暗号スイートを使用するよりも、新しいＳＡのための新しい暗号スイートを使用することを望む。この状況では、古いＳＡに関連付けられる第１の暗号スイートはもはや新しいＳＡに関連付けられていないため、イニシエータがレスポンダに送信するキー変更要求は、新しいＳＡのための第２の暗号スイートを保持する必要がある。詳細な実装形態は、図７Ａ～１２の説明において開示される。

さらに、別の状況は、イニシエータが第１の暗号スイート、例えば弱い暗号スイートのみをサポートし、イニシエータが、何らかの理由で、古いＳＡをキー変更するときに第１の暗号スイートを第２の暗号スイートに変更すること（例えば、強い暗号スイートへの変更）を望む場合である。この状況では、イニシエータが現在は第１の暗号スイートのみをサポートするため、イニシエータを再構成する必要がある。ネットワーク管理者は、第２の暗号スイートをサポートする、または第１の暗号スイートおよび第２の暗号スイートの両方をサポートするようにイニシエータを再構成することを選択し得る。構成はイニシエータ内に格納されるか、またはいくつかの他のデータベースもしくはデバイスに格納される。例えば、イニシエータと、イニシエータによりサポートされる暗号スイートとの間には対応関係がイニシエータ内または他の場所に格納され得る。レスポンダ側での構成プロセスは、上記と同様である。再構成の後、イニシエータは、サポートする第２の暗号スイートを選択して、ＳＡキー変更交換のためのキー変更要求内に第２の暗号スイートを置くことができる。

以下では、イニシエータに関連付けられる暗号スイートの変更がない場合のいくつかの状況を提供する。

１つの状況は、イニシエータが第１の暗号スイート、例えば弱い暗号スイートのみをサポートし、イニシエータが、古いＳＡをキー変更するときに第１の暗号スイートを変更しないままにすること（すなわち、第１の暗号スイートが依然としてキー変更されたＳＡに使用される）を望む場合であり、古いＳＡに関連付けられる第１の暗号スイートが依然として新しいＳＡに関連付けられるため、イニシエータがレスポンダに送信するキー変更要求は、新しいＳＡのための暗号スイートを保持しない。

別の状況は、イニシエータが２つ以上の暗号スイート、例えば、第１の暗号スイート（例えば弱い暗号スイート）および第２の暗号スイート（例えば強い暗号スイート）をサポートし、イニシエータが、古いＳＡをキー変更するときに第１の暗号スイートを第２の暗号スイートに変更することを望まない場合である。この状況では、古いＳＡに関連付けられる第１の暗号スイートが依然として新しいＳＡに使用されるため、イニシエータがレスポンダに送信するキー変更要求は、新しいＳＡのための暗号スイートを保持する必要がない。詳細な実装形態については、図７Ａ～１２の説明を参照されたい。

動作６０４、イニシエータに関連付けられる暗号スイートに変更がない場合に、イニシエータはＳＡをキー変更するために第１のキー変更要求をレスポンダに送信する。

上記のように、イニシエータに関連付けられる暗号スイートが変更されないことは、古いＳＡが使用した暗号スイートが依然として、キー変更されたＳＡ（すなわち、新しいＳＡ）に使用され得ることを意味する。イニシエータは新しいＳＡのための暗号スイートを保持する必要がない。

ＳＡが確立された後にイニシエータが暗号スイートを変更しないため、またはイニシエータがこれまでに暗号スイートを変更し、変更された暗号スイートが再び元のものに変更されて、現在の暗号スイートは、ＳＡが確立されたときに使用された暗号スイートと同じであるため、第１のキー変更要求は、第１のＳＰＩを保持し、イニシエータに関連付けられる暗号スイートを保持しない。

ＩＫＥキー変更シナリオでは、第１のＳＰＩは新しいイニシエータＳＰＩである。ＩＫＥ ＳＡは、両方のエンドでＳＰＩ対により識別され得る。一方のエンドがキー変更プロセスを開始すると、それはキー変更要求内の新しいＳＰＩを含み、キー変更後の新しいＩＫＥ ＳＡのためのイニシエータＳＰＩとして新しいＳＰＩが使用される。レスポンダが、応答においてＩＫＥキー変更に応答するとき、レスポンダは、キー変更後の新しいＩＫＥ ＳＡのためのレスポンダＳＰＩとして使用されるべきその新しいＳＰＩをキー変更応答に追加する。

ＩＰｓｅｃ ＳＡキー変更シナリオでは、第１のＳＰＩは、キー変更後の新しいＩＰＳｅｃ ＳＡのためのイニシエータにおいてインバウンドＳＰＩとして使用され、キー変更後の新しいＩＰＳｅｃ ＳＡのためのレスポンダにおいてアウトバウンドＳＰＩとして使用される。さらに、第１のキー変更要求はまた、上記のように、キー変更されるＳＡを識別するためにＮ［ＲＥＫＥＹ＿ＳＡ］ペイロード内のＳＰＩを保持する。

この動作の詳細な実装形態は、図７Ａ～９に例示される以下のＩＫＥキー変更プロセスを参照し得る。

動作６０６、レスポンダは、第１のキー変更応答をイニシエータに送信する。レスポンダに関連付けられる暗号スイートに変更がない場合、第１のキー変更応答は、第２のＳＰＩを保持し、第２のネットワークデバイスに関連付けられる暗号スイートを保持しない。

上記のように、ＩＫＥキー変更シナリオでは、第２のＳＰＩは新しいレスポンダＳＰＩである。レスポンダが、応答においてＩＫＥキー変更に応答するとき、レスポンダは、キー変更後の新しいＩＫＥ ＳＡのためのレスポンダＳＰＩとして使用されるべき新しいレスポンダＳＰＩをキー変更応答に追加する。

ＩＰｓｅｃ ＳＡキー変更シナリオでは、第２のＳＰＩは、キー変更後の新しいＩＰＳｅｃ ＳＡのためのレスポンダにおいてインバウンドＳＰＩとして使用され、キー変更後の新しいＩＰＳｅｃ ＳＡのためのイニシエータにおいてアウトバウンドＳＰＩとして使用される。

この動作の詳細な実装形態は、図８～１０Ｄに例示される以下のＩＫＥキー変更プロセスを参照し得る。

動作６０８、第１のネットワークデバイスに関連付けられる暗号スイートおよび第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合に、イニシエータが第１のＳＰＩおよび第２のＳＰＩに応じてＳＡをキー変更する。

キー変更は、新しいＳＡを作成すること、およびキー変更される古いＳＡを削除することを含む。具体的には、イニシエータは、イニシエータＳＰＩ、レスポンダＳＰＩ、および古いＳＡに使用される変更のない暗号スイートを使用することによってＳＡをキー変更して、新しいＳＡのための新しい鍵を取得する。詳細な実装形態は、図７Ａ～９に例示される以下のＩＫＥキー変更プロセスを参照し得る。

図７Ａは、本開示の一実施形態によるＩＫＥ ＳＡのキー変更のフローチャートである。この実施形態では、イニシエータは、キー変更されるＳＡが確立されたときに使用される暗号スイート、例えば、より高い暗号アルゴリズムセットを有する強い暗号スイートを変更しない。

この実施形態では、２つのシナリオがあり、第１のシナリオは、レスポンダもまた暗号スイートを変更しない場合である。第２のシナリオは、レスポンダが暗号スイートを変更することを望む場合である。

この実施形態の第１のシナリオによれば、ＩＫＥキー変更プロセスは、以下の動作を含む。

動作７０２、イニシエータがＩＮＩＴ要求をレスポンダに送信する。ＩＮＩＴ要求は、正常なＨＤＲヘッドおよび上述のようなペイロードを除く、通知ペイロードを保持する。この実施形態では、通知ペイロードはＩＫＥＶ２＿ＲＥＫＥＹ＿ＯＰＴＩＯＮＡＬ＿ＰＡＹＬＯＡＤ＿ＳＵＰＰＯＲＴＥＤペイロードであり、これは、イニシエータが軽量キー変更をサポートすることを示す。

動作７０４、レスポンダは、ＩＮＩＴ応答をイニシエータに送信する。ＩＮＩＴ応答は、正常なＨＤＲヘッドおよび上述のようなペイロードを除く、通知ペイロードを保持する。この実施形態では、通知ペイロードはＩＫＥＶ２＿ＲＥＫＥＹ＿ＯＰＴＩＯＮＡＬ＿ＰＡＹＬＯＡＤ＿ＳＵＰＰＯＲＴＥＤペイロードであり、これは、レスポンダが軽量キー変更アプローチをサポートすることを示す。

上記の初期交換に従って、動作７０６および７０８が実行された後、イニシエータとレスポンダとの間にＩＫＥ ＳＡおよびＩＰＳｅｃ ＳＡが確立される。

図３Ａ～５に説明されるように、軽量キー変更の能力をネゴシエーションするための他の方法はまた、この実施形態にも適用され得ることが理解されるべきである。

動作７１０、ＩＫＥ ＳＡおよびＩＰＳｅｃ ＳＡが確立され、イニシエータがＩＫＥキー変更を周期的にトリガする。

イニシエータは、ＩＫＥ ＳＡの有効期間が失効しそうであるかどうかを周期的に検出し得る。上記のように、イニシエータは、自身の側の有効期間ポリシーを維持し得る。有効期間ポリシーは、異なるＳＡに対して異なる有効期間を設定し得る。ＩＫＥ ＳＡの有効期間が失効しそうであることをイニシエータが検出すると、動作７１２が実行される。

動作７１２、イニシエータが、ＩＫＥ ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求をレスポンダに送信する。ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、ＨＤＲヘッド、Ｎｉペイロード、およびＫＥｉペイロードを含む。１または複数の暗号スイートを保持するＳＡペイロードを保持する代わりに、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、通知ペイロード、例えばＮＥＷ＿ＳＰＩ通知を保持する。ＮＥＷ＿ＳＰＩペイロードは、新しいイニシエータＳＰＩを保持し、暗号スイートを保持しない、ＳＰＩフィールドを有し得る。図７Ｂは、キー変更パケットフォーマットの一例を示す。

代替的には、新しいイニシエータＳＰＩを保持するために軽量ＳＡペイロードまたは他のペイロードが使用され得る。

ＮＥＷ＿ＳＰＩは、キー変更後の新しいＩＫＥ ＳＡを識別するイニシエータＳＰＩを保持する新たに規定された通知ペイロードである。

一例として、図７Ｃは、ＩＫＥのためのＮＥＷ＿ＳＰＩを例示する。

一例として、図７Ｄは、ＩＫＥのための軽量ＳＡペイロードを例示する。この例では、軽量ＳＡペイロードは、単一の提案ペイロードを含み、トランスフォームおよび属性を含まない。この構造によれば、ＩＫＥキー変更の場合に「ＳＰＩ」で言及される値は、ＩＫＥ ＳＡのためのイニシエータ／レスポンダＳＰＩとして使用される。

動作７１４、レスポンダが、ＩＫＥ ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答をイニシエータに送信する。

ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＨＤＲヘッド、Ｎｒペイロード、およびＫＥｒペイロードを含む。１または複数の暗号スイートを保持するＳＡペイロードを保持する代わりに、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、通知ペイロード、例えばＮＥＷ＿ＳＰＩ通知を保持する。ＮＥＷ＿ＳＰＩペイロードは、新しいレスポンダＳＰＩを保持し、暗号スイートを保持しないＳＰＩフィールドを有し得る。

動作７１６、新しいＩＫＥ ＳＡが作成される。

具体的には、上記のように、このシナリオでは、イニシエータおよびレスポンダはいずれもそれらの暗号スイートを変更しない。新しいＩＫＥ ＳＡはイニシエータＳＰＩおよびレスポンダＳＰＩに応じ、古いＳＡに使用された元の暗号スイートがキー変更されて作成される。新しいＩＫＥ ＳＡは、ＩＫＥ制御パケットを保護するために使用される。
新しいＩＫＥ ＳＡ、すなわちキー変更されたＩＫＥ ＳＡは、ＩＫＥ ＳＡのすべての子ＳＡを継承し、これは、キー変更が成功した後に古いＩＫＥ ＳＡとリンクされた既存の子ＳＡが新しいＩＫＥ ＳＡに移動されることを意味する。

動作７１８、古いＩＫＥ ＳＡを削除するために、イニシエータが古いＩＫＥ ＳＡの削除要求をレスポンダに送信する。

古いＩＫＥ ＳＡの削除要求は、ＨＤＲおよびＤペイロードを含み得る。Ｄペイロードは、削除すべき古いＳＡを示すプロトコル識別子（ＩＤ）などの情報を含み得る。詳細な実装形態は、動作２１６を参照し得る。

動作７２０、古いＩＫＥ ＳＡの削除要求を受信すると、レスポンダは、古いＩＫＥ ＳＡの削除応答をイニシエータに送信する。

古いＩＫＥ ＳＡの削除応答は、ＨＤＲおよびＤペイロードを含み得る。Ｄペイロードは、削除すべきＳＡを示すプロトコル識別子（ＩＤ）などの情報を含み得る。詳細な実装形態は、動作２１８を参照し得る。

この実施形態で説明される軽量キー変更アプローチを使用することにより、このＮＥＷ＿ＳＰＩ通知ペイロードは、例えば、最小で３６バイトを節約し得、節約されるバイト数は複数の暗号スイートにおいて比例関係で増加し、これにより、複雑な検証の処理、およびしたがって、ＩＫＥキー変更交換におけるＳＡペイロードの処理が低減される。例えば、ＮＥＷ＿ＳＰＩ通知ペイロードのサイズは、１２～１６バイトの範囲であり得る。

図８を参照すると、図８は、レスポンダが現在使用中の暗号スイート（例えば、キー変更されるＳＡが確立されたときに使用した暗号スイート）をレスポンダが変更する第２のシナリオを例示する。この状況では、レスポンダは、動作８１４において、ＮＥＷ＿ＳＰＩ通知または変更された暗号スイートを保持するＳＡペイロードの代わりに、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答において提案未選択通知ペイロードをイニシエータに送信し得る。提案未選択通知ペイロードは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持される暗号スイート内に一致する暗号スイートが存在しないことを示すＮＯ＿ＰＲＯＰＯＳＡＬ＿ＣＨＯＳＥＮペイロードであり得る。次に、イニシエータが指示を受信した後、イニシエータはＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を再送信するが、今度は、このＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、イニシエータおよびレスポンダが暗号スイートについて合意を達成するまでレスポンダと暗号スイートを再ネゴシエーションするために、更新された暗号スイートを保持するＳＡペイロードを保持する。暗号スイートの再ネゴシエーションのプロセスは、本開示に記載のシナリオのいずれか１つを参照し得る。再ネゴシエーションの一例は以下に説明する。

この例では、動作８０２～８１２は、上記の動作７０２～７１２と同じである。しかし動作８１４では、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＨＤＲヘッド、通知ペイロードを保持する。通知ペイロードは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持される暗号スイート内に一致する暗号スイートが存在しないことを示す、ＮＯ＿ＰＲＯＰＯＳＡＬ＿ＣＨＯＳＥＮタイプのペイロードであり得る。一例として、図７Ｅは、通知メッセージタイプがＮＯ＿ＰＲＯＰＯＳＡＬ＿ＣＨＯＳＥＮである、通知ペイロードの構造を例示する。したがって、本明細書に開示される他の新しい通知の場合と同様に、従来の通知構造が使用されるが、この従来の通知構造は新しい通知タイプのものである。次に、イニシエータが指示を受信した後、イニシエータは、イニシエータおよびレスポンダが暗号スイートについて合意を達成するまでレスポンダと暗号スイートを再ネゴシエーションするために、更新された暗号スイートを保持するＳＡペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を再送信する。暗号スイートの再ネゴシエーションのプロセスは、本開示に記載のシナリオのいずれか１つを参照し得る。再ネゴシエーションの一例は以下に説明する。

次に、動作８１６において、イニシエータは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求をレスポンダに再送信する。第２のＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、ＨＤＲヘッド、Ｎ（ＲＥＫＥＹ＿ＳＡ）ペイロード、ＳＡペイロード、Ｎｉペイロード、任意のＫＥｉペイロードを含む。ＮｉペイロードおよびＫＥｉペイロードの内容については、動作２１２および動作７１２を参照し得る。ＳＡペイロードは、新しいイニシエータＳＰＩ、およびイニシエータが提案した１または複数の暗号スイートを保持するＳＰＩフィールドを保持する。

動作８１８において、レスポンダは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答をイニシエータに送信する。ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＨＤＲヘッド、ＳＡペイロード、Ｎｒペイロード、ＫＥｒペイロードを保持する。

動作８２０、新しいＩＫＥ ＳＡが作成される。この動作の実装形態については、上記の動作７１６を参照し得る。

動作８２０、古いＩＫＥ ＳＡを削除するために、イニシエータが古いＩＫＥ ＳＡの削除要求をレスポンダに送信する。

古いＩＫＥ ＳＡの削除要求は、ＨＤＲおよびＤペイロードを含み得る。Ｄペイロードは、削除すべきＳＡを示すプロトコル識別子（ＩＤ）などの情報を含み得る。詳細な実装形態については、上記の動作２１６および７１８を参照し得る。

動作８２２、古いＩＫＥ ＳＡの削除要求を受信すると、レスポンダは、古いＩＫＥ ＳＡの削除応答をイニシエータに送信する。

古い子ＳＡの削除応答は、ＨＤＲおよびＤペイロードを含み得る。Ｄペイロードは、削除すべきＳＡを示すプロトコル識別子（ＩＤ）などの情報を含み得る。詳細な実装形態については、上記の動作２１８および７２０を参照し得る。

図９は、本開示の一実施形態によるＩＫＥ ＳＡのキー変更のフローチャートである。この実施形態では、イニシエータが暗号スイートを変更する。

この実施形態では３つのシナリオが存在する。第１のシナリオは、レスポンダが暗号スイートを変更しない場合である。このシナリオでは、例えば、イニシエータは、弱い暗号スイートから強い暗号スイートに変更するための２つのサポートするスイート（例えば、弱い暗号スイートおよび強い暗号スイート）などを有し得るが、レスポンダは弱い暗号スイートのみをサポートし、暗号スイートを変更することを望まない。この場合、レスポンダは、イニシエータと暗号スイートをネゴシエーションしない場合があり、軽量キー変更アプローチを使用する。例えば、レスポンダは、レスポンダＳＰＩを含むために、ＮＥＷ＿ＳＰＩ通知もしくは軽量ＳＡペイロード、または任意の他のペイロードを使用し得る。

第２のシナリオは、レスポンダが暗号スイートを変更する場合である。このシナリオでは、例えば、イニシエータは、弱い暗号スイートから強い暗号スイートに変更するための２つのサポートするスイート（例えば、弱い暗号スイートおよび強い暗号スイート）などを有し、レスポンダもまた、弱い暗号スイート（キー変更されるＳＡが最初に確立されるときに使用される）から強い暗号スイートに変更することを望む。この場合、レスポンダは、キー変更応答において強い暗号スイートを保持するＳＡペイロードを保持し得る。

第３のシナリオは、レスポンダが暗号スイートを変更する場合である。このシナリオでは、例えば、イニシエータは１つのみのサポートするスイート（例えば、強い暗号スイート）を有し、弱い暗号スイートを強い暗号スイートに変更することを望み、レスポンダは、弱い暗号スイートのみをサポートする。この場合、レスポンダは、イニシエータにより送信されたキー変更要求に保持される暗号スイート内に一致する暗号スイートが存在しないことを示す通知ペイロードを送信する。次に、イニシエータが指示を受信した後、イニシエータはキー変更要求を再送信するが、今度は、更新された暗号スイートを保持するＳＡペイロードを保持するものを再送信して、イニシエータおよびレスポンダが暗号スイートについて合意を達成するまでレスポンダと暗号スイートを再ネゴシエーションする。暗号スイートの再ネゴシエーションのプロセスについては、本開示に記載されるシナリオのいずれか１つを参照し得る。

この実施形態によれば、ＩＫＥキー変更プロセスは、以下の動作を含む。

動作９０２～９１０の詳細な実装形態については、図７Ａで説明した動作７０２～７１０を参照し得る。

動作９１２、イニシエータは、ＩＫＥ ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求をレスポンダに送信する。ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、ＨＤＲヘッド、ＳＡペイロード、Ｎｉペイロード、およびＫＥｉペイロードを含む。各ペイロードに保持される情報については、動作１１２を参照し得る。この場合、例えば、ＳＡペイロードは、２つの暗号スイート、例えば、弱い暗号スイートおよび強い暗号スイートを保持する。

動作９１４、レスポンダは、ＩＫＥ ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答をイニシエータに送信する。ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＨＤＲヘッド、Ｎｒペイロード、およびＫＥｒペイロードを含む。暗号スイートを保持するＳＡペイロードを保持する代わりに、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、通知ペイロード、例えばＮＥＷ＿ＳＰＩ通知を保持する。ＮＥＷ＿ＳＰＩペイロードは、新しいレスポンダＳＰＩを保持するＳＰＩフィールドを有し、暗号スイートを保持しない。

動作９１４において、任意の方法として、レスポンダはそれが現在使用中の暗号スイートを変更することを望まないにもかかわらず、レスポンダは、それが現在使用中の暗号スイート（すなわち、ＳＡが確立されたときにそれが使用していたもの）を保持するＳＡペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答を新しいレスポンダＳＰＩに送信してもよいことが理解されるべきである。

この実施形態の第２のシナリオによれば、レスポンダは、それが現在使用中の暗号スイートを変更すること、例えば、弱い暗号スイートから強い暗号スイートに変更することを望む。ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、イニシエータによってサポートされる、変更された暗号スイート、すなわち強い暗号スイートを保持するＳＡペイロードを保持する。

動作９１６～９１８の詳細な実装形態については、図８で説明した動作８１６～８１８および図２で説明した動作２１６～２１８を参照し得る。

この実施形態の第３のシナリオによれば、例えば、イニシエータは、１つの暗号スイート（例えば、強い暗号スイート）のみをサポートし、暗号スイートを、例えば弱い暗号スイートから強いスイートに変更する。そして、レスポンダは弱い暗号スイートのみをサポートする。このシナリオでは、レスポンダにおける暗号スイートは、イニシエータにより提案された暗号スイートと一致しない。レスポンダとイニシエータとの間で暗号スイートの一致がないことが決定された後、レスポンダは、動作９１４において、ＳＡペイロードの代わりに、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答内の提案未選択通知ペイロードをイニシエータに送信し得る。提案未選択通知ペイロードは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持される暗号スイート内に一致する暗号スイートが存在しないことを示すＮＯ＿ＰＲＯＰＯＳＡＬ＿ＣＨＯＳＥＮペイロードであり得る。次に、イニシエータが指示を受信した後、イニシエータは、イニシエータおよびレスポンダが暗号スイートについて合意を達成するまでレスポンダと暗号スイートを再ネゴシエーションするために、更新された暗号スイートを保持するＳＡペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を再送信する。暗号スイートの再ネゴシエーションのプロセスは、本開示に記載のシナリオのいずれか１つを参照し得る。

ＩＫＥキー変更にＮＥＷ＿ＳＰＩ通知ペイロードを導入することにより、例えば、各ＩＫＥキー変更ごとに最小で３６バイトが節約され、したがって、複雑な検証の処理、およびＳＡペイロードの処理も低減され得る。

図１０Ａは、本開示の一実施形態によるＩＰＳｅｃ ＳＡのキー変更のフローチャートである。この実施形態では、イニシエータは、キー変更されるＳＡが確立されたときに使用される暗号スイート、例えば、より高い暗号アルゴリズムセットを有する強い暗号スイートを変更しない。フロー情報に関して、イニシエータは、フロー情報を変更してもよく、フロー情報を変更しなくてもよい。イニシエータがフロー情報を変更しない場合、キー変更要求は、ＴＳペイロードを保持する必要がなく、対照的に、イニシエータがフロー情報を変更する場合、キー変更要求は、変更されたフロー情報、例えばアドレス範囲、ポート範囲、およびＩＰプロトコルＩＤ等を反映するためにフロー情報を保持する。

この実施形態では、２つのシナリオがあり、第１のシナリオは、レスポンダもまた暗号スイートを変更しない場合である。第２のシナリオは、レスポンダが暗号スイートを変更する場合である。

ＩＫＥ ＳＡおよびＩＰＳｅｃ ＳＡを同時にキー変更する場合には、動作（すなわち、ＩＫＥ＿ＳＡ＿ＩＮＩＴまたはＡＵＴＨ要求メッセージ内のＩＫＥＶ２＿ＲＥＫＥＹ＿ＯＰＴＩＯＮＡＬ＿ＰＡＹＬＯＡＤ＿ＳＵＰＰＯＲＴＥＤ、および／または「ＮＥＷ＿ＳＰＩ通知」、または軽量ＳＡペイロードもしくはＳＡをキー変更するためのＳＰＩを含む任意の他のペイロードのネゴシエーション）は、本開示に記載される実施形態と同様のままであることが理解されるべきである。同時にキー変更する場合、好ましくは、キー変更プロセスは、メッセージを組み合わせることなく独立して実施される。

この実施形態の第１のシナリオによれば、ＩＰＳｅｃキー変更プロセスは、以下の動作を含む。

動作１００２～１０１０、動作１００２～１０１０の詳細な実装形態は、図８で説明した動作８０２～８１０を参照し得る。

動作１０１２、イニシエータは、子ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求をレスポンダに送信する。

ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、イニシエータがフロー情報を変更しない場合には、ＨＤＲヘッド、Ｎ（ＲＥＫＥＹ＿ＳＡ）ペイロード、ＮＥＷ＿ＳＰＩペイロード、Ｎｉペイロード、および任意のＫＥｉペイロードを含み、ＴＳペイロードを含まない。Ｎ（ＲＥＫＥＹ＿ＳＡ）ペイロードは、どの子ＳＡをキー変更すべきかを示すＳＰＩを保持する。ＮｉペイロードおよびＫＥｉペイロードの内容については、動作２１２を参照し得る。１または複数の暗号スイートを保持するＳＡペイロードを保持する代わりに、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、通知ペイロード、例えばＮＥＷ＿ＳＰＩ通知ペイロードを保持する。ＮＥＷ＿ＳＰＩペイロードは、新しいイニシエータＳＰＩを保持し、暗号スイートを保持しない、ＳＰＩフィールドを有する。代替的には、軽量ＳＡペイロードまたは他のペイロードは、新しいイニシエータＳＰＩを保持するために使用され得る。

ＮＥＷ＿ＳＰＩは、キー変更後の新しいＩＰＳｅｃ ＳＡを識別するイニシエータＳＰＩを保持する新たに規定されたＮＯＴＩＦＹペイロードである。図１０Ｂは、新しいフィールド、例えば、ＩＰＳｅｃキー変更要求内のＮＥＷ＿ＳＰＩ通知ペイロードを示すキー変更パケットフォーマットの一例を示す。

一例として、図１０Ｃは、ＡＨのためのＮＥＷ＿ＳＰＩを例示する。

一例として、図１０Ｄは、ＩＰＳｅｃ ＳＡのための新たに規定されたペイロードである２種類の軽量ＳＡを例示する。最上部の軽量ＳＡペイロードは、単一の提案ペイロードを含み、トランスフォームおよび属性を含まず、下部の軽量ＳＡペイロードは、図１０Ｄに示されるＳＡバンドルを含む。ＩＰｓｅｃトンネルを作成するとき、２つの方法が存在する。一方は、ＡＨまたはＥＳＰのいずれかを使用することであり、他方は、ＳＡバンドルとも呼ばれるＡＨおよびＥＳＰの両方を使用することである。ＳＡバンドルは、ユーザがＡＨおよびＥＳＰの両方を一度に使用することを望む場合に使用される。

ＩＰＳＥＣキー変更の場合、「ＳＰＩ」フィールド内で言及される値は、ＡＨ／ＥＳＰ ＳＡのためのインバウンド／アウトバウンドＳＰＩとして使用される。

代替的には、イニシエータがフロー構成を変更する場合、例えば、キー変更後の新しいＳＡのためのＩＰアドレス範囲などのフロー情報を変更する場合、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求はさらに、上述のペイロードを除くＴＳペイロードを保持し得る。ＴＳペイロードの内容については、動作２１２を参照し得る。

動作１０１４、レスポンダは、子ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答をイニシエータに送信する。

ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＨＤＲヘッド、Ｎｒペイロード、および、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求がＫＥｉペイロードを保持するかどうかに左右される任意のＫＥｒペイロードを含む。１または複数の暗号スイートを保持するＳＡペイロードを保持する代わりに、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、通知ペイロード、例えばＮＥＷ＿ＳＰＩ通知を保持する。ＮＥＷ＿ＳＰＩペイロードは、新しいレスポンダＳＰＩを保持し、暗号スイートを保持しないＳＰＩフィールドを有し得る。

ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、イニシエータに関連付けられるフロー情報を保持するＴＳペイロードを保持しないため、レスポンダは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答内のＴＳペイロードを保持するかどうかに関して以下の２つの選択を有し得る。

第１の選択は、レスポンダに関連付けられるフロー情報に変更がなく、現在使用中のフロー情報がキー変更後の新しいＩＰＳｅｃ ＳＡに依然として使用される場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、レスポンダに関連付けられるＴＳペイロードを保持しない。

第２の選択は、レスポンダに関連付けられるフロー情報に変更がある場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＴＳ許容不可能通知を保持する。ＴＳ許容不可能通知は、イニシエータとレスポンダとの間の情報に一致がないことを示すために使用されるＴＳ＿ＵＮＡＣＣＥＰＴＡＢＬＥ通知ペイロードであり得る。次に、イニシエータがＴＳ許容不可能通知を受信した後、イニシエータは、今度は更新されたフロー情報を保持するＴＳペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を再送信して、イニシエータおよびレスポンダがフロー情報について合意を達成するまでレスポンダとフロー情報を再ネゴシエーションする。フロー情報の再ネゴシエーションのプロセスについては、本開示に記載される暗号スイートまたはフロー情報のネゴシエーションのシナリオのいずれか１つを参照し得る。

暗号スイートまたはフロー情報のネゴシエーションのいずれか１つが第１のネゴシエーションターンにおいて失敗した場合、２つのエンドは、第２のネゴシエーションターンで暗号スイートおよびフロー情報のネゴシエーションの両方を再ネゴシエーションし得ることに留意されたい。その場合、再送信されるＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、フロー情報と共に暗号スイートのネゴシエーションをレスポンダと再ネゴシエーションするためのＳＡペイロードを有しても有さなくてもよい。暗号スイートの詳細については、本開示に記載されるＩＰｓｅｃ ＳＡ暗号スイートのシナリオのいずれか１つを参照し得る。

暗号スイートおよびフロー情報のネゴシエーションは独立して実行され得ることが理解されるべきである。その場合、２つのエンドは、第１のネゴシエーションターンにおいて暗号スイートの既に達成された合意を記録し得る。第２のネゴシエーションターンにおいて再送信されたＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、ＳＡペイロードを保持する、または保持しないことを通じて暗号スイートを再ネゴシエーションしなくてもよい。

イニシエータがフロー情報、およびしたがって、イニシエータに関連付けられる変更されたフロー情報を保持するＴＳペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を変更する場合、レスポンダは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答内にＴＳペイロードを保持するかどうかに関して以下の３つの選択を有し得る。

第１の選択は、レスポンダに関連付けられるフロー情報に変更がなく、レスポンダに関連付けられる現在使用中のフロー情報がＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持されるイニシエータに関連付けられるフロー情報内に存在する場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答はＴＳペイロードを保持しない。

第２の選択は、レスポンダに関連付けられるフロー情報に変更があり、レスポンダが、レスポンダに関連付けられるフロー情報として、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持されるイニシエータに関連付けられるフロー情報内のフロー情報を選択する場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＴＳペイロードを保持する。動作２１２において議論したように、レスポンダは、イニシエータにより提案されたトラフィックのサブセットを選択し得る、すなわち、トラフィックセレクタを、イニシエータの提案のいくつかのサブセットに絞り込み得る。レスポンダはまた、同一のＴＳペイロードをイニシエータに送信し得る。

第３の選択は、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持されるイニシエータが提案したフロー情報とフロー情報サポートとの間に一致するフロー情報がない場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、一致するフロー情報がないことを示すＴＳ許容不可能通知を保持する。次に、イニシエータが通知を受信した後、イニシエータは、更新されたフロー情報を保持するＴＳペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を再送信して、イニシエータおよびレスポンダがフロー情報について合意を達成するまでレスポンダとフロー情報を再ネゴシエーションする。フロー情報の再ネゴシエーションのプロセスについては、必要に応じて、本開示に記載される暗号スイートまたはフロー情報のネゴシエーションのシナリオのいずれか１つを参照し得る。上記のように、再ネゴシエーションプロセスは、暗号スイートおよびフロー情報のネゴシエーションを共に行ってもよく、または暗号スイートの既に達成された合意を再ネゴシエーションすることなく、第１のネゴシエーションターンで失敗したフロー情報のネゴシエーションのみを実行してもよい。

動作１０１６～１０２０の詳細な実装形態については、図８で説明した動作７１６～７２０および図２で説明した動作２１６～２２０を参照し得る。

ＩＰＳＥＣキー変更において、このＮＥＷ＿ＳＰＩ通知ペイロードは、例えば最小で７６バイトが節約され得、節約されるバイト数は、複数の暗号スイートおよび／またはＴＳペイロードにおいて比例関係で増加する。これにより、複雑な検証の処理、およびしたがって、ＳＡ、ＴＳｉ、およびＴＳｒペイロードの処理が低減される。

図１１を参照すると、図１１は、この実施形態の第２のシナリオを例示し、ここで、レスポンダが暗号スイートを変更し、例えば、レスポンダが、キー変更されるＳＡが確立されたときにレスポンダが現在使用中の暗号スイートを変更する。

このシナリオでは、動作１１０２～１１１２は上記と同じである。しかし動作１１１４において、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＨＤＲヘッド、提案未選択通知ペイロード、またはＴＳ許容不可能通知ペイロードを保持する。提案未選択通知ペイロードは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持される暗号スイート内に一致する暗号スイートが存在しないことを示すＮＯ＿ＰＲＯＰＯＳＡＬ＿ＣＨＯＳＥＮペイロードであり得る。ＴＳ許容不可能通知ペイロードは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持されるフロー情報内に一致するフロー情報が存在しないことを示すＴＳ＿ＵＮＡＣＣＥＰＴＡＢＬＥ通知であり得る。次に、イニシエータが指示を受信した後、イニシエータは、イニシエータおよびレスポンダが暗号スイートについて合意を達成するまでレスポンダと暗号スイートを再ネゴシエーションするために、更新された暗号スイートを保持するＳＡペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を再送信する。暗号スイートの再ネゴシエーションのプロセスは、本開示に記載のシナリオのいずれか１つを参照し得る。再ネゴシエーションの一例を以下に説明する。

次に、動作１１１６において、イニシエータは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求（第２のＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求とも呼ばれ得る）をレスポンダに再送信する。

第２のＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、ＨＤＲヘッド、Ｎ（ＲＥＫＥＹ＿ＳＡ）ペイロード、ＳＡペイロード、Ｎｉペイロード、任意のＫＥｉペイロード、イニシエータがフロー情報を変更するかどうかに依拠する任意のＴＳペイロードを含む。Ｎ（ＲＥＫＥＹ＿ＳＡ）ペイロードは、どの子ＳＡをキー変更すべきかを示すＳＰＩを保持する。ＮｉペイロードおよびＫＥｉペイロードの内容については、動作２１２および動作１０１２を参照し得る。ＳＡペイロードは、新しいイニシエータＳＰＩ、およびイニシエータが提案した１または複数の暗号スイートを保持するＳＰＩフィールドを保持する。

動作１１１８において、レスポンダは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答をイニシエータに送信する。ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＨＤＲヘッド、Ｎ（ＲＥＫＥＹ＿ＳＡ）ペイロード、ＮＥＷ＿ＳＰＩ通知ペイロードまたはＳＡペイロード、Ｎｒペイロード、任意のＫＥｒ応答（ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求がＫＥｉペイロードを保持するかどうかに依拠する）、およびレスポンダに関連付けられるフロー情報を保持する任意のＴＳペイロード（レスポンダが、レスポンダに関連付けられるフロー情報を変更するかどうかに依拠する）を保持する。再ネゴシエーションプロセスにおいて、暗号スイートおよびフロー情報のネゴシエーションは、本開示に記載されるように、暗号スイートおよびフロー情報のネゴシエーションアプローチのいずれか１つに応じて実行され得ることが理解されるべきである。

動作１１２０、この動作の実装形態については、上記の動作２１６を参照し得る。

動作１１２２、イニシエータは、古いＩＰｓｅｃ ＳＡを削除するために、古いＩＰｓｅｃ ＳＡの削除要求をレスポンダに送信する。

古い子ＳＡの削除要求は、ＨＤＲおよびＤペイロードを含み得る。Ｄペイロードは、削除すべきＳＡを識別するＳＰＩを含み得る。詳細な実装形態については、動作２１６を参照し得る。

動作１１２４、古いＰＳｅｃ ＳＡの削除要求を受信すると、レスポンダは、古いＩＰｓｅｃ ＳＡの削除応答をイニシエータに送信する。

古い子ＳＡの削除応答は、ＨＤＲおよびＤペイロードを含み得る。Ｄペイロードは、削除すべきＳＡを識別するＳＰＩを含み得る。詳細な実装形態については、動作２１８を参照し得る。

上記の再ネゴシエーションプロセスは、暗号スイートおよびフロー情報のネゴシエーションを共に行い、暗号スイートおよびフロー情報のネゴシエーションのいずれか１つが失敗した場合、再ネゴシエーションプロセスがトリガされ、再ネゴシエーションプロセスは、暗号スイートおよびフロー情報の両方を再ネゴシエーションする。上記のように、暗号スイートのネゴシエーションおよびフロー情報のネゴシエーションは、別々に実行されてもよい。

以下では、第２のシナリオにおけるフロー情報のネゴシエーションを説明する。

動作１１１２においてＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求がイニシエータに関連付けられるフロー情報を保持するＴＳペイロードを保持しない場合、レスポンダは、動作１１１４においてＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答内のＴＳペイロードを保持するかどうかに関して以下の２つの選択を有し得る。

第１の選択は、レスポンダに関連付けられるフロー情報に変更がなく、現在使用中のフロー情報がキー変更後の新しいＩＰＳｅｃ ＳＡに依然として使用される場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、レスポンダに関連付けられるＴＳペイロードを保持しない。

第２の選択は、レスポンダに関連付けられるフロー情報に変更がある場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＴＳ許容不可能通知を保持する。ＴＳ許容不可能通知は、イニシエータとレスポンダとの間の情報に一致がないことを示すために使用されるＴＳ＿ＵＮＡＣＣＥＰＴＡＢＬＥ通知ペイロードであり得る。次に、イニシエータがＴＳ許容不可能通知を受信した後、イニシエータは、更新されたフロー情報を保持するＴＳペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を再送信して、イニシエータおよびレスポンダがフロー情報について合意を達成するまでレスポンダとフロー情報を再ネゴシエーションする。フロー情報の再ネゴシエーションのプロセスについては、必要に応じて、本開示に記載される暗号スイートまたはフロー情報のネゴシエーションのシナリオのいずれか１つを参照し得る。

暗号スイートまたはフロー情報のネゴシエーションのいずれか１つが第１のネゴシエーションターンにおいて失敗した場合、２つのエンドは、第２のネゴシエーションターンで暗号スイートおよびフロー情報のネゴシエーションの両方を再ネゴシエーションし得ることに留意されたい。その場合、再送信されるＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、フロー情報と共に暗号スイートのネゴシエーションをレスポンダと再ネゴシエーションするためのＳＡペイロードを有しても有さなくてもよい。暗号スイートの詳細については、必要に応じて、本開示に記載されるＩＰｓｅｃ ＳＡ暗号スイートのシナリオのいずれか１つを参照し得る。

暗号スイートおよびフロー情報のネゴシエーションは独立して実行され得ることが理解されるべきである。その場合、２つのエンドは、第１のネゴシエーションターンにおいて暗号スイートの既に達成された合意を記録し得る。第２のネゴシエーションターンにおいて再送信されたＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、ＳＡペイロードを保持する、または保持しないことを通じて暗号スイートを再ネゴシエーションしなくてもよい。

更新された暗号スイートまたはＴＳでの第２のキー変更要求中、デバイスは、ＮＥＷ＿ＳＰＩ通知もしくは軽量ＳＡペイロード内のＳＰＩを再利用すること、または新しい暗号スイートでの第２のキー変更要求中に新しいＳＰＩを完全に生成することのいずれかができることが理解されるべきである。このアプローチは、本開示で議論される再ネゴシエーションプロセスに適用され得る。

イニシエータがフロー情報、およびしたがって、イニシエータに関連付けられる変更されたフロー情報を保持するＴＳペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を変更する場合、レスポンダは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答内にＴＳペイロードを保持するかどうかに関して以下の３つの選択を有し得る。

第１の選択は、レスポンダに関連付けられるフロー情報に変更がなく、レスポンダに関連付けられる現在使用中のフロー情報がＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持されるイニシエータに関連付けられるフロー情報内に存在する場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答はＴＳペイロードを保持しない。

第２の選択は、レスポンダに関連付けられるフロー情報に変更があり、レスポンダが、レスポンダに関連付けられるフロー情報として、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持されるイニシエータに関連付けられるフロー情報内のフロー情報を選択する場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＴＳペイロードを保持する。動作２１２において議論したように、レスポンダは、イニシエータにより提案されたトラフィックのサブセットを選択し得る、すなわち、トラフィックセレクタを、イニシエータの提案のいくつかのサブセットに絞り込み得る。レスポンダはまた、同一のＴＳペイロードをイニシエータに送信し得る。

第３の選択は、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持されるイニシエータが提案したフロー情報とフロー情報サポートとの間に一致するフロー情報がない場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、一致するフロー情報がないことを示すＴＳ許容不可能通知を保持する。次に、イニシエータが通知を受信した後、イニシエータは、更新されたフロー情報を保持するＴＳペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を再送信して、イニシエータおよびレスポンダがフロー情報について合意を達成するまでレスポンダとフロー情報を再ネゴシエーションする。フロー情報の再ネゴシエーションのプロセスについては、必要に応じて、本開示に記載される暗号スイートまたはフロー情報のネゴシエーションのシナリオのいずれか１つを参照し得る。

上記のように、再ネゴシエーションプロセスは、暗号スイートおよびフロー情報のネゴシエーションを共に行ってもよく、または第１のネゴシエーションターンで失敗したネゴシエーションのみを実行してもよい。

図１２は、本開示の一実施形態によるＩＰＳｅｃ ＳＡのキー変更のフローチャートである。この実施形態では、イニシエータは、キー変更されるＳＡが確立されたときに使用される暗号スイートを変更し、例えば、弱い暗号スイートから、より強い、例えばより高い暗号アルゴリズムセットを有するより高い暗号スイートに変更する。フロー情報に関して、イニシエータは、フロー情報を変更してもよく、フロー情報を変更しなくてもよい。イニシエータがフロー情報を変更しない場合、キー変更要求は、ＴＳペイロードを保持する必要がない。対照的に、イニシエータがフロー情報を変更する場合、キー変更要求は、変更されたフロー情報、例えばアドレス範囲、ポート範囲、およびＩＰプロトコルＩＤ等のいずれかを反映するためにフロー情報を保持する。

この実施形態では３つのシナリオが存在する。第１のシナリオは、レスポンダが暗号スイート、例えば暗号スイートを変更しない場合である。このシナリオでは、レスポンダは、イニシエータと暗号スイートをネゴシエーションしない場合があり、軽量キー変更アプローチを使用する。例えば、レスポンダは、レスポンダＳＰＩを含むために、ＮＥＷ＿ＳＰＩ通知もしく軽量ＳＡペイロード、または任意の他のペイロードを使用し得る。
第２のシナリオは、レスポンダが暗号スイートを変更する場合である。この場合、レスポンダは、キー変更応答において変更された暗号スイートを保持するＳＡペイロードを保持し得る。第３のシナリオは、キー変更要求に保持される暗号スイートが、レスポンダによってサポートされる暗号スイートと一致しない場合である。この場合、レスポンダは、イニシエータにより送信されたキー変更要求に保持される暗号スイート内に一致する暗号スイートが存在しないことを示す通知ペイロードを保持する。その後、２つのエンドは、暗号スイートについての合意が達成されるまで、暗号スイートを再ネゴシエーションする。暗号スイートの詳細なネゴシエーションについては、図９に対応する詳細な説明を参照し得る。

再び図１２を参照すると、図１２は、以下の動作を含むこの実施形態によるフローチャートを例示する。

動作１２０２～１２１０の詳細な実装形態については、図８で説明した動作８０２～８１０を参照し得る。

動作１２１２、イニシエータは、ＩＰＳｅｃ ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求をレスポンダに送信する。ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、ＨＤＲヘッド、キー変更すべき子ＳＡを示すＳＰＩを保持するＮ（ＲＥＫＥＹ＿ＳＡ）ペイロード、１または複数の暗号スイートおよび新しいイニシエータＳＰＩを保持するＳＡペイロード、Ｎｉペイロード、任意のＫＥｉペイロード、ならびに任意のＴＳペイロード（イニシエータが、イニシエータに関連付けられるフロー情報を変更するかどうかに依拠する）を含む。各ペイロードに保持される詳細な情報については、動作１１２を参照し得る。

動作９１４、レスポンダは、ＩＰＳｅｃ ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答をイニシエータに送信する。ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＨＤＲヘッド、ＮＥＷ＿ＳＰＩ通知ペイロードまたはＳＡペイロード（レスポンダが、レスポンダに関連付けられる暗号スイートを変更するかどうかに依拠する）、Ｎｒペイロード、任意のＫＥｒペイロード（ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求がＫＥｉペイロードを保持するかどうかに依拠する）、および任意のＴＳペイロード（レスポンダが、レスポンダに関連付けられるフロー情報を変更するかどうかに依拠する）を含む。ＮＥＷ＿ＳＰＩペイロードは、新しいレスポンダＳＰＩを保持し、暗号スイートを保持しないＳＰＩフィールドを有し得る。

動作１２１４において、任意の方法として、レスポンダはそれが現在使用中の暗号スイートを変更しないにもかかわらず、レスポンダは、それが現在使用中の暗号スイート（すなわち、ＳＡが確立されたときにそれが使用していたもの）を保持するＳＡペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答を新しいレスポンダＳＰＩに送信してもよいことが理解されるべきである。

この実施形態の第２のシナリオによれば、レスポンダは、現在使用中の暗号スイートを変更する。ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、イニシエータによってまたサポートされる、変更された暗号スイートを保持するＳＡペイロードを保持する。

動作１２１６～１２１８の詳細な実装形態については、図８で説明した動作８１６～８１８および図２で説明した動作２１６～２１８を参照し得る。

この実施形態の第３のシナリオによれば、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求内の暗号スイートは、レスポンダが変更することを望む暗号スイートと一致しない。このシナリオでは、レスポンダは、動作１２１４において、ＳＡペイロードの代わりに、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答内の提案未選択通知ペイロードをイニシエータに送信し得る。提案未選択通知ペイロードは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持される暗号スイート内に一致する暗号スイートが存在しないことを示すＮＯ＿ＰＲＯＰＯＳＡＬ＿ＣＨＯＳＥＮペイロードであり得る。次に、イニシエータが指示を受信した後、イニシエータは、イニシエータおよびレスポンダが暗号スイートについて合意を達成するまでレスポンダと暗号スイートを再ネゴシエーションするために、更新された暗号スイートを保持するＳＡペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を再送信する。暗号スイートの再ネゴシエーションのプロセスは、必要に応じて、本開示に記載のシナリオのいずれか１つを参照し得る。

以下では、この実施形態におけるフロー情報のネゴシエーションを説明する。

動作１２１２においてＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求がイニシエータに関連付けられるフロー情報を保持するＴＳペイロードを保持しない場合、レスポンダは、動作１２１４においてＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答内のＴＳペイロードを保持するかどうかに関して以下の２つの選択を有し得る。

第１の選択は、レスポンダに関連付けられるフロー情報に変更がなく、現在使用中のフロー情報がキー変更後の新しいＩＰＳｅｃ ＳＡに依然として使用される場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、レスポンダに関連付けられるＴＳペイロードを保持しない。

第２の選択は、レスポンダに関連付けられるフロー情報に変更がある場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＴＳ許容不可能通知を保持する。ＴＳ許容不可能通知は、イニシエータとレスポンダとの間の情報に一致がないことを示すために使用されるＴＳ＿ＵＮＡＣＣＥＰＴＡＢＬＥ通知ペイロードであり得る。次に、イニシエータがＴＳ許容不可能通知を受信した後、イニシエータは、更新されたフロー情報を保持するＴＳペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を再送信して、イニシエータおよびレスポンダがフロー情報について合意を達成するまでレスポンダとフロー情報を再ネゴシエーションする。フロー情報の再ネゴシエーションのプロセスについては、必要に応じて、本開示に記載される暗号スイートまたはフロー情報のネゴシエーションアプローチのいずれか１つを参照し得る。

暗号スイートまたはフロー情報のネゴシエーションのいずれか１つが第１のネゴシエーションターンにおいて失敗した場合、２つのエンドは、第２のネゴシエーションターンで暗号スイートおよびフロー情報のネゴシエーションの両方を再ネゴシエーションし得ることに留意されたい。その場合、再送信されるＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、フロー情報と共に暗号スイートのネゴシエーションをレスポンダと再ネゴシエーションするためのＳＡペイロードを有しても有さなくてもよい。

暗号スイートおよびフロー情報のネゴシエーションは独立して実行され得ることが理解されるべきである。その場合、２つのエンドは、第１のネゴシエーションターンにおいて暗号スイートの既に達成された合意を記録し得る。第２のネゴシエーションターンにおいて再送信されたＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、ＳＡペイロードを保持する、または保持しないことを通じて暗号スイートを再ネゴシエーションしなくてもよい。

イニシエータがフロー情報、およびしたがって、イニシエータに関連付けられる変更されたフロー情報を保持するＴＳペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を変更する場合、レスポンダは、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答内にＴＳペイロードを保持するかどうかに関して以下の３つの選択を有し得る。

第１の選択は、レスポンダに関連付けられるフロー情報に変更がなく、レスポンダに関連付けられる現在使用中のフロー情報がＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持されるイニシエータに関連付けられるフロー情報内に存在する場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答はＴＳペイロードを保持しない。

第２の選択は、レスポンダに関連付けられるフロー情報に変更があり、レスポンダが、レスポンダに関連付けられるフロー情報として、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持されるイニシエータに関連付けられるフロー情報内のフロー情報を選択する場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、ＴＳペイロードを保持する。動作２１２において議論したように、レスポンダは、イニシエータにより提案されたトラフィックのサブセットを選択し得る、すなわち、トラフィックセレクタを、イニシエータの提案のいくつかのサブセットに絞り込み得る。レスポンダはまた、同一のＴＳペイロードをイニシエータに送信し得る。

第３の選択は、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求に保持されるイニシエータが提案したフロー情報とフロー情報サポートとの間に一致するフロー情報がない場合であり、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、一致するフロー情報がないことを示すＴＳ許容不可能通知を保持する。次に、イニシエータが通知を受信した後、イニシエータは、更新されたフロー情報を保持するＴＳペイロードを保持するＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求を再送信して、イニシエータおよびレスポンダがフロー情報について合意を達成するまでレスポンダとフロー情報を再ネゴシエーションする。フロー情報の再ネゴシエーションのプロセスについては、必要に応じて、本開示に記載される暗号スイートまたはフロー情報のネゴシエーションのシナリオのいずれか１つを参照し得る。

上記のように、再ネゴシエーションプロセスは、暗号スイートまたはフロー情報のネゴシエーションを共に行ってもよく、または第１のネゴシエーションターンで失敗したネゴシエーションのみを実行してもよい。

ＮＥＷ＿ＳＰＩ通知ペイロードをＩＰＳＥＣキー変更に導入することにより、またはＴＳペイロードを保持しないことにより、例えば、各ＩＰＳＥＣキー変更ごとに最小で７６バイトが節約され、したがって、複雑な検証の処理、およびＳＡ、ＴＳｉ、およびＴＳｒペイロードの処理も低減され得る。

図１３を参照すると、図１３は、本開示の一実施形態によるネットワークデバイス１３００の概略図を例示する。ネットワークデバイスは、第１のネットワークデバイス（例えば、上述した実施形態で説明されるイニシエータ）および第２のネットワークデバイス（例えば、上述した実施形態で説明されるレスポンダ）を含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更するように構成され、第１のネットワークデバイスと第２のネットワークデバイスとの間にＩＫＥトンネルおよびＩＰｓｅｃトンネルが確立される。この実施形態では、ネットワークデバイスは第１のネットワークデバイスとして動作し、ネットワークデバイスは、決定モジュール１３０２、送信モジュール１３０４、受信モジュール１３０６、およびキー変更モジュール１３０８を含む。

決定モジュール１３０２は、第１のネットワークデバイスに関連付けられる暗号スイートに変更があるかどうかを決定するように構成される。送信モジュール１３０４は、第１のネットワークデバイスに関連付けられる暗号スイートに変更がない場合に、ＳＡをキー変更するために第１のキー変更要求を第２のネットワークデバイスに送信するように構成され、第１のキー変更要求は第１のＳＰＩを保持し、第１のネットワークデバイスに関連付けられる暗号スイートを保持しない。受信モジュール１３０６は、第２のネットワークデバイスから第１のキー変更応答を受信するように構成され、第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更応答は、第２のＳＰＩを保持し、第２のネットワークデバイスに関連付けられる暗号スイートを保持しない。キー変更モジュール１３０８は、第１のネットワークデバイスに関連付けられる暗号スイートおよび第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合に、第１のＳＰＩおよび第２のＳＰＩに応じてＳＡをキー変更するように構成される。この実施形態のネットワークデバイス内の各モジュールの実装形態の詳細については、図７Ａ～７Ｅおよび図１０Ａ～１０Ｄの実施形態におけるイニシエータの実装形態を参照し得る。

別の実施形態では、ネットワークデバイスは、再ネゴシエーションモジュール１３１０をさらに含む。第２のネットワークデバイスに関連付けられる暗号スイートに変更がある場合、第１のキー変更応答は、第２のネットワークデバイスからの提案未選択通知を保持する。再ネゴシエーションモジュール１３１０は、ネゴシエーションされた暗号スイートを取得するまで第２のネットワークデバイスと再ネゴシエーションするように構成され、キー変更モジュール１３０８は、再ネゴシエーションされた暗号スイートにさらに応じてＳＡをキー変更するように構成される。再ネゴシエーションモジュール１３１０は、ＩＰｓｅｃ ＳＡキー変更の場合に暗号スイートを再ネゴシエーションするかフロー情報を再ネゴシエーションするかを決定するように構成されることが理解されるべきであり、再ネゴシエーションプロセスは、送信モジュール１３０４および受信モジュール１３０６を通じて実行される。いくつかの実施形態では、再ネゴシエーションモジュール１３１０は、決定モジュール１３０２に組み込まれてもよい。提案未選択通知の一例は、ＮＯ＿ＰＲＯＰＯＳＡＬ＿ＣＨＯＳＥＮ通知ペイロードであり得る。この実施形態のネットワークデバイスの再ネゴシエーション実装形態の詳細については、図８および１１の実施形態におけるイニシエータの実装形態を参照し得る。

ネットワークデバイス１３００は、図１Ａ～１２の上述した実施形態においてイニシエータにより実行された動作を実装し得ることが理解されるであろう。詳細な実装形態については、上記の実施形態を参照し得る。ここで、１つずつ説明する必要はない。

図１４を参照すると、図１４は、本開示の一実施形態による別のネットワークデバイス１４００の概略図を例示する。ネットワークデバイス１４００は、第１のネットワークデバイス（例えば、上述した実施形態で説明されるイニシエータ）および第２のネットワークデバイス（例えば、上述した実施形態で説明されるレスポンダ）を含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更するように構成され、第１のネットワークデバイスと第２のネットワークデバイスとの間にＩＫＥトンネルおよびＩＰｓｅｃトンネルが確立される。この実施形態では、ネットワークデバイスは、第２のネットワークデバイスとして構成され、ネットワークデバイスは、受信モジュール１４０２、決定モジュール１４０４、送信モジュール１４０６、およびキー変更モジュール１４０８を含む。

受信モジュール１４０２は、ＳＡをキー変更するために第１のネットワークデバイスから第１のキー変更要求を受信するように構成され、第１のキー変更要求は、第１のＳＰＩを保持し、第１のネットワークデバイスに関連付けられる暗号スイートを保持しない。決定モジュール１４０４は、第２のネットワークデバイスに関連付けられる暗号スイートに変更があるかどうかを決定するように構成される。送信モジュール１４０６は、第１のキー変更応答を第１のネットワークデバイスに送信するように構成され、第２のネットワークデバイスに関連付けられる暗号構成に変更がない場合、第１のキー変更応答は、第２のＳＰＩを保持し、第２のネットワークデバイスに関連付けられる暗号スイートを保持しない。したがって、キー変更モジュール１４０８は、第１のＳＰＩおよび第２のＳＰＩに応じてＳＡをキー変更するように構成される。この実施形態のネットワークデバイス内の各モジュールの実装形態の詳細については、図７Ａ～７Ｅおよび図１０Ａ～１０Ｄの説明を参照し得る。

ネットワークデバイス１４００の別の実施形態では、第１のキー変更応答は、第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合に提案未選択通知を保持する。そのようにして、受信モジュール１４０２はさらに、第１のＳＰＩおよび第１のネットワークデバイスに関連付けられる暗号スイートを保持するＳＡをキー変更するために、第１のネットワークデバイスから第２のキー変更要求を受信するように構成される。そして、送信モジュール１４０６はさらに、第２のキー変更要求に保持される第１のネットワークデバイス関連付けられる暗号スイート内に一致する暗号スイートが存在しないことを示す別の提案未選択通知を保持する第２のキー変更応答を送信するように構成される。ネットワークデバイスはさらに、ネゴシエーションされた暗号スイートが取得されるまで第１のネットワークデバイスと再ネゴシエーションするように構成される再ネゴシエーションモジュール１４１０を含む。したがって、ＳＡは、再ネゴシエーションされた暗号スイートにさらに応じてキー変更される。再ネゴシエーションモジュール１４１０は、ＩＰｓｅｃ ＳＡキー変更の場合に暗号スイートを再ネゴシエーションするかフロー情報を再ネゴシエーションするかを決定するように構成されることが理解されるべきであり、再ネゴシエーションプロセスは、送信モジュール１４０６および受信モジュール１４０２を通じて実行される。いくつかの実施形態では、再ネゴシエーションモジュール１４１０は、決定モジュール１４０４に組み込まれてもよい。この実施形態のネットワークデバイスの再ネゴシエーション実装形態の詳細については、図８および１１の実施形態におけるイニシエータの実装形態を参照し得る。

ネットワークデバイス１４００は、図１Ａ～１２の上述した実施形態においてレスポンダにより実行された動作を実装し得ることが理解されるであろう。詳細な実装形態については、上記の実施形態を参照し得る。ここで、１つずつ説明する必要はない。

図１５を参照すると、図１５は、本開示の一実施形態による別のネットワークデバイス１５００の概略図を例示する。ネットワークデバイス１５００は、第１のネットワークデバイス（例えば、上述した実施形態で説明されるイニシエータ）および第２のネットワークデバイス（例えば、上述した実施形態で説明されるレスポンダ）を含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更するように構成され、第１のネットワークデバイスと第２のネットワークデバイスとの間にＩＫＥトンネルおよびＩＰｓｅｃトンネルが確立される。この実施形態では、ネットワークデバイスは、第２のネットワークデバイスとして構成され、ネットワークデバイスは、受信モジュール１５０２、決定モジュール１５０４、送信モジュール１５０６、およびキー変更モジュール１５０８を含む。

受信モジュール１５０２は、ＳＡをキー変更するために第１のネットワークデバイスから第１のキー変更要求を受信するように構成され、第１のキー変更要求は、第１のＳＰＩ、および第１のネットワークデバイスに関連付けられる暗号スイートを保持する。決定モジュール１５０４は、第２のネットワークデバイスに関連付けられる暗号スイートに変更があるかどうかを決定するように構成される。送信モジュール１５０６は、第１のキー変更応答を第１のネットワークデバイスに送信するように構成され、第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、第１のキー変更応答は、第２のＳＰＩを保持し、第２のネットワークデバイスに関連付けられる暗号スイートを保持しない。キー変更モジュールは、第１のＳＰＩおよび第２のＳＰＩに応じてＳＡをキー変更するように構成される。キー変更の実装については、例えば図６～１２の上記の詳細な説明を参照し得る。

ネットワークデバイス１５００の別の実施形態では、第１のキー変更応答は、第１のキー変更要求に保持される第１のネットワークデバイスに関連付けられる暗号スイート内に一致する暗号スイートが存在しないことを示す提案未選択通知を保持する。この場合、ネットワークデバイス１５００はさらに、ネゴシエーションされた暗号スイートが取得されるまで第１のネットワークデバイスと再ネゴシエーションするように構成される再ネゴシエーションモジュール１５１０を含む。したがって、ＳＡは、ネゴシエーションされた暗号スイートにさらに応じてキー変更される。当業者であれば、再ネゴシエーションモジュール１５１０は、ＩＰｓｅｃ ＳＡキー変更の場合に暗号スイートを再ネゴシエーションするかフロー情報を再ネゴシエーションするかを決定するように構成されることが理解され、再ネゴシエーションプロセスは、送信モジュール１５０６および受信モジュール１５０２を通じて実行される。いくつかの実施形態では、再ネゴシエーションモジュール１５１０は、決定モジュール１５０４に組み込まれてもよい。上述した実施形態のネットワークデバイス１５００における再ネゴシエーション実装形態の詳細については、図９および１２の実施形態におけるレスポンダの実装形態を参照し得る。

当業者であれば、ネットワークデバイス１５００は、図１Ａ～１２の上述した実施形態においてレスポンダにより実行された動作を実装し得ることが理解されるであろう。詳細な実装形態については、上記の実施形態を参照し得る。ここで、１つずつ説明する必要はない。

図１６を参照すると、図１６は、本開示の一実施形態による別のネットワークデバイス１６００の概略図を例示する。ネットワークデバイス１６００は、第１のネットワークデバイス（例えば、上述した実施形態で説明されるイニシエータ）および第２のネットワークデバイス（例えば、上述した実施形態で説明されるレスポンダ）を含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更するように構成され、第１のネットワークデバイスと第２のネットワークデバイスとの間にＩＫＥトンネルおよびＩＰｓｅｃトンネルが確立される。いくつかの実施形態では、ネットワークデバイス１６００は、図１Ａ～１２の実施形態で説明されたイニシエータとして動作し、図１Ａ～１２の実施形態で説明されたイニシエータの動作を実行し得る。他の実施形態では、ネットワークデバイス１６００は、図１Ａ～１２の実施形態で説明されたレスポンダとして動作し、図１Ａ～１２の実施形態で説明されたレスポンダの動作を実行し得る。

ネットワークデバイスは、プロセッサ１６０２、プロセッサ１６０２に結合したメモリ１６０４、送受信機（Ｔｘ／Ｒｘ）１６０６、およびＴｘ／Ｒｘ１６０６に結合したポート１６０８を含む。プロセッサ１６０２は、汎用プロセッサとして実装されてもよく、あるいは、１または複数の特定用途向け集積回路（ＡＳＩＣ）および／またはデジタル信号プロセッサ（ＤＳＰ）の一部であってもよい。プロセッサ１６０２は、単一のプロセッサまたは複数のプロセッサを指し得る。メモリ１６０４は、コンテンツを一時的に格納するためのキャッシュ、例えば、ランダムアクセスメモリ（ＲＡＭ）を含み得る。さらに、メモリ１６０４は、ロングタームストレージ、例えば、リードオンリメモリ（ＲＯＭ）を含み得る。イニシエータとして動作する場合、プロセッサ１６０２は、図１Ａ～１２の実施形態で説明したイニシエータの動作を実行するように構成される。レスポンダとして動作する場合、プロセッサ１６０２は、図１Ａ～１２の実施形態で説明したレスポンダの動作を実行するように構成される。

さらに、一実施形態では、メモリ１６０４は、複数のソフトウェアモジュール、例えば、図１３の実施形態で説明したモジュールを含み得る。別の実施形態では、メモリ１６０４は、複数のソフトウェアモジュール、例えば、図１４の実施形態で説明したモジュールを含み得る。さらなる実施形態では、メモリ１６０４は、複数のソフトウェアモジュール、例えば、図１５の実施形態で説明したモジュールを含み得る。

ソフトウェアモジュールの命令を実行することにより、プロセッサ１６０２は、複数の動作を実行し得る。いくつかの実施形態では、モジュールが動作を実行するように構成されている場合、それは実際には、プロセッサ１６０２が、モジュール内の命令を実行して動作を実行するように構成されていることを意味し得る。メモリ１６０４内の命令を実行することにより、プロセッサ１６０２は、図１Ａ～１２で説明した、イニシエータまたはレスポンダにより実行されるすべての動作を完全にまたは部分的に実行し得る。

図１７を参照すると、図１７は、ネットワークシステム１７００の概略図を例示する。ネットワークシステム１７００は、少なくとも、第１のネットワークデバイス１７０２（すなわち、イニシエータ）および第２のネットワークデバイス１７０４（すなわち、レスポンダ）を含み得る。第１のネットワークデバイス１７０２は、図１３の実施形態で説明したネットワークデバイス１３００であり得る。第２のネットワークデバイス１７０４は、図１４および１５の実施形態で説明したネットワークデバイス１４００またはネットワークデバイス１５００であり得る。別の実施形態では、第１のネットワークデバイスは、図１Ａ～１２の実施形態で説明したイニシエータとして動作し、図１Ａ～１２の実施形態で説明したイニシエータの動作を実行するネットワークデバイス１６００であり得る。そして、第２のネットワークデバイスは、図１Ａ～１２の実施形態で説明したレスポンダとして動作し、図１Ａ～１２の実施形態で説明したレスポンダの動作を実行するネットワークデバイス１６００であり得る。

当業者であれば、本開示を読んだ後に、本開示の実装のために任意の既知のまたは新しいアルゴリズムが使用され得ることを理解し得る。しかしながら、本開示は、任意の既知のまたは新しいアルゴリズムの使用にかかわらず、上述の利点および技術的進歩を達成する方法を提供することに留意されたい。

当業者であれば、本開示を読んだ後に、本明細書に開示される実施形態で説明した実施例と組み合わせて、ユニットおよびアルゴリズムの段階は、電子ハードウェア、またはコンピュータソフトウェアおよび電子ハードウェアの組み合わせにより実装され得ることを認識し得る。機能がハードウェアにより実行されるかソフトウェアにより実行されるかは、特定の発明、および技術的解決手段の設計上の制約条件に依拠する。本開示を読んだ後に、当業者は、異なる方法を使用して、各特定の発明について記載される機能を実装し得るが、その実装形態が本開示の範囲を出るものと見なすべきではない。

本開示に提供されるいくつかの実施形態では、開示されるシステムおよび方法は他の方法で実装され得ることが理解されるべきである。例えば、記載されるネットワークデバイスの実施形態は例示的であるに過ぎない。例えば、ユニットの分割は論理的機能分割に過ぎず、実際の実装形態においては他の分割であり得る。例えば、複数のユニットまたはモジュールは、別のシステムに組み合わされるまたは組み込まれてもよく、あるいはいくつかの特徴は無視されるまたは実行されなくてもよい。加えて、表示または議論される相互結合または直接結合または通信接続は、いくつかのインタフェースを通じて実装され得る。装置またはユニット間の間接的な結合または通信接続は、電子的、機械的、または他の形態で実装され得る。

これらの機能がソフトウェア機能ユニットの形態で実装され、独立した製品として販売または使用される場合、これらの機能は、コンピュータ可読記憶媒体に格納され得る。これらの機能は、機能を実行するように好適なハードウェアに命令し得るコンピュータプログラム製品を形成するコンピュータコードで表現され得る。そのような理解に基づいて、本開示の技術的解決手段は本質的に、または従来技術に寄与する部分、または技術的解決手段に寄与する部分は、ソフトウェア製品の形態で実装され得る。コンピュータソフトウェア製品は、記憶媒体内に格納され、本開示の実施形態で説明した方法の段階のすべてまたはその一部を実行するようにコンピュータノード（パーソナルコンピュータ、サーバ、またはネットワークノード、すなわちプロセッサであり得る）に命令するためのいくつかの命令を含む。前述した記憶媒体は、プログラムコードを格納できる任意の媒体、例えば、ＵＳＢフラッシュドライブ、リムーバブルハードディスク、リードオンリメモリ（Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ、ＲＯＭ）、ランダムアクセスメモリ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ、ＲＡＭ）、磁気ディスク又は光ディスクを含む。

そうでないことが明示的に特定されていない限り、互いに通信している複数のデバイスが、互いに継続して通信している必要はない。加えて、互いに通信しているデバイスは、１または複数の中間物を通じて直接または間接的に通信し得る。

単一のデバイスまたは物品が本明細書において説明されている場合、単一のデバイス／物品の代わりに、１つよりも多くのデバイス／物品が（それらが協働していようがいまいが）使用されてよいことは、容易に明らかであろう。同様に、１つよりも多くのデバイスまたは物品が（それらが協働していようがいまいが）本明細書において説明されている場合、１つよりも多くのデバイスまたは物品の代わりに、単一のデバイス／物品が使用されてよいこと、もしくは、示されている数のデバイスまたはプログラムの代わりに、異なる数のデバイス／物品が使用されてよいことは、容易に明らかであろう。あるデバイスの機能および／または複数の特徴は、そのような機能／複数の特徴を有するように明示的には説明されていない１または複数の他のデバイスによって、代替的に具現化されてよい。したがって、本発明の他の実施形態は、デバイス自体を含む必要がない。

Claims (37)

1. 第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムに適用される、セキュリティアソシエーション（ＳＡ）をキー変更するための方法であって、前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）トンネルおよびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立され、前記方法は、
   前記第１のネットワークデバイスが、ＳＡをキー変更するために前記第２のネットワークデバイスに第１のキー変更要求を送信する段階であって、前記第１のキー変更要求が、第１のセキュリティパラメータインデックス（ＳＰＩ）、および前記第１のネットワークデバイスに関連付けられる暗号スイートを保持する、送信する段階と、
   を備え、前記方法は更に、
   前記第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、
   前記第１のネットワークデバイスが前記第２のネットワークデバイスから第１のキー変更応答を受信する段階であって、前記第１のキー変更応答は、第２のＳＰＩを保持し、前記第２のネットワークデバイスに関連付けられる暗号スイートを保持しない、受信する段階と、
   前記第１のネットワークデバイスが前記第１のＳＰＩおよび前記第２のＳＰＩに応じて前記ＳＡをキー変更する段階と、を備え、
   前記第２のネットワークデバイスに関連付けられる暗号スイートに変更がある場合、
   前記第１のネットワークデバイスが前記第２のネットワークデバイスから第１のキー変更応答を受信する段階であって、前記第１のキー変更応答が、変更された暗号スイートを保持する、受信する段階、を備える、
   方法。
2. 前記第１のキー変更要求に保持される前記第１のネットワークデバイスに関連付けられる前記暗号スイート内に一致する暗号スイートが存在しない場合に、前記第１のキー変更応答が、前記第２のネットワークデバイスからの提案未選択通知を保持するとき、前記方法が、
   ネゴシエーションされた暗号スイートが取得されるまで前記第１のネットワークデバイスが前記第２のネットワークデバイスと再ネゴシエーションする段階をさらに含み、
   前記第１のネットワークデバイスが前記ＳＡをキー変更する前記段階は、前記ネゴシエーションされた暗号スイートにさらに応じたものである、
   請求項１に記載の方法。
3. ネゴシエーションされた暗号スイートが取得されるまで前記第２のネットワークデバイスと再ネゴシエーションする前記段階は、
   前記第１のネットワークデバイスが、前記第１のネットワークデバイスに関連付けられる更新された暗号スイートを前記第２のネットワークデバイスに送信して、前記ネゴシエーションされた暗号スイートが取得されるまで前記第２のネットワークデバイスとネゴシエーションすることを含む、
   請求項１に記載の方法。
4. 前記提案未選択通知が、ＮＯ＿ＰＲＯＰＯＳＡＬ＿ＣＨＯＳＥＮ通知ペイロードである、
   請求項２に記載の方法。
5. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がある場合に前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードをさらに保持し、前記第１のキー変更応答は、前記第２のネットワークデバイスに関連付けられるフロー情報に変更がない場合には前記第２のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持せず、前記第２のネットワークデバイスに関連付けられる現在使用中のフロー情報は、前記第１のキー変更要求に保持される前記第１のネットワークデバイスに関連付けられる前記フロー情報内に存在し、
   前記第１のネットワークデバイスが前記ＳＡをキー変更する前記段階は、前記第２のネットワークデバイスに関連付けられる前記現在使用中のフロー情報にさらに応じたものである、
   請求項２または３に記載の方法。
6. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がある場合に前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードをさらに保持し、前記第１のキー変更応答は、前記第２のネットワークデバイスに関連付けられる前記フロー情報に変更がある場合に前記第２のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持し、前記第２のネットワークデバイスは、前記第２のネットワークデバイスに関連付けられる前記フロー情報として前記第１のキー変更要求に保持される前記第１のネットワークデバイスに関連付けられるフロー情報内のフロー情報を選択し、
   前記第１のネットワークデバイスが前記ＳＡをキー変更する前記段階は、選択された前記フロー情報にさらに応じたものである、
   請求項２または３に記載の方法。
7. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がある場合に前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードをさらに保持し、前記第１のキー変更応答は、前記第１のキー変更要求に保持される前記第１のネットワークデバイスに関連付けられる前記フロー情報内に一致するフロー情報が存在しないことを示すためにＴＳ許容不可能通知を保持し、
   前記方法はさらに、
   ネゴシエーションされたフロー情報が取得されるまで前記第１のネットワークデバイスが前記第２のネットワークデバイスと再ネゴシエーションする段階を含み、
   前記第１のネットワークデバイスが前記ＳＡをキー変更する前記段階が、前記ネゴシエーションされたフロー情報にさらに応じたものである、
   請求項２または３に記載の方法。
8. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がない場合には前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持せず、前記第１のキー変更応答は、前記第２のネットワークデバイスに関連付けられるフロー情報に変更がない場合には前記第２のネットワークデバイスに関連付けられるＴＳペイロードを保持せず、
   前記第１のネットワークデバイスが前記ＳＡをキー変更する前記段階は、前記ＳＡに関連付けられるフロー情報の変更を伴わない、
   請求項２または３に記載の方法。
9. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がない場合には前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持せず、前記第１のキー変更応答は、前記第２のネットワークデバイスに関連付けられるフロー情報に変更がある場合にＴＳ許容不可能通知を保持し、
   前記方法はさらに、
   ネゴシエーションされたフロー情報が取得されるまで前記第１のネットワークデバイスが前記第２のネットワークデバイスと再ネゴシエーションする段階を含み、
   前記第１のネットワークデバイスが前記ＳＡをキー変更する前記段階が、前記ネゴシエーションされたフロー情報にさらに応じたものである、
   請求項２または３に記載の方法。
10. 前記第１のキー変更要求が、子ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求であり、前記ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求が、前記第１のＳＰＩを保持するＮＥＷ＿ＳＰＩ通知ペイロードを保持するか、または前記第１のＳＰＩを保持する軽量ＳＡペイロードを保持し、前記ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求が、前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持し、
    前記第１のキー変更応答が、前記ＩＫＥ ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答であり、前記ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答が、前記第２のＳＰＩを保持するＮＥＷ＿ＳＰＩ通知ペイロードを保持するか、または前記第２のＳＰＩを保持する別の軽量ＳＡペイロードを保持し、前記ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答が、前記第２のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持しない、
    請求項７に記載の方法。
11. 前記ＳＡをキー変更するために前記第１のキー変更要求を前記第２のネットワークデバイスに送信する前記段階の前に、前記方法はさらに、
    前記第１のネットワークデバイスが軽量キー変更をサポートすることを示す軽量キー変更サポート通知を前記第１のネットワークデバイスが前記第２のネットワークデバイスに送信する段階と、
    前記第１のネットワークデバイスが、前記第２のネットワークデバイスもペイロード軽量キー変更をサポートすることを示す別の軽量キー変更サポート通知を保持する応答を受信する段階と、を含む、
    請求項１から１０のいずれか一項に記載の方法。
12. 前記軽量キー変更サポート通知が、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求メッセージ内の通知ペイロードに保持され、前記別の軽量キー変更サポート通知が、ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答メッセージまたはＩＫＥ＿ＳＡ＿ＡＵＴＨ応答メッセージ内の通知ペイロードに保持されるか、または
    前記軽量キー変更サポート通知が、ＩＫＥ＿ＳＡ＿ＡＵＴＨ要求メッセージ内の通知ペイロードに保持され、前記別の軽量キー変更サポート通知が、ＩＫＥ＿ＳＡ＿ＡＵＴＨ応答メッセージ内の通知ペイロードに保持される、
    請求項１１に記載の方法。
13. 前記通知ペイロードのタイプが、ＩＫＥＶ２＿ＲＥＫＥＹ＿ＯＰＴＩＯＮＡＬ＿ＰＡＹＬＯＡＤ＿ＳＵＰＰＯＲＴＥＤである、請求項１２に記載の方法。
14. 第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムに適用される、セキュリティアソシエーション（ＳＡ）をキー変更するための方法であって、前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）トンネルおよびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立され、前記方法は、
    前記第２のネットワークデバイスが、ＳＡをキー変更するために前記第１のネットワークデバイスから第１のキー変更要求を受信する段階であって、前記第１のキー変更要求が、第１のセキュリティパラメータインデックス（ＳＰＩ）および前記第１のネットワークデバイスに関連付けられる暗号スイートを保持する、受信する段階と、
    前記第２のネットワークデバイスが、前記第２のネットワークデバイスに関連付けられる暗号スイートに変更があるかどうかを決定する段階と、
    を備え、前記方法は更に、
    前記第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合に、
    前記第２のネットワークデバイスが、前記第１のネットワークデバイスに第１のキー変更応答を送信する段階であって、前記第１のキー変更応答が、第２のＳＰＩを保持し、前記第２のネットワークデバイスに関連付けられる暗号スイートを保持しない、送信する段階と、
    前記第１のＳＰＩおよび前記第２のＳＰＩに応じて前記ＳＡをキー変更する段階と
    を備え、
    前記第２のネットワークデバイスに関連付けられる暗号スイートに変更がある場合に、前記第２のネットワークデバイスが、前記第１のネットワークデバイスに第１のキー変更応答を送信する段階であって、前記第１のキー変更応答が、変更された暗号スイートを保持する、送信する段階、を備える、
    方法。
15. 前記第１のキー変更応答が、前記第１のキー変更要求に保持される前記第１のネットワークデバイスに関連付けられる前記暗号スイート内に一致する暗号スイートが存在しないことを示す提案未選択通知を保持し、
    前記方法はさらに、
    ネゴシエーションされた暗号スイートが取得されるまで前記第２のネットワークデバイスが前記第１のネットワークデバイスと再ネゴシエーションする段階を含み、
    前記ＳＡが、前記ネゴシエーションされた暗号スイートにさらに応じてキー変更される、
    請求項１４に記載の方法。
16. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がある場合に前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードをさらに保持し、前記第１のキー変更応答は、前記第２のネットワークデバイスに関連付けられるフロー情報に変更がない場合には前記第２のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持せず、前記第２のネットワークデバイスに関連付けられる現在使用中のフロー情報は、前記第１のネットワークデバイスに関連付けられる前記フロー情報内に存在し、
    前記ＳＡが、前記第２のネットワークデバイスに関連付けられる前記現在使用中のフロー情報にさらに応じてキー変更される、
    請求項１４に記載の方法。
17. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がある場合に前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードをさらに保持し、前記第１のキー変更応答は、前記第２のネットワークデバイスに関連付けられる前記フロー情報に変更がある場合に前記第２のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持し、前記第２のネットワークデバイスは、前記第２のネットワークデバイスに関連付けられる前記フロー情報として前記第１のキー変更要求に保持される前記第１のネットワークデバイスに関連付けられるフロー情報内のフロー情報を選択し、
    前記ＳＡは、選択された前記フロー情報にさらに応じてキー変更される、
    請求項１４に記載の方法。
18. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がある場合に前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードをさらに保持し、前記第１のキー変更応答は、前記第１のキー変更要求に保持される前記第１のネットワークデバイスに関連付けられる前記フロー情報内に一致するフロー情報が存在しないことを示すためにＴＳ許容不可能通知を保持し、
    前記方法はさらに、
    ネゴシエーションされたフロー情報が取得されるまで前記第２のネットワークデバイスが前記第１のネットワークデバイスと再ネゴシエーションする段階を含み、
    前記ＳＡが、前記ネゴシエーションされたフロー情報にさらに応じてキー変更される、
    請求項１４に記載の方法。
19. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がない場合には前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持せず、前記第１のキー変更応答は、前記第２のネットワークデバイスに関連付けられるフロー情報に変更がない場合には前記第２のネットワークデバイスに関連付けられるＴＳペイロードを保持せず、
    前記ＳＡは、前記ＳＡに関連付けられるフロー情報の変更を伴わずにキー変更される、
    請求項１４に記載の方法。
20. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、フロー情報に変更がない場合には前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持せず、前記第１のキー変更応答は、前記第２のネットワークデバイスに関連付けられるフロー情報に変更がある場合にＴＳ許容不可能通知を保持し、
    前記方法はさらに、
    ネゴシエーションされたフロー情報が取得されるまで前記第２のネットワークデバイスが前記第１のネットワークデバイスと再ネゴシエーションする段階を含み、
    前記ＳＡが、前記ネゴシエーションされたフロー情報にさらに応じてキー変更される、
    請求項１４に記載の方法。
21. 前記ＴＳ許容不可能通知が、前記第１のキー変更応答に保持されるＴＳ＿ＵＮＡＣＣＥＰＴＡＢＬＥ通知ペイロードである、
    請求項２０に記載の方法。
22. 前記ＳＡがＩＫＥ ＳＡであるとき、前記第１のキー変更要求は、前記ＩＫＥ ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求であり、前記ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、前記第１のＳＰＩと、前記第１のネットワークデバイスに関連付けられる前記暗号スイートとを保持するＳＡペイロードを保持し、前記第１のキー変更応答は、前記ＩＫＥ ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答であり、前記ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、前記第２のＳＰＩを保持するＮＥＷ＿ＳＰＩ通知ペイロードを保持するか、または前記第２のＳＰＩを保持する軽量ＳＡペイロードを保持し、
    前記ＳＡが、前記ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、子ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求であり、前記ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求は、前記第１のＳＰＩと、前記第１のネットワークデバイスに関連付けられる前記暗号スイートとを保持するＳＡペイロードを保持し、前記第１のキー変更応答は、前記子ＳＡをキー変更するためのＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答であり、前記ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ応答は、前記第２のＳＰＩを保持するＮＥＷ＿ＳＰＩ通知ペイロードを保持するか、または前記第２のＳＰＩを保持する軽量ＳＡペイロードを保持する、
    請求項１４に記載の方法。
23. 前記第１のネットワークデバイスから、前記ＳＡをキー変更するための前記第１のキー変更要求を受信する前記段階の前に、前記方法がさらに、
    前記第２のネットワークデバイスが、前記第１のネットワークデバイスがキー変更任意ペイロードをサポートすることを示す通知を前記第１のネットワークデバイスから受信する段階と、
    前記第２のネットワークデバイスも前記キー変更任意ペイロードをサポートすることを示す応答を前記第２のネットワークデバイスが送信する段階とを含む、
    請求項１４から２２のいずれか一項に記載の方法。
24. 前記通知が、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求メッセージ内の通知ペイロードに保持され、前記応答を送信する前記段階が、ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答メッセージもしくはＩＫＥ＿ＳＡ＿ＡＵＴＨ応答メッセージ内の通知ペイロードを使用することにより実行されるか、または
    前記通知が、ＩＫＥ＿ＳＡ＿ＡＵＴＨ要求メッセージ内の通知ペイロードに保持され、前記応答を送信する前記段階が、ＩＫＥ＿ＳＡ＿ＡＵＴＨ応答メッセージ内の通知ペイロードを使用することにより実行される、
    請求項２３に記載の方法。
25. 前記通知ペイロードのタイプが、ＩＫＥＶ２＿ＲＥＫＥＹ＿ＯＰＴＩＯＮＡＬ＿ＰＡＹＬＯＡＤ＿ＳＵＰＰＯＲＴＥＤである、請求項２４に記載の方法。
26. 第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更するためのネットワークデバイスであって、前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）およびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立され、前記ネットワークデバイスが、前記第１のネットワークデバイスとして構成され、
    ＳＡをキー変更するための第１のキー変更要求を前記第２のネットワークデバイスに送信するように構成された送信モジュールであって、前記第１のキー変更要求が、第１のセキュリティパラメータインデックス（ＳＰＩ）および前記第１のネットワークデバイスに関連付けられる暗号スイートを保持する、送信モジュールと、
    前記第２のネットワークデバイスから第１のキー変更応答を受信するように構成された受信モジュールであって、前記第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、前記第１のキー変更応答が第２のＳＰＩを保持し、前記第２のネットワークデバイスに関連付けられる暗号スイートを保持しない、受信モジュールと、
    前記第１のＳＰＩおよび前記第２のＳＰＩに応じて前記ＳＡをキー変更するように構成されたキー変更モジュールと、を備え、
    前記第２のネットワークデバイスに関連付けられる暗号スイートに変更がある場合、前記受信モジュールは、前記第２のネットワークデバイスから第１のキー変更応答を受信するように構成され、前記第１のキー変更応答が、変更された暗号スイートを保持する、
    ネットワークデバイス。
27. 前記第１のキー変更要求に保持される前記第１のネットワークデバイスに関連付けられる前記暗号スイート内に一致する暗号スイートが存在しない場合に、前記第１のキー変更応答が、前記第２のネットワークデバイスからの提案未選択通知を保持し、前記ネットワークデバイスがさらに、ネゴシエーションされた暗号スイートが取得されるまで前記第２のネットワークデバイスと再ネゴシエーションするように構成された再ネゴシエーションモジュールを含み、
    前記キー変更モジュールが、前記ネゴシエーションされた暗号スイートにさらに応じて前記ＳＡをキー変更するように構成される、
    請求項２６に記載のネットワークデバイス。
28. 前記再ネゴシエーションモジュールが、前記第１のネットワークデバイスに関連付けられる更新された暗号スイートを前記第２のネットワークデバイスに送信して、ネゴシエーションされた暗号スイートが取得されるまで前記第２のネットワークデバイスとネゴシエーションするように構成される、
    請求項２７に記載のネットワークデバイス。
29. 第１のネットワークデバイスおよび第２のネットワークデバイスを含むネットワークシステムにおいてセキュリティアソシエーション（ＳＡ）をキー変更するためのネットワークデバイスであって、前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間にインターネットキー交換（ＩＫＥ）およびインターネットプロトコルセキュリティ（ＩＰＳｅｃ）トンネルが確立され、前記ネットワークデバイスが、前記第２のネットワークデバイスとして構成され、
    ＳＡをキー変更するための第１のキー変更要求を前記第１のネットワークデバイスから受信するように構成された受信モジュールであって、前記第１のキー変更要求が、第１のセキュリティパラメータインデックス（ＳＰＩ）および前記第１のネットワークデバイスに関連付けられる暗号スイートを保持する、受信モジュールと、
    前記第２のネットワークデバイスに関連付けられる暗号スイートに変更があるかどうかを決定するように構成された決定モジュールと、
    第１のキー変更応答を前記第１のネットワークデバイスに送信するように構成された送信モジュールであって、前記第２のネットワークデバイスに関連付けられる暗号スイートに変更がない場合、前記第１のキー変更応答が、第２のＳＰＩを保持し、前記第２のネットワークデバイスに関連付けられる前記暗号スイートを保持しない、送信モジュールと、
    前記第１のＳＰＩおよび前記第２のＳＰＩに応じて前記ＳＡをキー変更するように構成されたキー変更モジュールと、を備え、
    前記第２のネットワークデバイスに関連付けられる暗号スイートに変更がある場合、前記送信モジュールは、前記第１のネットワークデバイスに第１のキー変更応答を送信するように構成され、前記第１のキー変更応答が、変更された暗号スイートを保持する、
    ネットワークデバイス。
30. 前記第１のキー変更応答が、前記第１のキー変更要求に保持される前記第１のネットワークデバイスに関連付けられる前記暗号スイート内に一致する暗号スイートが存在しないことを示す提案未選択通知を保持し、 前記ネットワークデバイスがさらに、ネゴシエーションされた暗号スイートが取得されるまで前記第１のネットワークデバイスと再ネゴシエーションするように構成された再ネゴシエーションモジュールを含み、
    前記ＳＡが、前記ネゴシエーションされた暗号スイートにさらに応じてキー変更される、
    請求項２９に記載のネットワークデバイス。
31. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がある場合に前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードをさらに保持し、前記第１のキー変更応答は、前記第２のネットワークデバイスに関連付けられるフロー情報に変更がない場合には前記第２のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持せず、前記第２のネットワークデバイスに関連付けられる現在使用中のフロー情報は、前記第１のネットワークデバイスに関連付けられる前記フロー情報内に存在し、
    前記ＳＡが、前記第２のネットワークデバイスに関連付けられる前記現在使用中のフロー情報にさらに応じてキー変更される、
    請求項２９に記載のネットワークデバイス。
32. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がある場合に前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードをさらに保持し、前記第１のキー変更応答は、前記第２のネットワークデバイスに関連付けられる前記フロー情報に変更がある場合に前記第２のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持し、前記第２のネットワークデバイスは、前記第２のネットワークデバイスに関連付けられる前記フロー情報として前記第１のキー変更要求に保持される前記第１のネットワークデバイスに関連付けられるフロー情報内のフロー情報を選択し、
    前記ＳＡは、選択された前記フロー情報にさらに応じてキー変更される、
    請求項２９に記載のネットワークデバイス。
33. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がある場合に前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードをさらに保持し、前記第１のキー変更応答は、前記第１のキー変更要求に保持される前記第１のネットワークデバイスに関連付けられる前記フロー情報内に一致するフロー情報が存在しないことを示すためにＴＳ許容不可能通知を保持し、
    前記ネットワークデバイスがさらに、ネゴシエーションされたフロー情報が取得されるまで前記第１のネットワークデバイスと再ネゴシエーションするように構成された再ネゴシエーションモジュールを含み、
    前記ＳＡが、前記ネゴシエーションされたフロー情報にさらに応じてキー変更される、
    請求項２９に記載のネットワークデバイス。
34. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、前記第１のネットワークデバイスに関連付けられるフロー情報に変更がない場合には前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持せず、前記第１のキー変更応答は、前記第２のネットワークデバイスに関連付けられるフロー情報に変更がない場合には前記第２のネットワークデバイスに関連付けられるＴＳペイロードを保持せず、
    前記ＳＡは、前記ＳＡに関連付けられるフロー情報の変更を伴わずにキー変更される、
    請求項２９に記載のネットワークデバイス。
35. 前記ＳＡが、ＩＫＥ ＳＡの子ＳＡであるＩＰＳｅｃ ＳＡであるとき、前記第１のキー変更要求は、フロー情報に変更がない場合には前記第１のネットワークデバイスに関連付けられるフロー情報を保持するＴＳペイロードを保持せず、前記第１のキー変更応答は、前記第２のネットワークデバイスに関連付けられるフロー情報に変更がある場合にＴＳ許容不可能通知を保持し、
    前記ネットワークデバイスがさらに、ネゴシエーションされたフロー情報が取得されるまで前記第１のネットワークデバイスと再ネゴシエーションするように構成された再ネゴシエーションモジュールを含み、
    前記ＳＡが、ネゴシエーションされたフロー情報にさらに応じてキー変更される、
    請求項２９に記載のネットワークデバイス。
36. 前記ＴＳ許容不可能通知が、前記第１のキー変更応答に保持されるＴＳ＿ＵＮＡＣＣＥＰＴＡＢＬＥ通知ペイロードである、請求項３５に記載のネットワークデバイス。
37. セキュリティアソシエーション（ＳＡ）をキー変更するためのネットワークシステムであって、前記ネットワークシステムが、請求項２６から２８のいずれか一項に記載の第１のネットワークデバイスと、請求項２９から３６のいずれか一項に記載の第２のネットワークデバイスとを含む、ネットワークシステム。

Images