NSX Security : Trust on First Use (TOFU) and Trust on Every Use (TOEU) Explained

When dealing with Spoofguard, address learning and distributed firewall (DFW), we need to consider two modes under the IP discovery profile of segments called “Trust on First Use (TOFU)” and “Trust on Every Use (TOEU)”. Understanding these modes is important as this has a dependency with spoofguard as well as to avoid DFW bypassing in few scenarios.

IP discovery profile is used to learn the IP and MAC addresses of VMs attached to segment ports using different methods like ARP snooping, ND snooping, DHCP/DHCPv6 snooping and VM Tools. The discovered IP and MAC addresses are used to achieve ARP suppression in the logical segments. This realized IP/Port binding information is also used by spoofguard and DFW components.

Whenever an IP address is discovered, it is added to the “Discovered bindings table” under the segment from where it is added to the “Realized bindings table”. The way in which realized bindings table is updated depends on two modes – Trust on first use (TOFU) or Trust on Every Use (TOEU). The below screenshots shows the discovered bindings table for a segment port with an IP address 192.168.102.225 which is learned from two sources – ARP snooping and VM Tools.

And below is the corresponding realized binding table.

Let’s take a look the two modes – TOFU and TOEU in more detail.

Trust on First Use (TOFU)

In Trust on First Use (TOFU) mode, when an address is discovered and added to the realized bindings table, that address remains in the realized bindings table forever. TOFU when used alone does not block traffic and is a security feature used along with Spoofguard. TOFU together with spoofguard can prevent a rogue VM from spoofing an IP used elsewhere in the network. It also ensures that the IP addresses of virtual machines cannot be altered without intervention to ensure DFW rules aren’t bypassed in any manner.

By default, ARP snooping and ND snooping operate in the TOFU mode. The default ARP/ND snooped entry age out time is 10 mins and with TOFU enabled the learned entries wont age out and hence stay in realized bindings table forever. The ARP binding limit dictates the maximum number of IPs that can be discovered via ARP snooping and TOFU applies to all the address bindings within the binding limit.

TOFU is enabled by default under the IP discovery profile.

Let’s attach a VM to NSX segment with TOFU enabled and look at realized bindings.

We have a VM “Dev-VM-01” attached to segment “LS-DevApps” with an initial IP address 172.16.50.224. The IP address is discovered from both ARP snooping and VM Tools and will be added to the discovered bindings table which will then go to the realized bindings table.

Let’s change the IP address to 192.168.102.225. Since ARP snooping operate in TOFU mode, we should still see the old IP address (discovered via ARP) in the realized bindings table. The new IP will appear in the realized binding table through VM tools as it doesn’t operate in TOFU mode.

As we keep on changing the IP address, we see that the realized bindings table for ARP snooping will still have the first discovered IP address. However the IP addresses discovered through VM tools gets updated every time in the realized bindings table. This is because VM Tools operate in the second mode called “Trust on Every Use (TOEU)” which we will discuss next.

Trust on Every Use (TOEU)

In TOEU mode, when an address is discovered, it is added to the realized bindings list immediately and when it is deleted or expired, it is removed from the realized bindings list. TOEU is the default mode for DHCP snooping and VM Tools. When we disable TOFU under the IP discovery profile, we automatically switchover the ARP/ND Snooping mode to TOEU mode.

For the same NSX segment discussed earlier, let’s attach a new IP discovery profile with TOFU disabled. This will switch ARP snooping to TOEU mode.

We should now see that the realized bindings list is updated with the new IP address from ARP snooping.

Using TOFU with Spoofguard and Distributed Firewall

Now let’s apply TOFU with Spoofguard and distributed firewall to guarantee DFW rules aren’t bypassed when IP addresses of virtual machines changes. This also means users are restricted from changing IP addresses of VMs and that they require manual approval to do so.

We have a DFW rule to allow ICMP between the VMs in a security group called “Dev_Workloads”.

The security group “Dev_Workloads” have two dev VMs – Dev-VM-01 (192.168.102.225) and Dev-VM-02 (192.168.102.50).

The VMs are on NSX segment with TOFU and spoofguard enabled.

Since TOFU is enabled in the IP discovery profile of the sgment, the first discovered IP addresses are added to realized bindings list as below:

And the VMs are able to communicate over ICMP.

Now let’s assume that a user has changed the IP address of Dev-VM-02 to 192.168.102.70. We see that ICMP traffic is now dropped.

This is because the realized bindings table will only list the first discovered IP address which is the whitelist IP address used in spoofguard. The new IP address is untrusted and will be blocked until this is manually approved.

Approving IP address changes

There are two ways to manually approve IP address changes when used with TOFU and spoofguard.

Using Ignored-binding list
Using Manual-bindings

Ignored binding list

Entries added under ignored binding list are never realized. If the IP of a VM changes, the old IP can be temporarily added to ignored bindings which forces the realized bindings table to recalculate and update the table with the next discovered IP address of the VM (from the discovered binding table based on discovered timestamp)

We now see the new IP (192.168.102.70) added under realized bindings and the VM can now communicate.

The entry in ignored bindings should be deleted if we expect the VM to get the old IP address later.

Note : Ignore list is available only under port level and not under segment level.

Manual bindings

Manual bindings will override the discovered bindings and will solely show up in the realized list. Manual bindings will go as whitelisted entries in spoofguard. Manual bindings need to be done using the manager mode.

And the VM can now communicate

TOFU binding limits

With TOFU enabled, we can define the number of IP address bindings which can be added to the realized binding table. For eg, if the binding limit is set to 2, this means it allows IP changes on the VM two times before spoofguard blocks the traffic. Let’s test this.

ARP binding limit is defined in the IP discovery profile of the segment. Let’s set this to 2.

The discovered IP (192.168.102.50) gets added to realized bindings and the VM has communication.

Let’s assume that the user has changed the IP address of the VM to 192.168.102.65. We see that the new IP is added to realized binding and the VM still has communication.

Now let’s assume the user again changed the IP address, this time to 192.168.102.75. As this is outside the ARP binding limit, this IP is not realized and the VM doesn’t communicate.