variousandsundry

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 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.
+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
 
@@ -18,14 +18,14 @@ 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 is constitutes an implicit "transit zone" in such a case, as illustrated in the following digram:
+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:
 
 {% 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.
+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
 

pages/1/3(ecmp-symmetric)/1_3_2_2_2.md

@@ -35,7 +35,7 @@ It is *also* worth considering that *we* (as owners/operators of the network) *c
 
 ## Hierarchical relationship of transit zone (zone "0") to other zones
 
-In terms of how the network/graph is constructed, it doesn't really *matter* whether we consider a "zone" be defined by a shared level of trust, or a shared risk-profile (or the last character of its MAC-address). The *functional* distinction we have is:
+In terms of how the network/graph is constructed, it doesn't really *matter* whether we consider a "zone" be defined by a shared level of trust, or a shared risk-profile (or the last character of its 7 bits of its route-distinguisher). The *functional* distinction we have is:
 
 * Edges may connect *any* two nodes in the *same* zone
 * Edges may connect any transit-zone nodes to stateful-nodes-only in *other* security zones. 
@@ -57,21 +57,20 @@ The following figure depicts the reference topology, modified to add two single-
 
 The initial pattern we are using as the basis for recursion calls for edges between the parent ("0"/"transit") zone its it child-zones ("0.1", "0.2", "0.3") to land on *stateful* nodes in the child-zone, and *stateless* nodes in the parent-zone. We carry that pattern forward here.
 
-### *Stateful nodes* in the child-zone node of an inter-zone-edge
+### *Stateful nodes* in the child-zone node of a zone-depth-traversing edge
 
-Our *definition* of a security zone is based on paths in/out of the zone passing through a stateful node in that zone.
+Our *definition* of a security zone is based on paths in/out of the zone passing through a stateful node in that zone. Hence, a zone-depth-traversing edge *must* terminate on a stateful node.
 
-#### *Stateless nodes* in the parent-zone.
+### *Stateless nodes* in the parent-zone.
 
 Relative to the child-zones, the nominal *purpose* of the parent-zone is to provide a path between its child-zones. The stateful nodes on the "child-zone-side" of each partent/child-zone are "protecting" the nodes within the child-zone, and the nodes within the parent-zone are concurrently protected by those same stateful-edges. Adding a stateful edge to the parent-zone side would only duplicate the existing controls on the child-side edge.
 
 At this point, it would be entirely reasonable to say: "*well, yes... at the **top** of the zone-hierarchy (the data-plane of the multi-zone firewall in the preamble of this paper), there's an implicit trust that the parent/transit zone is "secure", but why should that presumption carry through to **lower zone-depths**?*
 
-The answer to that is: I have no idea if it should or shouldn't. But, if you *don't*, and you decide to have the parent-node of a zone-depth-traversing edge be a stateful node, you'd be better served with two zones at the *same* level of the zone-hierarchy. The only real benefit *inherent* to a hierarchical zone structure is the the stateful-nodes of the *parent* zone are spared from having to process traffic between the sub-zones. The following figure illustrates a set of zone-depth-2 zones (0.1.1, 0.1.2) attached to depth-1 zone 0.1's stateful-node. It also illustrates two zone-depth-2 zones attached to a stateless node in their parent-zone (on the right side of the graph.)
+The answer to that is: I have no idea if it should or shouldn't. But, if you *don't* cary it forward, and you decide to have the parent-node of a zone-depth-traversing edge be a *stateful* node, you'd be better served with two zones at the *same* level of the zone-hierarchy. The only real benefit *inherent* to a hierarchical zone structure is the the stateful-nodes of the *parent* zone are spared from having to process traffic between the sub-zones. The following figure illustrates a set of zone-depth-2 zones (0.1.1, 0.1.2) attached to depth-1 zone 0.1's stateful-node. It also illustrates two zone-depth-2 zones attached to a stateless node in their parent-zone (on the right side of the graph.)
 
 [![image](./grphth-17.svg){:class="img-fluid"}](./grphth-17.svg){:target="_blank"}
 
-
 Observation of the available paths quickly reveals that with the parent-side node of inter-zone-depth edges landing on a stateful node:
 
 * Paths between neighbor child-zones must traverse *three* stateful nodes (rather than two)
@@ -81,3 +80,11 @@ And that with parent-side node of inter-zone edges landing on stateless nodes:
 
 * Paths between neighbor child-zones must traverse *two* stateful nodes (rather than three)
 * Paths between child-zone and parent zone must traverse *one* stateful node (rather than two)
+
+## Summary
+
+When we attempt to reconcile the concept of a "transit zone" with that of a "network security zone", it becomes apparent that:
+
+* The relationship between a "transit zone" and other network security-zones that it is connected to is a parent:child (one:many, hierarchical) one.
+* How we define a network security zone *matters*, with regards to whether recursive security zones is a cogent concept or not
+ * 

pages/1/3(ecmp-symmetric)/1_3_2_3.md

@@ -43,10 +43,23 @@ An important refinement of this problem statement is to qualify it with the foll
 
 ### But, what *kind* of routing protocol?
 
-The scenario discussed in the preamble involved an enterprise network using eBGP, and that is the the scenario that our path-selection algorithm will build on. Notably we will assume that...
+The scenario discussed in the preamble involved an enterprise network using eBGP, and that is the the scenario that our path-selection algorithm will build on, and that we describe here in terms of assumptions about the behavior of nodes on our graph:
+
+* Each node has a unique identifier (we'll call it a "network name" for now)
+* Each node sends/receives messages from the nodes that it shares edges with.
+ * The messages are functionally analagous to BGP UPDATE messages
+ * The "network name" parameter acts as both ASN, router-ID, and network.
+ * Node "1" sends an update of "1" to node 2
+ * Node "2" receives the update, and adds an entry to its forwarding table (
+ * Reach "1" via the edge I just received the update on (the edge between "1" and "2" on the graph)
+ * Node "2" prepends that same update with its own "network name" and a space ("2 1") and sends it to nodes 5,6,7
+ * The behavior of the nodes is equivalent to that of an eBGP peer
+ * Announce the network-name of the sending no
+
+The graph in the following figure modifies the previous figure by removing any explicit textual annotations and adding a "network name" value to each node. The previously discussed properties of the nodes and edges are depicted visually (refer to the key to the left of the graph in the figure.)
+
+[![image](./grphth-19.svg){:class="img-fluid"}](./grphth-19.svg){:target="_blank"}
 
-* Assumption 1...
-* Assumption 2...
 
 
 ## Comparing the paths