Peering vs transit bij DDoS: wat verandert er echt tijdens een aanval?

Definitie van het probleem

Het probleem is dat peering een onbeschermde ingang kan worden. Een kort en goedkoop pad kan verzadigen als het niet verbonden is met de mitigatielaag. Veel teams ontdekken dit pas tijdens een serieus incident, wanneer routes al onder druk worden aangepast.

peering vs transit DDoS dwingt om het volledige pad te bekijken: BGP announcement, gekozen upstream, echte poortcapaciteit, beschikbare filtering, clean traffic handoff en gedrag van de dienst. Als één punt onduidelijk blijft, kan mitigatie theoretisch werken maar praktisch falen.

Ook commerciële taal is een probleem. “Veel capaciteit” legt niet uit wat gebeurt met legitieme UDP, bestaande TCP, latency, BGP communities of tijdelijke regels. Technische kopers willen mechaniek, niet alleen cijfers.

Waarom dit belangrijk is

Een verkeerde keuze wordt direct zichtbaar als storing. Eindgebruikers zien geen verschil tussen transitverzadiging, slechte BGP-policy of een te agressief filter; ze zien timeouts, packet loss of disconnects.

Ook kosten worden geraakt. Aanvalstraffic via het verkeerde pad kan 95th percentile, backbonegebruik en supporttickets verhogen. De architectuur moet de aanval vroeg reduceren zonder legitiem verkeer te offeren.

Voor latencygevoelige diensten zoals FiveM, Minecraft, VoIP of interactieve APIs moet stabiliteit behouden blijven. Bescherming die online blijft maar slecht aanvoelt is niet genoeg.

In de praktijk moet elk ontwerp vóór de klantmigratie worden getest: gecontroleerde verkeerssamples, duidelijke grenswaarden, vastgelegde rollback-stappen en een contactpunt per carrier. Die voorbereiding klinkt minder spectaculair dan grote capaciteitscijfers, maar bepaalt vaak of een platform tijdens een echte aanval stabiel blijft of dat het team onder druk moet improviseren.

Mogelijke oplossingen

Eerst moet het ingressmodel beschreven zijn: welke prefixes, welk ASN, welke upstreams en welke BGP-policy. Zonder basis kan automatisering het incident verergeren.

Daarna is proportionele filtering nodig. Blackhole, ACL, FlowSpec, scrubbing en rate-limit hebben verschillende impact. Elk middel heeft rol en eindtijd nodig.

Verder moet clean traffic delivery vóór de aanval vaststaan. GRE, IPIP, VXLAN, router-VM en cross-connect zijn geldig, maar verschillen in latency, controle en uitrol.

De juiste vraag is niet absoluut peering of transit, maar welk pad capaciteit, filtering, support en clean handoff biedt tijdens aanval.

De keuze moet ook regelmatig opnieuw worden geëvalueerd. Een peer die vandaag nuttig is, kan morgen een risico worden wanneer volumes sterk groeien, nieuwe klanten met gevoelig UDP-verkeer bijkomen of aanvalspatronen veranderen. Omgekeerd kan transit die duur lijkt strategisch zinvol zijn wanneer die betere paden naar belangrijke eindgebruikersnetwerken, duidelijke DDoS-processen of betrouwbaardere retourroutes biedt. Goede architectuur is daarom geen statisch schema, maar een doorlopend routing- en capaciteitsplan.

Peering of transit kiezen wanneer het aanvalspad verandert

Peeryx bekijkt dit eerst als netwerkontwerp: traffic naar een laag trekken die volume aankan, duidelijke aanvalsdelen verminderen en clean traffic teruggeven zonder de topologie te verbergen.

Het gaat niet om permanente generieke regels. FlowSpec of upstream filtering moet precies, tijdelijk en observeerbaar zijn. Tunnels of cross-connects moeten gedocumenteerd zijn.

Commercieel telt een bescherming die de klant begrijpt: pad, limieten, drempels, support en rollback in plaats van vage onbeperkte mitigatie.

Bij DDoS is peering niet automatisch beter of slechter dan transit. Peering kan latency en kosten verbeteren, maar legt ook meer verantwoordelijkheid bij je eigen routing- en filterbeleid. Zonder voldoende monitoring en mitigatiecapaciteit kan een directe peer een aanval heel efficiënt tot aan je eigen edge brengen.

Concreet gebruiksvoorbeeld

Een gamingdienst houdt peering voor normaal verkeer, maar verplaatst het aangevallen prefix naar beschermde transit wanneer een flood uit een specifiek ISP-netwerk komt.

Tijdens het incident kijkt het team naar volume, PPS, protocol, poorten, actieve routes en latency per ASN. Vermindert de actie de aanval zonder legitiem verkeer te raken, dan blijft ze actief; anders wordt ze smaller of verwijderd.

Na het incident gaan de gegevens in het runbook: welke community gebruiken, welk prefix verplaatsen, welke regel niet herhalen en welke capaciteit later nodig is. Zo verbetert de bescherming per aanval.

Transit is vaak duurder per Mbps, maar biedt meestal operationele processen, wereldwijde bereikbaarheid en soms DDoS-functies zoals blackhole, communities of FlowSpec. De juiste keuze is vaak een mix: peering voor gecontroleerde volumes en goede paden, transit voor bereik, beschermingsfuncties en voorspelbare escalatie.

Veelgemaakte fouten

• Capaciteit verwarren met echte mitigatie.
• BGP-wijzigingen improviseren tijdens aanval.
• Te brede filters op UDP of TCP toepassen.
• Latency en packet loss tijdens mitigatie niet meten.
• Het retourpad van clean traffic vergeten.
• Geen duidelijke rollback voor tijdelijke regels hebben.

FAQ