Résumé

  • L'incident YouTube de 2008 a montré qu'une plateforme peut devenir mondialement inaccessible en raison d'un comportement de routage en dehors de la couche applicative. Les utilisateurs ont vu une panne YouTube; le chemin de contrôle impliquait des annonces BGP, la propagation des routes, l'acceptation en amont et les décisions de filtrage à travers les réseaux.
  • Le problème de responsabilité est le décalage entre contrat et contrôle. Les spectateurs, créateurs et annonceurs comptent sur YouTube, mais le mécanisme de panne immédiat peut résider dans les systèmes autonomes et les politiques de routage qui ne font pas partie du contrat utilisateur-plateforme.
  • L'étude de cas de RIPE Labs et le contexte des collecteurs de routes rendent l'incident précieux car ils fournissent des preuves de ressources réseau plutôt que de simples rapports anecdotiques de panne. La visibilité des routes transforme une panne d'accessibilité en un dossier public reconstructible.
  • Les contrôles ultérieurs de sécurité du routage tels que la validation d'origine RPKI, les actions des opérateurs MANRS et les directives de filtrage BGP doivent être présentés comme un contexte de prévention, et non comme des contrôles qui existaient nécessairement ou étaient largement déployés en 2008.
  • La leçon durable est que les plateformes affectées ont toujours des devoirs de responsabilité même lorsqu'elles ne sont pas à l'origine de la mauvaise route: ingénierie du trafic, communication publique, cartographie des dépendances, communication avec les clients et plaidoyer pour une sécurité de routage plus forte.

Une plateforme peut tomber en dehors de sa propre pile

Le produit YouTube est perçu comme une application: rechercher une vidéo, charger une page, diffuser du contenu, publier, s'abonner, faire de la publicité, partager. Les informations publiques sur le produit YouTube présentent le service à travers des fonctionnalités destinées aux utilisateurs. Une panne d'accessibilité donne l'impression aux utilisateurs ordinaires que la plateforme est hors service. Mais l'événement de 2008 a montré que le chemin de défaillance le plus immédiat peut se situer sous l'application, dans le système de routage Internet.

L'étude de cas de RIPE Labs, YouTube Hijacking: A RIPE NCC RIS case study, reste une source publique centrale car elle utilise des preuves de collecteurs de routes pour montrer ce qui s'est passé en termes BGP. Le Routing Information Service du RIPE NCC explique le contexte de mesure: les collecteurs de routes observent les annonces BGP et rendent le comportement de routage visible pour analyse. La valeur de cette preuve est la responsabilité. Cela aide à passer de la question « YouTube était inaccessible » à « quelles annonces de routes se sont propagées, comment se sont-elles répandues, et qu'est-ce que le filtrage aurait pu changer? »

Le contrat orienté utilisateur n'incluait pas ces détails. Un spectateur n'a pas contracté avec chaque système autonome qui transportait les routes. Un créateur n'a pas approuvé les filtres de routes en amont. Un annonceur n'a pas choisi la politique d'interconnexion qui affectait l'accessibilité. Pourtant, leur expérience dépendait de ces décisions. C'est le décalage de contrôle: la relation avec la plateforme est visible, tandis que le contrôle du routage est distribué.

Ce décalage n'est pas propre à YouTube. Toute plateforme mondiale dépend des systèmes autonomes, du transit, du peering, du DNS, de la distribution de contenu et de la propagation des routes. Les utilisateurs blâment le service qu'ils connaissent parce que c'est celui qu'ils utilisent. Le service peut ou non contrôler le mécanisme de panne. Une analyse de responsabilité mature doit éviter les deux extrêmes: ne pas prétendre que la plateforme contrôlait chaque route en amont, et ne pas prétendre que la plateforme n'a aucun devoir lorsque ses utilisateurs sont coupés.

Les devoirs de la plateforme affectée sont différents de ceux de l'origine de la route fautive. La plateforme peut surveiller l'accessibilité, concevoir des chemins de trafic alternatifs, communiquer l'état, préserver les journaux, coordonner avec les fournisseurs en amont et soutenir les normes de sécurité du routage. Elle peut aussi expliquer aux utilisateurs que l'événement est un problème d'accessibilité plutôt qu'une compromission des données applicatives si c'est le fait établi. Ces devoirs importent car la confiance des utilisateurs est attachée à la plateforme même lorsque le chemin des paquets échoue ailleurs.

(Le reste de l'article continue en français, avec tous les paragraphes traduits de manière analogue.)