NET-301 Week 12 -- Capstone Preparation and Presentation

"A design that cannot be defended against specific named alternatives is not a design -- it is a configuration. Defend your choices." -- NET-301 Capstone rubric, Architecture Rationale section

Lecture (90 min)

12.1 What the NET-301 Capstone Requires

The NET-301 capstone is a six-gate evaluation. Gates 1-4 test infrastructure correctness (the network works as designed); Gates 5-6 test analytical depth (you understand what you built and can detect against it). Both layers are required for Tier 2 scoring.

The six Tier 1 gates (must all pass before Tier 2 applies):

Tier 2 scoring (100 pts) applies only after all six gates pass. A student who fails Gate 5 but has otherwise excellent Tier 2 work receives a Tier 2 score of 0.

12.2 Week 12 Checkpoint Agenda

The Week 12 lecture period functions as a structured peer review session. Each student (or pair, for topology-sharing configurations) presents for 10 minutes.

Checkpoint 1: Topology review (3 min). Student shares their Containerlab YAML or a topology diagram. Peers and instructor check:

• Are all required components present? (Minimum: 2 routers + 1 NSM sensor + 1 unknown-protocol server + 1 client)
• Is RPKI infrastructure included?
• Where is the NSM sensor placed relative to the traffic being monitored?

The instructor's question at this checkpoint: "If your sensor is here, what traffic does it miss?" If the student can answer this question with a specific example, they understand the sensor placement. If they cannot, they have a Week 13 task.

Checkpoint 2: Protocol RE status (4 min). Student shows what they know about the unknown protocol:

• Have they identified the magic number and message types?
• How many states have they observed?
• Have they done any active testing with Scapy?

The instructor's question: "What is the highest-confidence claim in your current state machine?" A student who says "I've confirmed state X via Scapy testing" is on track. A student who says "I haven't started the Scapy testing yet" needs a specific Week 13 plan.

Checkpoint 3: NSM detection preview (3 min). Student shows their current Suricata rule draft. Is it syntactically valid? Has it been tested against a live capture? What does it detect, and what does it not detect?

12.3 Architecture Rationale: How to Defend Design Choices

The Tier 2 Architecture Rationale section (40 pts) is where strong students pull away from average students. The rubric requires defending choices against named alternatives -- not describing what you built, but explaining why you built it this way rather than another way.

Template for each design choice:

Choice: [What you chose]
Alternative: [What you could have chosen instead]
Criteria: [The metric or constraint that drives the decision]
Rationale: [Why your choice wins on that criterion in your topology]
Tradeoff: [What you give up by not choosing the alternative]

Example for SR-MPLS vs. OSPF-only routing:

Choice: SR-MPLS with Prefix-SID for traffic engineering
Alternative: OSPF-only with equal-cost multipath (ECMP)
Criteria: ability to enforce specific forwarding paths for latency-sensitive services
Rationale: ECMP distributes load across all equal-cost paths but cannot enforce which
  path a specific flow takes. SR-MPLS's SR Policy with explicit segment lists allows
  the operator to specify the exact forwarding path for a given traffic class.
Tradeoff: SR-MPLS adds configuration complexity (SRGB management, Prefix-SID assignment)
  that pure OSPF-ECMP avoids. For a simple 4-node topology, OSPF-ECMP would be sufficient.

A write-up that contains 5+ such choice-alternative-rationale blocks in the Architecture section earns full marks. A write-up that says "I used SR-MPLS because it is better" earns minimal marks.

12.4 Weeks 13-14: Independent Build and Open Lab

Week 13 agenda: Independent build time. No lecture. Two optional open-lab sessions (2 hr each) scheduled for instructor support.

Week 14 agenda: Grading sessions. 20 minutes per student. Live topology demonstration -- all six gates verified in sequence by the grader. The grader does not reveal which gate failed; the student must diagnose and propose a fix.

Gate check-in protocol for instructors:

Gate 1: ping from client to furthest router. Pass = all pings succeed.
Gate 2: show ip route (or show bgp ipv4 unicast) on each router. 
        Pass = all expected prefixes present with correct next-hops.
Gate 3: ping across VXLAN VNI from one endpoint to another.
        show evpn arp-cache -- Pass = ARP entries from remote VTEP visible.
Gate 4: show rpki tables (or Routinator validate <prefix>/<len> AS<asn>).
        Pass = at least one prefix shows VALID state.
Gate 5: student presents protocol RE write-up. Grader asks:
        "Demonstrate one CONFIRMED claim from your state machine with Scapy."
        Student runs the Scapy test live. Pass = server responds as predicted.
Gate 6: student runs Suricata against a pcap of the unknown protocol.
        Pass = at least one alert fires with the correct SID.

12.5 Capstone Scope Boundaries

In scope for the capstone:

• Any routing protocol covered in Weeks 1-3 (SR-MPLS, SRv6, BGP, OSPF, IS-IS, VXLAN-EVPN)
• RPKI (Week 3)
• eBPF/XDP (Week 5) -- optional advanced gate
• NSM infrastructure from Weeks 6-7 (Suricata, Zeek, RITA)
• The unknown protocol provided for Lab 13 (Weeks 11-12)
• 5G threat modeling (Week 8) -- can appear as an Architecture Comparison Sidebar in the write-up but is not required in the live topology

Not in scope (but mentioned in the write-up as forward pointers):

• Production QUIC decryption infrastructure (commercial product; out of course budget)
• Full red team simulation infrastructure (PT-201 scope; referenced from Week 10 but not required in topology)

12.6 The Write-Up Structure

The capstone report has six required sections (see CAPSTONE.md for full rubric). Week 12 is the time to confirm the structure is started, not to write it.

Section checklist for Week 12 checkpoint:

• Executive Summary: one page; audience = network architect who will read the submission
• Topology Design: diagram + Containerlab YAML + architecture rationale
• Protocol Implementation: SR-MPLS/SRv6/VXLAN-EVPN configuration highlights + RPKI
• Protocol RE Write-up: state machine + message type tables + confidence levels + Lua dissector
• NSM Defense: sensor placement rationale + Suricata rule(s) + test evidence
• Coverage Gap Analysis: what this topology cannot detect, and why

The Coverage Gap Analysis section (Section 6) is the highest-difficulty section and the most commonly underdeveloped. A strong Coverage Gap Analysis names specific attack techniques (from Week 10's evasion catalog, or from the QUIC detection gap in Week 9) and explains why the NSM posture in this topology does not detect them. A weak one says "advanced persistent threats may not be detected."

Reflection Prompts

1. Gate 5 requires a live Scapy demonstration during the grading session. A student who has done all their verification offline (captured responses, not live-tested) will fail if the server is not running during the grading session. How should the capstone setup instructions address this? What is the instructor's responsibility vs. the student's responsibility for ensuring the server is available during grading?
2. The coverage gap analysis requires naming specific techniques that the NSM posture cannot detect. How does the list of undetectable techniques from Week 10's evasion catalog and Week 9's QUIC visibility matrix feed directly into Section 6 of the capstone report?
3. The NET-301 capstone is explicitly broader than a typical university lab: it requires building infrastructure, analyzing an unknown protocol, and writing a detection rule -- all for a single submission. What scaffolding from Weeks 1-11 was specifically designed to prepare students for each of these three components?