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.

Dossier
Le jeu de paramètres se vérifie. Pas l’état de signature : RFC 9858
RFC 9858 enrichit HSS/LMS de nouveaux choix de hachage et de niveau de sécurité. Il ne résout pas la difficulté propre aux signatures avec état: démontrer qu’une feuille à usage unique n’a été consommée qu’une seule fois, y compris après une panne, une restauration ou deux…

IETF
Le futur RFC 10040 peut signer une Map-Reply, pas vérifier le lieu
Une réponse cartographique peut être intacte, attribuable et réservée aux bons destinataires, sans que personne ait encore démontré la justesse physique de son point. L’arrivée prochaine du RFC 10040 donne au LISP un meilleur contenant pour la géolocalisation. Elle ne transforme…

Récits
Un scan a repéré 4 611 routeurs BGP exposés dans la région APNIC. Il n’en connaît pas la raison
À APNIC 62, une équipe de recherche a donné une mesure régionale à un problème discret du plan de contrôle: 4 611 routeurs rattachés à 1 343 systèmes autonomes ont répondu à un échange BGP OPEN non sollicité lors d’un scan IPv4 en février. Le signal est plus précis qu’un simple…

IETF
D-PATH ne bloque les boucles que si les passerelles s’accordent sur le domaine
Deux passerelles peuvent exécuter correctement la même RFC et pourtant ne pas protéger le même périmètre. Avec la RFC 10039, tout dépend d’une décision prise avant l’annonce BGP: quelles interfaces et quelles VRF appartiennent au même domaine, et quel identifiant commun en fera…

Créateurs
Cricket Liu et le long travail pour rendre le DNS exploitable
Le parcours de Cricket Liu suit l’évolution du DNS, d’un service spécialisé administré par quelques opérateurs à un plan de contrôle d’entreprise et, de plus en plus, à un capteur de sécurité. Son importance tient moins à l’invention de protocoles qu’à l’explication du…

IETF
DNSOP adopte le problème multi-algorithme, pas l’étiquette « UNIVERSAL »
Le 1er septembre, les présidents de DNSOP ont fermé un appel en laissant volontairement une porte ouverte. Le groupe prendra le document en charge, ont-ils constaté, mais la complexité du mécanisme reste à travailler. Cette réserve n’est pas une note de bas de page: elle définit…

IETF
La RFC 7506 est historique ; Router Alert 69 peut encore circuler
Dans un registre, la retraite est nette: RFC 7506 est classée historique et la valeur 69 porte la mention « DEPRECATED ». Sur un réseau, elle l’est beaucoup moins. Un ancien modèle de configuration peut encore émettre l’option, et un récepteur peut toujours la reconnaître. La…

Histoire d'Internet
La proposition ajoutait un en-tête. Elle refusait de réécrire l’adresse : RFC 1955
Enfouir un paquet sous un second paquet peut donner l’impression qu’on a évité de choisir. RFC 1955 faisait au contraire un choix très précis: conserver intactes les adresses IPv4 vues par les hôtes, mais confier aux routeurs de bordure et au DNS une nouvelle géographie de…

Histoire d'Internet
Quand le canal remplaçait l’en-tête : la frontière ATM de RFC 1954
Sur un lien ATM d'Ipsilon, l'étiquette d'un flux ne s'ajoutait pas simplement à un paquet IPv4. Elle choisissait un VPI/VCI et pouvait retirer du paquet jusqu'à seize octets d'informations répétées. RFC 1954 montre ainsi où l'optimisation devient dépendance d'état — et où doit…

IETF
Une association NAT64 n’est pas une politique de filtrage
Un même couple IPv4 public peut réapparaître à chaque essai et pourtant ne rien dire des sources autorisées à l’emprunter en sens retour. Dans un traducteur NAT64 avec état, la stabilité de l’association et la décision de filtrage sont deux faits distincts — donc deux…

Histoire d'Internet
Le raccourci venait du commutateur. Le routeur gardait le droit de dire non : RFC 1953
Dans RFC 1953, la voie rapide n’était pas une nouvelle autorité sur le paquet. Le voisin aval choisissait une étiquette dans son espace local et proposait au voisin amont de l’attacher à un flux IP défini. Celui-ci pouvait ne rien faire. Même acceptée, l’association expirait; en…

IETF
Un même opérateur ne crée pas un domaine de confiance SRv6 unique
Après une fusion, deux réseaux apparaissent sous le même nom dans l’organigramme. Un filtre placé entre eux semble alors redondant: pourquoi traiter comme externe un trafic qui appartient désormais au même groupe ? La réponse de sécurité ne se trouve pas dans l’acte de propriété…

IETF
IPv6 regroupe trois mesures derrière un seul booléen
Un opérateur peut vouloir automatiser la réponse à une adresse IPv6 dupliquée sans pour autant déléguer une sanction opaque. C’est pourtant la frontière que frôle `auto-resolve`, une feuille du modèle YANG consacré à Neighbor Discovery actuellement soumis au dernier appel de…

Histoire d'Internet
Le fichier était fini, puis il a continué : la frontière des membres de gzip
Un fichier gzip peut être complet sans être définitif. Après sa bande de fin, un second membre peut commencer, puis un troisième. Le décompresseur restitue leurs contenus dans l’ordre alors que les octets antérieurs demeurent intacts. RFC 1952 a ainsi placé l’extension non dans…

Tendances mondiales des services cloud
Chez Cloudflare, l'ancienne API post-quantique subsiste sans modifier le réglage
Le choix automatique et la liste des algorithmes autorisés relèvent désormais de commandes distinctes. Les procédures de retour arrière doivent suivre cette séparation.

IETF
Un incident « cleared » ne prouve pas quelle commande l’a clos
Dans le système de tickets, l’incident reste « en cours ». Dans le contrôleur réseau, il est déjà `cleared`. Entre les deux, une commande de résolution a bien été acceptée, mais personne ne peut relier avec certitude sa requête à la notification arrivée plus tard. Les trois…

Histoire d'Internet
Le centre de clés s’est dissous dans l’arbre, pas son autorité : RFC 1949
Un goulot d’étranglement peut disparaître sans que le pouvoir qu’il concentrait disparaisse avec lui. RFC 1949 proposait de confier aux nœuds déjà authentifiés d’un arbre multicast la capacité de distribuer les secrets du groupe aux arrivants suivants. Le calcul devenait plus…

IETF
Un catalogue de capacités ne décide pas d’un abonnement
Un orchestrateur interroge un équipement et reçoit une réponse rassurante: HTTPS est pris en charge, tout comme XML, JSON, TLS 1.2 et TLS 1.3. Cette description évite de négocier à l’aveugle. Mais elle ne choisit aucune combinaison, n’autorise aucun destinataire et ne crée aucun…

Histoire d'Internet
Le mot de passe n’était juste qu’une fois : RFC 1938 et l’état que le succès détruit
Un mot de passe réutilisable prétend décrire une vérité stable. RFC 1938 a proposé une vérité plus étrange: la bonne réponse cesse de l’être dès qu’elle est acceptée. Le serveur remplace alors son vérificateur par la réponse reçue. Cette mutation, plus que le simple calcul…

Récits
RIPE Database 1.124.1 a corrigé le choix du certificat. Le constat « aucune exploitation » doit être délimité
RIPE NCC n’avait aucune raison d’attendre une quinzaine de test ordinaire pour fermer une faille d’authentification signalée. Une autre obligation commence après le correctif: préciser quelles périodes, quelles requêtes et quels historiques ont été examinés avant d’affirmer…
