Résumé

  • Le projet RIPE 2026-02 ouvre une procédure après 14 jours cumulés sur une liste d’infrastructures approuvée au cours d’une période glissante de 30 jours. Le détenteur dispose ensuite de sept jours ouvrés pour agir ; le rétablissement doit intervenir dans la journée ouvrée suivant la vérification.
  • La clause 3.4 accepte l’isolement vérifié des préfixes. La clause 3.6 ne le reprend pas : elle cite la sortie de la liste ou, en cas de RPKI, la suppression du ROA concerné. Supprimer un ROA modifie la preuve de validation de l’origine ; le retrait BGP et l’isolement du préfixe sont des actions réseau distinctes.

Trois délais, mais deux portes de sortie

Le projet 2026-02 de RIPE NCC met la procédure en dates. Une adresse IP doit figurer au total 14 jours sur une liste d’infrastructures approuvée, dans une fenêtre glissante de 30 jours. Un opérateur réseau touché ou un National CERT dépose une notification authentifiée dans un ticket RIPE NCC Support, accompagnée de télémétrie automatisée et d’horodatages ou de signatures cryptographiques. RIPE NCC envoie alors un avis avec accusé de réception suivi aux contacts juridiques, administratifs et de facturation du détenteur. Celui-ci a sept jours ouvrés. Après vérification de la conformité, RIPE NCC doit lever les restrictions dans un jour ouvré.

La chronologie tient sur une ligne. La difficulté apparaît à la dernière étape : que faut-il montrer pour récupérer l’accès normal au registre ?

L’isolement autorisé disparaît du test de retour

L’article 3.4 offre deux voies de conformité pendant le délai de sept jours. Les préfixes concernés peuvent sortir des listes approuvées ; le détenteur peut aussi prendre une mesure administrative vérifiée pour isoler les préfixes. L’article 3.6 définit ensuite le rétablissement autrement. Les restrictions sont levées lorsque les préfixes ont quitté les listes ou, si le RPKI est concerné, lorsque le ROA approprié a été supprimé.

La deuxième voie de l’article 3.4 s’est évaporée. Un opérateur peut isoler un préfixe à la frontière de son réseau alors que la liste conserve encore l’entrée dans son historique public. L’article 3.4 appelle cela conforme ; l’article 3.6 n’en fait pas un motif de rétablissement. Le délai d’un jour ouvré ne sait donc pas clairement à partir de quel constat partir.

La suppression d’un ROA pose une autre question. Le RFC 9582 décrit le ROA comme un objet signé qui autorise un Autonomous System à annoncer certains préfixes. Le RFC 6811 attribue l’état NotFound à une route lorsqu’aucun VRP validé ne couvre son préfixe. Cet état décrit le dossier de validation. Le retrait BGP et l’isolement du préfixe relèvent d’actions réseau distinctes ; la politique du routeur détermine si un état de validation modifie la sélection ou le transfert des routes.

Le contrôle binaire de l’article 3.6 est rapide à exécuter. Il peut néanmoins conclure autre chose que le remède accepté par l’article 3.4.

La liste fait partie du mécanisme de sanction

Le projet confie au Security Working Group la tenue du registre des listes approuvées. Une liste doit reposer sur une télémétrie automatisée et objective, exclure les plages résidentielles ou dynamiques et conserver un historique publiquement vérifiable. Le cadre est utile ; plusieurs choix pratiques restent à faire : admission d’une liste, contestation d’une erreur, version historique utilisée pour compter les 14 jours et traitement des entrées qui se chevauchent.

L’article 3.5 renvoie aussi les restrictions intermédiaires à l’architecture du registre du détenteur. Il prévoit une réduction de son agilité opérationnelle et un statut public de « non-compliant abuse status » dans la RIPE Database, tout en cherchant à préserver les attributions et les réseaux en aval. La rationale du projet reconnaît que des restrictions précises doivent encore être convenues et décrites dans un document RIPE distinct pour éviter les ambiguïtés et les procédures impraticables. C’est une partie du contrôle, pas une note de bas de page.

La proposition est en phase de discussion. La mise à jour d’octobre de RIPE NCC fixe au 11 novembre la date limite des commentaires ; le programme de RIPE 93 prévoit le débat le 27 octobre dans le Security Working Group. La prochaine version peut harmoniser le test de sortie avant que le chronomètre ne soit prêt à tourner.

Sources