Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.


BCP 38, ne pas laisser des adresses IP usurpées sortir de son réseau

Première rédaction de cet article le 7 décembre 2016


Qu'est-ce que ça peut bien être, « BCP 38 » ? Ce terme désigne un ensemble de documents de bonnes pratiques pour les acteurs de l'Internet, plus spécialement les opérateurs réseaux : il ne faut pas laisser sortir de son réseau des paquets ayant une adresse source usurpée. Le respect de ce principe permettrait de lutter contre certaines attaques par déni de service sur l'Internet. Ce principe est formalisé dans deux RFC, les RFC 2827 et RFC 3704.

« BCP » veut dire « Best Current Practice ». Le but de cet étiquetage est de pointer vers le ou les RFC qui décrivent la pratique en question. En effet, un RFC, une fois publié, n'est jamais modifié, alors que le monde, lui, change. C'est ainsi que le RFC 7525, parlant de TLS est décrit par l'étiquette BCP 195 : les bonnes pratiques, en matière de cryptographie, changent vite. Une étiquette BCP peut pointer plusieurs RFC. Un bon exemple est le BCP 47, sur les étiquettes de langue, qui pointe vers les RFC 5646 et RFC 4647.

C'est également le cas de BCP 38, qui désigne le RFC 2827, avec les additions du RFC 3704.

Le problème que vise à résoudre ce BCP est celui de l'usurpation d'adresse IP par un attaquant qui voudrait faire du déni de service sans révéler son adresse, ou bien en faisant une attaque par réflexion. Par défaut, dans l'Internet, il est trivial d'émettre des datagrammes avec une adresse source mensongère. BCP 38 dit que les opérateurs réseaux devraient interdire cette pratique, en configurant leurs routeurs à cette fin. Par exemple, si un FAI a deux préfixes IP, 192.0.2.0/24 et 2001:db8::/32, il n'y a aucune raison valable de laisser sortir du réseau du FAI des paquets ayant comme adresse IP source, mettons, 203.0.113.65.

Notons qu'un déploiement systématique de BCP 38 résoudrait un certain nombre de problèmes de sécurité sur l'Internet, mais pas tous. Ainsi, si l'attaquant dispose d'un botnet, et fait une attaque directe (pas par réflexion), il n'a pas vraiment besoin de mentir sur ses adresses IP source, ce ne sont pas les siennes, de toute façon (usurper l'adresse source aurait quand même quelques avantages, ça dépend des cas).

Aujourd'hui, le déploiement de BCP 38 dans l'Internet n'est pas inexistant mais il est très inégal. Par exemple, la situation est bien meilleure en Europe qu'en Asie. Un attaquant qui veut faire de l'usurpation d'adresses IP a donc encore pas mal de réseaux à sa disposition.

Pourquoi est-ce que tout le monde n'a pas déployé BCP 38, malgré le très large consensus qui existe parmi les professionnels ? La principale raison est économique. Un opérateur qui déploie BCP 38 (tous les routeurs permettent de le faire, soit en n'autorisant que ses propres préfixes, soit par des astuces comme RPF) aide les autres. Imaginez l'ingénieur allant voir le directeur financier et lui disant « on va dépenser de l'argent, et le ROI ira entièrement à nos concurrents »... Comme en écologie, c'est donc un cas typique où le sacro-saint marché ne peut pas aboutir à une bonne solution.

Notez que tester si un FAI donné met en œuvre ou pas BCP 38 est un peu plus compliqué que cela peut sembler au premier abord. Je connais par exemple une box très utilisée en France qui bloque les paquets IPv4 ayant une adresse IP source usurpée (par effet de bord du NAT) mais qui ne le fait que pour des flots existants ou pour des paquets de début d'un flot. Si on envoie un paquet TCP sans bit SYN, il passe malgré son adresse usurpée...

Quelques lectures pour approfondir :


L'article seul

Fiche de lecture : The Internet of money

Auteur(s) du livre : Andreas Antonopoulos
Éditeur : Merkle Bloom
9781537000459
Publié en 2016
Première rédaction de cet article le 5 décembre 2016


Ce petit livre rassemble le texte de plusieurs conférences d'Andreas Antonopoulos au sujet de Bitcoin. Les textes ont été édités, les erreurs corrigées, mais le ton reste celui des conférences de l'auteur, passionantes et brillantes. Sa thèse principale est que le Bitcoin n'est pas juste une monnaie, c'est un mécanisme sur lequel on va pouvoir bâtir plein de nouvelles relations économiques, c'est l'Internet of money. Et les vieux dinosaures du monde actuel peuvent toujours critiquer, et prétendre que le Bitcoin n'a pas d'avenir, Antonopoulos démonte tous leurs arguments. (Les conférences elles-mêmes sont visibles en ligne.)

C'est donc vraiment le bouquin à faire lire aux gens qui expliquent doctement que le Bitcoin n'est pas une monnaie réelle, ou bien que ce n'est qu'une expérience d'une poignée de gusses dans leur garage. Antonopoulos est très pédagogue... et très militant.

Il n'a pas de mal à rappeler que les arguments contre le Bitcoin sont à peu près les mêmes que ceux employés par les messieurs sérieux et les experts médiatiques contre l'Internet (ou, puis-je ajouter, contre Unix et contre le logiciel libre) : c'est juste une expérience, ce n'est pas sérieux, c'est un truc de hippies libertariens, cela ne durera pas. Pourquoi croirait-on aujourd'hui ces mêmes experts ? D'où le titre du livre, qui fait allusion au fait que l'auteur prédit au Bitcoin le même succès que l'Internet : déranger les systèmes en place, permettre de nouvelles possibilités, reposer les questions. « Dire que le Bitcoin est une monnaie numérique, c'est aussi réducteur que dire que l'Internet est un téléphone amélioré. »

Un concept intéressant dans une des conférences est celui d'inversion de l'infrastructure. Au début, la nouvelle technologie utilise une infrastructure conçue pour la technologie précédente, et a donc bien du mal. Les premières voitures roulaient sur des routes prévues pour les chevaux. Ceux-ci ont quatre pattes et un bon équilibre, les trous ne les dérangeaient donc pas trop, alors qu'ils étaient redoutables pour les voitures. Petit à petit, les choses ont changé, l'infrastructure s'est inversée, et ce sont aujourd'hui les chevaux qui marchent sur une route goudronnée conçue pour les voitures. De même, l'Internet à ses débuts devait emprunter une infrastructure conçue pour le téléphone (et on avait besoin de modems, pour faire passer IP pour de la voix) alors qu'aujourd'hui, l'infrastructure s'est inversée, c'est la voix qui n'est plus qu'une des nombreuses applications qui utilisent l'infrastructure de l'Internet.

De la même façon, estime Antonopoulos, les services bancaires traditionnels continueront à exister, mais seront simplement des applications au dessus de Bitcoin.

L'auteur est bien conscient que les adversaires du Bitcoin ne vont pas se contenter de le ridiculiser ou de le critiquer. Ils vont activement tenter de l'interdire. Il est très optimiste sur les chances du Bitcoin de résister à cette censure (dans le pire des cas, les transactions seront encodées en smileys dans les discussions des articles Wikipédia et ne pourront donc pas être stoppées...) Après tout, Bitcoin a déjà été testé au feu, d'innombrables attaques ont déjà visé cette monnaie, et le Bitcoin a toujours survécu. (Voir à ce sujet l'hilarant site « Bitcoin Obituaries » et l'amusante vidéo « Not this time ».)

Antonopoulos insiste sur le caractère « sans permission » du Bitcoin. Il n'y a pas de Président du Bitcoin, chacun avec une idée peut la mettre en œuvre sur la chaîne de blocs tout de suite, sans demander de permission. En tant que « programmable money », Bitcoin n'a pas seulement un usage (payer) mais tous les usages qu'on peut imaginer. (Le Bitcoin est neutre, au sens de « neutralité du réseau ».)

Antonopoulos fait remarquer que toutes les innovations ont été la cible d'innombrables critiques à leur début. (Il oublie de dire que certaines critiques étaient justifiées. Par exemple, il cite des déclarations anti-voiture des débuts de l'automobile, pointant les dangers mortels de cette technologie, dangers qui existent toujours.) Ces critiques semblent bien ridicules avec le recul, comme celles contre le Bitcoin sonneront moyenâgeuses dans le futur. Antonopoulos remarque avec justesse que ces critiques portaient souvent sur des points de détail, qui allaient évoluer avec le temps. Ainsi, les premières critiques des automobiles portaient sur la difficulté à les faire démarrer, problème réel mais qui a été vite résolu avec l'invention du démarreur. (Personnellement, je me souviens bien des premières démonstrations de l'Internet que je faisais au début des années 1990, où la plupart des remarques des gens portaient sur le caractère « peu convivial » des logiciels utilisés. Peu de gens étaient capables de voir l'intérêt de cette technologie, au-delà de problèmes ergonomiques temporaires.)

Dans une autre conférence, Antonopoulos revient sur la monnaie : de quand date t-elle ? Et, d'ailleurs, qu'est-ce qu'on appelle « monnaie » ? (Beaucoup de messieurs experts refusent de considérer le Bitcoin comme une monnaie car ils donnent de la monnaie une définition arbitraire et anti-historique du genre « la monnaie est le moyen de paiement décidé par un État, et régulé ».)

L'auteur insiste aussi sur l'importance pour les acteurs du monde Bitcoin de ne pas copier bêtement le vocabulaire du passé. Ainsi, il s'énerve (à juste titre) contre les articles mentionnant le Bitcoin et qui sont illustrés par... des pièces de monnaie. Il reconnait que c'est d'ailleurs en partie la faute du terme « bitcoin » qui est trompeur. De même, le terme de « portefeuille », souvent utilisé pour les logiciels de gestion de ses bitcoins, est erroné : on ne peut pas copier un portefeuille traditionnel, alors qu'il n'y a aucun problème à le faire avec un portefeuille Bitcoin (il ne stocke pas d'argent, mais des clés).

Autre exemple de l'erreur qu'il y a à copier aveuglément les anciennes techniques, les places de marché Bitcoin. Ces places n'ont rien de Bitcoin, ce sont des établissements financiers traditionnels et, notamment, leur modèle de sécurité n'est pas du tout celui de Bitcoin.

Compte-tenu de la marée médiatique anti-Bitcoin (et anti-cryptomonnaies en général), on a bien besoin d'un livre comme celui-ci, qui redresse la barre. Par contre, il ne faut pas y chercher une analyse balancée. On ne voit aucune critique sur les aspects problématiques du Bitcoin. Il faudra un autre livre pour cela. Un volontaire pour écrire une critique sérieuse du Bitcoin ? (Qui ne se limite pas à des points de détail spectaculaires comme l'identité de Nakamoto, ou à du simple conservatisme du genre « les banques n'en veulent pas » ?) En attendant, lisez le livre, et écoutez les conférences d'Andreas Antonopoulos, vous ne le regretterez pas.


L'article seul

RFC 8027: DNSSEC Roadblock Avoidance

Date de publication du RFC : Novembre 2016
Auteur(s) du RFC : W. Hardaker (USC/ISI), O. Gudmundsson (CloudFlare), S. Krishnaswamy (Parsons)
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 4 décembre 2016


Normalement, en 2016, tous les résolveurs DNS sérieux devraient valider avec DNSSEC. Mais ce n'est pas le cas. Il y a plusieurs raisons à cela, mais ce nouveau RFC se focalise sur un problème précis : le cas d'un résolveur connecté via un réseau pourri, non-neutre, et qui se permet d'interférer avec le transport des paquets IP, menant le résolveur à de sérieuses difficultés. Comment détecter ces réseaux pourris ? Et que faire pour valider quand même ?

Si le résolveur est une grosse machine dans un centre de données, connectée directement à des opérateurs neutres, il n'y a pas trop de problème. C'est le cas des résolveurs des FAI, par exemple. Mais la situation est bien moins favorable à M. Michu. Si celui-ci veut, à juste titre, avoir son propre résolveur DNS sur sa machine, il dépend des réseaux où on laisse M. Michu se connecter, et ceux-ci sont rarement neutres. (Le RFC couvre le cas où ce résolveur local fait suivre - forwarde - les requêtes à un autre résolveur, et celui où il parle directement aux serveurs faisant autorité.)

La section 1.2 du RFC décrit les cas où la validation DNSSEC va être difficile ou impossible :

  • Résolveur qui ne connait pas DNSSEC (évidemment),
  • Intermédiaires (relais DNS dans la box, par exemmple), qui viole le protocole DNS au point de gêner le fonctionnement de DNSSEC (ce cas est décrit en détail dans le RFC 5625),
  • Équipements réseau actifs qui modifient ou bloquent les messages DNS, par exemple en supprimant les signatures DNSSEC (beaucoup de « firewalls » sont dans ce cas),
  • Réseau qui ne gère pas correctement les fragments, ce qui est plus fréquent avec DNSSEC.

Bien des outils ont été développés pour contourner ces problèmes, comme dnssec-trigger.

Pour faire des tests des résolveurs et de tous les équipements intermédiaires qui peuvent poser des problèmes de validation DNSSEC dans certains cas, le RFC parle d'une zone de test nommée test.example.com. Elle n'existe pas en vrai mais, aujourd'hui, la zone test.dnssec-tools.org fait la même chose (elle est par exemple utilisée pour les travaux pratiques lors de la formation DNSSEC chez HSC). Cette zone est délibérement peuplée avec des noms mal signés. Ainsi, le nom badsign-aaaa.test.dnssec-tools.org a un enregistrement AAAA dont la signature a été modifiée, la rendant invalide. Testons (pour tous les tests, comme le but était de voir le comportement DNSSEC, j'ai utilisé un fichier de configuration ~/.digrc contenant +dnssec +multiline, merci à Landry Minoza de l'avoir remarqué) :


% dig AAAA badsign-aaaa.test.dnssec-tools.org
; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> AAAA badsign-aaaa.test.dnssec-tools.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60910
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;badsign-aaaa.test.dnssec-tools.org. IN AAAA

;; Query time: 3759 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 04 17:12:28 CET 2016
;; MSG SIZE  rcvd: 63


% dig +cd AAAA badsign-aaaa.test.dnssec-tools.org
; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> +cd AAAA badsign-aaaa.test.dnssec-tools.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29404
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;badsign-aaaa.test.dnssec-tools.org. IN AAAA

;; ANSWER SECTION:
badsign-aaaa.test.dnssec-tools.org. 86400 IN AAAA 2001:470:1f00:ffff::1
badsign-aaaa.test.dnssec-tools.org. 86400 IN RRSIG AAAA 5 4 86400 (
				20170101064820 20161202054820 19442 test.dnssec-tools.org.
				nZ8bPLBleW/sW6x135+Iz4IhO6Lr04V8C9fC1bMVfCVY
				3rKqbOoBk1i+wnnGDCTWQ5iCicWTKLIpbDmCSW9C33pj
				P2j7C/ensspbdwpD/7Ia8zN+XUSN+ThLU6lgYGKFuoVL
				QmIG/vr1lOn6xdjXY2E4mStAjaGuertvKKDYy/I= )

;; AUTHORITY SECTION:
test.dnssec-tools.org.	280 IN NS dns1.test.dnssec-tools.org.
test.dnssec-tools.org.	280 IN NS dns2.test.dnssec-tools.org.
test.dnssec-tools.org.	280 IN RRSIG NS 5 3 86400 (
				20170101064820 20161202054820 19442 test.dnssec-tools.org.
				AK95JOAuvfZ1ZwEsrKiR8DP1zluoBvBkXHRXa78rrK5U
				UuZdLnZwnYlnNplrZZOrQNuUaPyb4zI0TGfw/+aa/ZTU
				qyx8uQODSHuBTPQTlcmCFAfTIyd1Q+tSTEs2TuGUhjKe
				H9Hk+w6yOjI/o52c2OcTMTJ4Jmt2GlIssrrDlxY= )

;; ADDITIONAL SECTION:
dns1.test.dnssec-tools.org. 280	IN A 168.150.236.43
dns2.test.dnssec-tools.org. 280	IN A 75.101.48.145
dns1.test.dnssec-tools.org. 86400 IN RRSIG A 5 4 86400 (
				20170101064820 20161202054820 19442 test.dnssec-tools.org.
				zoa0V/Hwa4QM0spG6RlhGM6hK3rQVALpDve1rtF6NvUS
				Sb6/HBzQOP6YXTFQMzPEFUza8/tchYp5eQaPBf2AqsBl
				i4TqSjkIEklHohUmdhK7xcfFjHILUMcT/5AXkEStJg7I
				6AqZE1ibcOh7Mfmt/2f0vj2opIkz6uK740W7qjg= )
dns2.test.dnssec-tools.org. 86400 IN RRSIG A 5 4 86400 (
				20170101064820 20161202054820 19442 test.dnssec-tools.org.
				hGq7iAtbHrtjCYJGMPQ3fxijhu4Izk8Ly+xZOa0Ag24R
				lqpFgdd2amDstFVLTRs3x15UqQIO+hmFdlbSOterDkbg
				/o2/FhtZOJr7c75Pu3EWi/DDbT9pULk4Uwjlie1QBopv
				LLZ94SlqKO7eQ02NRyy5EL4gD2G5rSffsUqEkj8= )

;; Query time: 206 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 04 17:12:44 CET 2016
;; MSG SIZE  rcvd: 885

    

Le second test, celui fait avec le bit CD (Checking Disabled), montre que le problème vient bien de DNSSEC. Autre test, avec une signature expirée :


% dig A pastdate-a.test.dnssec-tools.org
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46319
...


% dig +cd A pastdate-a.test.dnssec-tools.org
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49547
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
...
;; ANSWER SECTION:
pastdate-a.test.dnssec-tools.org. 86400	IN A 64.90.35.104
pastdate-a.test.dnssec-tools.org. 86400	IN RRSIG A 5 4 86400 (
				20161201224321 20161101234821 19442 test.dnssec-tools.org.
				lIL0zcEZpG/4uG5hImvpivH1C/D3PFI3RNYHlPbZ [...]

    

La liste de tous les noms à tester est en ligne.

Le but de ce RFC est de lister tous les tests que peut et devrait faire un validateur local, pour arriver à valider malgré des résolveurs amont, ou bien un réseau, hostile. Ces stratégies sont mises en œuvre, par exemple, dans dnssec-trigger.

En détectant la non-conformité (compliance, un terme à la mode dans les organisations), le validateur situé sur la machine terminale, ou bien dans le réseau local, peut alors adopter la meilleure stratégie de contournement (ou, dans le pire des cas, prévenir loyalement l'utilisateur qu'on ne pourra pas faire de validation DNSSEC). Les tests doivent être faits au début d'une nouvelle connexion réseau, ou bien lorsque celle-ci change.

La section 3 du RFC est consacrée à ces tests de non-conformité. Je ne vais pas décrire la totalité de ces tests, un sous-ensemble suffira. Ainsi, le premier test, le plus trivial, est que la machine puisse parler en UDP à son résolveur attitré (celui typiquement reçu en DHCP). On lui demande good-a.test.dnssec-tools.org et on doit avoir une réponse sous forme d'une adresse IP (comme son nom l'indique, ce nom est correctement signé). Si un test aussi trivial ne marche pas, ce n'est sans doute pas la peine d'aller plus loin. Un peu plus subtil, on teste le même résolveur en TCP.

Après, on passe à EDNS (RFC 6891), qui est indispensable pour DNSSEC. Une requête pour ce même nom, mais avec une option EDNS, doit passer. Si EDNS ne marche pas, on peut arrêter, DNSSEC ne marchera pas non plus. Mais s'il marche ? On teste alors avec le bit DO (DNSSEC OK) qui indique au serveur qu'il doit envoyer les données DNSSEC, notamment les signatures. La réponse doit inclure ce même bit DO. (C'est plus tard qu'on teste qu'on a bien reçu des signatures. Rappelez-vous que la plupart des middleboxes sont horriblement boguées. Certaines acceptent le bit DO et le renvoient, sans pour autant transmettre les signatures.)

On teste alors des zones qu'on sait signées et on regarde si le résolveur met le bit AD (Authentic Data), au moins pour les algoritmes RSA + SHA-1 et RSA + SHA-256. Si cela ne marche pas, ce n'est pas forcément une erreur fatale, puisque, de toute façon, on voulait faire la validation nous-même. Il faut aussi penser à faire le test inverse : un résolveur validant doit mettre le bit AD pour une réponse signée correctement, et doit répondre avec le code de retour SERVFAIL (Server Failure) si la réponse devrait être signée mais ne l'est pas, ou bien l'est mal. Cela se fait en testant badsign-a.test.dnssec-tools.org.

Dans les enregistrements DNSSEC, il n'y a pas que les signatures (RRSIG), il y a aussi les enregistrements servant à prouver la non-existence, NSEC et NSEC3. Il faut donc également tester qu'ils sont reçus car, en pratique, on voit en effet des middleboxes qui laissent passer les RRSIG mais bloquent stupidement les NSEC et les NSEC3. On demande donc non-existent.test.dnsssec-tools.org, et on doit récupérer non seulement une réponse avec le code NXDOMAIN (No Such Domain) mais également les NSEC ou NSEC3 permettant de valider cette réponse :


% dig AAAA non-existent.test.dnsssec-tools.org
[...]
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40218
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1
[...]
;; AUTHORITY SECTION:
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 900 IN NSEC3 1 1 1 D399EAAB (
				H9PARR669T6U8O1GSG9E1LMITK4DEM0T
				NS SOA RRSIG DNSKEY NSEC3PARAM )
iruevfos0vs8jssfj22me5p458p0qj1e.org. 900 IN RRSIG NSEC3 7 2 86400 (
				20161222153046 20161201143046 3947 org.
				kgCZC/gE4ySP7eZUb1+2ORYRhTrvL5YBIHLCBK5F8pqK
				MXGJXJ/hX+8LLrg4jHJaER2AelUgUGywRn4uY80ajYpg
				eTuSGzRX1aVCKAR8UB80bX/YLUPUPKWOdfgxTekD4nZk
				eoi/9JNmIMZRc0cmMGp8LSVMqX98F2bVJnZro8U= )
iruevfos0vs8jssfj22me5p458p0qj1e.org. 900 IN NSEC3 1 1 1 D399EAAB (
				IRVVBMC65HCBCFQNQS8NQFTAB943LCFU
				NS DS RRSIG )
vaittv1g2ies9s3920soaumh73klnhs5.org. 900 IN RRSIG NSEC3 7 2 86400 (
				20161222153046 20161201143046 3947 org.
				Nj/zvU0GB8vQ7bFfpSSWW+inE7RiOFjOpNc1K/TMnQqG
				QsKTLD9gBM8vgh3K1WdPXOCzthf/isDJAy2xLA/oRFFq
				KZ+Coo+33FManVmuyndGJ5bdgQqnpa0xGP7yOgjTfUsh
				Ff9HkX0mkzqYtWYzw0J7WnMPcOjmrlg26WsfwlU= )
vaittv1g2ies9s3920soaumh73klnhs5.org. 900 IN NSEC3 1 1 1 D399EAAB (
				VAJB898DELVT5UJ4I9D1BRD2FRTBSCM1
				NS DS RRSIG )

    

Certains serveurs DNS (ou, plus exactement, certains ensembles serveur+réseau+middlebox) n'acceptent que certains types d'enregistrement DNS (les plus connus, comme A, AAAA, MX, parfois SRV, etc). Il faut donc tester que le serveur accepte bien tous les types d'enregistrement,

Jusqu'à présent, on n'a testé que le résolveur « normal ». Même s'il ne valide pas, tant qu'il transmet fidèlement toutes les données DNS, on pourra au moins l'utiliser comme relais et cache. Par contre, dans certains cas, si on veut valider avec DNSSEC, il faudra complètement le court-circuiter. Ainsi, s'il ne transmet pas les signatures, on n'a pas d'autre choix que d'aller les demander à un autre résolveur, ou bien directement aux serveurs faisant autorité. Il faut donc tester qu'on puisse interroger ces serveurs, avec UDP et avec TCP. (Ce n'est pas toujours possible, certains réseaux violent tellement la neutralité de l'Internet qu'ils bloquent le port 53, celui du DNS.)

Avec DNSSEC, les réponses sont souvent de grande taille, et parfois fragmentées. Il faut donc tester que les fragments passent (ils sont souvent bloqués par des administrateurs réseau incompétents).

Une fois ces tests faits, il reste à synthétiser les résultats (section 4). L'idée est de pouvoir dire si le résolveur « normal » est :

  • Un validateur (on peut alors tout lui déléguer, en tout cas si on a confiance en lui),
  • Un résolveur DNSSEC (même s'il ne valide pas, il passe bien tous les enregistrements DNSSEC),
  • Une horreur à fuir.

En pratique, tous les résolveurs (ou plutôt l'ensemble du résolveur et du réseau situé devant, avec ses middleboxes qui cassent tout) ne rentrent pas parfaitement dans une de ces trois catégories. Ainsi, certains vont bloquer les fragments mais accepter TCP (ce qui permettra de quand même faire passer les données de grande taille), tandis que d'autres n'auront pas TCP mais qu'UDP fonctionnera bien, même en cas de fragmentation.

Une fois ces données collectées, et le résolveur correctement classé, on pourra alors déterminer comment contourner les éventuels problèmes (section 5 du RFC). Par exemple :

  • Si le résolveur officiel est un validateur ou bien un résolveur DNSSEC, on l'utilise comme forwarder pour transmettre les requêtes, profitant ainsi de son cache et réduisant la charge sur les serveurs faisant autorité.
  • Si le résolveur officiel est une horreur, mais que les requêtes DNS vers l'extérieur marchent, alors, ne pas faire appel au résolveur officiel et parler directement aux serveurs faisant autorité.
  • Si le résolveur officiel est une horreur, et que les requêtes DNS vers l'extérieur sont bloquées, tenter de joindre un résolveur extérieur de confiance, en utilisant DNS sur TLS (RFC 7858), ce que fait dnssec-trigger (dans son fichier de configuration, des lignes comme tcp80: 185.49.140.67 ou ssl443: 185.49.140.67 ...).
  • Sinon, si rien ne marche, laisser tomber, prévenir l'utilisateur et pleurer.

La section 6 du RFC sert de voiture-balai, en mentionnant les cas spéciaux qui peuvent être embêtants. Par exemple, DNSSEC dépend de l'horloge, puisqu'il faut vérifier que les signatures n'ont pas expiré. Mais la synchronisation de l'horloge dépend de NTP donc parfois du DNS si on a mis des noms de domaine dans son ntp.conf. Si la machine a une horloge assez stable pour garder l'heure entre un arrêt et un démarrage, ce n'est pas trop grave. Mais si la machine est un engin bon marché avec une horloge qui dévie beaucoup (genre le Raspberry Pi), que faire ?

Autre problème, les affreux portails captifs. Tant qu'on n'a pas cliqué sur « j'accepte cinquante pages de conditions d'utilisation que je n'ai pas lues, je veux recevoir du spam, et je promets de ne pas partager de la culture », on n'a pas un vrai accès Internet et le port 53 est sans doute bloqué. Il faudrait donc refaire les tests après le passage par le portail captif.

Face à ce genre de problèmes, une première solution est de ne pas tenter de faire du DNSSEC tant qu'on n'a pas synchronisé l'horloge, passé le portail captif (c'est ce que fait dnssec-trigger), au détriment de la sécurité. Au moins, on peut prévenir l'utilisateur et lui proposer de réessayer plus tard.


Téléchargez le RFC 8027


L'article seul

RFC 7970: The Incident Object Description Exchange Format Version 2

Date de publication du RFC : Novembre 2016
Auteur(s) du RFC : R. Danyliw (CERT)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF mile
Première rédaction de cet article le 1 décembre 2016


Pour rendre plus facilement analysables les innombrables rapports d'incidents de sécurité qui circulent sur Internet tous les jours, ce RFC spécifie un format standard XML, nommé IODEF, pour décrire ces incidents. Ici, il s'agit de la version 2 de ce format IODEF, la version 1 était dans le RFC 5070.

Tous les jours, des organisations comme les CERT et CSIRT, mais aussi les OIV, envoient et reçoivent des rapports détaillés concernant une attaque sur un réseau informatique ou un serveur. Ces rapports sont longs et détaillés mais, la plupart du temps, ce n'est pas une attaque isolée qui est intéressante, c'est l'image qui apparait lorsqu'on synthétise tous les rapports, et qu'on voit alors les tendances, par exemple l'arrivée d'un nouveau ver ou bien une attaque concertée contre un pays donné. D'où l'importance de pouvoir analyser automatiquement ces rapports, ce qui impose un modèle de données et un format standard, ce que fournit ce RFC.

Le modèle de données est proche des modèles objet, par exemple dans la descriptions des classes d'objets manipulés (comme la classe Incident en section 3.2, avec la cardinalité des attributs). Ces classes sont composés avec des données élémentaires (booléens, entiers, dates) décrites dans la section 2. Par exemple, parmi les attributs de la classe Incident, on trouve l'heure de début et de fin de l'incident, l'heure de détection, etc. Le schéma XML complet, écrit en W3C Schema, figure dans la section 8.

On trouve énormément de choses dans ce schéma (le RFC fait plus de 160 pages), pour traiter tous les cas prévus. Par exemple, on peut exprimer une liste de ports comprenant à la fois des ports individuels et des intervalles : 22,53,80,1024-2047. De nombreuses classes existent pour utiliser ces informations élémentaires. Ainsi, la classe Discovery, une nouveauté de la version 2, permet d'indiquer comment l'incident a été découvert (avec un attribut source qui a vingt valeurs possibles, comme avantivirus, os-logjournal, passive-dns - un système comme DNSdb, etc). Et BusinessImpact permet de décrire les conséquences de l'incident sur l'activité (breach-privacy, loss-of-service, theft-financial, etc). Ça peut même se quantifier financièrement avec la classe MonetaryImpact. Si on met les incidents de sécurité dans une base de données (ça s'appelle un SIEM, comme Prelude), on peut donc imaginer de regarder d'abord les incidents qui ont coûté le plus cher...

Voici un exemple d'un rapport d'incident, tiré du RFC (section 7), et qui décrit et qui décrit les systèmes de C&C (quatre serveurs) d'une campagne donnée (dans le RFC 5070, l'exemple était une simple reconnaissance avec nmap...). Cet exemple a l'avantage d'illustrer la classe IndicatorData, une nouveauté de la version 2 :


   <?xml version="1.0" encoding="UTF-8"?>
   <!-- A list of C2 domains associated with a campaign -->
   <IODEF-Document version="2.00" xml:lang="en"
      xmlns="urn:ietf:params:xml:ns:iodef-2.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation=
      "http://www.iana.org/assignments/xml-registry/schema/
       iodef-2.0.xsd">
     <Incident purpose="watch" restriction="green">
       <IncidentID name="csirt.example.com">897923</IncidentID>
         <RelatedActivity>
           <ThreatActor>
             <ThreatActorID>
             TA-12-AGGRESSIVE-BUTTERFLY
             </ThreatActorID>
             <Description>Aggressive Butterfly</Description>
           </ThreatActor>
           <Campaign>
             <CampaignID>C-2015-59405</CampaignID>
             <Description>Orange Giraffe</Description>
           </Campaign>
         </RelatedActivity>
         <GenerationTime>2015-10-02T11:18:00-05:00</GenerationTime>
         <Description>Summarizes the Indicators of Compromise
           for the Orange Giraffe campaign of the Aggressive
           Butterfly crime gang.
         </Description>
         <Assessment>
           <BusinessImpact type="breach-proprietary"/>
         </Assessment>
         <Contact type="organization" role="creator">
           <ContactName>CSIRT for example.com</ContactName>
           <Email>
             <EmailTo>contact@csirt.example.com</EmailTo>
           </Email>
         </Contact>
         <IndicatorData>
           <Indicator>
             <IndicatorID name="csirt.example.com" version="1">
             G90823490
             </IndicatorID>
             <Description>C2 domains</Description>
             <StartTime>2014-12-02T11:18:00-05:00</StartTime>
             <Observable>
               <BulkObservable type="fqdn">
               <BulkObservableList>
                 kj290023j09r34.example.com
                 09ijk23jfj0k8.example.net
                 klknjwfjiowjefr923.example.org
                 oimireik79msd.example.org
               </BulkObservableList>
             </BulkObservable>
           </Observable>
         </Indicator>
       </IndicatorData>
     </Incident>
     </IODEF-Document>

Le RFC note sagement que le partage d'informations n'est pas uniquement une question technique, mais qu'elle dépend aussi des procédures bureaucratiques de chaque organisation, des contraintes légales, de la confiance (ou de l'absence de confiance, souvent justifiée) et enfin de la simple bonne ou mauvaise volonté. (Mon opinion personnelle est que, en France, le partage d'informations précises sur les incidents de sécurité est très insuffisant.)

Les changements depuis la version 1 (celle du RFC 5070) sont listés dans la section 1.4. Beaucoup de détails, beaucoup d'ajouts, parmi lesquels je note :

  • Meilleure internationalisation (voir à ce sujet la section 6 du RFC), comme le fait que la classe Contact permette désormais d'indiquer une adresse postale en un jeu de caractères quelconque,
  • Nouvelles classes (comme IndicatorData ou Discovery cités plus haut, ou comme DomainData, pour des informations sur un nom de domaine), et nouveaux attributs dans les classes existantes (par exemple, Incident y gagne observable-id, un identificateur qui peut être utilisé dans des références croisées).

Si l'ajout de nouvelles classes ne rendent pas les anciennes descriptions IODEF incorrectes, en revanche, certains changements cassent la compatibilité et un fichier IODEF version 1 parfait ne sera pas forcément légal pour la version 2 (cf. section 4.4). Par exemple, la sous-classe NodeRole (qui permet de décrire si on est attaqué par une caméra de vidéosurveillance ou bien par un routeur) a changé de classe parente.

Et les mises en œuvre d'IODEF ? Un résumé de l'état de ces mises en œuvre figure dans l'Internet-Draft draft-ietf-mile-implementreport, et qui référence une liste des programmes IODEF (j'ai aussi trouvé celle-ci). Parmi d'autres, on peut noter la bibliothèque de Prelude (et qui a une version pour l'IODEF v2 de notre RFC), un module Perl, un autre en PHP, et un troisième en Python. On trouve aussi des moyens de connecter IODEF à des logiciels existants par exemple au logiciel de suivi de tâche Mantis, avec ce connecteur.

Pour des articles ou présentations sur IODEF, vous pouvez voir la Rump (session rapide) de Thomas Andrejak au SSTIC 2016 (vidéo en ligne).

Notez en France l'existence du projet SECEF (SECurity Exchange Format) qui a pour objectif de promouvoir et de faciliter l’usage des deux formats de fichier IDMEF (RFC 4765) et IODEF. Vous pouvez consulter leur Wiki, et leur tutoriel IODEF. Il y a aussi un article de synthèse sur SECEF, et un compte-rendu d'une de leurs réunions (mais vite fait et avec des erreurs).


Téléchargez le RFC 7970


L'article seul

RFC 8023: Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions

Date de publication du RFC : Novembre 2016
Auteur(s) du RFC : Matthew Thomas, Allison Mankin, Lixia Zhang (UCLA)
Pour information
Première rédaction de cet article le 27 novembre 2016


Ce nouveau RFC est le compte-rendu d'un atelier qui s'était tenu du 8 au 10 mars 2014 à Londres sur le thème des « collisions ». Ce terme exagéré et sensationnaliste désigne le phénomène qui peut se produire quand un acteur de l'Internet a bêtement choisi de se créer un TLD à lui dans le DNS, et que ce TLD est ensuite créé par l'ICANN.

Supposons que l'entreprise Bidon décide de nommer ses ressources internes (site Web réservé aux employés, etc) sous le TLD inexistant .bidon. C'est une mauvaise idée mais elle est fréquente. L'entreprise Bidon compte sur le fait que ses employés utiliseront les résolveurs DNS internes, qui ont été configurés pour reconnaître .bidon. Par exemple, avec Unbound, et un serveur faisant autorité en 2001:db8:666::1:541f, les résolveurs ont été configurés ainsi :

    stub-zone:
     name:   "bidon"
     stub-addr: 2001:db8:666::1:541f
    

Si un employé tente accidentellement d'accéder à une ressource en .bidon, alors qu'il n'utilise pas les résolveurs de la boîte, la requête filera vers la racine du DNS, qui répondra NXDOMAIN (No Such Domain). C'est ainsi que la racine voit souvent des requêtes pour des noms se terminant en .local, .home ou .belkin. Si, quelques années après, l'ICANN délègue effectivement ce TLD à une autre organisation, ces requêtes à la racine donneront désormais un vrai résultat. Au lieu d'un message d'erreur, le malheureux employé sera peut-être redirigé vers un autre site Web que celui attendu. C'est ce phénomène que Verisign avait baptisé « collision » (name collision), terme conçu pour faire peur.

C'est dans ce contexte qu'il y a plus de deux ans s'était tenu le « Workshop on Root Causes and Mitigation of Name Collisions », dont ce RFC est le compte-rendu tardif. Le premier rapport de l'ICANN qui mentionnait ce phénomène était le SAC 045 en 2010. Il pointait le risque que la délégation effective d'un nouveau TLD change la réponse obtenue, pour les clients mal configurés (qui interrogeaient à tort un résolveur extérieur, et donc la racine, au lieu de leurs résolveurs internes).

L'ICANN a même créé une page Web dédiée à cette question, dont la source réelle est le recouvrement de deux espaces de noms, l'interne et l'externe. La bonne pratique idéale serait de ne pas utiliser de noms qui n'existent pas ou, pire, qui existent avec une autre signification dans l'arbre public des noms de domaine (et, là, relire le RFC 2826 peut aider). Pour reprendre l'exemple de l'entreprise Bidon, si elle est titulaire de bidon.fr, elle devrait nommer ses ressources internes avec des noms se terminant en privé.bidon.fr ou interne.bidon.fr. Si on ne veut pas faire les choses proprement, et qu'on utilise quand même le TLD inexistant .bidon, alors il faut veiller très soigneusement à séparer les deux espaces de nommage et à éviter qu'ils ne se rencontrent un jour (ce qui est difficile à l'ère des mobiles, avec des appareils qui rentrent et qui sortent du réseau de l'entreprise). Sinon, on verra ces fameuses collisions.

En pratique, pas mal d'administrateurs système surestiment leurs compétences et croient qu'ils vont réussir à empêcher toute fuite vers le DNS public. C'est ce qui explique une partie des requêtes pour des noms inexistants que reçoit la racine (ces noms inexistants forment la majorité du trafic des serveurs racine du DNS). Un des problèmes de fond de l'Internet est en effet que l'administrateur de base ne se tient pas au courant et n'est pas informé des problèmes du monde extérieur. « Après moi, le déluge »

Autrefois, le problème était surtout théorique. Le nombre de TLD n'avait pas bougé depuis de très nombreuses années, et personne ne pensait que des TLD comme .pizza ou .green verraient le jour. Mais, en 2012, l'ICANN a lancé officiellement son programme d'ajout d'un grand nombre de TLD, et le risque est soudain devenu une question pratique. D'où l'atelier de 2014.

La section 2 du RFC revient en détail sur l'arrière-plan de ce problème de collision. Outre le rapport SAC 045 cité plus haut, il y avait eu une déclaration de l'IAB, puis un autre rapport du SSAC (Security and Stability Advisory Committee, un comité de l'ICANN), le SAC 046, une déclaration du RSSAC et plein d'autres textes sur les conséquences d'un agrandissement important de la zone racine. Par exemple, le rapport SAC 057 faisait remarquer que les AC attribuaient souvent des certificats pour des noms de domaine dans des TLD purement locaux. Cela montrait le déploiement de ces TLD privés et cela inquiétait. Si la société Bidon exploite .bidon et obtient d'une AC un certificat pour www.compta.bidon, après la délégation de ce même TLD dans la racine publique, ce certificat pourrait être utilisé pour usurper l'identité d'un autre serveur.

J'ai parlé plus haut des fuites vers le DNS public. Quelle est leur ampleur exacte ? Ce n'est pas si évident que cela de le savoir. Contrairement à un raccourci journalistique fréquent, l'ICANN ne gère pas la racine. Chaque opérateur d'un serveur DNS racine se débrouille indépendamment, supervise son serveur mais ne rend pas forcément compte à d'autres acteurs ou au public. En pratique, les opérateurs des serveurs racine ont un niveau d'ouverture très variable. (Cf. l'analyse de l'ICANN à ce sujet.) Un des moments où plusieurs opérateurs de serveurs racine collectent en même temps de l'information est le Day in the Life of the Internet et c'est sur la base de ces données qu'a été fait le rapport d'Interisle « Name Collision in the DNS ». Entre autres, ce rapport classait les futurs TLD selon qu'ils présentaient un risque de collision élevé ou faible (.home, .corp et .site se retrouvaient en tête du classement). L'ICANN a alors publié un plan pour gérer ce risque de collisions, notant que .home et .corp étaient de loin les plus « risqués », car ils sont fréquemment utilisés comme TLD locaux. Bien d'autres documents ont été publiés par l'ICANN, qui a une productivité extraordinaire lorsqu'il s'agit de faire de la paperasse. Le dernier mettait en place le système dit de « controlled interruption » qui, en gros, impose à tous les nouveaux TLD de résoudre, pendant les premiers temps de leur délégation, tous les noms de domaine vers l'adresse IP 127.0.53.53. Voici l'exemple de .box en novembre 2016 (ce cas avait fait l'objet d'un article de Heise en allemand, car le routeur Fritz!Box, très populaire en Allemagne, utilisait ce TLD) :



% dig ANY box.

; <<>> DiG 9.10.3-P4-Debian <<>> ANY box.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14573
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 24, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;box.			IN ANY

;; ANSWER SECTION:
box.			3600 IN	A 127.0.53.53
box.			3600 IN	SRV 10 10 0 your-dns-needs-immediate-attention.box.
box.			3600 IN	TXT "Your DNS configuration needs immediate attention see https://icann.org/namecollision"
box.			3600 IN	MX 10 your-dns-needs-immediate-attention.box.
box.			900 IN SOA a.nic.box. support.ariservices.com. (
				1478481375 ; serial
				1800       ; refresh (30 minutes)
				300        ; retry (5 minutes)
				1814400    ; expire (3 weeks)
				1800       ; minimum (30 minutes)
				)
box.			172800 IN NS b.nic.box.
box.			172800 IN NS d.nic.box.
box.			172800 IN NS c.nic.box.
box.			172800 IN NS a.nic.box.
[...]
;; Query time: 89 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 21 17:23:17 CET 2016
;; MSG SIZE  rcvd: 2938



    

Ces enregistrements ont pour but d'attirer l'attention des utilisateurs sur le risque de collision. Le TLD étant récent et pas encore peuplé, il ne devrait pas y avoir de requêtes DNS. S'il y en a quand même, c'est peut-être le résultat d'une collision avec un usage local. L'adresse IP 127.0.53.53 est une adresse locale à la machine. Si M. Michu tente de se connecter à http://quelquechose.box/ aujourd'hui, il sera redirigé vers la machine locale. Il verra une erreur (pas de serveur HTTP qui écoute) ou bien la page Web par défaut de sa machine (avec un message peu informatif comme « It works ») s'il y a un serveur HTTP. Si l'utilisateur regarde les enregistrements SRV, MX ou TXT, ou bien si un administrateur système regarde les requêtes DNS qui passent, ou bien les journaux du serveur de messagerie, peut-être comprendra-t-il qu'il doit agir. (Je trouve personnellement que la probabilité que cela arrive est assez faible.)

L'atelier lui-même, financé par Verisign (l'entreprise qui avait le plus crié « au loup » sur les name collisions), s'est donc tenu du 8 au 10 mars à Londres. Un site Web avait été mis en place pour cet atelier, et il contient les supports et les vidéos.

Je ne vais pas décrire tous les exposés de l'atelier, la liste complète figure dans l'annexe C du RFC, et les supports sont en ligne. Le RFC note qu'il y a eu plusieurs interventions sur la qualité des données du DITL (Day in the Life of the Internet) : il est trivial de les polluer (le DITL est annoncé publiquement, et à l'avance) par des requêtes artificielles. Aucune preuve n'a été trouvée d'une manipulation délibérée. De toute façon, les données montrent surtout qu'il y a beaucoup de n'importe quoi dans le trafic que reçoivent les serveurs racine (par exemple des requêtes avec le bit RD - Recursion Desired - alors que les serveurs de la racine ne sont pas récursifs). Cela peut être le résultat de bogues dans les résolveurs, de tests ou bien d'attaques délibérées.

La question de l'éducation des utilisateurs est revenue plusieurs fois. Faut-il s'inspirer du téléphone ou du système postal, qui ont tous les deux connu des changements qui nécessitaient une adaptation de l'utilisateur, qui s'est faite par le biais d'importantes campagnes de sensibilisation et d'éducation ?

Le comité de programme avait conclu que le sujet était loin d'être épuisé. Manque de données, manque de théories explicatives, manque d'intérêt pour la question, en tout cas, celle-ci restait largement ouverte après l'atelier (et je ne suis personnellement pas sûr que cela soit mieux aujourd'hui, plus de deux ans après l'atelier de Londres).


Téléchargez le RFC 8023


L'article seul

RFC 8005: Host Identity Protocol (HIP) Domain Name System (DNS) Extensions

Date de publication du RFC : Octobre 2016
Auteur(s) du RFC : J. Laganier (Luminate Wireless)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF hip
Première rédaction de cet article le 26 novembre 2016


Le protocole HIP n'avait pas à l'origine de mécanisme pour trouver l'identificateur d'une machine distante. Cela avait été fait dans le RFC 5205, qui permettait de trouver l'identificateur dans le DNS. Ce nouveau RFC remplace le RFC 5205.

HIP fait partie de la famille des protocoles qui visent à séparer l'identificateur du localisateur. Les identificateurs HIP se nomment les HI (Host Identifier) et, autrefois, le seul moyen de trouver l'HI d'une autre machine était d'attendre qu'elle vous contacte, ou bien de le configurer manuellement. Avec ce RFC, on peut trouver l'HI, comme une adresse IP, dans le DNS.

Notre RFC crée donc un nouveau type d'enregistrement DNS, nommé logiquement HIP (numéro 55), qui stocke, en échange d'un nom de domaine, le HI, son condensat (résumé) cryptographique - le HIT (Host Identifier Tag) - et les éventuels serveurs de rendez-vous, serveurs qui, dans le protocole HIP, servent d'intermédiaires facultatifs lorsqu'on veut contacter une machine distante (cf. RFC 8004).

Notre RFC permet de trouver l'identificateur à partir du nom mais pas le localisateur ; les serveurs de rendez-vous sont une solution possible pour cela ; une autre est d'utiliser les traditionnels enregistrements A et AAAA du DNS, le localisateur HIP étant une adresse IP.

Les localisateurs peuvent changer fréquemment alors que le DNS n'est pas temps-réel et ne change pas instantanément. Si un hôte HIP veut pouvoir être contacté malgré des changements d'adresse IP rapides, il vaut peut-être mieux qu'il utilise le système de rendez-vous du RFC 8004.

Curieusement (pour moi), le HIT est donc stocké dans les données DNS, alors que celles-ci n'offrent aucune sécurité au point que le RFC exige en section 4.1 de recalculer le HIT qui vient d'être obtenu dans le DNS.

Le tout ressemble donc aux enregistrements IPSECKEY du RFC 4025, ce qui est normal, le HI étant une clé cryptographique publique.

Voici un exemple d'enregistrement HIP tel qu'il apparaitrait dans un fichier de zone (sections 5 et 6 de notre RFC). On y trouve l'algorithme cryptographique utilisé (2 = RSA), le HIT (en hexadécimal), le HI (encodé en Base64) et les éventuels serveurs de rendez-vous (ici, deux, indiqués à la fin) :

www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
                                9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
                                b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
                                rvs1.example.com.
                                rvs2.example.com. )

Par contre, je n'ai pas réussi à trouver encore ce genre d'enregistrement dans la nature.

L'ensemble du RFC est assez court, ce mécanisme d'annuaire qu'est le DNS étant simple et bien connu.

Quels sont les changements depuis le premier RFC, le RFC 5205 ? Évidement le passage sur le chemin des normes, faisant de HIP une norme complète. Mais aussi l'ajout de l'algorithme de cryptographie asymétrique ECDSA, et plusieurs clarifications du RFC original sur le format des enregistrements DNS, aussi bien leur format sur le réseau que dans le fichier de zone.


Téléchargez le RFC 8005


L'article seul

RFC 8004: Host Identity Protocol (HIP) Rendezvous Extension

Date de publication du RFC : Octobre 2016
Auteur(s) du RFC : J. Laganier (Luminate Wireless,), L. Eggert (NetApp)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF hip
Première rédaction de cet article le 26 novembre 2016


HIP, par défaut, nécessite que l'initiateur d'une association connaisse le localisateur, l'adresse IP du répondeur. Si celui-ci bouge souvent, et qu'il n'est donc pas pratique de mettre cette adresse dans le DNS, une solution est d'utiliser le mécanisme de rendez-vous, décrit par ce RFC, où l'initiateur contacte un serveur de rendez-vous qui relaie vers le répondeur.

Le schéma est clairement expliqué dans la section 3 du RFC. En fonctionnement habituel de HIP, l'initiateur trouve l'identificateur et le localisateur du répondeur (typiquement, dans le DNS, cf. RFC 8005), puis le contacte directement. Si le localisateur n'est pas connu (ce qui est fréquent si le répondeur est un engin mobile, changeant souvent d'adresse IP), l'initiateur envoie le premier paquet (I1) au serveur de rendez-vous, qui le relaie au répondeur. Les autres paquets (R1, I2 et R2) seront transmis directement entre les deux machines HIP. Le mécanisme est détaillé dans la section 3.3 (il faut notamment procéder avec soin à la réécriture des adresses IP, en raison entre autre du RFC 2827).

Et comment l'initiateur trouve-t-il le serveur de rendez-vous ? En général dans le DNS, via les enregistrements de type HIP. Et comment le répondeur avait-il fait connaitre au serveur de rendez-vous son adresse IP ? Via le protocole d'enregistrement du RFC 8003, comme l'explique la section 4.

Comme toute indirection, le système de rendez-vous ouvre des problèmes de sécurité amusants. Si l'initiateur connaissait déjà l'identificateur du répondeur (donc sa clé publiqué), pas de problème, le passage par le serveur de rendez-vous ne diminue pas la sécurité. Si ce n'est pas le cas, alors, il n'y a rien à faire, l'initiateur n'a aucun moyen de vérifier l'identité du répondeur (section 5 du RFC).

Aucun changement depuis la première spécification, le RFC 5204, juste l'alignement avec la nouvelle version de HIP, celle du RFC 7401, désormais norme complète (et pas juste « expérimentale »).


Téléchargez le RFC 8004


L'article seul

RFC 8003: Host Identity Protocol (HIP) Registration Extension

Date de publication du RFC : Octobre 2016
Auteur(s) du RFC : J. Laganier (Luminate Wireless), L. Eggert (NetApp)
Chemin des normes
Première rédaction de cet article le 26 novembre 2016


Le protocole HIP, décrit dans le RFC 7401 est très bien adapté au cas où l'adresse IP (le localisateur) change après l'établissement d'une association. Mais cela laisse ouvert le grand problème de la connexion initiale. Comment trouver une machine HIP ? Par le mécanisme de rendez-vous du RFC 8004 ? C'est certainement une bonne solution mais, alors, comment les machines HIP sont-elles connues du serveur de rendez-vous ? C'est là que notre RFC rentre en jeu pour normaliser un mécanisme d'enregistrement auprès d'un service. C'est un mécanisme générique, qui peut servir à d'autres choses que le rendez-vous, d'ailleurs. (Il était à l'origine spécifié dans le RFC 5203, que notre RFC remplace.)

Le mécanisme est très simple et le RFC court. On réutilise simplement les établissements d'associations de HIP, avec de nouveaux types de paramètres, notamment REG_INFO (pour l'hôte qui accepte d'être registrar, c'est-à-dire d'enregistrer) et REG_REQUEST (pour celui qui demande un enregistrement). Le mécanisme exact est détaillé dans la section 3 et les nouveaux paramètres dans la section 4.

HIP authentifiant les deux parties bien plus solidement que IP seul, le registrar (terme d'ailleurs mal choisi, on risque de confondre avec les bureaux d'enregistrement de noms de domaine) peut alors décider s'il accepte l'enregistrement ou pas (sections 3.3 et 6).

Le rendez-vous, normalisé dans le RFC 8004 est donc une simple application de notre RFC mais d'autres pourront apparaître à l'avenir (comme celle du RFC 5770).

Quels sont les changements depuis le premier RFC, le RFC 5203 ? La principale est qu'HIP, qui avait le statut « Expérimental » est désormais sur le chemin des Normes et que les références de notre RFC ont donc changé (nouveau protocole HIP en RFC 7401). Mais ce nouveau RFC ajoute aussi la possibilité d'authentifier le registrar par certificat (RFC 8002), ainsi qu'un nouveau type d'erreur, le numéro 2, « ressources insuffisantes chez le registrar ».

Question mise en œuvre, je n'ai pas vérifié mais, normalement, HIP for Linux et OpenHIP devraient s'adapter aux nouveaux RFC HIP.


Téléchargez le RFC 8003


L'article seul

RFC 7971: Application-Layer Traffic Optimization (ALTO) Deployment Considerations

Date de publication du RFC : Octobre 2016
Auteur(s) du RFC : M. Stiemerling (Hochschule Darmstadt, S. Kiesel (University of Stuttgart), M. Scharf (Nokia), H. Seidel (BENOCS), S. Previdi (Cisco)
Pour information
Réalisé dans le cadre du groupe de travail IETF alto
Première rédaction de cet article le 22 novembre 2016


Il est fréquent aujourd'hui sur l'Internet qu'une application cherche à accéder à un contenu (mettons un film, ou bien la mise à jour d'un gros logiciel) qui est disponible à plusieurs endroits. Dans ce cas (qui est notamment fréquent pour le téléchargement en pair-à-pair), quelle source utiliser ? La « meilleure », bien sûr, mais comment la connaître ? Le but du protocole ALTO est de permettre de distribuer de l'information sur la topologie du réseau, afin que les applications puissent choisir la source la plus proche d'elles. ALTO est déjà normalisé (RFC 7285), ce nouveau RFC sert juste à décrire les scénarios d'usage et à donner des conseils pratiques de déploiement (déploiement qui semble très limité pour l'instant).

Outre le RFC décrivant le protocole (RFC 7285), il peut être utile de lire la description du problème qu'ALTO veut résoudre, le RFC 5693, et le cahier des charges, dans le RFC 6708.

La section 2 de notre RFC résume le fonctionnement d'ALTO. C'est un protocole client-serveur, le serveur ALTO connait l'information (la topologie du réseau, qui est connecté à qui, par quel genre de liens), le client est l'application qui veut accéder au contenu, il connait un ensemble potentiel de sources, et il veut savoir quelle est la « meilleure ». Par exemple, dans le cas de BitTorrent, le client a les adresses IP de l'essaim, il veut savoir à laquelle ou lesquelles demander les bouts de fichier (chunks) qui forment le contenu. Le client ALTO peut être un processus séparé, tournant en permanence, ou bien une bibliothèque liée à l'application. Il doit évidemment parler le protocole ALTO, donc connaitre HTTP et JSON.

Pour déployer ALTO, il y a donc quatre entités logiques à considérer :

  • L'origine de l'information (celle qui a compilé les informations de topologie, par exemple en commençant par lister les préfixes IP connus),
  • Le serveur ALTO, qui va distribuer cette information,
  • Le client ALTO, qui va la récupérer,
  • L'application (resource consumer, dans le RFC), qui va en faire quelque chose d'utile.

Ces entités sont typiquement gérées par des organisations différentes. Un exemple typique (mais ce n'est pas la seule possibilité) est que le FAI soit à l'origine de l'information (il connait son réseau), et la mette dans un serveur ALTO qu'il gère, ses abonnés ayant installé une application de partage de fichiers qui inclut un client ALTO. Dans ce cas, il y aurait deux organisations, le FAI gérant les deux premières entités et l'abonné les deux dernières. Mais d'autres répartitions peuvent exister.

Les organisations qui peuvent être impliquées sont en effet multiples : FAI et opérateurs réseau, bien sûr, utilisateurs, évidemment (agissant, soit seuls, soit en groupes se répartissant le travail), mais aussi des tiers, spécialisés dans la collecte et la distribution de cette information (par exemple des CDN). On pourrait même voir apparaitre des sociétés qui ne font que de l'ALTO.

Tout ceci a des conséquences sur le déploiement. Par exemple, un utilisateur peut faire confiance à un FAI mais pas à des tiers. Un FAI peut souhaiter distribuer de l'information à ses abonnés mais pas à tout l'Internet. ALTO définit un protocole, pas une politique : ce protocole permet différents modèles, y compris celui de serveurs ALTO spécialisés et payants. Autre conséquence de l'utilisation de telle ou telle répartition du travail, on pourrait avoir des serveurs ALTO partiels, qui ne contiennent de l'information que sur certains réseaux.

Dans tous les cas, le RFC rappelle qu'ALTO est juste une optimisation : une application doit fonctionner même si elle ne trouve aucun serveur ALTO, ou bien s'ils sont en panne.

Un petit rappel utile sur ALTO : il existe deux modes de fonctionnement différents, qui ont tous les deux des conséquences importantes, notamment sur la confidentialité. Dans le premier mode, le serveur ALTO fournit l'information qu'il a (sous forme de maps, des ensembles de données sur le réseaux, les liens, leur coût, etc) et le client cherche dedans ce qui l'intéresse. Ce mode préserve la vie privée du client (qui ne dit pas au serveur ce qui l'intéresse) mais pas celle du serveur (qui doit tout envoyer). Il n'est pas évident que beaucoup de FAI acceptent cela. Dans le second mode, le serveur permet des interrogations sur un point particulier (« qui est le plus proche de moi ? 192.0.2.87, 203.0.113.122 ou bien 198.51.100.20 ? »). Ce mode évite au serveur de tout divulguer mais oblige en revanche le client à révéler ses intentions (ici, les adresses IP des pairs potentiels, ce qui peut intéresser des organisations répressives comme la HADOPI). Notez que la fuite d'informations du serveur existe aussi dans le second mode : plusieurs clients ALTO peuvent coopérer pour poser beaucoup de questions et extraire ainsi une partie substantive de la base.

La partie 3 de notre RFC en vient aux conseils concrets pour les FAI. On considère que l'objectif du FAI est de minimiser ses coûts, donc a priori de garder le maximum de trafic en local (il y a des exceptions, que liste le RFC). Le serveur ALTO que gère le FAI va donc annoncer des coûts plus faibles pour les liens locaux.

Mais, d'abord, le FAI doit « remplir » le serveur ALTO avec de l'information. Cette étape d'avitaillement commence par la récolte d'informations sur le réseau. A priori, le FAI connait son propre réseau, et n'a donc pas de mal à récolter ces informations. Outre sa propre documentation interne, le FAI peut aussi utiliser de l'information issue d'autres sources, par exemple les protocoles de routage comme BGP (cf., entre autres, le RFC 7752) ou bien des mesures actives ou passives (cf. entre autres, le RFC 7491). Rappelez-vous qu'ALTO est uniquement un protocole permettant d'accéder à de l'information sur la topologie. Comment cette information a été récoltée et agrégée n'est pas de la responsabilité d'ALTO, de même que le protocole HTTP ne se soucie pas de comment est fabriquée la page HTML qu'il sert.

Le FAI doit ensuite appliquer ses critères (coût, performance, etc) à la topologie. Ces critères sont forcément imparfaits. Le client ALTO ne doit pas s'attendre à ce que l'information qui lui est donnée soit idéale dans tous les cas. Par exemple, le serveur ALTO peut indiquer un lien rapide et pas cher mais qui, au moment où le téléchargement commencera, sera saturé par un trafic intense (ALTO ne prétend pas être temps-réel). Et il y a bien d'autres choses qui ne seront pas connues de ceux qui ont compilé l'information, ou bien qui n'auront pas été incluses dans la base de données du serveur ALTO (« la carte n'est pas le territoire »). Les données distribuées par ALTO, les maps, sont supposées être relativement statiques. Mais, dans le monde réel, les choses changent et le client recevra donc peut-être une information légèrement dépassée.

Si vous trouvez le concept de map un peu abstrait, la section 3.5 du RFC donne plusieurs exemples. Par exemple, dans le cas le plus simple, celui d'un petit FAI ayant un seul opérateur de transit, les adresses dudit FAI seront dans le PID (Provider-defined IDentifier, cf. RFC 7285, section 5.1) 1, tout le reste de l'Internet étant le PID 2. Cela donnera une map (syntaxe décrite dans le RFC 7285, section 9.2) :

       {
       ...
        "network-map" : {
          "PID1" : {
            "ipv4" : [
              "192.0.2.0/24",
              "198.51.100.0/25"
            ],
            "ipv6" : [
              "2001:db8:100::/48"
            ]
          },
          "PID2" : {
            "ipv4" : [
              "0.0.0.0/0"
            ],
            "ipv6" : [
              "::/0"
            ]
          }
        }
      }

Un FAI plus gros, et à la topologie plus complexe, a plein de possibilités. Par exemple, ses propres réseaux peuvent être dans des PID différents, s'il veut pouvoir garder le trafic local à un de ses réseaux. Un exemple est celui où le même FAI a des abonnés fixes et mobiles, et où on souhaite limiter les transferts des abonnés fixes vers les mobiles, pour réduire l'utilisation des liens hertziens.

Reste ensuite à effectuer le déploiement des serveurs ALTO. Il existe plusieurs mises en œuvre logicielles d'ALTO et des compte-rendus d'expérience figurent dans les Internet-Drafts draft-seidel-alto-map-calculation et draft-lee-alto-chinatelecom-trial et dans le RFC 6875 (ainsi que, pour un protocole antérieur à ALTO, dans le RFC 5632). Cette expérience montre que certaines façons de collecter l'information peuvent être coûteuses : si un FAI a plusieurs liens avec l'Internet, et reçoit un flux BGP complet, et veut mettre chaque préfixe de la DFZ dans ses maps, il doit prévoir des machines assez costaud pour traiter cette information importante et assez changeante. Et le résultat serait une map qu'il serait difficile d'envoyer à tous les clients, vu sa taille. Il faut donc prévoir, dans ce cas extrême, de l'agrégation vigoureuse des préfixes IP.

La section 4 de notre RFC couvre ensuite l'utilisation d'ALTO, une fois qu'il est déployé. Normalement, tout le monde a intérêt à ce que ALTO soit utilisé : le FAI veut que les utilisateurs épargnent les liens réseaux les plus lents et les plus coûteux et les utilisateurs veulent les meilleures perfomances. En théorie, tout le monde trouvera son intérêt à utiliser ALTO.

Un exemple est celui de BitTorrent. Si les pairs BitTorrent incluent un client ALTO, chaque pair, quand il reçoit une liste d'adresses IP de l'essaim, peut alors interroger le serveur ALTO et trouver les « meilleurs » pairs. Ils peuvent même échanger cette information entre eux (PEX, Peer EXchange, dans le monde BitTorrent). Mais une autre possibilité est que ce ne soient pas les pairs qui interrogent le serveur ALTO mais le tracker (pour les essaims fonctionnant avec une machine qui sert de tracker, ce qui n'est pas toujours le cas). Ainsi, il n'est pas nécessaire de mettre un client BitTorrent dans chaque pair, c'est le tracker qui, grâce à l'information ALTO, choisit les meilleurs pairs pour chacun, et ne leur envoie que cela.

Le RFC se conclut pas une section 7 sur la sécurité. Parmi les problèmes à considérer, il y a le fait qu'un serveur ALTO malveillant, ou bien un serveur se faisant passer pour un serveur ALTO légitime, peut empoisonner le client avec de fausses données.


Téléchargez le RFC 7971


L'article seul

Fiche de lecture : Mastering Bitcoin

Auteur(s) du livre : Andreas Antonopoulos
Éditeur : O'Reilly
978-1-449-37404-4
Publié en 2015
Première rédaction de cet article le 20 novembre 2016


Vous voulez connaitre tous les détails techniques sur Bitcoin ? Voici un livre recommandé. À la fin, vous en saurez davantage que vous ne vouliez.

Le livre a été écrit par Andreas Antonopoulos, personnage connu dans le monde Bitcoin, et qui écrit de nombreux articles et donne plein de conférences (celle qu'il a donné à Paris le 11 octobre est en ligne, vous pouvez aussi voir les nombreux tweets que cela a entrainé et une excellente « storifycation de ces tweets). Son livre commence de manière très pédagogique, à travers des scénarios d'utilisation. Alice utilise Multibit pour acheter un café à Bob à Palo Alto, Bob fait refaire le site Web de son café à Gonesh, à Bangalore, et Jing mine du bitcoin à Shanghai. Au début, l'auteur fait peu de technique, se focalisant sur les applications.

Ensuite, cela devient plus technique, en commençant par l'installation d'un nœud Bitcoin (le livre n'est pas destiné à M. Michu). Andreas Antonopoulos explique le fonctionnement du client en ligne de commande qui permet de parler à son nœud Bitcoin. De la commande la plus triviale, permettant de savoir à quel bloc en est la chaîne locale :

 % bitcoin-cli getblockcount
439785
    

à des commandes plus complexes, ici pour voir l'achat du café d'Alice :

% bitcoin-cli gettransaction 0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2
    

(Si vous obtenez le message d'erreur Invalid or non-wallet transaction id, c'est que vous n'avez pas bien lu le livre et les instructions qu'il donne pour accéder à toutes les transactions.)

À noter que les exemples ont été réellement faits sur la chaîne publique Bitcoin, et peuvent donc être vérifiés. L'adresse d'Alice est 1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK et on peut donc voir toutes ses transactions en ligne, de sa première obtention de 0,1 bitcoin auprès de son ami Joe (transaction 7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18), à l'achat du café à Bob (transaction 0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2). Le code QR de la demande de bitcoins de Bob, dans le livre, est également un vrai, et on peut le lire (bitcoin:1GdK9UzpHBzqzX2A9JFP3Di4weBwqgmoQA?amount=0.015&label=Bob%27s%20Cafe&message=Purchase%20at%20Bob%27s%20Cafe).

L'auteur pense aussi aux programmeurs et leur explique comment accéder aux données Bitcoin et les manipuler depuis un programme. Par exemple, en Python, avec la bibliothèque pycoin.

Je l'ai dit, ce livre, malgré ses premières pages très pédagogiques sur Bitcoin, est prévu pour les techniciens. Vous y trouverez même une explication de la cryptographie sur courbes elliptiques, permettant de décrire ensuite les différents formats de clés.

Les utilisateurs de l'autre chaîne de blocs Ethereum savent qu'une adresse Ethereum ne désigne pas forcément un compte mais peut référencer un programme qui sera exécuté lorsqu'on enverra quelque chose à cette adresse. Mais peu savent que cette possibilité existe dans Bitcoin depuis longtemps. Antonopoulos décrit donc en détail les différents types d'adresses Bitcoin, notamment les P2SH (Pay To Script Hash) où le paiement va déclencher l'exécution d'un programme qui pourra, par exemple, demander plusieurs signatures pour valider un paiement (la grande différence entre Ethereum et Bitcoin n'est pas la présence ou l'absence de programmes stockés dans la chaîne, elle est dans le fait que seul Ethereum a un langage de Turing ; au passage, le livre contient un court chapitre présentant rapidement quelques chaînes de blocs concurrentes). Il y a même un peu d'assembleur Bitcoin dans le livre (mais pas un cours complet sur ce langage).

Les gens du réseau aimeront également le chapitre sur le fonctionnement pair à pair de Bitcoin et sur la façon dont les nœuds Bitcoin échangent. Un petit coup de bitcoin-cli getpeerinfo et je vois que ma machine Bitcoin a 124 pairs, dont 11 se connectent en IPv6. 86 font tourner le logiciel de référence Bitcoin Core et 30 sont basés sur BitcoinJ (ce sont surtout des clients utilisant Multibit).

Je l'ai dit plus haut, ce livre n'est pas du tout nécessaire pour utiliser Bitcoin, ni même pour comprendre comment il fonctionne. En revanche, il est indispensable si vous voulez comprendre les points les plus délicats du fonctionnement de Bitcoin, comme les UTXO, la structure de la chaîne avec les arbres de Merkle, le fonctionnement de SPV... Difficile de trouver une question technique sur Bitcoin qui n'aurait pas de réponse dans ce livre.

Avertissement : j'ai acheté ce livre en payant en euros, pas en bitcoins. J'en profite pour rappeler que, si vous aimez ce blog, je veux bien des bitcoins.


L'article seul

Panne des résolveurs DNS d'Orange, observations et remarques

Première rédaction de cet article le 17 novembre 2016


Le 16 novembre, deux pannes successives ont affecté les résolveurs DNS d'Orange. Que s'est-il passé exactement, et quelles conséquences peut-on en tirer ?

Commençons par les observations. Au moins, il s'agira de faits. Les deux pannes sont survenues approximativement entre 0840 UTC (soit quasiment en même temps que la plénière de l'IETF dont le thème était... « Attacks Against the Architecture » !) et 1030 pour la première, et entre 1315 et 1410 (toujours UTC) pour la seconde. N'ayant pas de compte chez Orange, j'ai utilisé deux sources d'informations, les rézosocios, où d'innombrables messages ont signalé la panne, et les sondes RIPE Atlas. Pour ces dernières, j'ai demandé des sondes se trouvant dans l'AS 3215, celui d'Orange (notez qu'il abrite des services très différents, ne dépendant pas forcément des mêmes résolveurs DNS). À ma connaissance, Orange n'a rigoureusement rien communiqué, ni pendant la panne (malgré les innombrables cris lancés par ses clients sur les rézosocios), ni après, donc je ne peux me fier qu'à ces observations. Les messages des utilisateurs d'Orange étaient pour la plupart trop vagues (« rien ne marche »), ne citant même pas un nom de domaine qu'on puisse ensuite tester. Personne hélas pour procéder à une récolte sérieuse de données, par exemple avec dig. Ces messages des utilisateurs ne peuvent donc servir qu'à signaler et confirmer qu'il y avait un gros problème. Mais les sondes Atlas nous en disent davantage.

Que nous montrent-elles ? Je prends par exemple le domaine de l'Université Stanford. Si je veux vérifier qu'il est bien visible, je demande à cent sondes RIPE Atlas de résoudre ce nom en adresse IP :

% atlas-resolve --requested 100 online.stanford.edu
[] : 1 occurrences 
[171.67.216.22] : 33 occurrences 
[171.67.216.23] : 28 occurrences 
[171.67.216.21] : 37 occurrences 
Test #6935163 done at 2016-11-17T04:56:58Z

C'était le lendemain de la panne, et tout marche bien (une seule sonde n'a pas eu de réponse, et cela peut être de la faute de son réseau d'accès). Mais pendant la panne ? On voyait, en se limitant à l'AS 3215, des choses comme :

% atlas-resolve --requested 100 --as 3215 online.stanford.edu
[TIMEOUT(S)] : 13 occurrences 
[ERROR: SERVFAIL] : 65 occurrences 
[171.67.216.22] : 8 occurrences 
[171.67.216.23] : 7 occurrences 
[171.67.216.21] : 7 occurrences 
Test #6934676 done at 2016-11-16T08:53:51Z

Regardons de plus près. La majorité des sondes RIPE Atlas situées dans l'AS d'Orange n'a pu résoudre le nom, et a au contraire obtenu un code SERVFAIL (SERVer FAILure), indiquant que le résolveur (je reviens sur ce terme plus loin) utilisé n'a pu joindre aucun des serveurs faisant autorité pour le domaine stanford.edu. Pas mal de sondes n'ont simplement pas eu de réponses de leur résolveur à temps.

Mais cette unique observation ne nous permet pas de dire que le problème venait d'Orange. Il est parfaitement possible que ce soit Stanford qui ait des ennuis, panne ou dDoS. Il faut donc, comme toujours lorsqu'on fait des observations scientifiques, comparer avec des mesures faites dans d'autres circonstances. Ici, on va simplement demander aux sondes situées dans un pays voisin, l'Allemagne :

    
% atlas-resolve --requested 100 --country DE online.stanford.edu 
[] : 1 occurrences 
[171.67.216.22] : 33 occurrences 
[171.67.216.23] : 31 occurrences 
[171.67.216.21] : 35 occurrences 
Test #6934677 done at 2016-11-16T08:54:06Z

Au pays de Konrad Zuse, toutes les sondes ou presque ont une réponse. Cela laisse entendre que tout va bien à Stanford et que le problème ne vient pas de l'université californienne. (J'aurais aussi pu tester avec un autre AS français, celui de SFR ou de Free.)

Autre façon de voir que le problème était bien chez Orange et pas du côté des domaines testés, essayer avec d'autres domaines :

%  atlas-resolve --requested 100 --as 3215 kotaku.com
[ERROR: SERVFAIL] : 47 occurrences 
[151.101.1.34 151.101.129.34 151.101.193.34 151.101.65.34] : 50 occurrences 
Test #6934730 done at 2016-11-16T10:10:01Z

% atlas-resolve --requested 100 --as 3215 spotify.com
[194.132.197.147 194.132.198.165 194.132.198.228] : 76 occurrences 
[ERROR: SERVFAIL] : 19 occurrences 
[TIMEOUT(S)] : 4 occurrences 
Test #6934675 done at 2016-11-16T08:52:10Z
    

Tous ces domaines marchaient parfaitement depuis d'autres AS ou d'autres pays.

Donc, problème de résolution DNS chez Orange. Comme l'ont vite découvert bien des utilisateurs, changer de résolveur DNS suffisait à résoudre le problème (ce qu'on pouvait également tester avec ce programme atlas-resolve et l'option --nameserver).

Notons bien, qu'il s'agissait des résolveurs DNS, pas des serveurs faisant autorité, comme cela avait été le cas récemment lors de l'attaque contre Dyn. La distinction est cruciale car ces deux types de serveurs DNS n'ont pas grand'chose en commun. Si vous lisez un article qui parle de « serveur DNS » tout court, sans préciser s'il s'agit d'un résolveur ou bien d'un serveur faissant autorité, méfiez-vous, c'est souvent un signe d'ignorance, ou de négligence, de la part de l'auteur de l'article.

Maintenant, les remarques. D'abord, beaucoup de gens (par exemple dans cet article de Numerama, mais aussi dans d'innombrables tweets) ont suggéré de passer des résolveurs DNS d'Orange (ceux utilisés par défaut par les abonnés à ce FAI) à ceux de Google Public DNS ou bien à ceux de Cisco OpenDNS. La plupart des sociétés à but lucratif doivent payer des commerciaux et des chargés de relation publique pour faire leur publicité, mais Google n'en a pas besoin, ayant des millions de vendeurs bénévoles et enthousiastes parmi ses utilisateurs. Mais ceux qui écoutent ces conseils et passent à Google Public DNS lui donneront les données personelles qui permettent leur propre surveillance (cf. le RFC 7626 sur le caractère sensible des requêtes DNS). Je ne développe pas davantage ce point ici, Shaft l'a fait mieux que moi. J'observe que, si ce genre de pannes continue, les utilisateurs français dépendront presque tous, pour une activité critique, d'un résolveur états-unien d'une entreprise privée. Cela devrait logiquement agiter ceux qui nous parlent tout le temps de souveraineté numérique, mais, en général, ces gens ne sont pas intéressés par les problèmes concrets et opérationnels.

Mais alors quelle serait la bonne solution ? Le mieux évidemment est d'utiliser des résolveurs proches, donc a priori dans le cas idéal, ceux de son FAI. Ceux-ci ne devraient pas tomber en panne, le DNS étant absolument indispensable à tout usage de l'Internet. Mais lorsque des pannes aussi longues surviennent, il est normal d'envisager d'autres solutions, et la bonne est certainement d'avoir un résolveur sur son réseau local (pas forcément sur chaque machine), ce qui est facile avec des équipements comme le Turris Omnia.

Notez qu'une minorité des sondes RIPE Atlas sont déjà sur un réseau local qui utilise un tel résolveur. Cela explique en partie pourquoi, dans les tests ci-dessus, un certain nombre de sondes arrivaient à résoudre les noms de domaine, même au plus fort de la panne. (Cela n'explique qu'une partie du phénomène. Il semble que certains noms avaient un taux de réussites plus fort que d'autres, ce qui ne peut pas s'expliquer par le choix du résolveur.) Notez qu'on peut avoir l'adresse IP du résolveur utilisé par la sonde (avec l'option --displayresolvers) mais que cela ne renseigne pas tellement. D'abord, c'est souvent une adresse IP privée (RFC 1918), ensuite, le premier résolveur vu par la sonde fait fréquemment suivre à un résolveur plus gros, qu'on ne voit pas, et qui peut être ou ne pas être un résolveur « officiel » du FAI. Je vous montre quand même le résultat pour l'une des mesures faites ci-dessus (notez la bogue pour le cas du timeout, où le résolveur n'est pas connu) :

% atlas-resolve -r 100 --as 3215 --displayresolvers --measurement 6934670  kotaku.com    
[ERROR: SERVFAIL] : 27 occurrences (resolvers ['172.31.255.254', '192.168.1.1', '80.10.246.2', '192.168.2.1', '192.168.254.254', '192.168.3.1'])
[151.101.1.34 151.101.129.34 151.101.193.34 151.101.65.34] : 69 occurrences (resolvers ['2a01:cb08:898c:fc00::1', '172.16.3.1', '192.168.1.1', '10.10.11.4', '10.63.0.252', '10.112.0.1', '8.8.8.8', '192.168.119.1', '192.168.1.9', '192.168.0.1', '10.0.0.34', '80.10.246.136', '192.168.248.153', '192.168.4.10', '192.168.1.40', '192.168.221.254', '149.202.242.66', '192.168.255.254', '192.168.28.1', '192.168.2.1', '10.0.0.1', '192.168.0.31', '194.2.0.20', '192.168.10.10'])
[TIMEOUT(S)] : 4 occurrences (resolvers <__main__.Set instance at 0x7fedc8194f80>)
Test #6934670 done at 2016-11-16T08:44:41Z

Deuxième sujet de réflexions sur cette panne, que s'est-il passé ? En l'absence de toute communication de la part d'Orange, on ne peut guère que spéculer. Notons tout de suite qu'il ne s'agissait pas cette fois d'un détournement (comme lorsque Orange avait redirigé Google et Wikipédia vers le Ministère de l'Intérieur) mais d'une absence de réponse. Cette absence dépendait des domaines. Je n'ai pas eu immédiatement de signalement d'un problème pour un domaine hébergé en France, seulement pour des domaines états-uniens (c'est après, donc trop tard pour les mesures, que j'ai appris que des domaines hébergés en France étaient également touchés). Comme le code de retour SERVFAIL indique que le résolveur n'a pas réussi à parler aux serveurs faisant autorité, on peut donc supposer que les liens menant à ces réseaux outre-Atlantique étaient inutilisables. Suite à une erreur de configuration, par exemple dans des ACL ? À un problème de routage vers certaines destinations ? À une attaque par déni de service ? Je ne le sais pas. Mais je me demande bien quelle était la panne ou l'attaque qui pouvait bloquer les résolveurs, tout en laissant passer toutes les autres machines (puisque, une fois qu'on avait un résolveur normal, le trafic n'était pas affecté).


L'article seul

RFC 8020: NXDOMAIN: There Really Is Nothing Underneath

Date de publication du RFC : Novembre 2016
Auteur(s) du RFC : S. Bortzmeyer (AFNIC), S. Huque (Verisign Labs)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 9 novembre 2016


Tout le monde apprend à l'école que les noms de domaine sont organisés en un arbre. (Et j'invite tout le monde à lire la section 3.1 du RFC 1034, pour dire moins de bêtises sur les noms de domaine.) Il en découle logiquement que, si un nœud de l'arbre n'existe pas, les nœuds situés en dessous n'existent pas non plus. C'est évident ? Hélas, non. En pratique, bien des résolveurs DNS sont prudents et, lorsqu'ils reçoivent une réponse négative pour un nom, mettons foo.example, ils n'enregistrent pas pour autant le fait que les sous-domaines comme bar.foo.example n'existent pas non plus, et, si un client leur demande des informations sur ce sous-domaine, ils vont relayer la question aux serveurs faisant autorité, alors qu'ils auraient parfaitement pu répondre à partir de leur cache. Ce nouveau RFC remet les choses en place : les noms de domaine sont organisés en arbre, ce comportement traditionnel est donc bel et bien erroné, et un résolveur devrait, lorsqu'il reçoit une réponse négative, mémoriser le fait qu'il n'y a pas non plus de sous-domaines de ce nom. Cela améliorera les performances du DNS et, dans certains cas, sa résistance à des attaques par déni de service.

Voyons d'abord ce que fait un résolveur actuel. J'ai choisi Unbound. Il vient de démarrer, on lui demande foobar56711.se, qui n'existe pas :

% dig MX foobar56711.se.

...	 
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56324

    

On a logiquement un NXDOMAIN (No Such Domain, ce nom n'existe pas ; cette erreur se nommait autrefois Name Error, et a le code 3). Où le résolveur a-t-il trouvé cette information ? Il a demandé aux serveurs faisant autorité, comme nous le montre tcpdump :

14:57:14.488196 IP (tos 0x0, ttl 57, id 52537, offset 0, flags [none], proto UDP (17), length 1063)
    130.239.5.114.53 > 10.10.86.133.44861: [udp sum ok] 64329 NXDomain*- q: MX? foobar56711.se. 0/6/1 ...     
    

Le serveur d'IIS (le registre de .se), 130.239.5.114 lui a bien dit NXDOMAIN. Maintenant, demandons au même résolveur xyz.foobar56711.se, sous-domaine du précédent :

% dig MX xyz.foobar56711.se.

...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64776

    

Et, si on regarde le trafic avec tcpdump, on voit que le résolveur a demandé encore au serveur faisant autorité, alors que c'était inutile !

15:00:32.929219 IP (tos 0x0, ttl 64, id 42641, offset 0, flags [none], proto UDP (17), length 75)
    10.10.86.133.40616 > 130.239.5.114.53: [bad udp cksum 0x8d98 -> 0xd7df!] 10643% [1au] MX? xyz.foobar56711.se. ar: . OPT UDPsize=4096 OK (47)
15:00:32.939437 IP (tos 0x0, ttl 57, id 14256, offset 0, flags [none], proto UDP (17), length 1067)
    130.239.5.114.53 > 10.10.86.133.40616: [udp sum ok] 10643 NXDomain*- q: MX? xyz.foobar56711.se. 0/6/1 ...
    

Pourquoi le résolveur est-il si prudent, et pose-t-il au serveur faisant autorité une question dont il aurait déjà dû connaitre la réponse ? Il y a plusieurs raisons mais la principale est que le RFC originel sur le DNS, le RFC 1034, est ambigu. Il ne décrivait pas de manière parfaitement claire ce qu'il faut faire lorsqu'un nom de domaine est un ENT, un Empty Non-Terminal, c'est-à-dire un nom de domaine qui n'a pas d'enregistrements mais qui a des sous-domaines. Certains ont pensé que cela autorisait à répondre NXDOMAIN lorsque le nom demandé est un ENT. Ce comportement a été clairement noté comme incorrect dans les RFC ultérieurs (section 7.16 du RFC 2136 et sections 2.2.2 et 2.2.3 du RFC 4592) mais tout le monde n'en avait pas forcément tiré les conséquences. Autre RFC qui contribuait au comportement erroné, le RFC 2308 (dans sa section 5) faisait l'erreur de dire qu'un résolveur ne pouvait renvoyer un NXDOMAIN que si la question portait sur exactement le même nom que celui qui avait été mis en cache. Notre nouveau RFC 8020 corrige cette erreur : un résolveur doit également renvoyer NXDOMAIN si la question est un sous-domaine d'un domaine inexistant.

La règle qui forme le cœur de ce nouveau RFC tient en une phrase (section 2) : « si un résolveur reçoit un NXDOMAIN, il peut et il devrait mémoriser le fait que ce nom et tous ceux en dessous n'existent pas ». Logiquement, les questions ultérieures portant sur un sous-domaine de ce nom devraient recevoir immédiatement un NXDOMAIN, sans déranger les serveurs faisant autorité. C'est d'ailleurs ce que fait Unbound, si on active l'option harden-below-nxdomain ainsi :

server:
    harden-below-nxdomain: yes     
   

On voit alors qu'Unbound, face aux deux requêtes successives pour foobar56711.se et xyz.foobar56711.se, n'écrit qu'une seule fois aux serveurs de .se. (Si cela ne marche pas pour vous, c'est peut-être que votre Unbound ne valide pas, vérifiez sa configuration DNSSEC, ou que le domaine est signé avec l'option opt-out.) Unbound suit donc le bon comportement mais, malheureusement, pas par défaut. (C'est déjà mieux que BIND, qui a toujours le mauvais comportement de demander systématiquement aux serveurs faisant autorité, ce qui annule partiellement l'intérêt d'avoir un cache.)

Voilà, vous savez maintenant l'essentiel sur le principe du NXDOMAIN cut. Voyons quelques détails, toujours en section 2 du RFC. D'abord, il faut noter que la règle n'est pas absolue : un résolveur, s'il y tient, peut continuer à renvoyer des réponses positives à une question sur un sous-domaine, même si le domaine parent n'existe pas, si le cache (la mémoire) du résolveur contenait des réponses pour ces sous-domaines. En terme d'implémentation, cela veut dire que le mode préféré est de supprimer tout le sous-arbre du cache lorsqu'on reçoit un NXDOMAIN, mais que ce n'est pas obligatoire.

D'autre part, rien n'est éternel dans le monde du DNS. Les informations reçues par le résolveur ne sont valables que pendant une période donnée, le TTL. Ainsi, une information positive (ce domaine existe) n'est vraie que jusqu'à expiration du TTL (après, il faut revalider auprès des serveurs faisant autorité). Même chose pour une information négative : la non-existence d'un domaine (et de tout le sous-arbre qui part de ce domaine) est établie pour un TTL donné (qui est celui du champ Minimum du SOA, cf. RFC 2308).

Dernier petit piège, s'il y a une chaîne d'alias menant au nom de domaine canonique, le NXDOMAIN s'applique au dernier nom de la chaîne (RFC 6604), et pas au nom explicitement demandé.

La section 4 de notre RFC détaille les bénéfices attendus du NXDOMAIN cut. Le principal est la diminution de la latence des réponses, et celle de la charge des serveurs faisant autorité. On aura moins de requêtes, donc un bénéfice pour tout l'écosystème. Cela sera encore plus efficace avec la QNAME minimisation du RFC 7816, puisque le résolveur pourra arrêter son traitement dès qu'il y aura un domaine absent.

Cela sera aussi utile dans le cas de certaines attaques par déni de service, notamment les attaques random QNAMEs avec un suffixe un peu long (comme dans le cas de l'attaque dafa888).

Mais tout n'est pas idéal dans cette vallée de larmes. Le NXDOMAIN cut peut aussi poser des problèmes, ce qu'examine la section 5. Le principal risque est celui que pose des serveurs faisant autorité bogués, comme ceux d'Akamai. Regardons le domaine de l'Université de Pennsylvanie, www.upenn.edu :

% dig  A www.upenn.edu   
www.upenn.edu.		300 IN CNAME www.upenn.edu-dscg.edgesuite.net.
   

C'est un alias pour un nom Edgesuite (une marque d'Akamai). Mais les serveurs de edgesuite.net sont bogués, ils répondent NXDOMAIN pour un ENT (Empty Non-Terminal, comme edu-dscg.edgesuite.net :


% dig @ns1-2.akam.net A edu-dscg.edgesuite.net     
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 659
...

   

La réponse correcte aurait dû être NODATA (c'est-à-dire le code NOERROR et une section Answer de taille nulle). Tant qu'Akamai n'aura pas réparé ses serveurs, des problèmes subsisteront.

Au fait, pourquoi ne pas se servir de l'enregistrement SOA, qui est renvoyé en cas de réponse négative, pour trouver un NXDOMAIN cut situé encore plus haut, et qui sera donc plus efficace pour limiter les requêtes ultérieures ? L'annexe A du RFC explique pourquoi c'est une fausse bonne idée. Prenons l'exemple d'un nom non existant, anything.which.does.not.exist.gouv.fr :


% dig AAAA anything.which.does.not.exist.gouv.fr 
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35377
...
;; AUTHORITY SECTION:
fr.			5400 IN	SOA nsmaster.nic.fr. hostmaster.nic.fr. (
				2224131472 ; serial
...

Le SOA renvoyé indique fr. Il ne faut pas en déduire que les noms plus spécifiques n'existent pas (gouv.fr existe, mais ce n'est pas une zone séparée, voilà pourquoi le SOA indiquait son parent fr).

La section 6 du RFC contient quelques conseils pour les implémenteurs. Rappelez-vous que les exigences de ce RFC concernent le comportement extérieur du résolveur, pas la façon dont il est mis en œuvre. Cette réalisation concrète va donc dépendre de comment sont représentés les domaines dans la mémoire du résolveur. La représentation la plus évidente est d'utiliser un arbre puisque c'est le modèle des noms de domaine. Mais ce n'est pas obligatoire. Un autre choix pourrait être celui d'un dictionnaire, plus rapide (pour un nom de domaine très profond, il y aura moins de lectures dans la structure de données) mais qui rend certaines opérations plus difficiles (toutes celles définies par rapport au modèle d'arbre, et elles sont nombreuses dans le DNS). Et il existe des implémentations intermédiaires, par exemple avec un arbre augmenté d'un index. Bref, le programmeur a le choix. S'il a opté pour un arbre, la façon la plus simple de respecter les exigences du RFC et, en recevant un NXDOMAIN, de supprimer tout sous-arbre qui partirait du nom ainsi nié.

Un petit mot de sécurité, maintenant qu'on approche de la fin. Si un résolveur accepte un NXDOMAIN mensonger (attaque par empoisonnement), les conséquences risquent d'être sérieuses puisque c'est un sous-arbre entier qui serait « détruit ». C'est pour cela que le RFC autorise un résolveur prudent à ne pratiquer le NXDOMAIN cut que si le NXDOMAIN a été validé avec DNSSEC. C'est ce que fait Unbound, cité plus haut.

Notez que, si on a DNSSEC, une technique encore plus puissante consiste à synthétiser des réponses NXDOMAIN en utilisant les enregistrements NSEC. Elle est décrite dans un Internet-Draft actuellement en cours de discussion.

Quels sont les résolveurs qui gèrent aujourd'hui le NXDOMAIN cut ? Outre Unbound, déjà cité, il y a PowerDNS Recursor, mais qui est, curieusement, limité au cas particulier de la racine.

Un peu d'histoire pour finir : le projet qui a mené à ce RFC a été lancé (cf. les supports) à la réunion IETF de Yokohama, à peine plus d'un an avant la publication du RFC (on peut voir ici l'histoire des différents brouillons). On voit que l'IETF peut agir vite.


Téléchargez le RFC 8020


L'article seul

Fiche de lecture : Quand le digital défie l'État de droit

Auteur(s) du livre : Olivier Iteanu
Éditeur : Eyrolles
978-2-212-11859-9
Publié en 2016
Première rédaction de cet article le 2 novembre 2016


On ne peut plus se plaindre que l'irruption du numérique dans toutes les activités humaines se fasse sans réflexion politique ou juridique. Voici encore un nouvel ouvrage sur la question, écrit par un juriste qui connait bien ce domaine depuis des années. Il tourne autour d'une question « est-ce que cette irruption du numérique va se faire au détriment du droit ? ».

Olivier Iteanu se penche sur quatre grandes questions politico-juridiques : la liberté d'expression, la vie privée, le droit d'auteur et la gouvernance de l'Internet. Sa thèse principale est que, oui, le numérique menace l'État de droit (au passage, il y a une différence entre « État de droit » et « état de droit » et Iteanu met bien la majuscule). En gros, les GAFA tentent d'imposer leurs lois (les fameuses CGU que personne ne lit, et qui sont souvent illégales, par exemple en obligeant d'aller traiter les litiges en Californie). Et cela se fait au détriment des lois nationales des pays vassaux.

La thèse est étayée par de nombreux exemples, les argumentaires des GAFA (« mais vous pouvez toujours changer les paramètres de vie privée, si vous ne voulez pas que vos données soient diffusées ») bien réfutés. Je ne vais pas en discuter ici, je ne cherche pas à défendre Google :-) Mais le problème est qu'Iteanu semble considérer qu'il n'y a menace pour les citoyens que lorsqu'elle vient d'un GAFA états-unien. Ainsi, la section sur la liberté d'expression oppose « liberté d'expression » et « freedom of speech » (en anglais dans le texte, pour bien montrer que c'est un concept étranger). L'idée est que le « freedom of speech » est absolu (et permet donc des discours racistes, par exemple), alors que la liberté d'expression est bornée par la loi. D'abord, cette opposition États-Unis-premier-amendement-freedom-of-speech-totale vs. France-pays-de-raison-et-de-mesure est largement fausse. Le premier amendement ne crée pas une liberté d'expression totale. Il dit juste que l'État ne doit pas la limiter. Cela laisse les entreprises privées ou des groupes de citoyens libres de limiter la liberté tant qu'ils veulent (cf. les censures de Facebook, par exemple). Mais, surtout, tout le chapitre sur la liberté d'expression fait comme si le seul problème lié à la liberté d'expression était l'abus que certains en font, pour de la propagande nazie, par exemple. Les menaces contre la liberté d'expression ne sont pas mentionnées. Et l'état d'urgence en France n'est jamais cité.

La tonalité « souverainiste » du livre est d'ailleurs assez agaçante. Les seuls reproches faits aux institutions françaises ou européennes sont de trop céder aux pressions états-uniennes. À lire ce livre, on a un peu l'impression que les États en Europe et notamment en France ne font jamais rien de dangereux ou de négatif, et que la seule question politique est de résister aux empiètements des GAFA et du gouvernement de Washington. L'auteur fait remarquer à juste titre que le passage du règne de la loi à celui de CGU dictées par une entreprise capilatiste n'est pas un progrès, mais cette dénonciation serait plus convaincante si elle était accompagnée d'une critique de la loi (qui est présentée comme l'expression indiscutable de la volonté du peuple).

Sur la vie privée (opposée à la « privacy » anglo-saxonne), Iteanu pointe à juste titre le danger de la surveillance massive que fait le gouvernement états-unien, notamment via la NSA, et le fait que le défunt Safe Harbor soit « un chiffon de papier ». Mais il ne mentionne qu'en passant, et sans critiques, les contributions françaises à la surveillance, comme la loi Renseignement.

Sur le droit d'auteur, Iteanu reprend la théorie comme quoi il y aurait une différence de philosophie entre « droit d'auteur » et « copyright » anglo-saxon, et que cette différence aurait des conséquences pratiques (ce qui n'est pas vraiment le cas). Par contre, il est cette fois bien plus critique pour le système français, pointant l'inefficacité et l'injustice du système répressif que symbolise en France la HADOPI.

Enfin, la partie sur la gouvernance de l'Internet critique logiquement l'ICANN (le livre a été écrit avant le léger changement des relations entre l'ICANN et le gouvernement états-unien le 1er octobre 2016, mais cela a peu d'importance). L'ICANN est une cible facile (et justifiée) mais il est dommage que l'ONU soit citée comme alternative crédible, sans l'once d'une critique. Iteanu cite entre autres des gens dont la crédibilité est très faible, comme Bellanger qui, dans un article fumeux, accusait Google de détournements imaginaires.

(Les techniciens pinailleurs comme moi seront surpris du tableau présentant les serveurs racine, et plus précisément de sa dernière colonne, « suffixe du nom de domaine », qui place la NASA dans un curieux .usg, ne met pas l'armée états-unienne sous .mil, et voit le RIPE-NCC en .int. De toute façon, aujourd'hui, tous les serveurs racine sont nommés sous .net.)

En résumé, l'analyse des GAFA, de leur attitude, des menaces qu'ils représentent pour la vie privée ou pour la souveraineté nationale, est très bonne et résume bien le problème. Mais l'« oubli » complet des menaces venant d'autres acteurs, comme l'État français ou comme les entreprises françaises, diminue sérieusement l'intérêt du livre. Olivier Iteanu connait bien son sujet (et évite donc de parler des pires énormités souverainistes comme le cloud souverain ou l'OS souverain) mais, hélas, il se laisse trop emporter par un point de vue national.

Tiens, ça me donne envie de parler en anglais. Full disclosure : j'ai reçu un exemplaire gratuit de ce livre.


L'article seul

RFC 7999: BLACKHOLE Community

Date de publication du RFC : Octobre 2016
Auteur(s) du RFC : T. King, C. Dietzel (DE-CIX Management), J. Snijders (NTT), G. Doering (SpaceNet AG), G. Hankins (Nokia)
Pour information
Réalisé dans le cadre du groupe de travail IETF grow
Première rédaction de cet article le 20 octobre 2016


Lorsqu'on est soumis à une sérieuse attaque par déni de service volumétrique, il faut parfois sacrifier la machine qui en est la cible, afin de préserver le reste des ressources réseau. On demande alors à son opérateur de jeter le trafic à destination de cette machine, avant qu'il n'emprunte la liaison qu'on veut préserver. Cela peut se faire manuellement mais c'est évidemment plus rapide et moins risqué si on le fait automatiquement, via une annonce BGP vers le préfixe visé. Pour cela, on marque l'annonce BGP avec une communauté (RFC 1997) qui veut dire « poubelle donc tout ce trafic ». Ce nouveau RFC normalise une communauté standard, « bien connue », pour cela, BLACKHOLE (0xFFFF029A). Ainsi, il n'y aura plus besoin d'utiliser une communauté différente pour chaque opérateur.

Cette méthode consistant à envoyer le trafic destiné à la victime vers un « trou noir » (blackholing) est décrite dans les RFC 3882 et RFC 5635. Comme elle agit au niveau IP, elle ne nécessite pas d'équipements spéciaux, et elle est très rapide, ne prenant que peu de ressources chez les routeurs. Par contre, elle est peu subtile : tout le trafic à destination d'un préfixe donné (préfixe en général réduit à une seule adresse IP, celle de la machine attaquée) est jeté, qu'il fasse partie de l'attaque ou pas. Quel est l'intérêt de couper tout le trafic ? Cela réalise l'objectif de l'attaquant, non ? C'est en effet une mesure désespérée mais rationnelle : son but est de préserver les ressources réseau pour que les autres machines fonctionnent. Si vous êtes connecté à l'Internet par une liaison à 10 Gb/s, et qu'une attaque de 20 Gb/s frappe votre opérateur, votre ligne va être complètement inutilisable. Aucune action de votre côté n'y changerait rien, dès que les paquets sont arrivés chez vous, c'est trop tard. Ce RFC traite le cas où on demande à l'opérateur de jeter le trafic avant qu'il ne soit envoyé sur la ligne entre l'opérateur et vous.

Le problème (section 1 du RFC) est qu'il existait plusieurs méthodes pour déclencher cet envoi dans un trou noir, ce qui compliquait la tâche des équipes réseau, une annonce BGP marquée avec une certaine communauté, une annonce BGP avec un certain next hop, et des méthodes non-BGP (dont le coup de téléphone au NOC). D'où la solution de notre RFC, définir une communauté standard. Plus besoin de se poser de question (à part celle de savoir si votre opérateur accepte cette commande, voir les sections 3.3 et 4). Au passage, les communautés BGP sont décrites dans le RFC 1997.

Une communauté BLACKHOLE est donc définie (section 2) et mise dans le registre IANA des communautés bien connues. Sa valeur est 0xFFFF029A. Le 666 à la fin vient de la Bible et était déjà couramment employé par les opérateurs. Notez donc que ce RFC n'invente pas une nouvelle technique (demander à son pair de jeter certains paquets est une technique très ancienne), il lui donne juste une communauté standard.

Voilà, c'est tout, juste une réservation d'un nom et d'une valeur. Si vous êtes intéressés par les détails pratiques, la section 3 est consacrée aux problèmes opérationnels. D'abord, un point essentiel : accepter des annonces BGP étiquetées BLACKHOLE est un choix local. Aucun opérateur n'est obligé de respecter cette demande et, dans ce cas, ladite communauté est ignorée. Lorsqu'on se connecte à un nouveau pair BGP, il peut donc être prudent de lire leur documentation ou de leur poser la question. N'utilisez BLACKHOLE qu'entre des adultes consentants. (Notez que cet avertissement du RFC est un peu contradictoire avec l'avantage proclamé de la normalisation de BLACKHOLE : en pratique, on est toujours obligé de savoir ce que fait son pair, on ne peut pas compter sur une méthode standard qui marcherait partout.) Une liste des opérateurs et points d'échange qui acceptent BLACKHOLE est disponible en ligne.

Si tout le monde accepte BLACKHOLE, on s'en sert comment ? Lorsqu'une attaque DoS est en cours, on annonce un préfixe qui couvre l'adresse IP visée, et on y ajoute cette communauté. On peut aussi utiliser BLACKHOLE pour les annonces du RFC 5635 (mais pas avec celles du RFC 5575).

Attention à ne pas propager ces annonces ! En effet, étant en général très spécifiques (souvent une seule adresse IP), elles seraient préférées, si elles étaient insérées dans une table de routage. Leur effet est prévu pour être strictement local et, donc, les annonces doivent être marquées avec la communauté NO_EXPORT (ou NO_ADVERTISE).

En parlant de spécificité, quelle doit être la longueur des préfixes annoncés avec un BLACKHOLE attaché ? Souvent, l'attaque ne vise qu'une seule adresse et, donc, les annonces BLACKHOLE seront souvent des /32 (en IPv4) et /128 (en IPv6), afin de ne sacrifier que le strict minimum de son réseau. Si vous avez une politique BGP de n'accepter que des préfixes plus généraux, c'est un point à modifier. Aujourd'hui (RFC 7454, section 6.1.3), les préfixes plus spécifiques que /24 (IPv4) et /48 (IPv6) sont rarement acceptés. Il faut donc faire des exceptions pour les trous noirs.

Lorsqu'un opérateur reçoit une de ces annonces « envoie-moi tout ça dans un trou noir », que doit-il vérifier ? Comme le résultat de cette annonce est de jeter tout le trafic, une attaque avec une annonce mensongère, ou bien une erreur d'un opérateur maladroit, pourrait avoir de sérieuses conséquences. Notre RFC recommande donc un certain nombre de tests de vraisemblance : vérifier que le pair est autorisé à annoncer un préfixe couvrant celui qu'il annonce avec BLACKHOLE, et vérifier que BLACKHOLE avec ce pair a été spécifiquement permis (le RFC recommande plus loin que ce ne soit pas permis par défaut). Même chose s'il y a des serveurs de route (RFC 7947) sur le trajet.

Par contre, il faut, pour le cas spécifique des annonces BLACKHOLE, débrayer les techniques de validation comme celle du RFC 6811. Par exemple, si un ROA (Route Origin Authorisation, RFC 6482) autorise une longueur maximale de préfixe de /48, l'annonce BLACKHOLE de longueur /128 doit quand même être acceptée.

À des fins de traçabilité, pour faciliter l'analyse a posteriori d'une attaque, et du traitement qu'elle a reçu, le RFC recommande de journaliser toutes les annonces BLACKHOLE. (Cela permettra, par exemple, de repérer les pairs qui abusent du mécanisme, cf. section 6.)

Si vous travaillez chez un éditeur de logiciels pour routeurs, n'oubliez pas les conseils de la section 4, destinés aux programmeurs. D'abord, l'acceptation des annonces « trou noir » ne devrait pas être faite par défaut. Le RFC demande qu'une action explicite de l'administrateur réseau soit nécessaire. D'autre part, pour ne pas avoir à taper la valeur numérique de cette communauté, le RFC suggère de permettre une valeur texte à indiquer, par exemple blackhole.

Quelques petits points sur la sécurité pour finir (section 6). D'abord, bien se rappeler que BGP n'a par défaut aucun mécanisme pour empêcher ou détecter les modifications des annonces. Si un attaquant actif retire ou ajoute la communauté BLACKHOLE, ça ne se voit pas. Même le futur BGPSec ne l'empêchera pas, puisqu'il ne protège pas les communautés. Il y a donc des possibilités d'attaques par déni de service de ce côté.

C'est entre autre pour cela que le RFC demande qu'on vérifie qu'un pair qui annonce un préfixe avec BLACKHOLE est autorisé à le faire (RFC 7454, section 6.2.1.1.2).


Téléchargez le RFC 7999


L'article seul

Le routeur Turris Omnia

Première rédaction de cet article le 19 octobre 2016


Je viens d'installer chez moi un routeur Turris Omnia. Ça fait quoi et ça sert à quoi ?

Voici ce routeur avec ses copains et copines (sonde RIPE Atlas et Raspberry Pi de supervision) : (Version non réduite) Rassurez-vous, on peut contrôler par un bouton la luminosité des diodes (très intense par défaut).

Le Turris Omnia est avant tout un routeur pour la maison ou la petite entreprise. En tant que routeur, il... route, c'est-à-dire qu'il fait passer les paquets d'un réseau à l'autre, en l'occurrence entre le réseau de la maison et celui du FAI et, via ce dernier, à tout l'Internet. C'est donc l'équivalent de la box qui, en France (mais pas ailleurs) est souvent fournie par le FAI.

La différence principale est que l'Omnia ne comprend que du logiciel libre et est ouvert, au sens où on est super-utilisateur sur cette machine et où on peut la configurer comme on veut, contrairement aux boxes fermées dont on ne sait pas exactement ce qu'elles font (elles peuvent par exemple surveiller le trafic, même local). L'Omnia n'est pas conçu par une boîte commerciale mais par le registre du .cz, une organisation sans but lucratif (qui développe des tas de choses intéressantes).

D'autre part, des tas de services qui devraient être de base en 2016 (IPv6, validation DNSSEC) sont disponibles en série sur l'Omnia.

Si vous n'êtes pas technicien, je vous préviens que l'Omnia est installable et configurable sans trop de difficultés mais que toute adaptation un peu sérieuse nécessite, pour l'instant, de bonnes compétences d'administrateur système et réseau.

Suivons maintenant l'ordre chronologique de la mise en route. Commençons par le matériel. Voici l'Omnia vue de devant, posée sur le T-shirt (optionnel...). Le port USB peut servir de console série (je n'ai pas encore essayé) : (Version non réduite).

Et l'arrière de la boîte. Les antennes Wi-Fi ne sont pas encore montées (les connecteurs dorés en haut). Le port SFP est rare sur ce genre de routeurs à la maison, mais je ne l'ai pas encore utilisé (il peut permettre des connexions directes à une fibre optique, par exemple) : (Version non réduite).

Et voici l'Omnia ouverte, pour les amateurs d'électronique (la documentation du matériel est en ligne) : (Version non réduite). Curieusement, une vis avait été oubliée à l'intérieur... Le Turris Omnia a 1 ou 2 Go de RAM (j'ai le modèle à 1 Go), un processeur ARM à 1,6 Ghz, une Flash de 8 Go, et quelques trucs que les électroniciens adoreront comme des ports GPIO.

Branchons-la, maintenant. Je suis abonné chez Free et, par défaut, c'est leur boitier qui fait l'interface physique avec la ligne ADSL (de toute façon, l'Omnia n'a pas de prise adaptée, à moins de passer par le SFP ?). J'ai donc décidé de garder la Freebox, mais elle s'occupe uniquement de la télévision, du téléphone fixe, et du branchement à l'ADSL. Tout le routage, le réseau local et le Wi-Fi sont faits par l'Omnia. Je laisse donc le Freebox Player (la boîte qui sert à la télé) branchée au Freebox Server (la Freebox proprement dit), comme avant. Et je passe la Freebox en mode « bridge ». Avec cette configuration, la télévision classique continue à fonctionner (regarder la télévision, gérer ses enregistrements via http://mafreebox.freebox.fr/, etc). Le téléphone marche aussi. Pour le reste, je branche la prise WAN de la Turris Omnia en Ethernet, sur le commutateur du Freebox Server. Les autres machines sont branchées sur le commutateur de l'Omnia (ou utilisent son Wi-Fi). Il y a cinq ports Ethernet utilisables.

Une fois l'Omnia et au moins un PC branché, on configure le routeur via le Web, en se connectant à http://192.168.1.1/ (rassurez-vous, tout cela est bien expliqué dans le joli manuel papier de quatre pages livré avec l'Omnia, ou bien en ligne. Il y a deux interfaces Web de configuration du Turris Omnia, Foris, orientée débutant, et spécifique à l'Omnia, et LuCI, bien plus riche, dont je parlerai plus longuement après. Voici ce que voit le célèbre M. Michu, lorsqu'il utilise Foris : Free ne fournit apparemment pas de mécanisme pour la configuration automatique d'IPv6, il a donc fallu la faire à la main, statiquement.

Contrairement au Turris précédent, cette fois, on n'est plus obligé de parler la langue de Karel Čapek avec l'Omnia. Presque tout est traduit. (Mais pas encore les divers HOWTO en ligne.) C'est un progrès appréciable pour le non-polyglotte qui, en 2014, avec l'ancien Turris, recevait des notifications du genre « Upozorneni od Vaseho routeru Turris ##### Oznameni o aktualizacich ##### • Nainstalovaná verze 82 balíku updater... ». La documentation de Foris est très détaillée, et il est recommandé de la lire (par exemple pour configurer le Wi-Fi, lorsque Foris demande à M. Michu s'il veut du 2,4 GHz ou du 5 GHz...)

Si on découvre des bogues à signaler, il faut écrire à info@turris.cz qui répond bien. Il y a aussi un canal IRC #turris à Freenode (peu d'activité). Questions forums collectifs, il y avait un système de forums (avec les menus uniquement en tchèque) qui a été abandonné au profit de Discourse, que je recommande d'utiliser (on a des réponses). Il est apparemment nécessaire, pour se loguer, d'avoir mojeID (ce que j'utilise) ou bien un compte sur un GAFA.

Ensuite, tout fonctionne, le routeur route, on peut regarder des vidéos de chats, envoyer du courrier, parler avec les copains en XMPP, télécharger de la culture, etc.

Notez que le routeur est sécurisé par défaut. Le pare-feu interne, dans sa configuration d'origine, bloque les connexions entrantes. (IPv4 et IPv6, bien sûr, une fonction qui manque terriblement à la Freebox, cf. RFC 6092.) De même, le routeur a SSH et un résolveur DNS mais n'accepte pas les connexions SSH ou DNS de l'extérieur. (Parfois, c'est même trop sécurisé.)

Une autre particularité du Turris Omnia est que le routeur se met à jour tout seul, récupérant automatiquement les nouvelles versions des logiciels, afin de corriger notamment les failles de sécurité (c'est évidemment configurable, via l'onglet Updater de Foris). C'est en effet une défaillance courante chez ces petits engins installés à la maison : le code n'est pas mis à jour et de vieilles failles durent longtemps. Tous les matins, on peut voir sur Foris ce qui a été changé :

On peut aussi le recevoir via le système de notification par courrier. Le Turris peut envoyer des messages via les MTA de NIC.CZ ou bien via le vôtre si vous la configurez ainsi (dans Maintenance).

Le Turris permet également d'envoyer ses données de trafic dans le nuage. Ce n'est évidemment pas activé par défaut mais, si on veut aider la science, cela se fait par l'onglet Data collection de Foris (« we'd like to inform you that you agreed with our EULA regarding data collection of your router »). Une fois cet envoi activé, et un compte sur le portail créé via le Turris, on pourra se connecter sur le portail (mojeID était nécessaire mais ce n'est plus le cas) et voir des jolis graphes de son trafic :

Naturellement, l'administrateur système consciencieux, même s'il se nomme Michu, va faire des sauvegardes. L'interface Foris a une option Configuration backup dans son onglet Maintenance.

Passons maintenant à l'interface Web avancée, LuCI. Elle n'est pas spécifique à l'Omnia et est au contraire bien connue des utilisateurs d'OpenWrt, système sur lequel est bâti l'Omnia. Ce n'est pas génial d'avoir deux interfaces Web pour la configuration, je trouve. Mais LuCI est indispensable pour les fonctions avancées, comme la configuration du pare-feu. Voici l'écran principal de LuCI :

LuCI peut servir à regarder l'état de certaines fonctions, ici le pare-feu :

Mais aussi à configurer des fonctions comme, ici, le commutateur interne avec ses VLAN (je n'ai pas encore testé mais cela semble nécessaire si on veut connecter le Freebox Player au réseau local) :

On peut aussi installer des programmes supplémentaires depuis LuCI. Le premier que j'ai mis était Majordomo (rien à voir avec le gestionnaire de listes de diffusion du même nom). Il permet d'intéressantes statistiques par machine (là aussi, quelque chose qui me manque sur la Freebox) :

Le vrai geek va sans doute vouloir se connecter à son beau routeur libre en SSH (chose qu'on ne peut certainement pas faire avec la Freebox...). Une fois le serveur activé (Advanced administration dans Foris mais attention avec SSH, une bogue sérieuse est décrite plus loin) :

% ssh root@turris 
Password:

BusyBox v1.23.2 (2016-09-05 13:26:40 CEST) built-in shell (ash)

  _______  _    _  _____   _____   _____   _____ 
 |__   __|| |  | ||  __ \ |  __ \ |_   _| / ____|
    | |   | |  | || |__) || |__) |  | |  | (___  
    | |   | |  | ||  _  / |  _  /   | |   \___ \ 
    | |   | |__| || | \ \ | | \ \  _| |_  ____) |
    |_|    \____/ |_|  \_\|_|  \_\|_____||_____/ 
                                                 


root@turris:~# sensors
armada_thermal-virtual-0
Adapter: Virtual device
temp1:        +86.1°C  
    

Notez que je ne connais pas de moyen de connaitre le condensat de la clé publique SSH créée, depuis l'interface Web. On ne peut donc pas vérifier, la première fois, qu'on se connecte bien à son Turris Omnia.

Le Turris Omnia utilise OpenWrt, un Unix (avec noyau Linux). La plupart des commandes seront donc familières aux unixiens :

    

root@turris:~# uptime
 11:32:39 up 1 day,  3:35,  load average: 0.02, 0.05, 0.01

root@turris:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p1            7.3G    180.5M      7.1G   2% /
tmpfs                   503.7M      6.9M    496.9M   1% /tmp
tmpfs                   512.0K      4.0K    508.0K   1% /dev

root@turris:~# dig fr.wikipedia.org

; <<>> DiG 9.9.8-P4 <<>> fr.wikipedia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38235
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;fr.wikipedia.org.		IN	A

;; ANSWER SECTION:
fr.wikipedia.org.	3	IN	A	91.198.174.192

;; Query time: 7 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Oct 19 11:36:54 UTC 2016
;; MSG SIZE  rcvd: 61

root@turris:~# uname -a
Linux turris 4.4.13-05df79f63527051ea0071350f86faf76-7 #1 SMP Mon Sep 5 13:01:10 CEST 2016 armv7l GNU/Linux

Pour mémoire, l'ancien Turris, avant l'Omnia, affichait :

root@turris:~# uname -a
Linux turris 3.10.18-b09ae823eeafb345725b393bc5efbba7 #1 SMP Tue May 6 16:24:28 CEST 2014 ppc GNU/Linux

Et n'avait que 250 Mo de stockage.

Le résolveur par défaut du Turris Omnia, l'excellent Knot Resolver (produit par la même organisation que Turris), valide avec DNSSEC (comme tout le monde devrait faire, en 2016). Dommage, il reste encore des sérieuses bogues (comme une mauvaise indication du résultat ou comme l'impossibilité de couper la validation).

Un des avantages du shell est qu'on peut faire tout ce qu'on veut. Ainsi, le système de sauvegarde par l'interface Foris dont je parlais plus haut ne sauvegarde que /etc/config. Si on veut tout garder, on peut le faire avec un script et cron.

Pour faire quoi que ce soit sur l'Omnia, il vaut mieux connaitre OpenWrt (son Wiki, ses forums...) Par exemple, si vous préférez joe à vi (et, non, je n'ai pas trouvé d'emacs sur OpenWrt, système conçu pour des engins contraints en ressources matérielles) :

root@turris:~# opkg list | grep -i editor
joe - 4.2-1 - Joe is world-famous Wordstar like text editor, that also features Emacs and Pico emulation
nano - 2.6.0-1 - Nano (Nano's ANOther editor, or Not ANOther editor) is an enhanced clone of the Pico text editor.
vim - 7.4-3 - Vim is an almost compatible version of the UNIX editor Vi. (Tiny build)
zile - 2.3.24-4 - Zile is a small Emacs clone. Zile is a customizable, self-documenting real-time display editor. Zile was written to be as similar as possible to Emacs; every Emacs user should feel at home with Zile.
...

root@turris:~# opkg install joe
Installing joe (4.2-1) to root...
Downloading https://api.turris.cz/openwrt-repo/omnia/packages//packages/joe_4.2-1_mvebu.ipk.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  238k  100  238k    0     0   589k      0 --:--:-- --:--:-- --:--:--  602k
Configuring joe.
    

La configuration IPv6 ne s'est pas faite toute seule (ce n'est pas entièrement la faute du Turris mais un peu quand même). Par défaut, le Turris distribue sur le réseau local des ULA (RFC 4193) comme fde8:9fa9:1aba:0:X:W:Y:Z. Pour réaliser la configuration en étant connecté à Free, j'ai suivi un bon HOWTO de OpenWrt mais il y manque un point important, la route par défaut statique (à ce sujet, cela vaut aussi la peine de consulter la documentation OpenWrt sur le réseau). Donc, ce que j'ai du faire :

  • Relever l'adresse locale au lien utilisée par l'Omnia sur la patte qui le connecte à la Freebox (ifconfig eth1),
  • Sur la Freebox (http://mafreebox.freebox.fr/, « Paramètres de la Freebox » puis « Configuration IPv6 »), mettre cette adresse en Next hop pour le préfixe que nous a alloué Free,
  • Au passage, notez sur la Freebox la valeur de ce préfixe alloué,
  • Configurer le réseau de l'Omnia (/etc/config/network) comme indiqué dans le HOWTO ci-dessus,
  • Ajouter une route statique sur l'Omnia (le HOWTO OpenWrt n'en parle pas).

Cela donc un /etc/config/network qui ressemble à (si 2001:db8:cafe:1234::1:fe/64 est le préfixe IPv6 alloué par Free, celui qu'on trouve dans l'interface Web de la Freebox) :

config interface 'lan'
	option ifname 'eth0 eth2'
	option force_link '1'
	option type 'bridge'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.1.1'
	option ip6addr '2001:db8:cafe:1234::1:fe/64'
	option ip6prefix '2001:db8:cafe:1234::/64'
	option ip6gw '2001:db8:cafe:1234::1'
	option ip6assign '64'
	option mtu '1452'

config interface 'wan'
	option ifname 'eth1'
	option proto 'dhcp'
        option mtu '1452'

config interface 'wan6'
	option ifname '@wan'
	option _orig_bridge 'false'
	option proto 'static'
	option ip6addr '2001:db8:cafe:1234::2/126'
	option ip6gw '2001:db8:cafe:1234::1'
	option ip6prefix '2001:db8:cafe:1234::/64'

# Route par défaut statique
config route6
	option interface 'wan6'
	option target '::/0'
	option gateway 'fe80::f6ca:e5ff:fe4d:1f41'

Si vous êtes attentifs, vous aurez remarqué qu'on force une MTU à 1 452 octets. L'IPv6 de Free en ADSL n'étant pas natif (mais un tunnel 6rd, cf. RFC 5969), ce réglage était nécessaire pour éviter les symptômes habituels d'un problème de PMTUD (ping qui marche mais pas curl, etc).

Si votre FAI ne fournit pas IPv6, le Turris Omnia permet d'établir un tunnel, en théorie, mais je n'ai jamais testé.

Autre jouet amusant, le Turris a un pot de miel configurable, pour SSH et telnet. Les sessions capturées sont également transmises aux responsables du projet et visibles via le portail des utilisateurs (mon premier « pirate » venait de Turquie et a tapé uname -a).

Passons maintenant aux problèmes, car le logiciel a des bogues embêtantes. J'ai eu beaucoup d'ennuis avec le serveur NTP. Rien ne marchait. J'ai du finalement désactiver le serveur par défaut (/etc/config/system, option enabled '0') et ntpclient, puis installer ntpd qui, lui, fonctionne. (Normalement, sur OpenWrt, cela aurait du marcher tout seul, la doc le dit). Attention, supprimer avec opkg le paquetage ntpclient ne suffit pas, la mise à jour automatique de l'Omnia le réinstalle. Maintenant, la synchronisation temporelle marche :

root@turris:~# ntpq
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+mx4.nic.fr      138.96.64.10     2 u  585 1024  377    8.661   -1.611   1.186
 webcgi1-g20.fre .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 webcgi2-g20.fre .INIT.          16 u    - 1024    0    0.000    0.000   0.000
+pob01.aplu.fr   40.179.132.91    2 u  555 1024  377   10.465   -4.789   4.553
-host3.nuagelibr 138.96.64.10     2 u  193 1024  377   10.405    3.660   2.096
 vel.itat.io     131.188.3.223    2 u   98 1024    1   25.894    0.007   0.230
*cluster004.lino 82.95.215.61     2 u  557 1024  377    7.166   -0.876   0.973

Et les machines du réseau local peuvent se synchroniser sur le Turris. (Au passage, la commande ntpq est dans le paquetage ntp-utils.)

Second problème sérieux, avec le serveur SSH. Pour un certain nombre d'utilisateurs de l'Omnia, la création des clés SSH de la machine se passe mal et des fichiers de taille zéro sont créés (et cela ne se produit pas uniquement, contrairement à ce que racontent certains, lors d'une coupure de courant). Cela empêche évidemment le serveur SSH de démarrer. On ne peut donc pas se connecter au shell pour arranger les choses. Il faut alors utiliser le port USB comme port série (je n'ai pas essayé) ou bien réparer le problème entièrement depuis LuCI (System puis Custom commands) en exécutant de quoi rétablir le système. Et l'interface de LuCI est pénible pour cela (par exemple, ssh-keygen -N "" ne marchera pas car LuCI supprime la chaîne vide...). J'ai donc du définir des commandes rm -f /etc/ssh/ssh_host_ecdsa_key /etc/ssh/ssh_host_ecdsa_key.pub /etc/ssh/ssh_host_ecdsa_key /etc/ssh/ssh_host_ecdsa_key.pub /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key.pub /etc/ssh/ssh_host_dsa_key /etc/ssh/ssh_host_dsa_key.pub /etc/ssh/ssh_host_ed25519_key /etc/ssh/ssh_host_ed25519_key.pub (eh non, pas droit aux jokers) puis ssh-keygen -A puis /etc/init.d/sshd start.

Autre méthode pour s'amuser, jouer avec les VLAN. En faisant une erreur dans la configuration du commutateur de l'Omnia, j'avais déclenché une tempête de trafic interne qui rendait le routeur totalement inutilisable. Même pas moyen de se connecter en SSH pour réparer. L'erreur étant dans la configuration, redémarrer ne servait à rien (l'Omnia n'a apparemment pas de mémorisation temporaire des configurations réseau potentiellement dangereuses, comme ça existe sur JunOS). Le port série aurait peut-être été une solution mais il y avait plus simple : remettre l'Omnia à sa configuration d'usine, se reconnecter, et restaurer la configuration sauvegardée.

Voilà, prochaine étape, installer un serveur SNMP...

Quelques autres lectures sur le Turris Omnia :

PS : si vous voulez acheter un Turris Omnia (j'ai eu le mien via le crowdfunding), voyez cette annonce.


L'article seul

Google détourné par Orange vers la place Beauvau

Première rédaction de cet article le 17 octobre 2016


Aujourd'hui, bien des clients d'Orange ont eu la mauvaise surprise de ne pas pouvoir visiter Google. La plupart n'avaient pas de messages d'erreur précis, juste une longue attente et un message d'erreur vague du genre « timeout ». Certains avaient la désagréable surprise de voir apparaitre une page menaçante, les accusant d'avoir voulu se connecter à un site Web terroriste. À l'origine de ce problème, une erreur de configuration dans les résolveurs DNS d'Orange, en raison de la fonction de censure administrative du Web.

D'abord, voyons l'étendue du problème. Il n'affectait que les clients d'Orange, et seulement ceux qui utilisaient les résolveurs DNS de l'opérateur (voir plus loin pour une définition des termes techniques). Les sites inaccessibles incluaient http://www.google.fr/, mais aussi http://fr.wikipedia.org/, http://www.ovh.com/ et quelques autres. Beaucoup d'utilisateurs ont imputé le problème à Google à tort (mot-croisillon #GoogleDown sur Twitter, ce qui était complètement erroné).

Il est rapidement apparu que le problème venait du DNS. Ce système permet d'associer à un nom de domaine (comme www.afnic.fr ou youtube.com) des données techniques, comme l'adresse IP de la machine serveuse. Cette adresse IP est indispensable au bon fonctionnement de l'Internet. Résoudre (traduire) un nom de domaine en adresse IP est le travail de deux sortes de serveurs DNS : les serveurs faisant autorité, qui connaissent le contenu d'une partie du DNS (par exemple, les serveurs faisant autorité gérés par l'AFNIC connaissent le contenu de .fr, les serveurs faisant autorité pour cfeditions.com connaissent le contenu de cfeditions.com, etc), et les résolveurs. Ces derniers ne connaissent rien mais, demandant aux serveurs faisant autorité, et mémorisant leur réponse (ce que les informaticiens appellent, bizarrement, « cacher »), ils obtiennent l'information qu'ils distribuent aux utilisateurs. Les résolveurs sont typiquement gérés par les FAI (comme Orange) mais il existe aussi des serveurs publics comme ceux de FDN. L'utilisateur de l'Internet n'a en général pas à s'en soucier, son FAI lui indique automatiquement ses résolveurs et tout roule.

Normalement, donc, un résolveur n'a pas de données propres et se contente de relayer entre l'utilisateur et le serveur faisant autorité. Mais, comme quasiment toute communication Internet commence par une requête DNS, il est tentant, lorsqu'on souhaite contrôler l'usage de l'Internet, de demander aux résolveurs de mentir, c'est-à-dire de donner une information qui n'est pas celle venue du serveur faisant autorité. C'est ce qui est prévu en France en application du décret n° 2015-125 du 5 février 2015. Le Ministère de l'Intérieur envoie aux principaux FAI une liste des domaines à bloquer (un article de Numérama détaille ce processus) et ceux-ci déploient la configuration nécessaire dans leurs résolveurs.

Mais, ce lundi matin, lorsqu'on interrogeait les résolveurs d'Orange au sujet de l'adresse IP de www.google.fr, au lieu de répondre avec l'adresse contenue dans les serveurs faisant autorité pour google.fr (serveurs gérés par Google), par exemple 216.58.211.99, ils répondaient 90.85.16.52, une adresse appartenant à un sous-traitant du Ministère de l'Intérieur. Lorsqu'un navigateur Web se connecte à cette adresse, il obtient normalement une page l'avertissant que le nom de domaine fait partie de ceux qui sont bloqués, et un motif est indiqué (promotion du terrorisme, par exemple, comme dans l'image ci-dessus).

Mais ce serveur était bien trop faible pour encaisser l'énorme trafic de Google et de Wikipédia, et a vite cessé de fonctionner correctement. C'est ce qui explique l'absence de réponse fréquemment rencontrée, faisant croire aux utilisateurs que Google était en panne. (Une autre raison est que la plupart des accès à Google se font désormais en HTTPS et que le serveur du Ministère ne gère pas HTTPS, ne répondant pas, même pas par un refus de connexion.)

Comment une telle bavure a pu se produire ? L'erreur était-elle dans la liste envoyée par le Ministère de l'Intérieur ou bien uniquement chez Orange ? On n'a évidemment pas d'information à ce sujet (les pannes Internet ne font jamais l'objet d'analyses indépendantes et publiques, ce qui explique que la sécurité ne progresse guère). Tout est possible, y compris des erreurs humaines qui sembleraient invraisemblables (mais on voit vraiment de tout dans le monde réel). Une des hypothèses les plus intéressantes (elle explique notamment pourquoi il y a eu plusieurs noms touchés) est celle d'un fichier de test installé par erreur à la place du « bon ».

Au fait, comment sait-on que les clients d'Orange (et uniquement eux) recevaient cette fausse information ? En effet, dans l'Internet d'aujourd'hui, complexe et international, une observation faite en un point n'est pas suffisante. Les clients d'Orange peuvent s'exclamer en chœur « Google est planté » et ceux de Free répondre « non, tout va bien ici ». Et les deux groupes ont raison... de leur point de vue. J'ai utilisé, outre les mesures faites par des experts chez différents FAI (merci, merci, merci), le réseau des sondes RIPE Atlas. Ces petits boitiers très utiles permettent de mesurer un certain nombre d'indicateurs techniques depuis de nombreux points du réseau. (Des détails pour les techniciens figurent à la fin de cet article.)

La panne elle-même, c'est-à-dire l'envoi de fausses informations par les résolveurs DNS d'Orange, a duré environ une heure. Mais son effet avait été prolongé par la mémorisation (les fameux « caches ») des informations dans certains composants du réseau (par exemple la « box » chez l'utilisateur). Cela fait que, plusieurs heures après, Google ou Wikipédia étaient toujours inaccessibles pour certains utilisateurs.

Les leçons à en tirer ? Le DNS est un composant critique de l'Internet et sa résilience, sa capacité à résister aux pannes et à repartir ensuite, est donc cruciale. D'où l'importance de l'Observatoire de la résilience Internet. Toute interférence avec le fonctionnement du DNS, que ce soit pour des raisons politiques ou autres, le met potentiellement en péril. C'est ce qu'avait analysé le rapport du Conseil Scientifique de l'AFNIC « Conséquences du filtrage Internet par le DNS », qui mettait bien en évidence le risque de tels filtrages ou blocages. Une bavure analogue à celle de Google était déjà arrivée au Danemark mais il semble que personne ne tire de leçons de l'expérience.

Que peuvent faire les utilisateurs face à de tels risques ? Le problème de fond est bien évidemment politique (la censure administrative, effectuée au mépris des contraintes opérationnelles) et doit donc être traité politiquement. Mais existe-t-il des solutions techniques ? Pour l'instant, la meilleure est d'avoir son propre résolveur DNS. Notez bien que je ne parle pas forcément d'un résolveur par machine à la maison. Cela peut être fait dans un équipement partagé, comme ce que permet le routeur Turris Omnia. Beaucoup de gens proposaient d'utiliser un résolveur DNS public. Ce n'est pas forcément une bonne solution. Google Public DNS a tous les inconvénients des services Google (bien expliqués dans le récent livre de Tristan Nitot). Cisco OpenDNS y ajoute le fait qu'il s'agit d'un résolveur menteur, comme ceux des principaux FAI français. Ceux d'OpenNIC marchent rarement et, de toute façon, sont une racine alternative, avec les inconvénients que cela présente. Et les résolveurs de FDN ? Ils sont honnêtes mais ils partagent un inconvénient commun avec presque tous les résolveurs DNS publics : ils n'offrent aucune authentification et rien ne garantit donc qu'on parle bien au résolveur qu'on veut. (C'est ainsi que Google Public DNS a déjà été détourné.)

Quelques lectures sur cet incident :

Le reste de cet article est uniquement pour les techniciens, attention. Le script utilisé pour interroger les sondes Atlas est décrit ici. La commande exacte était atlas-resolve --as 3215 --requested 100 www.google.fr, l'AS 3215 étant celui d'Orange.

La panne semble avoir duré d'environ 07:40 UTC à 08:35. Un utilisateur d'Orange qui testait avec dig voyait :

% dig A +short @192.168.10.1 www.google.fr
90.85.16.52

% dig A +short @8.8.8.8 www.google.fr
172.217.20.35
  

Les sondes Atlas, elles, voyaient :

% atlas-resolve --as 3215 -r 100 www.google.fr
[74.125.24.94] : 1 occurrences
[216.58.208.195] : 2 occurrences
[74.125.206.94] : 2 occurrences
[216.58.210.35] : 2 occurrences
[216.58.210.227] : 3 occurrences
[216.58.211.67] : 3 occurrences
[172.217.16.67] : 2 occurrences
[216.58.213.35] : 1 occurrences
[216.58.211.99] : 2 occurrences
[172.217.18.227] : 2 occurrences
[216.58.204.3] : 1 occurrences
[90.85.16.52] : 75 occurrences
[216.58.208.227] : 2 occurrences
Test #6886264 done at 2016-10-17T08:06:14Z
  

Remarquez que certaines sondes, minoritaires, voient la vraie valeur, sans doute parce que le réseau où elles sont situées n'utilise pas les résolveurs DNS d'Orange. Mais la grande majorité voit le 90.85.16.52 mensonger. Un autre exemple avec les sondes Atlas, mais en leur demandant d'utiliser un autre résolveur (Google Public DNS) :

 % atlas-resolve --as 3215 -r 100 -e 8.8.4.4 www.google.fr
Nameserver 8.8.4.4
[172.217.18.227] : 3 occurrences
[216.58.219.67] : 1 occurrences
[172.217.23.67] : 1 occurrences
[216.58.210.3] : 1 occurrences
[216.58.211.67] : 8 occurrences
[172.217.16.67] : 3 occurrences
[216.58.210.163] : 1 occurrences
[172.217.16.163] : 2 occurrences
[172.217.19.131] : 8 occurrences
[216.58.201.35] : 4 occurrences
[74.125.206.94] : 4 occurrences
[216.58.213.99] : 1 occurrences
[172.217.23.99] : 1 occurrences
[172.217.20.35] : 5 occurrences
[216.58.208.227] : 10 occurrences
[216.58.210.131] : 1 occurrences
[216.58.204.67] : 2 occurrences
[216.58.211.99] : 11 occurrences
[216.58.210.227] : 8 occurrences
[216.58.212.99] : 2 occurrences
[172.217.23.3] : 1 occurrences
[216.58.204.3] : 1 occurrences
[216.58.208.163] : 1 occurrences
[216.58.210.195] : 6 occurrences
[216.58.192.99] : 1 occurrences
[216.58.208.195] : 10 occurrences
Test #6886273 done at 2016-10-17T08:13:06Z
  

Cette fois, personne ne voit le mensonge (notez que les serveurs DNS de Google servent des réponses très différentes, mais qui sont toutes dans un réseau Google). Notez aussi que d'autres services Google comme Gmail ou comme le spyware Analytics n'avaient aucun problème.

Wikipédia faisait partie des victimes, comme Google :

% atlas-resolve --as 3215 -r 100 fr.wikipedia.org
[91.198.174.192] : 21 occurrences
[90.85.16.52] : 73 occurrences
[208.80.154.224] : 1 occurrences
Test #6886283 done at 2016-10-17T08:22:22Z
  

Merci à tou·te·s c·eux·elles qui m'ont envoyé des informations et des résultats de mesure. Ça, c'est l'Internet, la coopération, l'échange d'informations et la décentralisation.


L'article seul

RFC 7960: Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows

Date de publication du RFC : Septembre 2016
Auteur(s) du RFC : F. Martin (LinkedIn), E. Lear (Cisco Systems), T. Draegen (dmarcian), E. Zwicky (Yahoo), K. Andersen (LinkedIn)
Pour information
Réalisé dans le cadre du groupe de travail IETF dmarc
Première rédaction de cet article le 11 octobre 2016


Le mécanisme DMARC permet d'indiquer dans le DNS la politique d'un domaine concernant l'authentification du courrier. Si je reçois un message prétendant venir de ma-banque.example, et qu'il n'est pas authentifié (ni SPF, ni DKIM, ni autre chose), comment savoir si c'est parce que ma banque est nulle en sécurité du courrier, ou bien parce que le message est un faux ? DMARC (normalisé dans le RFC 7489) permet de répondre à cette question en publiant un enregistrement qui indique si le courrier est censé être authentifié ou pas. Comme toutes les techniques de sécurité, ce mécanisme est imparfait et il pose notamment des problèmes avec les messages indirects. Par exemple, si vous avez une adresse à votre ancienne université, alice@univ.example et que le courrier qui lui est adressé est automatiquement transmis à votre adresse professionnelle, alice@evilcorp.example, comment DMARC va-t-il réagir avec cette indirection ? C'est ce qu'explore ce RFC.

Voici la politique DMARC de Gmail. Elle est tolérante (p=none, accepter les messages non authentifiés) :

    
% dig TXT _dmarc.gmail.com
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59294
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
_dmarc.gmail.com.	600 IN TXT "v=DMARC1; p=none; rua=mailto:mailauth-reports@google.com"
...

_dmarc.paypal.com.	300 IN TXT "v=DMARC1; p=reject; rua=mailto:d@rua.agari.com; ruf=mailto:dk@bounce.paypal.com,mailto:d@ruf.agari.com"

La question de départ de l'administrateur système est « si je mets une politique DMARC restrictive (genre p=reject), vais-je perdre des courriers légitimes, à cause d'indirections comme les listes de diffusion ? » (section 1 du RFC). Il est d'autant plus difficile de répondre à cette question que l'architecture du courrier électronique est complexe et mal spécifiée (RFC 5598). Bien des logiciels ne suivent pas les règles, d'autant plus que beaucoup de ces règles n'ont pas été explicites dès le début. (Un bon exemple : avec un .forward, le serveur de courrier doit-il garder l'expéditeur indiqué dans l'enveloppe du message ? Essayez de trouver un RFC qui spécifie cela !)

La section 2 de notre RFC décrit les causes des problèmes DMARC. Si un message est légitime (le destinataire veut le recevoir), et qu'il est en outre techniquement correct, un problème, au sens de ce RFC, est quand la politique de DMARC (qui peut être de rejet) est appliquée à ce message, parce qu'il a été transmis indirectement. C'est injuste. Évidemment, si la politique DMARC est p=none (ne rien faire), ce n'est pas un vrai problème. Mais un p=reject peut être très ennuyeux.

Première cause de problèmes, des différences entre les identificateurs utilisés. DMARC n'authentifie pas directement, il dépend de SPF (RFC 7208) et DKIM (RFC 6376) pour cela. Ce qui intéresse l'utilisateur, évidemment, c'est le nom dans le champ From: (RFC 5322) du message. Pour lui, c'est ça l'expéditeur. Mais DKIM, et surtout SPF, n'ont pas la même conception : ils peuvent utiliser d'autres identificateurs. DMARC considère que l'accord (alignment, cf. RFC 7489, section 3.1) entre les identificateurs authentifiés par SPF et DKIM, et le champ From: du message peut être strict ou laxiste. « Strict » indique une correspondance parfaite, laxiste se limite à vérifier que le nom de domaine est le même.

Le principal identificateur utilisé par SPF est celui donné par la commande MAIL FROM dans la session SMTP (RFC 5321). C'est la principale cause de désaccord : si SPF authentifie cet identificateur et qu'il est différent de l'adresse utilisée dans le champ From: de l'en-tête du message, que faire ?

Deuxième cause de problème, le relayage d'un message. Si Bob bob@isp.example écrit à alice@univ.example, et qu'elle (ou son administrateur système) a demandé un relayage automatique vers alice@evilcorp.example, les serveurs de courrier de evilcorp.example verront un message prétendant être de isp.example, mais transmis par les serveurs de univ.example... SPF sera content ou pas, selon la façon exacte dont a été fait le relayage (en préservant le MAIL FROM ou pas). DMARC ne sera jamais content car, si le MAIL FROM a été changé (reflétant le relais), SPF authentifiera mais il n'y aura plus d'accord entre les identificateurs.

Évidemment, si le message est modifié en cours de route, c'est encore pire. SPF ne protège pas l'intégrité du message, mais DKIM le fait. Mais qui diantre se permet de modifier les messages ? Hélas, pas mal de gestionnaires de listes de diffusion le font. DKIM a une option (déconseillée... voir la section 8.2 du RFC 6376) pour ne signer que le début du message, évitant ainsi que la signature soit invalidée par l'ajout, par exemple, d'un paragraphe final. Cela ne couvre que le cas des messages simples, sans MIME, où la modification est un simple ajout à la fin. Autre possibilité de DKIM pour éviter d'invalider les signatures en cas de modification du message, le mode relaxed de canonicalisation du contenu, qui permet de supporter des modifications triviales comme la transformation de N espaces consécutifs en un seul.

Reprenant le vocabulaire du RFC 5598 (relisez-le d'abord !), la section 3 de notre RFC liste les différents composants de la messagerie qui peuvent jouer un rôle dans les transmissions indirectes, et les problèmes qu'elles posent. D'abord, le MSA (Message Submission Agent.) C'est la première ligne de vérification : il fait respecter les règles d'une organisation (ADMD, ADministrative Management Domain). S'il accepte un message où le champ From: du RFC 5322 n'est pas dans un domaine contrôlé par l'ADMD, il y a des chances que DMARC râle par la suite. Le RFC cite plusieurs cas d'usage où cela se produit : la fonction « envoyer cet article à un ami » de certains sites Web, par exemple, puisque le message va partir avec le domaine du lecteur de l'article, pas avec celui du site Web. On peut trouver de nombreux autres exemples, comme un service de gestion d'agenda qui envoie des courriers de rappel, en utilisant comme expéditeur l'adresse de l'utilisateur, ce qui est plutôt une bonne chose (pour des messages du genre « l'heure de la réunion a changé ») mais peut gêner DMARC. (Mon exemple préféré est le cas où on a une adresse de courrier mais pas de moyen de soumettre du courrier via cette organisation, ce qui est fréquent avec les adresses de fonction. Par exemple, on est membre d'une organisation qui fournit des adresses à ses membres et/ou responsables, ce qui permet de recevoir du courrier, mais on n'a pas de MSA pour en envoyer, on doit donc utiliser celui d'une autre organisation.)

Et les MTA, eux, quel est leur rôle dans les problèmes DKIM ? S'il change l'encodage (par exemple en passant du « 8 bits » à l'abominable Quoted-Printable), il va invalider les signatures DKIM (la canonicalisation de DKIM ne prévoit pas des transformations aussi radicales, même si elles ne modifient pas le message final). Idem si le MTA corrige les en-têtes du message pour les rendre conformes (une tâche qui relève plutôt du MSA, le MTA devant lui, transmettre fidèlement les messages qu'il a choisi d'accepter) : cela sort également du champ de la canonicalisation DKIM et cela invalide donc les éventuelles signatures. Enfin, le changement ou la suppression de certaines parties MIME (par exemple l'élision d'un document ZIP attaché, pour des raisons de protection contre les logiciels malveillants transmis par courrier) va évidemment également rendre les signatures invalides.

Et le MDA ? Peut-il casser des choses, également ? Oui, s'il passe les messages par Sieve (RFC 5228), qui a la possibilité d'ajouter ou de retirer des en-têtes, voire de modifier le corps (extension Sieve du RFC 5703). Si les tests DMARC sont faits après le passage de Sieve, ou bien si le message est ensuite réinjecté dans le système de courrier, des problèmes peuvent se produire.

Reste le cas des intermédiaires (mediators). Ce sont les entités qui prennent un message, puis le ré-expédient (parfois après modification). Un exemple est l'alias. Via une entrée dans /etc/aliases ou bien via un .forward, ou bien via le redirect de Sieve, ou encore via encore une autre méthode, un message initialement destiné à une adresse est finalement transmis à une autre. C'est par exemple courant pour les adresses « ancien élève », que fournissent certaines universités, et qui permettent de garder à vie une adresse dans le domaine de l'établissement où on a fait ses études. Un certain nombre d'associations professionnelles fournissent un service équivalent. En général, ces intermédiaires ne cassent pas DKIM (ils ne modifient pas le message) mais, selon la façon dont ils redirigent, peuvent invalider l'autorisation SPF.

Un autre exemple d'intermédiaire classique est le gestionnaire de listes de diffusion. En plus de rediriger un message (ce qui fait que le message écrit par alice@univ.example n'est pas émis par les serveurs de courrier de l'université), ces logiciels changent souvent le message, par exemple en ajoutant une inutile étiquette [Ma jolie liste] aux sujets des messages, en ajoutant un texte à la fin (instructions de désabonnement, pourtant déjà possibles avec l'en-tête List-Unsubscribe:), en retirant des pièces jointes, ou bien (surtout dans les théocraties comme les États-Unis) en remplaçant des gros mots par des termes plus acceptables.

Toutes ces modifications vont probablement invalider les signatures DKIM (cf. RFC 6377) et faire que les messages envoyés par certains participants à la liste (ceux qui ont une politique DMARC p=reject) ne seront pas reçus par les destinataires qui testent cette politique. (Si un avis de non-remise est transmis, le logiciel de gestion de la liste peut en déduire que l'adresse n'existe pas, et désabonner d'autorité le destinataire.)

Et les filtres ? Certaines organisations insèrent dans le réseau des dispositifs qui vont analyser le courrier, par exemple à la recherche de logiciel malveillant. Souvent, ils vont modifier les messages, afin de supprimer ces contenus indésirables. Ces modifications vont évidemment invalider les signatures. Idem si on change ou supprime des URL contenus dans le message et considérés « dangereux ». Même chose avec un système anti-spam qui ajouterait un [SPAM] dans le sujet.

En revanche, le courrier reçu d'un serveur secondaire (MX de secours), qui a pris le relais pendant une panne du primaire, puis expédié le courrier quand le primaire remarche, ne pose pas de problèmes. Bien sûr, les tests SPF échoueront mais, normalement, on ne fait pas ces tests sur le courrier qui vient de son propre serveur secondaire.

Bon, voici le tour d'horizon complet de tout ce qui peut marcher mal. Mais que faire ? La section 4 du RFC s'attaque aux solutions. Elles sont nombreuses et très différentes. Mais attention : DMARC est là pour rejeter des messages considérés comme invalides. On peut arranger les choses pour que certains de ces messages « passent » mais cela va contre le but de DMARC. Si les messages sont de grande valeur (transactions financières, par exemple), il vaut mieux ne pas chercher de solutions, et simplement se contenter de messages transmis directement, ne subissant pas de traitements qui vont invalider SPF ou DKIM.

C'est d'autant plus vrai que l'écosystème du courrier électronique est très complexe. On trouve un zillion de logiciels différents, plus ou moins bien écrits. Par exemple, des gens utilisent encore Qmail, qui n'a plus eu une seule mise à jour depuis 1998. Certaines des mesures ou contre-mesures utilisées pour la sécurité du courrier sont parfaitement légales, mais vont casser tel ou tel logiciel qui est utilisé à certains endroits.

Assez d'avertissements, les solutions. D'abord, du côté de l'expéditeur. Celui-ci (ou son premier MTA) peut faire des efforts pour améliorer l'accord entre les identificateurs. Un logiciel sur info.example qui envoie du courrier pour le compte de bob@univ.example peut ainsi décider d'utiliser un en-tête From: qui ne posera pas de problème, celui du vrai envoyeur, et de mettre l'adresse de Bob dans un Reply-To:. Comme la plupart des solutions présentées dans cette section 4, elle est imparfaite (le destinataire peut se demander qui est cet envoyeur qu'il ne connait pas). Le RFC fournit de nombreux autres exemples de désaccord entre identités, qui peuvent être réparés en changeant un peu le processus d'envoi du message. Comme le disait ma grand-mère, « il y a toujours une solution, pour peu que chacun y mette du sien ».

Les envoyeurs peuvent aussi limiter le risque de modifications invalidantes, en ne signant pas trop d'en-têtes avec DKIM, ou en envoyant des messages parfaitement formés (pour éviter aux serveurs ultérieurs la tentation de les « réparer »).

Les receveurs peuvent aussi agir mais leurs possibilités sont plus limitées, note le RFC.

Entre les expéditeurs et les receveurs, il y a tous les intermédiaires qui prennent un message et le ré-expédient. Ce sont souvent eux qui causent le problème, et ils sont donc souvent en position de le réparer. Par exemple, ils peuvent changer le From: du message pour mettre le leur, ce qui permettrait à peu près n'importe quelle modification, et serait plus « franc » (puisque le message n'est plus tout à fait l'original, autant changer l'auteur...) Évidemment, dans ce cas, assez violent, il faut au minimum garder l'information sur l'émetteur originel, avec l'en-tête Original-From: (RFC 5703). Le problème est que le récepteur humain sera sans doute déconcerté par cet expéditeur (d'autant plus qu'Original-From: est peu ou pas affiché).

Comme les modifications invalident les signatures, les ré-expéditeurs pourraient les éviter, par exemple en ajoutant des en-têtes au lieu de modifier les existants, lorsqu'ils veulent ajouter un contenu (du genre « ceci est un spam »). Il serait peut-être préférable, dans certains cas, de rejeter les messages plutôt que de les modifier, ce qui cassera la vérification de signatures plus loin.

Et, en parlant des ré-expéditeurs, les listes de diffusion, pas vraiment prévues par DKIM, que faire pour elles ? Le RFC 6377 a déjà traité leur cas. Une technique courante est de modifier le champ From: pour mettre l'adresse de la liste, réduisant l'auteur original à un commentaire dans cet en-tête (avis personnel : je déteste ça). Comme cela rend difficile de répondre en privé au vrai auteur d'un message, l'ajout d'un Reply-To: peut aider. Une autre solution est d'emballer le message original dans une partie MIME message/rfc822. Cette partie resterait intact et le message emballant aurait comme expéditeur la liste. Mais peu de MUA savent afficher proprement ce genre de messages (spécialement dans le monde des mobiles).

Encore plus fasciste, le gestionnaire de liste pourrait interdire l'abonnement des gens utilisant une adresse où il y a une politique DMARC autre que p=none. (Le RFC oublie de parler du cas où une politique p=reject n'existait pas au moment de l'abonnement mais a été rajoutée après.)

Enfin, il existe aussi des solutions qui sont encore en cours de discussion à l'IETF, et dont le RFC décourage l'usage dans un environnement de production. Ce sont entre autres des extensions au modèle du RFC 7601 pour créer une chaîne d'authentification où chaque acteur important signerait le message en route. Ou, plus radical, des mécanismes stockant l'état initial d'un message avant transformation, pour pouvoir retrouver cet état original et vérifier la signature.

Bref, le problème n'est pas résolu...


Téléchargez le RFC 7960


L'article seul

RFC 7950: The YANG 1.1 Data Modeling Language

Date de publication du RFC : Août 2016
Auteur(s) du RFC : M. Bjorklund (Tail-f Systems)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF netmod
Première rédaction de cet article le 10 octobre 2016


Le protocole standard Netconf (normalisé dans le RFC 6241) permet de configurer un équipement réseau (par exemple un commutateur) à distance. Netconf fonctionne par des RPC dont les paramètres sont des actions à faire effectuer par l'équipement configuré, ou bien les nouvelles valeurs que peut prendre telle ou telle des variables de configuration de cet équipement. Mais comment savoir quelles actions sont possibles, quelles variables existent, et quelles valeurs elles peuvent prendre ? Jusqu'à présent, cela pouvait se spécifier uniquement dans une documentation en langue naturelle fournie avec l'équipement. Désormais, il est possible de spécifier ces informations dans un langage formel, YANG. La première version de YANG était normalisée dans RFC 6020, ce nouveau RFC normalise la nouvelle version, la 1.1, qui a peu de changements, mais certains cassent la compatibilité ascendante.

Ce RFC 7950 est très détaillé, plus de deux cents pages. Et je n'ai pas personnellement d'expérience pratique avec YANG. Donc, je ne donne ici qu'un très bref résumé. Un tel survol se trouve également dans la section 4 du RFC : YANG modélise les données (configuration et état) qui seront utilisées par Netconf. Ces données sont représentées sous forme arborescente. YANG est modulaire (section 5.1 du RFC), un module YANG pouvant se référer à d'autres modules. YANG définit un ensemble de types pour décrire les données (section 9 et RFC 6991). Il permet également d'indiquer les contraintes que doivent respecter les données. YANG, langage de haut niveau, ne décrit pas l'encodage utilisé sur le câble.

Notez que YANG peut être utilisé avec d'autres protocoles que Netconf, comme RESTCONF (décrit dans le Internet-Draft draft-ietf-netconf-restconf).

YANG a donc bien des points communs avec le SMI des RFC 2578 et RFC 2579. Avant Netconf, beaucoup de gens pensaient que toute la gestion des équipements réseau se ferait en SNMP, en s'appuyant sur ce modèle SMI. Si, pour la lecture des variables, SNMP s'est largement imposé, force est de constater que, pour l'écriture de variables et pour les actions, SNMP reste très peu utilisé, au profit de toute une galaxie de mécanismes privés (Web, REST, SSH + CLI, etc), galaxie que Netconf vise à remplacer. Une MIB du SMI peut donc être traduite en YANG, l'inverse n'étant pas vrai (YANG étant plus riche).

La syntaxe de YANG utilise des groupes emboîtés, délimités par des accolades. Mais une syntaxe équivalente, en XML, existe, sous le nom de Yin. Tout module YANG peut être traduit en Yin sans perte et réciproquement (voir la section 13 pour plus de détails sur Yin).

Donc, un engin donné, routeur ou autre équipement qu'on veut gérer, est décrit par des modules YANG. Lorsqu'un serveur Netconf à bord dudit engin met en œuvre un module YANG, cela veut dire qu'il permet de modifier, via Netconf, les variables décrites dans le module (le serveur typique met en œuvre plusieurs modules). Voici le début d'un module possible :

     // Only an example, not a real module. 
     module acme-system {
         namespace "http://acme.example.com/system";
         prefix "acme";

         organization "ACME Inc.";
         contact "joe@acme.example";
         description
             "The module for entities implementing the ACME system.";

         revision 2010-08-05 {
             description "Initial revision.";
         }
...

On l'a dit, YANG est arborescent. Les feuilles de l'arbre (section 4.2.2.1 du RFC) contiennent une valeur particulière, par exemple, ici, le nom de l'engin géré :

       leaf host-name {
           type string;
           description "Hostname for this system";
       }

Ici, leaf est un mot-clé de YANG qui indique une feuille de l'arbre (plus de nœuds en dessous), host-name est le nom que l'auteur du module a donné à une variable, de type « chaîne de caractères ». Lorsqu'un serveur Netconf enverra cette information à un client (ou réciproquement), elle sera encodée en XML ainsi (Netconf utilise XML pour l'encodage des messages mais d'autres encodages sont possibles, cf. RFC 7951) :


       <host-name>my-router.example.com</host-name>

Donc, pour résumer, YANG modélise ce qu'on peut lire ou modifier, Netconf permet de le lire ou de le modifier effectivement.

Par contre, si un nœud de l'arbre YANG n'est pas une feuille, il est désigné par le mot-clé container. Par exemple, il y a ici deux containers emboîtés et une feuille :

     container system {
         container login {
             leaf message {
                 type string;
                 description
                     "Message given at start of login session";
             }
         }
     }

Lorsque Netconf utilise cette donnée, cela ressemblera, sur le câble, à ceci :


     <system>
       <login>
         <message>Good morning</message>
       </login>
     </system>

YANG dispose d'un certain nombre de types pour représenter les données (section 4.2.4 et RFC 6991), mais on peut aussi créer ses types (sections 4.2.5 et 7.3) par exemple ainsi :

     typedef percent {
         type uint8 {
             range "0 .. 100";
         }
         description "Percentage";
     }

     leaf completed {
         type percent;
     }

On a ajouté un intervalle de validité au type prédéfini uint8. Autre exemple, en indiquant une valeur par défaut, et en dérivant d'un type défini dans le module inet :

     typedef listen-ipv4-address {
         type inet:ipv4-address;
         default "0.0.0.0";
     }

YANG a bien d'autres possibilités, décrites en détail dans les sections suivantes. Par exemple, dans un monde idéal, tous les engins mettant en œuvre un module YANG donné géreraient la totalité des variables du module. Mais, comme ce n'est pas forcément le cas, YANG permet des déviations (sections 5.6.3 et 7.20.3). Prenons l'exemple du RFC, un routeur BGP qui suit un module YANG BGP. Le module ne donne pas de limite au nombre de pairs BGP mais un routeur bas de gamme pourrait avoir une limite, disons à 16 pairs. Un client Netconf qui tenterait de configurer un dix-septième pair recevrait donc une erreur. Le mot-clé YANG deviation permettrait audit client de savoir à l'avance en quoi ce routeur particulier dévie du modèle BGP général. Le client Netconf n'aurait donc pas à essayer pour voir, il pourrait savoir à l'avance que l'opération de configuration du dix-septième pair ne marchera pas.

La syntaxe formelle de YANG est décrite en section 6. Elle ressemble à celle de langages de programmation comme C ou à celle de SMIng du RFC 3780 (RFC qui n'a pas eu de succès). Cette syntaxe favorise la lisibilité par des humains, le cahier des charges étant de privilégier les lecteurs, pas les auteurs de modules, ni les programmeurs d'outils YANG. À noter que, comme dans toutes les normes modernes, YANG n'est pas limité à l'ASCII et peut utiliser tout Unicode.

Bien que YANG n'utilise pas XML, il réutilise un langage de ce monde, XPath (sections 6.4 et 7.5.3). XPath sert à indiquer les dépendances entre nœuds de l'arbre.

YANG permet en effet de définir des contraintes (section 8) que doivent respecter les variables, avec la directive must. Par exemple :

         must "ifType != 'ethernet' or " +
              "(ifType = 'ethernet' and ifMTU = 1500)" {
             error-message "An ethernet MTU must be 1500";
         }

Voici un exemple de requête Netconf complète, correspondant à une variable YANG. Soit un équipement muni d'un serveur SSH et d'un serveur Netconf pour sa configuration. Disons que le serveur Netconf met en œuvre la variable YANG port, définie ainsi :

     leaf port {
         type inet:port-number;
         default 22;
         description "The port which the SSH server listens to"
     }

La requête Netconf <edit-config> (RFC 6241, section 7.2) qui configure le serveur SSH pour écouter sur le port 2022 serait :


     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <services>
               <ssh>
                 <port>2022</port>
               </ssh>
             </services>
           </system>
         </config>
       </edit-config>
     </rpc>

Le choix de YANG comme langage standard pour la description des capacités d'un serveur Netconf ne s'était pas fait sans mal. Plusieurs concurrents avaient été envisagés notamment Relax NG, un choix logique puisque Netconf utilise XML. Un langage de description de schémas comme Relax NG semblait donc un choix raisonnable. Parmi les discussions à ce sujet, citons par exemple le débat qui avait eu lieu sur la liste du secteur Applications de l'IETF. Les raisons du choix de YANG, telles que vues par les concepteurs de YANG, sont décrites sur le site officiel du projet mais je trouve cette comparaison très unilatérale.

Un bon tutoriel Netconf, couvrant également YANG, est disponible en http://www.aims-conference.org/issnsm-2008/06-netconf-yang.pdf.

Quelles sont les mises en œuvre de YANG ? Il en existe une liste sur le site officiel. Voyons par exemple l'outil pyang, qui sert à valider des schémas YANG (y compris de la nouvelle version 1.1 décrite dans ce RFC) et à les convertir dans d'autres formats. Il ne semble pas trop maintenu mais, bon, il marche. Il peut produire du XSD et du RelaxNG - enfin du DSDL mais c'est presque pareil. Voici un exemple de test d'un schéma invalide (leaf a été tapé laf) :


% pyang test.yang
test.yang:11: error: unexpected keyword "laf"

Et, si on corrige :

% pyang test.yang
% 

Maintenant, convertissons en Yin :


% cat test.yang
 module acme-foo {
         namespace "http://acme.example.com/foo";
         prefix "acfoo";

         list interface {
             key "name";
             leaf name {
                 type string;
             }

             leaf mtu {
                 type uint32;
                 description "The MTU of the interface.";
             }
         }
     }

% pyang -fyin test.yang
<?xml version="1.0" encoding="UTF-8"?>
<module name="acme-foo"
        xmlns="urn:ietf:params:xml:ns:yang:yin:1"
        xmlns:acfoo="http://acme.example.com/foo">
  <namespace uri="http://acme.example.com/foo"/>
  <prefix value="acfoo"/>
  <list name="interface">
    <key value="name"/>
    <leaf name="name">
      <type name="string"/>
    </leaf>
    <leaf name="mtu">
      <type name="uint32"/>
      <description>
        <text>The MTU of the interface.</text>
      </description>
    </leaf>
  </list>
</module>

Et voici une conversion du même code en DSL :


% pyang -fdsdl test.yang
<?xml version='1.0' encoding='UTF-8'?>
<grammar datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
	 ns="http://acme.example.com/foo"
	 xmlns="http://relaxng.org/ns/structure/1.0"
	 xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
	 xmlns:acfoo="http://acme.example.com/foo"
	 xmlns:dc="http://purl.org/dc/terms"
	 xmlns:dsrl="http://purl.oclc.org/dsdl/dsrl"
	 xmlns:nm="urn:ietf:params:xml:ns:netmod:dsdl-attrib:1"
	 xmlns:sch="http://purl.oclc.org/dsdl/schematron">
  <dc:source>YANG module 'acme-foo' (automatic translation)</dc:source>
<start>
   <zeroOrMore>
      <element name="interface" nm:key="name">
	  <element name="name">
	     <data type="string"/>
	  </element>
	  <optional>
	     <element name="mtu"><a:documentation>The MTU of the interface.</a:documentation>
		<data type="unsignedInt"/>
	     </element>
	  </optional>
       </element>
   </zeroOrMore>
</start>
</grammar>

Outre pyang, il y a bien entendu même un mode Emacs, yang-mode.

Le site officiel du projet, http://www.yang-central.org/, contient beaucoup d'autre information sur YANG.

Notez que l'ancien YANG, 1.0, décrit dans le RFC 6020, n'est pas abandonné. L'ancien RFC reste d'actualité pour décrire la version 1.0, qui restera en usage un certain temps. Les principaux changements apportés par la version 1.1 de YANG sont décrits dans la section 1.1 du RFC. La liste est très longue, mais la plupart ne sont que des points de détail. Parmi les changements qui peuvent rendre illégaux des modèles YANG qui étaient légaux avant, il y a par exemple le changement d'interprétation des échappements dans les chaînes de caractères, ou bien le fait qu'une chaîne de caractères qui n'est pas encadrée par des apostrophes ou des guillemets n'a plus le droit de contenir des apostrophes ou guillemets (section 6.1.3). De même, les clés (identificateurs uniques) ne peuvent plus être conditionnelles (instructions when ou if-feature) ce qui est logique, mais rend également invalide certains anciens modèles YANG.


Téléchargez le RFC 7950


L'article seul

Fiche de lecture : surveillance://

Auteur(s) du livre : Tristan Nitot
Éditeur : C&F éditions
978-2-915825-65-7
Publié en 2016
Première rédaction de cet article le 9 octobre 2016


Si vous avez lu tous les articles d'Amaelle Guiton, de bluetouff et d'Andréa Fradin, si vous allez à tous les Quadr'Apéro de la Quadrature du Net (en lisant un livre de Schneier dans le métro) ou, bien sûr, si vous travaillez pour Facebook ou pour la DGSI, ce livre ne vous apprendra rien. Vous savez déjà que l'internaute ordinaire (pas le suspect de djihadisme ou de grand banditisme, non, le fameux M. Michu) est surveillé en permanence par les outils et services numériques qu'il utilise. Mais, contrairement au djihadiste ou au bandit, M. Michu ne le sait pas, ou bien il ne mesure pas exactement l'ampleur de la surveillance généralisée, ou alors il est complètement résigné, convaincu de ne rien pouvoir y faire. Le livre de Tristan Nitot vise à informer cet internaute innocent (dans tous les sens du terme) de la surveillance dont il fait l'objet, mais aussi à proposer des pistes pour améliorer les choses et faire reculer un peu la surveillance. (La préface d'Adrienne Charmet insiste sur l'importance de marcher sur ces deux jambes, l'exposition des problèmes, et celle des solutions.)

Ce livre est très court, ce qui reflète soit la paresse de l'auteur, soit son désir d'être utile à un maximum de gens qui pourraient être découragés en voyant un énorme pavé universitaire (qui, au passage, manque, sur ce sujet). L'auteur présente d'abord la variété des techniques de surveillance existantes. Contrairement à ce que prétendent les menteurs qui affirment qu'avec le chiffrement des smartphones, les policiers ne pourraient plus travailler, notre vie privée a énormément perdu avec l'arrivée de ce phono sapiens. Doté de capteurs perfectionnés, il enregistre tout et transmet tout à ses maîtres (qui ne sont pas son propriétaire...). Ensuite, les GAFA comme Google récoltent une quantité faramineuse de données, que leurs techniques perfectionnées permettent d'analyser. L'auteur donne plusieurs exemples concrets et précis (avec à chaque fois l'URL permettant d'aller se renseigner davantage, souci de sérieux rare). Toute cette partie est très pédagogique. Si vous êtes le geek instruit et politisé cité au début, c'est l'ouvrage à recommander à vos proches (et aux lointains aussi) moins informés, pour qu'ils comprennent ce qui arrive aujourd'hui à tout citoyen. Et ne leur racontez pas tout, laissez-leur le plaisir de découvrir l'erreur gravissime du cochon, citée à chaque conférence de l'auteur :-)

Tristan Nitot tord aussi le cou à quelques mythes comme le « je n'ai rien à cacher ». On a tous des choses (tout à fait légales) à cacher. Personnellement, je demande aux gens qui affirment n'avoir rien à cacher « votre dernier relevé bancaire, et la liste de vos dix derniers partenaires sexuels, avec les pratiques utilisées ».

Un point important de son livre est la question du modèle économique des acteurs de l'Internet. Si Google et Facebook nous surveillent autant, ce n'est pas parce qu'ils sont des filiales de la NSA, ni parce qu'ils sont vendus au diable ou aux reptiliens. C'est parce qu'ils sont gratuits, et qu'il faut bien se financer d'une manière ou d'une autre. Exploiter les données personnelles est une méthode rentable, et largement invisible pour l'utilisateur. Elle nécessite la récolte du plus grand nombre de données personnelles possible, et il n'est donc pas exagéré de noter que « le modèle d'affaires du Web, c'est la surveillance ».

Le désir de l'auteur (et de la préfacière) de ne pas uniquement décrire l'affreuse surveillance dont nous sommes l'objet, mais également de faire preuve d'un certain optimisme en indiquant des choix qui amélioreraient les choses, va parfois un peu loin. Si je peux comprendre l'analyse mesurée que Nitot fait d'Apple (société dont il ne cache pas les défauts mais qui, en matière de surveillance, semble en effet « moins pire » que les autres), j'ai plus de mal avec l'éloge qu'il fait de la société Sen.se dont le fondateur répète partout que la vie privée n'est pas son problème car « Facebook fait pire ». C'est ainsi que le produit Mother de cette société envoie tout dans « un ordinateur de quelqu'un d'autre » et que c'est présenté comme inévitable.

L'auteur continue en expliquant qu'un autre Internet est possible. Car dénoncer la surveillance, c'est très bien, mais cela peut mener à la sidération : convaincu d'être surveillé de partout, et de ne pas pouvoir l'empêcher, sauf à vivre dans une grotte sans électricité, le citoyen pourrait se décourager et renoncer à son droit à la vie privée. Il est donc nécessaire de proposer des pistes d'amélioration. Plusieurs sont avancées : le logiciel libre, bien sûr, condition nécessaire (mais pas du tout suffisante), le paiement des services (« si c'est gratuit, c'est que vous n'êtes pas le client, vous êtes la marchandise »), l'auto-hébergement (sans cacher, comme pour les autres solutions, les extrêmes difficultés que cela pose), le chiffrement (encore une condition nécessaire mais pas suffisante)... Nitot demande aussi que les partisans d'un autre Internet s'attaquent aussi au problème difficile de faire aussi bien, voire mieux, que les GAFA en matière de vécu utilisateur.

L'auteur détaille aussi, avec beaucoup de précision, quelques mesures d'hygiène numérique qui peuvent permettre de limiter un peu les dégâts de la surveillance. Par exemple, bloquer le spyware Google Analytics, ou bien avoir son propre nom de domaine permet de ne pas dépendre d'un seul fournisseur, et d'être donc libre de le quitter si ses pratiques ne sont pas acceptables.

Notons que ces manipulations sont parfois longues, ce qui reflète le désir des maîtres de la surveillance de nous empêcher de diminuer celle-ci. Il faut ainsi neuf étapes pour configurer Twitter de manière plus respectueuse de la vie privée.

Pour une genèse du livre, par son auteur, et pour une liste exhaustive des articles qui en parlent, voir sur le Standblog.

Déclaration de conflit d'intérêts : j'ai reçu un exemplaire gratuit de ce livre, mais il n'était pas accompagné d'une bouteille de vin, donc j'écris cet article à jeun et en toute objectivité.


L'article seul

RFC 7955: Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block

Date de publication du RFC : Septembre 2016
Auteur(s) du RFC : L. Iannone (Telecom ParisTech), R. Jorgensen (Bredbandsfylket Troms), D. Conrad (Virtualized, LLC), G. Huston (APNIC)
Pour information
Réalisé dans le cadre du groupe de travail IETF lisp
Première rédaction de cet article le 23 septembre 2016


Le RFC 7954 réservait un préfixe IP, 2001:5::/32, pour les identificateurs du protocole expérimental LISP. Ce RFC 7955 décrit les mécanismes d'allocation à l'intérieur de ce préfixe. Ils sont simples et légers : un peu de documentation et on a son sous-préfixe.

Le RIPE-NCC assure la gestion de ce préfixe. La politique d'enregistrement est simple (sections 4 et 9 de notre RFC) :

  • Ce préfixe est expérimental et les allocations sont donc temporaires. N'espérez pas garder éternellement votre joli préfixe sous 2001:5::/32. Si l'expérience se termine et que le 2001:5::/32 cesse d'être utilisé, tous ses sous-préfixes disparaitront aussi.
  • Les allocations doivent être renouvelées tous les ans, afin de s'assurer que le titulaire est toujours actif dans le banc de test LISP. (C'est bien un renouvellement, pas une nouvelle allocation, on conserve le même préfixe.)
  • Les préfixes abandonnés ne sont pas réutilisés, autant que possible, ou alors en attendant au moins une semaine.
  • Une organisation peut avoir plusieurs sous-préfixes.
  • Premier arrivé, premier servi.

Quelles sont les règles que suivra le registre de 2001:5::/32 (section 5) ?

  • Suivre les règles habituelles des registres d'adresses IP : collecter et archiver l'information envoyée par le titulaire, et la rendre accessible (par exemple via whois).
  • Gérer les noms de domaine dans ip6.arpa correspondants au préfixe géré.
  • Allouer un sous-préfixe à quiconque le demande, sous seule condition qu'il fournisse les informations demandées dans la section suivante.

La section 6, en effet, contient les informations demandées aux titulaires (ce sont à peu près les mêmes que pour obtenir un numéro d'organisation privé). On y trouve les grands classiques, nom de l'organisation qui demande, adresse, informations de contact, taille du préfixe demandé, raisons de la demande...

Comme indiqué plus haut, c'est le RIPE-NCC qui gérera le préfixe. Normalement, tout est déjà en place mais pas encore annoncé (cela sera mis en ligne après la publication du RFC).


Téléchargez le RFC 7955


L'article seul

Articles des différentes années : 2016  2015  2014  2013  2012  2011  2010  Précédentes années

Syndication : en HTTP non sécurisé, Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu, en HTTPS, Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.