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
L’en-tête arrivait en dernier : la reconstruction des trames série dans le RFC 1963
Le RFC 1963 a choisi une disposition qui ressemble d’abord à un paradoxe: transmettre les données, puis placer à la fin l’en-tête qui permet de les interpréter. Ce choix répondait au moment où la taille compressée devenait connue. Il définissait une grammaire de reconstruction…
IETF
Le Vérificateur s’est abonné, pas la décision
Un projet de l’IETF transforme l’attestation des équipements en flux d’événements. Il rapproche la mesure de l’observation, sans abolir les frontières entre preuve reçue, évaluation, autorisation et résultat.
Récits
RIPE NCC dit sa facturation 2027 prête. La facture, elle, attend encore le 31 décembre
RIPE NCC a achevé les travaux applicatifs nécessaires à son barème 2027 avant que n’existent les données qui fixeront les premières factures. C’est une chronologie raisonnable pour un projet. Mais elle oblige à distinguer deux preuves: celle d’un logiciel livré et celle d’un…
Récits
La contrainte RPKI d’ARIN vieillit au rythme du paquet qui la distribue
Entre un registre mis à jour chaque jour et un validateur local, il y a une chaîne de fabrication. Le projet de contrainte d’ancre de confiance d’ARIN ne sera crédible que si cette chaîne laisse un reçu.
Dossier
AlmazCloud Network : ce que le registre ne prouve pas sur AS210328
Une enquête sur la différence entre une identité réseau enregistrée, une présence web et une capacité d’exploitation observable.
Société des ressources numériques
ROYA Communications et l’AS210837 : mesurer la continuité quand les couches d’observation divergent
Le résumé de veille ROYA Communications et l’AS210837: mesurer la continuité quand les couches d’observation divergent explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences…
Dossier
Deux chemins appariés ne prouvent pas un aller-retour : RFC 9854
Dans un réseau radio contraint, le trajet qui permet à une requête d'atteindre sa cible peut être inutilisable dans l'autre sens. Le RFC 9854 traite ce problème avec deux instances directionnelles liées; cette liaison protège la cohérence du contrôle, mais elle ne constitue ni…
Société des ressources numériques
AS210057 : ce que les traces publiques établissent — et ce qu’elles ne permettent toujours pas d’attribuer
Le résumé de veille AS210057: ce que les traces publiques établissent — et ce qu’elles ne permettent toujours pas d’attribuer explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les…
IETF
Roberto Peon et la table HPACK qui retenait des champs sans jamais mettre une réponse en cache
Un indice minuscule peut restituer un long champ HTTP sur une connexion. Il ne dit ni si une réponse est fraîche, ni si elle peut être réutilisée, ni même si elle a été conservée.
Histoire d'Internet
Un dictionnaire perdu dans un sens, le trafic continuait dans l’autre : RFC 1962
Sur une liaison PPP, « les deux extrémités sont d’accord » était une formule trop grossière. En 1996, RFC 1962 a séparé deux décisions: ce que chaque récepteur sait décompresser et ce que son pair peut donc lui envoyer. La même séparation limite la panne: un dictionnaire peut…
Récits
Le ticket ouvert d’ARIN sur 1 024 caractères cache une grammaire de routage privée
ARIN doit décider s’il agrandit un champ de commentaires de son registre de routage. Mais le cas soumis à l’institution révèle autre chose qu’un problème de taille: chez Lumen, une phrase balisée dans `remarks` peut supplanter la liste de membres prévue par RPSL. Avant d’ajouter…
Récits
RIPE ABUSE : qui contrôle réellement la chaîne après le signalement ?
Le contact abuse-c de RIPE Database ouvre une voie de signalement, mais il ne constitue qu’un point de départ. Pour comprendre ce que ce mécanisme contrôle réellement, il faut suivre le déplacement de la responsabilité: du registre vers la boîte aux lettres, puis vers le…
Récits
Un seul pourcentage ne suffit pas à solder le plan ROV d’APNIC et de NIXI en Inde
Un protocole d’accord peut fixer une ambition en une page. La preuve de son exécution tient rarement dans une case. Pour le programme indien d’APNIC et de NIXI, il faudra distinguer les autorisations de route, les observations faites auprès des internautes, les politiques…
Dossier
Le contrôleur a reçu l’état. Il lui manquait encore une horloge : RFC 9857
RFC 9857 rend enfin l’état des chemins candidats SR Policy visible hors du routeur de tête. Cette visibilité inverse le sens habituel de l’automatisation, sans résoudre la question décisive: de quand date l’observation et jusqu’où peut-on lui faire confiance ?
IETF
Jon Callas et l’identifiant OpenPGP qui n’a jamais désigné une clé unique
Seize caractères hexadécimaux tiennent dans un ticket d’incident. Ils ne suffisent pas à distinguer à coup sûr une clé, encore moins à prouver l’identité ou le pouvoir de son détenteur.
Tendances FAI régionaux Europe et Moyen-Orient
AS210837 : comment tester la continuité opérationnelle d’un réseau sans confondre les signaux
Le résumé de veille AS210837: comment tester la continuité opérationnelle d’un réseau sans confondre les signaux explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences possibles…
IETF
Une entropie nouvelle entre dans la session ; la reprise reste à prouver dans les deux sens
Le KeyUpdate ordinaire de TLS 1.3 prolonge une chaîne de secrets déjà établie. Le projet Extended Key Update propose de refaire un échange de clés dans une session vivante et d'injecter un secret partagé neuf. Cette opération ouvre une possibilité de reprise après compromission…
Histoire d'Internet
L’URL transportait une requête, pas son autorité : RFC 1959
Une adresse que l’on peut copier donne une impression de stabilité. Pourtant, dans le cas de RFC 1959, ce qui voyageait n’était ni une fiche d’annuaire ni une décision d’accès. L’URL rassemblait les éléments nécessaires à la construction d’une recherche LDAP. Le serveur…
IETF
Nathaniel Borenstein et l'encodage Base64 qui n'a jamais promis la confidentialité
Deux chaînes Base64 peuvent cacher la même suite d'octets au regard humain, ou produire les mêmes octets malgré une forme différente. Aucune des deux ne dit qui avait le droit de les lire.
Dossier
Deux sources, un choix, mais aucune preuve de continuité : RFC 9856
La redondance multicast ne vaut que si le récepteur obtient un flux unique et exploitable. RFC 9856 organise le choix dans un EVPN; elle ne transforme pas ce choix en verdict de service.