Cisco TrustSec SGT Exchange Protocol IPv4

CTS-SXP uses the device and user credentials acquired during authentication for classifying the packets by security groups (SGs) as they enter the network. This packet classification is maintained by tagging packets on ingress to the CTS-SXP network so that they can be properly identified for the purpose of applying security and other policy criteria along the data path. The Security Group Tag (SGT) allows the network to enforce the access control policy by enabling the endpoint device to act upon the SGT to filter traffic.

Tagging packets with SGTs requires hardware support. There may be devices in the network that can participate in CTS authentication, but lack the hardware capability to tag packets with SGTs. However, if CTS-SXP is used, then these devices can pass IP-to-SGT mappings to a CTS peer device that has CTS-capable hardware.

CTS-SXP typically operates between ingress access layer devices at the CTS domain edge and distribution layer devices within the CTS domain. The access layer device performs CTS authentication of external source devices to determine the appropriate SGTs for ingress packets. The access layer device learns the IP addresses of the source devices using IP device tracking and (optionally) DHCP snooping, then uses CTS-SXP to pass the IP addresses of the source devices along with their SGTs to the distribution switches. Distribution switches with CTS-capable hardware can use this IP-to-SGT mapping information to tag packets appropriately and to enforce Security Group Access Control List (SGACL) policies as shown in the figure below. An SGACL associates an SGT with a policy. The policy is enforced when SGT-tagged traffic egresses the CTS domain.

Figure 1

How CTS-SXP Propagates SGT Information

You must manually configure a CTS-SXP connection between a peer without CTS hardware support and a peer with CTS hardware support. The following tasks are required when configuring the CTS-SXP connection:

• If CTS-SXP data integrity and authentication are required, the same CTS-SXP password can be configured on both peer devices. The CTS-SXP password can be configured either explicitly for each peer connection or globally for the device. Although a CTS-SXP password is not required it is recommended.
• Each peer on the CTS-SXP connection must be configured as either a CTS-SXP speaker or CTS-SXP listener. The speaker device distributes the IP-to-SGT mapping information to the listener device.
• A source IP address can be specified to use for each peer relationship or a default source IP address can be configured for peer connections where a specific source IP address is not configured. If no source IP address is specified, then the device uses the interface IP address of the connection to the peer.

CTS-SXP allows multiple hops. That is, if the peer of a device lacking CTS hardware support also lacks CTS hardware support, the second peer can have a CTS-SXP connection to a third peer, continuing the propagation of the IP-to-SGT mapping information until a hardware-capable peer is reached. A device can be configured as a CTS-SXP listener for one CTS-SXP connection as a CTS-SXP speaker for another CTS-SXP connection.

A CTS device maintains connectivity with its CTS-SXP peers by using the TCP keepalive mechanism. To establish or restore a peer connection, the device repeatedly attempts the connection setup by using the configured retry period until the connection is successful or until the connection is removed from the configuration.

The CTS-SXP implementation of Virtual Routing and Forwarding (VRF) binds a CTS-SXP connection with a specific VRF. It is assumed that the network topology is correctly configured for Layer 2 or Layer 3 VPNs, and that all VRFs are configured before enabling CTS-SXP.

CTS-SXP VRF support can be summarized as follows:

• Only one CTS-SXP connection can be bound to one VRF.
• Different VRFs may have overlapping CTS-SXP peer or source IP addresses.
• IP-to-SGT mappings learned (added or deleted) in one VRF can be updated only in the same VRF domain. The CTS-SXP connection cannot update a mapping bound to a different VRF. If no SXP connection exits for a VRF, IP-SGT mappings for that VRF won't be updated by SXP.
• CTS-SXP does not support the establishment of connections with source and destination IPv6 addresses. However, multiple address families per VRF are supported where one CTS-SXP connection in a VRF domain can forward both IPv4 and IPv6 IP-to-SGT mappings.
• CTS-SXP has no limitation on the number of connections and number of IP-to-SGT mappings per VRF.

CTS-SXP extends the deployment of additional platforms such as network devices, Identity firewalls, and the wireless controller to additional places on the network. CTS-SXP is used for Identity distribution through inline devices where the identity information is learned from a primary communication path that exists across networks as shown in the figure below.

The SG name is one of the attributes that is used by the Identity firewall to apply enforcement policy. With the SG-name-to-SGT mapping information learned through an authentication server and IP-to-SGT binding learned through CTS-SXP, when a packet arrives, source and destination IP addresses in the packet are used to derive source and destination tags. The Identity firewall applies a policy to the received IP packets based on the configured policy where the SG name or SGT is one of the attributes.

Figure 2

CTS-SXP Identity Distribution Path Across Networks

1.    enable

2.    configure terminal

3.    cts sxp enable

The CTS-SXP peer connection must be configured on both devices. One device is the speaker and the other is the listener. When using password protection, make sure to use the same password on both ends.

Note

If a default CTS-SXP source IP address is not configured and you do not configure a CTS-SXP source address in the connection, the Cisco TrustSec software derives the CTS-SXP source IP address from existing local IP addresses. The CTS-SXP source IP address might be different for each TCP connection initiated from the router.

1.    enable

2.    configure terminal

3.    cts sxp connection peer ipv4-address {source | password} {default | none} mode {local | peer} [[listener | speaker] [vrf vrf-name]]

4.    exit

5.    show cts sxp {connections | sgt-map} [brief | vrf vrf-name]

1.    enable

2.    configure terminal

3.    cts sxp default password [0 | 6 | 7] password

1.    enable

2.    configure terminal

3.    cts sxp default source-ip src-ip-addr

1.    enable

2.    configure terminal

3.    cts sxp reconciliation period seconds

1.    enable

2.    configure terminal

3.    cts sxp retry period seconds

1.    enable

2.    configure terminal

3.    cts sxp log binding-changes

Perform this task to configure a class map for classifying Security Group Access (SGA) zone-based policy firewall network traffic.

Note	You must perform at least one match step.

The zone-based firewall policy uses the security group tag (SGT) ID for filtering. In a zone-based firewall policy, only the first packet that creates a session matches the policy. Subsequent packets in this flow do not match the filters in the configured policy, but instead match the session directly. The statistics related to subsequent packets are shown as part of the inspect action.

1.    enable

2.    configure terminal

3.    class-map type inspect [match-any | match-all] class-map-name

4.    match security-group source tag sgt-number

5.    match security-group destination tag sgt-number

6.    exit

1.    enable

2.    configure terminal

3.    policy-map type inspect policy-map-name

4.    class type inspect class-name

5.    inspect

6.    exit

7.    zone-pair security zone-pair-name source source-zone destination destination-zone

8.    service-policy type inspect policy-map-name

9.    end

10.    interface type number

11.    zone-member security zone-name

12.    exit

13.    show policy-map type inspect zone-pair session

This example shows how to enable CTS-SXP and configure the CTS-SXP peer connection on Router_A, a speaker, for connection to Router_B, a listener:

Router# configure terminal
Router_A(config)# cts sxp enable
Router_A(config)# cts sxp default password Cisco123
Router_A(config)# cts sxp default source-ip 10.10.1.1
Router_A(config)# cts sxp connection peer 10.20.2.2 password default mode local speaker

This example shows how to configure the CTS-SXP peer connection on Router_B, a listener, for connection to Router_A, a speaker:

Router# configure terminal
Router_B(config)# cts sxp enable
Router_B(config)# cts sxp default password Cisco123
Router_B(config)# cts sxp default source-ip 10.20.2.2
Router_B(config)# cts sxp connection peer 10.10.1.1 password default mode local listener

This example shows CTS-SXP connections:

Router_B# show cts sxp connections
 SXP              : Enabled
 Default Password : Set
 Default Source IP: 10.10.1.1
Connection retry open period: 10 secs
Reconcile period: 120 secs
Retry open timer is not running
----------------------------------------------
Peer IP          : 10.20.2.2
Source IP        : 10.10.1.1
Conn status      : On
Connection mode  : SXP Listener
Connection inst# : 1
TCP conn fd      : 1
TCP conn password: default SXP password
Duration since last state change: 0:00:21:25 (dd:hr:mm:sec)
Total num of SXP Connections = 1