Sur cette page
À retenir
- Le peering est sélectifIl peut réduire coût et latence vers certains réseaux, mais ce n’est pas une couverture Internet globale.
- Le transit apporte de la couvertureUn transitaire offre une joignabilité plus large et souvent plus de contrôles liés au DDoS.
- Le DDoS change l’économieUn trafic entrant bon marché ne l’est plus s’il sature un port et contourne la mitigation.
Définition du problème
Le problème est que le peering peut attirer du trafic sans offrir le même modèle de service qu’un transit protégé. Une session de peering public peut donner une excellente latence vers un gros FAI, mais si un flood arrive par ce port et qu’il n’existe pas de chemin de mitigation, le chemin le plus court devient le chemin de panne.
Le transit, de son côté, n’est pas automatiquement propre. Un transitaire classique peut fournir full routes et reachability mondiale, mais s’il ne propose qu’un blackhole basique, le service protégé a encore besoin d’une autre couche. La vraie question n’est pas “peering ou transit ?”, mais “quel chemin a la capacité, le filtrage, le support et le handoff contrôlé pendant l’attaque ?”
Le DDoS interagit aussi avec la politique BGP. Une route plus spécifique, un changement d’AS path ou une communauté peut déplacer le trafic du peering vers un transit protégé. Mais si cette politique est improvisée pendant l’incident, elle peut créer asymétrie, mauvais chemins retour ou coût inattendu.
Pourquoi c’est important
C’est important parce que beaucoup de réseaux optimisent d’abord le trafic normal : commit transit plus bas, plus de peering, trafic entrant moins cher, chemins plus courts. C’est logique, mais le DDoS n’est pas du trafic normal. Il peut arriver par le chemin le moins cher, le plus rapide ou le moins préparé.
Pour un serveur de jeu, une plateforme SaaS, du streaming ou de l’hébergement, une décision de peering peut devenir un sujet support. Les utilisateurs disent “le serveur est down” alors que la cause réelle est une entrée régionale via un point d’échange saturé. Sans visibilité par ingress, l’opérateur accuse le mauvais firewall, serveur ou logiciel.
Un transit protégé doit expliquer filtrage, alternatives au blackhole, options FlowSpec, limites de capacité et livraison de trafic propre. Un pair public ne fournit généralement pas ce niveau de service DDoS spécifique au client.
Les solutions possibles
Une solution consiste à garder le peering pour le trafic normal faible latence, mais à router les préfixes attaqués par le transit protégé. On garde l’avantage performance tout en donnant un vrai chemin de mitigation aux ingénieurs.
Une autre solution est la dé-préférence sélective : pendant l’attaque, des communautés ou route-maps rendent certains chemins moins attractifs sans retirer le service. Cela demande des tests et du monitoring.
Une troisième option consiste à conserver le peering public, mais avec suffisamment de capacité et de filtrage sur l’edge IXP : ACL, sampling, FlowSpec interne et escalade claire auprès du peer ou de l’IXP quand l’abus est visible.
Enfin, certains services doivent simplement utiliser le transit protégé comme chemin entrant principal. Si la disponibilité sous attaque compte plus que quelques millisecondes ou quelques euros, il vaut mieux concevoir la protection d’abord et optimiser le peering ensuite.
- Comprendre BGP : préfixes, AS path et choix de routes
Revoir préfixes, AS path et décisions BGP.
Cas concret ou exemple d’usage
Un fournisseur gaming peer sur un IXP pour une faible latence vers un gros FAI et achète du transit chez deux upstreams. En temps normal, les métriques sont excellentes. Puis les attaquants ciblent le port de query du jeu depuis l’empreinte de ce même FAI. Le trafic entre par peering car le chemin est préféré et sature le port IXP.
La réaction rapide mais mauvaise est de couper la session de peering. Cela peut restaurer la stabilité, mais augmente la latence pour tous les utilisateurs de ce FAI. Un meilleur design déplace seulement le préfixe ou service attaqué vers le transit protégé, applique un filtrage ciblé et garde le reste du peering actif lorsqu’il reste sain.
Après l’incident, l’opérateur compare latence, perte, volume ingress et faux positifs. Ce retour permet de décider si le service reste sur transit protégé, revient au peering ou utilise une politique hybride.
Erreurs fréquentes
- Croire que le peering est toujours meilleur parce que le chemin est plus court.
- Utiliser le peering public comme contournement non protégé de la mitigation.
- Acheter du transit uniquement au prix sans demander les contrôles DDoS.
- Modifier AS path ou more-specific pendant l’attaque sans plan de rollback.
- Ignorer la capacité inbound des ports IXP.
- Mélanger traffic engineering normal et traffic engineering d’attaque.
FAQ
Le peering est-il mauvais pour l’Anti-DDoS ?
Non. Il peut être excellent, mais il ne doit pas contourner la mitigation des services qui ont besoin d’être protégés.
Le transit est-il toujours plus sûr ?
Pas automatiquement. Un transit protégé avec filtrage et handoff propre est différent d’un transit classique avec blackhole seulement.
Peut-on combiner peering et transit protégé ?
Oui. Beaucoup de designs solides gardent le peering pour le trafic normal et utilisent le transit protégé pour les préfixes attaqués ou critiques.
Le peering réduit-il la latence ?
Souvent vers certains réseaux. Mais si le chemin peering sature sous attaque, l’expérience réelle devient pire qu’un chemin protégé légèrement plus long.
