GDOI は、グループ キー管理のための、Internet Security Association Key Management Protocol（ISAKMP）ドメイン オブ インタープリテーション（DOI）として定義されています。グループ管理モデルでは、GDOI プロトコルが、グループ メンバーと、グループ コントローラまたはキー サーバ（GCKS）との間で動作し、その結果、認証されているグループ メンバー間での SA が確立されます。ISAKMP では、ネゴシエーションの 2 つのフェーズが定義されています。GDOI は、フェーズ 1 の ISAKMP セキュリティ アソシエーションによって保護されます。フェーズ 2 の交換は、RFC 6407 によって定義されています。次の図に示したトポロジとそれに続く説明は、このプロトコルのしくみを説明したものです。

グループ メンバーは、グループと通信するために必要な IPsec SA または SA を取得するためのキー サーバに登録します。グループ メンバーによって、そのグループの個別のポリシーおよびキーを取得するためのキー サーバにグループ ID が提供されます。これらのキーは、現在の IPsec SA が期限切れになる前に、定期的に更新されます。その結果、トラフィックのロスがなくなります。

show crypto isakmp sa detail コマンドの出力では、GET VPN のキー暗号化キー（KEK）キー再生成認証に RSA 署名が使用されるため、セキュリティ アソシエーション（SA）認証を「rsig」として表示します。

キー サーバの役割には、ポリシーの維持や、グループのキーの作成および維持などがあります。グループ メンバーが登録されると、キー サーバによってこのポリシーおよびキーが、グループ メンバーに対してダウンロードされます。また、キー サーバは、既存のキーの期限が切れる前にグループに対してキーの再生成を実行します。

Note	Cisco IOS XE リリース 3.5S 以前のリリースでは、キー サーバは Cisco ASR 1000 シリーズ ルータではサポートされていません。これらは Cisco IOS T ベースまたはメインラインベース イメージを使用して設定する必要があります。これは、Cisco IOS XE リリース 3.6S 以降のリリースの制限ではありません。

キー サーバには、登録要求の処理およびキーの再生成の送信という 2 つの機能があります。グループ メンバーはいつでも登録可能で、最新のポリシーおよびキーを受信できます。グループ メンバーがキー サーバに登録する場合、キー サーバによって、グループ メンバーが参加を試みているグループ ID が確認されます。この ID が有効なグループ ID だった場合、キー サーバによって、SA ポリシーがグループ メンバーに対して送信されます。ダウンロードされたポリシーを処理できることがグループ メンバーによって確認されると、キー サーバから各キーがダウンロードされます。

キー サーバからダウンロードされるキーには、キー暗号キー（KEK）とトラフィック暗号キー（TEK）の 2 種類があります。TEK は、同じグループ内のグループ メンバーどうしの通信で使用される IPsec SA になります。KEK は、キー再生成メッセージを暗号化します。

IPsec SA の期限切れが近づいた場合、またはキー サーバ上のポリシーが変更（コマンドライン インターフェイス [CLI] を使用）された場合、GDOI サーバによってキー再生成メッセージが送信されます。CSCti89255 では、KEK タイマーが期限切れになる前に KEK のキー再生成が行われます。グループ メンバーもタイマーを開始し、タイマーの期限が切れる前に更新されたキーを受け取ることを期待します。これらを受け取らない場合、グループ メンバーは KEK の期限切れの前にジッタが生じた再登録を開始します。KEK ライフタイムが期限切れになると、KEK は削除されます。

パケット損失に備えて、キー再生成メッセージが定期的に送信される場合もあります。パケット損失が発生する原因としては、信頼できる転送を使用することなくキー再生成メッセージが送信されることなどが考えられます。キーの再生成メカニズムがマルチキャストである場合は、受信者がキーの再生成メッセージを受信できなかったことを示す有効なフィードバック メカニズムがないため、定期的に再送信することによってすべての受信者が最新の情報を受信できるようにします。キー再生成メカニズムがユニキャストである場合、受信元によって確認応答メッセージが送信されます。

上記のトポロジは、次のようにグループ メンバーがグループに参加するうえで必要なプロトコル フローを示しています。

1. グループ メンバーがキー サーバに登録されます。キー サーバによってグループ メンバーが認証および許可され、グループ メンバーが IP マルチキャスト パケットを暗号化および復号化するうえで必要な IPsec ポリシーおよびキーがダウンロードされます。

2. 必要に応じて、キー サーバからグループ メンバーに対してキーの再生成メッセージが「プッシュ」されます。キー再生成メッセージには、古い IPsec SA の期限が切れた際に使用される新しい IPsec ポリシーおよびキーが格納されています。常に有効なグループ キーが使用できるように、キーの再生成メッセージは SA の期限が切れる前に送信されます。

3. 各グループ メンバーは、キー サーバによって認証を受けてから、キー サーバから受信した IPsec SA を使用して、同じグループ内の他の認証済みグループ メンバーと通信します。

マルチキャスト キー再生では、グループのポリシーおよびキーを配信するために GDOI プロトコル（RFC 6407）が使用されます。GDOI プロトコルは、キー サーバとグループ メンバーの間で使用されます。キー サーバによってポリシーとキーが作成および維持され、さらに、認証された各グループ メンバーにダウンロードされます。

GDOI プロトコルは、ISAKMP フェーズ 1 交換によって保護されます。GDOI キー サーバと GDOI グループ メンバーの ISAKMP ポリシーは同じである必要があります。このフェーズ 1 ISAKMP ポリシーは、そのポリシーに従う GDOI プロトコルを保護できる程度に強力なものである必要があります。GDOI プロトコルは、フェーズ 1 ISAKMP ポリシーに従う 4 メッセージ交換です。フェーズ 1 ISAKMP 交換は、メイン モードまたはアグレッシブ モードで発生する可能性があります。

次の図は、ISAKMP フェーズ 1 交換を示しています。

上記メッセージ（ISAKMP フェーズ 1 メッセージと 4 つの GDOI プロトコル メッセージ）を GDOI 登録と呼びます。上に示した交換全体は、グループ メンバーとキー サーバ間のユニキャスト交換です。

キー再生成メカニズムがマルチキャストである場合、登録中、グループ メンバーによってマルチキャスト グループのアドレスが受信され、そのグループ メンバーが、マルチキャスト キー再生成を受信するうえで必要なマルチキャスト グループに登録されます。

GDOI プロトコルでは、ユーザ データグラム プロトコル（UDP）ポート 848 が使用されます（Network Address Translation-Traversal（NAT-T）が使用されている場合、ポートは 4500 まで変化します）。

IPsec は、IP レイヤのトラフィックのための各種セキュリティ サービスを提供するためのアーキテクチャが定義された、よく知られた RFC です。IETF RFC 2401 には、各種コンポーネントおよびそれらがどのように互いに組み合されて IP 環境を形成しているかが記述されています。

キー サーバとグループ メンバーは、GET VPN アーキテクチャを構成する 2 つのコンポーネントです。キー サーバには、グループ認証キーと IPsec SA が保存され、グループ メンバーに対して提供されます。

グループ メンバーでは、対象となるトラフィック（暗号化するに値し、IPsec によってセキュリティ保護されるトラフィック）に対して暗号化サービスが提供されます。

キー サーバとグループ メンバー間における通信は暗号化およびセキュリティ保護されます。GDOI には、TEK と KEK という 2 つのキーがサポートされています。TEK は、キー サーバからすべてのグループ メンバーにダウンロードされます。ダウンロードされた TEK は、グループ メンバー間で安全に通信するためにすべてのグループ メンバーで使用されます。このキーは、実質的には、すべてのグループ メンバーによって共有されるグループ キーとなります。グループ ポリシーおよび IPsec SA は、グループ メンバーへの定期的なキーの再生成メッセージを使用して、キー サーバによってリフレッシュされます。KEK もキー サーバによってダウンロードされ、グループ メンバーによって、キー サーバから受信するキーの再生成メッセージの復号化に使用されます。

キー サーバによって、GDOI グループのグループ ポリシーと IPsec SA が生成されます。キー サーバによって生成される情報には、複数の TEK 属性、トラフィック暗号化ポリシー、ライフタイム、送信元と宛先、各 TEK に関連付けられるセキュリティ パラメータ インデックス（SPI）ID、キーの再生成ポリシー（1 つの KEK）などがあります。

次の図に、グループ メンバーおよびキー サーバ間の通信フローを示します。キー サーバは、グループ メンバーからの登録メッセージを受信したあと、グループ ポリシーと新しい IPsec SA を含む情報を生成します。次に、新しい IPsec SA がグループ メンバーにダウンロードされます。キー サーバでは、グループごとに、各グループ メンバーの IP アドレスを含むテーブルが保持されます。グループ メンバーが登録されると、キー サーバはメンバーの IP アドレスを関連するグループのテーブルに追加します。これにより、キー サーバは、アクティブなグループ メンバーをモニタできるようになります。1 つのキー サーバで複数のグループをサポートできます。また、1 つのグループ メンバーは、複数のグループに属することができます。

IPsec と ISAKMP SA は、次のタイマーによって維持されます。

• TEK ライフタイム：IPsec SA のライフタイムを決定します。TEK ライフタイムが終了する前に、キー サーバによってキー再生成メッセージが送信されます。このメッセージには、新しい TEK 暗号キーと変換、および既存の KEK 暗号キーと変換が格納されています。TEK ライフタイムはキー サーバ上でだけ設定します。ライフタイムは、GDOI プロトコルによって各グループ メンバーに対して「プッシュ ダウン」されます。TEK ライフタイムの値はネットワークのセキュリティ ポリシーによって異なります。set security-association lifetime コマンドが設定されていない場合、デフォルト値である 86,400 秒が有効になります。TEK ライフタイムを設定するには、「IPsec ライフタイム タイマーの設定」セクションを参照してください。

• KEK ライフタイム：GET VPN キー再生成 SA のライフタイムを決定します。ライフタイムが終了する前に、キー サーバによってキー再生成メッセージが送信されます。このメッセージには、新しい KEK 暗号キーと変換、および新しい TEK 暗号キーと変換が格納されています。TEK ライフタイムはキー サーバ上でだけ設定します。ライフタイムは、GDOI プロトコルによって各グループ メンバーに対して動的にプッシュ ダウンされます。KEK ライフタイム値は、TEK ライフタイム値よりも大きい必要があります（KEK ライフタイム値は、TEK ライフタイム値の少なくとも 3 倍以上にすることが推奨されます）。 rekey lifetime コマンドが設定されていない場合、デフォルト値である 86,400 秒が有効になります。KEK ライフタイムを設定するには、「マルチキャスト キー再生成の設定」セクションを参照してください。

• ISAKMP SA ライフタイム：ISAKMP SA が期限切れになる前にどれだけの期間存在するべきかを定義します。ISAKMP SA ライフタイムは、グループ メンバーおよびキー サーバ上で設定します。グループ メンバーとキー サーバに連携可能なキー サーバがない場合、グループ メンバーの登録が終了しても ISAKMP SA は使用されません。このような（連携可能なキー サーバがない）場合、ISAKMP SA のライフタイムを短く設定できます（最小 60 秒）。連携可能なキー サーバが存在する場合は、連携可能なキー サーバの通信中に ISAKMP SA を「アップ」の状態に保つため、すべてのキー サーバのライフタイムを長く設定する必要があります。 lifetime コマンドが設定されていない場合、デフォルト値である 86,400 秒が有効になります。ISAKMP SA ライフタイムを設定するには、「ISAKMP ライフタイム タイマーの設定」セクションを参照してください。

TEK/KEK ライフタイムが終了する前に、KS は、シーケンス番号を 1 つ増やしたキー再生成メッセージを送信します。ただし、最後のキー再生成メッセージの送信以降にセカンダリ KS がプライマリ KS になった場合、新しいプライマリ KS は、キー再生成メッセージのシーケンス番号を 10 ずつ増やします。

プライマリ KS とセカンダリ KS は、20 秒ごとにシーケンス番号を同期します。

次の例は、プライマリ KS（KS1）とセカンダリ KS（KS2）で構成される展開においてキー再生成メッセージのシーケンス番号がどのように変化するのかを示しています。この例では、シーケンス番号の初期値が 1 であると想定されています。

また、展開に多数の GM があることと、KS がキー再生成メッセージの配信を再試行する必要がある場合があることも想定されています。シーケンス番号は、再試行ごとに 1 ずつ増加します。

1. キー再生成メッセージを送信する時間になると、KS1 はシーケンス番号を 2 に増やします。

2. すべての GM がメッセージを受信するように、KS1 がキー再生成メッセージを 3 回再送信するとします。再試行ごとに、シーケンス番号が 1 ずつ増加します。そのため、このキー再生成が終わったときのシーケンス番号の値は 5 です。

3. 次のキー再生成メッセージを送信する時間になると、KS1 がキー再生成メッセージを 1 回だけ送信するとします。そのため、この 2 回目のキー再生成が終わったときのシーケンス番号は 6 です。

4. 次のキー再生成メッセージが送信される前に、KS2 がプライマリ KS になるとします。

5. キー再生成メッセージを送信する時間になると、KS2 はシーケンス番号を 10 ずつ増やします。そのため、キー再生成メッセージはシーケンス番号 16 で送信されます。

6. すべての GM がメッセージを受信するように、KS2 がキー再生成メッセージを 2 回再送信するとします。再試行ごとに、シーケンス番号が 1 ずつ増加します。そのため、このキー再生成が終わったときのシーケンス番号の値は 18 です。

7. 次のキー再生成メッセージが送信される前に、KS1 がプライマリ KS になるとします。

8. キー再生成メッセージを送信する時間になると、KS1 はシーケンス番号を 10 ずつ増やします。そのため、キー再生成メッセージはシーケンス番号 28 で送信されます。KS1 がキー再生成メッセージを 1 回だけ送信するとします。キー再生成が終わったときのシーケンス番号は 28 です。

9. 次のキー再生成メッセージを送信する時間になると、KS1 はシーケンス番号を 1 ずつ増やします。KS1 がキー再生成メッセージを 1 回だけ送信するとします。キー再生成が終わったときのシーケンス番号は 29 です。

次の表に、各キー再生成動作でのシーケンス番号の変化の概要を示します。

キー サーバとグループ メンバー間のキー再生成シーケンス番号のチェックは次のように行われます。

1. GROUPKEY-PUSH メッセージのアンチリプレーは RFC 6407 で規定されているように復元されます。

   • グループ メンバーは、最後に受信したキー再生成メッセージのシーケンス番号以下の番号のキー再生成メッセージをすべてドロップします。
   • グループ メンバーは、最後に受信したキー再生成メッセージのシーケンス番号より大きい番号のキー再生成メッセージをすべて（差がどれだけ大きくても）承認します。

2. シーケンス番号は、KEK 再生成メッセージ時ではなく、KEK 再生成キーの後の最初のキー再生成メッセージ時に 1 にリセットされます。

マルチキャスト キー再生成は、有効なマルチキャスト キー再生成が使用されて送信されます。登録が成功すると、グループ メンバーが特定のマルチキャスト グループに登録されます。グループに登録されているすべてのグループ メンバーによって、このマルチキャスト キー再生成が受信されます。マルチキャスト キー再生成は、キー サーバに設定されているライフタイムに基づいて定期的に送信されます。IPsec またはキー再生成ポリシーがキー サーバ上で変更された場合もマルチキャスト キー再生成が送信されます。設定の変更によってトリガーされると、キー再生成によって、新しく更新されたポリシーが有効なマルチキャスト キー再生成を持つすべてのグループ メンバーに送信されます。

キー サーバによって、キー再生成の時間が次のようにプッシュ バックされます。

1. TEK のタイムアウトが 300 秒の場合：

tek_rekey_offset = 90（300 < 900 のため）

再送信が設定されている場合、キー再生成タイマーがさらに戻されます。

3 つの再送信がすべて 10 秒の場合：3 * 10

その結果、キー再生成が実際に発生するのは (300 - 90 - 30) = 180 秒

2. TEK のタイムアウトが 3600 秒の場合：

tek_rekey_offset = 3600 * 10% = 360 秒

再送信が設定されている場合、キー再生成タイマーがさらに戻されます。

3 つの再送信がすべて 10 秒の場合：3 * 10

その結果、キー再生成が実際に発生するのは (3600 - 360 - 30) = 3210 秒

KEK の期限が切れ、転送モードがマルチキャストである場合、マルチキャスト KEK キー再生成が送信されます。マルチキャスト KEK が送信されると、グループ メンバーによって古い KEK が新しい KEK に置き換えられます。これはマルチキャスト キー再生成であり、再送信が送信されるので、古い KEK は引き続き暗号化に使用されます。このような状況が発生するのは、グループ メンバーによって新しい KEK キー再生成が受信されていないためです。そのため、マルチキャスト キー再生成を受信したグループ メンバーには古い KEK は存在せず、それらの再送信は廃棄されます。

最初に KEK キーを受信せず、現在は KEK 再送信を受信して古い KEK を新しい KEK に置き換えているグループ メンバーの場合、後の再送信は廃棄されます。たとえば、5 つの再送信が設定されており、シーケンス番号が 1 のマルチキャスト KEK キー再生成がグループ メンバー 1 で受信される場合、グループ メンバーに古い KEK がないため、シーケンス番号が 2、3、4、5、6 である他のすべての再送信は廃棄されます。

グループ メンバー 2 によってシーケンス番号が 1 の KEK キー再生成が取得されず、シーケンス番号が 2 である再送信が受信された場合、他の再送信 3、4、5、6 は廃棄されます。

大型のユニキャスト グループでは、遅延問題を軽減するため、キー サーバによって一度にごく少数のグループ メンバーのキー再生成メッセージだけが生成されます。すべてのグループ メンバーによって、古い SA の期限が切れる前に新しい SA の同じキー再生成メッセージが受信されることが、キー サーバには保証されています。さらに、ユニキャスト グループでは、キー サーバからのキー再生成メッセージが受信された後、グループ メンバーによって、暗号化された確認応答（ACK）メッセージが、キー再生成メッセージの一部として受信されたキーが使用されて、キー サーバに送信されます。キー サーバによって ACK メッセージが受信されると、その受信が関連するグループのテーブルに書き込まれ、次のことが実行されます。

• キー サーバにアクティブなグループ メンバーの最新リストが保管されます。

• キー サーバによって、アクティブなメンバーにだけキー再生成メッセージが送信されます。

さらに、ユニキャストグループでは、3 回連続したキー再生成が行われて ACK メッセージが 1 つもキー サーバによって受信されなかった場合、キー サーバによってアクティブ リストからグループ メンバーが削除され、その特定のグループ メンバーに対するキー再生成メッセージの送信が停止されます。3 回連続したキー再生成が行われて ACK メッセージが 1 つも受信されなくても、グループ メンバーがキー再生成メッセージを受信する必要がある場合には、現在の SA が期限切れになった後には、グループ メンバーはキー サーバに完全に再登録される必要があります。非応答グループ メンバーのイジェクトは、キー サーバがユニキャスト キー再生成モードで動作している場合にだけ行われます。マルチキャスト キー再生成モードでは、キー サーバによるグループ メンバーの排出は行われません。そのモードでは、グループ メンバーが ACK メッセージを送信できないからです。

マルチキャスト キー再生成におけるのと同様、再送信が設定されている場合、各キー再生成は、設定された回数再送信されます。

キー再生成転送モードおよび認証は、GDOI グループ下で設定できます。

ユニキャスト キー再生成転送モードが定義されていない場合、デフォルトでマルチキャストが適用されます。

TEK キー再生成が受信されなかった場合、現在の IPsec SA が期限切れになる 60 秒前にグループ メンバーがキー サーバに再登録されます。グループ メンバーの再登録が発生する前に、キー サーバによってキー再生成が送信される必要があります。再送信が設定されていない場合、SA が期限切れになる前に、キー サーバによってキー再生成 tek_rekey_offse が送信されます。tek_rekey_offset は、設定されているキー再生成ライフタイムに基づいて算出されます。TEK キー再生成のライフタイムが 900 秒より短い場合、tek_rekey_offset は 90 秒に設定されます。TEK キー再生成のライフタイムが 900 秒を超えるように設定されている場合、rekey_offset = (設定されている TEK キー再生成のライフタイム)/10 となります。再送信が設定されている場合、SA が期限切れになる 90 秒前に最新の再送信が送信されるように、tek_rekey_offset よりも前にキー再生成が発生します。

キー サーバでは、すべてのユニキャスト グループ メンバーに対するキー再生成の送信をいつ開始するか計算するために、次の例に示す数式が使用されます。キー サーバにおけるユニキャスト キー再生成処理によって、1 回のループで 50 のグループにおけるユニキャスト グループ メンバーに対してキー再生成が送信されます。このループ内でかかる時間は推定 5 秒です。

キー サーバによって、50 のグループのグループ メンバーのキー再生成が行われます。これは 2 回のループに相当します。たとえば、グループ メンバーの数が 100 の場合：

キー再生成ループの数 = (100 グループ メンバー)/50 = 2 ループ：

• 1 回のループでのキー再生成にかかる時間（推定）= 5 秒

• 50 の 2 回ループにおける 100 グループ メンバーに対するキー再生成にかかる時間：2 * 5 秒 = 10 秒

そのため、キー サーバによって、キー再生成の時間が次のようにプッシュ バックされます。

• TEK のタイムアウトが 300 の場合：300 - 10 = 290

ただし、開始は TEK が期限切れになるよりも前である必要があります（マルチキャストの場合と同じです）。

• 300 < 900 であるため、tek_rekey_offset = 90

• そのため、実際の TEK 時間から 90 秒を引いて、290 - tek_rekey_offset = 200 秒

再送信が設定されている場合、キー再生成タイマーがさらに戻されます。

• 3 つの再送信がすべて 10 秒の場合：200 - (3 * 10) = 170

• TEK のタイムアウトが 3600 秒である場合：3600 - 10 = 3590

ただし、開始は TEK が期限切れになるよりも前である必要があります（マルチキャストの場合と同じです）。

• 3600 > 900 であるため、tek_rekey_offset = 3600 * 10% = 360

• そのため、実際の TEK 時間から 360 秒を引いて、3590 - tek_rekey_offset = 3230 秒

再送信が設定されている場合、キー再生成タイマーがさらに戻されます。

• 3 つの再送信がすべて 10 秒の場合：3230 - (3 * 10) = 3200 秒

数式 tek_rekey_offset は、ユニキャストおよびマルチキャスト キー再生成に適用されます。

次の表に、セキュリティ ポリシーの変更に対応したキー再生成の動作の一覧を示します。

ポリシーの変更を即時に有効にするには、次の手順に従います。

• キーサーバーで clear crypto gdoi [group ] コマンドを使用します。

• すべてのグループメンバーで clear crypto gdoi [group ] コマンドを使用します。

Note	キー サーバは管理者がコンフィギュレーション モードを終了するとポリシーの更新のためのキー再生成を送信し、適切な場合にキー再生成が送信されるようにします。

Note	グループ メンバーで双方向モードに変更する前のパッシブ モードの動作は次のとおりです。 キー サーバの SA モードを「no sa receive-only」に変更し、コンフィギュレーション モードを終了する場合、キー再生成はグループ メンバーに送信され、「受信専用」から「発信オプション」にグループ メンバーの状態が変化するのを確認できます。組み込みタイマーによって設定されたインターバル（約 5 分）の後は「両方」に状態が変化します。 キー サーバはこの状態をすぐに「両方」として示します。すべてのグループ メンバーが更新される過程である可能性があるため、これは意図的に行われます。

グループ メンバー上でキー再生成が受信され、処理されると、新しい IPsec SA（SPI）がインストールされます。古い IPsec SA と新しい IPsec SA が共に使用される期間が存在します。指定された一定期間の経過後に、古い IPsec SA は削除されます。この重複によって、すべてのグループ メンバーが現在のキー再生成を受信し、新しい IPsec SA を追加できます。この動作は、キー サーバからのキー再生成のための転送モード（マルチキャストまたはユニキャスト キー再生成転送）とは無関係です。

グループ メンバー上では、古い SA が期限切れになる約 30 秒前に、グループ メンバーによって、パケットを暗号化するために発信方向で新しい SA が使用されます。古い SA が期限切れになる約 60 秒前にキー サーバからのキー再生成を介して新しい SA がグループ メンバー側で受信されていない場合、グループ メンバーが登録されます。

次の図では、時間 T2 が古い SA が期限切れになる時間です。T1 が T2 の 30 秒前で、これは、グループ メンバー（GM）によって発信方向で新しい SA の使用が開始される時間です。T0 は、T2 の 30 秒前です。T0 の時点で新しい SA が受信されない場合、グループ メンバーが登録される必要があります。T は、T0 の 30 秒前です。T の時点でキー サーバによってキー再生成が送信される必要があります。

Note	セキュリティに対する脅威は、脅威からの保護に役立つ暗号化技術と同様に絶え間なく変化しています。最新のシスコの暗号化に関する推奨事項については、『Next Generation Encryption』（NGE）ホワイト ペーパーを参照してください。

キー サーバ上の設定変更によって、キー サーバごとの再生成のトリガーが可能です。次のサンプル設定を参照し、サンプルに記述されたもののうち、キー再生成が発生する変更と発生しない変更を確認してください。

crypto ipsec transform-set gdoi-p esp-aes esp-sha-hmac
! 
crypto ipsec profile gdoi-p
 set security-association lifetime seconds 900
set transform-set gdoi-p 
!
crypto gdoi group diffint
 identity number 3333
 server local
  rekey algorithm aes 128
  rekey address ipv4 121
  rekey lifetime seconds 3600
  no rekey retransmit
  rekey authentication mypubkey rsa mykeys
  sa ipsec 1
   profile gdoi-p
   match address ipv4 120
   replay counter window-size 3

次に示すキー サーバ上での設定変更では、キー サーバからのキー再生成がトリガーされます。

• TEK 設定におけるすべての変更（例の「sa ipsec 1」）。

  • ACL（上記例の「match address ipv4 120」）が変更された場合。ACL におけるすべての追加、削除、または変更がキー再生成の原因となります。
  • TEK リプレイがキー サーバ上でイネーブルまたはディセーブルになっている場合、キー再生成が送信されます。
  • TEK 内の IPsec プロファイルの削除または追加（例の「profile gdoi-p」）。
  • マルチキャストからユニキャスト転送への変更。
  • ユニキャストからマルチキャスト転送への変更。

次に示すキー サーバ上での設定変更は、キー サーバからのキー再生成のトリガーとはなりません。

• TEK 下におけるリプレイ カウンタ ウィンドウ サイズの変更（例の「sa ipsec 1」）。

• キー再生成再送信の設定または削除。

• キー再生成 ACL の削除または設定。

• TEK ライフタイムの変更（上記例の「set security-association lifetime seconds 300」）または KEK ライフタイムの変更（例の「rekey lifetime seconds 500」）。

• キー再生成アルゴリズムの追加、削除、または変更（例の「rekey algorithm aes 128」）。

次の表は、GET VPN コマンドによる変更の包括的な一覧です。どのコマンドがキー再生成のトリガーとなり、どのコマンドがならないのかを示しています。各コマンドは、それらのコマンドが入力されるコンフィギュレーション モードに基づいて分類しています。表には、キー再生成のトリガーになるか否かを問わず、コマンドが有効になるタイミングも示しています。

Note	GDOI グループで KEK ライフタイムが変更されると、現在の KEK が期限切れになり、新しい KEK が生成された場合にのみ変更が適用されます。キーサーバーでキー再生成コマンドの crypto gdoi ks rekey を発行することにより、強制的に変更を適用できます。

疑似時間同期によってタイムアウトが発生した場合、KEK タイマーまたは TEK タイマーのどちらかが次の 60 秒間に期限切れになるようにスケジュールされているかどうかがキー サーバによって確認されます。そのようにスケジュールされている場合、そのタイムアウトと疑似時間同期タイムアウトが結合されます。つまり、そのキー再生成は TEK キー再生成または KEK キー再生成と、疑似時間同期タイムアウト キー再生成の両方として動作します。疑似時間同期の詳細については、「時間ベースのアンチ リプレイ」セクションを参照してください。

マルチキャスト キー再生成は、デフォルトで再送信されます。ユニキャスト キー再生成では、キー サーバが ACK を受信しない場合にキー再生成が再送信されます。どちらの場合も、キー再生成の再送信前に、次の 120 秒間にスケジュールされている TEK キー再生成または KEK キー再生成があるかどうかがキー サーバによって確認されます。ある場合、現在の再送信は停止され、スケジュールされたキー再生成が発生するまで待機します。

キー サーバで ACL または他のポリシーが変更されると、グループ メンバーの動作が変わります。次の 3 種類のシナリオで、グループ メンバーの動作に対するポリシーの各種変更の影響を説明します。

シナリオ 1

次の例では、ホスト A とホスト B を許可するように ACL が最初に設定されています。

ip access-list extended get-acl
permit ip host A host B
permit ip host B host A

次に、キー サーバで、ホスト C とホスト D を許可するように ACL が変更されます。

ip access-list extended get-acl
permit ip host C host D
permit ip host D host C

ACL の変更は、次の方法でグループ メンバーの動作に影響を与えます。

• キー サーバによって、ただちに、すべてのグループ メンバーに対してキー再生成が送信されます。

• キー再生成後ただちに、グループ メンバーによって、ホスト A とホスト B 間のトラフィックが暗号化されていないテキストで送信されます。

• キー再生成後ただちに、グループ メンバーによって、ホスト C とホスト D 間のトラフィックが暗号化されたテキストで送信されます。

Note	Cisco ASR 1000 シリーズ アグリゲーション サービス ルータと Cisco ISR G2 ルータの GETVPN グループメンバーは、キーサーバーでの ACL の変更またはその他のポリシー変更に続くキー再生成（トリガーまたは定期的）の後に、異なる動作をします。Cisco ISR G2 ルータのグループメンバーは、完全な再登録なしで新しいポリシーをインストールしますが、Cisco ASR 1000 シリーズ アグリゲーション サービス ルータのグループメンバーは、更新されたポリシーを取得するために再登録します。

グループ メンバーのクロックとキー サーバとの同期は、ずれたり失われたりする可能性があります。クロックの同期を維持するため、キー サーバの最新の疑似時間値が格納されたキー再生成メッセージ（マルチキャストがユニキャストかは状況に応じます）が（キー再生成メッセージで、あるいは、グループ メンバーに対して最小で 30 分ごとに）定期的に送信されます。このアンチ リプレイ チェックでパケットにエラーが発生した場合、送信元および受信元の両方の疑似時間がプリントされ、エラー メッセージが生成され、カウントの値が増分されます。

アンチリプレイの統計情報を表示するには、送信元および受信元デバイスの両方で show crypto gdoi group group-name gm replay コマンドを使用します。管理者がサイズ設定のリプレイ方法に影響を与えるような設定変更を行った場合、キー サーバによってキー再生成メッセージが発信されます。

ティックは、SAR クロックのインターバル期間です。この期間に送信された各パケットの pseudoTimeStamp は同じものになります。またティックは、キー サーバからの疑似時間と共にグループ メンバーにダウンロードされます。たとえば、次の図に示すように、T0 と T1 の間で送信されたパケットの pseudoTimeStamp は同じ T0 になります。SAR には、ルーズなアンチ リプレイ保護が用意されています。リプレイされたパケットは、それらがウィンドウ内にリプレイされている場合は、受信されます。デフォルトのウィンドウ サイズは 100 秒です。パケットのリプレイを最小限に抑えるため、ウィンドウ サイズを小さく保つことを推奨します。

アンチ リプレイ機能をキー サーバ上の IPsec SA 下でイネーブルにするには、次のコマンドを使用します。

• replay time window-size ：非シーケンシャルまたは時間ベースモードがサポートされるリプレイ時間オプションをイネーブルにします。ウィンドウ サイズは秒単位です。このモードは、1 つのグループ内に 3 つ以上のグループ メンバーが存在している場合にだけ使用します。

• replay counter window-size ：シーケンシャルモードをイネーブルにします。このモードは、1 つのグループ内に 2 つのグループ メンバーだけが存在している場合に便利です。

• no replay counter window-size ：アンチリプレイをディセーブルにします。

通知メッセージは IKE フェーズ 1 によってセキュリティ保護され、IKE 通知メッセージとして送信されます。IKE によって提供される認証および機密保持は、キー サーバ間のメッセージをセキュリティ保護するために使用されます。通知メッセージ内のシーケンス番号によって、アンチ リプレイ保護が提供されます。通知メッセージは定期的にプライマリ キー サーバからセカンダリ キー サーバに送信されます。

通知メッセージには、現在の状態を維持するための次のコンポーネントが含まれます。

グループ下の sa receive-only コマンドを削除します。sa receive-only コマンドを削除すると、このグループの新しい IPsec SA が作成され、キー再生成が開始されます。受信と同時に、グループ メンバーによって、双方向で SA が再インストールされ、その SA の passive モードでの使用が開始されます。SA が永続的に passive モードでいることはできないので、5 分間キー再生成がなかった場合、グループ メンバーによって、これらの SA が受信モードまたは送信モードに変更されます。passive モードから双方向暗号化モードへの変換は自動で行われるので、管理者は何もする必要はありません。

GET VPN GM 認証は、事前共有キーまたは PKI を使用して実行できます。GET VPN 認証をオンにすることはベスト プラクティスです。キー サーバが複数の GDOI グループに使用される際、あるグループの GM が別のグループからキーとポリシーを要求するのを防ぐには、キー サーバ認証が必要です。ISAKMP 認証では GM がキー サーバから GDOI 属性を要求できることが確認され、GDOI 認証では GM がキー サーバに設定された特定のグループから GDOI 属性を要求できることが確認されます。

GDOI 認証は、GM から送信された ISAKMP ID に基づきます。GM が ID として IP アドレスを送信すると、認証アドレスのみが認証に使用されます。GM が識別名（DN）またはホスト名を送信すると、認証 ID が使用されます。ID として IP アドレスを使用すると、DN またはホスト名と照合する認証がバイパスされます。逆も同様です。特定の DN の GM だけが接続できる（別の ID を使用する GM が接続できない）ようにするには、認証アドレスで deny any を指定する必要があります。

%GDOI-1-UNAUTHORIZED_IPADDR: Group getvpn received registration from
unauthorized ip address: 10.1.1.9

%GDOI-1-UNAUTHORIZED_IDENTITY: Group getvpn received registration from
unauthorized identity: Dist.name: hostname=GroupMember-1, ou=TEST

Fail-Close モードで作業するためにクリプト マップを設定する場合、注意しなければならないことがあります。Fail-Close ACL を正しく定義しないと、自分自身をロックアウトしてしまう可能性があります。たとえば、セキュアシェル（SSH）を使用して暗号マップが適用されたインターフェイス経由でルータにログインする場合、deny tcp any eq port host address コマンドラインを Fail-Close ACL 下に含める必要があります。キーサーバーへのパスを検索する場合は、ルータが使用しているルーティングプロトコル（deny ospf any any など）も含める必要がある場合もあります。最初に Fail-Close とその ACL を設定し、次に show crypto map gdoi fail-close map-name コマンドを使用して Fail-Close ACL を確認します。Fail-Close ACL を確認し、それが正しいと確信したら、activate コマンドを設定して、Fail-Close モードで暗号マップを動作させることができます。activate コマンドを設定しない限り、Fail-Close はアクティブになりません。

Fail-Close ACL はグループ メンバーの視点で設定します。Fail-Close ACL は、グループ メンバー上で次のように設定されます。

access-list 125 deny ip host host1-ip-addr host2-ip-addr

Fail-Close モードでは、host1 から host2 へのすべての IP トラフィックが、Group Member 1 によって、暗号化されていないテキストで送信されます。さらに、着信ミラー トラフィック（つまり、host2 から host1 への IP トラフィック）も、GM1 によって暗号化されていないテキストで受信されます。

Note	deny エントリに一致するすべての IP トラフィックは、グループ メンバーによって、暗号化されていないテキストで送信されます。

着信トラフィックは、ミラー アクセス リストに対応付けられます。

Fail-Close アクセス リストは、グループ メンバー アクセス リストと同じルールに従います。詳細は、「グループ メンバー アクセス コントロール リスト」のセクションを参照してください。

GDOI 登録を行うために deny udp any eq 848 any eq 848 コマンドを設定する必要はありません。コード自体によって、そのコードの設定対象となっているキー サーバからの、特定のグループ メンバーの GDOI パケットであるかどうかが判断されます。そのグループ メンバーの GDOI パケットだった場合、そのパケットは処理されます。ただし、キーサーバーがグループメンバー 1 の後になるシナリオでは、グループメンバー 1 がキーサーバーに正常に登録できない場合、グループメンバー 1 に対して明示的に deny udp any eq 848 any eq 848 コマンドラインが設定されていない限り、他のグループメンバーも登録できなくなります。しかし、Fail-Close 機能が正しく設定されている場合は、グループ メンバーがキー サーバへの登録に失敗しても、望まないトラフィックが「暗号化されずに」出ていくことがないようにすることができます。ただし、他のグループ メンバーからの登録パケットが、登録に失敗した場合でもグループ メンバー 1 経由でキー サーバに到達できる場合、指定されたトラフィックが暗号化されずに出ていくことを許可することができます。

Fail-Close モードの設定の詳細については、「Fail-Close モードのアクティブ化」セクションを参照してください。

Fail-Close モードがアクティブになっているか確認するには、show crypto map gdoi fail-close コマンドを使用します。