System Components

Chapter 1 — Architecture, Components, and Working Principles

1.1 System Architecture

The router security architecture is built around the fundamental concept of plane separation: the Management Plane, Control Plane, and Data Plane each have distinct responsibilities, threat surfaces, and protection mechanisms. This decomposition ensures that a compromise or failure in one plane does not automatically cascade into the others, and that security controls can be applied with surgical precision.

The Management Plane encompasses all administrative access paths — SSH/HTTPS terminals, SNMPv3 agents, AAA client functions, syslog forwarding, and NTP synchronization. It is deliberately isolated in a dedicated management VRF or OOB network, accessible only from approved operations subnets via authenticated and encrypted sessions. The Control Plane handles routing protocol operations, including BGP/OSPF/IS-IS adjacency management, RIB/FIB programming, BFD keepalives, and control-plane ACL/CoPP enforcement. The Data Plane performs hardware-accelerated packet forwarding through ASIC/NP engines, applying ACLs, QoS policies, uRPF source validation, and policy-based routing at line rate.

Router Plane Decomposition Architecture
Figure 1.1: Router Plane Decomposition — Management, Control, and Data Plane Separation

Module Relationships & Boundaries

The architecture distinguishes between mandatory core modules, optional recommended modules, and supporting external systems. Core modules must be implemented on every in-scope router; optional modules should be implemented where platform capabilities and compliance requirements permit; supporting systems are external dependencies that must be confirmed operational before router commissioning.

Module Category Components Implementation Status Notes
Core (Mandatory) Secure management access, AAA, routing protocol auth/filters, CoPP/CPP, data-plane ACL + anti-spoof, logging/time, config backup/restore Required Must be verified at acceptance
Optional (Recommended) PKI-based device identity, RPKI validation for BGP, MACsec on trusted L2, automated compliance checks, signed config artifacts Recommended Implement where platform supports
Supporting Systems Jump host/VPN, AAA servers, SIEM, NTP, config management platform External Dependency Must be available before commissioning

Data and Control Flows

  • Admin login flow: Admin workstation → VPN/jump host → router mgmt interface (in mgmt VRF) → AAA authenticate/authorize → command accounting to SIEM.
  • Routing update flow: Neighbor adjacency permitted only if interface + peer IP + source address match policy → authenticated session → inbound policy filters → RIB decision → FIB programming.
  • Forwarding flow: Packet arrives on ingress interface → ingress ACL/uRPF → routing/VRF lookup → egress ACL → transmit; exceptions punted to CPU are rate-limited by CoPP.

1.2 Components and Functions

Each component in the router security ecosystem has a defined responsibility, set of inputs and outputs, engineering KPIs, and a documented mismatch risk profile. Understanding these relationships is essential for both initial design and ongoing operations. The swimlane diagram below illustrates how Ops Systems, Router Functions, and Networks interact through well-defined interfaces.

Components and Functions Swimlane Diagram
Figure 1.2: Component Swimlane Diagram — Ops Systems, Router Functions, and Networks
Component Responsibility Inputs Outputs Key KPIs Mismatch Risks
OOB/Mgmt Network Isolate management traffic Ops IP range, routing to jump host Reachability to mgmt interfaces Packet loss <0.1%, latency <50ms, ACL deny-by-default If shared with user LAN → lateral movement, credential harvesting
Jump Host / Bastion Central entry with MFA and recording VPN auth, admin identity SSH proxy, session logs MFA success rate, session recording coverage 100% Direct router exposure to Internet; no session audit
AAA Server (TACACS+/RADIUS) AuthN/AuthZ/Accounting User identity, policy Permit/deny, role, command logs Availability ≥99.9%, auth latency <1s AAA outage blocks ops; weak role model enables privilege abuse
Router Mgmt Services Encrypted admin services SSH/HTTPS, SNMPv3 CLI/API responses, traps SSH only, TLS1.2+, idle timeout Telnet/HTTP/SNMPv2 leaks credentials
Routing Protocol Stack Establish adjacencies, exchange routes Neighbor packets, keys RIB updates Neighbor stability, auth failures=0 Route injection, session hijack
CoPP/CPP Protect CPU/control plane Punted traffic Rate-limited punts CPU <60% under attack, adjacency stable Control-plane DoS resets protocol sessions
ACL/uRPF/PBR Data-plane enforcement Ingress packets Allowed flows only Drop spoofed=100%, false positive <0.1% Over-blocking breaks business; under-blocking leaks traffic
Syslog/SIEM Central audit and detection Logs, netflow Alerts, retention Coverage 100%, retention ≥180 days No evidence in incidents; delayed response
Config Backup/Repo Recoverability and drift control Device configs Versioned backups, diffs Backup success ≥99%, RTO met No rollback path; config drift undetected

1.3 Working Principles

Startup Sequence

The startup sequence is designed to establish security controls in the correct order before exposing any service to the network. This prevents a window of vulnerability during boot where the device might be accessible without full security controls in place.

  1. Hardware boot → secure image verification (where supported) → load base config.
  2. Management plane up first: mgmt VRF interfaces, SSH/HTTPS; NTP sync; syslog target reachable.
  3. AAA reachability validated; if AAA fails, device enters restricted mode (local break-glass only, logged).
  4. Control plane: routing processes start; neighbors established only on permitted interfaces; authentication checked.
  5. Data plane: ACL/uRPF applied; default deny boundaries enforced; monitoring enabled.

Normal Operation

During normal operation, the router continuously enforces its security baseline while maintaining full operational capability. Periodic AAA accounting ensures all privileged commands are logged; periodic config compliance checks detect drift from the approved baseline; route policy ensures only intended prefixes propagate; CoPP remains active with any punt spikes triggering alarms; and backups run on schedule with diffs requiring change ticket references.

Exception Chains

The following table documents the three most critical exception scenarios, their detection mechanisms, behavioral responses, and recovery procedures. Each exception chain has been designed to fail safely — that is, the default behavior upon failure is to restrict access rather than grant it.

Exception Trigger Mechanism System Behavior Recovery Action
AAA Outage AAA server unreachable; admins cannot authenticate normally Allow only break-glass account from OOB subnet; generate high-severity SIEM alert; enforce short session timeout Restore AAA connectivity; require post-event credential rotation; review break-glass usage logs
BGP Session Hijack Attempt Attacker spoofs neighbor IP or connects on wrong interface Peer ACL denies; TCP-AO/MD5 fails; logs "auth failure"; CoPP rate-limits repeated SYNs; no route installed Review peer ACL; confirm authentication keys; investigate source of attempts; alert SecOps
Control-Plane Flood Excessive ICMP/TTL-expired/fragment punts to CPU CoPP drops/limits classes; CPU remains stable; routing adjacencies preserved; alert triggers with top talkers Identify top talker; apply upstream filter; tune CoPP class; coordinate with upstream provider if needed
Bad Change / Outage Incorrect ACL rule order denies critical traffic Pre-check (staged commit/confirm timer) detects reachability loss; automatic rollback; ticket flagged Review config diff; identify root cause; apply corrected change with peer review; update test cases