Cisco Bring Your Own Device (BYOD) CVD
BYOD Policy Enforcement Using Security Group Access
Downloads: This chapterpdf (PDF - 7.08MB) The complete bookPDF (PDF - 62.3MB) | Feedback

Table of Contents

BYOD Policy Enforcement Using Security Group Access

Security Group Tag Overview

ACL Complexity and Considerations

Security Group Tag

Security Group Access Domain Infrastructure

TrustSec Using 802.1X for Link Encryption

TrustSec in Manual Mode for Link Encryption

Security Group Tag Distribution and Forwarding Mechanisms

User Policies with SGT

SGT Assignment for Data Center Servers

Migrational Considerations for TrustSec Implementation

What’s New in This CVD

Description

Network Topology Diagram

Terminology

Deployment Scenario 1

Deployment Scenario 2

Common Infrastructure for Both Scenarios

Configuring ISE to Support TrustSec

Configuring ISE for Network Access Device Authentication

Configuring Network Access Devices for Authentication at ISE

RADIUS Server Configuration on the CT-5508 Wireless Controller

RADIUS and CTS Configuration of the 5760 Switch

RADIUS and CTS Configuration of the Nexus 7000

RADIUS and CTS Configuration of the Catalyst 6500

RADIUS and CTS Configuration of the 3850 Switch

Configuring Network Devices with a Device SGT

Configuring Static IP/SGT Bindings on Nexus Switches

Configuration for Deployment Scenario 1

Catalyst 6500 Platform Specific Considerations

Configuring Security Group Tag Exchange Protocol (SXP) for Wireless Controllers

Wireless Controller Configuration

Catalyst 6500 SXP Configuration

Configuring Switching Infrastructure to Support TrustSec with 802.1ae MACsec Encryption

TrustSec Link Policy

Catalyst 6500 Commands

Nexus 7000 Commands

Catalyst 3850 Commands

CT-5760 Commands

Policy Enforcement

Device On-boarding, Provisioning, Authentication, and Authorization Policies for TrustSec in ISE

TrustSec Policy Configuration Using the ASA and Security Group Firewall in the Data Center—Deployment Scenario 2

ASA Firewall Configuration

RADIUS Server Configuration on the ASA Firewall

Configuring Security Group Tag Exchange Protocol (SXP) for Wireless Controllers, Catalyst 3850, and ASA

CT-5508 Wireless Controller Configuration

CT-5760 Wireless Controller Configuration

Catalyst 6500 SXP Configuration

3850 SXP Configuration

6500 VSS Distribution Switch

Nexus 7000 SXP Configuration

ASA SXP Configuration

Configuring SG-FW Role-Based Policies at ASA

Device On-boarding, Provisioning, Authentication, and Authorization Policies for TrustSec in ISE

BYOD Policy Enforcement Using Security Group Access

Revised: March 6, 2014

What’s New: In the previous version of the BYOD CVD, TrustSec in the use of security group tags was addressed in a Centralized Unified Wireless Design within a campus, where users attaching to the wireless network based on authentication credentials in the respective authorization were assigned a security group tag.

In this version of the BYOD CVD, the use of security group tags as a means for enforcing policy is expanded to include a Centralized Unified Wireless Design incorporating the Cisco CT 5760 wireless controller as well as in a Converged Access infrastructure using the Cisco Catalyst 3850. In the CUWN design both the CT 5508 and the CT 5760 wireless controllers are used in parallel to terminate wireless devices in the campus. Additionally, policy enforcement for wireless access via the Catalyst 3850 and its integrated controller, when deployed in the campus access layer, is expanded to include the use of security group tags in addition to access control lists used in the previous version of the BYOD CVD.

As in the previous version of the BYOD CVD, this version continues to demonstrate the use of security group tags for policy enforcement in the same two scenarios using both SG ACLs on Nexus and Catalyst switches for the first scenario and the ASA security appliance in conjunction with the Security Group Firewall (SG-FW).

Security Group Tag Overview

The previous version of the BYOD CVD relied primarily on Access Control Lists for policy enforcement to restrict user traffic as appropriate upon successful authentication and authorization. The use of ACLs can become a daunting administrative burden when factoring the number of devices on which they are applied and the continual maintenance required to securely control network access.

This version of the BYOD CVD uses a complimentary technology known as TrustSec and the use of Security Group Tags (SGT). Security Group Tags offer a streamlined and alternative approach to enforcing policy and traffic restrictions with minimal and, in some cases, little or no ACLs at all if TCP/UDP port level granularity is not required.

Security Group Tags are used as an alternative to ACLs for enforcing role-based policies for campus wireless devices where the Cisco Wireless Controllers have been centrally deployed and configured for operation in local mode (wireless traffic locally switched at the controller).

ACL Complexity and Considerations

To date, variations of named ACLs on wireless controllers, static and downloadable ACLs on various routing and switching platforms, as well as FlexACLs for FlexConnect wireless traffic in the branch have been used as a means of enforcing traffic restrictions and policies. In order to configure and deploy these ACLs, a combination of either command line (CLI) access to each device via Telnet/SSH or network management such as Prime Infrastructure have been required and used for statically configured ACLS while the Cisco Identity Services Engine (ISE) has been used to centrally define and push downloadable ACLs (DACL) to switching platforms.

  • Unique ACLs may be required for different locations such as branches or regional facilities, where user permissions may need to be enforced for local resources such as printers, servers, etc.
  • The operational complexity of ACLs may be impacted by changes in business policies.
  • The risk of security breaches increases with potential device misconfigurations.
  • ACL definitions become more complex when policy enforcement is based on IP addresses.
  • Platform capabilities, such as processor memory, scalability, or TCAM resources may be impacted by complex ACLs.

Cisco’s TrustSec provides a scalable and centralized model for policy enforcement by implementing Cisco's Security Group Access architecture and the use of Security Group Tags.

Security Group Tag

Security Group Tags, or SGT as they are known, allow for the abstraction of a host’s IP Address through the arbitrary assignment to a Closed User Group, represented by an arbitrarily defined SGT. These tags are centrally created, managed, and administered by the ISE. The Security Group Tag is a 16-bit value that is transmitted in the Cisco Meta Data field of a Layer 2 Frame as depicted in Figure 23-1.

Figure 23-1 Layer 2 SGT Frame Format

 

The Security Group Tags are defined by an administrator at Cisco ISE and are represented by a user-defined name and a decimal value between 1 and 65,535 where 0 is reserved for “Unknown”. Security Group Tags allow an organization to create policies based on a user's or device's role in the network providing a layer of abstraction in security policies based on a Security Group Tag as opposed to IP Addresses in ACLs.

The SGT is dynamically assigned, or bound, to user/device’s IP Address upon successful AAA Authentication and subsequent Authorization to the network via Cisco ISE. This SGT mapping is communicated to and stored at the Network Access Device (NAD) serving as the Authenticator. On Cisco switches, these mappings may be dynamically created through RADIUS Attribute Value (AV) pairs passed down from ISE; or may optionally be defined at the device for a host’s IP Address, physical port, VLAN, or subnet, depending on the switching platform’s capabilities. In the case of Cisco Unified Wireless Network (CUWN) wireless LAN controllers such as the WiSM2 or CT5508 however, these IP to SGT mappings can only be dynamically created at the controller through the information communicated by ISE. For specific platform capabilities, refer to the appropriate configuration guides found at http://www.cisco.com or in the Cisco TrustSec Switch Configuration Guide at: http://www.cisco.com/en/US/docs/switches/lan/trustsec/configuration/guide/sgacl_config.html#wp1054201 .

For additional information regarding the Security Group Access architecture, refer to the TrustSec Design and Implementation Guide at: http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns744/landing_DesignZone_TrustSec.html .

Security Group Access Domain Infrastructure

There are two methods of configuring the infrastructure to support TrustSec enabling the forwarding and policy enforcement of frames with an embedded Security Group Tag.

  • TrustSec using 802.1X for Link Encryption
  • TrustSec in Manual Mode for Link Encryption

Common to both of these methods is first the ability to employ MACsec (802.1ae) which provides encryption, a message integrity check, and data-path replay protection for links between adjacent network devices thereby protecting the CMD field and the SGT value it contains. Second is configuration for 802.1X authentication between those network devices that will enforce policies based on the SGT and the Cisco Identity Services Engine (ISE) acting as an Authentication Server.

TrustSec Using 802.1X for Link Encryption

The first method for configuring an TrustSec infrastructure makes use of 802.1X to establish a domain of authenticated and trusted network devices. Every networking device in the TrustSec Domain must be authenticated either directly with ISE, or through its neighbor acting as an authenticator on behalf of the Supplicant network device.

The first networking device to join a TrustSec Domain is considered to be the “Seed” Device. When first powered on, it acts as an 802.1X supplicant joining the TrustSec Domain through an EAP-FAST exchange with ISE as the Authentication Server. Upon successful authentication with ISE, the network device will, through the EAP provisioning tunnel, receive a Protected Access Credential (PAC) key and secure token generated by ISE. This key is used for all future RADIUS Exchanges with ISE.

Seed devices are configured with the list of ISE servers against which it can authenticate. It is not necessary to provide this list of AAA servers on every device when 802.1X is used and subsequently, as adjacent networking devices configured for TrustSec come up, the seed device will act as an 802.1X Authenticator to its neighbor as a Supplicant. As such these neighbors are considered to be “non-seed” devices. This process is known as Network Device Admission Control or NDAC. Once the networking devices have authenticated against ISE, a common Pairwise Master Key (PMK) is derived for use by both sides during subsequent mutual authentication and MACsec negotiation with optional encryption for each of the interconnecting interfaces.

Finally each device, using the credentials acquired after successful authentication with ISE, will through Secure RADIUS exchange, acquire SGT definitions and policies to be enforced in the network.

For additional information regarding NDAC and MACsec, please refer to the Cisco TrustSec 3.0 document “Introduction to MACSec and NDAC” which can be found in Design Zone on Cisco.com at: http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns744/landing_DesignZone_TrustSec.html .

TrustSec in Manual Mode for Link Encryption

The second method, depicted in this CVD, does not rely on 802.1X for device link authentication and encryption. To enable link protection without 802.1X, TrustSec manual mode can be configured such that a common Pairwise Master Key (PMK) is manually configured on the respective interfaces for use by both sides during subsequent MACsec negotiation and optional encryption. This is one of the primary differences with TrustSec with 802.1X wherein this key is dynamically derived from the credentials acquired from ISE after successful authentication.

Another distinction between 802.1X mode and manual mode lies in how the concept of a TrustSec domain of trust is established. When using 802.1X for link authentication, the network device credentials are used during the process of bringing the link up and subsequent authentication with the peer interface; this establishing a trust state with the adjacent device. As this 802.1X-based mechanism is unavailable when configuring manual mode, a static policy must be defined establishing a trusted state on both side of a TrustSec enabled link in addition to the manual PMK configuration.

As in the case of TrustSec with 802.1X link authentication, communication on the links between trusted devices in the TrustSec domain can be secured with a combination of encryption, message integrity checks, and data-path replay protection mechanisms through the use of 802.1ae MACsec. This encryption capability allows the SGT value carried in the Cisco Meta Data (CMD) field of the 802.1q Header to be protected. Today, there are two keying mechanisms available for use with 802.1ae based encryption, the first is a Cisco proprietary protocol known as Security Association Protocol or SAP (similar to 802.1X-2010 MKA) and the second, a standards-based mechanism known as MACsec Key Agreement or MKA. Both use Galois Message Authentication Code (GMAC) as a mechanism to provide authentication and 128-bit AES-GCM (Galois/Counter Mode) symmetric encryption, which is capable of line-rate encryption and decryption for both 1 GB and 10 GB Ethernet interfaces, and provides replay attack protection of every frame. Within this CVD, SAP is used as the keying mechanism for all 10GE MACsec links.

SAP, is a key derivation and exchange protocol based on a draft of IEEE 802.11i which performs the following functions:

  • Negotiate cipher suite for data traffic.
  • Derive session keys for data traffic.
  • Exchange SCIs (Secure Channel Identifier) that will be used by data traffic.
  • Ensure that the exchange is being performed with the same devices that participated in authentication.
  • Perform the exchange with an acceptable degree of security (i.e. confidentiality, protection against MiM attacks, message integrity, etc.).

SAP supports the following modes:

  • gcm-encrypt—GMAC authentication, GCM encryption
  • gmac—GMAC, authentication only, no encryption
  • no-encap—No encapsulation, no SGT plain Ethernet
  • null—Encapsulation/SGT present, no authentication, no encryption

When configuring the TrustSec infrastructure to make use of Manual Mode on the links as opposed to 802.1X mode, there is no requirement to configure every network device to support 802.1X-based link authentication. However, the requirement for 802.1X configuration and network device authentication at ISE still exists for those devices that will require SGT definitions and mappings as well as for SGT-based policy enforcement.

In order to authenticate, the network device(s) will require a configuration identifying the AAA servers (ISE) against which they will authenticate. Once a device has successfully authenticated, secure RADIUS using a PAC key and secure token acquired during authentication is used to communicate with ISE to acquire TrustSec environmental data such as the Security Group Name and the numeric value associated with the tag, an optional SGT used by the device to source packets, and SGT/IP mappings that have been created at ISE. Additionally, policies based on SGTs in the form of SGACLs created at ISE are pushed out to those devices capable of enforcing them such as certain Catalyst and Nexus switching platforms.


Note At the time of this writing, the ASA only receives the SG Name and Tag value and does not support dynamic policy download; ACEs containing SGTs must be locally defined on the ASA. The ASA however must store a PAC key/token which is provisioned at the ASA in order to dynamically acquire Security Group Names and Tag values as created within ISE for later use in defining those policies based on SGT. Wireless controller platforms such as the WiSM2 and 5508, although defined at ISE to support 802.1X wireless client authentication, do not download any TrustSec environment data but merely receive SGT mapping information upon successful client authorization to be discussed later.


In the BYOD CVD, this 802.1X configuration for network device authentication will be configured at several locations in the infrastructure to be discussed later:

  • A Catalyst 6500 VSS switch in a Shared Services block where the wireless controllers have been deployed
  • The CT-5760 wireless controller in Shared Services
  • Catalyst 3850 Converged Access switches providing access layer connectivity
  • At two Nexus 7000 Data Center aggregation switches

As discussed later, these will be the locations in the network where policies based on SGTs will be enforced using dynamically acquired SGACLs. Although it is entirely possible to configure every device in the path for 802.1X authentication, it is purely optional as SGACLs are enforced upon egress from the device having a corresponding destination IP Host to SGT mapping matching an SGACL. The devices that are in the path between source and destination will not have this mapping typically and hence this TrustSec environment data will not be applicable or enforceable.

Security Group Tag Distribution and Forwarding Mechanisms

In order to impose or forward a frame with an SGT Value, specialized switching ASICs are required for forwarding on Ethernet Ports. A variety of Cisco switching platforms in the Nexus and Catalyst families support the inline tagging of an SGT value on 10G Ethernet Ports and, to a lesser extent, 1G Ethernet depending on the platform. This SGT inline tagging capability is sometimes referred to as SGToverEthernet or “native tagging”. In this CVD the following network infrastructure supporting SGT imposition and forwarding (native tagging) will be used:

  • Catalyst 6500 with SUP2T and WS-X6904 linecards. 10G interfaces in Shared Services, Core, Campus Distribution.
  • Nexus 7000 with SUP2 and a combination of F2e and M1 linecards. 10G interfaces in the Data Center.
  • Converged Access Catalyst 3850. 10G interfaces in Campus Access.
  • CT-5760 wireless controller. CUWN (centralized) wireless access 10G interfaces.

For specific information regarding platform support for SGT inline tagging, refer to the appropriate product documentation at: http://www.cisco.com or the “TrustSec Switching Configuration Guide” at: http://www.cisco.com/en/US/docs/switches/lan/trustsec/configuration/guide/trustsec.html .

For the network access devices (NAD) capable of SGT native tagging, when a user or device is authenticated and a SGT Value has been forwarded as a RADIUS AV to the NAD, this IP to SGT mapping will be created and stored at the access switch or controller. Frames sourced from that user or device will be tagged upon egress from the switch or controller on a physical port or, in the case of an SVI, internally associated with the packet as it egresses the SVI. In either case, if an SGACL is matched prior to egress from the device or SVI, the action defined in the SGACL will be enforced otherwise the packet with the imposed SGT will be forwarded.


Note SGACLs are always enforced upon egress from a device or SVI and only if the network device has a local mapping for the destination SGT enforced by the SGACL. SGACLs may also be enforced within a VLAN if configure to do so with SGACL enforcement occurring at the destination’s egress port.


In certain Catalyst and Nexus switching products, it is also possible to enable role-based enforcement within a VLAN, where an SGACL may be enforced between devices with different SGT values. Refer to Figure 23-2.

Figure 23-2 SXP Advertisement, SGT Imposition, and SGACL Enforcement

 

Packets that have a Security Group Tag applied can be forwarded throughout an infrastructure as long as those network devices support SGToverEthernet, native tagging, and the link has been configured with the appropriate policy defining whether those tags should be trusted or re-written through the use of the <policy static> command on the TrustSec interface. As a packet arrives at a switch that supports SGToverEthernet for example, the switch will remove and inspect the header to perform forwarding lookups, apply any QOS treatment, and act upon any security ACLs configured there. Providing the intermediate device does not have an IP to SGT mapping that is denied in an SGACL at this device, the packet will be forwarded along with the associated SGT towards the destination where an egress SGACL will be enforced (permit or deny).

For those platforms that do not support the native SGT tagging capabilities, the SGT eXchange Protocol or SXP as it is known was created to advertise IP Address to SGT Binding information. On devices that support SXP only, they are considered to be “SGT-Aware”, the 802.1X authentication and authorization of a user is exactly the same as those devices supporting native tagging. On these devices supporting SXP, the IP to SGT mapping is created and maintained and can be advertised to a device where native tagging is supported. This advertisement or SXP “Peering” as it is known can be created to an adjacent device or one that is multiple Layer 2 or Layer 3 hops away as SXP uses TCP as a communications transport between peered devices. Refer to Figure 23-2.

As untagged packets sourced from a device advertising IP to SGT mappings via SXP arrive at a switch that is capable of native tagging, the source IP Address is identified and either the associated SGT can be added to the packet and forwarded or an applicable SGACL enforced.

In the previous version of this CVD where the CT-5508 was used exclusively as the wireless controller, it was necessary to advertise the IP/SGT mappings to the Catalyst 6500 VSS Shared Services switch with the tag being inserted upon egress from the 6500. In the current CVD, the CT-5760 will be highlighted in addition to the CT-5508 and supports native tagging, so all frames egressing the CT-5760 will carry the appropriate SGT. Figure 23-2 depicts the tag insertion behavior of CT-5508 and CT-5760.

For a detailed explanation of SXP and SGT, see the TrustSec Design and Implementation Guide at: http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns744/landing_DesignZone_TrustSec.html .

User Policies with SGT

When a user/device accesses the network for the first time, whether wired or wireless, as described in the CVD, the network access device (NAD), wireless controller or switch, serves as an 802.1X authenticator to start the authentication process. The AAA server against which the user will be authenticated will be the Cisco Identity Services Engine (ISE). As this is the first time the device has been seen on the network, it will first be provisioned with the proper credentials for access to the network. During this provisioning process, access to the network will be restricted though the use of standard ACLs to those services such as DHCP, DNS, ISE, and the Google PlayStore required for on-boarding the device as specifically defined in the BYOD CVD.

Once a device has been successfully on-boarded and provisioned, the network access device (NAD) once again acts as an 802.1X authenticator to start the device/user authentication process with ISE. During this authentication process, the device/user is identified based on credentials offered such as a Digital Certificate or Active Directory Group membership. In past versions of the BYOD CVD, once authenticated, users or devices would have been authorized and based on a matching policy would have either been granted unrestricted access to the network or perhaps partial access, restrictions enforced by a suitable ACL either downloaded in the case of switches or associated with a statically configured (named) ACL on the networking device. As an alternative to this approach, an SGT can be used and upon identifying the appropriate authorization policy in ISE, the NAD will receive and store the appropriate SGT to be associated with the user or device's IP Address, commonly referred to as an IP to SGT Binding.

Based on these Security Group Tags, role-based policies can be enforced on supporting hardware through the use of Security Group ACLs (SGACLs) on Cisco switching infrastructure, policies defined on Security Group Firewalls (SGFW) such as the ASA, or an SGFW implemented on the IOS Zone-Based Firewall (ZBFW) on Cisco Routers. These policies may be as simple as a permit or deny an SGT statement or may include specific IP Port information in addition to source or destination SGT to identify specific applications or traffic.

It should be apparent, that when an abstraction layer such as the TrustSec architecture and SGTs are used, device and virtualized server mobility is greatly enhanced as the IP Address of the device is no longer a consideration in enforcing policies in the network. This is true as long as the SGT value was dynamically assigned through a port profile when using the Nexus 1000V, by ISE based on authorization policy, or if the mapping was the result of a VLAN, L3 interface, or IP Subnet to SGT Binding with the VLAN, L3 interface, or Subnet duplicated on other devices. Now, as an entity moves in the network either through mobile roaming or server vMotion by virtue of the port profile when using the Nexus 1000V, one need not be concerned with having appropriate address-based ACLs defined on the destination device. The policy can follow them based on the SGT they have been assigned. If however the IP Host Address to SGT mapping were statically defined at a networking device, that mapping is only resident on that device and not shared with other devices in the TrustSec Domain.

Through the use of Security Group Tags, it will be possible to eliminate many of the Downloadable and named ACLs required in previous BYOD CVDs with a ubiquitous set of tags applicable to an entire domain and managed centrally at the ISE.

This CVD uses TrustSec as an alternative to named ACLs for campus wireless (centralized) access. As of Cisco Unified Wireless Networking (CUWN) software release 7.4MR1 and 7.5 for the WiSM2 and CT5508, sixty-four ACLs can be configured, each having sixty-four Access Control Entries or ACEs (permit/deny statements) within an ACL. In most organizations this may not be an issue, however in others, this may be too limited when using ACLs to segment the network based on roles or device types or if the devices are a Corporate or Personal asset. When using ACLs, a Named ACL is created on the wireless controller and as a user is authenticated and authorized, ISE pushes down the name of the ACL to be applied to the user in the RADIUS AV pair returned to the controller. If there are more than sixty-four unique roles, or more likely more than sixty-four Access Control Entries in an ACL, the use of named ACLs will not be possible. For these scenarios, TrustSec offers an extremely scalable alternative where hundreds of roles may be identified for users or devices, thereby eliminating the requirement for the use of specific IP addresses in an ACL.

The policies demonstrated in this CVD cover the use case where North/South (wireless access to data center) policies need to be enforced restricting access to resources in the data center. Although entirely possible, East/West (wireless user to user) policy enforcement using SGT will be considered out of scope for this version of the CVD. East/West traffic enforcement will be included in a future version of the BYOD CVD when wired access with SGT is addressed.

SGT Assignment for Data Center Servers

Unlike campus access through Catalyst Switches and Cisco Wireless Controllers where dynamic SGT mappings are communicated and created through 802.1X and RADIUS exchange, the vast majority of organizations do not implement 802.1X for server connectivity. As such, data center switches such as the Cisco Nexus switches provide only limited support for the use of 802.1X and do not specifically support an SGT RADIUS AV as an option. Although 802.1X support would be available if using Catalyst Switches in the data center, this use case is not covered. Therefore, IP Address to SGT mappings for these resources must be either manually defined as in the case of bare metal servers and non-Cisco virtual switches or within port profiles if the Cisco Nexus 1000V virtual switch is deployed.

For purposes of this CVD, the IP to SGT Bindings have been defined at Nexus 7000 data center aggregation switches, as depicted in Figure 23-3.

Figure 23-3 Server IP to SGT Bindings

 

In addition to the manual creation of an IP Address to SGT mapping either globally, or within a VLAN for enforcement of intra-vlan traffic between hosts belonging to different Security Groups, the Nexus 7000 also supports the following:

  • Assigning an SGT to a port for all data sourced from a host attached to that port.
  • Support for mapping an SGT to a VLAN such that all traffic from hosts within that VLAN will be tagged accordingly.
  • Support for mapping an SGT to an IP Address within a VRF.

The VLAN to SGT mapping feature was first introduced in NX-OS v6.2.2 for the Nexus 7000. The VLAN to SGT mapping feature binds an SGT to packets from a specified VLAN. This simplifies the migration from legacy to TrustSec-capable networks as follows:

  • Supports devices that are not TrustSec-capable but are VLAN-capable, such as legacy switches, wireless controllers, access points, VPNs, etc.
  • Provides backward compatibility for topologies where VLANs and VLAN ACLs segment the network, such as server segmentation in data centers.

When a VLAN is assigned a gateway that is a switched virtual interface (SVI) on a TrustSec-capable switch and IP Device Tracking is enabled on that switch, then TrustSec can create an IP to SGT binding for any active host on that VLAN mapped to the SVI subnet.

IP-SGT bindings for the active VLAN hosts are exported to SXP listeners. The bindings for each mapped VLAN are inserted into the IP-to-SGT table associated with the VRF the VLAN is mapped to by either its SVI or by a cts role-based l2-vrf cts global configuration command.

VLAN to SGT bindings have the lowest priority of all binding methods and are ignored when bindings from other sources are received, such as from SXP or CLI host configurations.


Note For VLAN to SGT mappings, the VLAN MUST have an SVI associated with it in order for the mapping to be created. If an SVI does not exist, the IP Address of the device within the VLAN will not be mapped to an SGT.


The Nexus 5500, as of this version of the CVD, supports port (interface) to SGT mapping as well as manual IP to SGT mapping. For local SGACL enforcement on the Nexus 5500, port to SGT mapping must be used as the intent of IP to SGT mapping is for SXP advertisement.

For the Nexus 1000V, the SGT can be assigned within the port profile definition and subsequently advertised via SXP to a d Nexus 7000 for SGT imposition or SGACL enforcement. The use of the Nexus 1000V is considered out of scope for this release of the BYOD CVD, however additional information can be found in “Segmenting Clients and Servers in the Data Center” at: http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns744/landing_DesignZone_TrustSec.html .


Note The Nexus 5500 family of switches only support SXP speaker mode and not listener mode. As such, it is not is not possible to advertise Nexus 1000V IP/SGT mappings to the 5500, therefore a Nexus 7000 must be used for this purpose.


Finally, it is also possible to define these SGT host mappings within ISE. These mappings are subsequently pushed to all SGT-capable network devices authenticated within the TrustSec Domain. An “SGT-capable device” by definition can impose and forward the SGT as well as enforce an SGACL. The exceptions here are the ASA, as its Security Group policies are not dynamically obtained but locally configured, and devices that are only SGT-Aware (only SXP supported). When defining IP/SGT mappings at ISE one configuration detail must be noted as if not followed every device within the TrustSec Domain would receive every server mapping configured at ISE. When defining “Advanced TrustSec Settings” for network devices within ISE, a small check box for “Include this device when deploying Security Group Tagging Mapping Updates” is by default selected as can be seen in Figure 23-4. When selected, any IP/SGT Mappings defined at ISE will be pushed to that device. Hence if plans call for SGT mappings to be created at ISE, as part of the configuration process discussed in later sections, this box should be unchecked for all those network devices where the static ISE mappings are undesirable.

Figure 23-4 ISE SGT Mapping Update Configuration

 

Within the CVD, all static mappings are created at the Nexus 7000 Aggregation switches closest to the server. In the CVD both IP/SGT mappings as well as VLAN to SGT mapping are defined. Note that VLAN to SGT mapping is currently unavailable for the Nexus 5500.

In implementing TrustSec in a data center several strategies can be used to provide various zones for policy enforcement or means by which servers can be mapped to the appropriate SGT value. It is beyond the scope of this document to discuss these strategies in detail as they will vary from one organization to the next based on server deployment (addressing/physical connectivity), data sensitivity and role-based policies restricting access, Infosec policies, and switching platforms, whether physical or virtualized, that are used.

The first step for implementation of TrustSec within the data center should be the creation of a matrix defining whether access is permitted or denied.

  • One axis should define the various server roles based on application or database and the type of data resident relative to security and role-based access restrictions.
  • The other axis defining the various user/device classifications such as Employee_Corporate, Employee_Personal_PartialAccess, Contractor, etc.

Once completed it will then be possible to examine where servers presently reside in the data center and how best to map the respective IP Addresses to SGT values. Depending on current security practices within the data center, servers may already have been organized in security zones or pods with either firewalls or ACLs already protecting them. Typically this organization will have been represented through VLANs and IPv4 subnets associated with them.

When using the Nexus 7000 for direct server connectivity or as a means of aggregating other virtualized or physical switching infrastructures, the recommended approach for creating IP to SGT bindings would be to map a VLAN to an SGT value. By default then, all server traffic associated with that VLAN will be encapsulated with the defined SGT. If other servers reside in that VLAN with different access restrictions, it is entirely possible to statically map the server’s IP address to a different SGT value within the VLAN, thereby overriding the global VLAN to SGT mapping and enabling enforcement to and from the server not only from hosts external to the VLAN but even between servers within the VLAN.

Migrational Considerations for TrustSec Implementation

As the implementation of TrustSec within the data center will most likely be through a migrational approach, one possible method for implementing TrustSec would be to identify those servers that all user roles have access to and assign them to a security group allowing open access. This might include services such as DNS/DHCP, Active Directory, Cisco Identity Services Engine, etc.

The next group of servers to be associated with an SGT could be those servers accessible to users/devices identified by a specific SGT that have only limited access to these intranet servers, applications, databases, etc. In doing so, the appropriate SGACLs can be established permitting access to these servers. By doing this, it then follows that all remaining servers can be assigned an SGT either through static mapping or assignment to a VLAN which is mapped to the appropriate SGT.

It is strongly recommended that a plan be developed to stage the migration to the use of TrustSec for policy enforcement in an orderly fashion by first assigning all servers an SGT using VLAN to SGT or static IP to SGT mapping prior to enabling the Campus Access. This CVD assumes that all servers have been assigned an SGT prior to enabling TrustSec. Recognizing however that every organization will have different requirements, it may be necessary to begin implementation of TrustSec for policy enforcement within at network access at the same time as data center resources. As previously discussed this will likely be through the use of 802.1X for both wired and wireless access although other methods do exist in Catalyst switching platforms such as VLAN to SGT mapping, Layer 3 Interface to SGT mapping, etc. As part of this migration process, TrustSec should be enabled in the campus and data center aggregation and switching infrastructure prior to enabling the access switches supporting TrustSec.

As areas of the network are migrated to the use of Security Group Tags and propagation of same, the appropriate SGACLs will be defined through creation of TrustSec policies at ISE discussed later in the CVD. It is assumed that during this migration period there will be traffic from users and devices that have not been associated with a tag and as this traffic enters the TrustSec Domain at the campus aggregation or distribution layer switches where TrustSec and SGT propagation is enabled, the Ethernet frames will be encapsulated with a CMD header containing an SGT value of 00 or “unknown”. As this traffic traverses the Catalyst switching infrastructure, it will be propagated over the CTS links as SGT:00 until it enters the first Nexus switch. The Nexus switches behave differently and based on the interface configuration for TrustSec, the Nexus will remark the SGT:00 value to one specified on the ingress interface. This is discussed in much greater detail in TrustSec Link Policy. For purpose of discussion here, the SGT value used for the Nexus links in the CVD will be 80.

In order to ensure access to data center resources, a TrustSec policy permitting access from SGT:80 will be required for server access. As there will be traffic both from employee devices with full access and other restricted traffic with only partial access being remarked to SGT:80 during the migration period, there will obviously be no way to enforce a policy restricting or denying access on a per user basis and so SGT:80 will need access to all servers with specific access restricted by other means, such as ACLs, firewall rules at the edge of the TrustSec Domain, etc.

The task of assigning an SGT to every data center asset will likely prove daunting when first migrating to the use of Security Group Tags. In the scenario where SGACLs will be used to enforce policy, the SGACL is defined by permitting or denying access between a specific source and destination SGT and IP Addresses are not used within these policies. Although the following configuration is not discussed in this CVD, a concept that can be exploited when granting access to servers in the data center is that of the SGT value of zero or “unknown” as it is referred to.

If the IP Address of a server or the VLAN in which it resides has not been mapped to an SGT at the point of enforcement, such as the Nexus 7000 in the data center, that server would be considered unknown and associated with SGT:00. Unlike ACLs with an implicit deny at the end, SGACLs when implemented on a switching platform have an implicit permit to unknown or permit all; this is not true on the ASA or IOS ZBFW acting as a SG-FW where an implicit deny is still maintained. Hence on a switch, if there is not a specific tag value assigned to a server, the destination is considered Unknown (SGT:00) and as long as an SGACL denying a specific source SGT to SGT:00 or unknown, the packet is forwarded.

The use of SGT:00, if used cautiously, provides a possible migrational approach to tag assignment in the data center. By assigning an SGT to all data center resources requiring open access such as DHCP/DNS as well as those servers that can be accessed by users with only restricted access privileges, a SGACL can be created granting server access for those restricted users, while denying access to servers that have yet to be mapped, thus represented by SGT00 or the “unknown” tag.

The following example depicts one possible use of the unknown tag in a BYOD setting where personal or contractor assets are permitted on the network and only partial access to data center resources is permitted through the use of SGACLs on the switching infrastructure. Throughout the campus infrastructure the default policy permitting any SGT to “unknown” is left unaltered. However at the Nexus 7000 Data Center Aggregation switches where policies based on SGACLs are enforced, an explicit SGACL denying access between a specific source SGT to “unknown” (SGT:00) can be created. A policy defining permissions for SGT00 whether as source or destination that is explicitly (manually) configured on a Nexus 7000 will take precedence over the default policy that implicitly permits traffic to or from unknown. The following commands configure the SGACL locally on the Nexus 7000 Data Center Aggregation switches:

cts role-based access-list block12toUnk /Creates an SGACL "block12Unk"
deny ip /Action performed by SGACL "block12Unk"
cts role-based sgt 12 dgt 0 access-list block12toUnk /Manually configure mapping of Cisco TrustSec Security Group Tags (SGTs) to a security group access control list (SGACL). Defines source SGT12 to destination SGT0 (Unknown)
 

To verify the role-based access policy at the Nexus 7000, issue the command sh cts role-based policy. The following is an excerpt of the entire output showing the previously denied SGACL.

ua33-n7k-1-agg# sh cts role-based policy
sgt:10
dgt:unknown rbacl:Permit IP
permit ip
 
sgt:11
dgt:unknown rbacl:Permit IP
permit ip
 
sgt:12
dgt:unknown rbacl:block12toUnk
deny ip
 
sgt:any
dgt:any rbacl:Permit IP
permit ip
 

To carry this example further, users and devices with only partial access to the data center are assigned SGT:12. Within the data center, those servers that SGT12 will have access to are assigned an SGT value 40. Servers that these users should not be able to access have been assigned SGT 50. In doing so we enforce three policies regarding server access for the SGT12 users:

  • Permit SGT12 to SGT40
  • Deny SGT12 to SGT50
  • Deny SGT12 to Unknown

For users or devices that have full access to data center resources and are assigned a different SGT, the default, implicit permit to Unknown is left in place and any other SGT-based restrictions can be enforced as required. An example might be in the case of a web server and its corresponding database where a corporate device can access the web server but only the web server and DB Admins can access the database.

When using an ASA firewall to protect data center resources additional flexibility in policy definition is possible as either a source or destination SGT can be used with a destination or source IP Address in the ACE. This now allows one to create policies where a tag assigned to users/devices with partial access can be granted or denied to specific SGTs and or IP Addresses. When using an SG-FW to enforce policy, an ACE can be defined denying a source SGT access to “Unknown” as well.

Prior to implementation of a Security Group Access architecture, many organizations may have already designed their data centers in such a way as to protect those resources by placing them behind a firewall. Others may simply elect to secure them through the use of access control lists where only specific access has been granted while general access from all other sources is denied. Both approaches are demonstrated within this CVD through two separate scenarios where:

  • Campus Wireless BYOD users and devices have role-based access through the use of Security Group Access Control Lists (SGACLs) in one scenario.
  • The Security Group Firewall (SG-FW) capability found in the ASA in the other scenario.

It should be pointed out that these two approaches, SGACLs and SG-FW, are not mutually exclusive and may be used together.

As previously discussed, it is beyond the scope of this CVD to provide a detailed approach to developing a migration strategy for the implementation of Security Group Tags in the data center as well as providing architectural guidance for building secure, containerized data centers. Due to the diverse ways companies, organizations, educational institutions, and governments have built their networks and data centers and the underlying security architectures to protect them, it is impractical to define the various ways TrustSec could be deployed. The only intent of the examples given above is to suggest ways this may be accomplished. For additional information on these topics, refer to the data center document repository in Design Zone on Cisco.com at: http://www.cisco.com/en/US/netsol/ns743/networking_solutions_program_home.html as well as the TrustSec document repository at: http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns744/landing_DesignZone_TrustSec.html .

What’s New in This CVD

In this Enterprise Mobility BYOD CVD, Security Group Tags are used as a means to enforce role-based access policies for Campus wireless users as in the previous version of this CVD. New to this CVD however is the introduction of the CT-5760 wireless controller as well as the Catalyst 3850 for campus wireless access and the ability to natively tag traffic accessing the network through these devices. Two specific infrastructure deployment scenarios are examined within this CVD. The first use case makes use of TrustSec Policy defined at the Identity Services Engine and the resulting SGACLs being dynamically exchanged with the Catalyst 6500 and 3850 switches, the CT-5760 wireless controller, and the Nexus 7000 infrastructure. The second use case once again makes use of the TrustSec Policy defined at the Identity Services Engine, but policy is enforced through the configuration of Security Group Firewall (SG-FW) policies defined on an ASA providing secure access to data center resources.

The wireless access design using the CT-5508 wireless controller previously validated in the previous CVD will continue to be used to support access to data center resources by wireless devices using the CT-5508 instead of the CT-5760, identical to that demonstrated the previous CVD.

Description

This BYOD CVD only discusses Security Group Access in conjunction with campus wireless access; wired access is completely out of scope. The following new capabilities are validated compared to previous versions of this CVD:

  • SGT assignment and forwarding for wireless devices connecting via the Catalyst 3850 Converged Access switch enabled via Darya IOS-XE release.
  • SGT assignment and forwarding for wireless devices connecting via the CT-5760 wireless controller enabled via Darya IOS-XE release.
  • Nexus 7000 support for VLAN to SGT mapping found in “Freetown” NX-OS 6.2.

The previous BYOD CVD required that Shared Services, Core, Data Center Core, and Data Center Aggregation all be configured to support SGT forwarding using CTS Manual Mode and MACsec link encryption. This BYOD CVD requires the addition of the Catalyst 6500 VSS Distribution Layer to provide connectivity for the Catalyst 3850 Converged Access switches terminating campus wireless devices in the access layer. As with 2.5 the 10Gb Ethernet links configured for Security Group Tag propagation on the Calayst 6500 and 3850 switches will make use of CTS Manual Mode. Although the link between the Catalyst 6500 switches uses MACsec for link encryption, the C3850 10Gb uplink to the distribution C6500 does not utilize MACsec encryption as although the hardware is capable, software support will not be available until a future release of IOS-XE for the Catalyst 3850.

In this CVD as previously discussed, the CT-5760 is added to the design along with the CT-5508 for the centralized CUWN design for the campus. As with the CT-5508, the CT-5760 is connected to the Shared Services Catalyst 6500 VSS switch. The key difference is that the link from the CT-5760 to the 6500 Shared Services is 10G Ethernet supporting SGT forwarding. As with the C3850, this link is configured for CTS Manual Mode without MACsec link encryption for the same reasons. As traffic egressing the CT-5760 can now be tagged appropriately, the requirement for SXP can be eliminated in the SGACL deployment, but is still required for the second model using the ASA and SG-FW in the data center due to lack of tagging support on the ASA. The requirement for SXP when deploying the CT-5508 remains as in the previous CVD and is included in the following sections of this document.

Network Topology Diagram

The BYOD topology is illustrated in Figure 23-5.

Figure 23-5 BYOD Topology Diagram

 

The key items to note in Figure 23-5 include:

  • At a campus location the wireless design can be deployed either by using Centralized Wireless Architecture, which can be implemented by either using 5508 WLC or 5760 WLC, or by using Converged access switches 3850 switches. This design supports combination of both architectures.
  • The core infrastructure at the campus remains the same as the previous CVD design.
  • The Campus Wireless Design depicted in the previous CVD is still relevant in this design. This design shows the additional capabilities of 5760 WLC.

As in the pervious BYOD CVD, two different scenarios are depicted for TrustSec policy enforcement. The next two sections describe the details of each policy enforcement mechanism.

Terminology

There are several terms that that will be used throughout this document:

  • Tagging points—These are different places in the Campus where the traffic is initally tagged. As shown in Figure 23-6, the points with this icon:

 

are the devices that tag the traffic. Within the campus, the 5760 WLC for centralized wireless access design and 3850 for the converged access design are the places where the traffic is initally tagged. Also, as the CT-5508 is unable to tag traffic, mappings that are learned are advertised to the Catalyst 6500 VSS in Shared Services where the traffic is then tagged. Finally within the data center, the Nexus 7000 Aggregation switch is responsible for tagging traffic.

Figure 23-6 shows the points where the tags are initially generated.

Figure 23-6 Points Where Tags are Generated

 

  • SGT capable links—These are the links that receive the frames with SGT on the ingress and impose the tags on the egress. In Figure 23-6, all the links that are marked “Green” are SGT capable links.
  • EAST-WEST Traffic enforcement—This is a term that basically describes that enforcement occuring between access devices/users within the same network at Layer 2 or Layer 3.
  • North-South Traffic—This is the traditional approach for policy enforcement. Servers that have data reside in the data center, which is described as “North” of the devices in the network. Access policies/restrictions from the campus access layer, whether wired or wireless, are typically enforced at security appliances or infrastructure near to or at which the servers are attached. The next two sections discusses two distinct scenarios that will be used to enforce this North-South traffic in this CVD.

Deployment Scenario 1

In the previous version of the CVD, Deployment Scenario 1 focused completely on restricting access to data center resources based on Security Group membership of campus-based wireless devices accessing the network through a CT-5508 wireless controller. This is now expanded to include devices accessing the network through the Catalyst 3850 and CT-5760. The details of how to configure this policy enforcement are shown in the following sections.

Deployment Scenario 1 Components:

  • CT5760; IOS-XE 3.3
  • CT5508; CUWN 7.6
  • Catalyst 6500
  • SUP2-T; 15.1.1-SY1
  • WS-X6904 Linecard with 10GE Modules (FourX Adapter)
  • C3850 Converged Access Switches; IOS-XE 3.3
  • Nexus 7000
  • SUP2; 6.2(6)
  • M1 Linecards; N7K-M108X2-12L
  • F2e Linecard; N7K-F248XP-25E ( only last 8 ports supporting MACsec )
  • Nexus 5548
  • ISE 1.2 with Patch 5 installed

Figure 23-7 depicts the infrastructure that is used for purposes of TrustSec validation in this CVD.

Figure 23-7 TrustSec Infrastructure in this BYOD CVD

 

In Figure 23-7 the links extending between the Catalyst 6500 VSS in Shared Services to the Catalyst 6500 VSS in the core and extending to the Nexus 7000 are 10GE links. On the Catalyst 6500s, WS-X6904 linecards with the FourX Adapters provide the 10GE interfaces while the N7K-M108X2-12L and N7K-F248XP-25E linecards provide the Nexus 7000 interfaces. The links between the Nexus 7000 and the Nexus 5548 are likewise connected to N7K-M108X2-12L linecards at the Nexus 7000 and 10GE ports on the Nexus 5548. All other network connectivity for wireless controllers, ASA firewalls, ISE, and the miscellaneous servers depicted are 1GE links.

Figure 23-8 Infrastructure Deployment Scenario 1 SGT Enforcement

 

In this first scenario, wireless users, upon successful authentication and authorization, will be associated with a specific role and an IP to SGT mapping will be created on the wireless controller with the device’s IP Address and the appropriate SGT. In Deployment Scenario 1, wireless device traffic will have the SGT inserted at different networking devices and this insertion point is dependent on which wireless controller the device is terminating at for network access.

Table 23-1 summarizes where the SGT will be inserted.

 

Table 23-1 SGT Insertion

Architecture
Wireless Controller
Device
Explanation

Converged

3850

3850 switches

3850 Switch support inline tagging capability

Centralized

5760

5760 wireless controller

5760 wireless controller supports inline tagging capability

Centralized

5508

6500 Shared Services

5508 does not support in-line tagging. Therefore SXP is used between 5508 and 6500. Tags imposed at 6500.

In Deployment Scenario 1, CUWN traffic with Security Group Tags will be forwarded from the Shared Services Catalyst 6500 VSS, where the wireless controllers are attached, or from the 3850 converged access switches connected to the Catalyst 6500 Distribution switch. These tags are then propagated through the Core of the BYOD infrastructure en route to servers located in the data center. In Figure 23-8, the links depicted in blue will be configured for SGT forwarding as well as manually configured for 802.1ae MACsec encryption where available.


Note As of IOS-XE 3.3.0, the Catalyst 3850 and CT-5760 wireless controller will impose and propagate the SGT as well as enforce SGACLs. Although these platforms have the necessary ASICs for MACsec support, the software has yet to be enabled as of the writing of this CVD. These links are green dashes


As this traffic traverses the SGT-capable Core, this tag will be propagated hop-by-hop en route to the Nexus 7000s that compose the data center switching infrastructure within which the various servers are located. As shown in the Figure 23-8, a wireless user accessing the network using centralized wireless architecture is assigned a tag value of 12 after successful authentication and authorization; similarly, a wireless user accessing the network using a converged access medium is assigned a tag value of 10.

As 802.1X is not used to authenticate the servers residing in the Nexus data center infrastructure, the server IP Address to SGT mapping can either be manually defined on the Nexus 7000 Data Center Aggregation switch or at the ISE server, which would subsequently “push” that mapping to the Nexus 7000. For purposes of the CVD, specific IP/SGT mappings have been manually defined on the Nexus 7000 data center Aggregation Switches as well as the use of VLAN to SGT mapping.

As tagged user traffic arrives at the Nexus 7000 data center switch where the manual SGT mappings for the servers have been created, the traffic will be matched against TrustSec Policy (SGACL) defined either centrally at ISE or locally and will be either forwarded or dropped as applicable. For example, as shown in Figure 23-8, the traffic with SGT 10 arriving from converged access wireless user with full access is permitted by the Nexus aggregation switch and the traffic with SGT12 from a CUWN wireless user who has partial access is denied access to the servers.

As discussed earlier, all SGT mappings for the servers have been manually created on the Nexus 7000 aggregation switches. As the servers are connected to the Nexus 5548 switches depicted in Figure 23-8, traffic from the Nexus 5548s egresses untagged as no mappings have been created there. Once this traffic passes through the Nexus 7000 Aggregation switch, the resident SGT mappings will be examined and the appropriate SGT imposed upon egress from the aggregation switch. The SGT mappings can be implemented on Nexus 7000 via IP/SGT mapping or by VLAN/SGT mapping. The details for this configuration are covered later in this document. In the event that traffic would be initiated by a server associated with an SGT in the data center, the tagged traffic would then leave the Nexus 7000 data center switches traversing the Catalyst 6500 Core and Shared Service infrastructure enroute to the destination. The SGT is propagated at each hop towards the destination, whether that be the wireless controllers attached to the Shared Services 6500 or wireless devices accessing the network through the Catalyst 3850s.

If destined for CUWN wireless controllers, upon arrival at the Shared Services 6500, the traffic will be matched against local TrustSec Policy (SGACL) and will be either forwarded or dropped depending on the controller to which it is destined. If destined for the CT-5508, SGACL policies will be enforced at the Shared Services C6500 VSS as the CT-5508 does not support tagging or SGACLs and only advertises the IP/SGT mappings to the Shared Services C6500 VSS for enforcement. If destined for the CT-5760 with its support for SGT tagging and SGACLs, the IP/SGT mappings for those devices accessing the network at the CT-5760 will be created and stored at the 5760 and hence the SGACL enforced there as well.

If destined for the Catalyst 3850 and the converged access wireless users, the SGACL policy will be enforced on the Catalyst 3850 to which the wireless user is associated.

Figure 23-9 depicts where SGACLs will be enforced in the Unified Access infrastructure.

Figure 23-9 Policy Enforcement in Deployment Scenario 1

 

Deployment Scenario 2

In this Enterprise Mobility BYOD CVD, Deployment Scenario 2 focuses on the use of ASA firewalls as a Security Group Firewall (SG-FW) separating access between Nexus 7000 Core and Aggregation layers enforcing rules created using a combination of Security Group Tags and IP Addresses as source and destination. These rules can contain ACEs constructed solely with source and destination SGT or combined with an IP address as source or destination. In Deployment Scenario 2 the policy enforcement is executed by firewall rules instead of SGACL s defined in the campus infrastructure or the Nexus Aggregation switches. Additionally, these firewall rules must be configured locally on the ASA as opposed to the creation of switch SGACLs created and pushed from within the Cisco Identity Services Engine.

Wireless Deployment Scenario 2 Components:

  • CT5760; IOS-XE 3.3
  • CT5508; CUWN 7.6
  • Catalyst 6500
  • SUP2-T; 15.1.1-SY1
  • WS-X6904 Linecard with 10GE Modules (FourX Adapter)
  • C3850 Converged Access Switches; IOS-XE 3.3
  • Nexus 7000
  • SUP2; 6.2(6)
  • M1 Linecards; N7K-M108X2-12L
  • F2e Linecards; N7K-F248XP-25E ( only last 8 ports supporting MACsec )
  • Nexus 5548
  • ASA Firewall, 9.0.2
  • ISE 1.2 with Patch 5 installed

In the previous BYOD CVD, the CT-5508 was used for all CUWN termination, whereas in this version of the CVD wireless termination as previously discussed will be expanded to include wireless device termination centrally at the CT-5760 wireless controller and through converged access design using the Catalyst 3850 switch. As the ASA Firewall does not support native SGT tagging, SXP will be once again be used to advertise both campus and data center IP/SGT mappings to the ASA for subsequent policy enforcement to and from data center resources.

It should be noted that although Scenario 1 and Scenario 2 are dissimilar in how Security Group Tags are propagated within the network and policies enforced, these two design scenarios are not mutually exclusive and may be combined. For purposes of this CVD however, Scenario 2 assumes the use of the ASA SG-FW as the sole means of policy enforcement and SXP as the sole means of advertising IP/SGT mappings in lieu of SGT propagation configured on the various infrastructure interfaces.

Figure 23-10 depicts the network topology.

Figure 23-10 TrustSec Deployment Scenario 2

 

The key items to note in Figure 23-10 include:

  • The key differences in Scenario 2 as compared to Scenario 1 are:

Tag information is sent mainly by SXP tunnels and there are no CTS enabled links in the Core part of the network.

ASA, which is the policy enforcer, obtains the information about source and destination tags through a SXP tunnel from a single Nexus data center switch. This is done to prevent ASA from maintaining several different SXP tunnels from different peers.

  • The distribution switch in the campus location initiates a SXP tunnel to the Nexus data center aggregation switch and communicates the information about the tags that it has obtained through SXP peering from the Catalyst 3850 access switches.
  • Shared Services and Distribution Catalyst 6500 VSS switches have SXP tunnels to dual Nexus 7000 aggregation switches and then from those Nexus switches to the ASA.

With Deployment Scenario 2, an alternate means other than SGACLs will be used to enforce TrustSec policy. In Scenario 2 an ASA running version 9.0(2) will be used as a Security Group Firewall (SG-FW) securing data center resources from outside access. Unlike Scenario 1, the 10GE infrastructure between the Shared Services Catalyst 6500 VSS and the data center does not need to be enabled to support Security Group Tag forwarding or SGACLs. As the ASA does not presently support native SGT tagging on its Ethernet interfaces, Security Group Tag Exchange Protocol (SXP) must be used for it to learn IP/SGT mappings from other areas of the network where they have been dynamically learned or statically configured. It is by virtue of these SXP advertisements that the ASA is capable of inspecting the untagged traffic and, through the use of these IP/SGT mappings, that SG-FW policies are enforced.

As in the case of the first deployment scenario, wireless users, upon successful authentication and authorization, will be associated with a specific role and an IP to SGT Binding will be created on the wireless controller with the device’s IP Address and the appropriate SGT.

Once the IP/SGT mappings have been created upon wireless device access to the respective controller, SXP will be used as the primary method through which these mappings are communicated to the ASA firewall. As depicted in Figure 23-10, the 3850 converged access switches, and both the CT-5760 and CT-5508 wireless controllers, must communicate their respective IP/SGT mappings to the ASA Firewall. In this design we have chosen the following method to optimize the number of SXP tunnels needed to the ASA Firewall:

  • The CT-5760 and CT-5508 wireless controllers have an SXP peering to the Shared Services C6500 VSS, which also has an SXP peering to each of the Nexus 7000 data center aggregation switches.
  • Access layer Catalyst 3850 switches establish an SXP tunnel to the C6500 VSS campus distribution switch, which then establishes a tunnel to each of the Nexus 7000 data center aggregation switches. The primary advantage in this approach is to aggregate what may be hundreds of Catalyst 3850s peering at the respective campus distribution switch(es) and then creating a single SXP peering to the data center.
  • All SXP tunnels from the Campus infrastructure are aggregated at each of the Nexus 7000 data center aggregation switches.
  • The IP/SGT mapping information is aggregated and sent by each of the Nexus 7000 aggregation switches to the HA primary ASA Firewall, including all of the server mappings created through static IP/SGT mappings or VLAN/SGT mappings at the Nexus switches. By doing this, the ASA does not have to maintain numerous SXP peerings to different devices.

Table 23-2 summarizes the SXP peering that will be used in the CVD.

 

Table 23-2 SXP Peering

Device
Role
Intfc
Dst Device
Role
Intfc

CT-5760

Speaker

Lo0

Shared Svcs C6500 VSS

Listener

Lo0

CT-5508

Speaker

NA

Shared Svcs C6500 VSS

Listener

Lo0

Shared Svcs C6500 VSS

Speaker

Lo0

N7K-Agg-1

Listener

Lo0

Shared Svcs C6500 VSS

Speaker

Lo0

N7K-Agg-2

Listener

Lo0

Catalyst 3850 Access

Speaker

Lo0

Distribution C6500 VSS

Listener

Lo0

Distribution C6500 VSS

Speaker

Lo0

N7K-Agg-1

Listener

Lo0

Distribution C6500 VSS

Speaker

Lo0

N7K-Agg-2

Listener

Lo0

N7K-Agg-1

Speaker

Lo0

ASA Firewall HA Primary

Listener

Out

N7K-Agg-2

Speaker

Lo0

ASA Firewall HA Primary

Listener

Out

As previously discussed, the ASA firewall that will be used to enforce SG-FW policies must be manually configured with SGT policies as dynamic updates via ISE is presently not supported in the ASA. The details regarding these SG-FW policies are discussed later.

As wireless traffic egresses the Shared Services Catalyst 6500 VSSs en route to the data center, the traffic will be untagged and will simply be propagated through the Core, enter the data center switching infrastructure, and ultimately arrive at the ASA firewall where the appropriate SG-FW policy will be enforced. As shown in Figure 23-11, all traffic going from the user to the server passes through the ASA firewall.

In the unlikely event that any traffic would be sourced from a server in the data center, it would likewise egress the Nexus 7000 aggregation switch untagged and be forwarded to the ASA firewall where any applicable SG-FW policy will be enforced.

Figure 23-11 depicts the infrastructure used in Deployment Scenario 2 and the means by which security group policies will be enforced.

Figure 23-11 Deployment Scenario 2 and Security Group Policy Enforcement

 

Common Infrastructure for Both Scenarios

As explained in the overview section, there are several components that have to be configured to ensure that the appropriate SGT is assigned to the user, the SGT is propagated in the network or an IP/SGT mapping is advertised, and policy is enforced.

The following tasks are common to both of the deployment scenarios depicted in this CVD and hence are discussed prior to addressing the specific tasks required for each of the two deployment scenarios. Regardless of the deployment scenario, these tasks as outlined in the following sub-sections should be completed prior to proceeding to those sections discussing specific deployment scenarios:

1. Configuring ISE to support Security Group Access.

2. Configuring ISE for network access device authentication.

3. Configuring the network devices for integration with ISE.

4. Configuring the network devices with a device SGT.

5. Configuring static IP/SGT and VLAN/SGT mappings on Nexus data center aggregation switches for servers.

Configuring ISE to Support TrustSec

For Cisco ISE to function as a TrustSec server and provide TrustSec services, you must define the following global TrustSec settings. The first step is to define ISE as a TrustSec AAA server as depicted in Figure 23-12.

1. Go to Administration > Network Resources > SGA AAA servers and click Add.

2. Enter the host name of the Identity Services Engine server or Policy Service Node if ISE Roles have been distributed among dedicated servers.

3. Enter the IP Address of the ISE server.

4. Enter the UDP Port number for RADIUS authentication and click Save.

Figure 23-12 ISE TrustSec Server AAA Definition

 

The next step to be completed is to configure TrustSec Server Protected Access Credential (PAC) Time-to-Live settings and SGT reservations.

The tunnel PAC generates a tunnel for the EAP-FAST protocol and is used for Secure RADIUS communications with Network Devices for TrustSec environmental data. A new PAC is generated if the network device re-authenticates for any reason or when the TTL expires.

By default Security Group Tags are dynamically assigned a decimal/hex value in ascending order by ISE. It is possible to change this behavior such that all tags must be manually defined or to reserve a range that can be specifically allocated to users, devices, or servers. In the CVD, all tags will be manually defined as depicted in Figure 23-13.

To complete this step:

1. Access the Identity Services Engine and follow the path Administration > System > Settings > Security Group Access.

2. Configure the Tunnel PAC Time to Live.

3. Configure the Proactive PAC update time if desired. In Figure 23-13, the PAC will be renegotiated after 10% of TTL or nine days.

4. By default the system will automatically assign SGT values. If you wish to reserve a range that can be specifically allocated to users, devices, or servers, select the check box next to “Reserve a range From” and specify the Tag values. In the CVD, all tags will be manually assigned as shown below.

5. Save the settings.

Figure 23-13 TrustSec Servers Settings in ISE

 

The next step is to define Security Group Tag names and associate them with a numerical value at the Identity Services Engine. The SGT names are periodically pushed to the Network Access Device (NAD) through periodic updates or upon that network device’s authentication (NDAC Authentication) with ISE. They may also be manually pushed as well.

To complete this step as depicted in Figure 23-14:

1. Go to Policy > Policy Elements > Results >Security Group Access > Security Groups.

2. Click “Add”.

3. Define the SGT Name and add an optional description.

4. Click the radio button next to “Select value from reserved range”

5. Enter the desired SGT value from the range defined in the previous step.

Figure 23-14 Security Group Creation

 

In this CVD, Table 23-3 shows the SGT Names and corresponding Tag Values used.

 

Table 23-3 SGT Names and Tag Values

SGT Value
SGT Name
Description

5

SGT5_TrustSec_NAD

This is used For TrustSec Network Devices And For Trust State.

10

SGT10_Campus Corp

Corporate device with full access to the network.

11

SGT11_Campus_Pers_Full

Personal device with full access to the network

12

SGT12_Campus_Pers_Partial

Personal device with restricted access to some resources on the network.

40

Servers_Services_OpenAccess

Servers in data center accessible by all devices.

50

Servers_Corporate

Corporate Servers that only Corporate devices or approved personal devices have access to.

80

SGT80_Interface

Reserved for us with the <policy static trusted> command on TrustSec-capable interfaces.

0

Unknown

System defined/reserved representing a device (IP Address) not associated with a SGT.

These values will be defined in ISE as can be seen in Figure 23-15.

Figure 23-15 Security Groups Used in CVD

 

Configuring ISE for Network Access Device Authentication

The next configuration task is to define the Network Devices that will be enforcing TrustSec Egress Policies in ISE and create the necessary AAA configuration on the devices. This is done to create a secure tunnel for EAP-FAST authentication of the device such that TrustSec environment data such as SG Names and associated SGT as well as TrustSec Egress Policies or SGACLs can be exchanged periodically. As discussed in TrustSec Using 802.1X for Link Encryption, this process is known as Network Device Admission Control or NDAC. As 802.1X will not be used to authenticate network devices across a link in order to build a trust relationship for SGT forwarding as well as MACsec encryption, it is only necessary to define those devices enforcing SGT policy, as well as those wireless controllers serving as an 802.1X Authenticator to Supplicants on wireless devices attempting to Access the network. Therefore to support Deployment Scenario 1 it will be necessary to create definitions for minimally six devices and Deployment Scenario 2 will require a seventh device, the ASA Firewall HA Primary, based on the infrastructure depicted in Figure 23-16.

Figure 23-16 Network Devices to be Defined in ISE

 

Refering to Figure 23-16, these devices are:

1. CT5760 Wireless Controller (required for 802.1X wireless device access and TrustSec policy enforcement)

2. CT5508 Wireless LAN Controller (required for 802.1X wireless device access)

3. Catalyst 6500 VSS Shared Services Switch (TrustSec policy enforcement)

4. Data Center Nexus 7000 Aggregation Switch #1 (TrustSec policy enforcement)

5. Data Center Nexus 7000 Aggregation Switch #2 (TrustSec policy enforcement)

6. Cat 3850 switch at Campus ( required for 802.1x wireless device access and TrustSec policy enforcement)

7. ASA Firewall HA Primary (TrustSec environment data, specifically security group names)

As SGACLs will not be enforced at the data center Nexus 7000 Core switches nor the Catalyst 6500 VSS Core in Scenario 1 and as this core infrastructure provides simple transport services in Scenario 2, it is not mandatory for these devices to be added to the Network Device List in ISE; the network device does not need to be defined in ISE to simply forward packets with an embedded SGT. It is however recommended to define these devices to accommodate future network changes or enforcement policies as well as define a device SGT to be used by traffic sourced by these switches. The following steps must be taken to define the network devices within ISE as depicted in Figure 23-17:

1. At ISE go to Administration > Network Resources > Network Devices and click Add.

2. Enter the hostname of the device. This will be the same name as configured at the network device and documented later with the cts credential command on switches and would be the wireless controller name.

3. Enter the IP Address of the network device. This must be the address used to source all RADIUS communications from the device.

4. Change the Network Device Location or Device Type if a custom location/type has been previously defined. Within the CVD the Shared Services, Core, and Data Center switches all make use of the default setting as seen in Figure 23-17. The exceptions to this are the wireless controllers and converged access switches. For the controllers we have specified a custom “Device Type” known as “Campus_Controller:SGT_Enabled” and for converged access C3850 switches, “Converged:SGT_Enabled”. This custom location is configured under “Network Device Groups” as depicted in Figure 23-18. The significance of the use of a custom device type lies in the ability to use that as an attribute within the Authorization Profile at ISE to determine a result. In this CVD we use the “device type” “Campus_Controller:SGT_Enabled” or “Converged:SGT_Enabled” to determine that an SGT Value should be handed back to the wireless controller after a user or device’s successful authorization as opposed to an ACL for policy enforcement. This allows for a migrational approach to deploying infrastructure that will make use of SGT as opposed to ACLs for policy enforcement.

5. Configure the RADIUS Shared Secret. This must match that configured on the network device.

6. Click the down arrow next to SNMP Settings and complete as appropriate.

7. Click the down arrow next to Advanced TrustSec Settings. These settings are only used for those devices supporting SGACLs and Native SG Tagging on SGT-capable hardware requiring the download of TrustSec environmental and policy data from ISE.

Figure 23-17 Network Device Generic Definition at ISE

 

Figure 23-18 Network Device Group definition

 

8. Once the Advanced TrustSec Settings configuration box has been expanded as seen in Figure 23-19, click the check box next to “Use Device ID for TrustSec Identification”

9. Enter the password that will be configured later on the network device in the cts credential command. This can be the same as the RADIUS Shared Secret.

10. Configure the desired settings for “TrustSec Notifications and Updates”. Note that these are the settings that determine the frequency of the TrustSec Environment updates to the network device. It is recommended that aggressive timers not be used here and as such these have been left at the default value for one day. Note that this is to configure the automated, periodic update of the pertinent data. In addition to these periodic updates, it is possible to manually push updates for SGT Names/Values, Network Device SGT, SGT Egress Policy (SGACL), and AAA Server List from within ISE to those network devices supporting Change of Authorization (CoA). Note that the Nexus 7000 does not support CoA at the time of this document. To support a manual push of environmental data and policy to the Nexus 7000, it is possible to do so through reissuing the cts credential command at the Nexus 7000 discussed later. For further information regarding these parameters and how TrustSec environment data is exchanged, refer to the ISE User Documentation and specifically the “Configuring TrustSec Settings on Switches” and “TrustSec CoA” sections of the chapter “Configuring Cisco Security Group Access Polices” located in the ISE 1.2 User Guide at: http://www.cisco.com/en/US/products/ps11640/products_user_guide_list.html .

11. Enter the credentials to access Exec Mode (if applicable) and the Enable Mode password used by ISE to access the device to manually push updated information.

12. Complete steps one through seven for every wireless controller providing 802.1X-authenticated wireless access to users and steps one through eleven for all network devices that will be enforcing TrustSec Policy requiring SGT Names and SGACL egress policies.

Figure 23-19 Network Device—Advanced TrustSec Settings

 

Configuring Network Access Devices for Authentication at ISE

Configuration of the network devices for NDAC support will be outlined in this section. A section will be devoted to each of the Wireless Controllers, Catalyst 6500 VSS, and the Nexus 7000 switches.

The following configuration tasks will all be completed at the network devices themselves. This configuration is critical to identify the ISE Primary server as the AAA server from which information regarding TrustSec will be exchanged. Note that for greater resilience, multiple ISE Policy Service Nodes can be listed and will be tried in succession. As previously mentioned, it is only necessary to configure those devices that will provide access for the wireless users and the network devices that will actually enforce TrustSec policies. It is completely optional whether or not this needs to be configured on other devices in the path between the enforcement points.

RADIUS Server Configuration on the CT-5508 Wireless Controller

The configuration of RADIUS server information is required in order for the controller to act as a RADIUS Authenticator for 802.1X-based authentication of wireless clients accessing the network. More than likely these steps have already been completed as this is a basic requirement for securing wireless access regardless of the desire to use ACLs or Security Group Tags.

1. Access the wireless controller either through the local UI or Prime. In Figure 23-20 the controller’s GUI is depicted.

2. Go to Security > AAA > Radius > Authentication

3. In the top right of the screen, if the ISE server has not been configured yet, click New.

4. A new window will open as seen in Figure 23-21.

Figure 23-20 Wireless Controller RADIUS Configuration

 

Figure 23-21 Wireless Controller RADIUS Server Configuration

 

5. Use the drop down to enter the correct priority; lower number is higher priority.

6. Enter the ISE server’s IP address.

7. Enter the Shared Secret which must match that configured for the wireless controller as defined in the Network Device List in ISE.

8. Enter the correct RADIUS Authentication UDP port number.

9. Click Apply.

10. Configure the controller’s RADIUS Accounting information as the Authentication information above. This can be accessed by following Security > AAA > Radius > Accounting.

Configuration of the wireless controller RADIUS server configuration is complete. Repeat these steps if additional controllers need to be configured.

RADIUS and CTS Configuration of the 5760 Switch

As shown in the network topology diagram (Figure 23-16), the 5760 Wireless LAN Controller in the campus network supports in-line tagging of SGT frames. The following steps outline those tasks necessary to configure ISE as a RADIUS server at the 5760 Wireless LAN controller in the campus network. As discussed, this is to establish a secure connection with ISE for the exchange of TrustSec Environment Data and Policies. These steps should be performed on all 5760 wireless controllers regardless of deployment scenario as they will serve as RADIUS Authenticator to wireless devices accessing the network or propagating Security Group Tags and enforcing policies based on same as in the case of Scenario 1.

aaa new-model
!
!
// The aaa authorization CTS Configures the switch to use RADIUS authorization for all network-related service requests.
// cts authorization list Specifies a Cisco TrustSec AAA server group.
aaa authentication login default enable
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa authorization network CTS group radius
aaa accounting identity default start-stop group radius
!
cts authorization list CTS
!
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 send nas-port-detail
radius-server dead-criteria time 5 tries 3
!
radius server bn14-3495-2
address ipv4 10.230.1.12 auth-port 1812 acct-port 1813 pac key 7 11270A0C03175A5E577E7E
 
Although the following steps are only required for Scenario 1 and the use of SGACLs, should a hybrid approach combining SGACLs and SG-FW in Scenarios 1 and 2 be desired, the <cts role-based enforcement> command will be required.
 
(config)#cts role-based enforcement /Global command to enable TrustSec
(config)#cts role-based enforcement vlan-list 57 /Enable role-based enforcement between devices in VLAN 57; East/West enforcement.

RADIUS and CTS Configuration of the Nexus 7000

The following steps outline those tasks required to enable TrustSec role-based enforcement and configure ISE as a RADIUS server at the Nexus 7000. As discussed, this is to establish a secure connection with ISE for the exchange of TrustSec Environment Data and specifically the SGT Names for use in creating IP/SGT Bindings at the Nexus 7000 Data Center Aggregation switches. No policies are available for download as they are configured at the ASA as SGACLs are not used in this deployment scenario.

Although SGACLs will not be enforced at the Nexus 7000 Data Center Aggregation switches as in the first deployment scenario, but rather at the ASA configured as a Security Group Firewall, it is still necessary to define the Nexus 7000 aggregation switches in ISE in order to share TrustSec Environment Data in order to learn SG Names and IP/SGT mappings defined centrally at ISE.

feature dot1x /Enable dot1x support.
feature cts /Enable cts (TrustSec) support
 

Although the following steps are required for Scenario 1 and the use of SGACLs, should a hybrid approach combining SGACLs and SG-FW in Scenarios 1 and 2 be desired, the cts role-based enforcement command will be required.

TrustSec must be enabled for SGT propagation both globally on the switch as well as for those VLANs on which SGACLs will be enforced through the use of the following commands:

Global commands

cts role-based enforcement /Enables SGACL enforcement on Nexus 7000
cts role-based counters enable /Enable role-based access control list (SGACL) counters
 

VLAN Interface commands

(config)# vlan id /Enter VLAN configuration mode.
(config-vlan)# cts role-based enforcement /Enables SGACL enforcement for specified VLAN
 

Once the features have been enabled, the AAA servers and TrustSec Device credentials must be enabled through the following commands:

cts device-id device-id password password /TrustSec credentials for use with ISE; device ID and password much be the same as at ISE.
radius-server host 10.225.49.15 key <secret> pac /Specifies the RADIUS authentication server, shared secret must be same as configured for RADIUS secret at ISE.
aaa group server radius <ise> /Creates a AAA Server Group ISE
server 10.225.49.15 /Defines 10.225.49.15 as a member of Group ISE
aaa authentication dot1x default group <ise> /Specifies the 802.1X port-based authentication method as RADIUS.
aaa accounting dot1x default group <ise> /Enables 802.1X accounting using group ISE
aaa authorization cts default group <ise> /To configure the default authentication, authorization, and accounting (AAA) RADIUS server groups for Cisco TrustSec authorization
ip radius source-interface loopback0 /Matches the IP Address of the device configured in ISE; uses the IP Address of Lo0 to source all RADIUS.

RADIUS and CTS Configuration of the Catalyst 6500

The following steps outline those tasks necessary to enable TrustSec role-based enforcement and configure ISE as a RADIUS server at the Catalyst 6500. As discussed, this is to establish a secure connection with ISE for the exchange of TrustSec Environment Data and Policies. These steps should be performed on any Catalyst 6500 that will enforce policies based on Security Group Tags. For the infrastructure depicted in this CVD, configuration must be completed on the Catalyst 6500 VSS in Shared Services to which the wireless controllers are attached. Although optional when configuring Scenario 2, defining this provides additional support for a hybrid deployment where both Scenario 1 and 2 may be used, such as in the case of East-West traffic between different wireless controllers relative to the Shared Services C6500. As the Catalyst 6500 VSS Core and Catalyst 6500 VSS Distribution switches are merely forwarding tagged packets sourced from either the wireless users or servers themselves and not enforcing any policies, there is no requirement to configure it within ISE and is purely optional.

As with the Nexus 7000, although the following steps are required for Scenario 1 and the use of SGACLs, should a hybrid approach combining SGACLs and SG-FW in Scenarios 1 and 2 be desired, the cts role-based enforcement command will be required.

TrustSec must be enabled both globally on the switch for SGT propagation as well as for those VLANs on which SGACLs will be enforced through the use of the following global commands:

cts role-based enforcement /Globally enables SGACL enforcement for CTS-enabled Layer 3 interfaces in the system.
cts role-based enforcement vlan-list {vlan-ids | all} /Enables SGACL enforcement for Layer 2 switched packets and for L3 switched packets on an SVI interface.
 

Note SGACL enforcement is not enabled by default on VLANs. The cts role-based enforcement vlan-list command must be issued to enable SGACL enforcement on VLANs.


The following provides the configuration commands required for ISE as the RADIUS server on the Catalyst 6500:

cts credentials id device-id password <password> /TrustSec credentials for use with ISE; device ID and password must be the same as at ISE.
aaa new-model /Enables AAA
aaa group server radius <ise> /Creates a AAA Server Group ISE
server 10.225.49.15 auth-port 1812 acct-port 1813 /Defines 10.225.49.15 as a member of Group ISE.
aaa authentication dot1x default group radius /Specifies the 802.1X port-based authentication method as RADIUS.
aaa server radius dynamic-author /Enable CoA on the 6500 to enable updates for SG Names/Tags, Environment Data, and RBACL
client 10.225.49.15 server-key /Identifies ISE as AAA server initiating CoA
aaa authorization network <ise> group radius /Configures the switch to use RADIUS authorization for all network-related service requests using server group <ise>.
aaa accounting dot1x default start-stop group radius /Enables 802.1X accounting using RADIUS
cts authorization list <ise> /Specifies a Cisco TrustSec AAA server group
ip radius source-interface Loopback0 /Matches the IP Address of the device configured in ISE; uses the IP Address of Lo0 to source all RADIUS.
radius-server host 10.225.49.15 auth-port 1812 acct-port 1813 pac key <secret> /Specifies the RADIUS authentication server, shared secret must be same as configured for RADIUS secret at ISE.
radius-server vsa send authentication platform /Configures the switch to recognize and use vendor-specific attributes (VSAs) in RADIUS Access-Requests generated by the switch during the authentication phase
dot1x system-auth-control /Globally enables 802.1X port-based authentication

RADIUS and CTS Configuration of the 3850 Switch

Catalyst 3850 switches in the campus network support in-line tagging of SGT frames and will serve as both the RADIUS authenticator for wireless users as well as enforcing SGACLs. The following steps outline those tasks necessary to configure ISE as a RADIUS server at the 3850 switch acting as a Wireless LAN controller in the campus network. As discussed, this is to establish a secure connection with ISE for the exchange of TrustSec Environment Data and Policies. These steps should be performed on all Catalyst 3850 switches regardless of deployment scenario as they will serve as RADIUS Authenticator to wireless devices accessing the network or propagating Security Group Tags and enforcing policies based on same as in the case of Scenario 1.

aaa new-model
!
!
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa authorization network CTS group radius
aaa accounting dot1x default start-stop group radius
aaa accounting network default start-stop group radius
!
cts authorization list CTS
 

Although the following steps are required for Scenario 1 and the use of SGACLs, should a hybrid approach combining SGACLs and SG-FW in Scenarios 1 and 2 be desired, the cts role-based enforcement command will be required.

bnsl-3850-1(config)#cts role-based enforcement /Global command to enable TrustSec
bnsl-3850-1(config)#cts role-based enforcement vlan-list 551 /Enable role-based enforcement between devices in VLAN 551; East/West enforcement.

Configuring Network Devices with a Device SGT

The following outlines the configuration steps required to define a device SGT. Once a network device is configured with a device SGT, any traffic sourced from that device will use the defined SGT. Note that assigning a Security Group Tag to a device is purely optional. Network devices in this CVD are assigned a device SGT of 5. As granular role-based policies using SGTs are defined in the network, the assignment of an SGT to network devices may provide an additional level of control over whom or what may access the network infrastructure to poll or modify these devices.

Within this CVD when discussing the specific policies enforced by the SGACLs, it will be seen that SGT10 for Employees and SGT00 or unknown are both permitted access to SGT 5. Naturally this is for demonstration purposes only as much more granular policies would be defined for access to network infrastructure associated with SGT5. For example, it would be assumed that rather than providing all employees (SGT10) access to infrastructure, a group associated with network administrators would be defined and only those users would have access to SGT5 devices. In the case of unknown, it cannot be assumed that all network administrators have been migrated to the TrustSec Domain and hence once entering same via Catalyst switches or wireless networks yet to be migrated will be associated with SGT00 or unknown. As such, other security measures would naturally be required to restrict access to these devices such as ACLs or user credentials.

Also note that in the CVD, traffic between SGT 5 and 40 is permitted. This is in order to allow ISE, identified with SGT40, to be able to communicate with network devices to exchange not only TrustSec information but all AAA communications as well. Other options would be to assign ISE a unique SGT other than SGT40 which is used for Open Servers and Services that all can access. In doing this, all user, server, and network devices with their associated SGT assignments could be allowed to communicate with the unique SGT for ISE and a policy then established allowing ISE to communicate with the network devices without opening access to ISE from all servers with SGT40.

Although most likely used when using SGACLs throughout the infrastructure, as in the case of Scenario 1, there may be benefit even if only deploying Scenario 2 and a SG-FW.

1. At ISE navigate to Policy > Network Device Authorization.

2. Click the drop down box next to edit at the top right of the screen.

3. Select “Insert new row above” as depicted in Figure 23-22.

Figure 23-22 Configuring Network Device Authorization

 

4. A new line will be inserted as seen in Figure 23-23. Enter a rule name.

5. Click the “+” symbol in conditions and a drop down box will appear.

6. Click the arrow next to “Select Attribute” and the Dictionaries drop down box will appear.

Figure 23-23 Defining Authorization Policy for the Network Device

 

7. Select “SGADeviceID” and, as can be seen in Figure 23-24, the Expression is populated with “TrustSec:SGADeviceID”.

8. Ensure “Equals” is displayed in the expression and select the appropriate device, as depicted in Figure 23-24.

Figure 23-24 Defining Network Device ID

 

9. Finally, as in Figure 23-25 define the SGT for the device by clicking the arrow next to “Select a Security Group” and select the appropriate SG Name; the CVD uses “SGT5_TrustSec_NAD”. See the note below.

10. Repeat steps one through nine to define all network devices; as wireless controllers cannot natively tag packets with an SGT on its interfaces, this procedure is not required for them.

Figure 23-25 Assigning the SGT to a Network Device

 


Note In Steps 9 and 10 above the network device ID (typically the hostname) is used to create a “Network Device Authorization Rule”. An alternative approach would be to use the “Location” or “Device Type” attribute, as seen in Figure 23-23. By using one of these attributes provided when initially defining a network access device in ISE as previously discussed and as seen in Figure 23-17, potentially hundreds of rules using device IDs could be replaced by a single rule using the device type attribute to classify a specific platform such as “Campus_Controller:SGT_Enabled”. Figure 23-26 shows the alternative way to configure the device ID.


Figure 23-26 Alternative Configuration of Device ID

 

Configuring Static IP/SGT Bindings on Nexus Switches

Unlike campus access through Catalyst Switches and Cisco Wireless Controllers where dynamic SGT mappings are communicated and created through 802.1X and RADIUS exchange, the vast majority of organizations do not implement 802.1X for server connectivity. As such, data center switches such as the Cisco Nexus switches provide only limited support for the use of 802.1X and do not specifically support an SGT RADIUS AV as an option. Therefore, IP Address to SGT mappings will be manually defined for bare metal and virtual servers.

For purposes of this CVD, we continue to use IP to SGT Bindings at a Nexus 7000 data center aggregation layer switch, but will also expand the means by which servers can be mapped to an SGT through the VLAN in which they reside. This new feature, which was previously discussed in SGT Assignment for Data Center Servers, is VLAN to SGT Mapping and is found in the NX-OS 6.2 release. In addition to the manual creation of an IP Address to SGT mapping either globally at the switch or within a VLAN, the server’s IP/SGT mapping may also be defined in ISE. Configuration at ISE for use in the CVD is purely optional as the focus of the CVD is on static IP/SGT mappings or VLAN to SGT mappings at the Nexus 7000 switches.

For purposes of this CVD, the static IP/SGT Mappings and the VLAN/SGT mappings have been created at the Nexus 7000 Data Center Aggregation layer switches as depicted below. Note that as there are two Nexus 7000s composing the aggregation layer in the data center; both must be configured identically for consistent policy enforcement.

The following commands provide an example of IP/SGT static bindings:

cts role-based sgt-map 10.230.1.2 40 /Binds 10.230.1.2 to SGT 40
cts role-based sgt-map 10.230.1.45 40 /Binds 10.230.1.45 to SGT 40
cts role-based sgt-map 10.230.1.61 40 /Binds 10.230.1.61 to SGT 40
 

The following commands provide an example of VLAN/SGT bindings:

vlan 136 /Specifies a VLAN and enters VLAN configuration mode.
cts role-based enforcement /Enables SGACL enforcement within the VLAN cts role-based sgt 40 /Maps all devices within VLAN 136 to SGT 40
vlan 137
cts role-based enforcement
cts role-based sgt 50
 

To verify the IP/SGT mappings at the Nexus 7000, issue the command sh cts role-based sgt-map.

bn14-n7k-agg# show cts role-based sgt-map
IP ADDRESS SGT VRF/VLAN SGT CONFIGURATION
10.230.6.3 40(Servers_Services_OpenAccess)vlan:136 Learnt through VLAN SGT configuration
10.230.6.14 40(Servers_Services_OpenAccess)vlan:136 Learnt through VLAN SGT configuration
10.230.7.3 50(Servers_Corporate)vlan:137 Learnt through VLAN SGT configuration
10.230.7.14 50(Servers_Corporate)vlan:137 Learnt through VLAN SGT configuration
10.230.1.12 40(Servers_Services_OpenAccess)vrf:1 CLI Configured
10.230.1.45 40(Servers_Services_OpenAccess)vrf:1 CLI Configured
10.230.1.61 40(Servers_Services_OpenAccess)vrf:1 CLI Configured
 

Note Refer to Migrational Considerations for TrustSec Implementation for a complete discussion of SGT mapping strategies in the data center.


Configuration for Deployment Scenario 1

This section provides detailed information regarding configuration of the necessary components that compose and are unique to Scenario 1. In addition to the configuration requirements for SGT propagation through the campus infrastructure, MACsec encryption will be used for link encryption where possible in the network. In this CVD MACsec will be used to encrypt the 10G links between Catalyst 6500s and Nexus 7000s. On the 10G links connecting the Catalyst 6500 with the Catalyst 3850s in distribution and the CT-5760 in Shared Services, MACsec although available in hardware is not enabled in software on the 3850 and 5760 at the time of writing. This capability will be enabled in a future release.

Prior to discussing the Scenario 1 configuration specifics, a brief explanation of Catalyst 6500-specific forwarding behavior with SGT encapsulated frames is required when using a SUP2-T Supervisor in conjunction with specific linecards. The following section discusses these considerations.

Catalyst 6500 Platform Specific Considerations

Prior to discussing aspects of the TrustSec infrastructure configuration, it is necessary to highlight one aspect regarding the Catalyst 6500 when configured for Cisco TrustSec and specifically SG Tagging capability. As previously stated, the SUP2T and WS-X69xx series of linecards are the only SGT-Capable Supervisor and linecard available today for processing and imposition/removal of Security Group Tags in the Catalyst 6500. Specialized ASICs are required in order to forward tagged packets and encrypt the frames using 802.1ae MACsec with 10GE wirespeed performance. This functionality involves changes in the internal forwarding process. In order to support earlier linecards that do not have these newer ASICs (i.e., WS-X68xx, WS-X67xx, and WS-X61xx) in the same chassis when TrustSec has been enabled, two new operating modes have been developed called Ingress and Egress Reflector mode. Ingress Reflector mode is intended for use when the Catalyst 6500 is providing network access; it does not support linecards with a DFC installed. Egress reflector mode provides compatibility with legacy line cards by using the SUP2T forwarding engine’s built-in packet replication ASICs to initiate a second packet forwarding decision. This second forwarding decision is used to impose the Cisco TrustSec SGT information on packets egressing the system from an SGT-capable interface. For purposes of this BYOD CVD, Egress Reflector Mode will be used on the Catalyst 6500 VSS switches containing legacy linecards.

To enable the Egress Reflector Mode on the Catalyst 6500, it is necessary to perform a reload of the system. It is recommended for obvious reasons that this be performed off hours and that necessary precautions have been put in place to ensure that traffic can be forwarded around the reloading system if required. In the case of Catalyst 6500s configured for VSS, it is recommended that the entire system be reloaded through the reload command. The command to enable this mode of operation on the Catalyst 6500 is:

platform cts egress
 

For more detailed information, refer to: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-658388.html .

Configuring Security Group Tag Exchange Protocol (SXP) for Wireless Controllers

Campus wireless users accessing the network upon successfully matching an authorization profile at the Identity Services Engine will be associated with an SGT. Upon successful authentication and subsequent authorization to the network, the Identity Services Engine will pass the appropriate SGT value to the wireless controller through a RADIUS AV. This SGT value is associated with the IP Address of the wireless user obtained through the 802.1X authentication and an IP/SGT mapping/mapping created at the wireless controller.

Whereas the CT-5760 wireless controller supports native tagging upon egress from the controller and will be discussed separately in Scenario 1, wireless controllers such as the CT5508, used in this guide, and the WiSM2 do not support the tagging of packets sourced from these wireless users out of the controller through both physical and internal interfaces, in the case of the WiSM2. As such, the Security Group Tag Exchange Protocol will be used to advertise these SGT mappings to the Shared Services Catalyst 6500VSS switch, which will impose the appropriate tag upon egress from the switch.

SXP is configured on a device by identifying its peer’s IP Address and specifying a password for use in authenticating each side of the connection. SXP supports two modes which can be used either exclusively or combined. The first mode is that of the “Speaker”, which as the name suggests advertises IP/SGT mappings. The other mode is “Listener”, which also as its name suggests listens for the Speaker’s advertisements. It is possible for a device to be both a “Speaker” and a “Listener”. The CT5508 and WiSM2 only support “Speaker” mode as they do not support SGACLs or SGT Tagging and hence a “Listener” mode is not applicable.

Both sides of the SXP connection must be configured and within Deployment Scenario 1 this includes configuration of both CT5508s as well as the Shared Services Catalyst 6500 VSS switch. Refer to Figure 23-27.

Figure 23-27 SXP Peering

 

Wireless Controller Configuration

Access the wireless controller via a web UI and follow the following steps:

1. Navigate to Security > TrustSec SXP.

The screen in Figure 23-28 appears.

2. Click the drop down arrow for “SXP State” and select Enabled.

3. Set the “default Password”. This must match that configured on its peer.

4. Click “New” (top right).

5. Fill in the IP Address (typically Loopback if possible) of the SXP Peer or the Shared Services Catalyst 6500VSS switch.

6. Click Apply.

Once successfully configured, the screen in Figure 23-29 should be presented upon accessing Security > TrustSec SXP. The “Connection Status” will indicate “Off” until the other device is configured.

Figure 23-28 SXP Configuration at Wireless Controller

 

Figure 23-29 SXP Configuration Complete

 

Catalyst 6500 SXP Configuration

The following commands were used at the Shared Services Catalyst 6500 VSS to enable SXP peering with the CT5508 wireless controllers.

cts sxp enable /Enable CTS
cts sxp default source-ip 10.225.100.5 /Source SXP connection from 10.225.100.5 (Lo)
cts sxp default password password /Configured password on the 6500 for incoming SXP connections
cts sxp connection peer 10.225.43.2 source 10.225.100.5 password default mode local listener hold-time 0 0 /Builds an SXP connection to its peer at 10.225.43.2 using source address of 10.225.100.5 and the default password defined above. Specifies that this (local) device is in “Listener” mode. The source IP Address used here is purely optional as it was specified above.
 

Issuing the command show cts sxp connection results in the following output.

ua28-6500-1>sh cts sxp connections
SXP: Enabled
Highest Version Supported: 4
Default Password : Set
Default Source IP: 10.225.100.5
Connection retry open period: 120 secs
Reconcile period: 120 secs
Retry open timer is not running
----------------------------------------------
Peer IP: 10.225.43.2 <--Wireless Controller
Source IP: 10.225.100.5
Conn status: On
Conn version: 2
Local mode: SXP Listener
Connection inst#: 1
TCP conn fd: 1
TCP conn password: default SXP password
Duration since last state change: 0:21:49:55 (dd:hr:mm:sec)
 
Total num of SXP Connections = 1

Configuring Switching Infrastructure to Support TrustSec with 802.1ae MACsec Encryption

Now that the configuration of ISE and the Network Access Devices’ ability to communicate with ISE as the AAA server via RADIUS have been completed, the following steps are required for the configuration of the 10GE links in the switching infrastructure to support TrustSec, specifically SGT insertion, removal, and forwarding as well as the encryption of those links using 802.1ae MACsec. In the BYOD CVD infrastructure depicted in Figure 23-30, it is necessary to configure the blue, 10GE links in the figure for TrustSec using the Catalyst and Nexus switch cts command.

Figure 23-30 TrustSec Configuration of 10GE Links

 

There are two methods, 802.1X Mode and Manual Mode, for configuring 10GE interfaces to support Security Group Access (TrustSec), enabling the forwarding and policy enforcement of frames with an embedded Security Group Tag. CTS 802.1X Mode uses a Pairwise Master Key (PMK) derived through the authentication phase between the network device and ISE for link encryption whereas with CTS Manual Mode, as its name implies, the PMK is manually configured. In this CVD, the Manual Mode of configuration is used.

Common to both of these methods is first the ability to employ MACsec (802.1ae) which provides encryption, a message integrity check, and data-path replay protection for links between adjacent network devices thereby protecting the CMD field and the SGT value it contains. Second, as previously discussed is the configuration for 802.1X authentication of the network devices that will enforce policies based on the SGT with ISE acting as an Authentication Server.

Also common to both CTS Manual and 802.1X Mode is the use of the Security Association Protocol (SAP) which is an encryption key derivation and exchange protocol based on a draft version of the 802.11i IEEE protocol. In a TrustSec configuration, the keys are used for MACsec link-to-link encryption between two interfaces.

In CTS Manual Mode, the Pairwise Master Key (PMK) will be manually configured on each of the two interconnecting 10GE interfaces with the sap pmk command. The PMK is a hexadecimal value with an even number of characters and a maximum length of 32 characters. It is not necessary to specify all 32 characters as the value provided will be padded with zeroes. This value MUST be the same on both sides of the link between the two switches. The Catalyst 6500s will pad the PMK provided with leading zeroes by default however the Nexus 7000 will pad the PMK with trailing zeroes by default. It is possible however, at the Nexus 7000 command line, to alter this behavior which is demonstrated below.


Note If configuring 10GE links that have not been defined as a member of a port channel, you may proceed to the commands listed below. If however, these 10GE links are presently active within a port channel, it will be necessary to first remove them from that port channel as otherwise issuing the cts command will fail, having not successfully passed a port channel consistency check. Once removed from the Port Channel, TrustSec, through the cts command can now be configured.
When migrating port channels to enable TrustSec/MACsec, one possible migration option is to remove the links one at a time, configure TrustSec and MACsec as applicable on both sides of the link and ensure that the link comes back up. Repeat this on each port channel member until the last one is reached. Remove the last remaining member from the port channel. Once the port channel has no remaining links, those configured for TrustSec can then be added sequentially. This type of migrational procedure can be used on both the Catalyst and Nexus switching platforms.


When configuring the Security Association Protocol as the keying mechanism for use with MACsec several options are available for authentication and encryption on the link. Table 23-4 provides a summary of each option. When mode-list is specified as above, the devices on either side of the link will negotiate via the SAP protocol, the method supported. As defined above, gcm-encrypt will be tried first and so on.

 

Table 23-4 Security Association Protocol Options

Mode
Description

gcm-encrypt

Authentication and encryption

gmac

Authentication, no encryption

no-encap1

No encapsulation1

null

Encapsulation (SGT), no authentication or encryption

1.If the interface is not capable of SGT insertion or data link encryption, no-encap is the default and the only available SAP operating mode.

TrustSec Link Policy

When configuring the 10Gb Ethernet links for the Manual Mode of operation, it is necessary to define whether tags received from a peer device should be trusted or untrusted and how the tags or lack of should be propagated by the switch. This “Policy” is only applicable to traffic entering a switch interface and not upon egress from the switch. When the interface is configured for the trusted state, the tag encapsulated in the frame will be propagated as is. For those frames arriving at an interface that have either 00 (the “unknown” tag) or no CMD, hence no SGT present, the behavior will vary depending on the platform and is discussed later in this section. In the case of having defined the peer as “untrusted”, the tag present, whether a defined value, unknown, or if CMD is missing altogether, will be overwritten by the SGT value specified in the policy command. This is accomplished through the use of the policy static command on a switch ingress interface as follows:

(config-if)#cts manual /Manually enable an interface for Cisco TrustSec Security (CTS)
(config-if-cts-manual)# policy static sgt id trusted /Establishes that the peer is trusted.
 

Alternatively:

(config-if)#cts manual /Manually enable an interface for Cisco TrustSec Security (CTS)
(config-if-cts-manual)# policy static sgt id /Establishes that the peer is untrusted (no trusted keyword)
 

The policy definition is required for both the Catalyst 6500 and the Nexus 7000 and if omitted will result in the frames, whether tagged with a defined SGT value or SGT:00 for unknown, having the CMD header with the SGT value removed and hence an un-tagged frame. In other words, when omitting the policy static command any tag is inherently “untrusted”.


Note Prior to NX-OS v6.2.2, the omission of the policy static command had a very different behavior than than v6.2.2 and later. Prior to v6.2.2 if the command were omitted, frames received with an SGT defined would be forwarded with that value. If the frame carried an SGT of 00 or unknown, it would be forwarded with 00 and if the frame was untagged it would be forwarded as SGT:00.
Post NX-OS 6.2.2 as mentioned previously, if omitted, the frame will be forwarded without a tag after having removed the CMD header carrying the SGT.
Catalyst 6500 switches performs consistently regardless of version such that if omitted, the frame will be forwarded without a tag.


Table 23-5 summarizes the effect of omitting the policy static command from a Nexus 7000 inteface depending on the NX-OS version used.

 

Table 23-5 Effect of Omitting policy static Command from Nexus 7000 Interface

Policy static command omitted pre-NX-OS 6.2.2
Nexus 7000

Tagged Frame other than SGT:00

Pass with source tag

Tagged Frame SGT:00 or unknown

Pass with tag SGT:00

Un-Tagged Frame

Pass with tag SGT:00

Policy static command omitted post-NX-OS 6.2.2

Tagged Frame other than SGT:00

Pass without a tag (no CMD in header)

Tagged Frame SGT:00 or unknown

Pass without a tag (no CMD in header)

Un-Tagged Frame

Pass without a tag (no CMD in header)

Within the CVD, the TrustSec domain will make use of all “trusted” interfaces, however there are instances where an architecture or deployment has a requirement for strict policy control, such as at the edge of the TrustSec domain in order to mark traffic for specific treatment and hence the use of the “untrusted” policy state. Figure 23-31 and the subsequent explantion provide an example of the behavior of the policy static command when a peer is untrusted. This behavior is identical whether used on a Catalyst 6500 or Nexus 7000 interface.

Figure 23-31 Policy Static “Untrusted” Behavior

 

The following SGT marking behavior can be seen in the previous figure:

1. Frames having an SGT:100, SGT:00, and no tag (no CMD header present) are entering 6500-1 from the left.

2. A PC or Server connected by a non-TrustSec link is attached to 6500-1.

3. The ingress policy is set to <policy static SGT 200> (untrusted) on the left 10G link while the PC port is not configured.

4. Traffic leaving the switch now all have a value of SGT:200 as long as there is not a mapping for the Src IP Address in 6500-1. If a mapping for that IP exists, it will be marked with that static SGT value.

5. Notice that the PC traffic leaving the switch has SGT:00 for the following reasons:

  • No policy was configured on the PC's Ethernet port.
  • The policy static command configured on the egress interface has no effect on traffic in the egress direction. The policy static command only influences ingress traffic.
  • There is not a mapping for the Src IP Address in 6500-1. If a mapping for that IP had existed, it would have been marked with that static SGT value.

6. The Nexus 7000 switch now has traffic from the Catalyst 6500 peer with SGT:200 and the PC traffic with SGT:00.

7. The traffic entering N7K-1 is untrusted and thus as the traffic leaves N7K-1 it will be marked with SGT:400 as specified by the policy static sgt 400 on the ingress (left interface), as long as there is not a mapping for the Src IP Address in N7K-1for any of the flows. If a mapping for that IP exists, it will be marked with that static SGT value. Again the egress policy has no effect whatsoever on the traffic leaving the switch.

When specifying the policy static sgt id trusted command on an interface, any traffic received from a peer with a valid, pre-defined SGT value will be “trusted” and propagated with that SGT value intact, unlike the untrusted behavior where it is overwritten. As of the writing of this CVD there is a discrepancy between the behavior of a trusted interface in a Catalyst 6500 versus a Nexus 7000 relative to the propagation of untagged traffic or traffic with an SGT of 00 (unknown). This discrepancy exists with all versions of IOS for the Catalyst 6500 and NX-OS for the Nexus 7000 up to and including 15.1.2SY for the 6500 and 6.2.6 for the Nexus 7000. Figure 23-32 and subsequent explantion provide an example of the behavior of the policy static trusted command when a peer is trusted for both the Catalyst 6500 and the Nexus 7000.


Note In Figure 23-32 it can be seen that the SGT value specified for the ingress interfaces of the two switches is different. This is depicted in this fashion to demonstrate the behavior more thoroughly. When assigning the SGT value for the policy static trusted command, it may be the same or unique from one interface to the next throughout the TrustSec Domain. As a matter of best practice, it is recommended that a single, unique SGT value be used throughout the TrustSec Domain and not used for any other purpose than the interfaces.


Figure 23-32 Policy static Trusted Behavior

 

1. Frames having an SGT:100, SGT:00, and no tag (no CMD header present) are entering 6500-1on the top and N7K-1on the bottom from the left interface.

2. A PC or Server connected by a non-TrustSec link is attached to 6500-1 and N7K-1.

3. The ingress policy is set to policy static SGT 200 trusted on the left 10G link of both the Catalyst 6500 and the Nexus 7000 switches while the PC port is not configured.

4. Traffic leaving the first Catalyst 6500 in the top half of Figure 23-32 will be propagated as follows:

  • Tagged traffic will be forwarded with the tag received as in the case of SGT:100.
  • Untagged traffic from the PC without the CMD present will be forwarded with a tag of 00 or “unknown” as long as there is not a mapping for the Src IP Address in 6500-1. If a mapping for that IP exists, it will be marked with that static SGT value.
  • Unknown traffic, SGT:00, will be forwarded with 00 as long as there is not a mapping for the Src IP Address in 6500-1. If a mapping for that IP exists, it will be marked with that static SGT value.

5. Notice that the PC traffic leaving the Catalyst 6500 has SGT:00 for the following reasons:

  • No policy was configured on the PC’s Ethernet port.
  • The policy static command configured on an egress interface has no effect on traffic in the egress direction. The policy static command only influences ingress traffic.
  • There was not a mapping for the Src IP Address in 6500-1. If a mapping for that IP existed, the traffic would have been marked with that static SGT value.

6. Traffic leaving the first Nexus 7000 switch in the bottom half of the diagram will be propagated as follows:

  • Tagged traffic will be forwarded with the tag received as in the case of SGT:100.
  • Untagged traffic from the PC without the CMD present will be forwarded and marked with a tag of 200 as long as there is not a mapping for the Src IP Address in N7K-1. If a mapping for that IP exists, it will be marked with that static SGT value.
  • Unknown traffic SGT:00 will be forwarded and re-marked with 200 as long as there is not a mapping for the Src IP Address in N7K-1. If a mapping for that IP exists, it will be marked with that static SGT value.

7. Notice that the PC traffic leaving the Nexus 7000 has SGT:00 for the following reasons:

  • No policy was configured on the PC's Ethernet port.
  • The policy static command configured on an egress interface has no effect on traffic in the egress direction. The policy static command only influences ingress traffic.
  • There was not a mapping for the Src IP Address in N7K-1. If a mapping for that IP existed, the traffic would have been marked with that static SGT value.

8. The second Catalyst 6500 and Nexus 7000 switches are configured with policy static sgt 400 trusted on their ingress interfaces.

9. Traffic leaving the second Catalyst 6500 in the top half of the diagram will be propagated as follows:

  • Tagged traffic will be forwarded with the tag received as in the case of SGT:100.
  • Unknown traffic, SGT:00, will be forwarded with 00 as long as there is not a mapping for the Src IP Address in 6500-1. If a mapping for that IP exists, the traffic will be marked with that static SGT value.

10. Traffic leaving the second Nexus 7000 switch in the bottom half of Figure 23-32 will be propagated as follows:

  • Tagged traffic will be forwarded with the tag received as in the case of SGT:100 and SGT:200.
  • Unknown traffic, SGT:00, will be forwarded and re-marked with 400 as long as there is not a mapping for the Src IP Address in N7K-1. If a mapping for that IP exists, it will be marked with that static SGT value.

11. In Figure 23-32, remember that the egress policy has no effect whatsoever on the traffic leaving either the Catalyst 6500 or Nexus 7000.


Note In NX-OS 6.2.2, defect CSCul56062 was identified on the Nexus 7000 such that if an egress interface was configured as “Untrusted” (sgt policy static sgt id), the frames egressing the switch would be re-marked to the value specified in the policy static command. This behavior is depicted in Figure 23-33. This has since been resolved in NX-OS 6.2.6 and as such it is recommended to not use 6.2.2.


Figure 23-33 Policy static untrusted behavior with Defect CSCul56062

 

The following table summarizes the behavior of the policy static sgt id | trusted command.

 

Table 23-6 Behavior of policy static sgt id trusted Command

Policy Status
Catalyst 6500
Nexus 7000
Feature (policy static sgt 80 trusted)

State: Trust - Tagged Frame

Pass with Src SGT received

Pass with Src SGT received

State: Trust - Un-tagged Frame or SGT:00

Pass with SGT:00 (Unknown)

Pass with SGT:80 as configured.

Feature (policy static sgt 80)

State: Un-Trusted - Tagged Frame

Pass with SGT:80 as configured.

Pass with SGT:80 as configured.

State: Un-Trusted - Un-tagged Frame or SGT:00

Pass with SGT:80 as configured.

Pass with SGT:80 as configured.

The recommendation established in this CVD is to configure all interfaces within or at the edge of the TrustSec Domain as trusted. It is also strongly advised that the SGT value used in the policy static command is a unique value dedicated to interfaces only and, more specifically, not the Device SGT. The reason for not specifying the same SGT value as that used for the actual device is discussed later in this section. However suffice it to say based on the behavior of the Nexus 7000 interfaces when configured as trusted, any unknown traffic will be remarked to the SGT value specified in the interface policy static command. That said an explicit SGACL will be required denying access to the actual infrastructure’s Device SGT from the interface SGT so that only users/devices with a specific SGT have administrative access to network devices.

Based on the recommendation for a unique SGT value to be used on TrustSec interfaces, SGT 80 has been reserved and used exclusively in the CVD for this purpose. Figure 23-34 depicts the SGT marking behavior that can be expected.

Figure 23-34 Recommendation for policy static Command

 

1. Tagged traffic with either a defined value or 00 representative of “Unknown” as well as traffic without a CMD header and hence no SGT value whatsoever will enter 6500-1.

2. Note that the policy static sgt 80 trusted command on 6500-1’s right interface has no effect on traffic egressing the switch whatsoever. Its intent is for either return or sourced traffic from the data center. Traffic egressing 6500-1 will be marked accordingly:

  • Traffic with a valid SGT will be trusted and propagated with the original SGT such as 100.
  • Traffic without a CMD Header and hence no SGT will be encapsulated with a CMD and a value of 00 as long as there is not a mapping for the Src IP Address in 6500-1. If a mapping for that IP exists, it will be marked with that static SGT value.
  • Unknown traffic or SGT:00 will be forwarded with SGT:00 as long as there is not a mapping for the Src IP Address in 6500-1. If a mapping for that IP exists, it will be marked with that static SGT value.

3. N7K-1 will be configured with policy static sgt 80 trusted configured on the ingress interface (left).

4. Note that the policy static sgt 80 trusted command on N7K-1’s right interface has no effect on traffic egressing the switch whatsoever. Its intent is for either return or sourced traffic from the data center.

5. Based on the previously discussed differences in behavior between the Catalyst 6500 and Nexus 7000 platform, egress traffic will be marked accordingly:

  • Tagged traffic will be forwarded with the tag received as in the case of SGT100.
  • Unknown traffic, SGT00, will be forwarded and re-marked with 80 as long as there is not a mapping for the Src IP Address in N7K-1. If a mapping for that IP exists, it will be marked with that static SGT value.

Note In all of the previous examples and regardless of whether the device is a Catalyst 6500 or a Nexus 7000, there is one behavior that is always consistent. Untagged traffic without a CMD header present, and hence no SGT, upon egressing that device will always be encapsulated with the CMD header containing a value of 00. All traffic flowing across a TrustSec-capable link will have some SGT value and if a mapping for that traffic does not exist, it will always be 00 or “Unknown”.


One final consideration is around the traffic from users or devices accessing the network through network infrastructure that has yet to be configured for TrustSec. This was discussed in detail in Migrational Considerations for TrustSec Implementation. In summary, this traffic entering the data center with SGT00 will be remarked to SGT80. As such, it will be necessary to have a policy permitting access to all servers and resources in the data center from traffic with a source tag of 80 as it is impossible to discern a device’s role-based privileges. As such it would be anticipated that existing ACLs or firewall policies would restrict access based on IPv4 addresses.

Catalyst 6500 Commands

The following section provides configuration details for enabling TrustSec on the Catalyst 6500 interfaces. At the Ten Gigabit Ethernet interface configuration prompt issue the following commands. Note that the first two commands should have already been completed, however they have been included here as well.

cts role-based enforcement /Globally enables SGACL enforcement for CTS-enabled Layer 3 interfaces in the system.
cts role-based enforcement vlan-list {vlan-ids | all} /Enables SGACL enforcement for Layer 2 switched packets and for L3 switched packets on an SVI interface.
 
(config-if)#cts manual /Manually enable an interface for Cisco TrustSec Security (CTS)
(config-if-cts-manual)# sap pmk ABC123 mode-list gcm-encrypt gmac null /Manually specify the Pairwise Master Key (PMK) and the Security Association Protocol (SAP) authentication and encryption modes to negotiate MACsec link encryption between two interfaces.
(config-if-cts-manual)# policy static sgt 80 trusted /Establishes the trust state of the peer interface. See note above.
 

Nexus 7000 Commands

At the Ten Gigabit Ethernet interface configuration prompt issue the following. If this configuration is being applied to a link interconnecting a Catalyst 6500 and a Nexus 7000, note that it will be necessary to alter the sap pmk command to change the default method of padding the PMK should less than 32 characters be specified. The first two commands should have already been completed, however they have been included here as well.

cts role-based enforcement /Enables SGACL enforcement on Nexus 7000
cts role-based counters enable /Enable role-based access control list (SGACL) counters
 
(config-if)#cts manual /Manually enable an interface for Cisco TrustSec Security (CTS)
(config-if-cts-manual)# policy static sgt 80 trusted /Establishes the trust state of the peer interface. See note above.
 

Link connecting to another Nexus switch:

(config-if-cts-manual)# sap pmk ABC123 mode-list gcm-encrypt gmac null /Manually specify the Pairwise Master Key (PMK) and the Security Association Protocol (SAP) authentication and encryption modes to negotiate MACsec link encryption between two interfaces.
 

Link connecting to a Catalyst switch:

(config-if-cts-manual)# sap pmk ABC123 left-zero-padded mode-list gcm-encrypt gmac null /Manually specify the Pairwise Master Key (PMK) and the Security Association Protocol (SAP) authentication and encryption modes to negotiate MACsec link encryption between two interfaces.
 

The SAP modes of operation are identical to those of the Catalyst 6500 detailed earlier.

Catalyst 3850 Commands

The Catalyst 3850 commands are almost identical to those used on the Catalyst 6500. As there is no MACsec support for the Catalyst 3850, the interface sap pmk configuration is not required on the 10G links used to connect the 3850 to the Distribution Layer switch. Additionally platform reflector mode configuration on the Catalyst 6500 as previously documented is not applicable to the 3850. The first two commands should have already been completed, however they have been included here as well.

(config)#cts role-based enforcement /Global command to enable TrustSec

(config)#cts role-based enforcement vlan-list 551/Enable role-based enforcement between devices in VLAN 57; East/West enforcement.

(config-if)#cts manual /Manually enable an interface for Cisco TrustSec Security (CTS)

(config-if-cts-manual)# policy static sgt 80 trusted /Establishes the trust state of the peer interface. See note above.

CT-5760 Commands

The CT-5760 supports native SGT tagging on its interfaces and as discussed previously also supports SGACLs such that all wireless device traffic egressing the CT-5760 will be encapsulated with the appropriate SGT. Likewise all tagged traffic received at the CT-5760 will inspect the tag on the incoming traffic and match it against the SGACL policy it received from ISE prior to forwarding to the wireless devices. Unlike the CT-5508 in Scenario 1, there is no requirement for any SXP configuration.

The CT5760 wireless controller will require the exact same commands as the Catalyst 3850. The CT-5760 presently does not support MACsec either so the sap pmk commands used on the Catalyst 6500 will not be required on the 10Gb Ethernet interfaces used to connect to the Shared Services Catalyst 6500 VSS switch. The first two commands should have already been completed, however they have been included here as well.

(config)#cts role-based enforcement /Global command to enable TrustSec

(config)#cts role-based enforcement vlan-list 2/Enable role-based enforcement between devices in VLAN 57; East/West enforcement.

(config-if)#cts manual /Manually enable an interface for Cisco TrustSec Security (CTS)

(config-if-cts-manual)# policy static sgt 80 trusted /Establishes the trust state of the peer interface. See note above.

Policy Enforcement

The next step for TrustSec configuration at ISE will be the definition of the actual policy to be enforced. As discussed previously, the TrustSec Policy will only be created for use as an SGACL on Catalyst and Nexus switching products. The ASA family of firewalls as of v9.0 do not support dynamic creation/update of the policies defined in ISE. Only the actual Security Group Names and Tag value are dynamically acquired from ISE. The policy used in this CVD is depicted in Figure 23-35.

Figure 23-35 Security Group Tag Egress Policy Matrix

 


Note Within this CVD when discussing the specific policies enforced by the SGACLs, it will be seen that SGT10 for Employees and SGT00 or unknown are both permitted access to SGT 5. Naturally this is for demonstration purposes only as much more granular policies would be defined for network access. For example it would be assumed that rather than providing all employees (SGT10) access to infrastructure, a group associated with network administrators would be defined and only those users would have access to SGT5 devices. In the case of unknown, it cannot be assumed that all network administrators have been migrated to the TrustSec Domain and hence once entering will be associated with SGT00 or unknown. As such other security measures would naturally be required restrict access to these devices such as ACLs or user credentials.
Also note that in the CVD, traffic between SGT 5 and 40 is permitted. This is in order to allow ISE, identified with SGT40, to be able to communicate with network devices to exchange not only TrustSec information but all AAA communications as well.
Also note from Figure 23-35 that SGT 80 which has been reserved for use with the policy static interface commands is denied access to network infrastructure with a device SGT 5. Also with regard to SGT80 permissions, refer to TrustSec Link Policy for a detailed explanation and rationale why SGT80 must be permitted to all other SGT values during migration.


The basic TrustSec Policy that is used permits or denies a specific source SGT to a specific destination SGT. In addition to this basic policy it is possible to create SGACLs with additional granularity restricting or permitting access to specific TCP or UDP port numbers. Although not utilized in the CVD, the procedure for creating this policy is to first create an SGACL at ISE and then when creating a specific SGT policy, adding the SGACL to the definition. The following steps illustrate the creation of an optional SGACL to then be used in an SGT Policy. If this level of granularity is not required and only a basic permit or deny statement is needed, steps one through three below may be skipped.

1. Go to Policy > Policy Elements > Results > Security Group ACLs and Add an ACL.

2. Enter the name of the ACL and optionally add a description as depicted in Figure 23-36.

3. Add the ACL.

Figure 23-36 SGACL Creation

 

The next step is to define the SGT Policy on the ISE server by creating the appropriate entries to enforce the policy contained in Figure 23-35 earlier in this section. When creating the SGT Egress Policy definitions, it is possible to do this from three unique views:

  • Source Tree
  • Destination Tree
  • Matrix

Note that although the three views display the policy differently the steps for creating the policy are essentially the same. Please refer to the steps outlined below and depicted in Figure 23-37 where the Source Tree view is used.

4. Go to Policy > Security Group Access > Egress Policy and select a View. This example uses the Source View.

5. Click Add.

6. The following window opens as shown in Figure 23-37.

Figure 23-37 TrustSec Egress Policy Creation

 

7. Next click the Source Group down arrow and select the appropriate Source Group created earlier as depicted in Figure 23-38.

Figure 23-38 TrustSec Egress Policy Creation Source SGT

 

8. Click the Destination Group down arrow and select the appropriate Source Group as depicted in Figure 23-39.

Figure 23-39 TrustSec Egress Policy Creation Destination SGT

 

9. Ensure that the policy status is enabled and select an optional SGACL if necessary as in Figure 23-40.

Figure 23-40 Enabling TrustSec Egress Policy with SGACL

 

10. Finally define whether the traffic is permitted or denied and click Save as shown in Figure 23-41. This policy denies all traffic between a source associated with SGT12 and a destination with SGT50. Note that in Figure 23-41 an SGACL has not been defined. Also note that in creating the policy a like policy for return traffic denying SGT50 to SGT12 is not created automatically.

Figure 23-41 TrustSec Egress Policy Creation Denying Traffic

 

Once the addition of all egress policies is completed, the definitions can be viewed as a matrix as in Figure 23-42.

Figure 23-42 Egress Policy Matrix View

 

The following example output from the command show cts role-based permissions may be used to verify policies at a Catalyst 6500 once AAA configuration tasks have been completed later in this document.

ua28-6500-1#sh cts role-based permissions
IPv4 Role-based permissions default:
Permit IP-00
IPv4 Role-based permissions from group Unknown to group Unknown:
Permit IP-00
IPv4 Role-based permissions from group 10:SGT10_Campus_Corp to group Unknown:
Permit IP-00
IPv4 Role-based permissions from group 11:SGT11_Campus_Pers_Full to group Unknown:
Permit IP-00
IPv4 Role-based permissions from group 12:SGT12_Campus_Pers_Partial to group Unknown:
Permit IP-00
IPv4 Role-based permissions from group 40:Server_Services_OpenAccess to group Unknown:
Permit IP-00
IPv4 Role-based permissions from group 50:Servers_Corporate to group Unknown:
Permit IP-00
IPv4 Role-based permissions from group Unknown to group 40:Server_Services_OpenAccess:
Permit IP-00
IPv4 Role-based permissions from group 10:SGT10_Campus_Corp to group 40:Server_Services_OpenAccess:
Permit IP-00
IPv4 Role-based permissions from group 11:SGT11_Campus_Pers_Full to group 40:Server_Services_OpenAccess:
Permit IP-00
IPv4 Role-based permissions from group 12:SGT12_Campus_Pers_Partial to group 40:Server_Services_OpenAccess:
Permit IP-00
IPv4 Role-based permissions from group 40:Server_Services_OpenAccess to group 40:Server_Services_OpenAccess:
Permit IP-00
IPv4 Role-based permissions from group 50:Servers_Corporate to group 40:Server_Services_OpenAccess:
Permit IP-00
RBACL Monitor All for Dynamic Policies : FALSE
RBACL Monitor All for Configured Policies : FALSE

Device On-boarding, Provisioning, Authentication, and Authorization Policies for TrustSec in ISE

The final steps for configuring the infrastructure to support role-based policy enforcement involve the configuration within ISE of the various attributes and conditions required to support:

  • On-boarding a device within the ISE policy server.
  • Provisioning the device with the appropriate configuration and credentials to access the network.
  • Defining authentication and authorization profiles granting the appropriate access to the network.

This completes the configuration for Deployment Scenario 1. If there are no requirements to configure an SG-FW as in Scenario 2, the next steps are to configure the actual user policies as defined in Chapter 16, “BYOD Limited Use Case—Corporate Devices” for corporate devices and Chapter 15, “BYOD Enhanced Use Case—Personal and Corporate Devices” for personal devices.

TrustSec Policy Configuration Using the ASA and Security Group Firewall in the Data Center—Deployment Scenario 2

This section provides detailed information regarding configuration of the necessary components that are unique to Scenario 2 using the ASA firewall within the data center to enforce policies bsed on Security Group Tags and the SG-FW feature of the ASA.

ASA Firewall Configuration

Whereas Catalyst and Nexus switches can import the PAC file from ISE when authenticating for the first time, The ASA firewall requires that this process be performed manually. Importing the PAC file to the ASA establishes a secure communication channel with ISE. After the channel is established, the ASA initiates a PAC secure RADIUS transaction with ISE and downloads Cisco TrustSec environment data; specifically, the ASA downloads the security group table. As discussed earlier, the ASA firewall does not download SGT Policies only the SG tables; the SGT policies will be manually defined at the ASA. The security group table maps SGTs to security group names. Security group names are created on ISE and provide user-friendly names for security groups.

The first time the ASA downloads the security group table, it walks through all entries in the table and resolves all the security group names contained in security policies configured on the ASA; the ASA then activates those security policies locally. If the ASA is unable to resolve a security group name, it generates a system log message for the unknown security group name.

One special consideration needs to be kept in mind regarding the ASA and that is if PAC expiration occurs, a new PAC file will not be automatically downloaded as in the case of Catalyst and Nexus switches and hence updated SGT tables will not be able to be downloaded. At the time of this writing (v9.0.2), a new PAC file must be imported manually prior to the expiration of the existing one. If the ASA cannot download an updated security group table, the ASA continues to enforce security policies based on the last downloaded security group table until a new PAC file is downloaded and the ASA downloads an updated table.

The following steps must be completed to define the ASA firewall within ISE as depicted in Figure 23-43:

1. At ISE go to Administration > Network Resources > Network Devices and click Add.

2. Enter the hostname of the ASA firewall.

3. Enter the IP Address of the interface closest to the ISE server. In the case of the CVD, that happened to be the Outside Interface as ISE was located in a Shared Services block logically separated from the data center servers located within protected zones on various inside interfaces of the firewall.

4. Change the Network Device Location if appropriate.

5. Configure the RADIUS Shared Secret. This must match that configured on the ASA firewall.

Figure 23-43 ASA Network Device General Settings in ISE

 

Next complete the following steps for TrustSec configuration as depicted in Figure 23-44:

6. Click the arrow next to “Advanced TrustSec Settings”

7. Enter the Device ID.

8. Enter the password.

9. Note that none of the other settings for “TrustSec Notifications and Updates” and “Device Configuration Deployment” need to be completed. The TrustSec Environment Data and particularly the Security Group Tables/Names are downloaded to the ASA either manually or periodically based on the SXP Reconcile Timer configured at the ASA and covered later. Device Configuration Deployment is used to update Security Group Policies via CoA from ISE to the device. As TrustSec policies cannot be dynamically learned and must be manually defined on the ASA, these setting are not applicable as well.

Figure 23-44 ASA TrustSec Settings in ISE

 

The final task at ISE is to generate an Out of Band PAC for subsequent importing at ISE as depicted in Figure 23-45:

10. Click the arrow next to “Out of Band (OOB) TrustSec PAC”.

11. Click the “Generate PAC” button.

A popup will appear as depicted in Figure 23-46.

The device identity will be pre-populated using the “Device ID for TrustSec” hostname.

12. Define an arbitrary Encryption Key to be used.

13. Set the PAC Time to Live. Notice that this be configured for Days, Weeks, Months, or Years.

14. Click the “Generate PAC” button.

A PAC File will now be generated and you will be prompted to download and save the PAC file locally for later import and use by the ASA firewall.

Figure 23-45 Generating the TrustSec PAC File for the ASA Firewall at ISE

 

Figure 23-46 TrustSec PAC File Definition for the ASA Firewall at ISE

 

This completes the Network Device Definition for the ASA firewall in ISE.

RADIUS Server Configuration on the ASA Firewall

The following configuration steps need to be completed in order to establish the ISE server as a AAA server for the ASA and importing the TrustSec PAC File used for secure RADIUS exchange of TrustSec Environment Data and the SGT Tables specifically.

1. Open ASDM.

2. In ASDM, navigate to Configuration > Firewall > “Identity by TrustSec” as depicted in Figure 23-47.

3. Click the Manage button in the “Server Group Setup” area.

Figure 23-47 AAA Server Configuration in ASA

 

A popup window will open as can be seen in Figure 23-48.

4. Click the Add button.

Figure 23-48 Configuring AAA Server Groups in ASDM

 

A popup window opens as seen in Figure 23-49.

5. Enter a name for the AAA server Group.

6. Click OK.

Figure 23-49 Adding AAA Server Group in ASA

 

Once OK has been clicked the popup window closes and the “Configure AAA Server Groups” window is populated with the new Server Group as seen in Figure 23-50.

7. Click the Add button next to the box for “Servers in the Selected Group”.

Figure 23-50 Adding AAA Server to Server Group in ASA

 

A popup window opens as seen in Figure 23-51.

8. From the Interface drop-down select the interface closest to the ISE server as that interface's IP Address will serve as the source address for all RADIUS communications with ISE.

9. Enter the DNS Hostname or IP Address of the ISE server (PSN).

10. Change the Server Authentication Port to 1812 to match that configured at ISE.

11. Change the Server Accounting Port to 1813 to match that configured at ISE.

12. Enter the RADIUS “Server Secret Key” and “Common Password”. These will be the same as the shared secret key used earlier to define the ASA in ISE.

13. Click OK to add the AAA server to the AAA server Group. If more than one ISE Policy Service Node exist, repeat steps 10 through 15 to add additional AAA servers.

Figure 23-51 Adding AAA Server to Server Group

 

Once the AAA Server Group has been defined it will now be necessary to import the TrustSec PAC File at the ASA firewall. As depicted in Figure 23-52:

14. Down in the “Server Group Setup” area, select the correct AAA Server Group in the drop-down.

15. Click Import PAC.

A popup window will open as seen in Figure 23-53.

16. Browse to the location where the file was locally stored when generating the PAC at ISE and use the password used during PAC File generation.

Figure 23-52 Importing TrustSec PAC File at ASA

 

Figure 23-53 Importing TrustSec PAC at ASA

 

These final steps should be taken to validate that the PAC file was imported correctly at the ASA and that the SGT Tables have been downloaded from ISE. Issue the show cts pac command at the ASA firewall. The output should be as shown in Example 23-1.

Example 23-1 ASA show cts pac Output

 

bn15-asa/pri/act(config)# show cts pac
 
PAC-Info:
Valid until: Oct 29 2014 20:31:30
AID: 8ccd74a9731e0fa8305afddec90d0c9f
I-ID: bn15-asa
A-ID-Info: Identity Services Engine
PAC-type: Cisco Trustsec
PAC-Opaque:
000200b000030001000400108ccd74a9731e0fa8305afddec90d0c9f00060094000301
007915c1090d4dc78d2d85649ff9c9469200000013526ec63800093a8038a8f595501c
0137c5d6f55b67230bf77ad5d963a31a6c89d0c31c50e738e6e2fd51d2978dde577e2f
d7cef42b509cf02e937596a93d2f4995a5b080a0682745775cd6396549eaf813f5e040
a8f3413973cfc6de0dc5d1bf9535f2424d29a5c468897145cd498e8f2677a5cec82db1
f4903fd0a0
bn15-asa/pri/act(config)#
 

Now check that ASA to ISE communications has been successfully established by issuing the show cts environment-data command at the ASA. The following output should be seen.

bn15-asa/pri/act(config)# show cts environment-data
CTS Environment Data
====================
Status: Expired
Last download attempt: Failed
Environment Data Lifetime: 86400 secs
Last update time: 21:15:29 UTC Nov 7 2013
Env-data expired at: 21:15:29 UTC Nov 8 2013
Env-data refreshes in: 0:00:00:33 (dd:hr:mm:sec)
Retry timer (60 secs) is running
 
bn15-asa/pri/act(config)#
 

You can also validate that the TrustSec Environment Data and the SGT Tables have been successfully downloaded using ASDM as can be seen in Figure 23-54:

17. From ASDM go to Monitoring > Properties > Identity by TrustSec > Environment Data.

18. The Security Group names configured earlier in ISE should be present as seen in Figure 23-54.

Figure 23-54 TrustSec Environment Data at ASA

 

Configuring Security Group Tag Exchange Protocol (SXP) for Wireless Controllers, Catalyst 3850, and ASA

Campus wireless users accessing the network upon successfully matching an authorization profile at the Identity Services Engine will be associated with an SGT. Upon successful authentication and subsequent authorization to the network the Identity Services Engine will pass the appropriate SGT value to the wireless controller through a RADIUS AV. This SGT value is associated with the IP Address of the wireless user obtained through the 802.1X authentication and an IP/SGT mapping created at the wireless controller whether CT-5508, CT-5760, or Catalyst 3850.

In this deployment scenario there is no requirement to configure any links for forwarding of Security Group Tags nor MACsec. Instead SXP will be used to advertise the IP/SGT mappings created dynamically at the wireless controllers (network access devices) to the ASA configured as a Security Group Firewall (SG-FW) as well as those IP/SGT mappings statically created at the Nexus 7000 Data Center Aggregation switch. Refer to Figure 23-55.

Whereas the CT-5760 in Scenario 1 did not require SXP as it supports native tagging upon egress from the controller, SXP will be required for advertisement of the IP/SGT mappings to the ASA SG-FW as the ASA does not support native tagging and hence will use the SXP mappings when enforcing the SG-FW rules. Hence in Scenario 2, both the CT-5760 and the CT5508 will have an SXP peering established to the Catalyst 6500VSS Shared Services switch where the IP/SGT mappings will be aggreagated and the Catalyst 6500VSS Shared Services switch will then peer to the Nexus 7000 Data Center Aggregation switches, which will serve to aggregate all campus access mappings.

For campus access serviced by the Catalyst 3850, the C3850 switches will establish an SXP peering with the associated Catalyst 6500 Distribution switch and the C6500 Distribution switch will then peer to the Nexus 7000 Data Center Aggregation switches.

The Nexus 7000 Data Center Aggregation switches will have IP/SGT mappings either manually defined or dynamically created through the static VLAN/SGT mapping. All of these SGT mappings as well as those learned from both the Catalyst 6500VSS Shared Services and the Catalyst 6500 Distribution switches will be aggregated and advertised to the ASA SG-FW HA Primary.

SXP is configured on a device by identifying its peer’s IP address and specifying a password for use in authenticating each side of the connection. SXP supports two modes which can be used either exclusively or combined. The first mode is that of the “Speaker”, which as the name suggests advertises IP/SGT mappings. The other mode is “Listener”, which also as its name suggests, listens for the Speaker’s advertisements. It is possible for a device to be both a “Speaker” and a “Listener”. In this scenario, both the CT-5760 and the CT-5508 will be in speaker mode advertising the mappings they build upon wireless device access. The Catalyst 6500 VSS Shared Services and Distribution switches as well as the Nexus 7000 Data Center Aggregation switches will be in both speaker and listener mode. Finally, the ASA firewall, although capable of both modes, will only be configured for listener mode, receiving the advertisements for both wireless users and servers in the data center.

Per Figure 23-55, Table 23-7 summarizes the SXP peering that will be used in the CVD.

 

Table 23-7 SXP Peering

Device
Role
Intfc
Dst Device
Role
Intfc

CT-5760

Speaker

Lo0

Shared Svcs C6500 VSS

Listener

Lo0

CT-5508

Speaker

NA

Shared Svcs C6500 VSS

Listener

Lo0

Shared Svcs C6500 VSS

Speaker

Lo0

N7K-Agg-1

Listener

Lo0

Shared Svcs C6500 VSS

Speaker

Lo0

N7K-Agg-2

Listener

Lo0

Catalyst 3850 Access

Speaker

Lo0

Distribution C6500 VSS

Listener

Lo0

Distribution C6500 VSS

Speaker

Lo0

N7K-Agg-1

Listener

Lo0

Distribution C6500 VSS

Speaker

Lo0

N7K-Agg-2

Listener

Lo0

N7K-Agg-1

Speaker

Lo0

ASA Firewall HA Primary

Listener

Out

N7K-Agg-2

Speaker

Lo0

ASA Firewall HA Primary

Listener

Out

Figure 23-55 SXP Configuration in Deployment Scenario 2

 

CT-5508 Wireless Controller Configuration

Access the wireless controller via a web UI and follow these steps:

1. Navigate to Security > TrustSec SXP.

The screen in Figure 23-56 appears.

2. Click the drop down arrow for “SXP State” and select Enabled.

3. Set the “default Password”. This must match that configured on its peer.

4. Click New (top right).

5. Fill in the IP Address (typically Loopback if possible) of the SXP Peer or the Shared Services Catalyst 6500VSS switch.

6. Click Apply.

Once successfully configured, the screen in Figure 23-57 should be presented upon accessing Security > TrustSec SXP. The “Connection Status” will indicate “Off” until the other device is configured.

Figure 23-56 SXP Configuration at Wireless Controller

 

Figure 23-57 SXP Configuration Complete

 

CT-5760 Wireless Controller Configuration

The following is the configuration of the 5760 Wireless LAN Controller for SXP Connection to the Catalyst 6500 VSS Services switch:

cts sxp enable
cts sxp default source-ip 10.225.48.2
cts sxp default password 7 11270A0C03175A5E577E7E
cts sxp connection peer 10.225.100.5 password default mode peer listener hold-time 0
 

Issuing the command show cts sxp connection results in the following output.

bn16-wlc5760-1#show cts sxp connections
SXP : Enabled
Highest Version Supported: 4
Default Password : Set
Default Source IP: 10.225.48.2
Connection retry open period: 120 secs
Reconcile period: 120 secs
Retry open timer is not running
----------------------------------------------
Peer IP : 10.225.100.5
Source IP : 10.225.48.2
Conn status : On
Conn version : 4
Conn capability : IPv4-IPv6-Subnet
Conn hold time : 120 seconds
Local mode : SXP Speaker
Connection inst# : 1
TCP conn fd : 1
TCP conn password: default SXP password
Keepalive timer is running
Duration since last state change: 0:02:07:48 (dd:hr:mm:sec)
 
 
Total num of SXP Connections = 1

Catalyst 6500 SXP Configuration

The following commands are used at the Shared Services Catalyst 6500 VSS to enable SXP peering from the 6500 to Data Center Core:

cts sxp enable
cts sxp default source-ip 10.225.100.5
cts sxp default password 7 072132455A0C485744465E
cts sxp connection peer 10.225.43.2 password default mode peer speaker hold-time 0 0 / CT5508
cts sxp connection peer 10.225.100.8 password default mode peer listener hold-time 0 /Data center-agg1
cts sxp connection peer 10.225.100.9 password default mode peer listener hold-time 0 /Data Center Agg2
cts sxp connection peer 10.225.48.2 password default mode peer speaker hold-time 0 0 / CT 5760
 

Issuing the command show cts sxp connection results in the following output:

bn2-6500-1#show cts sxp connections
SXP : Enabled
Highest Version Supported: 4
Default Password : Set
Default Source IP: 10.225.100.51
Connection retry open period: 120 secs
Reconcile period: 120 secs
Retry open timer is not running
----------------------------------------------
Peer IP : 10.225.100.8
Source IP : 10.225.100.51
Conn status : On
Conn version : 1
Local mode : SXP Speaker
Connection inst# : 1
TCP conn fd : 1
TCP conn password: default SXP password
Duration since last state change: 8:06:51:56 (dd:hr:mm:sec)
 
----------------------------------------------
Peer IP : 10.225.100.9
Source IP : 10.225.100.51
Conn status : On
Conn version : 1
Local mode : SXP Speaker
Connection inst# : 1
TCP conn fd : 2
TCP conn password: default SXP password
Duration since last state change: 8:04:17:40 (dd:hr:mm:sec)
 
----------------------------------------------
Peer IP : 10.225.101.46
Source IP : 10.225.100.51
Conn status : On
Conn version : 4
Conn capability : IPv4-IPv6-Subnet
Conn hold time : 120 seconds
Local mode : SXP Listener
Connection inst# : 2
TCP conn fd : 4
TCP conn password: default SXP password
Hold timer is running
Duration since last state change: 1:00:13:36 (dd:hr:mm:sec)
 
----------------------------------------------
Peer IP : 10.225.101.47
Source IP : 10.225.100.51
Conn status : On
Conn version : 4
Conn capability : IPv4-IPv6-Subnet
Conn hold time : 120 seconds
Local mode : SXP Listener
Connection inst# : 1
TCP conn fd : 3
TCP conn password: default SXP password
Hold timer is running
Duration since last state change: 8:06:21:12 (dd:hr:mm:sec)
 
 
Total num of SXP Connections = 4

3850 SXP Configuration

The following commands are used at the 3850 converged access switch to enable SXP peering to the 6500 Distribution switch:

cts sxp enable
cts sxp default source-ip 10.225.102.186
cts sxp default password 7 0475180F1B241D1C5A4D50
cts sxp connection peer 10.225.100.101 password default mode peer listener hold-time 0

6500 VSS Distribution Switch

The following commands are used the 6500 VSS Distribution switch to enable SXP peering to the data center aggregation switches:

cts sxp enable
cts sxp default source-ip 10.225.100.101
cts sxp default password 7 0475180F1B241D1C5A4D50
cts sxp connection peer 10.225.100.8 password default mode peer listener hold-time 0 /Data Center Agg 1
cts sxp connection peer 10.225.100.9 password default mode peer listener hold-time 0 /Data Center Agg2
cts sxp connection peer 10.225.102.186 password default mode peer speaker hold-time 0 0 / Converged Access switch 1
cts sxp connection peer 10.225.102.197 password default mode peer speaker hold-time 0 0 / Converged Access Switch 2
cts sxp connection peer 10.225.102.187 password default mode peer speaker hold-time 0 0 / Converged Access Switch 3
 
bn5-6500-1#show cts sxp connections
SXP : Enabled
Highest Version Supported: 4
Default Password : Set
Default Source IP: 10.225.100.101
Connection retry open period: 120 secs
Reconcile period: 120 secs
Retry open timer is not running
----------------------------------------------
Peer IP : 10.225.100.8
Source IP : 10.225.100.101
Conn status : On
Conn version : 1
Local mode : SXP Speaker
Connection inst# : 1
TCP conn fd : 2
TCP conn password: default SXP password
Duration since last state change: 8:06:43:21 (dd:hr:mm:sec)
 
----------------------------------------------
Peer IP : 10.225.100.9
Source IP : 10.225.100.101
Conn status : On
Conn version : 1
Local mode : SXP Speaker
Connection inst# : 1
TCP conn fd : 1
TCP conn password: default SXP password
Duration since last state change: 8:04:31:43 (dd:hr:mm:sec)
 
----------------------------------------------
Peer IP : 10.225.102.186
Source IP : 10.225.100.101
Conn status : On
Conn version : 4
Conn capability : IPv4-IPv6-Subnet
Conn hold time : 120 seconds
Local mode : SXP Listener
Connection inst# : 1
TCP conn fd : 4
TCP conn password: default SXP password
Hold timer is running
Duration since last state change: 8:06:38:11 (dd:hr:mm:sec)
 
----------------------------------------------
Peer IP : 10.225.102.187
Source IP : 10.225.100.101
Conn status : On
Conn version : 4
Conn capability : IPv4-IPv6-Subnet
Conn hold time : 120 seconds
Local mode : SXP Listener
Connection inst# : 1
TCP conn fd : 5
TCP conn password: default SXP password
Hold timer is running
Duration since last state change: 8:06:38:10 (dd:hr:mm:sec)
 
----------------------------------------------
Peer IP : 10.225.102.197
Source IP : 10.225.100.101
Conn status : On
Conn version : 4
Conn capability : IPv4-IPv6-Subnet
Conn hold time : 120 seconds
Local mode : SXP Listener
Connection inst# : 1
TCP conn fd : 3
TCP conn password: default SXP password
Hold timer is running
Duration since last state change: 8:06:39:07 (dd:hr:mm:sec)
 
 
Total num of SXP Connections = 5
 
bn5-6500-1#

Nexus 7000 SXP Configuration

The following steps are required to configure the SXP connection between the data center aggregation switches and the ASA firewall:

cts sxp enable /Enables SXP on the Nexus 7000
cts sxp default password 7 Qomyw12345
cts sxp default source-ip 10.225.100.9 / default interface
cts sxp connection peer 10.225.48.2 password default mode speaker vrf default /c5760
cts sxp connection peer 10.225.100.5 password default mode speaker vrf default / c6500 VSS Shared Service switch
cts sxp connection peer 10.225.100.18 password default mode speaker vrf default
cts sxp connection peer 10.225.100.51 password default mode speaker vrf default /c6500 dist'n switch
cts sxp connection peer 10.225.100.101 password default mode speaker vrf default / c6500 VSS Distribution switch
cts sxp connection peer 10.230.3.4 password default mode listener vrf default /ASA Firewall
 

The interesting thing to observe above is the fact that the Nexus aggregation switch has peer relations to the C5760 Wireless LAN controller, 6500 VSS Distribution switch, and ASA Firewall. The SXP neighbor type is “Speaker” for C5760 and 6500 VSS that implies that the Nexus switch is listening to the tags, whereas the SXP neighbor relationship to ASA is “Listener” meaning that the Nexus Switch is a speaker and ASA is in the listener state.

ASA SXP Configuration

The following steps are required to configure the SXP connections between the ASA firewall and Nexus 7000 Data Center Aggregation switch and the ASA firewall and Shared Services Catalyst 6500 VSS switch. Refer to Figure 23-58.

1. Using ASDM to access the ASA firewall, navigate to Configuration > Firewall > Identity by TrustSec.

2. Check the box “Enable SGT Exchange Protocol (SXP)”.

3. Enter the Default Source IP Address the firewall will use. In the CVD, the Outside Interface is the one accessible to the Nexus 7000 and so it was chosen. Note that this IP Address must match that previously configured on the Nexus and Catalyst switches as their peer address on the firewall.

4. Configure and confirm the password to be used to establish the secure SXP connection. Note that this password must match that used to configure the SXP connection on the Nexus and Catalyst switches previously configured.

5. Click Add.

Figure 23-58 Configuring SXP on the ASA

 

The popup window in Figure 23-59 appears when Add is clicked.

Figure 23-59 Adding SXP Peers at the ASA

 

6. Enter the Peer’s IP Address. This must be the same one specified as the source interface at the Nexus or Catalyst switches.

7. For Password, select “Default” this is the password configured in Step 4 above.

8. For Mode select “Peer” from the drop down box.

9. For Role select “Speaker”. This defines the peer as a Speaker and the ASA as a Listener.

10. Add both Shared Services Catalyst 6500 VSS and Nexus 7000 Data Center Aggregation Switches as SXP Peers.

Once completed, the ASA “Identity by TrustSec” window should appear as in Figure 23-60. The two entries that were configured can now be seen in the window.

Figure 23-60 SXP Configured on ASA

 

In order to check the status of the SXP connections navigate to Monitoring > Properties > Identity by TrustSec > SXP Connections and the status of the connections can be seen as in Figure 23-61.

Figure 23-61 Checking Status of SXP at ASA

 

Configuring SG-FW Role-Based Policies at ASA

In Deployment Scenario 1 Egress Policies created at ISE were used almost exclusively for policy enforcement via SGACLs dynamically pushed to the Shared Service Catalyst 6500 VSS and Nexus 7000 Data Center Aggregation Switches in the infrastructure. When using an ASA, running v9.0(2) or higher software as a Security Group Firewall, these policies must be created on the ASA through CLI or ASDM. In order to create these role-based access policies, the SG Names and Tag Values must be first downloaded to the ASA prior to use in a policy. This is accomplished through the previous configuration steps and subsequent importing of the ISE TrustSec PAC file to be used in these exchanges competed earlier.

The table in Figure 23-62 reflects the policy that will be configured at the ASA firewall. One aspect of SG-FW configuration on the ASA is that role-based policies can be created that permit or deny communications between SGT that have been defined or Unknown (SGT 0). Additionally, on the ASA, it is possible to create policies with IP Addresses or network objects as the source or destination. This offers an extremely powerful configuration capability that is different than the Catalyst or Nexus switches where SGACLs are defined using the SGT values for source and destination without support of IP Addresses.

Very much like the Catalyst and Nexus switches as discussed in the Deployment Scenario 1 section, the ASA also supports the “Unknown” SGT value of SGT 0. A key concept to be considered when granting access to the data center is that of the SGT value of zero or “Unknown” as it is referred to. If the IP Address of a server has not been mapped to an SGT at the point of IP/SGT mappings such as the Nexus 7000 in the data center, that server would be considered Unknown and associated with SGT0. Unlike SGACLs when implemented on a switching platform where an implicit permit to Unknown is permitted, the ASA or IOS ZBFW acting as a SG-FW still enforces an implicit deny. Policies can however be created on the ASA SG-FW that permit or deny access to “Unknown” from any give source SGT. and thus can be used to support a migrational approach to tag assignment in the data center.

Between the ability to use “Unknown” and IP Addresses/Network Objects in role-based policies, the ASA offers an excellent platform supporting a migrational approach to implement TrustSec in the data center.

Figure 23-62 SG-FW Policy to be Configured on ASA Firewall

 


Note Within this CVD when discussing the specific policies enforced by the SGACLs, it will be seen that SGT10 for Employees and SGT00 or unknown are both permitted access to SGT 5. Naturally this is for demonstration purposes only as much more granular policies would be defined for network access. For example, it would be assumed that rather than providing all employees (SGT10) access to infrastructure, a group associated with network administrators would be defined and only those users would have access to SGT5 devices. In the case of unknown, it cannot be assumed that all network administrators have been migrated to the TrustSec Domain and hence once entering will be associated with SGT00 or unknown. As such other security measures would naturally be required restrict access to these devices such as ACLs or user credentials.
Also note that in the CVD, traffic between SGT 5 and 40 is permitted. This is in order to allow ISE, identified with SGT40, to be able to communicate with network devices to exchange not only TrustSec information but all AAA communications as well.
Also note from Figure 23-62 that SGT 80, which has been reserved for use with the policy static interface commands, is denied access to network infrastructure with a device SGT 5. Also with regard to SGT80 permissions, refer to TrustSec Link Policy for the rationale why SGT80 must be permitted to all other SGT values during migration.


The ASA firewall in Scenario 2 has been configured with three Layer 3 interfaces named Outside, SGT40, and SGT50. This configuration illustrates that a migration from a policy based on IP Addresses can easily be migrated to one based on SGT with only the need to add those new policies while still enforcing existing policies.

To configure role-based policies in the ASA, use ASDM as seen in Figure 23-63.

Figure 23-63 ASDM Role-based Policy Configuration

 

1. Navigate to Configuration > Firewall > Access Rules.

2. Highlight the desired interface to create the access rule on and click Add. A drop down box will open as can be seen in Figure 23-64.

3. Click Add ACL.

A popup window will open up.

4. From the Interface drop-down box, select the appropriate interface. In this example it will be the “Outside” interface as this will demonstrate the creation of a policy for user access to the data center.

5. Click the browse button next to the “Source Security Group” box.

Figure 23-64 Adding an Access Rule at the ASA

 

A popup window opens as in Figure 23-65.

6. Select the appropriate Security Name from the “Security Group” window.

7. Click Add and the selected name will populate the “Selected Security Group” box on the right.

8. Click OK.

Figure 23-65 Adding a Source Group to an Access Rule at the ASA

 

A new window will open as depicted in Figure 23-66.

9. Select the appropriate action; Permit or Deny.

10. Click the browse button next to the “Destination Security Group” box.

Figure 23-66 Adding Destination Group to Access Rule on ASA

 

A new popup window opens as in Figure 23-67.

11. Select the destination groups for the policy. In this case three groups have been selected; Server_Services_OpenAccess, Servers_Corporate, and Unknown.

12. Click Add and the selected name will populate the “Selected Security Group” box on the right.

13. Click OK.

Figure 23-67 Adding a Destination Group to an Access Rule at the ASA

 

You will be returned to the “Add Access Rule” window and can see that Source and Destination Security Group boxes have been populated as seen in Figure 23-68.

14. Click OK. You will be returned to the Access Rule main window.

15. Continue adding additional policies as appropriate.

Figure 23-68 Finalizing New Access Rule

 

Having completed the addition of all of the necessary policies, the Access Rules will appear similar to the example in Figure 23-69, as can be seen from the example below:

1. Outside Interface—SGT 10 can access Unknown, Servers_Corporate, Server_Services_OpenAccess, SGT80_Interface (Web Access), and Any. Obviously, rather than specifying the SG Names of the servers, ANY would have sufficed.

2. Outside Interface—SGT 11 can access Unknown, Servers_Corporate, Server_Services_OpenAccess, and SGT80_Interface.

3. Outside Interface—SGT 12 cannot access 10.230.4.22, which is mapped to SGT 40.

4. Outside Interface—SGT 12 can access Server_Services_OpenAccess (SGT 40) and SGT80_Interface.

5. Outside Interface—SGT12 cannot access Unknown and Servers_Corporate.

6. Outside Interface—Devices that are not associated with an SGT can get to any server. This may be undesirable and should be examined closely prior to implementing this rule. Essentially, it permits any device to access any server internally.

7. The SGT 40 Layer 3 interface has a higher priority of fifty as opposed to zero for the Outside interface, therefore an implicit permit exists for traffic sourced from SGT 40 to the Outside by default.

8. SGT 50 Interface—Cannot access SGT5 and SGT12 but can access everything else.

Figure 23-69 SG-FW Access Rules

 

In Figure 23-70, by navigating to Configuration > Firewall > Advanced > ACL Manager, the Access List names (access-groups within the CLI configs) can be seen with the associated ACEs assigned. Of particular interest is the first ACL “outside_access_in”. This is automatically created when the SXP peering is defined to allow the session be established to the outside interface.

Figure 23-70 Access Lists with Assigned ACEs

 

This completes the configuration for Deployment Scenario 2. The next steps will be to configure the actual user policies as defined in the “Limited Use Case” in the CVD for corporate devices and the “Enhanced Use Case” for personal devices.

Device On-boarding, Provisioning, Authentication, and Authorization Policies for TrustSec in ISE

The final steps for configuring the infrastructure to support role-based policy enforcement involve the configuration within ISE of the various attributes and conditions required to support:

  • On-boarding a device within the ISE policy server.
  • Provisioning the device with the appropriate configuration and credentials to access the network.
  • Defining authentication and authorization profiles granting the appropriate access to the network.

This completes the configuration for Deployment Scenario 1. If there are no requirements to configure an SG-FW as in Scenario 2, the next steps are to configure the actual user policies as defined in Chapter 16, “BYOD Limited Use Case—Corporate Devices” for corporate devices and Chapter 15, “BYOD Enhanced Use Case—Personal and Corporate Devices” for personal devices.