Core: Security

Infrastructure hardening - control, management, and data plane

Miro Kosut

Miro Kosut

— 3 min read
Share

Requirement / business driver

Protect the devices and the three planes themselves so the network can't be subverted or DoS'd through its own infrastructure.

Per-plane protection

  • Control plane - CoPP / CPPr rate-limit traffic punted to the CPU (routing, ARP, management) so a flood can't starve the control plane; secure the routing protocols (Securing routing protocols).
  • Management plane - secure access only (SSH not Telnet, SNMPv3, NETCONF over TLS), AAA for every login (AAA and identity - RADIUS, TACACS+, 802.1X), MPP (management-plane protection) to bind management to specific interfaces, and CPU / memory thresholding alerts. Out-of-band management where possible.
  • Data plane - uRPF (anti-spoofing), infrastructure ACLs (iACLs) to protect the core from the edge, and QoS to bound abusive flows (Threat detection and mitigation - DDoS, spoofing, MITM).

uRPF mode selection (strict vs loose)

uRPF's mode is a symmetry decision. Strict mode accepts a packet only if the route back to its source points out the very interface it arrived on - the strongest anti-spoofing check, but it presumes the forward and reverse paths match, so at a multihomed or asymmetric edge it drops legitimate traffic. It belongs where the reverse path is unambiguous: single-homed access, branch, and customer handoffs. Loose mode asks only that the source exists in the routing table at all (default route excluded) - it survives asymmetry, filters unroutable/bogon sources, and is the mechanism that makes source-based RTBH work: blackhole a source prefix once and loose-uRPF drops it network-wide (Threat detection and mitigation - DDoS, spoofing, MITM). A VRF variant scopes the loose check to the ingress VRF's table. The placement rule mirrors the stateful-symmetry principle: strict only where the design guarantees symmetric paths; loose everywhere asymmetry is possible.

Recommendation / justification

Apply all three planes - hardening one and ignoring another leaves an open flank. Prioritise CoPP + secure management + uRPF/iACLs as the baseline, and feed device telemetry to monitoring (Network management - traditional vs model-driven). Justify by which plane an attacker would target to disrupt availability.

What would change this (mid-scenario twist)

  • High-value/regulated core -> strict iACLs, OOB management, tighter CoPP.
  • Spoofing/DDoS concerns -> uRPF + edge anti-spoofing emphasised.

Validation checks

  • Is CoPP present and is management plane restricted to secure protocols + AAA?
  • Is anti-spoofing (uRPF/iACL) applied at the right edges?

IPv6 / dual-stack note

Build CoPP/iACLs/uRPF for both families; v6 control-plane (ND, MLD) needs protection too. One v6 ACL subtlety with design consequences: unlike ARP, ND rides IPv6 itself, so v6 ACLs carry implicit nd-na/nd-ns permits ahead of the final deny - strip or shadow them and the ACL kills address resolution on the link.

Spaced repetition

What does CoPP/CPPr protect against, and how?

It rate-limits traffic punted to the CPU (routing/ARP/management) so a flood can't starve the control plane.

Name a baseline control for each plane.

Control = CoPP + secured routing; Management = SSH/SNMPv3 + AAA + MPP/OOB; Data = uRPF + infrastructure ACLs + QoS.

uRPF's role is [...].

uRPF's role is anti-spoofing (drop packets whose source wouldn't route back out the receiving interface).

uRPF strict vs loose - what is the placement rule?

Strict (source must route back out the receiving interface) only where symmetry is guaranteed - single-homed access/branch/customer edges; loose (source merely exists in the routing table) at multihomed/asymmetric and core/peering edges - it also enables source-based RTBH.

Why do IPv6 ACLs implicitly permit nd-na/nd-ns before the final deny?

Unlike ARP (below IP), Neighbor Discovery rides IPv6 itself - remove or shadow those permits and the ACL breaks address resolution on the link.

Sources

  • Rick Graziani, IPv6 Fundamentals, 2nd Ed. - implicit ND permits in IPv6 ACLs.
  • Cisco Press, SCOR; Cisco device-hardening guides.
  • Cisco Press, CCNP ENARSI 300-410 OCG (Edgeworth/Lacoste) - uRPF modes.

domain: Core · blueprint-ref: Core 6.1.a/6.1.b/6.1.c/6.2 Infrastructure security · type: design-decision · status: complete · tags: [core, core/security, tradeoff/security, tradeoff/operability]

Read more