Sujet
Preuves fondées sur les ressources réseau
Au sein de la facette Sujet, la veille thématique Preuves fondées sur les ressources réseau 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
La clé changée sans rompre la connexion : le signal de relève de TCP-AO
Pour une session de routage durable, remplacer une clé d'authentification pouvait signifier choisir entre un secret vieillissant et une coupure. TCP-AO a rendu la relève visible dans chaque sens grâce à KeyID et RNextKeyID, sans confier à TCP la distribution des clés.

IETF
L’IETF approuve l’inondation dynamique à titre expérimental. « Acceptable » reste à mesurer
Réduire les annonces qui circulent sur un réseau très maillé paraît être un gain évident. La décision de l’IETF ne le transforme pourtant pas en vérité opérationnelle: elle ouvre une expérience dont la valeur dépendra de seuils annoncés avant l’essai, de plusieurs mises en œuvre…

Dossier
La liste a gardé son ordre. Une partie de la politique s’est perdue : RFC 9825
Lors d’un changement d’aire, une équipe a voulu « préserver » les étiquettes de quatre routes composantes sur leur préfixe agrégé. Le routeur, lui, ne les avait pas oubliées: il appliquait la règle qui déconseille de transférer les étiquettes des composants vers le résumé. En…

IETF
Le label est arrivé, mais sur le bon chemin ? RFC 9884 et la validation des PSID
Un label MPLS peut atteindre le bon egress et y être retiré, tout en étant associé au mauvais SR Policy, à la mauvaise candidate path ou à la mauvaise segment list. RFC 9884 transforme ce piège de portée et de granularité en vérification LSP Ping explicite.

Récits
L’étude 2025 de LACNIC ne précise pas la période des mesures
Un millésime classe un rapport dans une bibliothèque. Il ne date pas nécessairement les paquets qui ont produit ses graphiques. L’étude régionale de LACNIC formule des constats utiles sur les chemins Internet, mais ne donne pas au lecteur la période d’observation qui leur…

Dossier
Le jeton autorisait l’outil, pas les arguments choisis par l’agent
Un agent peut présenter le bon jeton, la bonne clé et le bon périmètre OAuth, puis virer l’argent vers le mauvais compte. La faute ne se trouve alors ni dans l’authentification ni forcément dans la granularité du droit. Elle se situe entre le moment où le modèle produit l’acte…

Histoire d'Internet
« Si les réponses sont nombreuses » : RFC 1501 avant le mandat
Le passage décisif de RFC 1501 était au conditionnel. Une réponse assez forte devait précéder la démarche auprès d’IBM, laquelle devait elle-même précéder la formation d’une organisation. Le numéro RFC rendait cette promesse publique; il ne pouvait accomplir les étapes annoncées.

Dossier
L’en-tête disait NOERROR ; le corps signé prouvait que le nom n’existait pas : RFC 9824
Le cache avait conservé la preuve DNSSEC, sa signature et sa durée de vie. Il avait oublié un seul bit: la capacité CO annoncée par l’amont. Au moment de répondre, le résolveur savait encore que le nom n’existait pas, mais ne savait plus s’il pouvait présenter cette conclusion…

Dossier
Le service a changé de relais. Son ancien enregistrement a gagné
Dans un réseau local, l’ancienneté protège utilement un nom contre un nouvel arrivant. Dans une architecture à plusieurs mandataires, elle peut au contraire protéger une copie périmée contre le propriétaire légitime du service. Le projet de nouveau mandat de DNSSD place cette…

Histoire d'Internet
Le lecteur pouvait archiver l’objet sans pouvoir le comprendre : RFC 1496
Dans un environnement X.400(84), recevoir une pièce MIME inconnue pouvait aboutir à un geste très modeste: l’enregistrer dans un fichier, puis chercher un autre programme capable de l’ouvrir. RFC 1496 considérait cette issue comme préférable à la destruction du message. Il ne la…

Récits
Les objets IRR d’ARIN gardent leur canal d’origine
Dans ARIN Online, un objet hérité d’IRR-email peut être supprimé mais pas corrigé. Cette limite protège peut-être une provenance que le formulaire ne sait pas restituer. Elle transforme néanmoins une modification ordinaire en rupture de filiation dès que l’utilisateur supprime…

Dossier
La méthode EAP a réussi ; la session protégée attendait encore son second témoin : RFC 9820
Le contrôleur avait supprimé la session après expiration de son délai. Dans son journal, l’objet était donc clos. L’équipement, isolé au même instant par une coupure radio, n’avait reçu ni la requête DELETE protégée ni la raison de son éviction. Il conservait son contexte et…

Dossier
Trois groupes ML-KEM approuvés, mais aucune recommandation générale
Une ligne de registre peut être techniquement complète tout en refusant de trancher à la place de l’exploitant. Pour les trois groupes ML-KEM autonomes que l’IESG vient d’approuver pour publication, le code existe, DTLS est admis, mais la colonne `Recommended` reste à `N`. Cette…

Histoire d'Internet
Le serveur de noms avait sauté une étape visible, pas une relation : RFC 1498
Un serveur de noms pouvait recevoir le nom d’un service et rendre directement plusieurs points d’attachement. Cette réponse compacte était commode. Elle ne supprimait pourtant ni la machine qui exécutait le service ni les deux liaisons conceptuelles que le résultat venait de…

Histoire d'Internet
Le code répondait. La spécification d’origine restait introuvable : RFC 1492
« Believed compatible »: quelques mots prudents portent tout le poids institutionnel de RFC 1492. En juillet 1993, la mise en œuvre simple de Cisco pouvait servir de témoin pour reconstruire TACACS, mais non de preuve d’un texte original que l’auteur n’avait pu obtenir pour des…

Dossier
Le commutateur a exécuté le programme. Il n’a pas acquis le droit de lire, de réécrire ou de décider : RFC 9817
Pendant une répétition immersive, le son reste fluide mais l’image d’un interprète prend un autre chemin. Le nom du service n’a pas changé. Le programme annoncé n’a pas changé. Pourtant, l’instance s’est déplacée vers un autre équipement, avec un état plus ancien et un accès plus…

Dossier
Trois attestations exactes ne prouvent pas qu’elles appartiennent à la clé du CSR
Dans une chaîne de certification automatisée, trois voyants verts peuvent cacher une faute d’identité. Une preuve décrit une clé créée dans un HSM, une autre une machine détenue par l’entreprise, une troisième un état jugé sain. Tant que l’autorité n’a pas démontré qu’elles…

Dossier
Un seul minuteur a réglé trois mécanismes IPv6. Les compteurs ont perdu la cause
Le ticket demandait de modifier le rythme de détection d’une adresse dupliquée. La valeur choisie a aussi changé la résolution d’adresse et les sondes de joignabilité. Rien n’était invalide dans la transaction: c’est son périmètre réel qui n’avait pas été comptabilisé.

Histoire d'Internet
Le huitième bit a disparu, une translittération est restée : RFC 1489
Un archiviste peut parfois lire une phrase russe après que son fichier a perdu tous ses bits de poids fort. Cette chance ne lui donne pourtant ni les octets d’origine, ni la preuve du codage, ni le droit de certifier les mots qu’il croit reconnaître. La table KOI8-R enregistrée…

Dossier
Le réflecteur de routes a diffusé le lien sans jamais l’observer : la frontière probatoire de la RFC 9815
La promesse du peering clairsemé est séduisante: conserver BGP, supprimer une grande partie des sessions du fabric et laisser chaque routeur recalculer le plus court chemin à partir d’une topologie distribuée. La RFC 9815 rend cette architecture possible. Elle oblige aussi à…
