Control-Plane Protection ist im Telco- und Provider-Design kein optionales „Security-Feature“, sondern ein topologischer Baustein für Stabilität. Wenn die Control Plane eines Routers oder einer Plattform instabil wird, fühlt sich das für Kunden selten wie ein klarer Ausfall an – eher wie „das Netz ist komisch“: sporadische Paketverluste, wechselnde Pfade, erhöhte Latenz, BGP-Sessions flappen, IGP konvergiert wiederholt, oder Services werden partiell unerreichbar. Besonders gefährlich ist, dass Control-Plane-Probleme oft kaskadieren: Ein überlasteter Router erzeugt mehr Routing-Churn, dieser Churn belastet Nachbarn, und plötzlich wird aus einem lokalen Problem ein regionaler Incident. Deshalb gehört Control-Plane Protection in die Topologie: Wo werden Protokolle terminiert? Welche Rollen haben Edge-, Core- und Service-Devices? Welche Pfade nutzen Management, Telemetry und Routing? Und wie werden Attacken oder Fehlkonfigurationen so abgefangen, dass sie lokal bleiben? In der Praxis sind drei Werkzeuge besonders wichtig: CoPP (Control Plane Policing), RTBH (Remote Triggered Black Hole) und FlowSpec. Richtig eingesetzt sind sie nicht nur Abwehrmechanismen gegen DDoS, sondern definieren auch Guardrails gegen Routing- und Management-Überlast: CoPP schützt CPU und Control-Plane-Queues, RTBH ermöglicht extrem schnelle, einfache Mitigation an der richtigen Stelle (Ingress/Edge), und FlowSpec erlaubt granulare Filterregeln, die sich policygesteuert und topologisch kontrolliert verteilen lassen. Dieser Artikel zeigt, wie Sie CoPP, RTBH und FlowSpec als Topologie-Bausteine planen: mit klaren Domain-Grenzen, sicheren Distribution-Mechanismen, sinnvollen Templates, Observability und Runbooks – damit Schutzmaßnahmen nicht selbst zum Risiko werden.
Warum die Control Plane der „Single Point of Weirdness“ ist
Im Provider-Netz ist die Datenebene (Forwarding) oft hochperformant und hardwarebeschleunigt. Die Control Plane dagegen ist begrenzter: CPU, Interrupts, Kernel-Queues, Prozess-Scheduler und Protokolldämonen. Viele Ereignisse zielen genau darauf ab oder wirken indirekt darauf: DDoS auf Routing-Interfaces, massenhafte ICMP/TTL-Expired, BGP/OSPF/IS-IS Flooding, malformed packets, oder auch „harmlose“ Telemetry-Fehlkonfigurationen mit zu vielen Streams. Wenn die Control Plane überlastet, hat das drei typische Folgen: Konvergenz wird langsam, Routing flappt, und Management/Telemetry fällt aus – also genau die Instrumente, die man zur Diagnose braucht.
- CPU Saturation: Routing- und Managementprozesse reagieren zu langsam; Sessions resetten, SPF-Läufe häufen sich.
- Queue/Buffer Pressure: Control-Plane-Pakete droppen; Protokolle verlieren Keepalives.
- Self-amplifying Churn: Instabilität erzeugt mehr Updates, die Instabilität verstärken.
- Blindflug-Risiko: Telemetry und Remote-Zugriff brechen; Troubleshooting wird schwer.
Leitprinzip: Protect the control plane to protect the network
Control-Plane Protection ist letztlich Resilienz-Engineering: Sie verhindern, dass ein lokales Störsignal eine großflächige Routing- oder Serviceinstabilität auslöst.
Topologisches Denken: Wo Control-Plane-Risiken entstehen
Control-Plane-Risiken sind nicht überall gleich. Sie konzentrieren sich auf Rollen und Kanten: Interconnect/Internet Edge (untrusted), Customer Edge (untrusted), Service-Edges (stateful und komplex), und Management-/Telemetry-Pfade. Der Core ist oft besser kontrolliert, aber im Core sind Blast Radien größer, daher sind Guardrails dort besonders wichtig. Ein gutes Design klassifiziert Interfaces und Pfade in Vertrauenszonen und passt CoPP/RTBH/FlowSpec entsprechend an.
- Internet/Peering Edge: Hohe Exposition, viele unerwartete Pakettypen; DDoS- und Scan-Risiko.
- Customer Edge: Heterogene Kunden, Fehlkonfigs und Missbrauch; BGP- und ICMP-Fluten möglich.
- Service Chains: CGNAT/Firewall/DDoS-Systeme erzeugen Steuertraffic; asymmetrische Pfade können Control-Plane belasten.
- Management/Telemetry: OOB/In-Band Management braucht eigene Schutzprofile, sonst wird es im Incident unbrauchbar.
Designregel: Rollenbasierte Policies statt „eine CoPP für alles“
Eine generische CoPP-Policy ist selten optimal. Besser ist ein Rollenmodell: Core-CoPP, Edge-CoPP, Customer-CoPP, Service-Edge-CoPP, Management-CoPP – mit klaren Templates.
CoPP (Control Plane Policing): Funktion und Designprinzipien
CoPP begrenzt und priorisiert Traffic zur Control Plane. Wichtig ist dabei, nicht „alles zu blocken“, sondern legitime Protokolle zu schützen und illegitime oder übermäßige Pakete zu drosseln. CoPP wird schnell gefährlich, wenn es zu aggressiv ist: Dann verursachen Sie selbst Routinginstabilität. Deshalb ist CoPP ein Balanceakt zwischen Sicherheit, Verfügbarkeit und Diagnosierbarkeit.
- Klassifizieren: Welche Pakete dürfen zur CPU (Routingprotokolle, BFD, Management, ICMP in definierten Grenzen)?
- Priorisieren: Kritische Protokolle (IGP/BFD/BGP) bekommen garantierte Budgets.
- Drosseln: Untrusted ICMP/TTL-Expired/Fragmentation/Scan-Traffic wird begrenzt.
- Default-deny/Default-police: Unbekannte Control-Plane-Pakete werden auf niedrige Raten gesetzt.
Ein praktisches CoPP-Zielbild
CoPP soll nicht „Stille“ erzeugen, sondern „Vorhersagbarkeit“: Legitimer Control-Plane-Traffic funktioniert auch im Stress, illegitimer Traffic wird begrenzt, und die CPU bleibt reaktionsfähig.
CoPP als Topologie-Baustein: Trust Zones und Interface-Klassen
CoPP wirkt am besten, wenn Interface-Klassen im Design feststehen. Ein Edge-Interface zum Internet braucht andere Regeln als ein Core-Link. Ebenso unterscheidet sich ein Management-Interface (OOB) stark von einem Customer-Facing-Interface. Topologie-Patterns definieren daher pro Interface-Klasse, welche Control-Plane-Pakete erwartet sind.
- Core Links: Nur interne Routingprotokolle und BFD; ICMP sehr begrenzt; keine „fremden“ Protokolle.
- Interconnect Ports: BGP plus begrenztes ICMP; strenge Schutzprofile gegen Scans/Abuse.
- Customer Ports: BGP/OSPF je nach Angebot, aber streng gefiltert; keine unnötigen Control-Plane-Pakete.
- Management: SSH/API/Telemetry, streng auf Jump-Zones beschränkt; Rate-Limits gegen Login-Floods.
Anti-Pattern: CoPP als nachträgliches Patchwork
Wenn CoPP erst nach Incidents „irgendwie“ ergänzt wird, entstehen oft unvollständige oder gefährliche Regeln. Besser ist, CoPP von Beginn an als Rollen-/Interface-Template zu planen und zu testen.
RTBH (Remote Triggered Black Hole): Schnelle Mitigation mit minimaler Komplexität
RTBH ist ein bewährtes Mittel, um volumetrische Angriffe schnell zu stoppen: Traffic zu einem Ziel (oder in manchen Modellen zu einem Source/Target-Muster) wird in der Nähe des Ingress verworfen. Der Charme von RTBH ist die Einfachheit und Geschwindigkeit: Ein BGP-Announcement mit einer Blackhole-Community kann innerhalb kurzer Zeit netzweit wirken – vorausgesetzt, die Topologie und Policy unterstützen es.
- Edge-nahe Wirkung: Traffic wird möglichst früh verworfen, bevor er Backbone/Interconnect belastet.
- Simple Policy: Standardisierte Blackhole-Community, die nur in definierten Domänen akzeptiert wird.
- Begrenzter Scope: RTBH sollte nur für autorisierte Ziele nutzbar sein; sonst wird es selbst zur Waffe.
- Operative Geschwindigkeit: Ideal für „Stop the bleeding“, während feinere Mitigation vorbereitet wird.
Designregel: RTBH braucht Containment und Authentizität
Blackhole-Routen dürfen nur aus vertrauenswürdigen Quellen kommen (z. B. DDoS-Systeme/SOC) und nur in klar definierten Routenbereichen wirken, sonst riskieren Sie Missbrauch oder Self-Inflicted Outages.
RTBH-Topologie: Wo RTBH ankern sollte
RTBH ist am effektivsten, wenn es an der Edge greift: dort, wo Traffic ins Netz kommt. Das bedeutet: Sie brauchen eine konsistente BGP-Policy, die Blackhole-Communities auf Edge/Interconnect akzeptiert und in Richtung der richtigen Ingress-Punkte propagiert – aber nicht darüber hinaus, wo es gefährlich wird. In Multi-Region-Netzen ist es sinnvoll, RTBH regional zu begrenzen, um versehentlich globale Blackholes zu vermeiden.
- Internet Edge: Blackhole wirkt vor Transit/Peering-Ingress oder direkt am Edge-Router.
- Backbone Core: Core sollte RTBH nur transportieren, nicht „generieren“; klare Policy verhindert Leaks.
- Regionale Begrenzung: Optional regionale Communities, um Failover und lokale Mitigation zu steuern.
- Scrubbing Integration: RTBH als schneller Stop, Scrubbing als selektive, nachhaltige Mitigation.
Anti-Pattern: RTBH ohne Logging und Review
Blackholes sind drastisch. Ohne klare Dokumentation, Zeitlimits und Review-Prozesse bleiben Blackholes manchmal „liegen“ und verursachen unnötige Ausfälle.
FlowSpec: Granulare, policygesteuerte Filter als Routing-Feature
BGP FlowSpec ermöglicht es, Filterregeln (z. B. für DDoS-Muster) über BGP zu verteilen und nahe am Ingress anzuwenden. Im Vergleich zu RTBH ist FlowSpec feiner: Sie können nur bestimmte Protokolle, Ports oder Paketgrößen matchen und Maßnahmen wie Drop, Rate-Limit oder Marking anwenden. Genau deshalb ist FlowSpec mächtig – und potenziell riskant, wenn Governance und Topologie nicht stimmen.
- Granularität: Match auf 5-Tuple, Protokoll, Ports, Flags, Fragmentation etc. (plattformabhängig).
- Aktionen: Drop, Rate-Limit, Redirect (z. B. zu Scrubbing), Marking – je nach Implementierung.
- Distribution: Über BGP, dadurch schnell und skalierbar, aber nur mit strikten Trust-Policies.
- Use Cases: DDoS-Mitigation, Abuse-Control, temporäre Schutzregeln, ohne ganze Ziele zu blackholen.
Designregel: FlowSpec nur aus einer „Policy Authority“ zulassen
FlowSpec muss aus klaren, autorisierten Quellen kommen (z. B. DDoS-Controller/SOC) und darf nicht frei durch das Netz „wandernd“ entstehen. Sonst drohen Self-Inflicted Outages durch falsche Regeln.
FlowSpec-Topologie: Scope, RR-Design und Containment
FlowSpec ist ein Inter-Domain-ähnliches Werkzeug innerhalb Ihres Netzes. Deshalb gelten ähnliche Guardrails wie bei Route Leaks: Domänengrenzen, Default-deny, Max-Limits und klare RR-Topologien. In großen Telco-Netzen wird FlowSpec oft über dedizierte RR-Cluster oder spezielle Address Families verteilt, um die normale Routing-Control-Plane nicht zu destabilisieren.
- Separate Distribution: Eigene RR-Cluster oder klare AFI/SAFI-Policy, damit FlowSpec Updates nicht das Basisrouting belasten.
- Regionalisierung: FlowSpec nur dort verteilen, wo es wirken soll (Region, PoP, Edge), nicht zwangsläufig global.
- Rule Limits: Maximale Anzahl Regeln, maximale Update-Raten, Timeouts/Expiries für Regeln.
- Containment: Keine Propagation zu Kunden/Peers; klare Export-Filter.
Anti-Pattern: FlowSpec „global default“
Globale FlowSpec-Verteilung ohne Scope kann im Fehlerfall ein globales Problem erzeugen. Besser ist ein bewusstes, topologisch begrenztes Modell.
CoPP, RTBH und FlowSpec zusammendenken: Ein abgestuftes Schutzmodell
Diese Mechanismen sind keine Konkurrenz, sondern unterschiedliche Ebenen eines Schutzmodells. CoPP schützt einzelne Geräte vor Control-Plane-Überlast (lokal). RTBH stoppt grobe volumetrische Angriffe schnell (netzweit, aber grob). FlowSpec bietet selektive Mitigation (netzweit, aber kontrolliert). Ein gutes Design definiert, wann welcher Hebel gezogen wird und wie sie zusammenarbeiten.
- Stufe 1 (Device Safety): CoPP verhindert, dass Router-CPU und Routing-Protokolle kollabieren.
- Stufe 2 (Stop the Bleeding): RTBH blockt extrem schnell, wenn ein Ziel überrollt wird.
- Stufe 3 (Selective Mitigation): FlowSpec reduziert Kollateralschäden durch gezieltes Filtern/Rate-Limits.
- Stufe 4 (Scrubbing/Service): Redirect zu Scrubbing oder spezialisierten DDoS-Systemen für nachhaltige Abwehr.
Designregel: Jede Stufe braucht Governance und Observability
Schutzregeln müssen sichtbar, auditierbar und zeitlich kontrolliert sein. Sonst werden sie selbst zur Fehlerquelle.
Observability: Schutzmaßnahmen müssen messbar sein
Control-Plane Protection ist nur dann erfolgreich, wenn sie messbar ist: CoPP-Counter, Drops pro Klasse, CPU/Memory, BGP/IGP Health, Queue-Drops und Traffic-Mix. Ebenso wichtig sind High-Signal Alerts: Nicht jeder Drop ist ein Incident, aber ein Drop plus SLO-Impact ist kritisch. Zusätzlich müssen die Mitigation-Systeme selbst beobachtbar sein (FlowSpec Rule Count, RTBH aktiv, Expiry-Status).
- CoPP Telemetry: Klassen-Counter, Drops, Rate-Limit Hits, CPU-Trends, Control-Plane Queue-Health.
- Routing Health: BGP Session Stability, Prefix-Counts, Update-Raten, Konvergenzzeiten.
- DDoS Visibility: Flow/IPFIX, PPS/bps, Top Targets, Top Sources, Interconnect-Auslastung.
- Mitigation State: RTBH- und FlowSpec-Regeln als Inventar mit Owner, Startzeit, TTL/Expiry.
High-Signal Alerting für Control-Plane Risiken
Ein wirksamer Alarm ist z. B. „CoPP-Drops steigen + BGP Keepalives verlieren + p99 Latenz steigt“ – nicht „CPU kurz 85%“. Korrelation nach Region/PoP/Rolle reduziert Noise.
Runbooks und Change Risk: Schutz darf nicht selbst instabil machen
CoPP/RTBH/FlowSpec sind mächtige Eingriffe. Ohne klare Runbooks und progressive Rollouts riskieren Sie Self-Inflicted Outages. Besonders CoPP sollte in Wellen ausgerollt werden: Canary auf einem PoP, dann Batch, dann breite Rollouts. RTBH/FlowSpec benötigen klare Authority-Modelle: wer darf Regeln setzen, wie werden sie freigegeben, wie lange gelten sie, und wie wird zurückgebaut?
- CoPP Rollout: Canary → Batch → Rollout, mit SLO-Gates und Rollback-Kriterien.
- Authority Model: SOC/DDoS-Controller als einzige Quelle für RTBH/FlowSpec; Netzteam kontrolliert Distribution.
- Expiry by Default: Regeln laufen automatisch aus, wenn sie nicht erneuert werden.
- Post-Incident Review: Welche Regeln waren nötig? Welche Kollateralschäden? Templates verbessern.
Anti-Pattern: „Wir aktivieren FlowSpec und sind fertig“
Ohne Governance, Limits und Observability kann FlowSpec zum globalen Risiko werden. Es ist ein Topologie- und Betriebsfeature, nicht nur ein Protokoll.
Typische Failure Scenarios und passende Guardrails
- ICMP/TTL Flood auf Edge: CoPP begrenzt ICMP zur CPU, ohne Troubleshooting komplett zu zerstören; Rate-Limits pro Klasse.
- Volumetrischer DDoS auf Ziel-IP: RTBH als Sofortmaßnahme, danach FlowSpec/Scrubbing für selektive Filter.
- Reflected UDP Attack: FlowSpec Drop/Rate-Limit für Protokoll/Port-Kombination, RTBH nur bei Bedarf.
- Control-Plane Churn durch Leak: Max-Prefix/Update-Rate Monitoring plus CoPP/CoPP-ähnliche Schutzprofile, RR-Containment.
- Telemetry Misconfig (zu viele Streams): CoPP/Management-Policing, getrennte Telemetry-Domain, Backpressure und Limits.
Praktische Leitlinien: CoPP/RTBH/FlowSpec als Topologie-Bausteine
- Rollen definieren: Core, Edge, Customer Edge, Service Edge, Management – je Rolle eigene Schutztemplates.
- CoPP systematisch bauen: Klassifizieren, priorisieren, drosseln; Default-police für unbekannte Control-Plane-Pakete.
- RTBH sauber integrieren: Standard-Community, autorisierte Quelle, Wirkung an der Edge, Logging und Expiry.
- FlowSpec kontrollieren: Policy Authority, Scope/Regionalisierung, Rule Limits, getrennte Distribution und Export-Filter.
- Containment planen: Schutzregeln dürfen nicht zu Kunden/Peers leaken; klare Domain-Grenzen und Filters.
- Observability verpflichtend: CoPP-Drops, CPU, Routing Health, DDoS-Visibility, Mitigation-Status als Dashboards und High-Signal Alerts.
- Progressiv ausrollen: Canary → Batch → Rollout, mit Go/No-Go Gates und getesteten Rollbacks.
- Runbooks etablieren: Trigger, Zuständigkeiten, Stop-Kriterien, Expiry, Post-Incident Review – damit Schutz stabil bleibt.
- Regelmäßig testen: Failure Workshops und kontrollierte Chaos-Experimente (kleiner Scope) zur Verifikation von Guardrails und SLOs.
