Secured Data Transmission experimental

Secured Data Transmission From the control-plane wars to silicon-level switching of any layer, secured against a hostile network Framing: CIA, combinatory axes, and the Hexad as a lens. Locating a transmission-security technique against confidentiality, integrity and availability, reasoning about the combinatory cases, and knowing when the Parkerian Hexad adds resolution the triad hides.. Place a technique against the CIA triad and its combinatory cases (A and I, C and I, A and C).. Explain what the Parkerian Hexad separates that CIA conflates.. Justify keeping CIA as the spine with traceability taught inside integrity and authenticity.. The CIA triad, Combinatory axes, The Parkerian Hexad, Traceability inside CIA Framing: CIA, combinatory axes, and the Hexad as a lens Every mechanism in this course, from spread spectrum to segment routing, is a move against a hostile network. Before building mechanisms we need a disciplined vocabulary for what 'secure transmission' means, so a claim like 'this link is secured' can be checked rather than merely felt. The CIA triad Confidentiality, integrity and availability form the spine of transmission security. Confidentiality means information in transit is disclosed only to authorised parties; the canonical attack is passive eavesdropping. Integrity means data arrives unmodified, or any modification is detectable; the canonical attack is active tampering with ciphertext or headers. Availability means the channel delivers data when needed; the canonical attack is denial, for instance jamming a radio link or cutting a fibre. The triad is popular because it is small and orthogonal enough to reason with, yet each axis maps to a distinct adversary capability: read, write, or deny. Combinatory axes Few real techniques sit on a single axis. Authenticated encryption with associated data binds confidentiality to integrity (the C-and-I case): the ciphertext is hidden and any tampering is detected. Disjoint multipath with secret splitting binds availability to confidentiality (the A-and-C case): losing one path does not deny the message, and no single path observer recovers it alone. A digital signature over a routing update binds integrity to authenticity without necessarily touching confidentiality (the C-and-I case again, from a different mechanism). Reasoning combinatorially prevents a common framing error: declaring a link 'secure' because it is encrypted, while ignoring that encryption does nothing against a jammer who denies the channel outright. Each mechanism should be placed against the axes it actually defends, and, just as importantly, the axes it leaves exposed. The Parkerian Hexad Donn Parker's Hexad refines CIA into six properties: confidentiality, integrity, availability, plus authenticity, utility, and possession or control. Authenticity separates 'this data is unmodified' from 'this data truly originates from the claimed sender,' a distinction CIA blurs inside integrity. Utility captures data that is intact and confidential yet unusable, for example ciphertext whose decryption key has been destroyed: nothing was disclosed or corrupted, but the data is dead. Possession or control captures an adversary holding ciphertext, or a stolen key, without yet having read anything: precisely the harvest-now-decrypt-later threat, where an interceptor stores traffic today against a future cryptanalytic break. CIA alone cannot express that risk cleanly, because nothing has yet been 'disclosed'; the Hexad gives it a name. Traceability inside CIA This course keeps Confidentiality, Integrity, Availability (CIA), not Confidentiality, Integrity, Availability, Traceability (CIAT), as the mandatory spine: adding a fourth first-class axis for every mechanism would fragment the rubric without buying proportionate clarity. Traceability and non-repudiation are instead taught inside integrity and authenticity, since an unforgeable, attributable record of who sent what is functionally an integrity property extended over time and identity. When you assess a design in this course, ask three questions in order: which CIA axis or combinatory pair is defended, whether the Hexad reveals a possession-or-control or utility risk the triad would hide, and whether any traceability claim is actually backed by an authenticity mechanism rather than asserted by policy. That discipline is what separates a real security architecture from a slogan. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Availability under attack: jamming and anti-jam. Jamming as an information-theoretic availability attack, spread-spectrum counter-measures, and quantified processing gain.. Analyse jamming as an attack on channel availability.. Explain spread-spectrum anti-jam and processing gain.. Quantify the margin a given processing gain buys against a jammer.. Jamming as an availability attack, Spread spectrum, Processing gain, Layered anti-jam Availability under attack: jamming and anti-jam A jammer does not read your traffic or forge it; a jammer denies it, by placing enough energy in the channel that the receiver cannot recover symbols reliably. That makes jamming the purest availability attack in this course, and it is best understood information-theoretically rather than anecdotally, because that lets a design's resistance be quantified rather than asserted. Jamming as an availability attack A jammer competes with the legitimate transmitter for the same finite resource: signal-to-noise-and-interference ratio at the receiver. Shannon's channel-capacity result ties the achievable error-free rate to bandwidth and signal-to-noise ratio; a jammer that raises the effective noise floor pushes the achievable rate toward zero, and past a threshold the link fails entirely. Jamming can be broadband (spread thinly across the whole band), partial-band (concentrated on a slice of it), or follower jamming (tracking a frequency-hopping signal). Note the secondary integrity effect: a jammer strong enough to corrupt some symbols without full denial produces undetected bit errors if the receiver's coding is too weak to catch them, so a purely-availability attack can bleed into integrity when coding is inadequate. Spread spectrum The classical counter-measure spreads the signal over far more bandwidth than the information rate requires, so a jammer with fixed total power is diluted across that wider band. Direct-sequence spread spectrum multiplies the data by a high-rate pseudo-random chip sequence known to the receiver; despreading correlates the received signal against the same sequence, coherently reconstructing the data while incoherent jammer energy stays spread and is suppressed. Frequency-hopping spread spectrum instead moves the carrier rapidly across a wide band on a pseudo-random schedule shared with the receiver, so a narrowband jammer only hits the signal on a fraction of hops. Both techniques require the spreading sequence itself to be a shared secret or otherwise unpredictable to the adversary; a known sequence gives no protection. Processing gain Processing gain is the ratio of spread bandwidth to information bandwidth, expressed in decibels, and it is the quantity that turns 'we spread the signal' into an engineering commitment. A design with 30 dB of processing gain suppresses a given jammer's effective power at the correlator output by roughly a thousandfold compared to an unspread signal; a design with only 10 dB buys a factor of ten. Against a jammer of fixed total power, higher processing gain directly raises the jamming margin: the amount of additional jammer power required to deny the link. This is why the course treats processing gain as measurable rather than qualitative: a lab that asserts anti-jam without stating the achieved margin against a modelled jammer has not demonstrated the property. Layered anti-jam No single mechanism suffices in practice. Spread spectrum buys processing gain; forward error correction adds redundancy so the residual errors a diluted jammer still causes are corrected rather than silently accepted, closing the integrity leak noted above; directional antennas and transmit-power control reduce the jammer's ability to couple energy into the receiver at all, and adaptive nulling can suppress a jammer's direction specifically. Layering these controls, and budgeting each one's contribution in decibels, converts 'anti-jam' from a marketing claim into a stack of quantified margins that together set the availability guarantee a hostile network must overcome. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Confidentiality and integrity in transit. Authenticated key exchange, authenticated encryption with associated data, and forward secrecy over an emulated path.. Build an authenticated, forward-secret channel.. Explain why authenticated encryption binds integrity to confidentiality.. Reason about harvest-now-decrypt-later and post-quantum implications.. Authenticated key exchange, Authenticated encryption (AEAD), Forward secrecy, Harvest-now-decrypt-later Confidentiality and integrity in transit Diffie and Hellman showed in 1976 that two parties can agree a shared secret over a channel a passive eavesdropper fully observes, founding public-key cryptography. That result is necessary but not sufficient for a secure transmission channel: raw key exchange, authentication of the peers, and integrity of the payload must all be composed correctly, and each has failed in practice when treated as separate, unrelated bolt-ons. Authenticated key exchange A bare Diffie-Hellman exchange agrees a key with whoever is on the other end of the wire, but says nothing about who that is; an active man-in-the-middle can run two independent exchanges, one with each party, and relay traffic while reading and altering it. Authenticated key exchange binds the exchange to long-term identity keys, typically by signing the ephemeral public values or deriving the session key from a combination of ephemeral and static key material, so each party gets cryptographic assurance the peer is who it claims. This is the difference between 'we agreed a secret' and 'we agreed a secret with the intended party,' and every protocol in this module (Transport Layer Security (TLS) 1.3, IKEv2, WireGuard's Noise-based handshake) exists to close that gap. Authenticated encryption (AEAD) Encrypting a payload without authenticating it is dangerous: ciphertext malleability lets an active attacker flip bits or splice blocks, and because many ciphers are chosen for confidentiality only, that tampering is often invisible to the receiver, converting a confidentiality mechanism into a false sense of integrity. Authenticated encryption with associated data solves this by binding a message authentication code (or an integrated construction such as Advanced Encryption Standard (AES)-Galois/Counter Mode (GCM) or ChaCha20-Poly1305) to the ciphertext, so any modification is detected on decryption. Associated data is authenticated but deliberately left in the clear, for example routing or sequence headers a middlebox must read, so those fields cannot be tampered with undetected even though they are not hidden. AEAD is the canonical occupant of the C-and-I combinatory case introduced in Module 0: one primitive, two axes. Nonce management is part of the design, not an afterthought: reusing a nonce under the same key catastrophically breaks confidentiality, integrity, or both in most AEAD constructions. Forward secrecy A channel has forward secrecy when compromise of a long-term identity key does not expose the content of past sessions. This is achieved by deriving each session's encryption key from fresh, ephemeral key material generated for that session and discarded afterward, so an attacker who later steals the long-term key can authenticate as the party but cannot retroactively recover ciphertext already recorded. A design that instead uses one static shared key for every session has no such property: a single compromise, at any point in the channel's lifetime, exposes everything ever sent, and everything yet to be sent until the key is rotated. Harvest-now-decrypt-later An adversary who cannot break today's cryptography can still record ciphertext now and wait for a future cryptanalytic capability, most notably a sufficiently large quantum computer running Shor's algorithm against the discrete-logarithm and factoring problems that classical key exchange relies on. This is the possession-or-control risk from Module 0 made concrete: nothing has been disclosed yet, but the adversary already holds what they need once capability catches up. The practical mitigations are to deploy post-quantum or hybrid classical-plus-post-quantum key exchange now for any data with a long confidentiality lifetime, to rely on forward secrecy so any one future key compromise cannot reach back through history, and, where neither is available, to bound the sensitivity window of the data itself so its value decays faster than an adversary's capability can arrive. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Key ceremonies and multi-party trust. Split-control key custody, threshold secret sharing, and the operational ceremonies that govern high-value keys.. Model split-control custody for a channel's keys.. Explain threshold secret sharing and quorum recovery.. Describe a real key ceremony and what it defends against.. Split control and dual custody, Threshold secret sharing, Hardware security modules, Key ceremonies in practice Key ceremonies and multi-party trust A key that can decrypt an entire organisation's traffic, or sign the root of a trust hierarchy the internet depends on, is too valuable to trust to a single person or a single unaudited procedure. This module moves from the mathematics of confidentiality and integrity to the organisational controls that keep the keys implementing them from being the weakest link. Split control and dual custody Split control, or dual custody, requires two or more distinct individuals to jointly perform a sensitive operation, so no single insider can unilaterally use, export, or destroy a key. This defends specifically against insider risk and coercion of a lone custodian; it does nothing against jamming or route spoofing, which is exactly why Module 0's discipline of naming the axis a control defends matters. Dual custody can be implemented cryptographically, by splitting a key so both halves are required to reconstruct it, or procedurally, by requiring simultaneous authorisation from two operators inside a hardware boundary that itself never reveals the key. Threshold secret sharing Shamir showed in 1979 how to split a secret into n shares such that any k of them reconstruct it exactly, while any fewer than k reveal nothing at all about the secret, using polynomial interpolation over a finite field: a degree-(k-1) polynomial is fixed by k points, and its constant term is the secret. A (3, 5) threshold scheme tolerates the loss of up to two shares while recovery is still possible, and simultaneously resists any two colluding or compromised holders, since two points do not determine a degree-2 polynomial. This is the same combinatorial trade this course flagged in Module 4's forerunner, path splitting: threshold custody trades availability for confidentiality by design, requiring a quorum to act (protecting against unilateral misuse) while tolerating some share loss (protecting continuity of operations). Hardware security modules A hardware security module keeps key material inside tamper-resistant hardware and performs cryptographic operations internally, so the key is used without ever being exported in a form the operating system, an administrator, or malware on the host can read. Hardware Security Modules (HSMs) typically enforce dual-control policies at the hardware level, log every operation, and respond to physical tampering by zeroising stored keys. They are the mechanism that makes split control and threshold custody operationally real rather than merely procedural: the module can require k-of-n authorisation before it will perform a signing or decryption operation at all. Key ceremonies in practice A key ceremony is a scripted, witnessed, and audited procedure for generating, activating, or using a high-value key, combining the ideas above into a single event. The Internet Assigned Numbers Authority (IANA) Domain Name System Security Extensions (DNSSEC) root key-signing-key ceremonies are the standing real-world example: multiple credentialed trusted community representatives travel to a secured facility, and the ceremony is scripted down to the minute, filmed, and later published, precisely because the root key underwrites the authenticity of the entire DNSSEC chain. A well-designed ceremony provides multiple witnesses and separation of duties so no single participant can subvert it, an auditable and repeatable script so deviations are immediately visible, and tamper-evident storage and logging of every credential and action taken. The absence of any one of these (a single administrator with unwitnessed access, an unscripted procedure, or unlogged hardware) reintroduces exactly the single point of failure that split control and threshold sharing were built to remove. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Path as a variable: multipath and splitting. Treating the path as a controllable security variable: disjoint paths for availability, secret splitting for confidentiality, and the traffic-analysis trade-offs.. Configure disjoint paths so traffic survives a cut link.. Split a secret across paths so no single observer recovers it.. Explain the traffic-analysis cost of multipath routing.. Path diversity for availability, Path splitting for confidentiality, Disjointness and correlated failure, Traffic-analysis trade-offs Path as a variable: multipath and splitting Every mechanism so far in this course has treated the path between sender and receiver as a given. This module treats it as a variable the defender can shape: which links carry traffic, how many independent routes exist, and whether a message travels whole or is divided across routes no single observer sees in full. Path diversity for availability If a single link is cut, jammed, or otherwise denied, a design that depends on that one link loses availability outright regardless of how strong its confidentiality or integrity is. Path diversity routes traffic across multiple physically or logically independent paths, so the failure of any one path degrades rather than denies the channel. This is the A-and-C combinatory case from Module 0 in its purest availability half: multipath is fundamentally an availability control, converting a single point of failure into a set of paths that must all fail simultaneously to deny the channel. Path splitting for confidentiality The same multiplicity of paths can be used differently: instead of sending the whole message redundantly down each path, split the message (or, better, split a Shamir-style secret share of it) across paths, so that an adversary who observes only one path recovers nothing useful about the content. Combined with threshold secret sharing from Module 3, a (k, n) split across n disjoint paths means an eavesdropper must compromise k of them simultaneously to reconstruct the message, turning path multiplicity into a confidentiality control rather than an availability one. This is why multipath is not a single technique but a design choice: the same physical diversity can be spent on redundancy (availability) or division (confidentiality), and a design should state explicitly which it is buying. Disjointness and correlated failure The entire benefit of multipath, in either mode, depends on the paths actually failing independently. Two 'different' paths that both traverse the same undersea cable landing station, the same regional power grid, or the same upstream transit provider are not disjoint in the way that matters: a single event, whether a cable cut, a power failure, or a Border Gateway Protocol (BGP) route leak upstream, can take out both simultaneously, silently collapsing an availability design back to a single point of failure. Verifying disjointness therefore means tracing physical topology and administrative control, not just distinct-looking logical routes, and correlated-failure analysis is a first-class design step, not an afterthought. Traffic-analysis trade-offs Multipath is not free. Splitting traffic across several paths increases the metadata an adversary positioned to observe multiple vantage points can correlate: timing, volume, and path-selection patterns can leak information about the split even when the content itself is protected, and reassembly at the receiver creates a natural correlation point. Path diversity used for availability can also paradoxically aid a well-positioned adversary's traffic analysis, since redundant copies on multiple paths give more opportunities to observe the same flow. The designer must weigh the confidentiality or availability gained against the traffic-analysis surface created, and, where the adversary model includes a global or multi-point observer, consider padding, dummy traffic, or timing decorrelation as a companion control rather than treating multipath as a self-contained solution. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ The control-plane wars: ATM versus IP. Connection-oriented signalled fabric against connectionless IP, and the security consequence of where the control plane lives.. Contrast ATM's signalled control plane with IP's distributed one.. Map each model's attack surface (signalling versus routing trust).. Explain label switching as the first reconciliation.. ATM: signalled virtual circuits, IP: connectionless forwarding, Attack surface by control-plane placement, Toward label switching The control-plane wars: ATM versus IP Beneath every mechanism in this course sits a more basic architectural question: where does the decision about how to forward a packet actually live, and who gets to make it? The 1990s saw two answers fight for the future of networking, and understanding why Internet Protocol (IP) won, and why it then quietly re-imported ATM's ideas, explains the rest of this course's trajectory toward Multiprotocol Label Switching (MPLS), Software-Defined Networking (SDN), and segment routing. ATM: signalled virtual circuits Asynchronous Transfer Mode (ATM) is connection-oriented: before any data moves, a signalling protocol establishes a virtual circuit end to end, reserving resources and fixing a path that every cell on that circuit will follow. Forwarding hardware at each switch needs only a small per-circuit label lookup, which made ATM attractive for hardware speed and for deterministic quality of service, since bandwidth and latency could be reserved in advance. The cost is that the network must maintain per-circuit state at every switch along the path, and nothing moves until signalling completes. IP: connectionless forwarding IP took the opposite position: no connection setup, no reserved path, and no per-flow state in the network. Each router makes an independent, destination-based forwarding decision on every packet using a distributed routing protocol (originally distance-vector and link-state Interior Gateway Protocols (IGPs), later Border Gateway Protocol (BGP) between domains) that floods reachability information rather than signalling circuits. This bought enormous scalability and resilience, since no single failure requires renegotiating a circuit, at the cost of weaker guarantees: no router promises a packet will actually arrive, or arrive on time, and the aggregate path a flow takes can shift underneath it without any endpoint being consulted. Attack surface by control-plane placement The security consequence follows directly from where control-plane trust lives. ATM's signalling is explicit and per-circuit: an attacker must subvert the signalling exchange itself to hijack a circuit, and the fabric's operator retains tight, centralised knowledge of every active path. IP's control plane is distributed trust: every router implicitly trusts the routing advertisements it receives from its peers, and there is no single signalling event to secure, only a continuous stream of route announcements that must each be individually validated (a problem this course returns to directly in the BGP-hijack module). Connection-oriented fabric concentrates the attack surface into a smaller, more auditable signalling channel; connectionless fabric distributes it across every router's routing-trust decisions, trading a smaller but higher-value target for a larger but more resilient one. Toward label switching IP won the traffic, but operators still wanted ATM's forwarding speed and traffic-engineering control. The reconciliation was to keep IP's distributed, connectionless routing for reachability while adding a fast, ATM-like label-switched fast path underneath it: routers agree labels for destination prefixes using a signalling-like protocol, then forward on the label rather than re-examining the full IP header at every hop. That synthesis is Multiprotocol Label Switching, the subject of the next module, and it is best understood as neither a pure victory for IP nor a return to ATM, but a deliberate graft of connection-oriented forwarding efficiency onto a connectionless control plane. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Label switching and MPLS. Adding label tagging to the forwarding pipeline: the label stack, forwarding equivalence classes, and label-based security boundaries.. Configure label tagging in the emulated forwarding pipeline.. Explain forwarding equivalence classes and label stacks.. Reason about the security properties and limits of label separation.. The MPLS label and stack, Forwarding equivalence classes, Label-switched paths, Separation and its limits Label switching and MPLS Multiprotocol Label Switching is the graft described at the end of the previous module: keep Internet Protocol (IP)'s distributed routing for reachability, but insert a short, fixed-length label in front of the packet so interior routers can forward on a simple label lookup instead of a full longest-prefix-match on the IP header. Rosen, Viswanathan and Callon formalised this in RFC 3031, and it remains the dominant technology inside carrier and large enterprise backbones today. The MPLS label and stack An Multiprotocol Label Switching (MPLS) label is a 20-bit value carried in a shim header inserted between the Layer 2 header and the IP packet, alongside a traffic-class field, a time-to-live, and a bottom-of-stack bit. That last bit matters: MPLS supports a stack of labels, pushed and popped like a real stack, which is what lets later mechanisms (Virtual Private Network (VPN) labels beneath transport labels, or the segment-routing label stacks in Module 9) layer multiple forwarding concerns into a single packet without the interior network needing to understand any of them beyond 'forward on the top label.' Forwarding equivalence classes A forwarding equivalence class (FEC) is the set of packets that a router treats identically for forwarding purposes, typically all packets destined to the same egress point or matching the same policy. MPLS's core efficiency move is to make the FEC-to-next-hop decision once, at the ingress edge, encode it as a label, and let every interior router simply swap that label for the next one on the path without re-deriving the FEC itself. This is precisely the label-switched analogue of Asynchronous Transfer Mode (ATM)'s virtual-circuit label lookup, purchased without giving up IP's distributed, connectionless control plane for reachability. Label-switched paths A label-switched path (LSP) is the specific sequence of label-swap decisions, established hop by hop via a Label Distribution Protocol (LDP) for simple reachability-following paths, or Resource Reservation Protocol (RSVP) extended for Traffic Engineering (TE), written RSVP-TE, for explicitly engineered, resource-reserved paths, that a labelled packet will traverse from ingress to egress. Because the path is fixed by the label bindings rather than recomputed hop by hop from the IP destination, LSPs give the operator explicit traffic-engineering control: a path can be steered away from a congested or untrusted link in a way plain IP forwarding cannot express, restoring some of ATM's determinism on top of IP's resilience. Separation and its limits Labels also create security boundaries: an MPLS VPN separates customers by ensuring each customer's traffic only ever carries and is forwarded on labels scoped to their own VPN, with the provider's interior routers never inspecting the customer's IP headers at all, which is a meaningful confidentiality and isolation property in the combinatory sense from Module 0. But that separation is only as strong as the trust boundary of the label-distribution control plane: labels themselves have no cryptographic protection, so an attacker who reaches the interior signalling (a compromised provider-edge router, or a misconfigured trust boundary at a customer handoff) can inject or splice labels and cross the separation. Label switching is a forwarding-plane and traffic-engineering technology first; treating label separation as equivalent to cryptographic isolation is the exact framing error Module 0 warned against. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ SDN: separating the planes. Pulling the control plane out of the box: a logically central controller, the programmable flow table, and the security inversion centralisation creates.. Attach a logically central controller to the emulated network.. Explain the OpenFlow separation of control and data planes.. Analyse the security inversion of centralised control.. Separating control and data planes, The flow table, The controller as policy point, Securing the control channel SDN: separating the planes Multiprotocol Label Switching (MPLS) added a fast label-switched data plane while leaving routing decisions distributed across every router. Software-Defined Networking takes the opposite move: pull the control plane out of every box entirely and centralise it in a logically single controller, leaving switches as comparatively dumb, programmable forwarding devices. McKeown et al.'s OpenFlow paper, and Casado et al.'s earlier Ethane, are the founding texts of this shift. Separating control and data planes In a traditional router, the control plane (computing routes, building forwarding tables) and the data plane (forwarding packets according to those tables) both run inside the same box, tightly coupled to that vendor's software. Software-Defined Networking (SDN)'s core architectural claim is that these two functions do not need to be co-located: the data plane can be a simple, fast, standardised forwarding engine, while the control plane runs as software on a separate, logically centralised controller that programs many switches through an open protocol. This inverts decades of distributed-routing orthodoxy from the Asynchronous Transfer Mode (ATM)-versus-Internet Protocol (IP) module: instead of each device reasoning locally from flooded routing state, one program computes the network-wide forwarding policy. The flow table OpenFlow's data-plane abstraction is the flow table: a set of match-action rules where a match pattern over packet header fields (source and destination addresses, ports, Virtual Local Area Network (VLAN) tags, and more) is bound to an action (forward out a port, modify a header, drop, or send to the controller). When a packet does not match any installed rule, the switch can forward it to the controller as an exception, letting the controller's software decide the new rule to install. This makes the switch's behaviour fully programmable from outside the box, without requiring new forwarding silicon for every new policy, foreshadowing the fully programmable pipelines of Module 10's P4 switches. The controller as policy point Because the controller sees the whole topology and computes forwarding centrally, it becomes the single place where network-wide policy, traffic engineering, access control, and failover logic are expressed, rather than being reconstructed independently and inconsistently at every box. This is a genuine engineering win: policy that used to require touching every router's configuration can now be expressed once and pushed everywhere consistently, and it is the architectural precondition for the Wide Area Network (WAN)-scale traffic engineering covered in the next module. Securing the control channel Centralising the control plane also centralises the consequence of compromising it: the controller becomes a single logical point whose compromise, denial, or manipulation can reprogram or blind the entire network's forwarding behaviour at once, an inversion of the distributed-trust model where compromising one IP router only ever affected that router's local view. The channel between controller and switches must itself be authenticated and integrity-protected (OpenFlow supports Transport Layer Security (TLS) for exactly this reason), the controller's own software attack surface must be minimised and hardened as a high-value target, and production designs typically add redundant controllers and a defined fail-safe or fail-open behaviour for switches that lose contact with the controller, so a controller outage degrades availability gracefully rather than catastrophically. Centralisation buys consistency and programmability; the price is a new, concentrated target that this course's Confidentiality, Integrity, Availability (CIA) framing requires you to name explicitly rather than assume away. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ WAN-SDN at scale. Centralised traffic engineering across sites: driving inter-datacentre links to high utilisation while managing the single logical point of compromise.. Run central traffic engineering across many sites.. Explain how WAN-SDN achieves high utilisation and availability.. Reason about the availability-and-compromise trade-off of a central brain.. Inter-datacentre traffic engineering, High utilisation with central control, Availability engineering, The central point of compromise WAN-SDN at scale Software-Defined Networking (SDN)'s centralised control-plane idea proved itself first inside single datacentre fabrics, then was pushed to its most demanding setting: the wide-area network links connecting an operator's own datacentres across continents. Google's B4 (Jain et al.) and Microsoft's Software-Defined WAN (SWAN) system (Hong et al.) are the two founding case studies, and both report the same headline result, driving inter-site links to utilisation levels classical distributed WAN routing could never safely reach. Inter-datacentre traffic engineering Traditional WAN links are provisioned with substantial headroom because distributed routing protocols cannot coordinate globally in real time: each router reacts to local link state, and reserving margin is the only safe way to absorb bursts and failures without a global view. Inter-datacentre traffic engineering instead uses the SDN model from the previous module at wide-area scale: a central traffic-engineering controller collects demand and topology from every site, computes a globally optimal allocation of traffic to paths, and pushes that allocation down as forwarding state, treating the entire private WAN as one fabric rather than a chain of independently routed hops. High utilisation with central control Because the controller has global visibility of demand and available capacity, it can pack traffic onto links far more tightly than distributed routing dares, prioritising elastic, delay-tolerant bulk transfer (data replication, backups) below latency-sensitive interactive traffic, and reallocating bandwidth in near real time as demand shifts. B4 reported driving some links to close to full utilisation, a level of efficiency that directly reduces the amount of expensive long-haul capacity an operator must buy, which is why Wide Area Network (WAN)-SDN spread rapidly once demonstrated at Google and Microsoft's scale. Availability engineering High utilisation is only safe if the controller also plans for failure: WAN-SDN systems compute traffic allocations that reserve fast-reroute capacity for the highest-priority traffic classes, so that when a link or site fails, priority traffic is guaranteed to fit within the surviving capacity even though the network was run near saturation. This is deliberate availability engineering built into the traffic-engineering objective itself, not an afterthought bolted on after optimising purely for utilisation, and it is what separates a WAN-SDN deployment that survives real failures from an over-optimised one that does not. The central point of compromise The same concentration of control that made high utilisation possible reproduces, at continental scale, the single-logical-point-of-compromise problem from the SDN module: a compromised or malfunctioning WAN traffic-engineering controller can misallocate capacity across every datacentre link simultaneously, potentially starving high-priority traffic across an entire global network in one action, a failure mode no single-router compromise in the old distributed model could produce. Production WAN-SDN deployments mitigate this with redundant controller instances, strict rate limiting and sanity-checking on the changes any single controller decision can push, and a defined fail-safe forwarding state at each site that switches revert to if central control is lost, so the network degrades to a known-safe distributed baseline rather than an unconstrained one. The lesson generalises: every unit of central-control efficiency purchased in this course must be paired with an explicit answer to 'what happens to availability and integrity when this central point is wrong or compromised.' Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Segment Routing: SR-MPLS and SRv6. Collapsing per-hop path state into the packet: source-chosen paths as a label stack or IPv6 segment list, and geo-based L3.. Encode a source path as a segment list.. Contrast SR-MPLS with SRv6 network programming.. Implement geo-based L3 and reason about path integrity.. Segment Routing architecture, SR-MPLS versus SRv6, The path as data the sender writes, Geo-based L3 and path integrity Segment Routing: SR-MPLS and SRv6 Multiprotocol Label Switching (MPLS) needed a signalling protocol (Label Distribution Protocol (LDP) or Resource Reservation Protocol (RSVP) extended for Traffic Engineering (TE), written RSVP-TE) to install per-hop label state at every router along a label-switched path, and Wide Area Network (WAN)-Software-Defined Networking (SDN) needed a central controller pushing that state down continuously. Segment Routing (SR), formalised by Filsfils et al. in RFC 8402, asks whether the interior network needs to hold any of that per-path state at all, and answers no: encode the path as an ordered list of instructions inside the packet itself, and let each router simply execute the next instruction. Segment Routing architecture A segment is an instruction: 'forward toward this node,' 'take this specific link,' or 'apply this service function.' A source node (or a centralised controller acting on its behalf) chooses an ordered list of segments that together express the desired path or service chain, and encodes that list into the packet. Interior routers need no per-flow or per-path state whatsoever; each router only needs to know how to execute the segment currently at the top of the list and advance to the next one, which is why segment routing is often described as collapsing signalled, per-hop path state into source-encoded packet data. SR-MPLS versus SRv6 SR-MPLS reuses the MPLS label stack from Module 6 as the segment-encoding mechanism: each segment is an MPLS label, and the ordered segment list is simply a label stack pushed at the ingress, requiring no new data-plane forwarding behaviour from routers that already understand label switching. SRv6 instead encodes each segment as a 128-bit IPv6 address, stored in a new Segment Routing Header, so segments can be full network-programming instructions with parameters, not just topological labels, letting a segment mean 'perform this specific function at this node' rather than only 'forward toward it' (RFC 8986). SR-MPLS is the lower-friction upgrade path for existing MPLS backbones; SRv6 is the more expressive, IPv6-native design that treats the network as directly programmable from the packet header itself, at the cost of larger headers and requiring IPv6 support throughout. The path as data the sender writes The security-relevant shift is architectural: in classical Internet Protocol (IP) or LDP-signalled MPLS, the path a packet takes is an emergent property of distributed routing state the sender does not control and often cannot even observe; in segment routing, the path is data the sender (or an SR-aware ingress on the sender's behalf) writes directly into the packet. This is a direct instance of Module 4's 'path as a controllable security variable': segment routing gives an operator explicit, packet-level control to route sensitive traffic away from untrusted links or through mandated inspection points, turning path selection from an implicit routing-protocol outcome into an explicit security decision. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Geo-based L3 and path integrity That same explicitness enables geo-based Layer 3 forwarding: segments can encode a requirement that traffic transit only nodes within a specified jurisdiction, supporting data-sovereignty and regulatory requirements by construction rather than by hopeful configuration of distributed routing policy. But writing the path into the packet only helps if the segment list itself cannot be tampered with in flight; an attacker who can rewrite the segment list can redirect traffic exactly as effectively as a route hijack redirects IP traffic. Production SRv6 deployments therefore rely on the network's trust domain being bounded (segment lists are trusted only within an operator's own infrastructure, stripped at the domain edge) and, where segment lists cross less trusted boundaries, on authenticating the header itself, since an unauthenticated 'the path is data' design simply relocates the routing-integrity problem from the control plane into the packet. Silicon-level switching of any layer. Programmable forwarding silicon (the P4 model), switching on any header from L2 to L7 as a compiled artefact, and the market reality of programmable ASICs.. Describe the P4 match-action model of programmable forwarding.. Explain switching on any layer as a compiled data-plane program.. Assess the market reality (Tofino end-of-life; P4 on DPUs and IPUs).. Programmable forwarding silicon, The P4 match-action model, Switching any layer L2 to L7, Market reality and open source Silicon-level switching of any layer Software-Defined Networking (SDN)'s OpenFlow flow table was a fixed set of match fields defined by the protocol specification: if the standard did not define a match on a given header field, no controller could program a switch to act on it. The final architectural step in this course's control-plane arc removes even that limitation, making the forwarding pipeline itself a compiled, programmer-defined artefact rather than a fixed set of vendor-chosen match fields. Programmable forwarding silicon A fixed-function switching Application-Specific Integrated Circuit (ASIC) hard-wires its parsing and matching logic at fabrication time: it can only ever match the header fields its designers anticipated. Programmable forwarding silicon instead implements a configurable pipeline of parsers and match-action stages whose behaviour is defined by a program loaded after fabrication, so the same chip can be reconfigured to parse and act on an entirely new header format, or a new combination of layers, without a hardware respin. This is the same underlying move as segment routing's shift of path logic from signalled network state into explicit data, applied one level down: the forwarding behaviour itself moves from fixed hardware into loaded, inspectable, and versionable software. The P4 match-action model Bosshart et al.'s P4 (Programming Protocol-Independent Packet Processors) is the dominant language for expressing these programs. A P4 program defines a parser that walks the packet's headers in whatever order and format the programmer specifies, a sequence of match-action tables where each table matches on programmer-chosen header fields (or metadata) and executes a programmer-defined action, and a deparser that reassembles the packet for transmission. The program is compiled to a target, whether a programmable ASIC, a Field-Programmable Gate Array (FPGA), a software switch, or a smart network interface card, giving the same source program a path to very different execution environments while keeping the forwarding logic itself protocol-independent and auditable as source code rather than opaque vendor firmware. Switching any layer L2 to L7 Because the parser and match tables are fully programmer-defined, a P4 pipeline can match on Layer 2 Media Access Control (MAC) fields, Layer 3 addresses, Layer 4 ports, or deeper application-layer fields, all within the same compiled pipeline, and can do so in combination, for example matching a specific application protocol signature riding over a specific tunnel encapsulation. This directly supports this course's encapsulation and tagging material: a programmable pipeline can parse and act on nested encapsulation layers, custom security tags, or geo-forwarding metadata that no fixed-function ASIC's predefined header set would recognise, making 'switching on any layer' a property of the compiled program rather than a hardware limitation to work around. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Market reality and open source The leading commercial programmable ASIC, Intel's Tofino, was announced end-of-life in 2023, a market signal that pure programmable-switch silicon has struggled against the economics of high-volume fixed-function chips, even as the programming model it popularised has proven durable. That durability shows in where P4 has migrated: Data Processing Units (DPUs) and infrastructure processing units now widely expose P4 or P4-like programmability for offloading network, security, and storage functions from the host CPU, and the P4 language and its open-source compiler and runtime ecosystem continue to be the reference model taught and used industry-wide regardless of which specific silicon executes it. The lesson for a doctoral engineer is to separate the programming abstraction, which has proven itself durable, from any single vendor's hardware implementation of it, which has not. Layer-2 loops, Spanning Tree, and broadcast storms. Why a Layer-2 loop melts a network, how the Spanning Tree Protocol prevents it, and how a broadcast storm unfolds and is contained.. Explain why a Layer-2 loop causes a broadcast storm (no TTL at L2).. Describe how the Spanning Tree Protocol elects a loop-free topology.. Apply the guards (BPDU guard, root guard, storm control) that prevent storms and rogue-root attacks.. Layer-2 loops and the broadcast storm, The Spanning Tree Protocol, Root election and BPDUs, Guards, RSTP, and attacks Layer-2 loops, Spanning Tree, and broadcast storms Every mechanism examined so far assumed the underlying topology was sound. Step down one more layer and a purely structural hazard appears that has nothing to do with cryptography or routing policy: a redundant physical link at Layer 2, added for the very availability reasons Module 4 championed, can itself become the single fastest way to destroy a network's availability if left unmanaged. Layer-2 loops and the broadcast storm Ethernet frames carry no time-to-live field; nothing in the frame itself limits how many times it can be forwarded. If redundant links create a physical loop between switches, a broadcast frame, or a frame to an unknown destination that a switch must flood out every port, will be forwarded around the loop, re-flooded at each switch, and duplicated exponentially with every circuit, since each switch retransmits every copy it receives out every port except the one it arrived on. Within a small number of loop traversals, this broadcast storm consumes all available bandwidth and switch CPU, and the network becomes unusable within seconds, an availability failure caused entirely by topology, requiring no external attacker at all, and often triggered by nothing more than a technician accidentally plugging both ends of a cable into the same switch. The Spanning Tree Protocol Radia Perlman's Spanning Tree Protocol, standardised as IEEE 802.1D, solves this by having switches cooperatively compute a loop-free logical topology, a spanning tree, over the physical mesh, then blocking traffic on any physical link not part of that tree. Redundant links remain physically connected, preserving the availability benefit of having them, but are logically disabled for normal forwarding and held in reserve, activated automatically if the active tree is broken by a failure elsewhere. This is the Layer-2 analogue of the path-as-a-variable discipline from Module 4: keep physical path diversity, but ensure exactly one loop-free logical path is active at any moment so redundancy provides failover rather than a storm. Root election and BPDUs Switches build the tree by exchanging Bridge Protocol Data Units (BPDUs), first electing a root bridge (the switch with the lowest bridge ID, a combination of a configurable priority and the switch's Media Access Control (MAC) address), then having every other switch compute its shortest path back to that root and designate the corresponding port as its route toward the root, blocking redundant ports that would otherwise create alternate, loop-forming paths. Because the root bridge becomes the reference point for the entire tree's shape, whichever switch wins root election effectively controls the topology every other switch converges to. Guards, RSTP, and attacks That root-election dependency is also the protocol's principal attack surface: a rogue or misconfigured switch injecting BPDUs claiming a very low priority can win root election and pull the entire tree's traffic through itself, an availability and confidentiality risk depending on what it then does with that traffic. Root guard prevents a port from ever accepting a superior BPDU that would make a neighbour the new root, confining root election to trusted switches; BPDU guard disables a port entirely the instant it receives any BPDU at all, appropriate on access ports where only end hosts, never switches, should ever be connected; and storm control rate-limits broadcast, multicast, or unknown-unicast traffic on a port, containing a storm's blast radius even if a loop briefly forms. Rapid Spanning Tree Protocol (RSTP), folded into 802.1D's successor standards, reduces the convergence time after a topology change from the original protocol's tens of seconds to a few seconds, shrinking the window during which either a genuine failure or an injected rogue-root attack can cause disruption before the tree reconverges to a safe state. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Inter-domain routing and BGP security. How the Border Gateway Protocol glues autonomous systems together, why misconfiguration and hijacks break it, and how origin validation and filtering defend it.. Explain BGP path-vector routing between autonomous systems.. Distinguish a prefix hijack from a route leak and give a real example.. Apply RPKI origin validation, prefix filtering and max-prefix limits as defences.. BGP and autonomous systems, Hijacks and route leaks, RPKI, ROAs and origin validation, Filtering, max-prefix and MANRS Inter-domain routing and BGP security Module 5 named Internet Protocol (IP)'s distributed trust model as its principal attack surface: every router trusts the routing advertisements it receives from its peers, with no signalling event to secure. Nowhere is that trust more consequential than at the boundary between networks, where the Border Gateway Protocol, defined by Rekhter, Li and Hares in RFC 4271, is the single protocol gluing every autonomous system on the internet into one reachable whole. BGP and autonomous systems The internet is a collection of autonomous systems, independently operated networks each identified by an AS number, and Border Gateway Protocol (BGP) is the path-vector protocol by which they exchange reachability: an AS announces 'I can reach this address prefix, and here is the sequence of AS hops the announcement has passed through,' and each receiving AS decides whether to accept, prefer, and re-announce that path onward based on its own policy. There is no global authority validating that an AS is actually entitled to announce a given prefix; the protocol is built entirely on each AS trusting what its neighbours tell it, precisely the distributed-trust attack surface Module 5 flagged in the abstract, now made concrete at internet scale. Hijacks and route leaks A prefix hijack occurs when an AS announces a prefix it does not legitimately own or is not authorised to originate, causing some or all of the internet to send that prefix's traffic to the hijacker instead of its rightful owner, whether for traffic interception, denial of service, or simple misconfiguration. A route leak is distinct: a legitimate route is re-announced beyond its intended scope, for instance a customer AS accidentally re-advertising a route it learned from one transit provider to another, turning itself into an unintended transit path for traffic that should never have passed through it. The 2008 Pakistan Telecom incident, which unintentionally hijacked YouTube's prefixes worldwide after an internal censorship announcement leaked to the global routing table, is the standing real-world case study of how a local misconfiguration becomes a global availability and confidentiality incident within minutes. RPKI, ROAs and origin validation Resource Public Key Infrastructure (RPKI) lets a prefix's legitimate holder cryptographically sign a Route Origin Authorization (ROA) stating which AS is authorised to originate that prefix, and at what maximum length. Origin validation then lets any BGP speaker check a received announcement's origin AS against the corresponding ROA, marking it valid, invalid, or unknown, and a network can be configured to reject routes marked invalid outright. This directly defends against the class of hijack where an unauthorised AS originates someone else's prefix, converting the previously unauthenticated 'trust whatever the neighbour announces' model into a partially verifiable one, though it validates only the origin AS, not the full AS-path, so path-manipulation attacks downstream of a valid origin remain a distinct residual risk. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Filtering, max-prefix and MANRS Origin validation is one layer of a broader defence-in-depth practice. Prefix filtering at network boundaries restricts which prefixes a given neighbour, particularly a customer, is allowed to announce at all, containing route leaks and hijacks at the point of ingress rather than relying on every downstream network to catch them. Max-prefix limits cause a BGP session to be automatically torn down if a neighbour suddenly announces far more prefixes than expected, a cheap circuit breaker against both misconfiguration and certain hijack or leak patterns. The Mutually Agreed Norms for Routing Security (MANRS) initiative packages these and related practices, including anti-spoofing filtering and coordination facilitation, into a baseline operators can commit to and be measured against, converting individually sound but optional controls into an industry-wide, auditable norm. SD-WAN: the enterprise overlay. The software-defined WAN overlay enterprises now deploy: transport-independent encrypted tunnels, centralised policy, application-aware path selection, and its security posture.. Explain SD-WAN as a transport-independent overlay with centralised policy.. Design application-aware path selection and failover across underlays.. Reason about SD-WAN security: tunnel encryption, the controller as target, and SASE convergence.. The SD-WAN overlay, Transport independence and encrypted tunnels, Application-aware path selection, Security posture and SASE SD-WAN: the enterprise overlay Wide Area Network (WAN)-Software-Defined Networking (SDN) proved centralised traffic engineering at the scale of one operator's own inter-datacentre backbone. SD-WAN, short for Software-Defined (SD) Wide Area Network, takes the same centralised-control idea and applies it to the very different setting of an enterprise connecting many branch sites over links it does not own or fully trust: broadband internet, Long-Term Evolution (LTE) and 5G, and traditional Multiprotocol Label Switching (MPLS) circuits, mixed and matched per site. The SD-WAN overlay SD-WAN builds a logical overlay network on top of whatever underlying transport each site happens to have, using edge appliances or virtual instances at each location that establish tunnels to each other and to a centralised orchestration point. Centralised policy, defined once and pushed to every site, replaces the box-by-box configuration that classical branch routing required, echoing SDN's core move of separating policy computation from per-device configuration, but applied to an overlay running over links the enterprise does not control end to end, rather than to switches inside a single operator's own fabric. Transport independence and encrypted tunnels Because the overlay does not depend on the properties of any specific underlay, a branch can mix an MPLS circuit, a broadband internet connection, and a cellular backup link, and the SD-WAN fabric treats them as interchangeable paths for its tunnels, each secured independently since none of those underlays can be assumed trustworthy end to end. This transport independence is what makes SD-WAN commercially attractive: enterprises can shift bulk traffic from expensive private MPLS circuits onto commodity broadband while the encrypted tunnel overlay provides the confidentiality and integrity that the private circuit used to provide implicitly through its closed nature. Every tunnel is therefore an authenticated, encrypted channel in the sense of Module 2, since transport independence means the underlay itself contributes essentially no security guarantee at all. Application-aware path selection With multiple paths available per site, the SD-WAN controller can select which underlay path carries which traffic based on real-time measured characteristics such as latency, jitter, packet loss, and available bandwidth, matched against each application's requirements, steering latency-sensitive voice or video onto the best-performing path while routing bulk transfers over cheaper links. This is Module 4's path-as-a-variable idea operationalised as a continuously running control loop: the path is not a static configuration choice but a live decision remade as underlay conditions change, in service of application performance rather than only security. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Security posture and SASE SD-WAN's security posture rests on the strength of its tunnel encryption and authentication, since the underlay transport is assumed hostile by design, and on the centralised orchestrator, which inherits exactly the single-logical-point-of-compromise concern raised for SDN and WAN-SDN controllers: an attacker who compromises SD-WAN orchestration can potentially reconfigure policy and path selection across every connected site at once. Because SD-WAN pushes so much traffic toward direct internet breakout at each branch rather than backhauling it through a central firewall, the industry's response has been to converge SD-WAN's connectivity fabric with cloud-delivered security functions, firewalling, secure web gateways, and zero-trust access, into a single service, marketed as Secure Access Service Edge (SASE). SASE is best understood not as a new primitive but as an architectural acknowledgment that transport-independent, centrally orchestrated connectivity and centrally orchestrated security policy need to be reasoned about, and defended, together. Doctoral capstone: an original artefact on the emulator. Build and defend an original research contribution on the emulator, proving a stated security property and defending it against the Section 5.5 synthesis under an injected constraint.. Build an original artefact that proves a stated security property on the emulator.. Defend the contribution against the control-plane synthesis.. Explain how to absorb an injected constraint and re-solve without losing the property.. Scoping an original contribution, Proving the property on the emulator, Defending against the synthesis, Surviving the constraint injection Doctoral capstone: an original artefact on the emulator Fourteen modules have moved from the framing question of what security even means for a transmission (Module 0), through the physical and cryptographic mechanisms that defend individual axes (jamming and anti-jam, authenticated encryption, key ceremonies, multipath), to the full history and mechanics of the control plane (Asynchronous Transfer Mode (ATM) and Internet Protocol (IP), Multiprotocol Label Switching (MPLS), Software-Defined Networking (SDN), Wide Area Network (WAN)-SDN, segment routing, programmable silicon) and the operational hazards and defences of real deployed networks (Spanning Tree, Border Gateway Protocol (BGP), Software-Defined (SD) Wide Area Network overlays). The capstone requires you to synthesise all of it into one original artefact, not merely recall it. Scoping an original contribution An original contribution at this level is a specific, falsifiable claim: a named security property, defined precisely enough that its presence or absence can be checked mechanically, achieved by a mechanism that is either new or is an existing mechanism from this course applied in a combination or setting not already demonstrated in the modules themselves. A well-scoped capstone states the property in the Confidentiality, Integrity, Availability (CIA)-plus-Hexad vocabulary of Module 0 (which axis or combinatory case, and whether a Hexad refinement such as possession-or-control is load-bearing), names the mechanism drawn from the technique pillars (Modules 1 to 4), the control-plane spine (Modules 5 to 10), or the operational block (Modules 11 to 13), and states the adversary model precisely enough that 'proving the property' has an unambiguous meaning before any code is written. Proving the property on the emulator A doctoral claim about a security property is only as credible as the evidence for it, and this course requires that evidence to be machine-checked on the emulator rather than argued in prose alone: the emulator must actually produce the claimed state, under the stated adversary model, and an automated assertion must verify the property holds, for instance that a jammed link still delivers traffic above a stated rate, that a tampered segment list is rejected, or that a compromised controller cannot exceed a bounded blast radius. A design that is elegant on paper but whose property assertion was never actually run against the emulator has not met the bar; the course's own assessment rule treats an unverified submission as incomplete regardless of the sophistication of its written argument, because an unproven claim is exactly the kind of unfalsifiable assertion doctoral work exists to eliminate. Defending against the synthesis Having proven the property under your chosen mechanism and adversary model, you must then defend the contribution against the course's control-plane synthesis: a critique, grounded in the ATM-versus-IP framing and its descendants, that probes whether your chosen control-plane placement (distributed versus centralised, in-band versus out-of-band, source-routed versus hop-by-hop) actually holds up, or whether it has quietly reintroduced a single point of compromise, an unauthenticated trust boundary, or a combinatory case you did not defend. This defence is where the course's central throughline, that every control-plane design choice trades a distributed attack surface for a concentrated one or vice versa, gets applied to your own work rather than to a historical case study. Related CCI capabilities NetDiagramer - Documentation that is never out of date. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Surviving the constraint injection Finally, an injected constraint, unknown to you in advance, is imposed on your design: perhaps a link is removed, a trust assumption is revoked, or a resource budget is tightened, and you must re-solve while retaining the proven property, or explicitly and precisely state which part of the property is lost and why. This mirrors the central discipline the entire course has been building toward: a security property that only holds under a fixed, favourable set of conditions was never really proven in the doctoral sense, since the value of a rigorously stated property is precisely that you can tell, under a changed constraint, whether it still holds or not.