Cisco TrustSec スイッチ コンフィギュレーション ガイド Cisco Catalyst スイッチについて

認証

ここでは、次の内容について説明します。

• 「Cisco TrustSec と認証」

• 「デバイスのアイデンティティ」

• 「デバイスの証明書」

• 「ユーザの証明書」

Cisco TrustSec と認証

ネットワーク デバイス アドミッション コントロール（NDAC）を使用して、Cisco TrustSec は、デバイスがネットワークに参加できるようにする前にデバイスを認証します。NDAC は、拡張認証プロトコル（EAP）方式としての Extensible Authentication Protocol Flexible Authentication via Secure Tunnel（EAP-FAST）とともに、802.1X 認証を使用して、認証を実行します。EAP-FAST カンバセーションによって、チェーンを使用した EAP-FAST トンネル内で他の EAP 方式の交換が可能になります。この方法では、管理者は Microsoft Challenge Handshake Authentication Protocol Version 2（MSCHAPv2）のような従来型のユーザ認証方式を使用しながら、EAP-FAST トンネルが提供するセキュリティも利用できます。EAP-FAST 交換中に、認証サーバは認証サーバとの将来のセキュアな通信に使用される共有キーおよび暗号化されたトークンが含まれる一意の保護されたアクセス クレデンシャル（PAC）を作成し、サプリカントに配信します。図 1-2 に、EAP-FAST トンネルおよび Cisco TrustSec で使用する内部方式を示します。

図 1-2 Cisco TrustSec の認証

ここでは、次の内容について説明します。

• 「EAP-FAST への Cisco TrustSec の機能拡張」

• 「802.1X ロールの選択」

• 「Cisco TrustSec 認証の概要」

EAP-FAST への Cisco TrustSec の機能拡張

Cisco TrustSec に EAP-FAST を実装することにより、次の機能拡張が実現しました。

• オーセンティケータの認証：オーセンティケータと認証サーバの間の共有キーを得るために PAC を使用するようにオーセンティケータに求めることにより、オーセンティケータのアイデンティティをセキュアに判断します。また、この機能により、オーセンティケータが使用できる可能なすべての IP アドレスに関して認証サーバに RADIUS 共有キーを設定する手間が省けます。

• ピアのアイデンティティを各デバイスに通知：認証交換の完了までに、認証サーバはサプリカントとオーセンティケータの両方を識別します。認証サーバは、保護された EAP-FAST 終端で追加の type-length-value（TLV）パラメータを使用して、オーセンティケータのアイデンティティと、そのオーセンティケータが Cisco TrustSec に対応しているかどうかをサプリカントに伝えます。認証サーバはさらに、Access- Accept メッセージの RADIUS 属性を使用して、サプリカントのアイデンティティおよびそのサプリカントが Cisco TrustSec に対応しているかどうかをオーセンティケータに伝えます。各デバイスは、ピアのアイデンティティを認識しているため、認証サーバに追加の RADIUS Access-Requests を送信し、リンクに適用されるポリシーを取得できます。

802.1X ロールの選択

802.1X では、オーセンティケータに認証サーバとの IP 接続が必要です。オーセンティケータは RADIUS over UDP/IP を使用してサプリカントとオーセンティケータの認証交換をリレーする必要があるためです。PC などのエンドポイント装置はネットワークへの接続時にサプリカントとして機能することになります。ただし、2 つのネットワーク デバイス間の Cisco TrustSec 接続の場合、各ネットワーク デバイスの 802.1X ロールが他方のネットワーク デバイスに即座に認識されない場合もあります。

隣接する 2 つのスイッチにオーセンティケータとサプリカントのロールを手動で設定する代わりに、Cisco TrustSec は自動的にロール選択アルゴリズムを実行して、いずれのスイッチがオーセンティケータとして機能し、いずれがサプリカントとして機能するかを決定します。ロール選択アルゴリズムは、RADIUS サーバに IP で到達可能なスイッチにオーセンティケータ ロールを割り当てます。どちらのスイッチもオーセンティケータとサプリカントの両方のステート マシンを起動します。あるスイッチが、ピアに RADIUS サーバへのアクセス権があることを検出すると、そのデバイスは自身のオーセンティケータ ステート マシンを終了し、サプリカントのロールを引き受けます。両方のスイッチが RADIUS サーバにアクセスできる場合、RADIUS サーバから最初に応答を受信したスイッチがオーセンティケータになり、もう 1 つのスイッチがサプリカントになります。

Cisco TrustSec 認証の概要

Cisco TrustSec 認証プロセスが完了するまでに、認証サーバは次の処理を行います。

• サプリカントとオーセンティケータのアイデンティティの検証

• サプリカントがエンドポイント装置の場合はユーザの認証

Cisco TrustSec 認証プロセスの完了時には、オーセンティケータおよびサプリカントの両方が次の情報を取得しています。

• ピアのデバイス ID

• ピアの Cisco TrustSec 機能についての情報

• SAP に使用されるキー

デバイスのアイデンティティ

Cisco TrustSec はデバイスの ID として IP アドレスも MAC アドレスも使用しません。その代わり、各 Cisco TrustSec 対応スイッチに、Cisco TrustSec ドメインで一意に識別できる名前（デバイス ID）を割り当てる必要があります。このデバイス ID は次の操作に使用されます。

• 認証ポリシーの検索

• 認証時におけるデータベース内のパスワードの検索

デバイスの証明書

Cisco TrustSec はパスワードベースのクレデンシャルをサポートしています。Cisco TrustSec はパスワードでサプリカントを認証し、相互認証を提供するために MSCHAPv2 を使用します。

認証サーバはこれらのクレデンシャルを EAP-FAST フェーズ 0（プロビジョニング）の交換（サプリカントで PAC がプロビジョニングされる）中にサプリカントの相互認証に使用します。Cisco TrustSec は PAC の期限が切れるまで、EAP-FAST フェーズ 0 の交換は再実行しません。その後のリンク起動時には、EAP-FAST フェーズ 1 とフェーズ 2 の交換だけを実行します。EAP-FAST フェーズ 1 交換では、認証サーバとサプリカントの相互認証に PAC を使用します。Cisco TrustSec がデバイスのクレデンシャルを使用するのは、PAC プロビジョニング（または再プロビジョニング）段階だけです。

サプリカントが最初に Cisco TrustSec ドメインに加入する際に、認証サーバはサプリカントを認証し、PAC を使用してサプリカントに共有キー、および暗号化されたトークンをプッシュします。認証サーバとサプリカントは、その後の EAP-FAST フェーズ 0 交換の相互認証にこのキーとトークンを使用します。

ユーザの証明書

Cisco TrustSec には、エンドポイント装置の特定タイプのユーザ クレデンシャルは必要ありません。認証サーバでサポートされるユーザ認証方式を任意に選択して、対応するクレデンシャルを使用できます。たとえば、Cisco Secure Access Control System（ACS）バージョン 5.1 は MSCHAPv2、汎用トークン カード（GTC）、または RSA ワンタイム パスワード（OTP）をサポートします。

セキュリティ グループ ベースのアクセス コントロール

ここでは、次の内容について説明します。

• 「セキュリティ グループおよび SGT」

• 「SGACL ポリシー」

• 「入力タギングおよび出力の強制」

• 「送信元セキュリティ グループの判断」

• 「宛先セキュリティ グループの判断」

• 「ルーテッドおよびスイッチド トラフィックでの SGACL の強制」

セキュリティ グループおよび SGT

セキュリティ グループは、アクセス コントロール ポリシーを共有するユーザ、エンドポイント デバイス、およびリソースのグループです。セキュリティ グループは Cisco ISE または Cisco Secure ACS の管理者が定義します。新しいユーザおよびデバイスが Cisco TrustSec ドメインに追加されると、認証サーバは、適切なセキュリティ グループにこれらの新しいエンティティを割り当てます。Cisco TrustSec は各スコープが Cisco TrustSec ドメイン内でグローバルに一意の 16 ビットのセキュリティ グループ番号を各セキュリティ グループに割り当てます。スイッチセキュリティ グループの数は認証済みのネットワーク エンティティの数に制限されます。セキュリティ グループ番号を手動で設定する必要はありません。

デバイスが認証されると、Cisco TrustSec はそのデバイスから発信されるすべてのパケットに、デバイスのセキュリティ グループ番号が含まれているセキュリティ グループ タグ（SGT）をタグ付けします。タグ付けされたパケットはネットワークを通じて Cisco TrustSec ヘッダーで SGT を運びます。SGT は全社内の送信元の許可を特定する単一ラベルです。

SGT には、送信元のセキュリティ グループが含まれているため、タグは送信元 SGT と呼ばれることもあります。宛先デバイスは、簡素化のために宛先グループ タグ（DGT）と呼ばれることがあるセキュリティ グループ（宛先 SG）にも割り当てられます。ただし、実際の Cisco TrustSec パケット タグには宛先デバイスのセキュリティ グループ番号は含まれていません。

SGACL ポリシー

セキュリティ グループ アクセス コントロール リスト（SGACL）を使用して、ユーザと宛先リソースのセキュリティ グループの割り当てに基づいて、ユーザが実行できる操作を制御できます。Cisco TrustSec ドメイン内のポリシーの強制は、軸の 1 つが送信元セキュリティ グループ番号、もう 1 つの軸が宛先セキュリティ グループ番号である、許可マトリクスで表示されます。マトリクスの本体の各セルには送信元セキュリティ グループから宛先セキュリティ グループ宛てに送信されるパケットに適用される必要がある許可を指定する SGACL の順序リストを含めることができます。

図 1-3 に、3 つの定義済みのユーザ ロールと 1 つの定義済み宛先リソースを含むシンプルなドメインの Cisco TrustSec 許可マトリクスの例を示します。ユーザの役割に基づいて宛先サーバへのアクセスを 3 つの SGACL ポリシーで制御します。

図 1-3 SGACL ポリシー マトリクスの例

ネットワーク内のユーザおよびデバイスをセキュリティ グループに割り当て、セキュリティ グループ間でアクセス コントロールを適用することで、Cisco TrustSec はネットワーク内のロール ベースのトポロジに依存しないアクセス コントロールを実現します。SGACL は従来の ACL とは異なり、IP アドレスではなくデバイス アイデンティティに基づいてアクセス コントロール ポリシーを定義するため、ネットワーク デバイスはネットワーク全体を移動し、IP アドレスを変更することができます。ロールと許可が同じであれば、ネットワーク トポロジが変更されてもセキュリティ ポリシーには影響しません。ユーザがスイッチに追加されたら、適切なセキュリティ グループにユーザを割り当てるだけで、ユーザはただちにそのグループの許可を受信します。

ロール ベースの許可を使用すると ACL のサイズが大幅に節約され、メンテナンス作業も簡単になります。Cisco TrustSec によって、設定されているアクセス コントロール エントリ（ACE）の数は、指定されている許可の数によって決定されるため、ACE の数は従来の IP ネットワークでよりもずっと小さくなります。Cisco TrustSec での SGACL の使用は、従来の ACL と比較して TCAM リソースをより効率的に使用します。

入力タギングおよび出力の強制

Cisco TrustSec アクセス コントロールは入力タギングおよび出力の強制を使用して実装されます。Cisco TrustSec ドメインへの入力点で、送信元からのトラフィックには送信元エンティティのセキュリティ グループ番号を含む SGT がタグ付けされます。SGT はドメイン全体でトラフィックで伝播されます。Cisco TrustSec ドメインの出力ポイントで、出力デバイスは送信元 SGT および宛先エンティティのセキュリティ グループ番号（宛先 SG、または DGT）を使用して、SGACL ポリシー マトリクスから適用するアクセス ポリシーを決定します。

Cisco TrustSec ドメインでは、図 1-4 のように SGT の割り当てと SGACL の強制が実行されます。

図 1-4 Cisco TrustSec ドメインの SGT と SGACL

ステップ 1 ホスト PC が Web サーバにパケットを送信します。PC と Web サーバは Cisco TrustSec ドメインのメンバではないが、パケットのデータ パスに Cisco TrustSec ドメインが含まれています。

ステップ 2 Cisco TrustSec の入力スイッチは、ホスト PC の認証サーバにより割り当てられたセキュリティ グループ番号である、セキュリティ グループ番号 3 の SGT を追加するようにパケットを変更します。

ステップ 3 Cisco TrustSec 出力スイッチは、Web サーバの認証サーバによって割り当てられたセキュリティ グループ番号である、送信元グループ 3 と宛先グループ 4 に適用する SGACL ポリシーを適用します。

ステップ 4 SGACL がパケットを転送するように許可している場合は、Cisco TrustSec 出力スイッチは SGT を削除するようにパケットを変更し、Web サーバにパケットを転送します。

送信元セキュリティ グループの判断

Cisco TrustSec ドメインの入力ネットワーク デバイスは、Cisco TrustSec ドメインに転送するときに、パケットに SGT をタグ付けできるように、Cisco TrustSec ドメインに入るパケットの SGT を判断する必要があります。出力のネットワーク デバイスは、SGACL を適用するために、パケットの SGT を判断する必要があります。

ネットワーク デバイスは、次のいずれかの方法でパケットの SGT を判断できます。

• ポリシー取得時に送信元の SGT を取得する：Cisco TrustSec 認証フェーズ後、ネットワーク デバイスは、ピア デバイスが信頼できるかどうかを示すポリシー情報を、認証サーバから取得します。ピア デバイスが信頼できない場合、認証サーバはそのピア デバイスから着信するすべてのパケットに適用する SGT も提供します。

• パケットの送信元 SGT を取得する：パケットが信頼できるピア デバイスから送信される場合、パケットは、SGT を伝送します。これは、そのパケットにとって、そのネットワーク デバイスが Cisco TrustSec ドメイン内の最初のネットワーク デバイスではない場合に適用されます。

• 送信元アイデンティティに基づいて送信元 SGT を検索する：アイデンティティ ポート マッピング（IPM）を使用すると、接続されているピア アイデンティティのリンクを手動で設定できます。ネットワーク デバイスは、SGT および信頼状態を含むポリシー情報を認証サーバに要求します。

• 送信元 IP アドレスに基づいて送信元 SGT を検索する：場合によっては、送信元 IP アドレスに基づいてパケットの SGT を判断するようにパケットを手動で設定できます。SGT 交換プロトコル（SXP）も、IP-address-to-SGT マッピング テーブルに値を格納できます。

宛先セキュリティ グループの判断

Cisco TrustSec ドメインの出力のネットワーク デバイスは、SGACL を適用する宛先グループ（DGT）を決定します。ネットワーク デバイスは、パケットの送信元セキュリティ グループを決定するために使用されるのと同じ方法（パケットのタグからのグループ番号の取得を除く）を使用して宛先セキュリティ グループを決定します。宛先セキュリティ グループ番号はパケットのタグに含まれません。

場合によっては、入口のデバイスまたは出口以外のその他のデバイスが、使用できる宛先グループの情報を持っていることもあります。このような場合、SGACL は出力デバイスではなくこれらのデバイスに適用されます。

ルーテッドおよびスイッチド トラフィックでの SGACL の強制

SGACL の強制は IP トラフィックだけに適用されますが、強制はルーティングまたはスイッチングされるトラフィックに適用できます。

ルーティングされたトラフィックについては、SGACL の強制は出力スイッチ、通常分散スイッチや、ルーテッド ポートが宛先ホストに接続するアクセス スイッチによって実行されます。SGACL の実行をグローバルにイネーブルにすると、強制は SVI インターフェイスを除く各レイヤ 3 インターフェイスで自動的にイネーブルになります。

スイッチングされるトラフィックの場合は、SGACL の強制はルーティング機能のない単一スイッチング ドメイン内のトラフィック フローで実行されます。2 台の直接接続されたサーバ間のサーバ間トラフィックのデータセンター アクセス スイッチ上で実行された SGACL の強制が、その例です。この例では、通常、サーバ間のトラフィックはスイッチングされます。SGACL の強制は、VLAN 内でスイッチングされるパケットまたは VLAN に関連付けられた SVI に転送されるパケットに適用できます。ただし実行は VLAN ごとに明示的にイネーブルにする必要があります。

許可とポリシーの取得

デバイス認証が終了すると、サプリカントとオーセンティケータの両方が認証サーバからセキュリティ ポリシーを取得します。2 つのピアは、リンク認可を実行し、Cisco TrustSec デバイス ID に基づいてリンク セキュリティ ポリシーを相互に適用します。リンクの認証方式は、802.1X または手動認証に設定できます。リンクのセキュリティが 802.1X である場合、各ピアは認証サーバから受信したデバイス ID を使用します。リンクのセキュリティが手動の場合、ピア デバイス ID を割り当てる必要があります。

認証サーバは次の属性を返します。

• Cisco TrustSec の信頼状態：パケットに SGT を付けるにあたり、ピア デバイスが信用できるかどうかを示します。

• ピア SGT：ピアが属しているセキュリティ グループを示します。ピアが信頼できない場合は、ピアから受信したすべてのパケットにこの SGT がタグ付けされます。SGACL がピアの SGT に関連付けられているかどうかデバイスが認識できない場合、デバイスは認証サーバに追加要求を送信して SGACL をダウンロードする場合もあります。

• 許可期限：ポリシーの期限が切れるまでの秒数を示します。Cisco TrustSec デバイスはポリシーと許可を期限が切れる前にリフレッシュする必要があります。デバイスはデータの有効期限が切れていなければ認証およびポリシー データをキャッシュし、リブート後に再利用できます。Cisco IOS Release 12.2(33)SXI では、ポリシー データおよび環境データだけがキャッシュされます。

ヒント Cisco TrustSec デバイスは、認証サーバからピアの適切なポリシーを取得できない場合に備えて、最小限のデフォルト アクセス ポリシーをサポートする必要があります。

図 1-5 に、NDAC および SAP ネゴシエーション プロセスを示します。

図 1-5 NDAC および SAP ネゴシエーション

環境データのダウンロード

Cisco TrustSec 環境データは、Cisco TrustSec ノードとしてのデバイスの機能を支援するひとまとまりの情報またはポリシーです。デバイスは、Cisco TrustSec ドメインに最初に加入する際に、認証サーバから環境データを取得しますが、一部のデータをデバイスに手動で設定することもできます。たとえば、Cisco TrustSec のシード デバイスには認証サーバの情報を設定する必要がありますが、この情報は、デバイスが認証サーバから取得するサーバ リストを使用して、後から追加することができます。

デバイスは、期限前に Cisco TrustSec 環境データをリフレッシュする必要があります。また、このデータの有効期限が切れていなければ、環境データをキャッシュし、リブート後に再利用することもできます。

デバイスは RADIUS を使用して、認証サーバから次の環境データを取得します。

• サーバ リスト：クライアントがその後の RADIUS 要求に使用できるサーバのリスト（認証および許可の両方）

• デバイス SG：そのデバイス自体が属しているセキュリティ グループ

• 有効期間：Cisco TrustSec デバイスが環境データをリフレッシュする頻度を左右する期間

RADIUS リレー機能

802.1X 認証プロセスで Cisco TrustSec オーセンティケータのロールを引き受けるスイッチは、認証サーバへの IP 接続を通じて、UDP/IP での RADIUS メッセージの交換により、スイッチが認証サーバからポリシーと許可を取得できるようにします。サプリカント デバイスは認証サーバとの IP 接続がなくてもかまいません。サプリカントに認証サーバとの IP 接続がない場合、Cisco TrustSec はオーセンティケータをサプリカントの RADIUS リレーとして機能させることができます。

サプリカントは、RADIUS サーバの IP アドレスと UDP ポートを持つオーセンティケータに特別な EAPOL メッセージを送信し、RADIUS 要求を完了します。オーセンティケータは、受信した EAPOL メッセージから RADIUS 要求を抽出し、これを UDP/IP を通じて認証サーバに送信します。認証サーバから RADIUS 応答が返ると、オーセンティケータはメッセージを EAPOL フレームにカプセル化して、サプリカントに転送します。

リンク セキュリティ

リンクの両側で 802.1AE Media Access Control Security（MACsec）をサポートしている場合、セキュリティ アソシエーション プロトコル（SAP）ネゴシエーションが実行されます。サプリカントとオーセンティケータの間で EAPOL-Key が交換され、暗号スイートのネゴシエーション、セキュリティ パラメータの交換、およびキーの管理が実行されます。これら 3 つの作業が正常に完了すると、Security Association（SA; セキュリティ アソシエーション）が確立します。

ソフトウェア バージョン、暗号ライセンス、およびリンク ハードウェア サポートに応じて、SAP ネゴシエーションは次の動作モードの 1 つを使用できます。

• Galois/Counter Mode（GCM）：認証および暗号化ありを指定します

• GCM 認証（GMAC）：認証あり、暗号化なしを指定します

• カプセル化なし：カプセル化なし（クリア テキスト）を指定します

• ヌル：カプセル化あり、認証なし、暗号化なしを指定します

カプセル化なしを除くすべてのモードで、Cisco TrustSec 対応のハードウェアが必要です。

Cisco IOS Release 12.2(50)SY 以降のリリースの Cisco Catalyst 6500 シリーズ スイッチについては、Cisco TrustSec は、IEEE 802.1AE 標準に準拠した AES-128 GCM および GMAC を使用します。

SXP によるレガシー アクセス ネットワークへの SGT の伝播

パケットへの SGT のタグ付けには、ハードウェアによるサポートが必要です。Cisco TrustSec 認証に参加する機能があっても、パケットに SGT をタグ付けするハードウェア機能がないデバイスがネットワークにある場合があります。SGT 交換プロトコル（SXP）を使用して、これらのデバイスは、Cisco TrustSec 対応のハードウェアを搭載している Cisco TrustSec ピア デバイスに IP アドレスと SGT のマッピングを渡すことができます。

通常、SXP は Cisco TrustSec ドメイン エッジの入力アクセス レイヤ デバイスと Cisco TrustSec ドメイン内のディストリビューション レイヤ デバイス間で動作します。アクセス レイヤ デバイスは入力パケットの適切な SGT を判断するために、外部送信元デバイスの Cisco TrustSec 認証を実行します。アクセス レイヤ デバイスは IP デバイス トラッキングおよび（任意で）DHCP スヌーピングを使用して送信元デバイスの IP アドレスを学習し、その後 SXP を使用して送信元デバイスの IP アドレスおよび SGT を、ディストリビューション スイッチに渡します。Cisco TrustSec 対応のハードウェアを備えたディストリビューション スイッチはこの IP と SGT のマッピング情報を使用してパケットに適切にタグを付け、SGACL ポリシーを強制します（図 1-6を参照）。

図 1-6 SXP プロトコルによる SGT 情報の伝播

Cisco TrustSec ハードウェア サポート対象外のピアと Cisco TrustSec ハードウェア サポート対象のピア間の SXP 接続は、手動で設定する必要があります。SXP 接続を設定する場合は、次の作業を実行する必要があります。

• SXP データの整合性と認証が必要になる場合は、ピア デバイスの両方に同じ SXP パスワードを設定する必要があります。SXP パスワードは各ピア接続に対して明示的に指定することも、デバイスに対してグローバルに設定することもできます。SXP パスワードは必須ではありませんが、使用することを推奨します。

• 各ピアを SXP 接続に SXP スピーカーまたは SXP リスナーとして設定する必要があります。スピーカー デバイスはリスナー デバイスに IP-to-SGT 情報を渡します。

• 送信元 IP アドレスを指定して各ピアの関係付けに使用したり、特定の送信元 IP アドレスを設定していないピア接続に対してデフォルトの送信元 IP アドレスを設定したりすることができます。送信元 IP アドレスを指定しない場合、デバイスはピアへの接続のインターフェイスの IP アドレスを使用します。

SXP は複数のホップを許可します。つまり、Cisco TrustSec ハードウェア サポート対象外デバイスのピアが Cisco TrustSec ハードウェア サポートの対象外でもある場合、2 番目のピアはハードウェア対応ピアに到達するまで IP と SGT のマッピング情報の伝播を継続して、3 番目のピアへの SXP 接続を設定できます。デバイスは 1 つの SXP 接続では SXP リスナーとして、別の SXP 接続では SXP スピーカーとして設定できます。

Cisco TrustSec デバイスは TCP キープアライブ メカニズムを使用して、SXP ピアとの接続を維持します。ピア接続を確立または回復するために、デバイスは設定可能な再試行期間を使用して接続が成功するか、接続が設定から削除されるまで接続の確立を繰り返し試行します。

非 TrustSec 領域のスパニングのためのレイヤ 3 SGT トランスポート

パケットが非 TrustSec を宛先として Cisco TrustSec ドメインを離れると、出力 Cisco TrustSec デバイスは外部ネットワークにパケットを転送する前に Cisco TrustSec ヘッダーおよび SGT を削除します。ただし、図 1-7 に示すように、パケットが別の Cisco TrustSec ドメインへのパス上にある非 TrustSec ドメインを通過するだけの場合、Cisco TrustSec レイヤ 3 SGT トランスポート機能を使用して SGT を維持できます。この機能では、出力 Cisco TrustSec デバイスは、SGT のコピーを含む ESP ヘッダーを使用してパケットをカプセル化します。カプセル化されたパケットが次の Cisco TrustSec ドメインに到達すると、入力 Cisco TrustSec デバイスは ESP カプセル化を解除して、SGT のパケットを伝播します。

図 1-7 非 TrustSec ドメインのスパニング

Cisco TrustSec レイヤ 3 SGT トランスポートをサポートするために、Cisco TrustSec 入力または出力レイヤ 3 ゲートウェイとして機能するすべてのデバイスは、リモート Cisco TrustSec ドメインの適格なサブネットと、それらの領域内の除外されたサブネットを一覧表示するトラフィック ポリシー データベースを維持する必要があります。Cisco Secure ACS から自動的にダウンロードできない場合、デバイスごとにこのデータベースを手動で設定できます。

デバイスは 1 つのポートからレイヤ 3 SGT トランスポート データを送信し、別のポートでレイヤ 3 SGT トランスポート データを受信できますが、入力および出力ポートの両方が Cisco TrustSec 対応のハードウェアであることが必要です。

（注） Cisco TrustSec はレイヤ 3 SGT トランスポートのカプセル化パケットを暗号化しません。非 TrustSec ドメインを通過するパケットを保護するために、IPsec などの他の保護方式を設定できます。

Cisco TrustSec 非対応スイッチング モジュールの Cisco TrustSec リフレクタ

Cisco TrustSec ドメインの Catalyst 6500 シリーズ スイッチ には、次のいずれかのタイプのスイッチング モジュールが含まれている場合があります。

• Cisco TrustSec 対応：ハードウェアは SGT の挿入および伝播をサポートします。

• Cisco TrustSec-Aware：ハードウェアは SGT の挿入および伝播をサポートしませんが、ハードウェアはパケットの送信元および宛先 SGT を特定するために検索を実行できます。

• Cisco TrustSec 非対応：ハードウェアは SGT の挿入および伝播をサポートせず、ハードウェア検索で SGT を特定することもできません 。

スイッチに Cisco TrustSec 対応のスーパーバイザ エンジンが含まれる場合は、同じスイッチ内のレガシー Cisco TrustSec 非対応スイッチング モジュールに対応するために、Cisco TrustSec リフレクタ機能を使用できます。Cisco IOS Release 12.2(50)SY 以降のリリースでは、Cisco TrustSec リフレクタは SPAN を使用して Cisco TrustSec 非対応スイッチング モジュールからのトラフィックを、SGT の割り当ておよび挿入のためにスーパーバイザ エンジンにリフレクトします。

2 つの相互に排他的なモード（入力および出力）は、Cisco TrustSec リフレクタでサポートされます。デフォルトはいずれのリフレクタもイネーブルでないピュア モードです。Cisco TrustSec 入力のリフレクタは、ディストリビューション スイッチに対向しているアクセス スイッチで設定され、Cisco TrustSec 出力のリフレクタはディストリビューション スイッチで設定されます。

サポート対象 TrustSec リフレクタのハードウェア

Cisco TrustSec リフレクタ機能の詳細およびサポートされるハードウェアの一覧については、次の URL にある『 Cisco Catalyst 6500 Series with Supervisor Engine 2T: Enabling Cisco TrustSec with Investment Protection 』のマニュアルを参照してください。

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-658388.html

入力のリフレクタ

Cisco TrustSec 入力のリフレクタは、Cisco TrustSec 非対応スイッチング モジュールが Cisco TrustSec ドメインのエッジにあり、Cisco TrustSec 対応のスーパーバイザ エンジンのアップリンク ポートが Cisco TrustSec 対応ディストリビューション スイッチに接続している、アクセス スイッチで実装されます。

Cisco TrustSec 入力のリフレクタの設定を受け入れるには、次の条件を満たす必要があります。

• スーパーバイザ エンジンが Cisco TrustSec 対応でなければなりません。

• Cisco TrustSec 非対応 DFC は、すべて電源がオフにする必要があります。

• Cisco TrustSec 出力のリフレクタはスイッチ上に設定しないでください。

• Cisco TrustSec 入力リフレクタをディセーブルにする前に、Cisco TrustSec 非対応スイッチング モジュールの電力を切る必要があります。

出力のリフレクタ

Cisco TrustSec 出力のリフレクタは Cisco TrustSec 非対応スイッチング モジュールがアクセス スイッチに対向するレイヤ 3 のアップリンクを使用して、ディストリビューション スイッチに実装されます。Cisco TrustSec 出力のリフレクタはレイヤ 3 のアップリンクだけでサポートされ、レイヤ 2 インターフェイス、SVI、サブインターフェイス、またはトンネルではサポートされないので、NAT トラフィックではサポートされません。

Cisco TrustSec 出力のリフレクタの設定を受け入れるには、次の条件を満たす必要があります。

• スーパーバイザ エンジンまたは DFC のスイッチング モジュールが Cisco TrustSec 対応である必要があります。

• Cisco TrustSec は、スーパーバイザ エンジンのアップリンク ポートまたは Cisco TrustSec 対応 DFC スイッチング モジュールの非ルーテッド インターフェイスでイネーブルにしないでください。

• Cisco TrustSec 出力リフレクタをディセーブルにする前に、Cisco TrustSec 非対応スイッチング モジュールの電力を切る必要があります。

• Cisco TrustSec 入力のリフレクタはスイッチ上に設定しないでください。

VRF-Aware SXP

仮想ルーティングおよびフォワーディング（VRF）の SXP の実装は、特定の VRF と SXP 接続をバインドします。Cisco TrustSec をイネーブルにする前に、ネットワーク トポロジがレイヤ 2 またはレイヤ 3 の VPN に対して正しく設定されており、すべての VRF が設定されていることを前提としています。

SXP VRF サポートは、次のようにまとめることができます。

• 1 つの VRF には 1 つの SXP 接続のみをバインドできます。

• 別の VRF が重複する SXP ピアまたは送信元 IP アドレス持つ可能性があります。

• 1 つの VRF で学習（追加または削除）された IP-SGT マッピングは、同じ VRF ドメインでのみ更新できます。SXP 接続は異なる VRF にバインドされたマッピングを更新できません。SXP 接続が VRF で終了しない場合は、その VRF の IP-SGT マッピングは SXP によって更新されません。

• VRF ごとに複数のアドレス ファミリがサポートされています。そのため、VRF ドメインの 1 つの SXP 接続が IPV4 および IPV6 両方の IP-SGT マッピングを転送できます。

• SXP には VRF あたりの接続数および IP-SGT マッピング数の制限はありません。

レイヤ 2 VRF-Aware SXP および VRF の割り当て

VRF からレイヤ 2 VLAN 割り当ては、 cts role-based l2-vrf vrf-name vlan-list グローバル コンフィギュレーション コマンドで指定されます。VLAN は VLAN 上に IP アドレスが設定されたスイッチ仮想インターフェイス（SVI）がない限り、レイヤ 2 VLAN と見なされます。VLAN の SVI に IP アドレスが設定されると、VLAN はレイヤ 3 VLAN になります。

cts role-based l2-vrf コマンドで設定された VRF 割り当ては、VLAN がレイヤ 2 VLAN として維持されている間はアクティブです。VRF の割り当てがアクティブな間に、学習した IP-SGT バインディングも VRF と IP プロトコル バージョンに関連付けられた転送情報ベース（FIB）テーブルに追加されます。VLAN の SVI がアクティブになると、VRF から VLAN への割り当てが非アクティブになり、VLAN で学習されたすべてのバインディングが SVI の VRF に関連付けられた FIB テーブルに移動されます。

VRF から VLAN への割り当ては、割り当てが非アクティブになっても保持されます。SVI が削除された、または SVI の IP アドレスの設定が解除された場合に再アクティブ化されます。再アクティブ化された場合、IP-SGT バインディングは、SVI の FIB に関連付けられた FIB テーブルから、 cts role-based l2-vrf コマンドによって割り当てられた VRF に関連付けられた FIB テーブルに戻されます。