Aller au contenu principal

Sujet

Automatisation de la sécurité

Au sein de la facette Sujet, la veille thématique Automatisation de la sécurité rassemble des articles qui partagent un même sujet, un même signal ou un même thème de suivi. Cette page offre aux lecteurs un parcours plus riche à travers les reportages associés, les preuves issues de sources publiques, les acteurs du marché et les implications pour l’infrastructure, avec suffisamment de contexte pour comprendre pourquoi le sujet compte pour les mouvements d’entreprises, les décisions de gouvernance, l’exposition régionale et le risque opérationnel. Les lecteurs peuvent comparer les signaux récurrents, les organisations concernées, les preuves publiques, le contexte du marché, la continuité de service, les achats, la concurrence, la conformité et les questions de planification stratégique liées au sujet, au lieu de se contenter d’une liste succincte d’articles correspondants. Elle explique ce que couvre le sujet, quels acteurs ou politiques de l’infrastructure sont impliqués, quelles preuves étayent la couverture et pourquoi le sujet peut être important pour les opérateurs, les clients, les investisseurs et les lecteurs de politiques publiques.

Un numéro de RFC ne transforme pas une prédiction en livraison

IETF

Un numéro de RFC ne transforme pas une prédiction en livraison

RFC 9564 est une satire publiée le 1er avril: son protocole FLIP prétend prédire les paquets avant leur arrivée. La plaisanterie révèle pourtant une frontière durable entre document publié, artefact identifié, calcul local et événement réseau.

27 sept. 2026
Un seul bitmap, plusieurs histoires TCP incompatibles

IETF

Un seul bitmap, plusieurs histoires TCP incompatibles

RFC 9565 fiabilise la manière dont IPFIX transporte les bits de contrôle TCP. Il ne donne pas pour autant au collecteur le film d’une connexion: le résultat reste une union d’observations, privée de leur ordre et de leur contexte.

25 sept. 2026
Les paquets sont sortis dans l’ordre. L’histoire complète restait à prouver

IETF

Les paquets sont sortis dans l’ordre. L’histoire complète restait à prouver

RFC 9566 permet au plan de données IP de DetNet de dupliquer des paquets, d’écarter les copies répétées et de remettre le flux en ordre grâce à MPLS sur UDP/IP. La séquence propre obtenue en sortie décrit toutefois la décision locale de PREOF, pas l’indépendance des chemins ni le…

25 sept. 2026
Un jeton accepté ne suffit pas à justifier l’ouverture de la porte

IETF

Un jeton accepté ne suffit pas à justifier l’ouverture de la porte

Avec RFC 9578, la cryptographie atteste qu’un émetteur a produit un objet valide. Elle ne fournit ni le motif d’autorisation, ni la preuve que le service attendu a été rendu.

25 sept. 2026
Le verdict n’a pas changé. La facture de calcul, si : RFC 9618

Dossier

Le verdict n’a pas changé. La facture de calcul, si : RFC 9618

Deux validateurs peuvent accepter exactement les mêmes chaînes X.509 sans présenter le même risque opérationnel. RFC 9618 remplace un arbre de politiques susceptible de croître exponentiellement par un graphe linéaire; il oblige ainsi les responsables à contrôler séparément la…

24 sept. 2026
L’alarme a sonné sans nommer le chemin en panne : RFC 9612

Dossier

L’alarme a sonné sans nommer le chemin en panne : RFC 9612

Une alarme BFD arrive avant toute explication fiable de sa direction. Le trajet aller, le retour demandé, la résolution du FEC inverse et la voie de repli peuvent chacun être responsables. RFC 9612 permet de demander un retour précis et d’en recevoir les refus, mais il ne…

24 sept. 2026
L’échange sûr a échoué. Le repli a rendu le mot de passe testable

IETF

L’échange sûr a échoué. Le repli a rendu le mot de passe testable

RFC 9588 ferme une voie de vérification hors ligne du mot de passe Kerberos; un client qui revient à l’horodatage chiffré après un échec peut la rouvrir.

24 sept. 2026
Le lien désignait la boîte. Il n’autorisait pas le serveur : RFC 2384

Histoire d'Internet

Le lien désignait la boîte. Il n’autorisait pas le serveur : RFC 2384

Une URL donne volontiers l’impression d’être une instruction complète. En 1998, le RFC 2384 a montré le contraire avec une sobriété remarquable: on pouvait condenser l’adresse d’une boîte POP, son port, une identité et un mécanisme d’authentification dans une seule chaîne, sans…

24 sept. 2026
Les sélecteurs concordaient. La capacité, non : RFC 9611

Dossier

Les sélecteurs concordaient. La capacité, non : RFC 9611

Plusieurs Child SA IPsec peuvent protéger exactement les mêmes flux sans fournir la même capacité dans les deux sens. RFC 9611 permet aux pairs de déclarer un groupe logique de SA liées à des ressources locales, mais il ne transforme ni un identifiant opaque en planificateur, ni…

24 sept. 2026
La réponse de la racine faisait autorité, pas sa complétude : RFC 9609

Dossier

La réponse de la racine faisait autorité, pas sa complétude : RFC 9609

Un résolveur peut recevoir une réponse DNS parfaitement conforme et rester privé de certaines adresses nécessaires à son démarrage. RFC 9609 ne traite pas cette situation comme un paradoxe: l’autorité de la réponse, l’authenticité d’un RRset, la présence des adresses et leur…

24 sept. 2026
Le circuit réservait les ressources. Le flux restait sans reprise : RFC 2383

Histoire d'Internet

Le circuit réservait les ressources. Le flux restait sans reprise : RFC 2383

RFC 2383 associait chaque saut ST2+ à un circuit virtuel ATM et permettait au réseau d’en signaler la rupture. Il imposait pourtant `NoRecover` dans CONNECT. Détecter une panne était une capacité du réseau; coordonner plusieurs agents pour reconstruire le bon flux sans…

24 sept. 2026
Le tunnel a gardé le paquet et perdu la congestion : RFC 9599

Dossier

Le tunnel a gardé le paquet et perdu la congestion : RFC 9599

Une migration promet moins de pertes: les nouveaux équipements marquent la congestion au lieu de jeter les paquets. Pourtant, un ancien décapsulateur retire l’en-tête marqué sans transmettre l’indication à IP. Le taux de livraison s’améliore tandis que la boucle de contrôle…

24 sept. 2026
PREPARED a survécu à la panne. La preuve devait survivre aussi : RFC 2372

Histoire d'Internet

PREPARED a survécu à la panne. La preuve devait survivre aussi : RFC 2372

En juillet 1998, le RFC 2372 a placé une règle de garde derrière deux mots du protocole TIP: avant de dire PREPARED, conserver la preuve qui permettra de retrouver cette promesse; avant de dire COMMIT depuis cet état, conserver la décision qu’il faudra peut-être répéter. La…

24 sept. 2026
RFC 9019 : un manifeste de micrologiciel signé ne vaut pas autorisation d’installation

IETF

RFC 9019 : un manifeste de micrologiciel signé ne vaut pas autorisation d’installation

Dans une installation critique, l’image provient bien de son auteur et le manifeste est intact. Pourtant, l’équipement attend encore l’accord de l’opérateur. Ce délai n’est pas une défiance envers la cryptographie: il reconnaît que l’auteur du code et le responsable de son…

24 sept. 2026
Le domaine était canonique. La partie locale ne l’était pas : RFC 9598

Dossier

Le domaine était canonique. La partie locale ne l’était pas : RFC 9598

Une autorité de certification peut inscrire une adresse internationalisée parfaitement conforme dans un certificat, tandis que le service de messagerie a créé une boîte avec une autre suite d’octets visuellement équivalente. RFC 9598 refuse de masquer ce désaccord: le domaine se…

24 sept. 2026
L’enveloppe avait atteint la zone. L’application devait encore la croire : RFC 2370

Histoire d'Internet

L’enveloppe avait atteint la zone. L’application devait encore la croire : RFC 2370

RFC 2370 a prêté le mécanisme de diffusion d’OSPF à des informations dont OSPF ne définissait pas lui-même le sens. Une LSA opaque pouvait respecter sa portée, être acquittée et entrer dans la base d’état des liens sans devenir pour autant une donnée comprise, une route calculée…

24 sept. 2026
Un champ QUIC exporté ne raconte pas toute la connexion

IETF

Un champ QUIC exporté ne raconte pas toute la connexion

La normalisation peut rendre une observation échangeable. Elle ne donne pas à un point de mesure la mémoire de tous les chemins, de tous les identifiants et de toutes les décisions de l’application.

24 sept. 2026
RFC 9608 : aucune voie de révocation ne signifie pas confiance permanente

IETF

RFC 9608 : aucune voie de révocation ne signifie pas confiance permanente

Un certificat ne vit que six heures. L'émettre prend quelques secondes, mais constater un vol de clé, qualifier l'incident et diffuser un état de révocation en prendrait dix. Dans ce cas, supprimer la recherche de révocation peut être rationnel. La question décisive n'est…

24 sept. 2026
La revendication était visible avant d’être fiable : RFC 9597

Dossier

La revendication était visible avant d’être fiable : RFC 9597

RFC 9597 rend certaines revendications CWT accessibles dans l’en-tête COSE avant le déchiffrement ou sans charge utile jointe. Cette avance aide au routage et à la découverte de clés, mais elle ouvre un intervalle où le système agit sur une information qu’il n’a pas encore…

24 sept. 2026
Le lien avait rédigé le message. L’utilisateur devait encore l’envoyer : RFC 2368

Histoire d'Internet

Le lien avait rédigé le message. L’utilisateur devait encore l’envoyer : RFC 2368

En 1998, RFC 2368 a permis à un lien `mailto:` de préparer le destinataire, l’objet, certains en-têtes et un court corps de message. Il n’a pourtant pas transformé le clic en envoi: le client local filtrait la proposition, puis l’utilisateur pouvait la modifier, l’approuver ou…

24 sept. 2026