Cisco TrustSec is a system that provides security for Cisco TrustSec-enabled network devices at each routing hop. In this system, each network device works to authenticate and authorize its neighbor devices, and then apply some level of security (group tagging, role-based access control lists (ACLs), encryption, and so on) to traffic between the devices. The Cisco TrustSec-enabled device acts as a border router. Cisco Identity Service Engine (ISE) is the designated domain manager for the Cisco TrustSec device. Cisco ISE is the primary source of group namespace and role-based policy information for Cisco TrustSec devices. Cisco ISE authenticates and authorizes end points into Security Groups (SGs).

Cisco Application Centric Infrastructure (ACI) automates IT tasks and accelerates data center application deployments. It accomplishes this using a business-relevant software defined networking (SDN) policy model across networks, servers, storage, security, and services.

Cisco TrustSec and Application Centric Infrastructure (ACI) networks are similar in semantics of group-based policy framework. Users and resources in both networks are categorized into groups and access is provided across groups. However, Cisco TrustSec and ACI differ in syntax and representation of group identity, and its propagation across the network. For instance, Cisco TrustSec networks use security group tagging, while ACI networks use end-point group (EPG).

Earlier to release Cisco IOS XE Everest 16.5.1 and Cisco ISE 2.2, the interaction between TrustSec and ACI was limited to:

• The creation and exchange of Security Groups from the TrustSec Domain into the ACI Domain.

• The creation and exchange of Endpoint Groups (EPGs) from the ACI Domain into the TrustSec Domain.

In this system, Cisco ISE 2.1 exchanged information with API through REST calls to the Application Policy Infrastructure Controller-Data Center (APIC-DC) API.

Effective with Cisco IOS XE Everest 16.5.1 and Cisco ISE 2.2, the mapping of security group tag with an ACI VNID that is used to represent an EPG is done dynamically. The same is true for traffic sourced from the ACI domain, wherein the VNID is translated into SGT for enforcement in the TrustSec domain. Hence, the TrustSec and ACI integration feature leverages the initial group information exchange to provide a data plane integration, where traffic source from either domain is dynamically translated into the destination domain's policy group structure - that is, source security group tag (SGT) is translated to ACI EPG and vice versa. This exchange allowed these new Security Groups or Endpoint Groups to be used in policies within the respective domains.

Cisco ISE interfaces with ACI Controller, which is also called APIC-DC, to learn EPG names, share SG names and corresponding EPG value, SGT value and VRF Name. This allows Cisco ISE to create and populate SG-EPG translation tables, which are obtained by the border device to translate TrustSec-ACI identifiers as traffic passes across the domains.

Cisco TrustSec device communicates with Cisco ISE through a RADIUS server using PAC Provisioning and Environment Data download. Refer to the sections titled "Protected Access Credential (PAC)" and "PAC Provisioning" in this chapter for more information about PAC.

For more information on TrustSec–ACI Policy Plane Integration, refer TrustSec – ACI Policy Plane Integration

TrustSec and ACI domain intersect at the control plane and data plane levels. With Cisco IOS XE Everest 16.5.1, the earlier policy plane integration (available in ISE 2.1) has been further extended and enhanced to include the data plane integration and ISE 2.2.

The ACI TrustSec Integration feature enables interaction between Cisco TrustSec and ACI in the following ways:

• Enable SG-EPG Translations-Enables control plane interactions by acquiring the operational data from the authentication server that maps security groups to endpoint groups and vice versa.Use the cts sg-epg translation command to do this.
• Enable EPG Propagation-Enables the data plane interactions to propagate the translated SG to EPG information from Cisco TrustSec to ACI domain and vice versa. Use the group-based policy command on ACI device to translate the SG to EPG.

A high-level workflow of the interaction is as follows:

1. When the cts sg-epg translation command is configured, Cisco TrustSec device sends an announcement to ISE about its intent of functioning as a border router to ISE through the sg-epg-translation string in the RADIUS Cisco AV pair cts-device-capability. sg-epg-translation is a new string added to the Cisco AV pair. The RADIUS Cisco AV pair is included in each Environment Data Download RADIUS request to ISE.

   Note	If the environment data is downloaded and the command is configured later, an environment data refresh is triggered.

2. ISE responds with the table names to Cisco TrustSec device.
3. Cisco TrustSec device sends a request to download the translation tables.

   Note	The translation tables are not pushed to the data-path unless the SG-EPG translation is enabled on an interface.

4. If SG-EPG translation is enabled on an interface, Cisco TrustSec control plane receives a notification pushing the tables to datapath.
5. The control plane sends a notification to the data-path notifying that the tables are being pushed to data-plane for programming.
6. The data-path initializes and sends an acknowledgment to the control plane to program the tables.
7. If the data-path responds with an affirmative acknowledgment, the control plane pushes the translation tables to data-path. If a negative acknowledgment is received, the control plane updates the local state that programming in data-path has failed.

In addition to the above workflow, the following steps may be required:

1. When SG-EPG translation is disabled on an interface in which the SG-EPG translation was configured earlier, the control plane notifies the data-path to delete the tables. However, the table will be retained in the control plane as long as the global command cts sg-epg translation is configured.
2. In case SG-EPG translation is enabled on an interface but the global command is not configured, the table is not downloaded from ISE. When the global command is configured, the control plane verifies that the command is enabled on one interface and the datapath is programmed accordingly.

This section explains the interactions between the Cisco TrustSec device and ISE in different scenarios.

The following table explains the interactions between the Cisco TrustSec device and ISE on the control plane, based on the configuration status of the cts sg-epg translation command, when ISE is connected to an Application Policy Infrastructure Controller (APIC) device.

The following table explains the interactions between the Cisco TrustSec device and ISE on the control plane, based on configuration status of the cts sg-epg translation command, when ISE is not connected to an APIC device.

The PAC is a unique shared credential used to mutually authenticate client and server. It is associated with a specific client username and a server authority identifier (A-ID). A PAC removes the need for Public Key Infrastructure (PKI) and digital certificates.

Creating a PAC consists of the following steps:

1. Server A-ID maintains a local key (master key) that is only known by the server.

2. When a client, which is referred to in this context as an initiator identity (I-ID), requests a PAC from the server, the server generates a randomly unique PAC key and PAC-Opaque field for this client.

3. The PAC-Opaque field contains the randomly generated PAC key along with other information such as an I-ID and key lifetime.

4. PAC Key, I-ID, and Lifetime in the PAC-Opaque field are encrypted with the master key.

5. A PAC-Info field that contains the A-ID is created.

6. The PAC is distributed or imported to the client automatically.

Note	The server does not maintain the PAC or the PAC key, enabling the EAP-FAST server to be stateless.

The figure below describes the PAC's construction. A PAC consists of the PAC-Opaque, PAC Key, and PAC-Info fields. The PAC-Info field contains the A-ID.

In Secure RADIUS, the PAC key is provisioned into each device during authentication to derive the shared secret. Since the RADIUS ACS does not store the PAC key for each device, the clients must also send an additional RADIUS attribute containing the PAC-Opaque field, which is a variable length field that can only be interpreted by the server to recover the required information and validate the peer’s identity and authentication. For example, the PAC-Opaque field may include the PAC key and the PAC’s peer identity.

The PAC-Opaque field format and contents are specific to the PAC server on which it is issued. The RADIUS server obtains the PAC Key from the PAC-Opaque field and derives the shared secret the same way clients do. Secure RADIUS only modifies the way shared secret is derived and not its usage.

EAP-FAST Phase 0 is used to automatically provision a client with a PAC.

Perform the following steps when deploying devices in an HA setup:

1. Clear the credentials from all the devices which are part of the HA setup.

2. Boot the stack setup and establish the device roles (active, standby, and members).

3. Configure the credentials on the active device. Use the cts credentials id id password password command to configure the credentials.

Note	While adding a new device to an existing stack, ensure that you clear the credentials on the fresh device and then add it to the existing stack setup.

Interconnection between Identity Service Engine (ISE) and ACI is required to exchange SG and EPG mappings and policy elements. To enable this interconnection, the TrustSec-ACI Policy Element Exchange option must be enabled in the Settings tab (Work Centers >> TrustSec >> Settings) in ISE. If this option is not enabled, communication between ISE and ACI will not be possible.

For more information, click the following link:

TrustSec-ACI Integration

To configure a TrustSec device, first configure the control plane and then configure the data-path.

Translation tables are refreshed along the following scenarios:

• The download of SG-EPG tables is tied to Environment Data download. So, the Environment Data refresh timer triggers the refresh of SG-EPG tables too.

• A force refresh of the SG-EPG tables can be done by issuing the Environment Data refresh command cts refresh environment-data.

• A CoA (Change of Authorization) from ISE can also be issued if there are updates to the tables on ISE.