Résumé

  • Après un passage d’Invalid à Valid, les réseaux multi-hébergés ont retrouvé l’accès depuis la moitié des points de mesure en neuf minutes en médiane, contre douze pour les réseaux mono-hébergés.
  • Après le passage inverse, la médiane a changé de camp : 42 minutes pour que la moitié des points perde l’accès dans les réseaux multi-hébergés, contre 30 minutes dans les réseaux à un seul fournisseur.

Pour l’équipe d’astreinte, le voyant vert ne déclenche pas la fin du chronomètre : il confirme l’autorisation RPKI, tandis que les sondes attendent encore de voir le préfixe redevenir joignable. La même équipe affronte le compte à rebours inverse quand la route passe à Invalid. Chaque fournisseur récupère et applique le nouvel état à son propre rythme.

Cette mesure a été présentée à RIPE 93 dans une étude sur le délai entre le changement d’état RPKI et la convergence du plan de données. Les chercheurs ont suivi environ 25 000 changements du dépôt RIPE qui modifiaient les données validées, puis isolé près de 1 500 événements simples où un seul changement permettait de suivre le retour ou la perte d’accès. Plus de 300 nœuds CAIDA Ark ont envoyé des traceroutes après chaque changement détecté, pendant une heure.

Le chronomètre ne partait ni de la saisie du ROA ni de sa première lecture par un validateur. Il mesurait le moment où la moitié des points de mesure pouvait de nouveau joindre le préfixe, ou ne le pouvait plus. Une mise à jour dans une base et un résultat visible sur le réseau sont deux événements distincts.

Le multi-homing accélère le retour

Quand une route passait d’Invalid à Valid, les réseaux multi-hébergés atteignaient le seuil de 50 % des points de mesure en neuf minutes en médiane. Les réseaux mono-hébergés mettaient douze minutes. Un fournisseur supplémentaire offrait une deuxième chance qu’un validateur ait déjà récupéré et traité le nouvel objet.

La médiane n’explique pas tout : la distribution des délais gardait aussi une queue lente plus courte pour les réseaux multi-hébergés. Chaque fournisseur utilise son propre logiciel relying-party et son propre cycle de récupération. Deux cycles indépendants augmentent les chances qu’un chemin apprenne tôt que la route est autorisée.

Le réseau ne rend pas lui-même le ROA valide. Le ROA déclare une autorisation d’origine ; le validateur calcule un état à partir des objets publiés. L’écart mesuré apparaît ensuite, quand les fournisseurs et les routeurs intègrent ce nouvel état.

Le même chemin retarde la sortie

À l’envers, le résultat s’inverse. Lorsqu’une route jusque-là valide devient Invalid, les réseaux mono-hébergés atteignent le seuil de perte d’accès en 30 minutes en médiane. Les réseaux multi-hébergés mettent 42 minutes.

Le chemin de secours continue d’assurer sa fonction. Si un fournisseur a déjà actualisé ses données RPKI et change le traitement de la route, un autre peut encore l’annoncer parce que son validateur n’a pas récupéré le nouvel état. Plus il y a de chemins indépendants, plus il existe de chances que l’un d’eux reste visible pendant la transition.

Pour un incident, cela change la lecture du voyant. Un état Invalid n’ordonne pas à tous les réseaux de couper la route. Chacun applique sa politique locale, et les validateurs ne récupèrent pas les données au même instant. BGP choisit ensuite parmi les annonces encore présentes. Le plan de contrôle peut donc afficher un état nouveau tandis que le plan de données transporte toujours du trafic.

L’étude a mesuré des cas à origine unique et exclu les cas couverts par une annonce moins spécifique. Les traceroutes ont duré une heure. La borne publiée décrit ces cas et cette fenêtre, pas un minuteur universel pour chaque route.

Une mise à jour, plusieurs horloges

Entre la modification d’un ROA et son effet sur la portée, il y a une chaîne : publication dans le dépôt, récupération par le validateur, calcul de l’état, transfert vers les routeurs, application de la politique locale et stabilisation du plan de données.

L’équipe a obtenu un signal précoce en surveillant l’origine du dépôt RIPE et en utilisant un validateur optimisé. Selon l’intervenant, ce signal précédait les validateurs publics comparés d’au moins 57 secondes, et de cinq minutes à la médiane. Les chercheurs pouvaient ainsi lancer leurs traceroutes avant une bonne partie du réseau. Cette méthode de mesure ne donne pas à RIPE NCC le contrôle des cycles de tous les validateurs.

Pour un opérateur, « RPKI mis à jour » ne constitue donc pas un seul délai de service. Si un client demande si la correction est effective, l’heure de publication ne répond pas pour tous les fournisseurs. Si une équipe de sécurité s’attend à ce qu’un Invalid arrête immédiatement une route détournée, la médiane de 30 à 42 minutes montre qu’une partie des points de mesure voyait encore le préfixe.

Sources : Résumé et enregistrement de RIPE 93 ; transcription officielle de la plénière ; RFC 6811, validation de l’origine des préfixes BGP.