Chapter 5 — Network and communications security: design alternatives
Lesson map
Lesson 05 published. Map, example, EX021.
flowchart TD
N0["Learning outcomes"]
N1["5.1 Three validation designs"]
N2["Lab — Origin validation"]
N3["5.2 Reading the validation"]
N4["5.3 Evaluating designs against cases"]
N5["5.4 Operational requirements"]
N6["5.5 The chosen design"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX021"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["5.1 Three validation designs"]
N2["Lab — Origin validation"]
N3["5.2 Reading the validation"]
N4["5.3 Evaluating designs against cases"]
N5["5.4 Operational requirements"]
N6["5.5 The chosen design"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]
[Learning outcomes]
|
v
[5.1 Three validation designs]
|
v
[Lab — Origin validation]
|
v
[5.2 Reading the validation]
|
v
[5.3 Evaluating designs against cases]
|
v
[5.4 Operational requirements]
|
v
[5.5 The chosen design]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX021]
Learning outcomes
You will (1) compare enforcement designs for route validation; (2) evaluate with synthetic data; (3) select a staged design.
5.1 Three validation designs
Marta compares three designs for handling route origin validation. In the first, the provider records validation results but takes no action, which offers visibility only. In the second, invalid routes receive lower preference, so a valid alternative is used when one exists but invalid routes still work if they are the only path. In the third, invalid routes are rejected entirely. Each design trades protection against the risk of losing legitimate reachability. The choice depends on how often invalid results are caused by stale records rather than real mis-origination.
Lab — Origin validation
"""Route origin validation of synthetic announcements against synthetic ROAs (RFC 6480 model; stdlib only)."""
import ipaddress
roas = [("192.0.2.0/24", 64500, 24), ("198.51.100.0/22", 64501, 24), ("203.0.113.0/24", 64502, 24)]
ann = [("192.0.2.0/24", 64500), ("192.0.2.0/24", 64666), ("198.51.100.0/23", 64501), ("198.51.100.0/25", 64501),
("203.0.113.0/24", 64502), ("100.64.10.0/24", 64510), ("198.51.102.0/24", 64501), ("203.0.113.0/24", 64503)]
def validate(p, asn):
p = ipaddress.ip_network(p); cover = [r for r in roas if p.subnet_of(ipaddress.ip_network(r[0]))]
if not cover: return "notfound"
return "valid" if any(asn == a and p.prefixlen <= m for _, a, m in cover) else "invalid"
res = [validate(p, a) for p, a in ann]
for (p, a), r in zip(ann, res): print(f"{p:18}AS{a:<6}{r}")
print({k: res.count(k) for k in ("valid", "invalid", "notfound")})
Run with python3 lab_rov.py. Verified output:
192.0.2.0/24 AS64500 valid
192.0.2.0/24 AS64666 invalid
198.51.100.0/23 AS64501 valid
198.51.100.0/25 AS64501 invalid
203.0.113.0/24 AS64502 valid
100.64.10.0/24 AS64510 notfound
198.51.102.0/24 AS64501 valid
203.0.113.0/24 AS64503 invalid
{'valid': 4, 'invalid': 3, 'notfound': 1}
5.2 Reading the validation
The synthetic run classifies eight announcements against three authorisations. Four are valid, including a /24 inside an authorised /22 because the authorisation allows prefixes up to /24. Three are invalid: one from an unauthorised network, one /25 more specific than the maximum length allowed, and one /24 announced by a different network from the one authorised. One is not found because no authorisation covers it. Marta notes that the /25 case is typical of real mistakes, where an operator announces a more specific route without updating the authorisation.
5.3 Evaluating designs against cases
For each invalid result, Marta asks what each design would do. Recording only would accept all three and protect nobody. Lower preference would avoid the two invalid routes that have valid alternatives, while still using the /25 if no other path existed. Rejection would drop all three, including the possibly legitimate /25. With synthetic data suggesting that one in three invalid results might be operator error, she recommends lower preference first, with monitoring of invalid routes and contact with their owners, followed by rejection once error rates are understood.
5.4 Operational requirements
Each design needs supporting operations. Validation requires validator software that fetches and checks signed data, with redundancy so a validator failure does not leave routers without results. Monitoring must alert when invalid routes appear for important destinations. Staff need a procedure for contacting other networks about incorrect authorisations. Marta notes that the provider's own authorisations must also be correct, since errors there would cause others to reject Fenwick Valley's routes. She adds a quarterly review of the provider's own published records to the plan.
5.5 The chosen design
The directors approve a staged design: three months of lower preference for invalid routes, with weekly reports on invalid routes received and contacts made, then a review deciding whether to move to rejection. The design follows SP 800-189's recommendations while respecting the provider's limited experience. Marta records success criteria for moving to rejection, such as fewer than a set number of invalid routes caused by errors in a month, and the reversal procedure if rejection causes reachability problems. Criteria decided in advance keep the later review objective.
Worked example
Four valid, three invalid and one not found; the staged design chooses lower preference first with criteria for rejection.
Synthetic case. Announcements and authorisations are synthetic.
Errors and limits
Moving straight to rejection without knowing error rates risks dropping legitimate routes.
Exercises
- EX021 — Validation counts. What counts does the validation lab report? Rubric: 3 = 4 valid, 3 invalid, 1 not found;; 2 = counts;; 1 = partial;; 0 = none.
- EX022 — Maximum length case. Why is the /25 announcement invalid? Rubric: 3 = more specific than ROA maximum length /24;; 2 = too specific;; 1 = wrong AS;; 0 = none.
- EX023 — Not found meaning. What does "not found" mean for an announcement? Rubric: 3 = no ROA covers the prefix;; 2 = no record;; 1 = invalid;; 0 = none.
- EX024 — Own records review. Why review the provider's own published authorisations? Rubric: 3 = errors would make others reject its routes;; 2 = own reachability;; 1 = vague;; 0 = none.
- EX025 — Rejection criteria. What should be decided before moving to rejection? Rubric: 3 = success criteria and reversal procedure;; 2 = criteria;; 1 = vague;; 0 = none.
Synthesis
Comparing designs against concrete validation results supports a staged, criteria-driven choice.
Continue studying — chapter 05 of 12
← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →