Op deze pagina
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.
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.
Mogelijke oplossingen
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.
- Hoe BGP werkt: prefixes, AS paths, routingbeslissingen en DDoS-impact
Bekijk prefixes, AS path en BGP-keuzes.
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.
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.
