Résumé

  • Une étude de cas publiée en mars 2017 par Juniper attribue à Erik Bais et à l’équipe d’A2B Internet la validation en laboratoire puis le passage en production d’une plateforme de routage vMX pour les connexions Internet de l’opérateur.
  • Cette étude rapporte une convergence d’une table BGP complète en trois à quatre secondes et une résolution plus rapide des incidents provoqués par des changements répétés de routes, mais elle ne constitue pas un banc d’essai indépendant ni une promesse applicable à tous les réseaux.
  • Un compte rendu indépendant de l’Internet Society daté du 17 mai 2018 confirme que Bais a ouvert à RIPE 76 une discussion sur les attaques DDoS, les réseaux sources récurrents et la responsabilité des opérateurs en matière d’hygiène du routage.
  • AMS-IX décrit par ailleurs une méthode d’A2B fondée sur des données agrégées de mauvaise configuration, ajustées à la taille des réseaux, afin d’éclairer certaines décisions de peering et de traitement du trafic, sans démontrer un effet à l’échelle de l’écosystème.
  • La reprise rapide et l’hygiène du routage sont ici rapprochées comme deux disciplines de continuité opérationnelle : ce rapprochement est une analyse, non la preuve que le déploiement de 2017 a causé l’intervention de 2018 ou qu’Erik Bais a inventé les technologies concernées.

En mars 2017, une étude de cas de Juniper a décrit le choix d’Erik Bais et de l’équipe d’A2B Internet de faire passer une plateforme de routage vMX du laboratoire à la production. Le résultat rapporté était concret : une table BGP complète aurait convergé en trois à quatre secondes, avec une reprise plus rapide après des variations répétées de routes. Pour un client, l’enjeu est la durée pendant laquelle une destination peut devenir instable ou inaccessible lorsqu’un lien change. Pour un opérateur, l’enjeu est de prouver qu’une architecture réagit comme prévu, y compris avec IPv6 et plusieurs chemins.

Un compte rendu indépendant de 2018 montre un second volet du travail attribué à Bais : demander aux réseaux à l’origine récurrente d’attaques DDoS d’améliorer leur hygiène. Les deux épisodes éclairent une même discipline d’exploitation, sans établir entre eux de lien causal.

Une décision d’exploitation plutôt qu’une promesse abstraite

Le point de départ n’est ni un titre de fonction actuel ni une biographie générale. La page officielle d’A2B utilisée comme source présente Erik Bais comme fondateur et propriétaire de l’entreprise. Elle décrit un périmètre comprenant le transit Internet, la gestion BGP complète, la connectivité par fibre et des services de centres de données aux Pays-Bas. Ces éléments donnent un contexte d’opérateur. Ils ne démontrent pas, à eux seuls, l’impact personnel de Bais et ne permettent pas de déduire une activité ou une fonction au présent.

La contribution examinée est plus étroite. Dans son étude de cas de mars 2017, Juniper présente la croissance des tables de routage, la vitesse de convergence, la prise en charge d’IPv6 et la possibilité d’automatiser davantage les opérations comme des problèmes qu’A2B cherchait à traiter. Le document attribue à Bais l’idée opérationnelle selon laquelle la convergence doit être rapide lorsqu’un lien tombe. Il attribue ensuite à Bais et à son équipe la validation en laboratoire et la décision de déplacer vMX dans le réseau de production. Enfin, il indique que la plateforme a servi aux connexions d’A2B tournées vers Internet.

Cette séquence compte parce qu’elle rend la décision observable. Une technologie peut être disponible sans être adaptée à une exploitation donnée. Le travail de l’opérateur consiste alors à définir ce qui doit être vérifié, à tester le comportement dans un environnement contrôlé, à décider si le risque résiduel est acceptable et à assumer les conséquences du passage en production. Le document ne prouve pas que Bais a conçu vMX, BGP ou les mécanismes sous-jacents. Il montre plutôt un choix situé : évaluer une plateforme de routage, la confronter aux besoins du réseau d’A2B, puis l’utiliser pour des connexions réelles.

Ce que BGP coordonne entre les réseaux

BGP, pour Border Gateway Protocol, est le protocole par lequel des réseaux autonomes échangent des informations sur les destinations qu’ils peuvent atteindre et sur les chemins disponibles. Dans une lecture non spécialiste, il ressemble moins à un calcul d’itinéraire routier détaillé qu’à un système continu d’annonces : un réseau déclare qu’il peut acheminer du trafic vers certains préfixes d’adresses IP, ses voisins évaluent ces annonces selon leurs propres politiques, puis propagent ou non les chemins retenus. Les décisions sont distribuées.

Aucune vue locale ne suffit à représenter tout Internet, et chaque opérateur conserve une marge de choix sur les routes qu’il accepte ou préfère.

Une « table BGP complète » désigne ici l’ensemble très vaste des routes Internet reçues par un routeur, et non une simple liste interne de quelques destinations. Lorsqu’un chemin disparaît ou qu’un autre devient préférable, les équipements concernés doivent retirer, recalculer, sélectionner et parfois annoncer de nouvelles routes. La convergence est le moment où ces changements se stabilisent suffisamment pour que le réseau applique de nouveau une vue cohérente des chemins disponibles.

Plus cette transition dure, plus il existe une fenêtre pendant laquelle du trafic peut suivre un chemin obsolète, être rejeté ou osciller entre plusieurs possibilités.

Un « flap » BGP est une succession de retraits et de réannonces d’une route. Pour le lecteur professionnel, l’image utile est celle d’une porte qui s’ouvre et se ferme à répétition : chaque mouvement déclenche du travail de contrôle et peut compliquer le choix d’un chemin stable. Le document de Juniper rapporte une résolution plus rapide de ce type d’incident après le déploiement. Il ne fournit toutefois pas, dans le corpus retenu ici, un protocole complet permettant de comparer toutes les charges, tous les équipements ou toutes les topologies.

La portée raisonnable du résultat est donc celle d’un retour d’exploitation publié sur le cas d’A2B.

Lire correctement le chiffre de trois à quatre secondes

La convergence de trois à quatre secondes est rapportée dans un document commercial du fournisseur à propos de son client. Cela ne la rend pas inutile, mais cela impose une attribution visible. Le chiffre décrit ce que Juniper publie comme résultat d’A2B et de Bais. Il ne s’agit pas d’un test indépendant réalisé avec une méthodologie publiée par un tiers. Il ne faut donc ni le présenter comme un record, ni l’étendre à tous les réseaux, ni supposer qu’il couvre chaque scénario de défaillance.

Trois limites doivent rester ensemble. Premièrement, le périmètre correspond au réseau et au moment décrits dans l’étude de mars 2017. Deuxièmement, une table complète n’est qu’un aspect du comportement : la reprise perçue par une application dépend aussi du plan de données, des chemins en amont et en aval et de l’état des sessions. Troisièmement, un temps de convergence favorable ne garantit pas que les routes reçues soient exactes, souhaitables ou sûres. La rapidité du calcul ne remplace ni la qualité des politiques ni l’hygiène des réseaux voisins.

Ces limites expliquent pourquoi le chiffre doit être lu comme une preuve d’exploitation circonscrite. Il montre qu’un objectif de reprise a été formulé, qu’une plateforme a été testée puis mise en production et qu’un résultat a été communiqué. Il ne montre pas que l’ensemble de l’écosystème a bénéficié du déploiement. Il ne démontre pas davantage une baisse du volume d’attaques DDoS. La distinction protège le lecteur contre deux erreurs symétriques : rejeter toute donnée publiée par un fournisseur, ou lui accorder une portée qu’elle n’a pas.

IPv6, multihébergement et automatisation : un contexte borné

L’étude de cas mentionne également la validation d’IPv6, le multihébergement et une base pour l’automatisation. IPv6, ou Internet Protocol version 6, est la version du protocole d’adressage conçue avec un espace d’adresses beaucoup plus vaste que celui d’IPv4. Sa présence dans le test indique que la décision ne concernait pas uniquement un chemin IPv4 historique. Les sources ne détaillent cependant pas tous les scénarios IPv6 exécutés ; il faut donc s’en tenir à l’existence de cette validation rapportée.

Le multihébergement, souvent désigné par le terme anglais multihoming, consiste pour un réseau à disposer de plusieurs connexions ou chemins externes afin de ne pas dépendre d’un seul accès. BGP permet d’exprimer des préférences entre ces chemins et de réagir à leur disponibilité. Le bénéfice potentiel est la continuité, mais la pluralité des chemins augmente aussi le nombre de politiques et de transitions à comprendre. Une reprise rapide ne naît pas automatiquement du fait d’avoir plusieurs liens : elle dépend de la manière dont les équipements détectent les changements et appliquent les décisions de routage.

L’automatisation peut réduire les opérations répétitives et rendre des configurations plus cohérentes, mais le corpus ne précise pas quels processus d’A2B ont été automatisés ni quels résultats mesurés en ont découlé. La formulation correcte est donc celle d’une fondation rapportée, pas celle d’une transformation achevée. Pris ensemble, IPv6, multihébergement et automatisation élargissent le contexte du choix de plateforme. Ils ne changent pas la thèse centrale : le cas porte sur la discipline nécessaire pour déplacer une fonction critique vers la production et vérifier sa capacité de reprise.

Le second épisode : la sécurité du routage à RIPE 76

Le 17 mai 2018, l’Internet Society a publié un compte rendu de RIPE 76 centré sur la sécurité du routage. Ce texte, indépendant du document commercial de Juniper, identifie Erik Bais d’A2B Internet comme l’intervenant ayant ouvert la discussion avec une présentation consacrée aux attaques par déni de service distribué. Une attaque DDoS, pour Distributed Denial of Service, cherche à rendre un service indisponible en l’inondant de trafic provenant de nombreuses sources ou machines. Le compte rendu ne mesure pas une réduction d’attaques attribuable à Bais ou à A2B.

Ce que le texte confirme est plus précis. La présentation signalait que certains réseaux d’origine apparaissaient de manière répétée dans les données observées et appelait les opérateurs concernés à nettoyer leurs réseaux. L’idée d’hygiène vise ici les pratiques qui empêchent des erreurs ou des abus prévisibles de devenir un problème durable pour les autres. Elle déplace la question de la seule défense de la cible vers la conduite des réseaux qui laissent régulièrement partir du trafic nuisible ou mal configuré.

Cette intervention constitue une contribution personnelle documentée parce qu’un compte rendu daté nomme Bais, décrit le sujet et rapporte le conseil adressé aux opérateurs. Elle ne prouve pas qu’il a créé les concepts de sécurité du routage, ni qu’il a résolu le problème. Sa valeur tient au lien établi entre données récurrentes et responsabilité opérationnelle. Là encore, le dossier est un cas de jugement appliqué : observer des motifs, distinguer les réseaux en fonction de leur comportement et demander une correction à ceux qui peuvent agir sur la source.

MANRS et la responsabilité de l’opérateur

Le compte rendu de l’Internet Society relie l’intervention à MANRS, pour Mutually Agreed Norms for Routing Security, un ensemble de normes mutuellement convenues pour améliorer la sécurité du routage. Pour un lecteur non spécialiste, l’intérêt de MANRS est de transformer une attente diffuse — « les réseaux devraient être plus sûrs » — en pratiques que les opérateurs peuvent discuter et appliquer. Le texte utilisé ici ne permet pas d’attribuer à Bais l’invention de MANRS, ni de conclure que tous les réseaux mentionnés ont changé leur conduite.

Le point opérationnel est celui de la responsabilité au bord de chaque réseau. Internet repose sur des décisions distribuées : aucun opérateur ne contrôle tous les chemins, mais chacun contrôle une partie de ses configurations, de ses annonces et de son trafic sortant. Lorsqu’un même réseau apparaît régulièrement comme origine d’un problème, l’information peut soutenir une demande de correction plus ciblée qu’une accusation générale. Cette approche exige toutefois une méthode équitable, car les réseaux n’ont pas tous la même taille, le même volume ou le même rôle.

Le registre d’une ressource ou le nom d’un contact ne suffit pas à prouver une contribution, une faute ou une qualité opérationnelle. Les enregistrements servent à identifier et à relier des ressources ; la réalité du réseau apparaît dans le code en fonctionnement, les annonces, les incidents et les réponses observées. C’est pourquoi l’analyse de Bais se fonde ici sur deux actions documentées — une décision de production et une intervention technique nommée — plutôt que sur sa seule présence dans un annuaire. La responsabilité devient crédible lorsqu’elle se rattache à un comportement mesurable et à une capacité d’action clairement située.

La méthode décrite par AMS-IX

Un article d’AMS-IX apporte un éclairage supplémentaire sur la méthode d’A2B. La date de publication n’était pas disponible dans l’extrait retenu ; il ne faut donc pas lui en attribuer une. Le texte décrit l’analyse de données agrégées sur les mauvaises configurations de réseaux et l’emploi d’une notation ajustée à la taille. Il indique que cette évaluation pouvait entrer dans les décisions de peering et dans la manière de traiter le trafic. Cette source corrobore une pratique d’opérateur, mais elle ne démontre pas un effet généralisé sur tout Internet.

L’ajustement à la taille répond à un problème simple. Un grand réseau peut produire davantage d’incidents en nombre absolu simplement parce qu’il transporte plus de trafic ou compte plus de systèmes. Comparer seulement les totaux risquerait donc de confondre volume et qualité. Une mesure relative peut offrir une lecture plus équilibrée, à condition que les données, la période et la formule soient assez claires pour être discutées. Les sources retenues n’exposent pas ici tous ces détails ; le principe peut être expliqué, mais la robustesse statistique de la notation ne peut pas être certifiée.

La méthode rend également visible le lien entre preuve et décision commerciale ou technique. Le peering est une relation dans laquelle deux réseaux échangent directement du trafic selon des conditions convenues. Le transit est un service par lequel un réseau paie généralement un autre réseau pour atteindre une partie plus large d’Internet. Une évaluation d’hygiène peut influencer le niveau de confiance accordé à un voisin, l’ouverture d’une relation ou le traitement prudent de certains flux.

Elle ne donne pas à un opérateur un pouvoir souverain sur les ressources de l’autre ; elle informe un choix local dont il doit pouvoir expliquer les critères et les conséquences.

Une relation analytique, pas une chaîne de causalité

Rapprocher les épisodes de 2017 et de 2018 est utile si la limite est explicite. La décision de déployer vMX en production n’est pas présentée par les sources comme la cause de l’intervention de Bais à RIPE 76. Aucun document retenu n’établit que la convergence de trois à quatre secondes a réduit les attaques DDoS, modifié le comportement des réseaux sources ou produit un résultat à l’échelle de l’écosystème. L’analyse ne doit pas transformer une succession chronologique en causalité.

Le lien se trouve dans la discipline de l’opérateur. Dans le premier cas, une équipe cherche à savoir comment son propre réseau réagira à un changement de chemin. Dans le second, un opérateur utilise des observations agrégées pour demander à d’autres réseaux de corriger des comportements récurrents et pour éclairer certaines relations d’interconnexion. Les deux démarches partent de la réalité en fonctionnement plutôt que d’un simple statut administratif. Elles transforment une préoccupation générale — continuité ou sécurité — en décision située, mesurable et révisable.

Cette lecture conserve aussi la bonne échelle d’attribution. Bais est directement relié à la priorité de convergence, à la décision prise avec l’équipe et à la présentation de RIPE 76. Les résultats de réseau sont ceux qu’un document de fournisseur rapporte au sujet d’A2B. La méthode de notation est décrite comme une pratique d’A2B. Aucun de ces éléments ne justifie de faire de Bais l’auteur unique de tout le système, ni de présenter l’entreprise comme ayant résolu un problème mondial. La précision de l’attribution renforce, plutôt qu’elle ne réduit, la valeur du cas.

Ce que les clients et les acheteurs peuvent demander

Un acheteur ne peut pas reproduire le cas d’A2B à partir d’un seul chiffre. Il peut cependant utiliser le cas pour formuler des questions plus exigeantes. Quel événement déclenche la mesure de convergence : perte d’un lien, retrait d’une route, changement de préférence ou redémarrage d’une session ? La mesure porte-t-elle sur le plan de contrôle, sur le trafic effectivement remis en circulation ou sur les deux ? Quelle table de routes a été utilisée, et comment les chemins IPv6 ont-ils été testés ? Quels résultats seraient considérés comme un échec ?

La même discipline s’applique à l’hygiène. Un opérateur qui classe ses voisins ou ses sources devrait pouvoir expliquer quelles données il observe, comment il normalise les différences de taille, à quelle fréquence il actualise l’évaluation et comment un réseau peut contester ou corriger un résultat. Sans ces précautions, une notation destinée à améliorer les opérations pourrait devenir opaque ou figer un jugement ancien. Les sources montrent l’existence d’une approche ; elles ne fournissent pas tous les paramètres nécessaires pour l’évaluer intégralement.

Pour les équipes d’achat, le meilleur usage de l’article est donc comparatif. Demander plusieurs exemples de reprise, distinguer les résultats de laboratoire des résultats en production, examiner les procédures d’escalade et vérifier que les engagements commerciaux ne dépassent pas les preuves techniques. Pour les dirigeants, l’enjeu est d’aligner les incitations : une équipe ne doit pas être récompensée uniquement pour la rapidité d’un changement si la qualité du routage ou la capacité de retour arrière se dégrade. La continuité est un résultat de système, pas un argument isolé de produit.

Les informations qui manquent encore

Pour évaluer plus profondément le résultat de convergence, il faudrait connaître la topologie de test, le volume exact de routes, les politiques appliquées, la distinction entre IPv4 et IPv6, le type de panne simulé, le nombre d’essais et la façon dont le temps a été mesuré. Il faudrait aussi séparer le retour du plan de contrôle — la sélection des routes — du retour effectif du trafic. Ces informations ne figurent pas dans les éléments retenus et ne doivent pas être inventées.

Pour évaluer la méthode d’hygiène, il faudrait disposer de la période d’observation, de la définition d’une mauvaise configuration, de la formule d’ajustement à la taille, des mécanismes de contestation et des résultats après intervention. L’article d’AMS-IX confirme l’existence d’une approche et son emploi dans des choix de peering ou de trafic. Il ne fournit pas, dans le corpus disponible, une étude d’impact complète. L’absence de date visible dans l’extrait impose également de ne pas l’insérer arbitrairement dans une chronologie précise.

Enfin, toute comparaison actuelle devrait revalider les rôles, les systèmes et les pratiques au moment de la décision. Cet article reste volontairement historique et analytique. Il examine des actes documentés en 2017 et 2018 et les questions durables qu’ils soulèvent. Il ne transforme pas ces actes en déclaration sur une fonction moderne, un produit actuel ou une performance présente.

Divulgation de l’image

Texte alternatif : Scène éditoriale photoréaliste générée par IA montrant, de dos, un opérateur réseau anonyme et entièrement dissimulé.

Légende : Cette scène éditoriale photoréaliste générée par IA n’est ni une photographie d’Erik Bais ni une représentation de ses traits ou de son apparence.

Sources

  1. A2B Internet, page officielle « About us », utilisée pour l’identité historique attribuée, la fondation et le contexte étroit des services de l’opérateur : https://www.a2b-internet.com/about-us/
  2. AMS-IX, « Predicting and mitigating DDoS attacks », utilisé pour la description de la méthode agrégée d’hygiène réseau et son lien borné avec certaines décisions de peering et de trafic : https://www.ams-ix.net/ams/news/predicting-and-mitigating-ddos-attacks
  3. Internet Society, compte rendu daté du 17 mai 2018 sur RIPE 76, utilisé comme confirmation indépendante de la présentation nommée de Bais et des conseils rapportés aux opérateurs : https://www.internetsociety.org/blog/2018/05/ripe-76-sees-strong-focus-on-routing-security/
  4. Juniper Networks, étude de cas A2B datée de mars 2017, utilisée avec sa limite de source fournisseur pour la décision vMX et les résultats de convergence rapportés : https://www.juniper.net/us/en/customers/a2b-case-study.html