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.
Dossier
La clé est devenue portable. Sa garde ne l’est pas devenue : RFC 9964
La migration post-quantique peut donner l’illusion qu’un nouveau nom d’algorithme règle le problème de confiance. RFC 9964 est plus précis. Il rend les clés ML-DSA représentables dans JOSE et COSE au moyen d’Algorithm Key Pair, ou AKP. Il impose un algorithme et une information…
Dossier
Une requête SCIM achevée ne décide pas à travers les domaines : RFC 9967
Un accusé 202 et un identifiant de transaction identique dans un événement ultérieur donnent une histoire plus nette à une modification SCIM asynchrone. Ils ne donnent pas à l’émetteur le pouvoir de décider ce que l’autre domaine doit faire de cette histoire. Une réception peut…

IETF
Tobias Fiebig et les quatre preuves de joignabilité du DNS
Le moment le plus risqué d’un changement de fournisseur DNS n’est pas toujours la publication des nouveaux serveurs. Il survient quand les anciennes adresses fonctionnent encore, que les nouvelles apparaissent dans la délégation et qu’un succès en double pile masque le chemin qui…

Histoire d'Internet
Avant DHCP, quatre octets ont choisi la grammaire : RFC 1048 et la limite BOOTP de 64 octets
Une machine qui démarrait par le réseau devait comprendre une réponse avant même de posséder tous les moyens ordinaires de se configurer. En 1988, RFC 1048 a transformé les 64 octets réservés par BOOTP aux données de fournisseur en une petite langue commune. Son cookie magique…

Histoire d'Internet
Le nom était l’adresse. Il n’était pas une route : le mappage IP-sur-NetBIOS de RFC 1088
En 1989, RFC 1088 a fait tenir une convention d’acheminement locale dans une écriture lisible. Pour une machine IP sur NetBIOS, l’adresse IP devenait le nom NetBIOS `IP.XX.XX.XX.XX`, chaque octet étant rendu en hexadécimal ASCII. Cette formule évitait une requête d’adresse…

Histoire d'Internet
Quatre octets ont donné une frontière à TCP. Ils n’ont pas reconstruit le réseau OSI : la limite TPKT de RFC 1006
Une application peut écrire une unité cohérente et TCP peut néanmoins la livrer en morceaux, ou avec sa voisine. Ce n’est pas une défaillance de TCP: c’est sa promesse de flot d’octets. RFC 1006 a répondu à ce décalage pour le transport ISO par une convention volontairement…
Dossier
Le code historique a atteint le client. Il n’a pas réautorisé le serveur : RFC 9963
Une nouvelle valeur dans un registre peut donner l’illusion d’une permission générale. RFC 9963 fait exactement l’inverse: il encadre une exception. Ses trois valeurs RSASSA-PKCS1-v1_5 historiques ne servent qu’à la signature `CertificateVerify` d’un client TLS 1.3, après qu’un…
Dossier
La connexion inverse est arrivée. L’identité de l’équipement restait à établir : RFC 10011
Une connexion qui arrive au bon écouteur peut rassurer une équipe trop vite. L’équipement était censé appeler, le contrôleur attendait, le pare-feu n’a pas bloqué le flux: voilà déjà beaucoup de faits utiles. Mais aucun de ces faits ne dit, à lui seul, quel équipement est à…

Histoire d'Internet
Le jeton a trouvé la connexion. Il n'a pas admis le sous-flux : la frontière MP_JOIN de MPTCP
Le premier paquet d'une nouvelle liaison peut porter une histoire qui lui est antérieure. Dans MPTCP, un SYN sur une autre paire d'adresses ne crée pas nécessairement une nouvelle conversation applicative: il propose d'ajouter un sous-flux TCP à une connexion déjà établie. La…
Dossier
La clé post-quantique a été ajoutée. Le destinataire classique pouvait toujours lire le message : RFC 9980
RFC 9980 donne à OpenPGP des algorithmes post-quantiques et des clés composites associant ML-KEM à X25519 ou X448. C’est une avancée d’interopérabilité, pas un tampon que l’on peut apposer sur toute messagerie. Un même message peut être chiffré pour une clé PQ/T et, afin de…

IETF
Weiqiang Cheng et le locator SRv6 dont le bail ne valait pas route
Un agrégat peut rester annoncé alors qu’un locator précis a expiré. Ce n’est ni forcément une panne ni la preuve que le bail demeure valable: c’est le point où le cycle DHCPv6, la table de routage et la politique de rejet doivent être relus ensemble.

Récits
LACNIC et l’économie d’une transition au-delà des RIR
Une architecture de relais crédible doit transmettre un service, des preuves et une autorité légitime — pas seulement une base de données.

Histoire d'Internet
La bannière occupait l’écran, pas la décision : la RFC 933 et la frontière d’affichage de Telnet
Une mention de sécurité répétée par l’application à chaque nouvel écran était à la fois fragile et coûteuse. La RFC 933 proposait de la confier au Telnet du poste de travail; elle rendait ainsi le marquage persistant, sans transformer ce texte en règle d’accès.
Dossier
Le modèle pouvait expliquer le réseau. Il ne pouvait pas autoriser le changement : NEMOPS et la frontière entre visibilité et contrôle
Le rapport NEMOPS réclame des modèles plus utiles, une meilleure observabilité et des changements vérifiables. Ces progrès rendent une opération plus intelligible. Ils ne disent pas qui peut exposer un service vivant à un risque, ni qui porte la perte lorsqu'une automatisation se…
Dossier
Le paquet rapide a maintenu la session active. Il n’a pas autorisé le changement : RFC 9985
RFC 9985 traite un dilemme très concret: protéger à haute fréquence une session BFD sans faire de l’authentification le facteur qui empêche l’échelle. Sa réponse répartit le coût. Une authentification plus coûteuse accompagne les changements significatifs; une autre, moins…

Histoire d'Internet
Le NAK refusait le port, non le paquet : RFC 938 et la frontière entre réception et aiguillage
Un protocole expérimental de 1985 pouvait confirmer l'avancée d'une séquence tout en déclarant inconnu le port local visé. Cette réponse, `PORT NAK`, ne dit pas qu'une application a reçu les données; elle soigneusement distingue le constat du transport de la décision…
Dossier
Une exigence OAM est écrite. Elle ne prouve pas un diagnostic opérationnel : RFC 9974 et la preuve BIER
Une liste d'exigences peut éclairer ce qu'il faut construire. Elle ne confirme ni qu'un réseau possède déjà cette capacité, ni qu'une mesure donnée justifie une action.

Récits
Le plan de clés RPKI du RIPE n’est pas encore un reçu de périmètre ROA
Le passage envisagé par le RIPE NCC vers des clés RPKI fondées sur OpenID Connect décrit un futur mécanisme d’accès. Il ne constitue pas encore une preuve publique du périmètre de ressources et de l’action précise qui ont autorisé une modification donnée de ROA.
Dossier
L’heure signée a évité un transfert. Elle n’a pas prouvé un instant : RPKI, RFC 9589 et la frontière de bascule
Lorsqu’un relying party RPKI quitte RRDP pour rsync, il peut réutiliser des objets sans faire d’une heure signée une vérité sur le temps. RFC 9589 organise cette économie de transfert et maintient séparées les preuves de validité, de publication et de routage.

Histoire d'Internet
L’UUID a traversé la connexion. L’autorité est restée sur place : le pari de la RFC 927 contre la double identification
Supprimer un second mot de passe ne supprimait pas une seconde décision. En 1984, la RFC 927 proposait qu’un hôte transmette un identifiant de quatre octets après avoir authentifié l’utilisateur; l’hôte cible gardait néanmoins le droit d’accepter ou de refuser cette parole venue…
