Cisco pxGrid & Native tagging

PxGrid Protocol

This is the communication bus and is used to share dynamic information at very large scale. It is used to learn the contextual information from ISE.

Example: - Cisco Firepower uses pxGrid to learn identities and SGT information from ISE.

PxGrid is considered to be publish & Subscriber communication bus, and has following components.

Controller: It keeps track of all topic that exits and a topic is a list of information that is available like session data with Source and Destination on network, or li may be list of all vulnerable endpoints and their vulnerabilities.

Subscribers: Subscribers are those who wish to receive these topics from controller. They can subscribe any topic of interest, after which they will be notified when there is data for that topic to be retrieved.

Publishers: Those pxGrid participants who can provide true source of data called as Publishers. Publishes will register the list of topic to controller, who perform the authorization for each subscriber to retrieve date from many possible publishers.

PxGrid is developed by extending the XMPP (Extensible Messaging & Presence Protocols) , pxGrid Controller is modified Extensible Communication platform (XCP)

pxGrid communication between its component is secured , Every Participant must trust the controller and vice versa .

For trust, Certificate based architecture must be developed between Controller and its participant. For best practice, use Same CA to issue pxGrid certificate for each of the participant. With ISE 2.1 , ISE can act as CA to issue pxGrid Certificate to pxGrid Participant along with endpoint certificates distribution.

Configuring ISE for pxGrid

pxGrid user interface can be seen on below ISE GUI path : Administration | pxGrid Services.

By default these services are not enabled on any ISE nodes.

Before enabling pxGrid to any PSN node, make sure that each node in the ISE cube has pxGrid certificate signed by same certificate authority. Beginning from ISE 2.2 onwards, each node’s pxGrid certificate will be signed automatically.

Follow below steps to see weather   each node has pxGrid certificate is signed by same CA or Not.

Administration | System | Certificates | Select any pxGrid Certificate | Click View

Check that the root signer of the certificate is the primary Policy Administration Node (PAN) of the ISE cube (the root CA) as shown in below figure.

In order to enable pxGrid controller function, use below path:

• Go to Administration | System | Deployment.
• The pxGrid controller function must run on a Policy Service Node (PSN). Select one of the PSNs from the list.
• Check the pxGridcheck box, as shown in below figure | Click Save.

It may be required to enable two pxGrid controller function per ISE cube to provide redundancy. Once pxGrid services will up and running, PAN and MnT will automatically register and publish their topics in to the grid. By Default, only ISE nodes are registered, and other registration requires approval or if you configure auto-generation.

Native Tagging

With the Native tagging access layer switch apply SGT to layer 2 frame that is sent across upstream switch. When this frame is received by upstream switch, it keep the tag and ensure that SGT is applied throughout infrastructure.

Below figure shows the Layer 2 frame format with SGT.

With the help of Native tagging, we can span our infrastructure endless and it is not affected by any routing Protocols or layer 3 Protocols.

When native tagging are done in infrastructure, SGT is communicated Hop by hop. When SGT is applied to traffic at every layer 2 link, a policy can be enforced at any point in infrastructure and there would be no size limit of IP to SGT mapping database.

Below figure describes Pervasive Tagging:

Configuring Native SGT Propagation

Here we will see the configuration of SGT on different models on Switches. :

3750-X Series Access Switches

Verification 

Enable tagging on 6500 Sup-2 Switches

Enable tagging on Nexus 7000 Series switches

Enforcement

Now the SGT assignment (Classification), and its propagation (Transport) is done, it time to see the Enforcement of TrustSec.

There are multiple ways to enforce traffic based on tags.

• Enforcement on a switch (SGACL)
• Enforcement on a firewall (SG-FW)

Enforcement on a switch (SGACL)

 In order to see how benefit is using SGT in SGACL, look below example.

Here is a general formula to see the savings:

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

With a traditional ACL on a firewall:

4 VLANs (src) × 30 (dst) × 4 permission = 480 ACEs

Per source IP on a port using dACL:

1 group (source) × 30 (dst) × 4 permission = 120 ACEs

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

4 SGT (src) × 3 SGT (dst) × 4 permission = 48 ACEs

There are two ways to deploy SGACLs

• North-South
• East-West

Below figure describes the North-South versus East-West SGT deployment

North-South refers to the use case of a user or device being classified at the access layer, but 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 is 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, in a scenario with a development server and a production server on the same Nexus 5000 Series switch in the data center, an SGACL may be deployed to prevent the development server from ever communicating with the production server. 

ISE provides three different views to create TrustSec policies and SGACLs: two tree views (Source Tree and Destination Tree), and a Matrix View.

Here we will see the Matrix view.

Work Centers | TrustSec | TrustSec Policy | Matrix.

Click the square that represents the intersection of a source SGT and a destination SGT.

Traffic Enforcement with Security Group FW.

Cisco has added the capability to enforce traffic on firewalls by including the source SGT and/or destination SGT in the firewall policy itself.

Beginning with ASA version 9.0, the ASA firewall gains SG-FW functionality. ASDM supports the full configuration, and therefore the ASA is the only SG-FW that has a GUI.

There is a new Security Group column in the Source Criteria and Destination Criteria sections as shown in below figure: