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.

IETF
Avec DKIM2, « pass » peut signaler une dérogation plutôt qu’un alignement
Lors d’un incident, l’analyste remonte du verdict vers la preuve. Mais si deux chemins — contrôle réussi et contrôle écarté — aboutissent au même `pass`, la piste s’arrête au moment décisif. La révision 01 de DKIM2 Sender Policy renforce les conditions de la dérogation…

IETF
Une signature valide ne prouve pas ce qui a été montré à l’approbateur
Un système peut valider une signature, reconstruire un écran à l’identique et vérifier l’attestation du terminal tout en restant incapable d’établir ce que la personne a réellement vu. La révision 01 d’une proposition consacrée aux reçus d’autorisation reconnaît désormais cette…
IETF
Le parseur s’est arrêté. L’en-tête n’a pas disparu : RFC 9740
Un compteur nul peut désigner une absence constatée, un type impossible à représenter ou une partie du paquet que l’instrument n’a jamais examinée. RFC 9740 permet de mieux distinguer ces situations. Encore faut-il que cette distinction survive à la fabrication d’une courbe…
IETF
QUIC sous YANG : l’épreuve de la connexion restée ouverte
Une configuration peut être acceptée sans que son effet sur une connexion QUIC déjà établie soit démontré. La révision 08 du projet YANG laisse ce passage à la bibliothèque et à son intégration: la preuve doit donc atteindre l’état réellement utilisé, sans prendre une reconnexion…

IETF
Un datagramme de rappel ne vaut pas autorité de l’équipement
Un routeur administré derrière un pare-feu ou un traducteur d’adresses doit parfois signaler sa présence avant que la plate-forme d’exploitation puisse le joindre. Le dernier projet du groupe NETCONF transpose Call Home à QUIC: l’équipement envoie un datagramme UDP vide, puis le…
Dossier
Le filtre de journaux choisit les questions de demain
Avec RFC 9742, la configuration de syslog devient plus comparable entre équipements. Cette langue commune ne garantit pourtant pas que les éléments nécessaires à une enquête survivront à l’incident.

IETF
Le projet sur la préparation post-quantique cite une implémentation, sans fermer ses cinq lacunes
Une implémentation peut prouver qu’un mécanisme fonctionne dans un périmètre donné. Elle ne transforme pas automatiquement ce périmètre en état de préparation post-quantique. La révision 04 d’un projet Internet individuel ajoute un cas concret d’autorité de certification, mais…

IETF
Un horodatage en chemin rapide n’est pas une mesure authentifiée
Un horodatage peut être récent, précis et techniquement bien placé sans attester celui qui l’a produit. Les projets SPRING consacrés à STAMP sur SRv6 et SR-MPLS proposent justement de faire écrire l’heure de réception dans le chemin rapide, afin de multiplier les sessions et de…

Récits
RIPE NCC fait signer l’ASPA avant de montrer les fournisseurs qu’il observe
Le titulaire d’un AS peut désormais publier une autorisation cryptographique de ses fournisseurs, mais la documentation de RIPE NCC précise que le tableau de bord ne lui indique pas quels fournisseurs sont visibles dans BGP. L’aide utile ne serait pas une liste réputée vraie: ce…

IETF
Un indicateur FRR non activé ne dit pas quelle politique locale a prévalu
Dans un réseau RSVP-TE, l’ingress peut formuler une exigence très précise pour le chemin de secours et recevoir, en retour, un silence d’un seul bit. Ce silence n’établit ni l’absence de protection ni la cause de l’écart. Il signale surtout que la décision a changé de niveau: la…

IETF
Le mode par défaut de COSE HPKE n’authentifie pas l’émetteur
Le déchiffrement a réussi. La clé du destinataire était la bonne, l’objet protégé est cohérent et l’opération HPKE n’a signalé aucune erreur. Cette réussite ne donne pourtant pas toujours le nom de celui qui a envoyé le message, ni le droit qu’il avait de le faire. Dans la…

Récits
Le client d’IA de LACNIC résout un modèle, puis dialogue sans identifiant de résolution
Avec la version 1.6.0 du client Java de PAI, une application peut d’abord consulter l’affectation d’un usage, puis envoyer sa conversation. Elle connaît le fournisseur et le modèle de la réponse, mais ne reçoit pas la preuve que l’affectation consultée est bien celle qui a été…

IETF
Une mise à jour BGP authentifiée n’est pas un registre d’admission de tunnel SD-WAN
Dans un réseau automatisé, le vert se propage plus vite que la preuve. Une session BGP protégée reçoit une annonce valide, le réflecteur la diffuse, puis l’interface résume toute la chaîne par un état rassurant. Pourtant, entre l’identité du pair, son droit à annoncer…

IETF
Une carte de ports modifiable exige une trace de dérogation
Un orchestrateur retient un point de raccordement, suit une référence et aboutit sur un port physique. Ce geste paraît purement technique. Pourtant, dans le projet IVY soumis au dernier appel de l’IETF, cette référence peut provenir d’une découverte automatique ou d’une saisie…

IETF
OCM peut retirer un membre sans renouveler la clé de fichier
Dans un groupe fédéré, le départ d’une personne peut être exact dans l’annuaire cryptographique et incomplet pour le document partagé. Le nouvel epoch MLS exclut bien son nœud. Mais si le serveur expéditeur conserve la clé de fichier, l’ancien serveur ou l’ancien appareil peut…

Histoire d'Internet
RFC 2056 : quand une URL ouvre une interaction Z39.50
En 1996, RFC 2056 a inscrit la recherche et la récupération Z39.50 dans la syntaxe des URL sans effacer l’état de session, les choix du client ni l’autorité locale du serveur.
Dossier
RFC 9747 : une boucle locale ne donne pas mandat sur le service distant
En dispensant le voisin de participer à BFD, l’Echo non affilié simplifie la détection. L’exploitant local hérite toutefois de la définition du test, de son calendrier et de la responsabilité d’en tirer une décision limitée.

IETF
Un résultat CoSERV valide ne prouve pas l’exhaustivité
Une requête parfaitement déterministe produit une réponse signée, liée à cette requête et encore dans sa période de validité. Le contrôle cryptographique réussit. Il reste pourtant impossible d’en déduire que le serveur a exploré un fonds complet ou renvoyé tout ce qui pouvait…

Histoire d'Internet
Le descripteur vide raccourcissait la liaison, pas le contrôle d’accès
Deux échanges pouvaient précéder la première opération NFS utile: découvrir un port RPC, puis demander à MOUNT de convertir un chemin exporté en descripteur. En 1996, le RFC 2054 proposa de commencer par l’hypothèse la plus probable et de réserver les anciens échanges aux cas où…

Histoire d'Internet
Dire « RC5 » ne suffisait pas : la frontière probatoire de la RFC 2040
La RFC 2040 n'a pas inventé RC5 et ne constitue pas un guide de déploiement contemporain. Elle accomplit une tâche plus austère: montrer qu'une famille cryptographique ne devient interopérable qu'une fois son identité complète — paramètres, état CBC et traitement du dernier bloc…
