Milestone map
Milestone map
3 milestones
Understand Protocol Layers Through Wireshark Analysis
6–10 weeks
Study the TCP/IP model: physical, network, transport, and application layers. Capture real network traffic with Wireshark and analyse at least five different protocols at multiple layers (e.g. HTTP, DNS, TCP handshake, ICMP, ARP). For each capture, identify the headers at each relevant layer and explain in writing what each field means and why it is there.
Proof required
Submit: Wireshark capture files (pcap format) for at least five different protocols; a written analysis (at least 200 words per protocol) identifying the relevant headers at each layer and explaining each field; and evidence that the captures are from real traffic you captured — not downloaded sample pcap files. A CS lecturer, network engineer, or systems programmer must review the analyses and confirm in writing that the protocol interpretations are correct.
What gets checked
- Five or more protocols are analysed with real captured traffic — not downloaded sample pcap files
- Each analysis covers headers at multiple layers and explains each field — not just names the fields
- A network engineer or CS lecturer has confirmed the protocol interpretations are correct
Common mistakes
- Using downloaded sample pcap files rather than capturing real traffic — the captures must be from real network activity you generated
- Analysis that names headers without explaining what each field does and why the protocol needs it
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Are the pcap files from real traffic — can you see timestamps and real IP addresses?
- Does each analysis explain what each field does — not just name it?
- Ask: 'why does TCP use a three-way handshake rather than a two-way handshake?' — tests deeper understanding beyond the captures
Implement a Network Application Using Sockets
8–12 weeks (after milestone 1)
Implement a functioning network application using raw socket programming (Python, C, or Go): a client-server application that communicates over TCP, and separately an application that uses UDP with packet loss handling. The implementation must correctly handle connection setup, data transfer, and teardown without using high-level networking libraries that abstract the socket layer.
Proof required
Submit: a public GitHub repository containing the TCP client-server and UDP application with packet loss simulation; a test harness showing the applications work correctly under normal and failure conditions; and a 200-word design document explaining why you made specific choices at the socket level (buffer sizes, select/poll vs. blocking, error handling). A network engineer or systems programmer must review the code and confirm it correctly handles edge cases.
What gets checked
- Both applications use raw socket APIs — not HTTP libraries or framework abstractions
- Test harness demonstrates operation under failure conditions — not just happy-path tests
- A network engineer or systems programmer has confirmed the socket handling is correct
Common mistakes
- Using requests, aiohttp, or similar libraries that hide the socket — the proof requires raw socket programming
- Test harness that only tests the happy path — failure handling requires deliberate failure injection
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Are raw socket APIs used — no HTTP libraries abstracting the socket layer?
- Does the test harness include failure injection — not just happy-path tests?
- Ask: 'what happens if the UDP receiver drops a packet — how does your implementation detect and handle it?' — tests failure handling understanding
Design and Analyse a Network Architecture
4–6 weeks (after milestone 2)
Design the network architecture for a small organisation (100 users, three departments, internet access, internal file server, and a web-facing application). Document the design: addressing scheme (IP subnets), routing plan, firewall rules, and DNS design. Present the design to a network engineer who reviews it for correctness, security gaps, and scalability.
Proof required
Submit: a complete network design document (at least 800 words) including addressing scheme, routing plan, firewall rules, and DNS design with a network diagram; and a recording or transcript of a design review with a network engineer where they identified at least two security or scalability issues and you responded to each.
What gets checked
- Design document includes all four components — addressing, routing, firewall rules, and DNS — with a network diagram
- Design review was with a network engineer who identified specific issues — not a conversational walkthrough
- Response to each identified issue demonstrates understanding — not just acknowledgement
Common mistakes
- Network diagram without a corresponding addressing scheme — a diagram without IP assignments cannot be evaluated for correctness
- Firewall rules that block everything or allow everything — a complete firewall requires specific rules for specific services
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Does the design include a network diagram with IP addressing?
- Are firewall rules specific — named services with named directions?
- Did the review identify at least two specific security or scalability issues?