ほとんどの Cisco ACI 展開で、ディザスタリカバリとスケーリングに対処する Multi-Site アーキテクチャを採用しているため、ローカル サイト内で MACsec 暗号化を使用する現在のセキュリティ実装は、複数のサイトにわたるデータセキュリティと整合性を保証するには不十分になっています。それらのサイトは、安全でない外部 IP ネットワークによって接続されており、個別のファブリックを相互接続しているからです。Nexus Dashboard Orchestrator リリース 2.0(1) は、トラフィックのサイト間暗号化を提供するために設計された CloudSec 暗号化を導入しています。

Multi-Site トポロジはサイト間の接続を提供するために、3 つのトンネル エンドポイント (TEP) IP アドレス（Overlay Multicast TEP、Overlay Unicast TEP、および External TEP Pool）を使用します。これらの TEP アドレスは、 Nexus Dashboard Orchestrator の管理者により設定され、各サイトの Cisco APIC にプッシュ ダウンされ、その後スパイン スイッチで設定されます。これらの 3 つのアドレスは、トラフィックがリモートサイトに送信されるタイミングを決定するために使用されます。この場合、2 つのスパイン スイッチ間に暗号化された CloudSec トンネルが作成され、サイト間ネットワーク (ISN) を介して 2 つのサイト間の物理接続が提供されます。

次の図は、ローカル サイト トラフィックの MACsec とサイト間トラフィックの暗号化に CloudSec を組み合わせた全体的な暗号化アプローチを示しています。

パケット暗号化

次に、CloudSec が発信トラフィック パケットを処理する方法の概要を示します。

• パケットは、外部 IP ヘッダ宛先アドレス フィールドとレイヤ 4 宛先ポート情報を使用してフィルタ処理され、フィルタされたパケットは暗号化の対象としてマークされます。

• 暗号化に使用するオフセットは、パケットのフィールドに基づいて計算されます。たとえば、オフセットは、802.1q VLAN があるかどうか、またはパケットが IPv4 または IPv6 パケットであるかどうかによって異なります。

  オフセットは自動的に決定され、ユーザーには表示されません。

• 暗号キーはハードウェア テーブルでプログラムされ、パケット IP ヘッダーを使用してテーブルから検索されます。

パケットに暗号化のマークが付けられると、暗号キーがロードされ、暗号化を開始するパケットの先頭からのオフセットが判明すると、次の追加の手順が実行されます。

• UDP 宛先ポート番号は、UDP ヘッダーから CloudSec フィールドにコピーされ、パケットが暗号解読されるときにリカバリされます。

• UDP 宛先ポート番号は、CloudSec パケットであることを示すために上書きされます。

  3.7(1) より前のリリースでは、ポートは Cisco 独自のレイヤ 4 ポート番号 9999 で上書きされます。

  IANA が割り当てたポート 8017 を使用するように CloudSec を構成できるリリース 3.7(1) 以降では、使用される宛先ポート番号は、このオプションを有効にしているかどうかに応じて 9999 または 8017 のいずれかです。

• [UDP 長(UDP length)] フィールドは、追加されるバイト数を反映するように更新されます。

• CloudSec ヘッダーは、UDP ヘッダーの後に直接挿入されます。

• 整合性チェック値 (ICV) は、ペイロードと CRC の間のパケットの最後に挿入されます。

• ICV では、128 ビットの初期化ベクトルを構築する必要があります。CloudSec の場合、ICV のために送信元 MAC アドレスを使用すると、SCI ごとのプログラム可能な値に置き換えられます。

• CRC は、パケットのコンテンツの変更を反映するように更新されます。

パケットの暗号解読

CloudSec が受信パケットを処理する方法は、上記で説明した発信パケット アルゴリズムと対称的です。

• 受信したパケットが CloudSec パケットである場合は、暗号解読され、ICV が検証されます。

  ICV 検証に合格すると、追加フィールドが削除され、UDP 宛先ポート番号が CloudSec ヘッダーから UDP ヘッダーに移動され、CRC が更新され、パケットの暗号解読と CloudSec ヘッダーの削除後に宛先に転送されます。そうでない場合、パケットはドロップされます。

• 復号化キーは、受信した CloudSec パケットの外部 IP ヘッダーのソース アドレス フィールド、CloudSec ヘッダーの SCI、および AN 番号フィールドを使用してキー ストアから取得されます。

• パケットが CloudSec パケットでない場合、パケットはそのまま残ります。

初期キー構成

次に、上記の図に示されている CloudSec 暗号キーの初期割り当ておよび配信プロセスの概要を示します。

• アップストリーム サイトの Cisco APIC は、サイトから送信された VXLAN パケットのデータ暗号化に使用されるためのローカル対称キーを生成します。アップストリーム サイトが暗号化に使用するのと同じキーが、ダウンストリーム リモート受信サイトのパケットの復号に使用されます。

  各サイトはほかのサイトに送信するトラフィックのためのアップストリーム サイトです。複数のサイトが存在する場合、各サイトは独自のサイトツーサイトキーを生成し、そのキーを暗号化に使用してからリモートサイトに送信します。

• 生成された対称キーは、ダウンストリーム リモート サイトに配布するために、アップストリーム サイトの Cisco APIC によって Nexus Dashboard Orchestrator (NDO) にプッシュされます。

• NDO はメッセージ ブローカとして機能し、生成された対称キーをアップストリーム サイトの Cisco APIC から収集し、それをダウンストリーム リモート サイトの Cisco APIC に配布します。

  キーは、キー暗号化キー (KEK) を使用して暗号化され、TLS ベースのチャネルを介して配布されます。

• 各ダウンストリーム サイトの Cisco APIC は、受信したキーを、キーを生成したアップストリーム サイトからのトラフィックを受信することを目的としたローカル スパイン スイッチの RX キーとして設定します。

• 各ダウンストリーム サイトの Cisco APIC は、ローカル スパイン スイッチから RX キーの展開ステータスを収集し、NDO にプッシュします。

• NDO は、すべてのダウンストリーム リモート サイトからアップストリーム サイトの Cisco APIC に戻って、主要な展開ステータスを中継します。

• アップストリームサイトはCisco APIC 、すべてのダウンストリーム リモート サイトから受信したキー展開ステータスが成功したかどうかを確認します。

  • ダウンストリーム デバイスから受信した展開ステータスが成功した場合、アップストリーム サイトはスパイン スイッチの TX キーとしてローカル対称キーを展開し、ダウンストリーム サイトに送信される VXLAN パケットの暗号化を有効にします。

  • ダウンストリーム デバイスから受け取った展開ステータスが失敗した場合、失敗した Cisco APIC サイトで障害が発生し、NDO で構成された「セキュア モード」設定に基づいて処理されます。「セキュアが必須 (must secure)」モードでは、パケットはドロップされ、「セキュアであるべき (should secure)」モードでは、パケットは宛先サイトに平文 (暗号化されていない) で送信されます。

    （注）	現在のリリースでは、モードは常に「セキュアであるべき (should secure)」に設定されており、変更できません。

キー再生成プロセス

生成された各 TX / RX キーは、設定された時間が経過すると有効期限が切れます。デフォルトでは、キーの有効期限は 15 分に設定されています。TX/RX キーの初期セットが期限切れになると、キー再生成プロセスが行われます。

キーの再割り当てプロセスには、同じ一般的なキーの割り当てと配布フローが適用されます。キー再生成プロセスは「ブレーク前に作成 (make before break)」ルールに従います。つまり、新しい TX キーがアップストリーム サイトに展開される前に、ダウンストリーム サイトのすべての RX キーが展開されます。これを実現するために、アップストリーム サイトは、ローカル アップストリーム サイトのデバイスに新しい TX キーを構成する前に、ダウンストリーム サイトからの新しい RX キーの展開ステータスを待ちます。

ダウンストリーム サイトが新しい RX キーの展開で障害ステータスを報告した場合、キー再生成プロセスは終了し、古いキーはアクティブなままになります。ダウンストリームサイトは、新しいキーの展開が一定期間終了した後、古い RX キーと新しい RX キーを保持し、いずれかのキーを適切に復号することで、順序どおりでないパケット配信が可能になるようにします。

（注）	スパイン スイッチのメンテナンス中のキー再生成プロセスに関しては、特別な注意が必要です。詳細については、スパイン スイッチ メンテナンス中のキー再生成プロセス を参照してください。

キー再生成プロセスの失敗

ダウンストリーム サイトがキー再生成プロセスによって生成された新しい暗号化キーの展開に失敗した場合、新しいキーは破棄され、アップストリーム デバイスは以前の有効なキーを TX キーとして引き続き使用します。このアプローチにより、アップストリーム サイトは、ダウンストリーム サイトのセットごとに複数の TX キーを維持する必要がなくなります。ただし、このアプローチでは、いずれかのダウンストリーム サイトでキー再生成の展開エラーが発生し続ける場合、キー更新プロセスが遅延する可能性もあります。マルチサイト管理者は、キー再生成を成功させるために、キーの展開の失敗の問題を修正するための行動を取ることが期待されています。

Cisco APICキー管理のロール

Cisco APIC は、キー割り当て (初期キーとキー再配布の両方)、スパイン スイッチからのキー展開ステータス メッセージの収集、および他のサイトへの配布のための各キーのステータスに関する Nexus Dashboard Orchestrator への通知に責任をもちます。

キー管理における Nexus Dashboard Orchestrator の役割

Nexus Dashboard Orchestrator は、アップストリーム サイトから TX キー（初期キーと後続のキーの再生成の両方）を収集し、RX キーとして展開するためにすべてのダウンストリーム サイトに配布します。NDO はまた、ダウンストリーム サイトから RX キーの展開ステータス情報を収集し、成功した RX キー展開ステータスで TX キーを更新するために、アップストリーム サイトに通知します。

アップストリーム モデル

MPLS など、ダウンストリーム キー割り当てを使用する他のテクノロジーとは対照的に、CloudSec のアップストリーム モデルには次の利点があります。

• このモデルはシンプルで、運用とネットワークへの導入が容易です。

• モデルは、マルチサイトのユース ケースに適しています。

• 複数の宛先サイトに送信される複製パケットの各コピーに同じキーと CloudSec ヘッダーを使用できるため、マルチキャスト トラフィックに利点があります。ダウンストリーム モデルでは、各コピーは暗号化中にサイトごとに異なるセキュリティ キーを使用する必要があります。

• 障害が発生した場合のトラブルシューティングが容易になり、複製されたユニキャスト パケットとマルチキャスト パケットの両方に対して、送信元から宛先へのパケットのトレーサビリティが一貫して向上します。