This framework relies heavily on the concept of a transit-zone. That is, a (network security) zone which is tasked with providing transport for traffic between other zones. The “edge”/”perimeter” of this zone is its connection to the firewalls on the perimeter of all the other zones.
The implicit transit zone
The “transit zone” is an implicit (but generally unacknowledged) element of any multi-zone topology in which multiple zones’ perimeters are hosted on different interfaces of a single firewall instance.
In such a topology, a seldom-asked question is:
What “zone” is traffic “in” after it enters a firewall’s interface in one zone, but before it exit’s another interface of the same firewall?
The answer proposed here is that the firewall’s internal data-plane constitutes an implicit “transit zone” in such a case, as illustrated in the following digram:
Show/hide diagram
/framework-transitzone-1.drawio.svg)
The insight that this “transit zone” (which is completely analagous to the “DMZ” or “no-man’s-land” in a back-to-back-firewall topology) exists in this context becomes important as the framework is further developed below.
The multi-VRF implicit transit zone
The preceding diagram illustrates firewalls in which a single routing function exists (all interfaces are in a single routing domain.) In many cases, not only are per-zone policy/rule-bases present on such firewalls, but often per-zone virtual routers are present as well. That scenario is illustrated here:
Show/hide diagram
/framework-transitzone-2.drawio.svg)
Implications/insights
The preceding diagram illustrates that multi-zone firewalls are conceptually equivalent to multiple zone-specific firewalls in a mesh topology with each other. We will rely on this insight in our anlaysis of desired forwarding behavior in subsequent sections.
It also suggests that we consider whether there is benefit to extending this implict transit zone within the firewalls’ data planes across the physical network for inter-data-center connectivity. That scenario is depicted below:
Show/hide diagram
/framework-transitzone-3.drawio.svg)
Extending the transit zone past the edge of the firewall appliances, and all the way across the wide-area network is a substantive change. At first blush, it seems likely to create more problems than it solves, but it is a crucial element of the emerging framework. In the meantime though, it solves a pre-existing design inefficiency. Specifically, without the transit zone extended across the WAN, the multi-zone firewall topology introduces an unwanted design constraint for workload placement.
Unwanted Zone instantiations
Without the transit zone extended to the wAN, if there are two sites, and three security zones, what happens if:
- Site 1 only has workload in zones 1 and 2 running (the firewalls there are only provisioned for zones 1 and 2)
- Site 2 only has workload in zones 2 and 3 running (the firewalls there are only provisioned for zones 2 and 3)
- And a host in site-1/zone-1 needs to communicate with a host in site2/Zone3?
If the multi-zone firewall runs a single routing-instance, the traffic in question could end up routed across the zone-2 WAN, but that is not desirable. If there were additional zones present in both sites, those zones’ WAN/IDC links would provide equally attractive paths (creating the need for more arbitrary desing choices to designate a “preferred” zone to act as the transit zone for this traffic).
Alternatively, if we prohibited (through BGP policy configuration) the firewalls from accepting the local zone-2 VRF as a valid next-hop for the remote-site zone-1 and zone-3 networks, there would literally be no path for the s1/z1 <-> s2/z3 traffic. That scenario is illustrated below. (Zone two is omitted completely from the diagram to simplify the depiction):
Show/hide diagram
/framework-transitzone-4.drawio.svg)
The figure above illustrates that there simply is no path for this traffic, but it is apparent that an acceptable path can be created by either:
- Instantiating the zone-1 firewall and VRF in site 2, and the zone-1 VRF in the WAN (peered to the zone-1 VRF in sites 1 and 2), or
- Doing the same thing with the zone-2 firewalls/VRFs.
Unfortunately, there is no design principal we can rely on to tell us which of these options should be preferred, and if we proceeded with both of them, we would re-introduce the equal-cost path dilemna that brought us here in the first place. Additionally, in the absence of any hosted workload in s1/z3 or s2/z1, the the configuring these additional VRFs and firewall instances (or at least zones/interfaces, if a monolithic FW is used) is un-wanted overhead.
This complication exists for any flows in which neither of the two zones in a given flow are “present” at both of the sites in the same flow. The implication here is that every zone (FW, DC-VRF and WAN VRF) must be instantiated at every site to support all potential flows.
Extending the transit zone across the WAN, however, provides us with a transport option that does not require any additional FW instantiations or hosting-compartment VRFs. This is depicted in the following figure:
Show/hide diagram
/framework-transitzone-5.drawio.svg)