Peering vs. Transit bei DDoS: was sich während eines Angriffs wirklich ändert

Definition des Problems

Das Problem ist, dass Peering zu einem ungeschützten Eingang werden kann. Ein kurzer und günstiger Pfad kann sättigen, wenn er nicht mit der Mitigation verbunden ist. Viele Teams erkennen das erst im ersten ernsten Incident, wenn Routen bereits unter Druck geändert werden.

Peering vs Transit DDoS zwingt dazu, den kompletten Pfad zu betrachten: BGP-Announcement, gewählter Upstream, echte Portkapazität, verfügbares Filtering, Clean-Traffic-Handoff und Verhalten des Dienstes. Bleibt ein Punkt undefiniert, kann die Mitigation theoretisch funktionieren und praktisch scheitern.

Auch die kommerzielle Sprache ist ein Problem. “Viel Kapazität” erklärt nicht, was mit legitimem UDP, etabliertem TCP, Latenz, BGP-Communities oder temporären Regeln geschieht. Technische Käufer brauchen Mechanik, nicht nur Zahlen.

Warum es wichtig ist

Eine falsche Entscheidung wird sofort als Ausfall sichtbar. Endnutzer unterscheiden nicht zwischen Transit-Sättigung, schlechter BGP-Policy und zu aggressivem Filter; sie sehen Timeouts, Paketverlust oder Disconnects.

Auch Kosten sind betroffen. Angriffstraffic auf dem falschen Pfad kann 95th Percentile, Backbone-Nutzung und Supportaufwand erhöhen. Die Architektur muss den Angriff früh reduzieren, ohne legitimen Traffic zu opfern.

Für latenzsensitive Dienste wie FiveM, Minecraft, VoIP oder interaktive APIs muss Stabilität erhalten bleiben. Schutz, der den Dienst online hält, aber die Nutzung ruiniert, reicht nicht.

In der Praxis sollte jedes Design vor der Kundenmigration getestet werden: kontrollierte Traffic-Samples, klare Grenzwerte, definierte Rollback-Schritte und ein Ansprechpartner pro Carrier. Diese Vorbereitung wirkt weniger spektakulär als große Kapazitätszahlen, entscheidet aber oft darüber, ob eine Plattform während eines echten Angriffs stabil bleibt oder ob das Team im Notfall improvisieren muss.

Mögliche Lösungen

Zuerst muss das Ingress-Modell dokumentiert sein: welche Präfixe, welches ASN, welche Upstreams und welche BGP-Policy. Ohne diese Basis kann Automation den Incident verschlimmern.

Zweitens braucht es proportionale Filterung. Blackhole, ACL, FlowSpec, Scrubbing und Rate-Limit haben unterschiedliche Auswirkungen. Jedes Werkzeug braucht Rolle und Ablaufzeit.

Drittens muss Clean-Traffic-Delivery vor dem Angriff feststehen. GRE, IPIP, VXLAN, Router-VM und Cross-Connect sind gültige Optionen, aber sie unterscheiden sich in Latenz, Kontrolle und Rollout.

Die richtige Frage ist nicht Peering oder Transit absolut, sondern welcher Pfad Kapazität, Filtering, Support und sauberen Handoff im Angriff bietet.

Die Entscheidung sollte außerdem regelmäßig überprüft werden. Ein Peer, der heute nützlich ist, kann morgen ein Risiko werden, wenn Volumen stark steigt, neue Kunden mit empfindlichem UDP-Traffic hinzukommen oder die Angriffsmuster sich ändern. Ebenso kann ein Transit, der teuer wirkt, strategisch sinnvoll sein, wenn er bessere Pfade zu wichtigen Endkundennetzen, klare DDoS-Prozesse oder zuverlässigere Rückwege bietet. Gute Architektur ist deshalb kein statisches Diagramm, sondern ein laufender Routing- und Kapazitätsplan.

Peering oder Transit wählen, wenn der Angriffspfad wechselt

Peeryx betrachtet das zuerst als Netzwerkdesign: Traffic zu einer absorptionsfähigen Schicht ziehen, offensichtliches Angriffsvolumen reduzieren und sauberen Traffic zurückgeben, ohne die Topologie zu verschleiern.

Es geht nicht um permanente generische Regeln. FlowSpec oder Upstream-Filtering müssen präzise, zeitlich begrenzt und beobachtbar sein. Tunnel oder Cross-Connect müssen dokumentiert sein.

Kommerziell zählt eine Schutzlösung, die der Kunde versteht: Pfad, Grenzen, Schwellen, Support und Rollback statt unendlicher Mitigationsversprechen.

Bei DDoS ist Peering nicht automatisch besser oder schlechter als Transit. Peering kann Latenz und Kosten verbessern, aber es verteilt auch mehr Verantwortung auf die eigene Routing- und Filterpolitik. Ohne ausreichende Monitoring- und Mitigation-Kapazität kann ein direkter Peer einen Angriff sehr effizient bis an die eigene Kante liefern.

Konkreter Anwendungsfall

Ein Gaming-Dienst behält Peering für normalen Traffic, verschiebt aber das angegriffene Präfix zu geschütztem Transit, wenn ein Flood aus einem bestimmten ISP-Netz kommt.

Im Incident prüft das Team Volumen, PPS, Protokoll, Ports, aktive Routen und Latenz je ASN. Reduziert die Aktion den Angriff ohne legitimen Traffic zu beschädigen, bleibt sie aktiv; sonst wird sie enger gefasst oder entfernt.

Nach dem Incident werden Daten in das Runbook übernommen: welche Community, welches Präfix, welche Regel nicht wiederholen und welche Kapazität später nötig ist. So verbessert sich die Schutzlogik mit jedem Angriff.

Transit ist dagegen oft teurer pro Mbps, bringt aber vertragliche Betriebsprozesse, globale Erreichbarkeit und teilweise DDoS-Funktionen wie Blackhole, Communities oder FlowSpec mit. Die richtige Antwort ist häufig eine Mischung: Peering für kontrollierte Volumen und gute Pfade, Transit für Reichweite, Schutzfunktionen und berechenbare Eskalation.

Häufige Fehler

• Kapazität mit echter Mitigation verwechseln.
• BGP-Änderungen im Angriff improvisieren.
• Zu breite Filter auf UDP oder TCP anwenden.
• Latenz und Paketverlust während Mitigation nicht messen.
• Den Rückweg für Clean Traffic vergessen.
• Keinen klaren Rollback für temporäre Regeln haben.

FAQ