Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

Cisco TrustSec (CTS) Security Group Tag (SGT) Exchange Protocol (SXP) (CTS-SXP) is a control protocol which propagates IP address to Security Group Tag (SGT) binding information across network devices. SGT 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.

SXP connections can be enabled such that the binding forwarded by one switch for an SXP connection can be received from another SXP connection, resulting in SXP connection loops. SXP loop topology might, however, result in stale binding in the network. SXPv4’s built-in loop detection and prevention mechanism addresses the stale binding issue whenever there is a loop between SXP nodes.

Loop prevention is achieved by adding SXP propagation path information when propagating (adding/deleting) bindings. Propagation path information keeps track of the network devices (via their node IDs) that the binding travels in an ordered manner. All nodes that participate in the network with looped SXP connections must run SXPv4 to function correctly. Loop detection is a mandatory capability in SXPv4.

Figure 1. SXPv4 Loop Detection

In the figure above there are three network devices: SW1, SW2, and SW3. There are also three SXP connections: SXP1, SXP2 and SXP3, together which create an SXP connection loop. A binding (10.1.10.1, 100) is learned at SW1 through local authentication. The binding is exported by SW1 to SW2 together with the path information (that is, SW1, from where the binding is forwarded).

Upon receiving the binding, SW2 exports it to SW3, again prepending the path information (SW2, SW1). Similarly, SW3 forwards the binding to SW1 with path information SW3, SW2, SW1. When SW1 receives the binding, the path information is checked. If its own path attribute is in the binding update received, then a propagation loop is detected. This binding is dropped and not stored in the SXP binding database.

If the binding is removed from SW1, (for example, if a user logs off), a binding deletion event is sent. The deletion event goes through the same path as above. When it reaches SW1, no action will be taken as no such binding exists in the SW1 binding database.

Loop detection is done when a binding is received by an SXP but before it is added to the binding database.

An SXP node ID is used to identify the individual devices within the network. The node ID is a four-octet integer that can be configured by the user. If it is not configured by the user, SXP picks a node ID itself using the highest IPv4 address in the default VRF domain, in the same manner that EIGRP generates its node ID. The node ID has to be unique in the network that SXP connections traverse to enable SXP loop detection.

The SXP loop detection mechanism drops binding propagation packets based on finding its own node ID in the peer sequence attribute. Changing a node ID in a loop detection-running SXP network could break SXP loop detection functionality and therefore needs to be handled carefully.

The bindings that are associated with the original node ID have to be deleted in all SXP nodes before the new node ID is configured. This can be done by disabling the SXP feature on the network device where you desire to change the node ID.

Note	Disabling the SXP feature brings down all SXP connections on the device.

Before you change the node ID, wait until the SXP bindings that are propagated with the particular node ID in the path attribute are deleted.

Note	A syslog is generated when you change the node ID.

SXP uses a TCP-based, keepalive mechanism to determine if a connection is live. SXPv4 adds an optional negotiated keepalive mechanism within the protocol in order to provide more predictable and timely detection of connection loss.

SXP connections are asymmetric with almost all of the protocol messages (except for open/open_resp and error messages) being sent from an SXP speaker to an SXP listener. The SXP listener can keep a potentially large volume of state per connection, which includes all the binding information learned on a connection. Therefore, it is only meaningful to have a keepalive mechanism that allows a listener to detect the loss of connection with a speaker.

The mechanism is based on two timers:

• Hold timer: Used by a listener for detection of elapsing time without successive keepalive and/or update messages from a speaker.

• Keepalive timer: Used by a speaker to trigger the dispatch of keepalive messages during intervals when no other information is exported via update messages.

The hold-time for the keepalive mechanism may be negotiated during the open/open_resp exchange at connection setup. The following issues are important during the negotiation:

• A listener may have desirable range for the hold-time period locally configured or have a default of 90 to 180 seconds. A value of 0xFFFF..0xFFFF indicates that the keepalive mechanism is not used.

• A speaker may have a minimum acceptable hold-time period locally configured or have a default of 120 seconds. This is the shortest period of time a speaker is willing to send keepalive messages for keeping the connection alive. Any shorter hold-time period would require a faster keepalive rate than the rate the speaker is ready to support.

• A value of 0xFFFF implies that the keepalive mechanism is not used.

• The negotiation succeeds when the speaker’s minimum acceptable hold-time falls below or within the desirable hold-time range of the listener. If one end turns off the keepalive mechanism, the other end should also turn it off to make the negotiation successful.

• The negotiation fails when the speaker’s minimum acceptable hold-time is greater than the upper bound of the listener’s hold-time range.

• The selected hold-time period of a successful negotiation is the maximum of the speaker’s minimum acceptable hold-time and the lower bound of the listener’s hold-time range.

• The speaker calculates the keepalive time to one-third of the selected hold-time by default unless a different keepalive time is locally configured.

Figure 2. Hold-time Negotiation Process

The figure above illustrates the hold-time negotiation process. More detail on the listener’s and speaker’'s roles is given below.

Connection Initiated by Listener

• A listener may include a hold-time attribute in the open message with minimum and maximum values set to its configured range of the hold-time period. A hold-time attribute with just a minimum value set to 0xFFFF0 would indicate to the speaker that the keepalive mechanism is not used.
• When a speaker receives an open message, it will react as follows:

  • If the hold-time attribute is not present or if it contains a minimum value that is set to 0xFFFF0, the speaker will set its keepalive time to 0xFFFF0 to indicate that the keepalive mechanism is disabled.

  • If the received hold-time attribute contains a valid range, the speaker must include a hold-time attribute in its open_resp message with a minimum value set as follows:

    • 0xFFFF0 if the speaker does not support the keepalive mechanism or if the mechanism is supported but disabled due to a local configuration, which sets the keepalive time to 0xFFFF0.

    • If the speaker’s minimum acceptable hold-time value is greater than the upper bound of the offered range, the speaker must send an open error message with the subcode set to “Unacceptable hold-time” and terminate the connection. Otherwise the speaker will set the selected hold-time to the maximum of its minimum acceptable hold-time value and the lower bound of the offered hold-time range.

    • The speaker will calculate a new value for its keepalive time as one-third of that selected hold-time.

    • The speaker will set the minimum hold-time value of the hold-time attribute to the selected hold-time.

• When the listener receives the open_resp message from the speaker, it will look for hold-time attribute:

  • If the hold-time attribute is present and contains a minimum hold-time value of 0xFFFF0, the speaker will set its hold-time value to 0xFFFF0 to indicate that the keepalive mechanism is not used.

  • If the minimum hold-time value is within the range offered by the listener, the listener will set its hold-time period to the selected value it has received in the open_resp message.

  • If the minimum hold-time value is outside the offered range, the listener will send an open error message with subcode set to “Unacceptable hold-time” and terminate the connection.

Connection Initiated by Speaker

• A speaker may include a hold-time attribute in the open message with minimum value set to its minimum acceptable hold-time period. A hold-time attribute with just a minimum value of 0xFFFF0 would indicate to the listener that the keepalive mechanism is not used.

• When a listener receives an open message, it will react as follows:

  • If the hold-time attribute is not present or if it contains a minimum value that is set to 0xFFFF0, the listener will set its hold-time to 0xFFFF0 to indicate that keepalive mechanism is disabled.

  • If the received hold-time attribute contains a valid value, the speaker must include hold-time attribute in its open_resp message with a minimum value set as follows:

    • 0xFFFF0 if the listener does not support the keepalive mechanism or if the mechanism is supported but disabled due to a local configuration, which sets the keepalive time to 0xFFFF0.

    • If the received hold-time value is greater than the upper bound of the listener’s configured hold-time range, the speaker must send an open error message with subcode set to “Unacceptable hold-time” and terminate the connection.

    • If the received hold-time value falls within the listener’s configured hold-time range, the listener will make it the selected hold-time.

    • If the received hold-time value is less than the lower bound of the listener’s configured hold-time range, the listener will set the selected hold-time to the lower bound of its hold-time range.

    • The listener will set the minimum hold-time value of the hold-time attribute to the selected hold-time.

• When the speaker receives the open_resp message from the listener, it will look for the hold-time attribute:

  • If the hold-time attribute is present and contains a minimum hold-time value of 0xFFFF0. The speaker will set its hold-time value to 0xFFFF0 to indicate that the keepalive mechanism is not used.

  • If the received hold-time value is greater or equal to the speaker's minimum acceptable hold-time, the speaker will calculate a new value for its keepalive time as one-third of the received hold-time.

  • If the received hold-time value is lower than the minimum acceptable, the speaker must send an open error message with subcode set to “Unacceptable hold-time” and terminate the connection.

Each security group in a CTS domain is assigned a unique 16 bit tag called the “Security Group Tag” (SGT). The SGT is a single label indicating the privileges of the source within the entire network. It is in turn propagated between network hops allowing any intermediary devices (switches, routers) to enforce polices based on the identity tag.

CTS-capable devices have built-in hardware capabilities than can send and receive packets with SGT embedded in the MAC (L2) layer. This feature is called “L2-SGT Imposition.” It allows Ethernet interfaces on the device to be enabled for L2-SGT imposition so that device can insert an SGT in the packet to be carried to its next hop Ethernet neighbor. SGT-over-Ethernet is a method of hop-by-hop propagation of SGT embedded in clear-text (unencrypted) Ethernet packets. Inline identity propagation is scalable, provides near line-rate performance and avoids control plane overhead.

The Cisco TrustSec with SXPv4 feature supports CTS Meta Data (CMD) based L2-SGT. When a packet enters a CTS enabled interface, the IP-SGT mapping database (with dynamic entries built by SXP and/or static entries built by configuration commands) is analyzed to learn the SGT corresponding to the source IP address of the packet, which is then inserted into the packet and carried throughout the network within the CTS header.

As the tag represents the group of the source, the tag is also referred to as the Source Group Tag (SGT). At the egress edge of the network, the group assigned to the packet’s destination becomes known. At this point, the access control can be applied. With CTS, access control policies are defined between the security groups and are referred to as Security Group Access Control Lists (SGACL). From the view of any given packet, it is simply being sourced from a security group and destined for another security group.

To complement CTS architecture of end-to-end identity enablement, Cisco ISR devices support inline propagation of SGT over Ethernet packets peer devices on the LAN. A typical branch deployment scenario for SGT over Ethernet is shown in the figure below:

Figure 3. Cisco ISR Router with Routed Port SGT Over Ethernet

• The end points are authenticated on a Cisco Catalyst switch and SGT-assigned. The switch tags native/802.1Q packets inline SGT on the egress.

• A Cisco ISR router sends/receives SGT over Ethernet (using EtherType 0x8909) on routed ports.

  • Ingress - receive SGToEthernet processes and makes SGT available to data-plane features (SGFW, IPsec).

  • Egress - send SGT over Ethernet from SGT learned from IP-SGT manager and/or IPsec. SGFW enforcements on Cisco ISR router using data-plane SGT.

• IPsec tags packets on WAN egress and vice-versa.

1.    enable


2.    configure terminal


3.    cts sxp listener hold-time minimum-period maximum-period


4.    cts sxp speaker hold-time minimum-period

Device> enable

Device# configure terminal

Device(config)# cts sxp listener hold-time 750 1500

Device(config)# cts sxp speaker hold-time 950

1.    enable


2.    configure terminal


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


4.    exit


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

Router> enable

Router# configure terminal

Device(config)# cts sxp connection peer 10.20.2.2 password default mode local speaker

Device(config)# exit

Device# show cts sxp connections

SUMMARY STEPS

1.    enable


2.    configure terminal


3.    cts sxp node-id {sxp-node-id | interface interface-type | ipv4-address}

Device> enable

Device# configure terminal

Device(config)# cts sxp node-id 172.16.1.3

1.    enable


2.    configure terminal


3.    interface {gigabitethernet port | vlan number}


4.    cts manual


5.    propagate sgt


6.    policy static sgt tag [trusted]


7.    end


8.    show cts interface brief

Device> enable

Device# configure terminal

Device(config)# interface gigabitethernet 0

Device(config-if)# cts manual

Device(config-if-cts-manual)# propagate sgt

Device(config-if-cts-manual)# policy static sgt 77 

Device(config-if-cts-manual)# end

Device# show cts interface brief

Interface GigabitEthernet0/0
    CTS is enabled, mode:    MANUAL
    Propagate SGT:           Enabled
    Peer SGT assignment:     Trusted

Interface GigabitEthernet0/1
    CTS is enabled, mode:    MANUAL
    Propagate SGT:           Disabled
    Peer SGT assignment:     Untrusted

Interface GigabitEthernet0/3
    CTS is disabled.