- Preface
- New and Changed Information
- Overview
- Managing User Accounts
- Configuring VSD
- Configuring AAA
- Configuring RADIUS
- Configuring TACACS+
- Configuring SSH
- Configuring Telnet
- Configuring IP ACLs
- Configuring MAC ACLs
- Configuring Port Security
- Configuring DHCP Snooping
- Configuring Dynamic ARP Inspection
- Configuring IP Source Guard
- Disabling the HTTP Server
- Blocking Unknown Unicast Flooding
- Configuring Cisco TrustSec
- Index
Contents
- Configuring Cisco TrustSec
- Information About Cisco TrustSec
- Cisco TrustSec Architecture
- SGACLs and SGTs
- Determining the Source Security Group
- SXP for SGT Propagation on the Cisco Nexus 1000V
- Licensing Requirements for Cisco TrustSec
- Prerequisites for Cisco TrustSec
- Guidelines and Limitations for Cisco TrustSec
- Default Settings
- Configuring Cisco TrustSec
- Enabling the Cisco TrustSec Feature
- Enabling Cisco TrustSec SXP
- Configuring Cisco TrustSec Device Tracking
- Configuring a Default SXP Password
- Configuring a Default SXP Source IPv4 Address
- Configuring Cisco TrustSec SGTs in a Port Profile
- Configuring Cisco TrustSec SXP Peer Connections
- Configuring Static IP-SGT Bindings
- Changing the SXP Retry Period
- Changing the Interface Delete Hold Timer
- Verifying the Cisco TrustSec Configuration
- Feature History for Cisco TrustSec
Configuring Cisco TrustSec
This chapter contains the following sections:
- Information About Cisco TrustSec
- Licensing Requirements for Cisco TrustSec
- Prerequisites for Cisco TrustSec
- Guidelines and Limitations for Cisco TrustSec
- Default Settings
- Configuring Cisco TrustSec
- Verifying the Cisco TrustSec Configuration
- Feature History for Cisco TrustSec
Information About Cisco TrustSec
Cisco TrustSec Architecture
The Cisco TrustSec security architecture enables you to build secure networks by establishing clouds of trusted network devices. Each device in the cloud is authenticated by its neighbors. Communication on the links between devices in the cloud is secured with a combination of encryption, message integrity checks, and data-path replay protection mechanisms.
Cisco TrustSec uses the device and user identification information that is acquired during authentication for classifying or tagging the packets as they enter the network. These packets are tagged on ingress to the Cisco TrustSec network so that they can be identified for the purpose of applying security and other policy criteria along the data path. The tag, also called the security group tag (SGT), allows the network to enforce the access control policy by enabling the endpoint device to act upon the SGT to filter traffic.
 Note | Ingress refers to when a packet enters the first Cisco TrustSec-capable device on its path to the destination and egress refers to when a packet leaves the last Cisco TrustSec-capable device on the path. |
This figure shows an example of a Cisco TrustSec cloud.
The Cisco TrustSec architecture consists of the following major components:
Authentication—Verifies the identity of each device before allowing them to join the Cisco TrustSec network.
Authorization—Decides the level of access to the Cisco TrustSec network resources that is based on the authenticated identity of the device.
Access control—Applies access policies on a per-packet basis using the source tags on each packet.
Secure communication—Provides encryption, integrity, and data-path replay protection for the packets that flow over each link in the Cisco TrustSec network.
SGACLs and SGTs
In security group access lists (SGACLs), you can control the operations that users can perform based on assigned security groups. The grouping of permissions into a role simplifies the management of the security policy. As you add users to the Cisco NX-OS device, you assign one or more security groups and they immediately receive the appropriate permissions. You can modify security groups to introduce new privileges or restrict current permissions.
Cisco TrustSec assigns a unique 16-bit tag, called the security group tag (SGT), to a security group. The number of SGTs in the Cisco NX-OS device is limited to the number of authenticated network entities. The SGT is a single label that indicates the privileges of the source within the entire enterprise. Its scope is global within a Cisco TrustSec network.
The management server derives the SGTs based on the security policy configuration. You do not have to configure them manually.
Once authenticated, Cisco TrustSec tags any packet that originates from a device with the SGT that represents the security group to which the device is assigned. The packet carries this SGT throughout the network within the Cisco TrustSec header. Because this tag represents the group of the source, the tag is referred to as the source SGT. At the egress edge of the network, Cisco TrustSec determines the group that is assigned to the packet destination device and applies the access control policy.
Cisco TrustSec defines access control policies between the security groups. By assigning devices within the network to security groups and applying access control between and within the security groups, Cisco TrustSec achieves access control within the network. The following figure shows an example of an SGACL policy.
This following figure shows how the SGT assignment and the SGACL enforcement operate in a Cisco TrustSec network.
The Cisco NX-OS device defines Cisco TrustSec access control policy for a group of devices as opposed to IP addresses in traditional ACLs. With such a decoupling, the network devices are free to move throughout the network and change IP addresses. Entire network topologies can change. As long as the roles and the permissions remain the same, changes to the network do not change the security policy. Cisco TrustSec greatly reduces size of ACLs and simplifies their maintenance.
In traditional IP networks, the number of access control entries (ACEs) configured is determined as follows:
The number of ACEs = (The number of sources specified) X (The number of destinations specified) X (The number of permissions specified)
Cisco TrustSec uses the following formula:
The number of ACEs = The number of permissions specified
Determining the Source Security Group
A network device at the ingress of the Cisco TrustSec cloud needs to determine the SGT of the packet that enters the Cisco TrustSec cloud so that it can tag the packet with that SGT when it forwards it into the Cisco TrustSec cloud. The egress network device needs to determine the SGT of the packet so that it can apply the SGACLs.
The network device can determine the SGT for a packet in one of the following methods:
-
Obtain the source SGT during policy acquisition—After the Cisco TrustSec authentication phase, a network device acquires a policy from an authentication server. The authentication server indicates whether the peer device is trusted or not. If a peer device is not trusted, the authentication server can also provide an SGT to apply to all packets that come from the peer device.
-
Obtain the source SGT field from the Cisco TrustSec header—If a packet comes from a trusted peer device, the Cisco TrustSec header carries the correct SGT field if the network device is not the first network device in the Cisco TrustSec cloud for the packet.
Look up the source SGT based on the source IP address—In some cases, you can manually configure the policy to decide the SGT of a packet that is based on the source IP address. The SGT Exchange Protocol (SXP) can also populate the IP-address-to-SGT mapping table.
SXP for SGT Propagation on the Cisco Nexus 1000V
You can use SXP to propagate the SGTs across network devices that do not have hardware support for Cisco TrustSec. The SXP protocol is used to propagate the IP addresses of virtual machines and their corresponding SGTs up to the upstream Cisco TrustSec-capable switches. On the egress side, the enforcement of the Role Based Access Control (RBACL) takes place at the egress interface on the Cisco TrustSec-capable distribution switch.
The SXP for SGT propagation involves the following steps:
Setting up SXP connection—You must configure each peer on the SXP connection as either an SXP speaker or an SXP listener. The speaker device distributes the SXP information (IP-SGT mappings) to the listener device. For Cisco TrustSec on the Cisco Nexus 1000V, the Cisco Nexus 1000V is configured as the SXP speaker in all peer connections.
Tracking and obtaining IP-SGT mapping—You must manually assign a SGT to a Virtual Machine. The SGT configurations are assigned to a port profile or to a virtual Ethernet interface. When you bring up a Virtual Machine, the SGT configurations that are assigned to the port profile are associated with the Virtual Machine.
You must configure IP device tracking and DHCP snooping so that the Cisco Nexus 1000V can track the IP addresses that are assigned to the ports. If you configure both IP device tracking and DHCP snooping, the information that is learned through both the sources is used to obtain the IP addresses of all the interfaces.
Communicating IP-SGT mapping through SXP—On the SXP platform, the IP-SGT mapping is stored in the SXP local database and is distributed to SXP listeners through SXP. For any new IP-SGT mappings, the Cisco Nexus 1000V checks the local database for new IP-SGT mappings or duplicates. The changes are then communicated to the upstream SXP listeners through SXP.
Setting up an SXP connection manually requires that you do the following:
- If you require SXP data integrity and authentication, you must configure both the same SXP password on both peer devices. You can configure the SXP password either explicitly for each peer connection or globally for the device. The SXP password is not required.
- You must configure each peer on the SXP connection as either an SXP speaker or an SXP listener. The speaker device distributes the SXP information to the listener device.
- You can specify a source IP address to use for each peer relationship or you can configure a default source IP address for peer connections where you have not configured a specific source IP address.
Licensing Requirements for Cisco TrustSec
The following table shows the licensing requirements for this feature:
| Feature | License Requirement |
|---|---|
Cisco TrustSec |
This feature requires an Advanced License. See the Cisco Nexus 1000V License Configuration Guide for more information on the licensing requirements for Cisco Nexus 1000V. |
Prerequisites for Cisco TrustSec
Guidelines and Limitations for Cisco TrustSec
-
Cisco TrustSec supports IPv4 addressing only.
The Cisco Nexus 1000V Virtual Supervisor Module (VSM) is always configured as the SXP speaker in all peer connections.
To assign an SGT to a Virtual Machine, you must manually configure SGT interactions in the port profile or vEthernet interface. This feature is not supported on a management interface or an Ethernet interface.
A maximum of 2048 IP-SGT mappings can be learned system-wide in the DVS. This total is for both entries learned through DHCP snooping and device tracking of individual VMs by ARP as well as IP traffic inspection.
The IP-SGT mappings can be communicated to up to 64 SXP peer devices.
Default Settings
Parameters |
Default |
|---|---|
Cisco TrustSec |
Disabled |
SXP |
Disabled |
SXP default password |
None |
SXP reconcile period |
120 seconds |
SXP retry period |
60 seconds |
Device Tracking |
Enabled |
Interface delete hold timer |
60 seconds |
Configuring Cisco TrustSec
Enabling the Cisco TrustSec Feature
You must enable the Cisco TrustSec feature on the Cisco Nexus 1000V before you can configure Cisco TrustSec.
This example shows how to enable the Cisco TrustSec feature:
switch# configure terminal switch(config)# feature cts switch(config)# show cts CTS Global Configuration ============================== CTS support : enabled CTS device identity : not configured SGT : 0 CTS caching support : disabled Number of CTS interfaces in DOT1X mode : 0 Manual mode : 0 switch(config)# switch(config)# show feature Feature Name Instance State -------------------- -------- -------- cts 1 enabled dhcp-snooping 1 enabled http-server 1 enabled lacp 1 disabled netflow 1 disabled network-segmentation 1 disabled port-profile-roles 1 disabled private-vlan 1 disabled segmentation 1 disabled sshServer 1 enabled tacacs 1 disabled telnetServer 1 enabled vtracker 1 disabled switch(config)#
Enabling Cisco TrustSec SXP
You can enable the Cisco TrustSec SXP on the Cisco Nexus 1000V.
This example shows how to enable the Cisco TrustSec SXP:
switch# configure terminal switch(config)# cts sxp enable switch(config)# show cts sxp CTS SXP Configuration: SXP enabled SXP default password configured SXP retry timeout:60 SXP reconcile timeout:120 Minimum SXP Version: 1 Maximum SXP Version:1 switch(config)#
Configuring Cisco TrustSec Device Tracking
You can configure device tracking to enable learning of IP address of Virtual Machines by inspecting the Address Resolution Protocol (ARP) and IP traffic on virtual Ethernet ports.
This example shows how to configure Cisco TrustSec device tracking:
switch# configure terminal switch(config)# cts device tracking enabled switch(config)#
Configuring a Default SXP Password
By default, SXP uses no password when setting up connections. You can configure a default SXP password for the Cisco NX-OS device.
| Command or Action | Purpose | |
|---|---|---|
| Step 1 | switch# configure terminal | Enters global configuration mode. |
| Step 2 | switch(config)# cts sxp default password [word | 7] password | Configures the SXP default password using the following options: By default, no SXP password will be used. |
| Step 3 | switch(config)# show cts sxp | (Optional)
Displays the SXP configuration. |
| Step 4 | switch(config)# show running-config cts | (Optional)
Displays the running configuration for Cisco TrustSec. |
| Step 5 | switch(config)# copy running-config startup-config | (Optional) Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration. |
This example shows how to configure the default SXP password:
switch# configure terminal switch(config)# cts sxp default password 7 CiscoPassword switch(config)# cts cts sxp CTS SXP Configuration: SXP enabled SXP default password configured SXP retry timeout:60 SXP reconcile timeout:120 Minimum SXP Version: 1 Maximum SXP Version:1
Configuring a Default SXP Source IPv4 Address
The Cisco NX-OS software uses the default source IPv4 address in all new TCP connections where a source IPv4 address is not specified. There is no effect on existing TCP connections when you configure the default SXP source IPv4 address.
| Command or Action | Purpose | |
|---|---|---|
| Step 1 | switch# configure terminal | Enters global configuration mode. |
| Step 2 | switch(config)# cts sxp default password password | Configures the SXP default password. |
| Step 3 | switch(config)# cts sxp default source-ip src-ip-addr |
Configures the SXP default source IPv4 address. |
| Step 4 | switch(config)# show cts sxp | (Optional)
Displays the SXP configuration. |
| Step 5 | switch(config)# copy running-config startup-config | (Optional) Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration. |
This example shows how to configure the default SXP source IPv4 address:
switch# configure terminal switch# cts sxp default password xyzexy switch(config)# cts sxp default source-ip 10.78.1.73 switch(config)# show cts sxp CTS SXP Configuration: SXP enabled SXP default password configured Default Source IP Address:10.78.1.73 SXP retry timeout:60 SXP reconcile timeout:120 Minimum SXP Version: 1 Maximum SXP Version:1 switch(config)#
Configuring Cisco TrustSec SGTs in a Port Profile
You can configure unique Cisco TrustSec security group tags (SGTs) as part of a port profile configuration or a vEthernet interface. The SGT is then associated with all the Virtual Machines that inherit the port profile.
| Command or Action | Purpose | |
|---|---|---|
| Step 1 | switch# configure terminal | Enters global configuration mode. |
| Step 2 | switch(config)# port-profile name | Enters port profile configuration mode for the named port profile. If the port profile does not already exist, it is created. |
| Step 3 | switch(config-port-prof)# cts sgt tag |
Configures the SGT for packets sent from the device. The tag argument is a local SGT for the device that is a hexadecimal value with the format 0xhhhh. The range is from 1 to 65519. |
| Step 4 | switch(config-port-prof)# show cts sxp sgt-map | (Optional)
Displays the mapping of the IP address to SGT for Cisco TrustSec. |
| Step 5 | switch(config-port-prof)# show running-configuration port-profile name | (Optional)
Displays a port-profile configuration. |
| Step 6 | switch(config)# copy running-config startup-config | (Optional) Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration. |
This example shows how to configure Cisco TrustSec SGT as part of a port profile configuration:
switch# configure terminal switch(config)# port-profile kumar switch(config-port-prof)# cts sgt 6766 switch(config-port-prof)# show cts sxp sgt-map switch(config-port-prof)# show running-config port-profile kumar !Command: show running-config port-profile kumar !Time: Wed Sep 26 22:58:16 2012 version 4.2(1)SV2(1.1) port-profile type vethernet kumar vmware port-group switchport mode access switchport access vlan 353 cts sgt 6766 no shutdown system vlan 353 state enabled switch(config-port-prof)#
This example shows how to configure Cisco TrustSec SGT on a vEthernet interface:
switch# configure terminal switch(config)# port-profile kumar switch(config-port-prof)# capability l3control switch(config-port-prof)# vmware port-group switch(config-port-prof)# switchport mode access switch(config-port-prof)# switchport access vlan 353 switch(config-port-prof)# cts sgt 6766 switch(config-port-prof)# no shutdown switch(config-port-prof)# system vlan 353 switch(config-port-prof)# state enabled switch(config-port-prof)# show running-config interface vethernet 1 !Command: show running-config interface Vethernet1 !Time: Wed Sep 26 22:59:39 2012 version 4.2(1)SV2(1.1) interface Vethernet1 inherit port-profile kumar description VMware VMkernel, vmk1 vmware dvport 65 dvswitch uuid "c1 0c 33 50 36 73 e3 9b-26 5f db 02 b3 79 cc b8" vmware vm mac 0050.5665.7F77 cts sgt 888 switch(config)#
Configuring Cisco TrustSec SXP Peer Connections
You must configure the SXP peer connection on both the speaker and the listener devices. When you are using password protection, make sure to use the same password on both the devices.
Note | If the default SXP source IP address is not configured and you do not specify the SXP source address in the connection, the Cisco NX-OS software derives the SXP source IP address from existing local IP addresses. The SXP source address can be different for each TCP connection that is initiated from the Cisco NX-OS device. |
Note | The Cisco Nexus 1000Vsupports SXP speaker mode only. Therefore, you must configure any SXP peer as a listener. |
| Command or Action | Purpose | |
|---|---|---|
| Step 1 | switch# configure terminal | Enters global configuration mode. |
| Step 2 | switch(config)# [no] cts sxp connection peer peer-ip-address source source-ip-address] password {[default] | [none [required] password} [mode {listener} [vrf {default | management}] | Configures the SXP address connection.
|
| Step 3 | switch(config)# show cts sxp connection | (Optional)
Displays the SXP connections and their status. |
| Step 4 | switch(config)# copy running-config startup-config | (Optional) Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration. |
This example shows how to configure Cisco TrustSec peer connections:
switch# configure terminal switch(config)# cts sxp connection peer 1.2.3.4 password none mode listener vrf management switch(config)# show cts sxp connection
Configuring Static IP-SGT Bindings
You can define a static binding between an IP host address to a security group tag (SGT). The static IP-SGT bindings are configured in a context of a VRF and are applied to the default VRF. The static IP-SGT bindings take precedence over dynamic bindings from sources such as SXP or locally authenticated hosts. A static IP-SGT bindings is exported to SXP peers if it is the only binding that is known for the given host IP address. Because the static IP-SGT bindings are configured in a context of a VRF, the static IP-SGT bindings must be configured in the same VRF in order to be exported to SXP peers.
| Command or Action | Purpose | |
|---|---|---|
| Step 1 | switch# configure terminal | Enters global configuration mode. |
| Step 2 | switch(config)# cts role-based sgt-map ip-address sgt sgt |
Configures the static binding between an IP host address to a security group tag (SGT). |
| Step 3 | switch(config)# vrf context | (Optional)
Specifies the IP-SGT bindings in a VRF context. The default is the default VRF. |
| Step 4 | switch(config)# show cts role-based sgt-map | (Optional)
Displays the mapping of the IP address to SGT for Cisco TrustSec. |
| Step 5 | switch(config)# show cts ipsgt entries | (Optional)
Displays SXP SGT entries. |
| Step 6 | switch(config)# copy running-config startup-config | (Optional) Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration. |
This example shows how to configure static IP-SGT bindings:
switch# configure terminal switch(config)# cts role-based sgt-map 1.1.1.1 100 switch(config)# vrf context management switch(config-vrf)# cts role-based sgt-map 2.2.2.3 200 switch(config-vrf)# exit switch(config)# show cts role-based sgt-map IP ADDRESS SGT VRF/VLAN SGT CONFIGURATION 1.1.1.1 100 vrf:1 CLI Configured 2.2.2.3 200 vrf:2 CLI Configured cinquedia(config)# show cts ipsgt entries Interface SGT IP ADDRESS VRF Learnt -------------- ------ ---------------- ---------- --------- - 100 1.1.1.1 default Cli Configured - 200 2.2.2.3 management Cli Configured switch(config)# show cts ipsgt entries vrf management Interface SGT IP ADDRESS Pushed Learnt -------------- ------ ---------------- ---------- --------- Vethernet1 888 10.10.101.10 Yes DHCP 10.78.1.78 Yes Device Tracking Vethernet2 6766 10.78.1.76 Yes Device Tracking - 545 99.10.10.10 Yes Cli Configured
Changing the SXP Retry Period
The SXP retry period determines how often the Cisco NX-OS software retries an SXP connection. When an SXP connection is not successfully set up, the Cisco NX-OS software makes a new attempt to set up the connection after the SXP retry period timer expires. The default value is 60 seconds (1 minute). Setting the SXP retry period to 0 seconds disables the timer and retries are not attempted.
| Command or Action | Purpose | |
|---|---|---|
| Step 1 | switch# configure terminal | Enters global configuration mode. |
| Step 2 | switch(config)# cts sxp retry-period seconds |
Specifies the SXP retry timer period. The default value is 60 seconds (1 minute). The range is from 0 to 64000. |
| Step 3 | switch(config)# show cts sxp | (Optional)
Displays the SXP configuration. |
| Step 4 | switch(config)# copy running-config startup-config | (Optional) Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration. |
This example shows how to configure the SXP retry period:
switch# configure terminal switch(config)# cts sxp retry-period 60 switch(config)# show cts sxp CTS SXP Configuration: SXP enabled SXP retry timeout:60 SXP reconcile timeout:120 Minimum SXP Version: 1 Maximum SXP Version:1 switch(config)#
Changing the Interface Delete Hold Timer
The interface delete hold timer period determines how long the interface holds on to the IP-SGT mapping once the interface goes to a nonparticipating state. After the timer expires, the IP-SGT mappings are deleted from the interface and the peers.
| Command or Action | Purpose | |
|---|---|---|
| Step 1 | switch# configure terminal | Enters global configuration mode. |
| Step 2 | switch(config)# [no] cts interface delete-hold seconds |
Specifies the delete hold timer period for an interface. The default value is 60 seconds (1 minute). The range is from 0 to 64000. If the timer is set to 0, the IP-SGT mappings are deleted instantly. The no form of this command does not start the timer when the interface goes to a nonparticipating state and the IP-SGT entries are then always held on the interface. |
| Step 3 | switch(config)# show cts interface delete-hold timer | (Optional)
Displays the interface delete hold timer period. |
| Step 4 | switch(config)# copy running-config startup-config | (Optional) Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration. |
This example shows how to configure the interface delete hold timer:
switch# configure terminal switch(config)# cts interface delete-hold 60 switch(config)# show cts interface delete-hold timer 60 switch(config)#
Verifying the Cisco TrustSec Configuration
Use the following commands to verify the configuration:
| Command | Purpose |
|---|---|
show cts |
Displays the global Cisco TrustSec configuration on the Cisco Nexus 1000V. |
show cts sxp |
Displays the Cisco TrustSec SXP configuration. |
show cts device tracking |
Displays the Cisco TrustSec device tracking configuration. |
show cts sxp connection |
Displays Cisco TrustSec SXP connections. |
show cts role-based sgt-map |
Display the mapping of the IP address to SGT for Cisco TrustSec. |
show cts ipsgt entries |
Displays SXP SGT entries. |
show cts interface delete-hold timer |
Displays the Cisco TrustSec interface delete hold timer period. |
show running-configuration cts |
Displays the running configuration information for Cisco TrustSec. |
Feature History for Cisco TrustSec
Feature Name |
Feature Name |
Releases |
|---|---|---|
Cisco TrustSec |
4.2(1)SV2(1.1) |
This feature was introduced. |