diff --git a/pages/1/3(ecmp-symmetric)/1_3_2_1.md b/pages/1/3(ecmp-symmetric)/1_3_2_1.md index 142c145..5267112 100644 --- a/pages/1/3(ecmp-symmetric)/1_3_2_1.md +++ b/pages/1/3(ecmp-symmetric)/1_3_2_1.md @@ -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 diff --git a/pages/1/3(ecmp-symmetric)/1_3_2_2.md b/pages/1/3(ecmp-symmetric)/1_3_2_2.md index 5815bb8..f85385a 100644 --- a/pages/1/3(ecmp-symmetric)/1_3_2_2.md +++ b/pages/1/3(ecmp-symmetric)/1_3_2_2.md @@ -45,17 +45,17 @@ 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 @@ -63,13 +63,12 @@ The figure below is a translation of the figure at the top of this page to a gra [![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 @@ -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: - - diff --git a/pages/1/3(ecmp-symmetric)/1_3_2_3.md b/pages/1/3(ecmp-symmetric)/1_3_2_3.md index ab11d9e..aa8ee11 100644 --- a/pages/1/3(ecmp-symmetric)/1_3_2_3.md +++ b/pages/1/3(ecmp-symmetric)/1_3_2_3.md @@ -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: