Voici un RFC explicitement politique, puisqu'il documente la façon dont les concepteur·rices de protocoles à l'IETF devraient examiner les conséquences de leurs protocoles sur l'exercice des droits humains. Si vous concevez un protocole réseau (IETF ou pas), c'est une lecture recommandée.

Le 10 septembre est sortie la version 16 d'Unicode (https://blog.unicode.org/2024/09/announcing-unicode-standard-version-160.html). Une description officielle des principaux changements est disponible (https://www.unicode.org/versions/Unicode16.0.0/) mais voici ceux qui m'ont intéressé particulièrement. (Il n'y a pas de changement radical.)

Voici un RFC sur le protocole de routage Babel. Il normalise une extension au protocole pour tenir compte du RTT, le temps d'aller-retour sur un segment du réseau. C'est l'occasion de revenir sur ce critère de routage, souvent cité mais rarement utilisé (et pour de bonnes raisons).

Des chercheurs en sécurité ont publié un article (https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/) sur un problème causé par le serveur whois du TLD ".mobi". Le problème est réel et le travail des chercheurs excellent, mais je souhaiterais ajouter quelques points.

Pour des raisons de robustesse, il est fortement recommandé d'avoir plusieurs serveurs faisant autorité (serveur-dns-faisant-autorite.html) pour une zone DNS. Mais ce n'est pas tout : il faut aussi de la diversité, pour éviter que la même cause ne rende plusieurs serveurs injoignables. Il est donc très souhaitable d'avoir des serveurs secondaires en dehors de son réseau habituel. Si on est une grosse organisation, il existe des offres commerciales pour cela. Et si on est une petite organisation, avec peu de moyens ? Des solutions existent quand même.

On le sait, les attaques par déni de service sont une des plaies de l'Internet, très difficiles à contrer. Quand elles sont motivés géopolitiquement, on peut souvent les lier à des pays étrangers (pas toujours à juste titre). Il est donc tentant de bloquer les attaques en bloquant l'étranger, ce que vient de faire la Cour de Cassation. Intéressant cas de géopolitique Internet.

Si vous lisez ce blog régulièrement, vous savez que j'insiste souvent pour que, lorsqu'on teste un service réseau, on ne le fasse pas que depuis un seul point de mesure. L'Internet est vaste, et varié ! Il faut donc utiliser plusieurs points de mesure. Si on ne travaille pas chez Google, on n'a probablement à sa disposition qu'un petit nombre de points à sa disposition et on utilise donc un système réparti de mesure. Vous le savez, je suis un grand fan des sondes RIPE Atlas (https://atlas.ripe.net/) mais il est toujours bon de regarder les alternatives comme Globalping (https://www.jsdelivr.com/globalping), qui fait l'objet de cet article.

Le préfixe IPv6 normalisé pour les documentations, "2001:db8::/32" était trop petit pour vous ? Vous aviez du mal à exprimer des architectures réseau complexes, avec beaucoup de préfixes ? Ne pleurez plus, un nouveau préfixe a été alloué, c'est désormais un /20, le "3fff::/20".

Si vous êtes responsable d'une zone DNS, et que vous la testez régulièrement avec des outils comme Zonemaster (https://zonemaster.fr/) ou DNSviz (https://dnsviz.net/) (ce que font tous les responsables sérieux), vous avez peut-être eu des avertissements comme quoi vos « paramètres NSEC3 » n'étaient pas ceux conseillés. C'est parce que les recommandations en ce sens ont changé avec ce RFC. Lisez-le donc si vous voulez comprendre les recommandations actuelles.

Vous qui me lisez, vous êtes probablement un mammifère. Sans une météorite complaisante, vous seriez toujours un genre de petite souris qui n'a même pas inventé l'Internet et vous ne pourriez pas lire ce blog. Heureusement pour vous et malheureusement pour les dinosaures, la météorite a frappé, dégageant le terrain pour « le triomphe et le règne des mammifères », que raconte ce livre.

Comme pour tous les protocoles de séparation de l'identificateur et du localisateur (separation-identificateur-localisateur.html), le protocole LISP, normalisé dans le RFC 9300, doit faire face au problème de la correspondance (mapping) entre les deux informations. Comment trouver un localisateur, en ne connaissant que l'identificateur ? LISP n'a pas de solution unique et plusieurs protocoles de correspondance peuvent être utilisés. La stabilité du logiciel des routeurs imposait une interface stable avec le système de résolution des identificateurs en localisateurs. C'est ce que fournit notre RFC 9301, qui spécifie l'interface, vue du routeur, et qui ne devrait pas changer, même si de nouveaux systèmes de correspondance/résolution apparaissent. Ce RFC remplace le RFC 6833. L'interface change assez peu mais le texte est sérieusement réorganisé, et la spécification a désormais le statut de norme et plus simplement d'expérimentation.

Le jeu de caractères Unicode est vaste (149 000 caractères la dernière fois que j'ai compté et cela augmente régulièrement). Il est donc souvent difficile de trouver un caractère donné. Quels sont les outils pour cela ?

Cet ouvrage (https://www.larcier-intersentia.com/fr/souverainete-numerique-9782802771340.html) collectif rassemble les articles liés aux interventions lors d'un intéressant colloque sur la souveraineté numérique (https://iode.univ-rennes.fr/tous-nos-evenements/souverainete-numerique) tenu à la fac de droit de Rennes en 2022.

Traditionnellement, tous les résolveurs DNS (resolveur-dns.html) fournissaient un service équivalent. Le client avait un résolveur configuré, soit statiquement, soit via DHCP, et ne se souciait pas vraiment du résolveur ainsi désigné, tous étaient pareils. Aujourd'hui, ce n'est plus vraiment le cas : les résolveurs fournissent des services très différents, par exemple en matière de chiffrement, ou de blocage de certains noms. Il est donc utile que le client puisse se renseigner sur son résolveur, ce que permet cette nouvelle technique, le type de données RESINFO, que le client va récupérer dans le DNS.

Ce RFC ajoute au format de données binaire CBOR la possibilité de stocker des données temporelles plus détaillées, incluant par exemple l'échelle utilisée (UTC ou TAI), ou bien ayant une précision supérieure.

Ce mardi 5 juillet 2022, l'organisme de normalisation étatsunien NIST a annoncé (https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms) qu'il avait choisi les algorithmes de cryptographie post-quantiques qu'il allait maintenant normaliser. Ce sont Kyber (https://pq-crystals.org/kyber/index.shtml) pour l'échange de clés et Dilithium (https://pq-crystals.org/dilithium/index.shtml) pour les signatures.

« Quand le numérique devient patrimoine » est le sous-titre de ce livre (https://www.chartes.psl.eu/editions/catalogue-des-publications/de-lecran-lemotion) consacré à un tour d'horizon complet de la question de la gestion patrimoniale des documents numériques. L'auteure s'appuie notamment sur son importance expérience à la BnF. Aucune nostalgie du papier dans ce livre tourné vers l'avenir.