NET-301 Instructor Guide

Course: Advanced Network Security (NET-301)
Audience: Students who have completed NET-101 and NET-201
Format: 12 chapters across 14 weeks; 90-min lecture + 90-min lab per chapter
Primary anchors: Kurose-Ross 9e, Bejtlich Practice of NSM, Liz Rice Learning eBPF, Dutt Cloud Native Data Center Networking, Davidoff & Ham Network Forensics

This guide covers Weeks 1-12 in full (v0.2).

Chapter 1: Carrier WAN -- MPLS, Traffic Engineering, Segment Routing

Opening Hook (5 min)

Open with the Pakistan Telecom incident (February 2008): a misconfigured BGP route leaked over YouTube's prefix to the global DFZ, blackholing YouTube for two hours and reaching ~170 countries. The question isn't just "how did this happen" -- it's "why didn't the WAN recover automatically?" MPLS traffic engineering and segment routing exist partly to answer that. MPLS Fast Reroute can reroute around a failed link in under 50 milliseconds; a BGP route leak takes minutes to hours to converge.

Pacing

• Lecture (90 min): Section 1 (WAN scaling, MPLS label format, LER/LSR/LSP): 25 min. Section 2 (LDP vs RSVP-TE, FRR mechanics): 25 min. Section 3 (SR-MPLS: Node/Adj SIDs, SRGB, SR Policy): 20 min. Section 4 (SRv6 SID format and behaviors): 15 min. Architecture comparison table + Kurose-Ross §5.4 weave: 5 min.
• Lab (90 min): Lab 1 is a 5-router Containerlab SR-MPLS topology. Part A (bring-up): 20 min. Part B (IS-IS with SR): 30 min. Part C (SR Policy explicit segment): 30 min. Report write-up: 10 min.

Common Issues

1. Students conflate the label stack with the IP header. Draw the Ethernet/IP/MPLS stack on the board and physically point to where the label sits (between IP and Ethernet). The stack flag bit (S=1) is the only way to know you're at the bottom.
2. Prefix-SID index vs. absolute label. Students set segment-routing prefix-sid index 101 and expect label 101. Remind them: label = SRGB base + index. If SRGB starts at 16000, Prefix-SID index 101 → label 16101. Show show mpls table to confirm.
3. SR Policy color attribute. Students often skip setting color on the SR Policy and then wonder why the policy isn't selected. The color must match a BGP color community or explicit route-policy color to steer traffic.
4. FRR config file vs. vtysh. Containerlab FRR nodes load frr.conf at boot. Changes made via vtysh in a running session persist only until restart unless explicitly saved (write memory). Reinforce this to avoid mysterious "why did my config disappear" issues after container restart.

Anchor Weave Placement

Kurose-Ross 9e §5.4 ("The Internet Control Message Protocol") is foundational background. The more targeted weave for this chapter is the MPLS material, which Kurose-Ross treats briefly but correctly in §5.4.3. Point students there for the label format table. The Dutt reference (Cloud Native Data Center Networking Ch 1-2) covers the "why MPLS at carrier scale" question well and is worth assigning as independent reading for the first week.

Lab Timing Note

Part C (SR Policy with explicit segment list) is the hardest part of Lab 1. Budget 30 min and circulate during it. The most common failure is setting the SR Policy's candidate path with the correct Adj-SIDs but forgetting to verify with traceroute --mpls. If traceroute doesn't show labels, the SR Policy is not active -- check show segment-routing traffic-eng policy all detail.

Chapter 2: Datacenter Fabric -- Clos Topology, VXLAN, EVPN

Opening Hook (5 min)

Facebook's 2013 blog post "Introducing Data Center Fabric, the Next-Generation Facebook Data Center Network" (still publicly accessible) describes their move from three-tier to Clos topology. The punchline: three-tier topology meant any pod-to-pod traffic traversed the core layer and back -- a 2-hop core traversal for what should be a local conversation. Clos removes that bottleneck. Draw the old three-tier first, then the fabric. Students immediately see why bisection bandwidth matters.

Pacing

• Lecture (90 min): Section 1 (three-tier failure mode, Clos definition, spine-leaf): 20 min. Section 2 (VXLAN frame format, VTEP mechanics): 20 min. Section 3 (EVPN route types 1-5, ARP suppression): 25 min. Section 4 (symmetric IRB, L3VNI, eBGP unnumbered): 20 min. Sidebar + Dutt weave: 5 min.
• Lab (90 min): Lab 2 is a 2-spine/4-leaf VXLAN-EVPN Containerlab fabric. Part A (underlay eBGP unnumbered): 20 min. Part B (VXLAN/EVPN config): 30 min. Part C (VM mobility demonstration): 30 min. Report: 10 min.

Common Issues

1. Route Type confusion. Students conflate RT-2 (MAC/IP advertisement) with RT-5 (IP prefix route). Give the one-line distinction: RT-2 is "I own this MAC address (and optionally this IP)"; RT-5 is "I can route this IP prefix." ARP suppression relies on RT-2 cached ARP entries at the VTEP.
2. Symmetric vs. asymmetric IRB. The key distinction is which VTEP performs L3 routing. Asymmetric: the ingress VTEP routes and then bridges -- no L3VNI needed, but every VTEP must know every VRF. Symmetric: ingress VTEP routes to the L3VNI transit segment; egress VTEP routes to the destination -- scales better because VRF state is localized.
3. eBGP unnumbered RFC 5549 confusion. Students ask "how can BGP peer without an IP address?" The answer: IPv6 link-local addresses are used for the BGP session; IPv4 prefixes are then advertised with the next-hop encoded as an IPv6 address per RFC 5549. Show show bgp ipv4 unicast neighbors to reveal the link-local next-hop.
4. VTEP flood domain. Before ARP suppression is working, unknown unicast is flooded. Students sometimes see correct pings but wonder why there's broadcast traffic. Confirm show evpn arp-cache populates correctly after first ping before marking ARP suppression as functional.

Anchor Weave Placement

Dutt Cloud Native Data Center Networking Ch 4 (VXLAN) and Ch 5 (EVPN) are the primary references. Assign Ch 4 before Week 2 lecture. The Kurose-Ross framing (§4.3 IP addressing; §5.4 routing protocols) gives the general control-plane context. For the hyperscaler adoption timeline in the Architecture Comparison Sidebar, the Facebook, Google, and Microsoft network engineering blog posts (publicly available) are more concrete than any textbook.

Lab Timing Note

VM mobility (Part C) requires Docker containers at known IP addresses on different leaves. Pre-stage the topology YAML and container launch commands in the lab document. The most common failure: students detach a container and re-attach it to a different leaf but don't wait for the EVPN RT-2 update to propagate. Show watch -n1 'vtysh -c "show evpn mac vni all"' on the spine to observe the MAC move in real time.

Chapter 3: Internet Scale -- BGP Scaling, RPKI, Prefix Hijack Defense

Opening Hook (5 min)

Show the Cloudflare blog post from June 2019: "Cloudflare outage caused by bad software deploy" -- except it was actually triggered by a small ISP (Verizon) accepting a route leak from Allegheny Technologies that de-preferred Cloudflare's paths. The blog post opens: "Today we saw a BGP route leak cause significant disruption." Then show the BGPMON data for the route leak window. Route security is not a theoretical concern -- it is a recurring operational failure mode affecting major infrastructure.

Pacing

• Lecture (90 min): Section 1 (iBGP full-mesh O(n^2), Route Reflectors): 25 min. Section 2 (BGP communities: well-known + large): 15 min. Section 3 (RPKI: ROA structure, validation states, RTR): 25 min. Section 4 (historical hijack cases, MOAS detection, operator practice): 20 min. Kurose-Ross framing: 5 min.
• Lab (90 min): Lab 3 is Routinator + FRR RPKI validation. Part A (Routinator Docker): 20 min. Part B (5 test ROAs): 30 min. Part C (prefix hijack simulation): 30 min. Report: 10 min.

Common Issues

1. maxLength semantics. Students consistently get this wrong on their first attempt. The ROA's maxLength field sets the maximum prefix-length that the origin AS is authorized to announce. A ROA for 203.0.113.0/24 with maxLength 24 means /25 or longer is Invalid (not covered). A ROA with maxLength 25 would cover /24 and /25 but not /26.
2. RTR session startup delay. Routinator takes time to sync from the RIR trust anchors on first boot. The lab uses a Docker volume to cache TAL data, but students will still see a 30-60 second window where show rpki cache-server shows "down." Tell them to run docker logs routinator --tail 20 to watch sync progress.
3. "Invalid" vs. "NotFound" behavior. By default, FRR's match rpki invalid route-map entry drops Invalid routes. NotFound routes are accepted by default (this is the IETF-recommended baseline). Students sometimes expect NotFound to also be rejected, leading to confusion about the model.
4. bgp-hijacker container not in FRR image. The bgp-hijacker container for Part C needs its own Containerlab node. Walk through the topology YAML addition before students start -- this is the part of the lab most likely to stall on configuration.

Anchor Weave Placement

Kurose-Ross 9e §5.3 (BGP) is the primary weave. §5.3.2 covers Route Reflectors correctly; §5.3.4 touches prefix hijacking. Assign §5.3 before Week 3. The RPKI material is not in Kurose-Ross -- direct students to RFC 6480 (Architecture for RPKI) and the NIST SP 800-189 (BGP security guidelines). Both are publicly available. The Cloudflare blog post is an excellent independent practice reading.

Lab Timing Note

Part C (prefix hijack simulation) is the anchor of Lab 3. The dramatic moment is seeing the Invalid route appear in show bgp ipv4 unicast with a RPKI state tag, then confirming FRR's route-map drops it. If Routinator isn't synced when students get to Part C, have them proceed with Part A and B first -- Routinator usually completes its initial sync within 5-8 minutes of container start.

Chapter 4: Network Automation -- Ansible, Nornir, GitOps

Opening Hook (5 min)

The 2016 Rogers Communications outage (Canada) affected 911 services for eight hours. The post-incident report attributed the initial trigger to a manual configuration change that propagated incorrectly through the network. Manual changes at scale create correlated failure risk. Open with this question: "What would have to be true about your change process for this not to happen?" The answer points directly to idempotent automation and change review pipelines.

Pacing

• Lecture (90 min): Section 1 (Ansible concepts, idempotency principle, YAML structure): 20 min. Section 2 (Nornir Python-native approach): 20 min. Section 3 (NAPALM multi-vendor abstraction): 15 min. Section 4 (GitOps IaC workflow, security considerations): 25 min. Dutt Ch 9 weave: 10 min.
• Lab (90 min): Lab 4 uses the Lab 1 or Lab 2 topology as the managed network. Part A (Ansible playbook, two-run idempotency): 40 min. Part B (Nornir script): 30 min. Part C (Jinja2 template): 20 min.

Common Issues

1. Ansible changed_when: false vs. idempotency. Students conflate suppressing "changed" output with actual idempotency. Explain: changed_when: false on a read-only task (like show bgp summary) correctly marks it as not-changed. The actual idempotency check is the when condition that skips the write task if the desired state already exists.
2. FRR network_os support. The ansible_network_os: frr setting relies on the ansible.netcommon collection. Students running on fresh systems often hit ModuleNotFoundError. Walk through pip3 install ansible ansible-pylibssh and ansible-galaxy collection install ansible.netcommon before lab time.
3. Nornir changed tracking. The example Nornir script returns a Result with changed=True/False. Students sometimes don't realize they need to explicitly set changed=False on the "already configured" path -- the default Result doesn't infer change state from the device.
4. Jinja2 template whitespace. FRR configs are whitespace-sensitive. A Jinja2 {% for %} loop that doesn't control whitespace correctly will generate tabs or extra blank lines that cause FRR's config parser to fail. Show {%- for -%} whitespace control strips in the template.

Anchor Weave Placement

Dutt Cloud Native Data Center Networking Ch 9 ("Network Automation") is the primary anchor. Assign before Week 4. The GitOps section connects directly to what students already know from prior software engineering: it's "git for network config" -- the same PR/review/merge model applied to infrastructure state.

Lab Timing Note

Part A takes the most time. Students frequently debug SSH connectivity issues between the Ansible controller and Containerlab nodes -- confirm ssh root@<clab-ip> works manually before starting the playbook. The second most common issue: vtysh syntax differences between FRR versions. Have the FRR version pinned in the Containerlab YAML and double-check the cli_config command syntax against that version.

Chapter 5: eBPF/XDP -- Line-Rate Kernel Networking

Opening Hook (5 min)

In 2019, Cloudflare published "L4Drop: XDP DDoS Mitigations" describing their migration from iptables to XDP for DDoS mitigation. The performance difference: iptables saturates a CPU core at ~1 million packets per second; XDP achieves ~14 million packets per second on the same hardware by dropping packets before the kernel even builds an sk_buff. Open with this number: 14x. Then ask: "If the attacker is sending 14 million packets per second of garbage, where do you want to enforce the drop?"

Pacing

• Lecture (90 min): Section 1 (line-rate problem, eBPF execution model, verifier): 25 min. Section 2 (BPF program types, BPF maps): 15 min. Section 3 (XDP modes and verdicts, complete XDP C program walkthrough): 25 min. Section 4 (Cilium: eBPF-native Kubernetes, Hubble, Tetragon): 20 min. Sidebar + Liz Rice weave: 5 min.
• Lab A (90 min): Lab 5 (eBPF/XDP program authoring): Part A (packet counter): 30 min. Part B (IP blacklist): 30 min. Part C (XDP vs iptables performance): 30 min.
• Lab B (90 min): Lab 6 (Cilium Kubernetes networking): Parts A-D as specified.

Common Issues

1. eBPF verifier rejections. This is the top student frustration. The verifier rejects programs with unbounded loops, uninitialized variables, and missing pointer bounds checks. Emphasize: every pointer dereference must be preceded by a bounds check against data_end. The pattern if ((void *)(ip + 1) > data_end) return XDP_PASS; is not optional.
2. clang BPF target vs. native. Students sometimes compile without -target bpf and get an x86 object file that ip link set xdp obj rejects. The compile command is clang -O2 -target bpf -c. The -O2 is also required -- the verifier rejects non-optimized BPF bytecode in some kernel versions.
3. PERCPU_ARRAY vs. ARRAY semantics. BPF_MAP_TYPE_PERCPU_ARRAY stores a separate value per CPU core. bpftool map dump shows an array of per-cpu values; the user-space reader must sum them. Students expecting a single integer are confused by the JSON array output.
4. Cilium kind cluster DNS resolution. After kind create cluster, CoreDNS pods may not be ready until Cilium installs. Students who try kubectl exec immediately after cluster creation often hit DNS failures. Have them run kubectl rollout status -n kube-system deployment/coredns --timeout=120s before proceeding.
5. L7 policy requires HTTP parser. CiliumNetworkPolicy with toPorts.rules.http requires Cilium's HTTP parser (based on Envoy). If Hubble shows DROPPED but the HTTP code is 403, Cilium's L7 enforcement is working. If it's a connection timeout, Cilium's HTTP parser isn't engaged -- check cilium config | grep l7-proxy.

Anchor Weave Placement

Liz Rice Learning eBPF Ch 1-3 is the primary anchor for the eBPF section. Assign Ch 1 (introduction + "Hello World" XDP program) before Week 5. The Liz Rice book has a companion GitHub repository (lizrice/learning-ebpf) with working examples that supplement the lab. Dutt Ch 8 covers Cilium architecture in the context of cloud-native data centers.

Lab Timing Notes

Lab 5 Part C (XDP vs iptables performance measurement) requires two machines (or containers with network namespaces) for iperf3. Pre-configure the test environment before lab time: two Containerlab nodes connected back-to-back, or two network namespaces linked with a veth pair. Students running on a single machine will need to use namespaces (ip netns).

Lab 6 requires Docker pull of kennethreitz/httpbin which is ~500 MB. Pre-pull before lab: docker pull kennethreitz/httpbin. Also pre-download the Cilium CLI binary if the lab environment has limited bandwidth.

Chapter 6: NSM at Scale -- Suricata Cluster, Zeek Pipeline, SIEM

Opening Hook (5 min)

The 2020 SolarWinds intrusion went undetected for nine months. Post-incident analysis revealed that the attacker's SUNBURST backdoor made C2 connections that were individually indistinguishable from legitimate SolarWinds telemetry traffic. Detection required correlating four data types simultaneously: full-content (the actual HTTPS payloads), session data (connection timing patterns), statistical analysis (connection frequency to Avsvmcloud.com), and alert data (Suricata rules for known-bad JA3 hashes). Open with this: "What NSM infrastructure would you need to have caught SUNBURST on day one?" Then build toward the answer through the chapter.

Pacing

• Lecture (90 min): Section 1 (Bejtlich four-data-types at scale): 20 min. Section 2 (Suricata AF_PACKET cluster_flow mode, EVE JSON, Suricata-Update): 25 min. Section 3 (Zeek cluster mode: manager/logger/proxy/worker; log pipeline): 25 min. Section 4 (SIEM integration: Wazuh + Elasticsearch; correlation patterns): 15 min. Bejtlich weave: 5 min.
• Lab (90 min): Lab 7 (Suricata cluster + Zeek pipeline + SIEM). Part A (Suricata offline analysis): 30 min. Part B (Zeek analysis): 30 min. Part C (SIEM correlation rule): 30 min.

Common Issues

1. Suricata cluster_flow vs. cluster_qdisc vs. cluster_cpu. Students often confuse the AF_PACKET cluster types. For NSM, cluster_flow is almost always correct: it hashes flows to a single worker, ensuring all packets in a TCP session land on the same Suricata thread. cluster_cpu distributes by CPU -- simpler but breaks flow coherence.
2. Zeek JSON vs. ASCII log format. The LogAscii::use_json=T flag is essential for the lab's Python analysis scripts. Without it, Zeek writes TSV logs that the JSON parser rejects. Students who forget this flag and then run the script see json.JSONDecodeError on every line.
3. RITA import path. rita import <zeek-log-dir> <dataset-name> requires the directory, not individual files. Students sometimes pass conn.log directly and get an import error. Also: RITA's show-beacons output is only meaningful after the rita analyze step -- many students skip this intermediate step.
4. Elasticsearch Watcher availability. Watcher requires the Basic (free) or higher license tier. On a fresh Docker deployment, students need to activate the 30-day trial (POST /_license/start_trial?acknowledge=true) or use the community Watcher equivalent. If licensing is an issue, substitute a Kibana alerting rule for the Watcher exercise.

Anchor Weave Placement

Bejtlich Practice of NSM Ch 1 (four data types), Ch 5 (Suricata tuning), and Ch 6 (Zeek) are the three primary placements. Assign Ch 1 before Week 6 -- it's foundational framing. The four-data-types taxonomy should be introduced at the start of the lecture and referenced explicitly as each tool (Suricata, Zeek, Elasticsearch) is positioned. The SolarWinds example maps precisely onto the four types; walk through that mapping explicitly.

Lab Timing Note

Lab 7 requires the four academy NSM corpus pcap files (normal-traffic-24h.pcap, intrusion-lateral.pcap, c2-beacon.pcap, exfiltration-dns.pcap). These must be pre-staged in ~/academy-corpus/ before lab time. The normal-traffic-24h.pcap is the largest -- Suricata offline analysis may take 2-3 minutes. Have students run the Suricata analysis commands on all three corpus files simultaneously in separate terminals to save time.

Chapter 7: Threat Hunting and Network Forensics

Opening Hook (5 min)

Richard Bejtlich's opening line in Practice of NSM: "Assume breach." The operational posture has shifted: you're not trying to prevent all intrusions -- you're assuming some will succeed and building the capability to detect and respond. Threat hunting is the proactive discipline: you're not waiting for a Suricata alert; you're actively looking for evidence of compromise in traffic that hasn't triggered any signature. Open with this question: "If a sophisticated attacker has been in your network for 30 days without triggering a single Suricata rule, how do you find them?"

Pacing

• Lecture (90 min): Section 1 (threat hunting vs. signature detection; baseline generation): 20 min. Section 2 (JA3/JA3S fingerprinting, RITA beaconing analysis): 25 min. Section 3 (Wireshark forensics depth: TCP stream, Export Objects, tshark scripting): 20 min. Section 4 (multi-phase attack lifecycle, forensics reconstruction methodology): 20 min. Davidoff & Ham weave: 5 min.
• Lab (90 min): Lab 8 (threat hunt -- reconstruct a multi-phase intrusion timeline). Part A (timeline reconstruction): 45 min. Part B (RITA beaconing analysis): 20 min. Part C (JA3 analysis + custom Suricata rule): 25 min.

Common Issues

1. Zeek log timestamp units. Zeek's ts field is Unix epoch in floating-point seconds. Students who try to sort by string comparison get wrong results for events within the same second. The timeline script in Lab 8 uses float(e['ts']) correctly -- draw attention to this.
2. RITA beacon scoring. RITA's beacon score is a jitter percentage: lower = more regular = more suspicious. Students intuitively expect higher score = more suspicious. Emphasize: a score of 2.1% means 2.1% jitter in the beacon interval -- nearly perfectly periodic, which is highly suspicious. A score of 80% means highly irregular -- could be human traffic.
3. JA3 database lookups. The ja3.me and sslbl.abuse.ch databases have rate limits. If the lab environment doesn't have internet access, pre-download the SSLBL JA3 fingerprint CSV (curl https://sslbl.abuse.ch/blacklist/ja3_fingerprints.csv) and have students grep it locally.
4. Wireshark TCP stream reassembly. Students trying to follow a TLS stream see only encrypted data. This is expected -- the goal is to analyze the TLS metadata (JA3, SNI, certificate) not the payload. Redirect students to the ssl.log in Zeek for the parsed TLS metadata rather than trying to decrypt in Wireshark.
5. Suricata JA3 rule syntax. The ja3.hash keyword is a Suricata 6.0+ sticky buffer. Students on older Suricata builds will see "unknown keyword" errors. Pin the Suricata version in SETUP.md and verify suricata --build-info | grep HAVE_JA3.

Anchor Weave Placement

Davidoff & Ham Network Forensics Ch 1 (methodology), Ch 3 (traffic analysis), and Ch 11 (malware traffic) are the primary placements. Assign Ch 1 before Week 7. The Davidoff & Ham framing around chain-of-custody requirements is important for students who will work in environments where forensic evidence may be used in legal proceedings. The chain-of-evidence paragraph should be woven into the Lab 8 report instructions.

Lab Timing Note

Lab 8 Part A (timeline reconstruction) is the most time-intensive. The unified timeline script produces up to 200 events; students need to manually scan for the three key events (initial access, lateral movement, exfiltration). Pre-highlight the three event types in the lab instructions so students know what pattern to look for. If time runs short, Parts B and C can be completed as independent work -- Part A is the core forensics exercise.

Chapter 8: 5G Core Network and Protocol Security

Opening Hook (5 min)

Show the GSMA's "5G Security Architecture" one-pager. Point to the SUCI block in the registration flow. "This one box represents 30 years of engineering. Every cellular generation before 5G transmitted the subscriber's permanent identity in plaintext at least once during registration. An IMSI-catcher could harvest identities passively. 5G's answer is a single ECIES encryption -- the phone generates a fresh ciphertext every registration using the operator's public key, and only the operator's UDM can decrypt it. Tonight you're going to watch that sequence in a packet capture."

Pacing

• Lecture (90 min): Section 8.1 (SBA architecture, N-interfaces): 15 min. Section 8.2 (5G-AKA 6-step sequence): 25 min (draw on board alongside students reading the handout). Section 8.3 (SUCI/SUPI privacy): 15 min. Section 8.4 (attack classes): 20 min (table walkthrough). Section 8.5 (Open5GS/UERANSIM architecture): 15 min.
• Lab (90 min): Labs 9 and 10 are the Week 8 labs. Lab 9 is the capture lab; Lab 10 is the threat modeling exercise. Lab 9 is the priority -- if time is short, Labs 10 can be completed as independent work.

Common Issues

1. Open5GS bring-up failures. The most common issue is AMF IP misconfiguration in the UERANSIM gNodeB config. Before lab starts, verify the AMF container IP via docker inspect and confirm the gNodeB config points to it. The quickstart handout handouts/net-301-5g-open5gs-quickstart.md documents all common failures and fixes.
2. Students who haven't read the AKA handout. The lecture's efficiency depends on students having read handouts/cross-chapter-wireless-aka-progression.md in advance. Cold-call a student to name the three AKA comparison axes at lecture start. If most students haven't read it, spend 10 extra minutes on Axis 1 (trust anchor) and Axis 2 (identity privacy) -- these are what the lab makes concrete.
3. 5G SA vs. NSA confusion. Many students have heard "5G" in consumer contexts and assume it refers to NSA deployments (most real-world 5G deployments as of 2026 are NSA). Clarify at the start: the lab uses 5G SA (standalone). NSA security properties are covered in the comparison table but the lab only exercises SA.
4. Wireshark NGAP dissector not showing NAS-5GS fields. This is a Wireshark version issue -- NAS-5GS dissection requires Wireshark 3.6+. Confirm lab machine Wireshark version before the session. Fallback: use tshark with -Y nas-5gs to filter NAS messages.

Anchor Weave Placement

Kurose-Ross §8.8.2 covers 5G-AKA with a clear 6-step sequence and SUCI explanation. Assign it as required pre-reading for Week 8. The handouts/cross-chapter-wireless-aka-progression.md is a deeper cross-track synthesis -- it's the reading that contextualizes §8.8.2 within the broader WPA2/WPA3/5G-AKA progression.

Lab 9 / Lab 10 Timing Note

Lab 9 (15 pts, 90 min lab): Part A (deployment) = 30 min; Part B (Wireshark annotation) = 30 min; Part C (Suricata rule) = 20 min. The deployment setup is the single most likely failure point. Pre-test the Open5GS Docker Compose + UERANSIM on the lab hardware before the session.

Lab 10 (20 pts, 3 hr independent): designed for independent work after Lab 9. Students who struggle with the ATT&CK for Mobile mapping should check the mobile-attack MITRE Navigator layer and search by keyword ("IMSI", "SS7", "fake base station").

Chapter 9: QUIC, HTTP/3, and Encrypted Transport Security

Opening Hook (5 min)

Pull up a Zeek http.log from a week-6 lab capture. "Every HTTP request, every URL, every response code -- all here. Now watch." Open a Zeek conn.log from a session that was QUIC. "Same destination. Same connection duration. Same byte counts. HTTP method: gone. URL: gone. Response code: gone. This is not a hypothetical future problem. It's the current deployment reality for any site serving via HTTP/3."

Pacing

• Lecture (90 min): Section 9.1 (QUIC mechanics): 20 min. Section 9.2 (HTTP/3): 10 min. Section 9.3 (MASQUE/tunneling): 10 min. Section 9.4 (detection challenges + table): 20 min -- this table is the core deliverable of the lecture; build it live with students contributing cells. Section 9.5 (defensive options): 15 min. Lab 11 setup walkthrough: 15 min.
• Lab (90 min): Lab 11 is the NSM coverage gap analysis. The actual HTTP/3 generation (Part A) takes 10-15 min. The coverage gap report (Part D) is where students spend most of the time.

Common Issues

1. curl without HTTP/3 support. Many default curl installations lack QUIC/HTTP3 support. The lab includes a Python aioquic fallback and a note about Ubuntu's curl --http3 availability. Pre-test on lab hardware before the session. The fallback works but generates less varied traffic -- if the aioquic fallback is used, the Wireshark dissection is less rich.
2. Students expect QUIC to be fully invisible. The SNI in the Initial CRYPTO frame surprises students who expected "QUIC is encrypted, therefore unmonitorable." The key insight: Initial packets use a standard derivation that any party can derive from the Connection ID. Only 1-RTT application data is truly opaque to a passive observer.
3. Suricata version issues. alert quic requires Suricata 7.0+. For labs running Suricata 6.x, use the alert udp any any -> any 443 fallback. Students should note which syntax they used in their report.
4. The coverage gap report is the highest-difficulty Part. Students who write "QUIC is more secure" as their answer to the coverage gap question miss the NSM lens entirely. Coach: "From a defender's perspective, what specifically can you NO LONGER detect that you COULD detect with HTTP/1.1? Give field names."

Anchor Weave Placement

RFC 9000 §21 (Security Considerations) is assigned as independent reading -- it explicitly discusses the intended limitation on network operator visibility. Kurose-Ross §3.7 provides transport-layer context. The key pedagogical move: RFC 9000 designed this visibility loss intentionally; the defenders' job is to adapt, not to expect the standard to accommodate them.

Lab 11 Timing Note

Lab 11 (20 pts, 2 hr independent): Part A-C can typically be completed in the 90-min lab window if curl HTTP/3 works. Part D (coverage gap report) is the 2-hr independent component. Grade the coverage gap report for specificity: generic "QUIC is harder to monitor" prose earns minimal credit; a table with 5+ specific field-level observations earns full credit.

Chapter 10: Penetration Testing Cross-Cut

Opening Hook (5 min)

"I want you to play attacker for the next 90 minutes. Not because we're training attackers -- but because you cannot build a good defense against a threat you don't understand from the inside." Show the detection results table from Week 10's Architecture Comparison Sidebar (NSM detection coverage by attack phase). "The orange cells -- 'medium' detection -- are where defenders need attacker intuition to tune correctly. Today we're going to earn that intuition."

Pacing

• Lecture (90 min): Section 10.1 (offense-informs-defense framing): 5 min. Section 10.2 (nmap + NSM signatures): 20 min (run a live nmap against a lab node; show conn.log fill in real-time). Section 10.3 (C2 + beacon detection): 25 min. Section 10.4 (lateral movement): 20 min. Section 10.5 (DNS exfiltration): 10 min. Section 10.6 (evasion catalog): 10 min.

Common Issues

1. Ethics framing. Some students are uncomfortable with the "play attacker" framing. Reinforce: the target is a Docker container on an isolated network; the techniques being used are documented defensive-awareness exercises, not novel attacks. The course Rules of Engagement apply. No external traffic.
2. Metasploit msfvenom on lab machines. Some lab machines may have antivirus or endpoint detection that flags msfvenom output. The lab uses Docker containers specifically to isolate this. If the host machine has EDR, run msfvenom inside the attacker container, not on the host.
3. RITA jitter analysis. Students who don't run the beacon for long enough (less than 5 minutes, less than ~5 beacon intervals) will not have enough data for RITA to score. The lab requires 360 seconds of capture for a 60-second beacon with 30% jitter. Emphasize: RITA needs enough beacon intervals to compute the distribution metrics.
4. Docker isolated network verification. Students must confirm no external traffic leaves the lab12-net Docker network. Have them run docker network inspect lab12-net to confirm "Internal": true.

Anchor Weave Placement

Bejtlich Ch 1 and Ch 6 are both relevant: Ch 1 frames the four NSM data types, and Ch 6 covers the threat-hunting cycle. Week 10's offense-informs-defense doctrine is the practical connection between the two: running the attack gives you the ground truth that Ch 6's "hypothesis" phase requires.

Lab 12 Timing Note

Lab 12 (25 pts, 90 min lab + 3 hr independent): Part A (meterpreter setup) = 30 min. Part B (capture + analysis) = 45 min (includes 6-minute wait for RITA). Part C (gap analysis) = 15 min in lab + bulk of independent time. The RITA beaconing analysis is time-gated by the beacon interval -- ensure students start the capture before the 360-second wait.

Chapter 11: Reverse Engineering Cross-Cut

Opening Hook (5 min)

Show a raw TCP stream in Wireshark -- hex view, no dissector. "What is this?" Pause. "You can see it's TCP. You can see byte patterns. You can see repeated sequences. You cannot read it -- yet." Then open the same stream with a Lua dissector loaded. "Same bytes. Now it's readable. The dissector didn't add information -- it surfaced information that was already there. Protocol RE is the skill of moving from the left side to the right side."

Pacing

• Lecture (90 min): Section 11.1 (methodology): 20 min -- walk through the 5 phases with a concrete example (using the stub server from Lab 13). Section 11.2 (Lua dissector development): 25 min -- live-code the minimal scaffold on screen while students follow along. Section 11.3 (Scapy fuzzing): 15 min. Section 11.4 (state machine extraction): 15 min. Section 11.5 (Gate 5 walkthrough): 15 min.

Common Issues

1. Students don't read the protocol first, they just write the dissector. The Lua dissector is step 4 of 5 in the methodology -- it should emerge from the annotation work, not precede it. Students who skip steps 1-3 write dissectors that parse wrong offsets. Enforce the annotation-first sequence.
2. Confidence vocabulary. "CONFIRMED" vs. "INFERRED" vs. "HYPOTHESIZED" seems bureaucratic to students who want to just write "I found it." Explain: this vocabulary is what distinguishes a protocol RE write-up that a grader can trust from one that might be hallucinating. Real RE reports use confidence levels because the RE methodology is inherently probabilistic.
3. Lua offset errors. The most common Lua dissector bug: buffer(0,2) for magic, then buffer(2,2) for length -- forgetting there's a 1-byte type field at buffer(2,1) between them. Walk through buffer indexing arithmetic in the lecture. Have students verify by right-clicking a field in Wireshark and checking "Go to packet bytes."
4. Scapy sr1() timeout. Students who run Scapy verification against a server that requires a specific first message (e.g., must receive CONNECT before any other message) and send the wrong first message will get no response -- sr1() times out after 2 seconds. Emphasize: Scapy tests must follow the protocol state machine, not just send arbitrary bytes.

Anchor Weave Placement

Davidoff & Ham Ch 3 and Ch 7 are the primary references. Assign Ch 3 as pre-reading. The Lua dissector development section maps to Wireshark Developer Guide Ch 9 (Protocol Dissector Howto) for students who want to go deeper.

Lab 13 Timing Note

Lab 13 (20 pts, 90 min lab + 4 hr independent): Parts A-C (capture, annotation, state machine) = 60 min in lab. Part D (Lua dissector) = 30 min in lab + 1 hr independent. Part E (Suricata rule) = 15 min independent. The Gate 5 self-assessment is the highest-value independent component -- students who honestly assess their gaps and name specific remediation steps are ready for the capstone.

Chapter 12: Capstone Preparation and Presentation

Opening Hook (5 min)

"Every lab in this course was practice for something in the capstone. Lab 1: the topology bring-up you've done six times. Lab 3: the RPKI gate. Labs 6-8: the NSM sensor and rules. Lab 13: the protocol RE write-up. Week 12 is not a new chapter -- it's the accounting of what you've built."

Pacing

• Week 12 lecture (90 min): This is a structured peer review session, not a traditional lecture. Run the checkpoint agenda from Section 12.2 of the week file. Each student presents for 10 min. With 20+ students, the session takes 90+ min; split into two sessions if needed.
• Weeks 13-14: Independent build time. Two optional open-lab sessions per week (2 hr each). The instructor's Week 13-14 job is triage, not teaching.

Common Issues

1. Gate 5 live demo failures. Students who have done all Scapy verification offline (saved outputs, not live-tested) may be unable to re-run it live during the grading session if the server isn't running. Require students to confirm their protocol server is running and accessible before the grading session starts. The grader should check: nc -zv localhost 9876 before asking for the Scapy demo.
2. Architecture rationale section underdeveloped. The #1 reason for B- vs. A- grades. Students who write "I chose X because it is appropriate" earn minimal points. The choice-alternative-rationale template in Section 12.3 of the week file is the minimum structure.
3. Coverage gap analysis too generic. "Advanced threats may evade detection" earns zero points. Coach students to cite specific techniques from the Week 10 evasion catalog (e.g., "Jitter >25% on HTTPS C2 reduces RITA beacon score below threshold; compensating control would be byte-count ratio analysis of long-duration SSL sessions").
4. Students who want to submit both Track A and Track B capstones. Only one track is required and graded. If a student submits both, grade the higher-scoring one. Do not grade both and average -- the rubric allocates 100 Tier 2 pts for one track.

Anchor Weave Placement

No new anchor material in Week 12. The capstone is the synthesis point. The architecture rationale section implicitly requires students to apply Kurose-Ross (routing protocol rationale), Bejtlich (NSM sensor design), and Davidoff & Ham (protocol RE methodology) simultaneously -- without being asked to cite any of them.

Capstone Lab Timing Note

Grading sessions (20 min per student): Gate 1-4 verification takes 8-10 min for a student who passes all four. Gate 5 (Scapy live demo + write-up review) takes 5 min. Gate 6 (Suricata rule demo) takes 2-3 min. Tier 2 scoring is done offline after the live session.

Assessment Notes (v0.2 Addendum)

Week 8 lab pre-test requirement: Open5GS + UERANSIM bring-up must be pre-tested on lab hardware before the session. The Docker memory requirements and AMF IP configuration are the two most common blocking issues.

QUIC curl availability: Pre-verify curl --http3 works on lab machines before Lab 11. If not available, the Python aioquic fallback is documented in the lab instructions.

Lab 12 isolation verification: Before grading Lab 12, ask students to show docker network inspect lab12-net confirming "Internal": true. A student who ran traffic against external systems (even by accident) has a lab integrity issue.

Gate 5 protocol seed: The capstone unknown protocol (capstone_unknown.pcap, TCP port 7777, magic 0xDEAD) is different from the Lab 13 practice protocol (port 9876, magic 0xABCD). Students who memorize the Lab 13 magic and try to apply it directly to the capstone will immediately see it fails -- this is by design.

Assessment Notes

Tier 1 gate (capstone): All six gates must pass before Tier 2 scoring applies. Gate 5 (protocol RE) and Gate 6 (NSM detection) are the two most commonly failed. Schedule a mid-point check-in at Week 10 to confirm students have identified the unknown protocol's state machine before the capstone deadline.

B- minimum (70/100 Tier 2): The architecture rationale section (40 pts) is where strong students pull away. Students who merely describe their design choices without defending them against named alternatives land in the 20-28 pt range. Coach students early to structure their architecture sections as "I chose X over Y because of Z."

Lab report consistency: All lab reports should follow the same format: numbered sections matching the lab Parts, tables for enumerated data (protocol counts, alert signatures, etc.), and at least one analytical paragraph that goes beyond "what happened" to "why it matters." Establish this norm in Lab 1.

Toolchain Integration

Every tool introduced in NET-301 should be added to the student's Toolchain Diary (started in NET-101). Key entries: