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.

Histoire d'Internet
DHCP choisissait le domaine Kerberos avant que Kerberos puisse le juger : RFC 3495
Un certificat parfaitement valable pouvait arriver devant le mauvais KDC. La cryptographie jugeait alors le demandeur, mais pas la décision DHCP qui l’avait conduit jusque-là.

IETF
Le domaine a changé la marque. À la sortie, il devait rendre l’identité du service : RFC 5127
La RFC 5127 autorise un réseau à réunir plusieurs classes Diffserv dans un même traitement, voire à employer un marquage local. Elle lui refuse cependant le droit de perdre l’identité reçue: l’agrégation est une décision de transmission locale, non un transfert de propriété sur…

IETF
Le certificat portait le préfixe, pas l’identité de l’AS : RFC 9582
Dans un ROA, l’absence de l’extension de ressources AS n’est pas une lacune. Le RFC 9582 l’exige, car le certificat et la charge signée n’exercent pas la même autorité.

IETF
Le retour était chiffrable ; le choix du profil restait attaquable : la frontière de la RFC 5124
La RFC 5124 associe le retour RTCP rapide d’AVPF à la protection SRTP/SRTCP de SAVP. Mais la sécurité du paquet ne remonte pas dans le temps pour protéger une négociation vulnérable, et les octets ajoutés consomment le budget qui détermine si le retour reste utile.

IETF
Le défi est arrivé. Le client ne devait aucun jeton : RFC 9577
Un serveur peut formuler une demande `PrivateToken` parfaitement conforme sans acquérir le droit d’interpréter le silence. Le RFC 9577 organise précisément cet espace entre invitation, réponse et décision.

IETF
Même station de base, liens IPv6 différents : ce que RFC 5121 refuse de confondre
Deux abonnés peuvent partager la même technologie radio, le même site et la même station de base sans appartenir au même lien IPv6. RFC 5121 oblige à regarder au-delà de la proximité physique: le lien utile est celui qui relie une station mobile à son routeur d’accès, avec ses…

IETF
Le réplicateur s’annonçait prêt. La feuille attendait encore trois secondes : RFC 9574
Dans RFC 9574, le délai par défaut n’est pas un détail de confort. Il révèle l’intervalle où le plan de contrôle connaît le réplicateur alors que le plan de transfert peut encore ignorer la feuille.

IETF
La page montrait deux lignes. Le paquet n’en contenait qu’une : RFC 5118
Un essai SIP peut échouer avant même d’atteindre le parseur: au moment où un opérateur copie une ligne repliée depuis un RFC et fabrique, sans le voir, d’autres octets. RFC 5118 a donc livré à la fois une convention de reconstruction et une archive exacte; le rendu lisible…

IETF
Deux chemins ont accepté la même identité. Ils n’offraient ni le même service ni le même prix : RFC 5113
Une authentification réussie peut cacher une mauvaise sélection. Le RFC 5113 montre pourquoi deux chemins d’itinérance capables d’accepter le même identifiant ne produisent pas nécessairement la même route de données, les mêmes services ou la même facture.

IETF
Le même label était partout. Son sens ne l’était pas : RFC 9573
RFC 9573 réduit fortement l’état MPLS des MVPN et EVPN. Cette économie suppose toutefois qu’une convention externe soit déjà vraie sur chaque routeur concerné.

IETF
Le lot portait une étiquette. Sa fenêtre de comptage restait ouverte : RFC 9571
Une étiquette peut réunir les paquets d’une même expérience sans annoncer que le dernier d’entre eux a déjà quitté les files, les cœurs et les pipelines du réseau observé.

IETF
Le numéro d’algorithme existe. Le chemin de validation, pas forcément : RFC 9558
Un registre peut attribuer un numéro à une suite cryptographique avec une précision parfaite. Il ne peut pas obliger le résolveur qui se trouve devant l’utilisateur à savoir l’employer.

IETF
Le préfixe protégé a été reconstruit. Pas le paquet média entier : RFC 5109
Le tableau de bord annonçait « récupération FEC réussie ». En réalité, le niveau 0 avait restitué l’en-tête RTP et le début critique du paquet, tandis que la fin, moins protégée, restait inconnue. RFC 5109 permet de décrire exactement cet entre-deux. C’est l’exploitation qui…

IETF
La charge est partie en périphérie. Le pouvoir de décider, non : RFC 9556
Un calculateur installé près d’une machine peut continuer à travailler quand le nuage devient inaccessible. Cette proximité ne dit pourtant ni qui l’a autorisé à lire les données, ni qui assume la commande envoyée au monde physique.

IETF
L’identifiant du serveur a été remplacé. Il n’identifiait pas le serveur
Le bail se renouvelait tant que le relais restait joignable. Dès que ce chemin a disparu, l’adresse nommée « identifiant du serveur » n’a conduit à aucun serveur. Le RFC 5107 explique pourquoi: cette adresse peut être choisie par le relais pour ramener les renouvellements dans…

IETF
La clé reste au domicile, mais la publication part chez un tiers : RFC 9526
Externaliser le DNS d'un réseau résidentiel ne revient pas à céder une autorité unique. Le RFC 9526 laisse au domicile la fabrication et la signature de la zone, puis confie à d'autres acteurs sa diffusion, son rattachement au parent et sa visibilité publique.

IETF
Le Fast-Reconnect-ID a retrouvé un contexte. Il n’a pas authentifié le pair
Le serveur vient d’émettre un nouveau pseudonyme, mais le pair ne l’a peut-être jamais enregistré. Le RFC 5106 protège le dernier identifiant confirmé et oblige l’échange chiffré à réussir avant de faire du nouveau contexte une réalité partagée.

IETF
Le Replication-SID a trouvé un état, pas la preuve d’un arbre : RFC 9524
Le contrôleur avait reçu un accusé de réussite de chaque routeur. Pourtant, un paquet revenait vers un nœud de réplication déjà traversé et chaque passage produisait de nouvelles copies. Tous les états locaux étaient exploitables; leur assemblage ne formait pas un arbre. RFC 9524…

IETF
La signature était valide. La délégation n’était pas encore autorisée
Un jeton ENUM peut traverser sans altération un chemin non fiable, porter une signature XML correcte et rester inutilisable pour la demande présentée. Le RFC 5105 oblige le registre à distinguer l’authenticité du document de l’autorité de déléguer.

IETF
Le numéro de lien était dans la sonde ; le port devait encore le confirmer — RFC 9533
Le rapport annonçait 2,1 millisecondes pour un agrégat de quatre liaisons. Ce chiffre ne disait pas si les quatre avaient été testées, ni laquelle avait transporté la requête et le retour. RFC 9533 construit précisément la preuve qui manquait entre l'interface logique et ses…
