◇ OpenCyber Academy
Postgraduate · Chapter 6 · English

Chapter 6 — Network and communications security: controlled evaluation

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 6 — Network and communications security: controlled evaluation

Lesson map

Lesson 06 published. Map, example, EX026.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 Evaluation question"]
  N2["Lab — Ingress check"]
  N3["6.2 Reading the check"]
  N4["6.3 Monitor-first trial"]
  N5["6.4 Evaluation criteria"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX026"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 Evaluation question"]
  N2["Lab — Ingress check"]
  N3["6.2 Reading the check"]
  N4["6.3 Monitor-first trial"]
  N5["6.4 Evaluation criteria"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX026"]

[Learning outcomes]
    |
    v
[6.1 Evaluation question]
    |
    v
[Lab — Ingress check]
    |
    v
[6.2 Reading the check]
    |
    v
[6.3 Monitor-first trial]
    |
    v
[6.4 Evaluation criteria]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX026]

Learning outcomes

You will (1) evaluate ingress filtering on synthetic traffic; (2) estimate customer impact; (3) design a monitor-first trial.

6.1 Evaluation question

Before enforcing ingress filtering for residential customers, Marta asks a precise question: what share of customer traffic would be dropped, and how much of that is legitimate? If almost all dropped traffic is spoofed or misconfigured, enforcement is safe. If legitimate customers use addresses outside their assigned ranges, for example because of unusual business arrangements, enforcement could cut them off. The evaluation must answer this using synthetic or sampled data, without disrupting anyone, before any filter is switched on. The answer decides whether enforcement goes ahead.

Lab — Ingress check

"""Ingress filtering check (RFC 2827 idea): flag synthetic customer packets whose source is outside the customer's prefix (stdlib only)."""
import ipaddress
cust = {"c1": "100.64.1.0/24", "c2": "100.64.2.0/25", "c3": "100.64.3.0/24"}
pk = [("c1", "100.64.1.9"), ("c1", "100.64.1.200"), ("c2", "100.64.2.140"), ("c2", "100.64.2.10"), ("c3", "10.0.0.5"),
      ("c3", "100.64.3.77"), ("c1", "198.51.100.4"), ("c2", "100.64.2.99"), ("c3", "100.64.3.1"), ("c1", "100.64.1.1")]
bad = [(c, s) for c, s in pk if ipaddress.ip_address(s) not in ipaddress.ip_network(cust[c])]
for c, s in bad: print(f"{c} source {s} outside {cust[c]}")
print(f"{len(bad)} of {len(pk)} would be dropped ({100*len(bad)/len(pk):.0f}%)")

Run with python3 lab_ingress.py. Verified output:

c2 source 100.64.2.140 outside 100.64.2.0/25
c3 source 10.0.0.5 outside 100.64.3.0/24
c1 source 198.51.100.4 outside 100.64.1.0/24
3 of 10 would be dropped (30%)

6.2 Reading the check

The synthetic sample contains ten packets from three customers. Three, thirty percent, would be dropped. One comes from an address just outside customer c2's /25, which may be a misconfigured device or a customer using more addresses than assigned. One from customer c3 uses a private address, which should never appear on the public internet and suggests a misconfigured router. One from customer c1 uses an address belonging to another network entirely, which is consistent with spoofing. Real proportions would be far lower; the sample is designed to show each case.

6.3 Monitor-first trial

Marta proposes a controlled trial: apply the filters in counting mode, which records matching packets without dropping them, for four weeks across all residential access routers. Each week, the operations team reviews customers with matches. Where matches suggest a misconfiguration, support contacts the customer. Where they suggest a customer legitimately needs more addresses, assignments are corrected. Only after the review period, and with customer notice sent, does enforcement begin. This design measures impact under real conditions while protecting customers from surprise disruption.

6.4 Evaluation criteria

Marta defines success criteria before the trial: matched traffic from fewer than one in a thousand customers after corrections, no matches explained by legitimate needs that cannot be fixed, and support tickets within normal range after enforcement. She also defines stopping conditions: if enforcement generates a support ticket spike above a set threshold in its first week, filters return to counting mode while causes are investigated. Pre-set criteria and stopping rules make the trial a genuine test rather than a formality before an already-decided change.

6.5 Limits of the evaluation

Counting-mode results show what would be dropped, but not why every match occurred. Some customers may be hosting services they have not mentioned, and some matches may come from rare events not seen during four weeks. Marta reports these limits and recommends keeping the customer contact process permanent, so any later legitimate need can be handled. She also notes that the trial measures impact on Fenwick Valley's customers but cannot measure the benefit to others directly, which must be argued from the guidance and the nature of spoofed traffic.

Worked example

The synthetic sample drops three of ten packets; the trial plan uses four weeks of counting mode before enforcement.

Synthetic case. Traffic is synthetic.

Errors and limits

Enforcing filters without a counting period risks disrupting customers with unusual but legitimate setups.

Exercises

Synthesis

A controlled, monitor-first evaluation with pre-set criteria makes enforcement safe and evidence-based.

Continue studying — chapter 06 of 12

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →