Skip to content

Commit

Permalink
adsfadf
Browse files Browse the repository at this point in the history
  • Loading branch information
@menckend
menckend committed Jun 9, 2024
1 parent df94047 commit 71ecf77
Show file tree
Hide file tree
Showing 3 changed files with 37 additions and 106 deletions.
2 changes: 1 addition & 1 deletion pages/1/3(ecmp-symmetric)/1_3_2_1.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ permalink: 1_3_2_1.html
summary: "Not *here*, but not *there* either"
---

This framework relies heavily on the concept of a transit-zone. That is, a (network security) zone which is tasked exclusively with providing transport for traffic between other zones. No workload/hosts are attached to this network, only transport nodes. The "edge"/"perimeter" of this zone is its connection to the firewalls on the perimeter of all the other zones.
This framework relies heavily on the concept of a transit-zone. That is, a (network security) zone which is tasked excusively 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

Expand Down
59 changes: 12 additions & 47 deletions pages/1/3(ecmp-symmetric)/1_3_2_2.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -45,31 +45,30 @@ The BGP-speakers on our network are represented as "nodes" on an un-directed gra

## Properties

* "Statefulness" is a boolean value that describes whether or not a node tracks/enforces connection state for bi-directional traffic flows between two nodes. Put more plainly: "whether the node will refuse to forward traffic if it does not "see" *both* flows in a bidirectional flow-pair between two other nodes.
* This will be important later, when we start building *paths* through the graph
* We depict statefulness in the visual graph by depicting the node with a dashed perimeter (non-stateful nodes have a solid perimeter)
* "Security-zone" is a label/tag used to identify nodes which may communicate with each other *without* passing through a "stateful" node.
* That is to say, that any path between two nodes in different security zones (with different zone-ID values/colors) *must* include at least one stateful node
- "Statefulness" is a boolean value that describes whether or not a node tracks/enforces connection state for bi-directional traffic flows between two nodes. Put more plainly: "whether the node will refuse to forward traffic if it does not "see" *both* flows in a bidirectional flow-pair between two other nodes.
- This will be important later, when we start building *paths* through the graph
- We depict statefulness in the visual graph by depicting the node with a dashed perimeter (non-stateful nodes have a solid perimeter)
- "Security-zone" is a label/tag used to identify nodes which may communicate with each other *without* passing through a "stateful" node.
- That is to say, that any path between two nodes in different security zones (with different zone-ID values/colors) *must* include at least one stateful node
*Conversely, there must be a path between nodes in the same security zone that does *not* traverse any stateful nodes
* We depict the security-zone of a node by coloring the node's perimeter (each unique color is a distinct security zone)
* "Site" is a property of the links between devices on the network
* We will denote edges representing links between nodes in the same site with a label ending in ".0"
* All edges between nodes in the *same* site will have will have identical labels
* We will denote edges representing links between nodes in different sites with a label ending in ".*n*" (where *n* is a non-zero integer)
- We depict the security-zone of a node by coloring the node's perimeter (each unique color is a distinct security zone)
- "Site" is a property of the links between devices on the network
- We will denote edges representing links between nodes in the same site with a label ending in ".0"
- All edges between nodes in the *same* site will have will have identical labels
- We will denote edges representing links between nodes in different sites with a label ending in ".*n*" (where *n* is a non-zero integer)

## Graphs of the topology

The figure below is a translation of the figure at the top of this page to a graph, using the conventions described in the preceding section.

[![image](./grphth-11.svg){:class="img-fluid"}](./pages/1/3(ecmp-symmetric)/grphth-11.svg){:target="_blank"}


The two figures below show the same graph, with the elements' visual orentation shifted, but no changes to the underlying structure of the graph itself.

[![image](./grphth-12.svg){:class="img-fluid"}](./pages/1/3(ecmp-symmetric)/grphth-12.svg){:target="_blank"}



The preceding figures illustrate the following observation of our network/graph's structure:
> For every "non-zero" site value "*n*", a stateful site *n* node is connected to a stateless site *0* node, and a stateless site *n* node is connected to a statefu site *0* node.
## Rules of Inference

Expand All @@ -85,37 +84,3 @@ We use the following rules of inference in building our graph (network topology)
* Edges are labeled using the following conventions
* Connections between edges in the same "site" end in ".0"
* Connections between edges in different "sites" end in ".*n*" where "*n*" is a non-zero integer.








## Observation: Recursion of "zones" and "sites"

It is apparrent from the visual depiction of the graphs that the "transit zone "zone-0" has a parent/child relationship with the "workload-hosting" zones (zones 0.1 - 0.3) and that the "WAN site" (site "0") has a parent/child relationship with the "workload-hosting" sites (sites 0.1 - 0.3) What, if anything does this suggest about recursively defined sites and/or zones? Would there be an value in such constructs in the first place?

### Recursive/nested sites structure

As previously discussed, the concept of "site"is useful to us in this context specifically because of the functional limitations of firewalls and other devices acting as "stateful" nodes on the network/graph. We want the selected paths through the graph/network to be "aware" of whether stateful nodes are in the same site or not. Recursively defined sites, or "sub-sites" are not germane to the use-cases we contemplate here, but *how* they *would* be structured if a relevant use-case presented itself is worth considering.

In order to allow us to represent disjoint nteworks, we will use "0" as am implicit root-level of the site hierarchy (with a single, implicit, node.) We will use the following convention in applying site-labels to edges connecting nodes:
- (Implicit) edges from the implicit root node (to "actual" top-level sites' nodes) are labeled as
- 0.0 If the non-root node has no "children" (where "*n*" is the top level site)
- 0.*n* If the non-root-node has "children" (sub-sites), where the non-root-node is the *nth* isolated group of non-root-nodes
- Edges between nodes at the same "site" (at any level) are labelled with the label of site's connection to the parent-site

-
Within the graph, we would assign a weight of "1.1.1" to any edges that connect to nodes within the same "sub-site". This pattern could be extended to an arbitrary degree of recursion (if there were a use-case to take advantage of it.)

The following figure depicts a topology with the "root" site ("0") having three child-sites ("0.1" - "0.3"), each of which have three sub-site/children ("0.*n*.1 - 0.*n*.3"), which in turn, have their own child/sub-sub-sites ("0.*n*.*m*.1 - 0.*n*.*m*.3") The recursive nature of the sub-site structure is illustrated with dashed circles around each "site", with each parent-level site containing all of each children-sites (and their descendents.)

[![image](./grphth-1.svg){:class="img-fluid"}](./grphth-1.svg){:target="_blank"}

### Recursive security zones

Security zones might also be nested nested using a similar mechanism, although in this case the distinction between child/parent object has a deeper policy significance in the real-world networks that we are modelling. If we entertain the concept of recursively structured network security zones, it becomes quickly apparent that there is a parent-child relationship between "transit zone" and "workload-hosting zone", and that the a workload-hosting-zone with "child" sub-zones *is* the transit-zone for it child/sub-zones. As illustrated in the following figures:


82 changes: 24 additions & 58 deletions pages/1/3(ecmp-symmetric)/1_3_2_3.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,80 +3,46 @@ l1idx: 1
l2idx: 3
l3idx: 2
l4idx: 3
title: "Nested/Recursive Zones"
title: "Nested/Recursive Zones and Sites"
permalink: 1_3_2_3.html
summary: "Not *here*, but not *there* either"
summary: "Are recursively structured 'sub'-zones and/or 'sub'-sites of value?"
---

This framework relies heavily on the concept of a transit-zone. That is, a (network security) zone which is tasked exclusively with providing transport for traffic between other zones. No workload/hosts are attached to this network, only transport nodes. The "edge"/"perimeter" of this zone is its connection to the firewalls on the perimeter of all the other zones.
Having (somehwat) formalized our definitions or "zone" and "site" as well a how represent them on a graph, we consider the innately hierarchical structures of each.

### The *implicit* transit zone
# Sites as a Recursive Concept

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.
We previously established that our concept of "site" in the networks we are contemplating is:
> A region in space (or the set of network nodes in that space) for which we "prefer" paths between nodes "in" that site to remain local to.
In such a topology, a seldom-asked question is:
This gives us a useful construct to address the the "real world" network desgin incentives to avoid un-needed high-latency hops between network nodes. It's worth considering, though:
> are there *other* properties of nodes (or the edges connecting them) that we might want to express a "locality" preference for? Are those properties inherently recursive in structure? Is there value to modeling that hierarchical structure in our graph?
> 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?
Distance/locality *can*, obviously, be sub-divided in a hierarchical manner. "Degree of resiliency" is another property that we might conceivable

The answer proposed here is that the firewall's internal data-plane is constitutes an implicit "transit zone" in such a case, as illustrated in the following digram:

{% capture details %}
[![image](./framework-transitzone-1.drawio.svg){:class="img-fluid"}](./pages/1/3(ecmp-symmetric)/framework-transitzone-1.drawio.svg){:target="_blank"}
{% endcapture %}
{% capture summary %}Show/hide diagram{% endcapture %}{% include details.html %}

The insight that this "transit zone" (which is completely analagous to the "DMZ" zone in an back-to-back-firewall topology where to organizations are interconnected) *exists* in this context becomes important as the framework is further developed.
## Observation: Recursion of "zones" and "sites"

### The multi-VRF implicit transit zone
It is apparrent from the visual depiction of the graphs that the "transit zone "zone-0" has a parent/child relationship with the "workload-hosting" zones (zones 0.1 - 0.3) and that the "WAN site" (site "0") has a parent/child relationship with the "workload-hosting" sites (sites 0.1 - 0.3) What, if anything does this suggest about recursively defined sites and/or zones? Would there be an value in such constructs in the first place?

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:
{% capture details %}
[![image](./framework-transitzone-2.drawio.svg){:class="img-fluid"}](./pages/1/3(ecmp-symmetric)/framework-transitzone-2.drawio.svg){:target="_blank"}
{% endcapture %}
{% capture summary %}Show/hide diagram{% endcapture %}{% include details.html %}
### Recursive/nested sites structure

### Implications/insights
As previously discussed, the concept of "site"is useful to us in this context specifically because of the functional limitations of firewalls and other devices acting as "stateful" nodes on the network/graph. We want the selected paths through the graph/network to be "aware" of whether stateful nodes are in the same site or not. Recursively defined sites, or "sub-sites" are not germane to the use-cases we contemplate here, but *how* they *would* be structured if a relevant use-case presented itself is worth considering.

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.
In order to allow us to represent disjoint networks, we will use "0" as am implicit root-level of the site hierarchy (with a single, implicit, node.) We will use the following convention in applying site-labels to edges connecting nodes:
- (Implicit) edges from the implicit root node (to "actual" top-level sites' nodes) are labeled as
- 0.0 If the non-root node has no "children" (where "*n*" is the top level site)
- 0.*n* If the non-root-node has "children" (sub-sites), where the non-root-node is the *nth* isolated group of non-root-nodes
- Edges between nodes at the same "site" (at any level) are labelled with the label of site's connection to the parent-site

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:
-
Within the graph, we would assign a weight of "1.1.1" to any edges that connect to nodes within the same "sub-site". This pattern could be extended to an arbitrary degree of recursion (if there were a use-case to take advantage of it.)

{% capture details %}
[![image](./framework-transitzone-3.drawio.svg){:class="img-fluid"}](./pages/1/3(ecmp-symmetric)/framework-transitzone-3.drawio.svg){:target="_blank"}
{% endcapture %}
{% capture summary %}Show/hide diagram{% endcapture %}{% include details.html %}
The following figure depicts a topology with the "root" site ("0") having three child-sites ("0.1" - "0.3"), each of which have three sub-site/children ("0.*n*.1 - 0.*n*.3"), which in turn, have their own child/sub-sub-sites ("0.*n*.*m*.1 - 0.*n*.*m*.3") The recursive nature of the sub-site structure is illustrated with dashed circles around each "site", with each parent-level site containing all of each children-sites (and their descendents.)

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.
[![image](./grphth-1.svg){:class="img-fluid"}](./grphth-1.svg){:target="_blank"}

#### Unwanted Zone instantiations
### Recursive security zones

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):

{% capture details %}
[![image](./framework-transitzone-4.drawio.svg){:class="img-fluid"}](./pages/1/3(ecmp-symmetric)/framework-transitzone-4.drawio.svg){:target="_blank"}
{% endcapture %}
{% capture summary %}Show/hide diagram{% endcapture %}{% include details.html %}

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:

{% capture details %}
[![image](./framework-transitzone-5.drawio.svg){:class="img-fluid"}](./pages/1/3(ecmp-symmetric)/framework-transitzone-5.drawio.svg){:target="_blank"}
{% endcapture %}
{% capture summary %}Show/hide diagram{% endcapture %}{% include details.html %}
Security zones might also be nested nested using a similar mechanism, although in this case the distinction between child/parent object has a deeper policy significance in the real-world networks that we are modelling. If we entertain the concept of recursively structured network security zones, it becomes quickly apparent that there is a parent-child relationship between "transit zone" and "workload-hosting zone", and that the a workload-hosting-zone with "child" sub-zones *is* the transit-zone for it child/sub-zones. As illustrated in the following figures:

0 comments on commit 71ecf77

Please sign in to comment.