Zero Trust Inline Segmentation: The New Way of Microsegmentation in Network Design

Microsegmentation Without Zero Trust Inline Segmentation

In a VXLAN architecture, you can use macrosegmentation and microsegmentation to protect data and critical assets through Group-Based Policy (GBP). Group-based policies build on VXLAN to deliver location-independent access control for endpoints. This allows you to enforce consistent security policies across different parts of the enterprise network without depending on where a device is physically connected.

By using GBP, you can reduce configuration complexity and avoid deploying large numbers of firewall filters across all switches. Group-based policies help prevent lateral movement of threats by applying consistent security rules throughout the network, regardless of endpoint or user location. VXLAN-GBP uses a reserved field in the VXLAN header to carry a scalable group tag (SGT). These tags can be referenced in firewall filter rules, providing a more reliable method of policy enforcement than relying on port numbers or MAC addresses.

Scalable group tags can be assigned statically on the switch, either per port or per MAC address, or dynamically through a RADIUS server. When using 802.1X authentication, the RADIUS server can push the appropriate SGT to the switch after the user successfully authenticates.

In campus VXLAN deployments, VXLAN-GBP segmentation is particularly valuable because it allows you to define access policies that are independent of the physical network design. This simplifies both the planning and implementation of security policies for applications and endpoint devices.

You can find more detailed information on the VXLAN-GBP standard in the IEEE RFC, I-D.draft-smith-vxlan-group-policy. For the purposes of this example architecture, VXLAN-GBP leverages a reserved field in the VXLAN header as an SGT.

Starting with Junos OS Release 22.4R1, Juniper Networks switches support VXLAN-GBP in egress and ingress enforcing mode as described below:

• GBP egress enforcement:
  • This is the IETF standards-based approach.
  • The GBP tag is part of the VXLAN data plane and needs to be set as the group policy ID in the VXLAN header.
  • For verification of the destination GBP tag from a remote switch, the packet must be sent to the remote switch every time. The remote switch can then act as an enforcement point for traffic egressing the fabric to the next wired client and can, based on SGT Policy, block the traffic, and discard the packet.
• GBP ingress enforcement:
  • This is a Juniper Networks proprietary enhancement to the Junos GBP and SGT implementations.
  • This enhancement is available starting with Junos OS Release 22.4R1.
  • Here, the GBP tag is an extension of the control plane (MP-BGP extension).
  • The GBP tag information is added through a vendor-specific attribute to the EVPN Type-2 MAC and IP address information that the fabric shares among its nodes. In this case, the value of the group policy ID in the VXLAN header is always zero by default as it is not used for enforcement.
  • The significant advantage to this approach is that the destination GBP tag of a wired client present on a remote switch is already known because it’s learned through the control plane. With this enhancement, the SGT on the local switch where the source wired client is attached can pre-emptively block traffic that is not allowed to be sent to a destination client on a remote switch. The enforcement of SGTs always happens at the ingress wired client switch. The need to send all traffic through the fabric even though it may get discarded by the SGT, as in the standards-based approach, does not happen with this solution.
  • This extension makes it easier for administrators to debug GBP-based traffic forwarding decisions. You can review a local switch to find out if traffic would be allowed or blocked by a remote switch. Junos OS commands such as show ethernet-switching table display GBP tag information of local and remote wired clients.

There are different ways you can apply a GBP tag to a wired client to be used by the SGTs to allow or block traffic.

You can assign GBP tags as follows:

• For static GBP tag assignment:
  • You must statically configure the tag assignment to identify a wired client and assign the GBP tag to it.
  • Match criteria (depending on Junos OS release version) can be:
    1. Layer 3 source IPv4 prefixes and hosts
    2. Layer 3 source IPv6 prefixes and hosts
    3. Layer 2 MAC address
    4. Switch interface/port and VLAN ID (not supported on Juniper Networks® EX4100 Switches)
    5. Layer 2 VLAN ID (not supported on EX4100 Switches)
    6. Switch interface/port
• For dynamic GBP tag assignment:
  • The wired client needs to be authenticated at the switch port when entering the fabric.
  • It is based on RADIUS server authorization information which is part of the RADIUS access-accept message.
  • The wired client authentication can be:
    1. IEEE 802.1X EAP-based
    2. MAC authentication bypass (MAB)

The Juniper Mist portal simplifies this process and abstracts the switch configuration needed as shown below.

After defining the GBP tag assignment, you need to specify the SGTs as switch policies. Again, the Juniper Mist cloud simplifies and abstracts this process in its portal, allowing you to build an intuitive communication matrix.

Note:

We strongly recommend using a switch template to configure static or dynamic GBP tag assignments and SGT policies since the templates ease the task of distributing this information across all access switches of an IP Clos fabric.

More information is available in the following JVD Extension for IP Clos fabrics along with examples of deployment.

Microsegmentation with Zero Trust Inline Segmentation

The approach taken so far is only available in IP Clos fabrics because the SGT enforcement functions must be executed where your wired client’s ingress the fabric. This is because wired clients attached to different ports of the same access switch may need to be blocked from communication inside the same VLAN.

Imagine you attempt the enforcement northbound to the fabric with enforcement on the WAN router side. That may be appropriate for protection from traffic towards and from the Internet, but it may be too late for L3-based macrosegmentation (depending on design) and definitely for L2-microsegmentation inside the same VLAN.

With ZTIS, Juniper now:

• Closes the gap between all other campus fabric designs (EVPN MH, CRB, and ERB) enabling microsegmentation in those as well.
• Enables microsegmentation when you have no EVPN fabric at all which is typical for simpler branch designs with a small number of switches and APs.
• Enables GBP tag propagation from APs to attached switches (also through remote tunnels using Juniper Mist Edge).

To allow these new features and topologies to operate together, share GBP tag information for both wireless and wired clients, and enforce those policies consistently, a vendor-specific enhancement was introduced to support the propagation of client information across the network.

Remember that in the IP Clos fabric scenarios explained above, one could decide to use:

• A GBP tag embedded in the VXLAN data header enabling egress enforcement.
• The Juniper proprietary BGP-MP extension adding the GBP tag as part of the EVPN control plane enabling ingress enforcement.

Reusing these two approaches for APs and branch switches would typically result in significant integration costs, require additional capacity, and involve extending the EVPN fabric across all wired and wireless devices. A more streamlined approach for ZTIS was therefore needed and developed.

The ZTIS solution introduces new message types that are exchanged among all devices within the same Layer 2 domain or EVPN fabric. Two message types are required:

• A ZTIS Update message is generated when a switch or AP authenticates a new client MAC address. The device then distributes the associated MAC-to-GBP tag mapping to other devices in the network.
• A ZTIS Lookup message is sent when a device detects a new MAC address in its local table but does not yet know the corresponding GBP tag. The device that has the MAC-to-GBP mapping responds with a ZTIS Update message. Lookup messages are commonly used after a switch reboot, when previously learned MAC-to-GBP information has been lost and must be rebuilt.

Hence you more or less have a third way of a control plane function that uses a flood-and-learn (or hop-by-hop learning when unicast messages can be used) approach to exchange the MAC-to-GBP tag information. Please note that the GBP enforcement function still happens at the access switch of your network (not considered Juniper Mist Edge here) as explained above as a requirement.

How are these two new messages then exchanged with the network? The messages exchanged between ZTIS devices in the network are based on the Juniper extension using the ethernet Logical Link Control (LLC) messages SNAP. These messages:

• Can be Layer 2 unicast between two ZTIS-capable switches. The switch detects this using additional Juniper LLDP extensions learned from the remote switch.
• Or those are Layer 2 multicast messages in all other cases especially from ZTIS-capable APs attached to ZTIS-capable switch (this includes Juniper Mist Edge tunnels).

Below is a Wireshark packet capture of such a message where we highlighted the most important fields to review.

1. Destination MAC address 0x5d5b35ffff01 is used for all L2 multicast messages to flood the GBP network knowledge to all attached devices. Otherwise, it would be a unicast packet between the ZTIS switches.
2. In the LLC SNAP section, the protocol ID you see:
   1. Protocol ID=0x000b identifies a GBP Update message
   2. Protocol ID=0x000c identifies a GBP Lookup message
3. After the first two bytes of the data field, you see the encoded MAC address of wired and wireless clients.

ZTIS also enhances microsegmentation by adding the ability to enforce policies based on destination IP prefixes. Previously, it was only possible to assign a static GBP tag based on the source IP prefix. With destination IP prefix support, you can now create enforcement policies for traffic leaving the client VLAN and reaching external networks.

When defining multiple destination IP prefixes for enforcement, it is recommended to order them from most specific to most general. The most specific prefixes should appear at the top of the list, with broader prefixes below. This follows the same logic as a traditional firewall, where the first matching rule is applied and subsequent rules are not evaluated. In the example below, source GBP assignments are based on dynamic authentication through RADIUS, such as EAP or MAB, along with several overlapping destination IP rules that define traffic flows outside the local client VLAN.

When creating policies, they must be ordered correctly, as shown in the example below:

1. All rules that match on a destination GBP tag should be placed at the top of the configuration. These rules apply only to traffic within the same VLAN, which is a known limitation of ZTIS.
2. Destination IP prefix rules should be arranged from the longest prefix to the shortest, assuming they do not overlap. This ensures that more specific matches are evaluated first. A rule that permits internet traffic using a /0 prefix should always be the final rule for a given source GBP tag. Destination IP prefixes may also be used for traffic within the same VLAN, but they are required when defining policies for traffic between different VLANs.

Based on the above policy, let’s assume a wired client gets source GBP tag=100 based on RADIUS EAP/MAC authentication. The client can be located in either VLAN:

• VLAN1 with network=10.99.99.0/24 assigned
• VLAN2 with network=10.88.88.0/24 assigned

The table below represents which traffic the client can send to which destination:

Table 1: Source to Destination Processing Example

Source IP GBP tag 100	Destination IP 8.8.8.8	Destination IP 10.11.11.11	Destination IP 10.33.33.33	Destination IP 10.99.99.23	Destination IP 10.88.88.88
VLAN1 10.99.99.23/24	Allowed (internet)	Allowed (fabric)	Allowed (server)	Allowed (wired client)	Denied (vlan1088)
VLAN2 10.88.88.23/24	Allowed (internet)	Allowed (fabric)	Allowed (server)	Allowed but unicast (fabric)	Allowed (wired client)

Note:

Policy enforcement is applied in a single direction, similar to an ACL. You must therefore ensure that traffic intended to be bidirectional is not unintentionally blocked by other rules. In the example, this occurs when the source IP is 10.88.88.23 in VLAN2 and the destination IP is 10.99.99.23 in VLAN1. An ICMP echo request would be forwarded and reach 10.99.99.23, but the ICMP echo reply would be dropped by the vlan1088 rule because it does not permit that return traffic.

Let’s review valid ZTIS topologies and how they work.