◇ OpenCyber Academy
Postgraduate · Chapter 2 · English

Chapter 2 — Network and communications security: current practice

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 2 — Network and communications security: current practice

Lesson map

Lesson 02 published. Map, example, EX006.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Site-to-site VPN practice"]
  N2["2.2 Routing security practice"]
  N3["2.3 Filtering practice"]
  N4["2.4 Gap analysis"]
  N5["2.5 Practice versus guidance"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX006"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Site-to-site VPN practice"]
  N2["2.2 Routing security practice"]
  N3["2.3 Filtering practice"]
  N4["2.4 Gap analysis"]
  N5["2.5 Practice versus guidance"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX006"]

[Learning outcomes]
    |
    v
[2.1 Site-to-site VPN practice]
    |
    v
[2.2 Routing security practice]
    |
    v
[2.3 Filtering practice]
    |
    v
[2.4 Gap analysis]
    |
    v
[2.5 Practice versus guidance]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX006]

Learning outcomes

You will (1) survey current practice in VPNs, routing security and filtering; (2) compare guidance with the partner's state.

2.1 Site-to-site VPN practice

Current practice for site-to-site VPNs uses IKEv2, specified in RFC 7296, with certificate-based authentication and modern algorithms, as described in NIST SP 800-77r1. IKEv1 remains in many networks but is more complex, has more configuration pitfalls and is deprecated in much guidance. Pre-shared keys are simple but are often long-lived, shared by email and reused across peers, so a single leak can expose several links. At Fenwick Valley, VPNs connect the points of presence to the operations centre and to one partner provider, and their configurations have grown piecemeal over a decade.

2.2 Routing security practice

Internet routing relies on BGP, in which networks announce the address blocks they can reach. Mistaken or malicious announcements can redirect traffic. The Resource Public Key Infrastructure, described in RFC 6480, lets address holders publish signed Route Origin Authorisations stating which network may originate their prefixes. Routers can then classify announcements as valid, invalid or not found. NIST SP 800-189 recommends route origin validation and related practices for networks exchanging traffic. Many small providers have published authorisations for their own prefixes but have not yet enforced validation on routes they receive.

2.3 Filtering practice

RFC 2827, known as BCP 38, recommends that networks drop packets from customers whose source addresses do not belong to those customers. This ingress filtering limits spoofed traffic, which is used to hide attackers and amplify denial-of-service attacks. It costs the filtering network little but mostly benefits others, which is why adoption has been uneven. SP 800-189 repeats the recommendation. Fenwick Valley filters business customers with static addresses but not residential customers, because staff worried about breaking unusual customer setups years ago.

Extending filtering to residential customers would therefore need tests of those unusual setups, not just a change of policy.

2.4 Gap analysis

Marta compares the provider's state with current guidance. Gaps include IKEv1 on three peers, pre-shared keys on five, published authorisations but no validation of received routes, and incomplete ingress filtering. She notes strengths too: good inventory of network devices, central logging and a capable operations team. A gap analysis is more useful when it lists strengths as well as weaknesses, because strengths show what the organisation can build on and help prioritise changes that fit existing skills and tools rather than requiring new ones.

2.5 Practice versus guidance

Guidance describes good practice in general terms; practice must fit a specific network. Marta interviews engineers at two neighbouring providers about their experience. One enforced route validation and dropped a partner's routes for an afternoon because of a stale authorisation; the other moved slowly and found the soft-enforcement stage valuable. These experiences add practical detail missing from guidance, such as how to handle exceptions and how to communicate with partners. Combining published guidance with peer experience gives a more realistic picture of what implementation involves.

Worked example

The gap table lists four gaps against SP 800-77r1, SP 800-189, RFC 6480 and RFC 2827, plus three strengths.

Synthetic case. Interviews and data are synthetic.

Errors and limits

Treating guidance as a checklist ignores local constraints that determine how changes should be made.

Exercises

Synthesis

Comparing current practice with the partner's state, including strengths, focuses effort where it matters.

Continue studying — chapter 02 of 12

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →