Résumé

  • Vers 02 h 24 UTC le 6 novembre 2012, Cloudflare a constaté que des services de Google étaient inaccessibles depuis certaines parties de l'Internet. Une route observée vers Google traversait AS4436, PCCW/AS3491, Moratel/AS23947, puis l'origine légitime Google/AS15169 [1].
  • Cloudflare a décrit une interruption limitée d'environ 27 minutes et a estimé que 3 à 5 % de la population connectée avait pu être touchée, avec un effet plus marqué autour de Hong Kong. Il s'agit de l'estimation de cet observateur, pas d'un recensement indépendant [1].
  • Le RFC 7908 cite ensuite l'incident Moratel-PCCW comme exemple d'une fuite de type 4 : des préfixes appris d'un pair sont exportés vers un fournisseur de transit, au-delà de la portée prévue [2].
  • Cloudflare a d'abord jugé probable une annonce erronée. Une mise à jour de son article rapporte la position de Moratel : une défaillance matérielle inattendue aurait provoqué la situation anormale, sans intention malveillante [1]. Les données publiques ne permettent pas de trancher le mécanisme interne exact.
  • La responsabilité opérationnelle se trouve des deux côtés de la session. Moratel devait empêcher la sortie de routes non autorisées; PCCW devait distinguer les routes client acceptables de routes apprises dans une autre relation avant de les propager.

Ce que l'observation permet d'établir

Cloudflare indique que ses équipes ont remarqué la panne vers 02 h 24 UTC. Les premiers symptômes ressemblaient à un problème DNS, puisque même l'adresse 8.8.8.8 n'était plus joignable depuis son réseau. Le diagnostic s'est déplacé vers la couche de routage lorsque le chemin a montré une adresse de Moratel en Indonésie, détour inattendu pour un trafic partant de Californie vers Google [1].

Le chemin publié pour un préfixe de Google contenait AS4436, AS3491, AS23947 et AS15169. La dernière valeur restait celle de l'origine Google. L'anomalie n'était donc pas l'usurpation simple d'une origine par un réseau inconnu. Le problème se trouvait au milieu du chemin : une route plausible avait franchi une frontière commerciale et opérationnelle qui ne devait pas la transporter.

Cloudflare dit avoir contacté un ingénieur chez Moratel. L'annonce incorrecte a été corrigée vers 02 h 50 UTC et les routes sont revenues à la normale environ trois minutes plus tard [1]. Une interruption courte ne devient pas négligeable pour autant. Les utilisateurs voyaient un service inaccessible alors que les serveurs de destination pouvaient continuer de fonctionner. Les équipes applicatives, DNS et support pouvaient chercher la panne dans leur propre environnement alors que la cause visible se trouvait dans le plan de contrôle interdomaines.

Il faut conserver les limites de cette observation. Cloudflare disposait d'un point de vue opérationnel précieux et a publié le chemin qu'il voyait. Il n'observait pas chaque utilisateur ni chaque opérateur. Son estimation de 3 à 5 % ne doit pas être transformée en mesure universelle. De même, l'expression initiale d'une erreur de manipulation était une appréciation. La mise à jour attribue à Moratel une défaillance matérielle inattendue.

Sans journaux de routeur, alarmes matérielles, historique de configuration et chronologie interne, le public ne peut pas départager matériel, logiciel, configuration, basculement ou interaction entre ces éléments.

Pourquoi il s'agit d'une fuite de type 4

BGP permet à des systèmes autonomes d'échanger des informations de joignabilité. Chaque système autonome applique sa propre politique et porte un numéro ASN. Une annonce contient un préfixe, un chemin d'AS et d'autres attributs. Le routeur ne vérifie pas seulement qu'un chemin existe : il choisit de l'accepter, de le préférer et éventuellement de le réannoncer.

Ces choix traduisent des relations. Un client achète normalement l'accès à l'Internet auprès d'un fournisseur. Deux pairs échangent en principe les routes de leurs clients respectifs, sans offrir automatiquement un transit complet. Une route peut donc être valide lorsqu'elle est reçue sur une session et interdite lorsqu'elle est exportée vers une autre.

Le RFC 7908 définit une fuite comme la propagation d'une annonce au-delà de sa portée prévue. Son type 4 correspond à des routes apprises d'un pair latéral puis annoncées au fournisseur de transit du réseau fautif. Le document nomme explicitement la fuite Moratel-PCCW de préfixes Google parmi ses exemples [2].

Cette classification déplace le contrôle. La question n'est pas seulement de savoir si AS15169 avait le droit d'originer les préfixes. Il faut savoir si AS23947 pouvait exporter ce chemin vers AS3491 et si AS3491 devait l'accepter comme route client. Une validation d'origine peut confirmer le dernier ASN sans détecter une transition pair-client ou client-fournisseur contraire à la relation prévue.

Le devoir de preuve du côté export

L'opérateur qui exporte doit pouvoir reconstruire la session concernée, son rôle, les routes reçues, les routes retenues et les routes effectivement annoncées au voisin. Le dossier doit séparer les préfixes propres, les routes client autorisées, les routes apprises d'un pair et les routes reçues d'un fournisseur.

Si une panne matérielle a déclenché l'événement, une clôture utile doit expliquer l'effet de cette panne sur la politique. Un redémarrage a-t-il chargé une configuration incomplète? Un mécanisme de secours a-t-il utilisé une politique plus large? Une table temporaire a-t-elle été annoncée pendant la convergence? Une règle de filtrage a-t-elle été contournée? Dire « panne matérielle » décrit un déclencheur possible, mais pas la raison pour laquelle l'export a pu échouer en mode ouvert.

Les preuves doivent réunir l'intention et l'exécution. Un diff de configuration est utile, mais insuffisant. Il faut aussi l'état des routes reçues et annoncées, les communautés pertinentes, les horodatages, les événements du matériel et la séquence de retrait. C'est cette réconciliation qui montre si la réparation a fermé le passage ou seulement supprimé l'annonce visible.

Le devoir de preuve du côté transit

Un fournisseur en amont ne se contente pas de transporter ce qu'un client lui envoie. Il définit les annonces qu'il accepte, la manière dont il les classe et les destinations vers lesquelles il les propage. Cloudflare a décrit PCCW comme le fournisseur amont qui avait accepté les routes envoyées par Moratel [1]. Les données RDAP actuelles relient AS3491 à PCCWG-APAC-HK et à PCCW Global (HK) Limited [6]. Elles établissent une continuité d'identité actuelle, pas la totalité du contrat de 2012.

PCCW devait disposer d'un dossier d'autorisation : préfixes ou cône client attendu, origines permises, motifs de chemin acceptables, limites de volume, alertes et procédure d'exception. Si un client peut légitimement transporter des routes de tiers, un simple filtre sur l'origine devient difficile. Cette difficulté augmente le besoin d'une relation explicite et d'une réconciliation fréquente; elle n'annule pas le devoir de filtrage.

Une grande dorsale amplifie le risque. Une erreur locale devient visible à distance lorsque l'amont la sélectionne et la réannonce. La réponse « le client nous l'a envoyé » ne suffit donc pas. Le produit du fournisseur est précisément une propagation contrôlée. Son dossier doit montrer à quel moment l'annonce anormale a été reçue, acceptée, sélectionnée et distribuée.

Registre, chemin réel et doctrine Heng.lu

Le RDAP actuel d'APNIC identifie AS23947 comme MORATELINDONAP-AS-ID et l'associe à PT. Mora Telematika Indonesia [5]. Le RDAP d'AS3491 identifie PCCWG-APAC-HK et PCCW Global (HK) Limited [6]. Ces registres rendent l'identité et le contact des ressources plus durables.

Ils ne révèlent pas la route exécutée à 02 h 24 UTC. Un registre peut dire qui exploite un ASN. Il ne montre ni la politique active, ni les routes annoncées sur une session, ni la décision d'import d'un voisin. C'est la surface Heng.lu de cet article : le registre est un grand livre et un mécanisme de continuité, pas un substitut au réseau en fonctionnement. La légitimité opérationnelle se vérifie en rapprochant le titulaire, l'intention de relation et l'état effectivement exécuté.

La réponse historique de RIPEstat pour 8.8.8.0/24 conserve une visibilité de l'origine AS15169 pendant la journée demandée [4]. Sa granularité de huit heures ne permet pas de prouver la fuite de quelques dizaines de minutes. Elle n'est donc pas utilisée comme preuve du chemin anormal. Pour ce chemin, le dossier repose sur l'observation contemporaine de Cloudflare et sur la classification ultérieure du RFC 7908.

Des contrôles qui doivent échouer en mode fermé

Le premier contrôle est une politique explicite sur chaque session externe. L'absence d'une règle d'import ou d'export ne doit pas ouvrir la table entière. Une route apprise d'un pair ne doit pas devenir exportable vers un fournisseur par défaut.

Le deuxième est un grand livre de provisionnement relié à la configuration. Il doit indiquer l'ASN voisin, le rôle, les préfixes ou origines autorisés, les limites de routes, le propriétaire du changement et l'échéance d'une exception. L'automatisation doit compiler cette intention et vérifier ce qui est réellement déployé.

Le troisième est la surveillance des routes annoncées. Une hausse soudaine du nombre de préfixes, une origine tierce inattendue ou un chemin incompatible avec le rôle de la session doit déclencher une alerte et, pour les cas les plus risqués, un rejet automatique.

Le quatrième est la signalisation de la relation. Le RFC 9234, publié bien après 2012, définit les BGP Roles et l'attribut Only-to-Customer. Ces outils rendent certaines limites plus lisibles par les machines et peuvent aider à reconnaître des propagations contraires au rôle annoncé [3]. Ils servent ici de contexte de contrôle; rien ne prouve leur déploiement par Moratel ou PCCW au moment de l'incident.

Le cinquième est l'observation indépendante. Les collecteurs externes peuvent montrer qu'une route a franchi la frontière alors que chaque opérateur pense que sa configuration locale est correcte. Ces données doivent être corrélées aux états Adj-RIB-In et Adj-RIB-Out internes, pas les remplacer.

Ce qu'une clôture publique devrait contenir

Une clôture utile commencerait par une chronologie en UTC : premier symptôme, première alerte interne, première route anormale confirmée, contact entre opérateurs, arrêt de l'export, retrait observé et retour stable. Elle distinguerait l'heure de l'observation de celle du diagnostic.

Elle décrirait ensuite la classe de route et de politique sans publier des secrets de réseau. Le public a besoin de savoir si une route apprise d'un pair a été exportée vers un transit, si une règle était absente ou contournée, et si le filtre client de l'amont acceptait un ensemble trop large.

Enfin, elle prouverait le changement durable : intention approuvée, politique générée, empreinte de la configuration déployée, test négatif rejetant une route équivalente, seuil d'alerte, propriétaire du retour arrière et observation externe du retrait. Le rétablissement du service est une étape. La preuve que le même chemin ne repassera pas est la clôture.

Sources

  1. https://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about/
  2. https://www.rfc-editor.org/rfc/rfc7908.txt
  3. https://www.rfc-editor.org/rfc/rfc9234.txt
  4. https://stat.ripe.net/data/routing-history/data.json?resource=8.8.8.0/24&starttime=2012-11-06T00:00:00&endtime=2012-11-07T00:00:00
  5. https://rdap.apnic.net/autnum/23947
  6. https://rdap.arin.net/registry/autnum/3491