CCNP Security SISAS 300-208 Official Cert Guide (2015)

Part V: Advanced Secure Network Access

Chapter 18. TrustSec and MACSec

This chapter covers the following exam topics:

Describe SGA

Describe TrustSec architecture

SGT classification—dynamic/static

SGT transport—inline tagging and SXP

SGT enforcement—SGACL and SGFW

MACSec

Throughout this book, you have been exposed to many ways of controlling network access based on the context of a user and device. There is virtual local area network (VLAN) assignment, in which access is controlled at the Layer-3 edge or by isolating that VLAN into a segmented virtual network (VRFs). Additionally, there is access control list (ACL) assignment, which can be a local ACL, called into action by a RADIUS attribute, or a downloaded ACL (dACL). These ACLs are applied ingress at the switch port or at the virtual port in the case of the Wireless LAN Controller (WLC).

These are all very good access control methods, but controlling access only at the point of network ingress can leave room for a more desirable and scalable solution. In this chapter, you will learn about one such Cisco enhancement to make access control more scalable and powerful; it’s called TrustSec. This is a very confusing name to give to a solution because Cisco has redefined what TrustSec means numerous times. However, you will learn about it in the context expected for the exam, and that definition of TrustSec is a policy-defined segmentation solution that provides advanced enforcement. This was formerly referred to as security group access (SGA).

TrustSec is a natural progression on top of the IEEE 802.1AE industry standard, commonly referred to as MACSec. This standard defines a Layer-2 encryption for Ethernet environments very similar to Wi-Fi Protected Access (WPA).

This chapter focuses on the fundamentals of TrustSec and MACSec as well as showing the configuration of the many devices available for use in a TrustSec environment. Basic use cases are presented for security group ACL, and security group firewalls.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 18-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”

Table 18-1 “Do I Know This Already?” Section-to-Question Mapping

Caution

The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you do not know the answer to a question or are only partially sure of the answer, you should mark that question as wrong for purposes of the self-assessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

1. What is a security group tag?

a. A luggage tag applied by TSA workers at airports to flag bags as they enter security checkpoints

b. An internal assignment used in ISE to represent a local copy of an Active Directory group

c. A 16-bit value that represents the context of a user and/or a device

d. An RFID tag used to identify a wireless asset to ISE

2. Where are security groups defined in the ISE administrative GUI?

a. Administration > System > Security Group Access > Security Group

b. Policy > Policy Elements > Results > Security Group Access

c. Policy > Policy Elements > Dictionaries > System > Security Group Access

d. Policy > Firewall > Identity by TrustSec

3. What are three ways that an SGT can be assigned to network traffic?

a. Manual binding of the IP address to an SGT

b. Manually configured on the switch port

c. Dynamically assigned by the network access device

d. Dynamically assigned by the 802.1X authorization result

e. Manually configured in the NAC agent profile

f. Dynamically assigned by the AnyConnect network access manager

4. True or False? An SGT-capable device can automatically map traffic to an SGT based on the VLAN of that traffic.

a. True

b. False

5. Which peering protocol can be used to transmit a mapping of IP address to SGTs between SGT-capable devices when traffic is crossing non-SGT-capable network segments?

a. Enhanced Interior Gateway Routing Protocol (EIGRP)

b. Intermediate System—Intermediate System (IS-IS)

c. Border Gateway Protocol (BGP)

d. Security Group Exchange Protocol (SXP)

6. What are two modes of SXP peers?

a. Speaker

b. SGT-Reflector

c. Listener

d. SGT-Sender

7. How is the SGT transmitted when using native tagging?

a. The SGT is included in the Cisco Metadata (CMD) portion of the Layer-2 Frame.

b. The SGT is included in 802.1Q trunking.

c. The SGT is included in Inter-Switch-Link (ISL) trunking.

d. The SGT is carried in Cisco Discovery Protocol (CDP) messages.

8. When using native tagging of SGTs, how can an administrator ensure confidentiality and integrity of the tag?

a. By enabling MD5 authentication between SGT peers

b. By enabling IEEE 802.1AE (MACSec) between the switches

c. By enabling IEEE 802.1AE (MACSec) between the endpoint and the access switch

d. By configuring peer-to-peer GRE tunnels between the switches

9. What are two methods of enforcement with SGTs?

a. SG-ACLs on switches.

b. SG-ACLs on routers.

c. SG-Firewalls.

d. SG-Appliances.

e. SGTs are not enforced.

10. What is the difference between uplink MACSec and downlink MACSec?

a. Uplink MACSec defines the encrypted traffic entering the switch from the endpoint, whereas downlink MACSec is the encrypted traffic leaving the switch, destined to the endpoint itself.

b. There is no difference between uplink and downlink MACSec.

c. The difference is solely based on the encryption algorithm used.

d. Uplink MACSec defines the encrypted connection between network infrastructure components, whereas downlink MACSec defines the encrypted connection between the access layer device and the endpoint.

Foundation Topics

Ingress Access Control Challenges

VLAN assignment and downloadable ACLs (dACLs) are fantastic ways of controlling access to a network. However, when a network grows, so do the challenges of keeping up with the ingress access controls. Let’s take a look at each one of these standard use cases individually and discuss the challenges.

VLAN Assignment

VLAN assignment based on the context of a user or device is a common way to control access to the network. Let’s use a hypothetical scenario of controlling access to servers that contain credit card data, which falls under the realm of Payment Card Industry (PCI) regulatory compliance:

1. A user is a member of the Retail-Managers group in Active Directory.

2. The posture of the system is compliant.

3. Therefore, ISE assigns the user into the PCI-Allowed VLAN on the switch or WLC. To use that VLAN assignment to control access to the servers that house that PCI data, an ACL must be applied somewhere. Let’s assume the ACL is applied at a firewall between the campus/branch networks and the data center.

4. The ACL on the data center firewall must be updated to include all the source IP addresses of PCI-Allowed VLANs throughout the entire network infrastructure.

Figure 18-1 illustrates the concept of VLAN-based access control on a single switch.

Figure 18-1 Controlling access with VLANs on a single switch.

Next, the company has decided to control access to the HR server, so that only members of the HR Department can talk to HR servers. Another set of rules must be built that assign the HR VLAN and another set of entries in the access list. Figure 18-2 illustrates the concept of controlling access with two VLANs on a single switch.

Figure 18-2 Controlling access with two VLANs on a single switch.

Now, consider how this can scale as we continue to add VLANs and add switches and WLCs to the equation. One customer that the author works with has more than 50,000 switches in their access layer. That is a tremendous number of VLANs to create and addresses to maintain in an access list on a firewall. That same customer had 15 full-time employees managing the firewall rules. They needed to find some better mechanism to control access that would lower their OPEX tremendously.

What if you had 100 remote sites? That would mean 100 new IP subnets, and that can easily modify your existing route summarization strategy. When that is the case, the route summarization alone can cause a network redesign, which will add even more operational cost. Figure 18-3illustrates the growing complexity as the network grows.

Figure 18-3 VLAN control can be operationally expensive.

There is a formula to determine the number of access control entries (ACEs) in an access control List (ACL). The formula takes the number of sources multiplied by the number of destinations multiplied by the permissions of the ACL:

(# of sources) * (# of destinations) * permissions = # of ACEs

So, with the environment depicted in Figure 18-3—only 4 sources * 2 destinations * 4 permissions—we would need 32 ACEs. This is obviously just a small example, and we will examine more in the following sections of this chapter.

Ingress Access Control Lists

Another way to control access is to use ACLs applied ingress (inbound) at the port (or virtual port) that the user or device is using to access the network. This could be locally defined ACLs that are called by using the filter-id RADIUS attribute, or they could be dACLs where the entire ACL is defined on ISE and downloaded to the port. On the WLC, Airespace ACL is also a viable option.

Obviously, dACLs provide a better operational model because there is only one place to update an ACL when a change needs to be made. Additionally, the number of ACEs required is lower when applying the ACL to a switchport than it would be to apply the ACL to a centralized location. This is because the ACL is being applied at the point of ingress, so there would be only a single source IP address (theoretically). Cisco switches will perform source-substitution on these ACLs to make it even easier. With source-substitution, the “any” keyword in the source field of an ACL is replaced with the actual IP address of the host on the switchport.

Using the same formula for 6 destinations and 4 permissions, we would have:

1 source * 6 destinations * 4 permissions = 24 ACEs

However, there are a few complications with using ACLs on access layer devices. Two major complications that exist are the regular maintenance of the ACLs and the size of the ACLs.

If ACLs are being used to explicitly defend hosts, they must be updated regularly for all new destinations that get added to the network. This can cause an exorbitant amount of operational expense maintaining the lists and ensuring they get updated correctly. Additionally, there is a limited number of ACEs that a switch will be able to apply.

ACLs get loaded into and executed from Ternary CAM (TCAM). Access layer switches have a limited amount of TCAM, which is usually assigned per ASIC. Therefore, the number of ACEs that can be loaded depends on a number of factors, such as the number of hosts per ASIC and the amount of free TCAM space.

Due to that limited amount of TCAM, ACLs cannot be overly large, especially when the access layer can be a mixture of different switches, with each switch having a different level of TCAM per ASIC. The best practice recommendation is to keep the ACEs at fewer than 64 per dACL. This might need to be adjusted for your specific environment, but it is a good place to start. On WLCs, the maximum configurable limit is 64 ACLs with a maximum of 64 ACEs per ACL. Figure 18-4 illustrates the concept of ingress ACLs.

Figure 18-4 Ingress ACLs.

What Is TrustSec?

TrustSec, also known as security group access (SGA), is a next-generation access control enforcement and segmentation technology that was created to address the growing operational expenses with maintaining firewall rules and access lists. SGA is a complimentary enforcement technology that removes the concerns of TCAM space and ACE explosion.

The ultimate goal of TrustSec is to assign a tag, known as a security group tag (SGT), to the user’s or device’s traffic at ingress (inbound into the network) and then enforce the access elsewhere in the infrastructure (in the data center, for example). So, SGA assigns a tag at login and enforces that tag elsewhere in the network (egress enforcement). To be clear, this enforcement happens at the egress of the first SGT-enabled device—not the egress point closest to the destination. Therefore, this approach should not create any unnecessary load on the upstream network for traffic that will be dropped.

The SGT should be representative of some overarching role(s) within the company. For instance, an SGT can be assigned to a GUEST user so that GUEST traffic can be isolated from non-GUEST traffic throughout the infrastructure. Here is a list of some common security groups:

Network Infrastructure—This SGT gets assigned to all the switches, routers, WLCs, and firewalls within the organization. This ensures that any management protocols are not impacted by the enforcement of SGT.

Network Services—This SGT is assigned to the servers providing common services that most everyone should be able to reach (DNS, DHCP, NTP, and so on). As noted previously, this ensures that these critical protocols are not impacted by upstream SGT enforcement.

Executive—Many organizations might classify their executives into their own SGT, simply to ensure that executives will never be denied access to anything.

Sales—For the sales force because they are users who might need specific access to customer account management information.

Finance—For the bean counters. These users might require access to payroll, asset management, and profit information—information that others do not require access to.

HR—For the group of employees who have access to your personal and financial data.

Line-of-Business-1—SGTs often are used when an umbrella company has many different lines of business and those lines of business cannot have access to each other’s data.

Line-of-Business-2—This is the same as the previous one.

The trick with SGTs is to use them for bulk access control and do your fine-grain access control within the application security itself. Additionally, each end user or end device may be assigned only a single SGT. So, you do not want to create too many roles; otherwise, you will spend too much time trying to figure out all the permutations and will lose the value of TrustSec.

What Is a Security Group Tag?

A security group tag is a 16-bit value that ISE assigns to the user’s or endpoint’s session upon login. The network infrastructure views the SGT as another attribute to assign to the session and will insert the Layer-2 tag to all traffic from that session. The SGT also can be manually assigned or mapped from the source VLAN. The SGT can represent the context of the user and device. Let’s look at an example.

The following is one of my favorite examples from a customer I worked with directly. The customer is a retail organization and therefore accepts credit cards from their customers, which places them under the domain of PCI compliance. Access to any server housing credit card data must be protected as strictly as any technology will allow.

In this customer’s case, we defined a rule in ISE that looked for machine and user authentication (EAP-Chaining) AND verified that the user was a member of a PCI group in Active Directory AND that the machine’s posture was compliant. If the user and machine met all these conditions, an SGT named PCI was assigned. No access was granted to PCI servers without the PCI SGT.

So, as you can see, SGTs can be applied based on the full context of the authentication or simply based on a single condition, such as Guest.

Note

The endpoint itself is not aware of the tag. It is known in the network infrastructure.

Figure 18-5 and Figure 18-6 show the assignment of an SGT to an authentication session on a Cisco switch and Cisco WLC, respectively.

Figure 18-5 SGT applied to session on a switch.

Figure 18-6 SGT applied to session on a WLC.

Defining the SGTs

ISE serves as the single-source-of-truth for which SGTs exist, and ISE considers an SGT a policy result. Therefore, you will create one SGT result for each SGT you want to define in the environment.

Create the SGTs in ISE by doing the following from within the ISE GUI:

Step 1. Navigate to Policy > Policy Elements > Results.

Step 2. Select Security Group Access > Security Groups.

Figure 18-7 shows the Security Groups list. Notice the default is a SGT of 0, “unknown.” This is the tag that will be used if traffic arrives that is untagged. In other words, even the lack of an SGT can be used in the security policy.

Figure 18-7 Security groups.

Now you are adding new security groups to be used in your network infrastructure. You begin by creating a security group for network access devices:

Step 3. Click Add.

Step 4. Name the new SGT NADs.

Figure 18-8 shows the adding of a new SGT for the NADs. Notice in the figure that the SGT value is predetermined. ISE 1.2 automatically assigns the value from 2 to 65535. Automatic assignment can be disabled for more manual control over tag values.

Figure 18-8 Adding a security group for NADs.

Step 5. Click Submit to save.

It is considered a best practice to also have a security group for all the common network services that will exist on a network. These are services that should always be accessible by any device, such as DNS and DHCP.

Step 6. Click Add.

Step 7. Name the new group CommonServices.

Step 8. Click Submit to save.

Step 9. Repeat Steps 6-8 until you have the security groups created for your organization’s security policy.

Figure 18-9 shows a sample set of security groups.

Figure 18-9 Sample security groups.

Classification

To use SGTs within your network infrastructure, your network devices must support SGTs. All Secure Access-supported Cisco switches and wireless controllers do support the assignment of the SGT. The assignment of an SGT to an authentication session is defined as classification. The process of communicating that assigned SGT upstream into the network can occur via either native tagging or a peering-protocol; this process is defined as Transport or Propagation.

Figure 18-10 shows an example of one access switch that has native tagging, with the packets getting tagged on the uplink port, and through the infrastructure. It also shows a switch that is not native tagging capable; it uses a peering protocol to update the upstream switch. In both cases, the upstream switch continues to tag the traffic throughout the infrastructure.

Figure 18-10 Security group tagging.

To use the SGT, the tag must be assigned (classification). This can happen dynamically and be downloaded as the result of an ISE authorization. Tags also can be assigned manually at the port level or even mapped to IP addresses and downloaded to SGT-capable devices.

Dynamically Assigning SGT via 802.1X

Assigning a tag is as simple as adding it as another permission or result of an authorization in an authorization policy. From the ISE GUI, do the following:

Step 1. Navigate to Policy > Authorization.

Step 2. Edit an existing authorization rule.

Step 3. Click the plus (+) sign under Permissions.

Step 4. Click the plus (+) sign next to the Authorization Profile.

Step 5. Select Security Group.

Step 6. Select the appropriate security group to apply.

Figure 18-11 shows some of the authorization rules using both a standard authorization profile result and a security group tag. The two results are concatenated with the AND operator. The tag is deployed only to devices that are SGA capable, as provided in the Administration -> Network Resources -> Network Devices configuration for the NAD. Otherwise, the standard authorization profile policy is deployed to the NAD on behalf of the endpoint.

Figure 18-11 Authorization rules with SGT assignment.

Manually Assigning SGT at the Port

In most cases, 802.1X will not be used in the data center. Servers are not usually required to authenticate themselves to the data center switch because the data center is normally considered physically secure and no network access control is applied there. However, the servers themselves will be the destination of traffic coming from the campus and from within the data center itself.

Because 802.1X is not typically used in the data center, we need a manual way to apply the SGT. This is configured at the interface level of the Nexus configuration and is manually applied to the port itself. Example 18-1 shows the assignment of an SGT tag to a switch port.

Example 18-1 Static SGT Assignment

NX7K-DIST(config)# int eth1/3
NX7K-DIST(config-if)# cts manual
NX7K-DIST(config-if-cts-manual)# policy static sgt 0x3

Example 18-1 has manually assigned the SGT “3” to the port on the Nexus 7000. This is also available on the Nexus 5000 and 1000v.

Manually Binding IP Addresses to SGTs

As an alternative to assigning the SGT to the port itself, ISE has the ability to centrally configure a database of IP addresses and their corresponding SGTs, and then SGT-capable devices can download that list from ISE.

From the ISE GUI, do the following:

Step 1. Navigate to Policy > Policy Elements > Results > Security Group Access > Security Group Mappings.

Step 2. Click Add.

Step 3. Select the appropriate SGT from the drop-down list.

Step 4. Enter the IP address or DNS name of the host.

Step 5. Click Submit to save.

Figure 18-12 illustrates an example of mapping a server IP address to an SGT named PCI.

Figure 18-12 Mapping an SGT to an IP address in ISE.

Repeat Steps 2-5 for any other static IP-to-SGT mappings required for your organization. Figure 18-13 shows the security group mappings screen with multiple mappings.

Figure 18-13 Mappings screen with multiple SGT-to-IP mappings.

Now that the mappings exist on ISE, other devices will be able to download them, such as a Nexus 7000 data center switch.

Access Layer Devices That Do Not Support SGTs

Because we do not live in a perfect world, and not all the equipment on the network will be the latest and greatest, we need another way to classify the endpoint traffic. One example is an older Cisco WLC (such as the 4400) that does not support version 7.2 or newer and therefore cannot accept the SGT classification from ISE, nor send the update via SXP.

Additionally, this could be a VPN concentrator or some third-party equipment that found its way into the deployment. Although that gear might not support the classification and transport natively, it might be capable of assigning different VLANs or IP addresses per authorization result.

With the many distribution layer devices, you have the ability to map subnets and VLANs and assign all source IP addresses from the subnet or VLAN to a specific tag.

Mapping a Subnet to an SGT

The cts role-based sgt-map [ipv4-subnet | ipv6-subnet] sgt tag-value command enables the subnet to SGT binding. When used, the IP device tracking feature in the switch identifies matches and assigns the SGT. Example 18-2 shows the use of the cts role-based sgt-map command.

Example 18-2 cts role-based sgt-map for Subnets

C6K-DIST(config)#cts role-based sgt-map 192.168.26.0/24 sgt 4

Mapping a VLAN to an SGT

The cts role-based sgt-map vlan-list vlans sgt tag-value command enables the VLAN-to-SGT binding. When used, the IP device tracking feature in the switch identifies matches and assigns the SGT. Example 18-3 shows the mapping of a VLAN list to an SGT.

Example 18-3 cts role-based sgt-map for VLAN Lists

C6K-DIST(config)#cts role-based sgt-map vlan-list 40 sgt 4

Transport: Security Group Exchange Protocol

In a perfect world, all your access layer devices would support tagging the users’ traffic natively. As we do not live in a perfect world, not all devices support native tagging. However, all supported Cisco switches support the assignment of the SGT to the authentication session (known as classification).

Cisco has developed a peering protocol (similar to BGP or LDP) to enable devices to communicate their database of IP address-to-SGT mappings to one another. This peering protocol is called Security Group Exchange Protocol (SXP). Because this is a peering protocol, it is possible to be very specific and deterministic as to which devices send updates and which ones receive updates.

An SXP peer can be a speaker or a listener. A speaker is a device that sends the IP address-to-SGT bindings. A listener is a device that receives the bindings.

SXP Design

SXP uses TCP as its transport, so the peers can be Layer-2 adjacent or multiple hops away. A network device can peer to an upstream switch for tag propagation or even peer directly to the enforcement device (the data center switch or security group firewall). Figure 18-14 illustrates the concept of SXP peering.

Figure 18-14 SXP peering.

Routing protocols have a limitation for the number of neighbors they can scale to, and so does SXP. Due to the limitations of scale for the number of peers, SXP design can be architected to be multi-hop, which allows for aggregation points. Devices such as the Catalyst 6500 with a Supervisor 2T engine or the Aggregation Services Router (ASR) are solid choices for SXP aggregation. Figure 18-15 illustrates the multi-hop SXP concept.

Figure 18-15 SXP multi-hop.

There are numerous benefits to this design. Not only does it not require SXP-aware infrastructure along every hop in the network path, but it also provides a deterministic scalable design.

Configuring SXP on IOS Devices

From global configuration, you must enable SXP globally. Each peer will need to be added individually, as well as have a global default SXP password set. Follow these steps:

Step 1. Enter cts sxp enable.

Step 2. Enter cts sxp connection peer [peer-ip-address] password [default | none] mode [local | peer] [listener | speaker].

This command is used to define the SXP peer. The options are as follows:

password default—This states to use the password defined globally for all SXP connections. At the current time, it is not possible to have different SXP passwords per peer.

password none—Do not use a password with this SXP peer.

mode local—This states that the following SXP argument is defining the local side of the connection.

mode peer—This states that the following SXP argument is defining the peer’s side of the connection.

listener—Defines that the specified device (local or peer) will receive SXP updates through this connection.

speaker—Defines that the specified device (local or peer) will send SXP updates through this connection.

Step 3. (optional) cts sxp default password password.

Step 3 is an optional step for when your connections will use the globally defined password instead of no password.

Examples 18-4 and 18-5 display the steps for setting up the SXP connection between a 4500 (an access layer device that does not support native tagging) and a 6500 with a Supervisor 2T (a distribution layer device that supports native tagging). Figure 18-16 illustrates the connection.

Figure 18-16 SXP between 4500 and 6500.

Example 18-4 Enabling SXP on the 4500

4503(config)#cts sxp enable
4503(config)#
*Aug 9 06:51:04.000: %CTS-5-SXP_STATE_CHANGE: CTS SXP enabled
4503(config)#cts sxp connection peer 10.1.40.1 password default mode peer listener
4503(config)#
*Aug 10 09:15:15.564: %CTS-6-SXP_TIMER_START: Connection <0.0.0.0, 0.0.0.0> retry
open timer started.
*Aug 10 09:15:15.565: %CTS-6-SXP_CONN_STATE_CHG: Connection <10.1.40.1,
10.1.40.2>-1 state changed from Off to Pending_On.
4503(config)#
*Aug 10 09:15:15.566: %CTS-3-SXP_CONN_STATE_CHG_OFF: Connection <10.1.40.1,
10.1.40.2>-1 state changed from Pending_On to Off.
4503(config)#cts sxp default password TrustSec123
4503(config)#
*Aug 10 09:17:20.936: %CTS-5-SXP_DFT_PASSWORD_CHANGE: CTS SXP password changed.

Example 18-5 Enabling SXP on the 6500

C6K-DIST(config)#cts sxp enable
C6K-DIST(config)#
Aug 10 16:16:25.719: %CTS-6-SXP_TIMER_START: Connection <0.0.0.0, 0.0.0.0> retry
open timer started.
C6K-DIST(config)#cts sxp default password TrustSec123
C6K-DIST(config)#cts sxp connection peer 10.1.40.2 password default mode peer
speaker
C6K-DIST(config)#
Aug 10 16:17:26.687: %CTS-6-SXP_CONN_STATE_CHG: Connection <10.1.40.2, 10.1.40.1>-1
state changed from Off to Pending_On.
Aug 10 16:17:26.687: %CTS-6-SXP_CONN_STATE_CHG: Connection <10.1.40.2, 10.1.40.1>-1
state changed from Pending_On to On.

Configuring SXP on Wireless LAN Controllers

Cisco’s WLC added support for SGT classification and SXP transport beginning with the 7.2 release.

From the WLC user interface, do the following:

Step 1. Using the top menu navigation, select Security.

Step 2. Along the left side, select TrustSec SXP (second from the bottom).

Configure the settings on this page to be:

SXP State = Enabled

Default Password = the same default password you configured on the switches (all passwords in the SXP “domain” will need to be the same)

This has enabled SXP globally. Each peer will need to be added individually. To add a new SXP peer (a listener), follow these steps:

Step 3. Click New (in the upper-right corner).

Step 4. Enter the IP address of the listener peer.

Step 5. Click Apply (in the upper-right corner).

The added peers will be displayed on the TrustSec SXP page. Their statuses will be listed next to their IP addresses. After the peer is configured on the other side, the status should change from off to on.

Figure 18-17 displays a completed TrustSec SXP page.

Figure 18-17 TrustSec SXP page—peer status.

You also can verify the SXP connection from the other side, as shown in Example 18-6.

Example 18-6 Verifying the Connection Between the WLC and 6500

C6K-DIST#sho cts sxp connections brief
SXP : Enabled
Default Password : Set
Default Source IP: Not Set
Connection retry open period: 120 secs
Reconcile period: 120 secs
Retry open timer is not running

-----------------------------------------------------------------------------
Peer_IP Source_IP Conn Status Duration
-----------------------------------------------------------------------------
10.1.40.2 10.1.40.1 On 4:06:36:24 (dd:hr:mm:sec)
10.1.60.2 10.1.60.1 On 0:00:03:31 (dd:hr:mm:sec)

Total num of SXP Connections = 2

Configuring SXP on Cisco ASA

The Cisco Adaptive Security Appliance (ASA) has support for SGT enforcement (known commonly as SG firewall). Certain models of the ASA have added support for native tagging with version 9.3 and newer, but SXP is the most common method used for the transport of IP-to-TAG bindings, and it is the solution covered by the exam objectives.

It is important to note that the ASA has multiple functions. These functions include deep packet inspection firewalling and remote access VPN (among many others). ASA version 9.2.1 and newer enforce SGTs, receive SGTs (transport), and assign SGTs to remote access VPN users (classification).

From the ASA Device Manager (ASDM), do the following:

Step 1. Navigate to Configuration > Firewall > Identity by TrustSec.

Step 2. Globally enable SXP by checking the Enable SGT Exchange Protocol (SXP) check box in the upper-left corner.

Step 3. Click Add to add a new SXP peer.

Step 4. In the Add Connection Peer pop-up window, add the IP address of the remote peer.

Step 5. Select Default for the Password (unless you will not be using passwords).

Step 6. Set the mode to Peer.

Step 7. Set the role to Speaker.

Step 8. Click OK.

After clicking OK, you are returned to the main identity by TrustSec page. At this point, you will have SXP enabled and a single peer defined, but no default password yet.

Step 9. (optional) If you will be specifying the source IP address of the ASA, you can configure that source in the Default Source field.

Step 10. Enter the default password for your entire SXP deployment.

Figure 18-18 shows the SXP connections on the ASA via the ASDM management GUI.

Figure 18-18 SXP connections in ASDM.

Verifying SXP Connections in ASDM

Verifying SXP connections in ASDM is accomplished through Monitoring > Properties > Identity by TrustSec pages.

From ASDM, follow these steps:

Step 1. Navigate to Monitoring > Properties > Identity by TrustSec.

Step 2. Click SXP Connections to see the configured peers and their statuses, as shown in Figure 18-19.

Figure 18-19 Monitoring SXP connections in ASDM.

Step 3. Click IP Mappings to see any IP address-to-SGT mappings that the ASA has learned about, as shown in Figure 18-20.

Figure 18-20 Monitoring IP address to SGT mappings in ASDM.

Transport: Native Tagging

Native tagging is the ultimate goal with any TrustSec deployment. With this approach, the access layer is capable of applying the SGT to the Layer-2 frame as it is sent across the wire to the upstream host. The upstream host will continue that and ensure the tag is applied as the traffic is sent out the egress interface toward the next hop and so on; this way, the tag is always present throughout the entire infrastructure.

Figure 18-21 shows the format of the Layer-2 frame, with the SGT value that exists within the Cisco CMD field circled.

Figure 18-21 Layer-2 frame format with SGT.

Native tagging enables the technology to scale to virtually endless size, and it remains completely independent of any Layer-3 protocol. In other words, architecturally speaking, it does not matter if the traffic is IPv4 or IPv6. The tag is completely independent. Figure 18-22 illustrates the pervasive tagging concept.

Figure 18-22 Pervasive tagging.

As you can see in Figure 18-22, when native tags are supported pervasively within the infrastructure, the SGT is communicated hop-by-hop. This provides for end-to-end segmentation and tremendous scale. With the tag being applied to the traffic at every Layer-2 link, you are able to enforce policy at any point in the infrastructure and there are no limitations to the size of an IP-to-SGT mapping database because the mapping database is not being used at all.

For added security, the tag can be encrypted with MACSec or IPSec and the network infrastructure can be authenticated prior to sending or receiving Tags.

Configuring Native SGT Propagation (Tagging)

The next few configuration exercises show the enabling of native security group tagging on three types of switches: a 3750 series access layer switch, a 6500 series distribution layer switch, and Nexus data center switches. Figure 18-23 shows the logical network layout used in the configuration examples to follow.

Figure 18-23 SGTs from access to distribution and distribution to data center.

Configuring SGT Propagation on Cisco IOS Switches

This section discusses the configuration of SGT propagation on access layer switches such as the 3560-X and 3750-X that have the capability to use native tags. The Catalyst 6500 and Nexus series switches are covered in the following sections.

When it comes to inserting the tag into Layer-2 traffic, there is a fundamental choice to make: to use encryption or not to use encryption. For simplicity, let’s focus on the easy one: without encryption. Encrypting the tag is discussed more the section “MACSec.”

From global configuration, do the following:

Step 1. Enter the cts role-based enforcement command.

This will globally enable the tagging of SGTs. It also enables the ability to enforce SGACLs (discussed in a future section). However, without this command in the global configuration, the switch will not tag the Layer-2 traffic.

Step 2. Enter into interface configuration mode of the tagging-capable port by typing interface interface-name.

Step 3. Enter the cts manual command.

We are using cts manual because we are not utilizing NDAC at this point. The cts manual mode of operation enables us to apply the tag to the Layer-2 frame without needing to negotiate encryption or requiring a fully trusted domain of Cisco switches (such as we would need with NDAC).

Step 4. Enter the policy static sgt sgt-value trusted command.

When we created our security groups earlier in this chapter, we created a special group for NADs. We called that security group “NADs” and the value of that group was 2 (0x02). That is the value we are applying here with this policy static sgt 2 trusted command. The trusted keyword in this command ensures that no changes are made to the incoming tags because they are from a trusted source.

Example 18-7 shows the enabling of tagging on a 3750-X, and Example 18-8 shows how to verify the tagging.

Example 18-7 Enabling Tagging on a 3750-X Series Access Switch

C3750X(config)#cts role-based enforcement
C3750X(config)#interface Ten 1/1/1
C3750X(config-if)#cts manual
C3750X(config-if-cts-manual)#policy static sgt 2 trusted

Example 18-8 Verifying Tagging on a 3750-X Series Access Switch

C3750X#sho cts interface Ten 1/1/1
Global Dot1x feature is Enabled
Interface TenGigabitEthernet1/1/1:
CTS is enabled, mode: MANUAL
IFC state: OPEN
Authentication Status: NOT APPLICABLE
Peer identity: "unknown"
Peer's advertised capabilities: ""
Authorization Status: SUCCEEDED
Peer SGT: 2
Peer SGT assignment: Trusted
SAP Status: NOT APPLICABLE
Configured pairwise ciphers:
gcm-encrypt
null

Replay protection: enabled
Replay protection mode: STRICT

Selected cipher:

Propagate SGT: Enabled
Cache Info:
Cache applied to link : NONE

Statistics:
authc success: 0
authc reject: 0
authc failure: 0
authc no response: 0
authc logoff: 0
sap success: 0
sap fail: 0
authz success: 3
authz fail: 0
port auth fail: 0

L3 IPM: disabled.

Configuring SGT Propagation on a Catalyst 6500

The Catalyst 6500 is a special case. This switch is sometimes used in the access layer, but it’s most often used in the distribution layer or even in the data center. There are also a tremendous number of line cards possible for this chassis-based switch, some of which can support native tagging and some of which cannot. Due to the possibility of multiple locations and multiple line card possibilities, the Catalyst 6500 requires the administrator to set whether the switch should be used for egress (receiving the tag from other devices) or ingress, which would place it at the access layer. These modes are referred to as reflector modes.

Note

This switch is unable to be configured for both ingress and egress mode simultaneously.

Ingress reflector mode should be used only in the access layer. This mode allows the use of non-SGA-capable line cards along with an SGA-capable supervisor. (An example of this would be a Catalyst 6504-E chassis populated with a Supervisor 2T and a 6148 series line card.) With this mode, all packet forwarding occurs on the Supervisor 2T PFC. Line cards that use distributed forwarding are not supported in ingress reflector mode (such as the 6748-GE-TX).

With this mode of operation, ISE is able to assign an SGT to a device entering the access layer via any supported line card, but that tag is applied only to network traffic leaving one of the ports physically on the Supervisor 2T. In other words, the switch can apply the tag on an uplink port, but not any of the downlink ports. Additionally, the switch will not be able to read the incoming tag on any ports except the ones physically on the Supervisor 2T module itself.

Egress reflector mode is normally associated with the 6500 being deployed in the distribution layer or data center. With this mode, SGA propagation and encryption (MACSec) can be enabled on the Supervisor 2T and 6900 series line cards. These are the model of line card most often seen in the distribution layer, and as such, this provides for a nice SGA aggregation design. The switch will be able to read all incoming SGT tagged packets and apply that tag to the traffic leaving the switch as well. This is the model of security group tagging that one normally thinks of when discussing the topic. Additionally, if the Catalyst 6500 is a SXP peer, it is capable of applying the SGT to Layer-2 traffic based on the IP to SGT bindings learned via SXP.

From global configuration on the Catalyast 6500, do the following:

Step 1. Select the CTS reflector mode by typing platform cts {egress | ingress}.

Because this is a distribution layer deployment of the Catalyst 6500, choose egress mode. If this were an access layer deployment, where end users would be authenticated, then you would have chosen ingress mode.

Step 2. Enter cts role-based enforcement.

Step 3. Enter into interface configuration mode of the tagging-capable port by typing interface interface-name.

Step 4. Enter cts manual.

We are using cts manual because we are not utilizing NDAC at this point. The cts manual mode of operation enables us to apply the tag to the Layer-2 frame, without needing to negotiate encryption or requiring a fully trusted domain of Cisco switches (such as we would need with NDAC).

Step 5. Enter policy static sgt sgt-value trusted.

When we created our security groups earlier in this chapter, we created a special group for network access devices. We called that security group “NADs,” and the value of that group was 2 (0x02). That is the value we are applying here with this policy static sgt 2 trustedcommand. The trusted keyword in this command ensures that no changes are made to the incoming tags, as they are from a trusted source.

Example 18-9 Enabling Tagging on Catalyst 6500 Supervisor 2T

C6K-DIST(config)#platform cts egress
C6K-DIST(config)#cts role-based enforcement
C6K-DIST(config)#interface Ten1/5
C6K-DIST(config-if)#cts manual
C6K-DIST(config-if-cts-manual)#policy static sgt 2 trusted

Example 18-10 Verifying Tagging on the Catalyst 6500 Supervisor 2T

C6K-DIST#show cts interface Ten1/5
Global Dot1x feature is Enabled
Interface TenGigabitEthernet1/5:
CTS is enabled, mode: MANUAL
IFC state: OPEN
Authentication Status: NOT APPLICABLE
Peer identity: "unknown"
Peer's advertised capabilities: ""
Authorization Status: SUCCEEDED
Peer SGT: 2
Peer SGT assignment: Trusted
SAP Status: NOT APPLICABLE
Configured pairwise ciphers:
gcm-encrypt
null

Replay protection: enabled
Replay protection mode: STRICT

Selected cipher:

Propagate SGT: Enabled
Cache Info:
Cache applied to link : NONE
Statistics:
authc success: 0
authc reject: 0
authc failure: 0
authc no response: 0
authc logoff: 0
sap success: 0
sap fail: 0
authz success: 1
authz fail: 0
port auth fail: 0

L3 IPM: disabled.

Configuring SGT Propagation on a Nexus Series Switch

You’ve just configured the SGT propagation on the access and distribution layers. Now you will enable the propagation on the data center switch.

From global configuration on the Nexus Series switch, do the following:

Step 1. Type feature dot1x at global configuration mode.

The Nexus Series requires the feature dot1x to be enabled before enabling CTS features.

Step 2. Type cts enable at global configuration mode.

This command enables security group access and MACSec and NDAC features to be enabled and configured.

Step 3. Enter cts role-based enforcement.

Step 4. Enter into interface configuration mode of the tagging-capable port by typing interface interface-name

Step 5. Enter cts manual.

Step 6. Enter policy static sgt sgt-value trusted.

Example 18-11 Enabling Tagging on Nexus 7000

NX7K-CORE(config)# feature dot1x
NX7K-CORE(config)# cts enable
NX7K-CORE(config)# cts role-based enforcement
NX7K-CORE(config)# int eth1/26
NX7K-CORE(config-if)# cts manual
NX7K-CORE(config-if-cts-manual)# policy static sgt 0x2 trusted

Enforcement

Now that we have security groups being assigned (classification) and they are being transmitted across the network (transportation), it is time to focus on the third staple of security group access: enforcement.

There are multiple ways to enforce traffic based on the tag, but ultimately, we can summarize them into two major types:

Enforcement on a switch (SGACL)

Enforcement on a firewall (SG-FW)

SGACL

Historically, enforcement with SGACL was the only option available. It started with the Nexus 7000 Series and has expanded to the many additional switches. A major benefit to SGACL usage is the consolidation of access control entries (ACEs) and the operational savings involved with maintenance of those traditional access lists.

An SGACL can be visualized in a format similar to a spreadsheet. It is always based on a source tag to a destination tag. Figure 18-24 shows an example SGACL policy on ISE, which represents the SGACLs in a columns-and-rows presentation.

Figure 18-24 SGACL egress policy: matrix view.

The box that is highlighted in gray shows that any traffic with a source of the Employee SGT (6) attempts to reach a destination with the HR SGT (5), an SGACL named Permit_WEB will be applied along with a catch-all of Deny IP. The contents of the Permit_WEB ACL are displayed in Figure 18-25, where you can see that only HTTP and HTTPS are permitted.

Figure 18-25 Permit_WEB SGACL contents.

As you can see with Figures 18-24 and 18-25, the resulting ACL would be to permit HTTP (tcp/80) and HTTP (tcp/443) and deny all other traffic. This traffic is applied egress of the switch where the SGACL is configured. In this case it is applied at the Nexus 7000 in the data center, as traffic attempts to reach the HR server.

This form of traffic enforcement can provide a tremendous savings on the complexity and number of ACEs to maintain. There is a general formula to see the savings:

(# of sources) * (# of destinations) * permissions = # of ACE’s

With a traditional ACL on firewall:

4 VLANs (src) * 30 (dst) * 4 permission = 480 ACE’s

Per source IP on port using dACL:

1 group (source) * 30 (dst) * 4 permission = 120 ACE’s

With SGACLs, the number of ACEs is a magnitude smaller:

4 SGT (src) * 3 SGT (dst) * 4 permission = 48 ACE’s

There are two main conceptual paths in which to deploy SG-ACLs: North-South and East-West. North-South refers to the use case of a user or device being classified at the access layer, but with enforcement with the SGACL occurring at the data center. For example, a guest entering the access layer is assigned a GUEST SGT. Traffic with a GUEST SGT will be dropped if it tries to reach a server with financial data.

East-West refers to the use case of an SGACL protecting resources that exist on the same switch. For example, with a development server and a production server on the same Nexus 5000 Series switch in the data center, an SGACL can be deployed to prevent the development server from ever communicating with the production server. Another East-West example is a guest and an employee both using the same access layer switch. Traffic can be filtered between these two devices so the guest cannot communicate to the employee, who is in the same VLAN on the same switch. This is also referred to as peer-to-peer.

Figure 18-26 illustrates the concepts of North-South and East-West traffic flow enforcement.

Figure 18-26 North-South versus East-West visually explained.

There is much that can be learned about security group ACLs and the integration of the switches with ISE. However, that would be beyond the scope of the topic for the certification exam, and this book is therefore stopping here with the conceptual overview.

Security Group Firewalls

Some organizations prefer to do the traffic enforcement on the switching infrastructure, and others prefer it to be on a device that was purpose-built to do traffic filtering: a firewall. Cisco has added the capability to enforce traffic on firewalls by implementing the security group firewall (SG-FW). Two types of security group firewalls exist—the ASA-based SG-FW and the router-based SG-FW. This makes sense because the routers use a zone-based firewall (ZBF) and the ASA does not.

Security Group Firewall on the ASA

Beginning with ASA version 9.0, the ASA firewall added SG-FW functionality. ASDM supports the full configuration, and therefore the ASA is the only SG-FW that has a GUI (as of the writing of this book).

The SG-FW in the ASA is a very simple concept. The powerful firewall policy in the firewall has been expanded to include source and destination security groups into the decision. As you can see in Figure 18-27, there is a new “Security Group” column in the Source and Destination Criteria sections.

Figure 18-27 ASDM firewall policy.

Security Group Firewall on the ISR and ASR

The ASA is not the only security group firewall on the market. Both the Integrated Services Router Generation and the Aggregation Services Router (ASR) have a very powerful ZBF capability.

The Cisco ISR’s began support of SG-FW as of version 15.2(2)T, and the Cisco ASR 1000 added support of the SG-FW as of IOS-XE version 3.4. Both routers are capable of running the SXP, and the ASR has native tagging capabilities.

MACSec

In years long passed, when Wi-Fi was first being introduced into the consumer and corporate space, security concerns were raised. The concerns were around sensitive data being transmitted through the air, without any level of confidentiality. The temporary answer to this was to use Wired Equivalency Protection (WEP). WEP was not very secure (as history has proven), but it provided an extra level of protection designed to bring wireless connections to the same security level as a wired network.

Well, the fun part is that wireless networks quickly became even more secure than wired networks. As described many times in this book so far, 802.1X authentication took off like a rocket in wireless networks and enhancements were made to the encryption and keying mechanisms, such as Wi-Fi Protected Access (WPA/WPA2) using AES encryption. So, wireless networks had full encryption mechanisms to provide the confidentiality and integrity of data traversing the Layer-2 hop from the endpoint into the network infrastructure, in addition to the strong identity capabilities of 802.1X.

We needed “Wireless Equivalency” for wired networks to provide equivalent confidentiality and integrity. What was the answer? Should we use IPSec on every endpoint to every other endpoint, encrypting the entire communication from end-to-end? If we did that, how do we provide strong levels of quality of service (QoS) if we cannot see the content of a packet, and how would we glean into the packet to ensure security with all the security tooling that we have invested in? We would be simply encrypting both good and bad traffic across the network if we used end-to-end IPSec.

The answer to provide Wireless Equivalency, and a viable alternative to end-to-end IPSec, was to layer on the confidentiality and integrity using IEEE 802.1AE (MACSec). MACSec provides Layer-2 encryption on the LAN between endpoints and the switch, as well as between the switches themselves. Figure 18-28 illustrates the concept of the hop-by-hop encryption.

Figure 18-28 MACSec Layer-2 hop-by-hop encryption.

MACSec (IEEE 802.1AE) provides Layer-2 encryption on the LAN. The encryption also encapsulates and protects the CMD field, which carries the SGT as described the earlier in this chapter.

As of the time this book was published, there are two keying mechanisms available, both using 128-bit AES-GCM (Galois/Counter Mode) symmetric encryption that is capable of line-rate encryption and decryption for both 1Gb and 10Gb Ethernet interfaces and that provides replay attack protection of each and every frame.

The keying mechanisms are Security Association Protocol (SAP) and MAC Security Key Agreement (MKA). SAP is a Cisco proprietary keying protocol used between Cisco switches, whereas MKA is going to be the industry standard and is currently used between endpoints and Cisco switches.

Downlink MACSec

Downlink MACSec is the term used to describe the encrypted link between an endpoint and the switch. The encryption between the endpoint and the switch is handled by the MKA keying protocol. This requires a MACSec-capable switch (such as a Cisco Catalyst 3750-X) and a MACSec-capable supplicant on the endpoint (such as the Cisco AnyConnect Network Access Manager). The encryption on the endpoint can be handled in hardware (if the endpoint possesses the correct hardware) or in software using the main CPU for the encryption and decryption.

The Cisco switch has the ability to force encryption, make it optional, or force nonencryption; that setting can be configured manually per port (not very common) or dynamically as an authorization result from ISE (much more common). If ISE returns an encryption policy with the authorization result, the policy issued by ISE overrides anything set using the switch CLI.

Figure 18-29 shows the MACSec policy within an authorization profile on ISE. You can notice at the bottom, that the attribute sent to the switch is cisco-av-pair=subscriber:linksec-policy, followed by the policy itself. The choices are Must-Secure, Should-Secure, and Must-Not-Secure. Example 18-12 shows these options on the switch CLI, and Table 18-2 displays the resulting policy based on the supplicant policy and switch policy.

Figure 18-29 Authorization profile with MACSec policy.

Example 18-12 MACSec Policy Switch CLI

C3750X(config-if)#authentication linksec policy ?
must-not-secure Never secure sessions
must-secure Always secure sessions
should-secure OPTIONALLY secure sessions

Table 18-2 Resulting MACSec Policies

If the authentication server does not return the appropriate attribute-value pair to set the policy, the switch uses the configured policy on the port. If no policy is specified in the switch configuration, the switch reverts to the default policy of Should-Secure.

Switch Configuration Modes

A few configurations on the switch interface have implications for a MACSec deployment, such as the authentication host mode. The host mode plays an important role because it determines the number of endpoints that can be connected to a single switch interface.

Single Mode—MACsec is fully supported in single-host mode. In single-host mode, only a single MAC or IP address can be authenticated and secured with MACsec. If a different MAC address is detected on the port after an endpoint has authenticated, a security violation is triggered on the port.

Multidomain Authentication (MDA) Mode—With this mode, a single endpoint can be on the Data domain, and another endpoint can be on the Voice domain. MACsec is fully supported in MDA host mode. If both endpoints are MACsec capable, each will be secured by its own independent MACsec session. If only one endpoint is MACsec capable, that endpoint can be secured while the other endpoint sends traffic in the clear.

Multiauthentication Mode—With this mode, a virtually unlimited number of endpoints can be authenticated to a single switch port. MACSec is not supported in this mode.

Multihost Mode—Although MACSec usage with this mode technically might be possible, it is not recommended. With multihost mode, the first endpoint on the port authenticates, and then any additional endpoints will be permitted onto the network via the first authorization. So, MACSec would work with the first connected host, but no other endpoint’s traffic would actually pass because it would not be encrypted traffic.

Example 18-13 shows a switch interface configuration for MACSec-enabled endpoints. The example is using the default MACSec policy of Should-Secure and therefore the default setting is not displayed.

Example 18-13 Switch Interface Configuration for MACSec

interface X
switchport access vlan 10
switchport mode access
switchport voice vlan 99
ip access-group ACL-ALLOW in
authentication event fail action next-method
authentication event server dead action authorize vlan 2274
authentication event server alive action reinitialize
authentication event linksec fail action next-method
authentication host-mode multi-domain
authentication open
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication violation restrict
macsec
mka default-policy
mab
dot1x pae authenticator
dot1x timeout tx-period 10
spanning-tree portfast
end

ISE Configuration

Downlink MACSec is configured as attribute within the authorization profile (the result of an authorization). To add this result to an authorization profile, do the following:

Step 1. Navigate to Policy > Policy Elements > Results.

Step 2. Select Authorization Profiles.

Step 3. Edit an authorization profile to which you would like to add MACSec.

Step 4. Under Common Tasks, scroll down to MACSec Policy.

Step 5. Select must-secure, should-secure, or must-not-secure.

Step 6. Click Submit or Save to save the change.

Uplink MACSec

Uplink MACSec is the term used to describe encrypting the link between the switches with IEEE 802.1AE. At the time this book was written, the switch-to-switch encryption keying mechanism used Cisco’s proprietary SAP instead of MKA, which is used with the downlink MACSec. The encryption is still the same AES-GCM-128 encryption used with both uplink and downlink MACSec.

Uplink MACSec can be achieved manually or dynamically. Dynamic MACSec requires 802.1X between the switches and is covered in the NDAC section. For this section, we will focus on manual mode.

Manually Configuring Uplink MACSec

This method of MACSec is perfect to layer on top of the Manual SGTs configured earlier in this chapter. It will encrypt the inter-switch links. Start by reexamining the configuration of our uplink interface as we had it configured earlier in this chapter. Example 18-14 shows the uplink configuration.

Example 18-14 Uplink Configuration

C3750X# show run int Ten 1/1/1
Building configuration...

Current configuration : 286 bytes
!
interface TenGigabitEthernet1/1/1
description Cat6K Ten1/5
no switchport
ip address 10.1.48.2 255.255.255.252
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 EIGRP
load-interval 60
cts manual
policy static sgt 2 trusted
no macro auto processing
end

With the configuration shown in Example 18-13, our uplink between the 3750-X and the 6500-Sup2T is set up to use manual keying, without any encryption at all, and to apply SGTs to the frames. Now we will layer encryption on top of this to provide confidentiality and integrity of the SGTs and the data. Figure 18-30 depicts the relevant infrastructure configuration used for this example.

Figure 18-30 Adding MACSec to the uplink.

Step 1. From interface configuration mode, enter cts manual.

Step 2. Enable encryption with the sap pmk pairwise-master-key mode-list gcm-encrypt command.

The Pairwise Master Key (PMK) should be a hexadecimal value configured to be the same on both sides of the link. This master key can be compared to a RADIUS shared secret between a NAD and ISE, or even the pre shared key used with IPSEC encryption.

Step 3. Add the sap pmk pairwise-master-key mode-list gcm-encrypt command to the other side of the link.

Example 18-15 displays the sample configuration steps, and Example 18-16 shows the final configuration for the uplink port on the 3750-X.

Example 18-15 Adding Encryption to the Uplink Interface

C3750X#conf t
Enter configuration commands, one per line. End with CNTL/Z.
C3750X(config)#int Ten1/1/1
C3750X(config-if)#cts manual
C3750X(config-if-cts-manual)#sap pmk 26 mode-list gcm-encrypt
C3750X(config-if-cts-manual)#end
C3750X#

Example 18-16 Final Configuration for Uplink Interface

C3750X#sho run int ten1/1/1
Building configuration...

Current configuration : 386 bytes
!
interface TenGigabitEthernet1/1/1
description Cat6K Ten1/5
no switchport
ip address 10.1.48.2 255.255.255.252
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 EIGRP
load-interval 60
cts manual
policy static sgt 2 trusted
sap pmk 0000000000000000000000000000000000000000000000000000000000000026
mode-list gcm-encrypt
no macro auto processing
end

Verifying the Manual Configuration

You can validate that the manual encryption on the uplink was successful with the show cts interface command, as shown in Example 18-17. SAP status is the status of the encryption, and the example shows that SAP succeeded, the pairwise cypher is using gcm-encrypt, and replay protection is enabled.

Example 18-17 Output of show cts interface Command

C3750X#show cts interface TenGigabitEthernet 1/1/1
Global Dot1x feature is Enabled
Interface TenGigabitEthernet1/1/1:
CTS is enabled, mode: MANUAL
IFC state: OPEN
Authentication Status: NOT APPLICABLE
Peer identity: "unknown"
Peer's advertised capabilities: "sap"
Authorization Status: SUCCEEDED
Peer SGT: 2
Peer SGT assignment: Trusted
SAP Status: SUCCEEDED
Version: 2
Configured pairwise ciphers:
gcm-encrypt

Replay protection: enabled
Replay protection mode: STRICT

Selected cipher: gcm-encrypt

Propagate SGT: Enabled
Cache Info:
Cache applied to link : NONE

Statistics:
authc success: 0
authc reject: 0
authc failure: 0
authc no response: 0
authc logoff: 0
sap success: 2
sap fail: 0
authz success: 5
authz fail: 0
port auth fail: 0

L3 IPM: disabled.

C3750X#

Exam Preparation Tasks

Review All Key Topics

Review the most important topics in the chapter, noted with the key topics icon in the outer margin of the page. Table 18-3 lists a reference of these key topics and the page numbers on which each is found.

Table 18-3 Key Topics for Chapter 18

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

TrustSec

security group tag (SGT)

classification

transport

Security Group Exchange Protocol (SXP)

North-South

East-West