So continuing on from my first Trustsec post which can be viewed here I would like to make some notes on SXP, the Security Exchange Protocol which makes it more practical to deploy the Cisco Trustsec solution.
First, we should go back to the fundamentals of Trustsec, Trustsec uses SGT's to tag traffic originating from end devices depending on the policies configured on ISE. The SGT's are 16 bits in length and are assigned by ISE when the device authenticates on the network.
Traffic is tagged on Ingress of the Trustsec domain. To allow enforcement across the network when the traffic is transmitted across the network other network devices need to be aware of the SGT associated with the traffic so receiving devices can make enforcement decisions on permitting or denying that traffic.
So how does this SGT remain associated with the data as it travels across the network? The SGT tag is inserted within the header of the frame as seen below. Sourced from cisco.com.
The issue we have is that to keep this SGT field intact within the frame as it travels across the network there is a requirement that all devices must be Trustsec enabled. This is a big show stopper for large established networks that wish to deploy Trustsec as it involves new configuration to be applied to all network devices to enable Trustsec, in reality, many of these devices will probably require replacing or a software upgrade to support the Trustsec capability.
Cisco's solution to this is SXP (Security Exchange Protocol) which allows peerings across a non-Trustsec aware network to advertise IP to SGT bindings. SXP uses the TCP transport layer on port 64999. With SXP the device at the edge of the network tagging user traffic can propagate to other Trustsec devices on the network with an IP to SGT binding. For example, if a device with the IP address 172.16.0.1 connects to the network and is assigned a SGT of 100 by ISE the switch will propagate this information to other switches telling them that if you see traffic sourced from a device with an IP address 172.16.0.1 you should re-tag this traffic with SGT 101.
An example of how this all fits together is an HQ / Branch network. Let's imagine that company 'XYZ Ltd' have 5 branches across the UK and one data centre. If XYZ wanted to deploy Trustsec to enforce access control within the data centre the SGT tags would have to remain intact between the branches and the data centre for this to happen without SXP all the network devices between the branches and data center would have to be Trustsec aware. However, because XYZ do not have a private WAN they are in control of this is unlikely to be possible. Even if they did have a private WAN network ensuring that all the devices are Trustsec aware could be a huge cost, especially if those WAN devices don't support Trustsec. The workaround would be to create an SXP peering between the switches at the sites to a device on the edge of the data center, this means that SGT's will be assigned at the site, removed when transported over the WAN but re-tagged upon entry to the data centre ready for policies to be applied.