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
Ce que sait réellement un rapport agrégé : RFC 9990 et la frontière avant toute mesure
Un rapport DMARC agrégé est une observation formulée par un système de réception, non le jugement définitif d’un réseau sur un domaine. Il peut révéler une source oubliée, une configuration instable ou un volume qui mérite enquête. Il ne permet pas, seul, d’identifier une…

Histoire d'Internet
L’Internet servait de liaison, pas de réseau : la frontière expérimentale de la RFC 1070
Avant d’échanger une seule information de routage OSI, un système EON devait savoir à qui parler. Une liste tenue par l’IANA lui donnait quelques adresses de départ. Cette liste ne décrivait pourtant ni les routeurs, ni tous les entités, ni même un état nécessairement à jour.…

IETF
Lukasz Kondrad et le groupe RTP qui n’était pas encore une scène reconstruite
Quatre lignes SDP peuvent appartenir à une même représentation V3C sans avoir jamais produit, chez le récepteur, le même objet en trois dimensions. La grammaire relie des composants; seule l’exécution établit la scène.

Histoire d'Internet
La requête était en file. Le fichier devait encore bouger : la frontière BFTP de la RFC 1068
Une tâche peut survivre à la fenêtre qui l'a créée. Le résultat, lui, n'existe pas encore. En 1988, BFTP a confié à une file persistante et à un démon les tentatives qu'un utilisateur ne voulait plus surveiller. Cette continuité rendait le transfert plus commode, tout en…
Dossier
La préférence fut publiée. Ce n’était pas un contrôle de l’IA : RFC 9969
RFC 9969 ne transforme pas une préférence publiée en pouvoir sur un système d’IA. Le rapport rend visible un problème de coordination: une préférence peut être exprimée, attachée à un contenu et observée lors d’un crawl sans pour autant identifier le collecteur, prouver un usage…
Dossier
L’identifiant de provisioning n’était pas un accès réseau : RFC 9965
RFC 9965 offre à un pair EAP sans identifiants une manière de demander un parcours de provisioning limité. Un identifiant `eap.arpa` décrit cette demande; il ne prouve ni l’identité du pair, ni l’émission d’un identifiant, ni un accès normal au réseau.

Histoire d'Internet
La trame FDDI transportait IP, pas une identité : la frontière d’encapsulation de la RFC 1188
Un réseau peut savoir comment placer un datagramme dans une trame sans savoir qui en est l’auteur, à qui appartient une adresse, ni ce que le destinataire fera du contenu. La RFC 1188 a rendu cette retenue visible sur FDDI en 1990. Elle a fixé une grammaire de liaison, une taille…

Histoire d'Internet
Pour attendre moins, le paquet avait moins de place : le compromis de la RFC 1046
Une file courte tient mieux une promesse de délai qu'une file généreuse. Elle a aussi une conséquence immédiate: elle refuse plus tôt ce qui n'y entre pas. En 1988, la RFC 1046 a bâti sa proposition de service IP à faible délai sur cette tension, sans offrir à la classe rapide ni…
Dossier
Une signature de clé d’hôte n’achève pas la décision de confiance locale : RFC 10042
RFC 10042 ajoute à SSH une construction précise qui mêle ML-KEM et ECDH pour établir un secret de session. La signature du transcript compte, mais elle ne remplace ni la vérification locale de la clé d’hôte, ni l’authentification de l’utilisateur, ni une décision d’accès.

Histoire d'Internet
La boîte aux lettres était un contact, pas une salle de contrôle : la « tradition orale » de la RFC 1173
Au début de l’Internet, une panne visible de loin ne donnait pas à l’observateur le pouvoir de la réparer. Elle lui donnait, au mieux, une raison de trouver quelqu’un qui pouvait regarder du côté concerné. La RFC 1173, publiée en 1990, a fixé cette discipline de coopération: un…
Dossier
Un nom SNI ne désigne pas à lui seul le serveur qui décide : RFC 9950
RFC 9950 permet de configurer séparément l’adresse de transport d’un serveur TACACS+, son nom de domaine pour SNI et les mécanismes de sécurité associés. Cette précision de configuration ne donne pas à un nom la capacité de prouver qui décide, ni ce qu’un service autorisera.
Dossier
Un test à débit fixe n’autorise pas la conclusion : RFC 9946
RFC 9946 réserve le test UDPSTP à débit fixe à une exploitation locale très précise. Cette restriction ne transforme ni le débit injecté ni le résultat observé en engagement de capacité.

Histoire d'Internet
Une phrase de politique n’était pas un contrôle réseau : RFC 1087 et les limites de « l’usage acceptable »
En 1989, l’Internet Activities Board pouvait désigner des comportements qui mettaient en danger une infrastructure de recherche partagée. Il pouvait condamner l’intrusion intentionnelle, la perturbation, le gaspillage, la destruction et l’atteinte à la vie privée. Mais aucune de…

Histoire d'Internet
Le bit préservait le chemin du retour, pas l'authenticité de la requête : le SRC HYPERchannel de la RFC 1044
La RFC 1044 ne disait pas simplement qu'une adresse source était « correcte ». Elle précisait le test: inverser les adresses du support devait ramener une réponse au processus d'origine. Cette précision faisait du bit SRC une preuve utile de réversibilité, tout en laissant hors…
Dossier
Le message CMC est arrivé. L’autorité de certification, elle, n’est pas arrivée avec lui : RFC 10003
RFC 10003 permet à un objet CMC de circuler par fichier, courrier, HTTP ou TCP. Cette circulation prouve une étape de transport, pas la compétence locale de décider d’un certificat.

Histoire d'Internet
La vitesse était une indication d’affichage, pas la liaison : la limite de Telnet dans le RFC 1079
En 1988, un programme de terminal distant pouvait apprendre quelque chose d’utile sur le terminal de son correspondant sans feindre de connaître le réseau qui les séparait. Le RFC 1079 trace cette limite avec une rare netteté. Il permet à un pair Telnet de demander deux vitesses…

IETF
La nouvelle charte STIR de l’IETF sépare le droit d’utiliser un numéro de l’identité de l’entité
Un appel peut présenter une signature valide et un certificat couvrant le bon numéro sans révéler l’acteur institutionnel qui se trouve derrière cette autorisation. Le projet de nouvelle charte STIR reconnaît précisément ce manque. La réponse ne devrait pas être un annuaire…
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…
