Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

È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.


L'informatique doit-elle être rangée dans les sciences humaines et sociales ?

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


L'informatique est en fait une SHS et devrait être rangée ainsi dans les universités. C'est par cette idée provocante (mais, je vous rassure tout de suite, que l'auteur estime irréaliste) que commence l'article de Randy Connolly « Why computing belongs within the social sciences ». Une thèse intéressante et bien exposée, qui s'appuie sur des éléments sérieux mais qui a aussi d'ennuyeuses faiblesses.

Comme je l'ai dit, l'auteur ne propose pas réellement de réorganiser les universités et le CNRS en déplaçant le département d'informatique au même étage que la sociologie et l'histoire. Son but est plutôt de faire réfléchir au statut de l'informatique : on la place toujours dans les sciences dures (ou sciences exactes), en général à côté de la mathématique mais ne faudrait-il pas reconsidérer cette habitude ? L'idée centrale de l'auteur est que, d'abord, l'informatique a un tel pouvoir aujourd'hui, un tel rôle dans nos sociétés, qu'elle n'appartient plus au monde de la pure science, et ensuite que les sciences humaines et sociales auraient beaucoup à lui apporter.

Un grand nombre des points soulevés par l'auteur sont parfaitement exacts. L'informatique n'est pas seulement une technique à succès, présente partout (comme le sont bien d'autres sciences, par exemple la physique) : elle est au cœur de toutes nos activités à l'heure actuelle. Elle interagit donc fortement avec la société. L'informatique a du pouvoir (c'est bien pour cela que c'est un métier qui paie bien et ne connait pas le chômage) et donc des responsabilités. Affirmer, comme le fait l'auteur, que le code est politique n'est pas nouveau, ni original, mais ce n'est pas forcément encore bien compris, ni même admis par tou·tes les informaticien·nes (« je code juste, je ne fais pas de politique »). Ce n'est donc pas une mauvaise idée de le répéter. Ensuite, il est certain que les autres sciences (pas seulement les SHS) ont des choses à apprendre à l'informatique. C'est encore une banalité (que serait la science qui prétendrait rester isolée et considérerait les autres sciences comme dénuées d'intérêt ?) mais qui n'est pas encore bien intégrée. On trouvera sans peine des informaticien·nes qui renâcleraient à l'idée d'introduire des cours de psychologie ou d'économie dans leur cursus, au nom de « ça ne sert à rien ».

(Au passage, l'auteur a une façon intéressante de décrire la différence entre sciences dures et sciences humaines : les sciences dures se caractérisent par la méthode unique, la bonne, les sciences humaines par le pluralisme des méthodes. En effet, en SHS, il n'y a jamais de consensus entre les chercheurs, même sur des choses de base. Ce critère semble plus utile qu'un critère souvent utilisé, celui de la réfutabilité. Il y a des sciences dures comme la paléontologie ou l'astrophysique où on ne peut pas facilement faire des expériences…)

L'auteur fait trois suggestions concrètes, admettre que les autres sciences ont quelque chose à apporter à l'informatique, des cours de SHS dans les filières informatiques (et pas juste un « cours d'éthique » perdu en fin de semestre et clairement marqué comme secondaire), et l'embauche dans les départements d'informatique de gens qui ne sont pas à proprement parler informaticien·nes. Les trois me semblent de bonnes idées.

J'ai apprécié l'appel à s'ouvrir, à aller voir dans les autres champs disciplinaires ce qu'ils peuvent nous apporter. L'auteur a raison de faire remarquer que certain·es informaticien·nes ont une fâcheuse tendance à croire que tous les problèmes du monde se règlent avec de l'informatique, une vision techno-solutionniste très présente, par exemple, dans le discours macroniste et sa startup nation. Or, si l'arrivée d'informaticien·nes dans un champ nouveau peut rafraichir ce champ, la plupart du temps, quelqu'un qui débarque dans un nouveau domaine sans faire l'effort de la comprendre a plus de chances d'être un arrogant débutant que d'être un génie qui va bouleverser le monde. Mais l'article a aussi des faiblesses importantes.

La première est que la politique est absente. À le lire, on a l'impression que les décisions d'une entreprise comme Facebook sont uniquement dues au fait que les ingénieurs ont une certaine mentalité, et que ce sont eux qui décident. Il montre ainsi une étonnante ignorance du monde de l'entreprise et de ses mécanismes de gouvernance. Zuckerberg ne prend pas ses décisions parce que, il y a longtemps, il était programmeur. Il les prend en fonction des profits pour son entreprise, comme le fait n'importe quel autre patron. Le remplacer par quelqu'un qui a fait des études de science politique ou de communication ne changerait probablement rien. (Pour citer un commentaire de Joseph Bedard, « les patrons des entreprises de la tech ne sont pas des informaticiens et, s'ils l'ont été autrefois, ils ne le sont plus ».) Mais il est vrai qu'aux États-Unis, critiquer le capitalisme est un sujet tabou. Socialement, il est bien plus admis de demander qu'on donne quelques cours d'anthropologie ou de linguistique aux décideurs.

Cette négligence de la politique mène l'auteur à de curieuses affirmations comme de prétendre qu'aujourd'hui, le pouvoir ne s'exercerait rarement que par la violence et plutôt via des algorithmes. S'il est vrai que presque toutes nos activités sont médiées par des logiciels (et que les gens qui développent et déploient ce logiciel ont donc une responsabilité), il n'en est pas moins vrai que l'utilisation de ces logiciels est imposée et n'est pas le résultat d'une diffusion douce. N'importe quel gilet jaune ayant manifesté à Paris pourrait dire au professeur d'université dans sa tour d'ivoire que, si, la violence du pouvoir est encore un moyen utile et utilisé.

Ensuite, si je comprends que l'auteur (qui publie dans une revue de l'ACM) s'adresse surtout à un public d'informaticien·nes, et donc passe l'essentiel de l'article à réhabiliter les SHS dans l'esprit de ses confrères et consœurs, il faut quand même noter que les SHS, comme l'informatique, ne résolvent pas tous les problèmes. L'auteur parle de champs de recherche « établis depuis longtemps » comme si c'était une garantie de sérieux ; le cas de l'astrologie ou bien de la pseudo-médecine qu'on a pratiqué jusqu'au XVIIIe siècle montre que l'ancienneté d'une discipline ne dit rien sur son bon fonctionnement.

L'auteur estime ainsi que la conception de l'Internet, faite sans trop se soucier des problèmes de sécurité (un cliché classique), aurait été différente si on avait impliqué dès le début des gens ayant, entre autres, « une meilleure connaissance de la psychologie humaine ». Cette affirmation est franchement nulle sur plusieurs points. D'abord, l'expérience des réseaux informatiques prouve largement que les systèmes conçus en fonction de la sécurité ne sont tout simplement jamais utilisés et jamais déployés (ce qui, il est vrai, résout pas mal de problèmes de sécurité…). Comme l'analyse très justement le RFC 5218, pour avoir du succès dans le monde réel, il faut être utilisable et agréable, donc ne pas trop embêter les utilisateurs avec la sécurité (même s'il faudra bien s'y atteler un jour). Ensuite, même aujourd'hui, avec l'expérience acquise et la compréhension de l'importance des questions de sécurité, on ne sait pas forcément toujours sécuriser l'Internet sans le stériliser complètement. Enfin, prétendre que les psychologues auraient prévu le problème (alors que les SHS ne sont pas spécialement connues pour leurs succès prédictifs…) car la nature humaine, les gens sont méchants, ça a toujours été comme ça et sera toujours comme ça, c'est du Café du Commerce, pas de la psychologie comme science.

(Les lecteur·trices averti·es noteront en outre que l'article ne différencie pas tout le temps l'informatique en tant que science et celle en tant que technique. Mais c'est un sujet complexe que je ne traite pas moi non plus.)

Ah, et pour finir, une vidéo où une informaticienne parle de sa passion pour la programmation, mais aussi, et à juste titre, du pouvoir qu'apporte cette technique.


L'article seul

Tempête solaire sur l'Internet ?

Première rédaction de cet article le 15 octobre 2021


L'Internet est vulnérable aux attaques, aux pannes du matériel, aux bogues des logiciels. Mais il peut aussi être vulnérable aux actions du Soleil, comme le montre l'étude « Solar superstorm: planning for an Internet apocalypse » qui, en dépit d'un titre putaclic, est une analyse sérieuse et détaillée des risques que courra l'Internet avec l'actuelle croissance de la violence du Soleil.

Le Soleil nous éclaire et nous donne parfois des coups de soleil. Mais il a aussi un autre effet, celui provoqué par les tempêtes solaires, notamment les éjections de masse coronale. Pendant ces tempêtes, le Soleil éjecte une grande quantité de particules dont l'arrivée sur Terre provoque divers phénomènes électromagnétiques, notamment la génération de courants induits dans les conducteurs. Les câbles qui relient les équipements des réseaux informatiques, comme l'Internet, peuvent donc être perturbés, voire endommagés. La plus connue de ces tempêtes est l'événement de Carrington, qui est survenu à une époque où l'électricité était une nouveauté peu employée et où le réseau principal était le télégraphe. Les éjections de masse coronale sont très directionnelles et, si elles ne se produisent pas en direction de la Terre, les conséquences sont minimes (comme par exemple pour l'éruption de juillet 2012).

L'activité solaire, et ces tempêtes, suivent des cycles. Le plus connu est le cycle de 11 ans, et nous en sommes actuellement au cycle n° 25. Mais il y a d'autres cycles, de période plus longue, comme le cycle de Gleissberg. Le hasard a fait que l'expansion de l'Internet a coïncidé avec un minimum de la plupart de ces cycles, donc une activité solaire relativement faible. Mais les choses changent, l'activité solaire augmente, et une tempête de grande intensité, perturbant sérieusement l'Internet (et d'autres constructions techniques) est une possibilité réelle dans les prochaines années. Une tempête de la taille de celle de Carrington aurait des conséquences autrement plus importante aujourd'hui.

(Notez que, si les fibres optiques ne sont pas conductrices, le câble d'alimentation des répéteurs qui les longe l'est, et qu'une fibre optique peut donc être mise hors de service par une tempête solaire.)

L'article « Solar superstorm: planning for an Internet apocalypse » cherche à quantifier le risque et à étudier comment le limiter. Un de ses angles d'attaque est de regarder la distribution géographique des équipements réseau. En effet, les conséquences de la tempête solaire sont plus intenses aux latitudes élevées, donc près des pôles. D'autre part, plus un conducteur est long, plus le courant induit est important. Les câbles sous-marins transocéaniques sont donc les plus vulnérables. L'auteur s'est donc plongé dans les données et a regardé où il y avait le plus de risques. (Il a stocké une copie des données en ligne, sauf celles pour lesquelles il n'avait pas l'autorisation, comme les données de l'UIT.) Par exemple, CAIDA publie des informations très utiles sur les routeurs.

Je vous résume quelques conclusions :

  • Les câbles sous-marins transatlantiques sont très concentrés en un petit nombre de points sur la côte Est des États-Unis (les transpacifiques sont mieux répartis), et trop au Nord, ce qui augmente les risques. En cas de tempête solaire intense, tous ces câbles seraient mis hors d'usage, seuls ceux partant de Floride, à une latitude plus basse, seraient épargnés (et ils ne vont pas en Europe, donc la connectivité entre l'Europe et les États-Unis serait probablement interrompue).
  • Rappelez-vous que la tempête a surtout des effets aux latitudes élevées ; l'auteur calcule que l'Alaska perdait toute sa connectivité sous-marine, mais Hawaï serait relativement épargné.
  • Fait amusant, dans l'hypothèse d'une tempête intense, le Royaume-Uni perdait sa connectivité avec l'Amérique du Nord mais pas avec l'Europe ; un Brexit à l'envers.
  • Les câbles terrestres, plus courts, seront nettement moins touchés.
  • Et les centres de données ? La tendance étant de les mettre de plus en plus au Nord, pour faciliter leur refroidissement, notamment dans le contexte du réchauffement planétaire, ils pourraient également être affectés.
  • Et les serveurs DNS de la racine ? L'auteur y a pensé aussi et considère que, vu leur répartition très variée à la surface du globe, ils ne seront probablement pas tous affectés à la fois.

Dans l'état actuel de la science, on ne sait pas prédire les tempêtes solaires, uniquement déterminer des probabilités. On ne peut donc pas se préparer longtemps à l'avance. Toutefois, en cas de tempête solaire, comme la masse coronale éjectée voyage plus lentement que la lumière, on voit la tempête plusieurs heures, voire plusieurs jours, avant d'en ressentir les effets. Il existe des services d'alarme utilisés, par exemple, par l'aviation. C'est le cas du service Presto du SIDC. Un avertissement typique (daté du 11 octobre 2021) dit « A halo coronal mass ejection has been observed in the available SOHO/LASCO coronagraph imagery at 07:24 on Oct 9. This halo coronal mass ejection is associate with the M1.6-class flare peaking at 06:38 UTC on the same day in the Catania sunspots group 58 (NOAA AR-2882), which was located on the central meridian. The projected speed was measured 692 km/s by the software package CACTus. The true speed has been estimated around 950 km/s. The transit time to Earth is estimated to take about 62 hours, ant the arrival to Earth time would be on Oct 12, around 01:00 UTC. ». Dans ce cas, la masse éjectée (CME = Coronal Mass Ejection) arrivera bien sur Terre mais on a un peu d'avance pour se préparer. Notez que ce service Presto est également accessible via Gemini : presto-gemini.png

Que faire quand on reçoit l'avertissement ? Couper le courant peut aider mais ne suffit pas, le danger venant des courants induits par la réception sur Terre de la masse coronale éjectée. L'auteur recommande de travailler la diversité, avec davantage de câbles, et mieux répartis. La redondance (et l'absence de SPOF) reste la meilleure défense.

L'auteur se penche aussi sur la remise en fonctionnement après la panne et c'est sans doute la plus mauvaise partie de l'article, avec des « solutions » très stratosphériques comme SCION ou Loon.

Ah et, bien sûr, l'article rappelle que le plus gros problème sera peut-être le manque d'électricité, car le réseau électrique va déguster lui aussi (et son bon fonctionnement dépend peut-être en partie de l'Internet).


L'article seul

Panne de routage OVH d'octobre 2021

Première rédaction de cet article le 13 octobre 2021


Aujourd'hui le routage IPv4 chez OVH a été en panne pendant environ une heure. J'indique ici quelques observations effectuées puis j'en profite pour donner un avis sur la fiabilité de l'Internet, sur OVH et sur les yakafokons qui nous expliquent comment il aurait fallu faire. (Si vous n'êtes pas informaticien·ne, allez directement à la fin, la partie qui commence par « Maintenant, les leçons à en tirer. ».)


L'article complet

RFC 9137: Considerations for Cancellation of IETF Meetings

Date de publication du RFC : Octobre 2021
Auteur(s) du RFC : M. Duke (F5 Networks)
Réalisé dans le cadre du groupe de travail IETF shmoo
Première rédaction de cet article le 12 octobre 2021


Pour son travail de normalisation technique, l'IETF tient normalement trois réunions physiques par an. La pandémie de Covid-19 a évidemment changé tout cela. Les premières décisions d'annulation ont été prises selon un procédure ad hoc, mais ce nouveau RFC fournit des critères plus rigoureux pour les prochaines décisions d'annulation.

La dernière réunion physique de l'IETF a eu lieu à Singapour en novembre 2019. Depuis, les conditions sanitaires ont forcé à annuler toutes les réunions. Mais notre nouveau RFC ne se limite pas au cas de la Covid-19. Une réunion, après tout, peut devoir être annulée pour d'autres raisons, un problème de dernière minute dans le bâtiment où elle devait se tenir, une catastrophe naturelle dans le pays d'accueil, un brusque changement dans la politique de visa de ce pays, etc. (Le RFC cite même le cas d'une guerre civile, mais ce n'est encore jamais arrivé à une réunion IETF.) Dans ces cas, l'IETF LLC (la direction administrative de l'IETF) et l'IESG vont devoir décider si on maintient la réunion ou pas.

La section 3 du RFC expose les critères de décision. L'IETF LLC (cf. RFC 8711) détermine si la réunion peut se tenir, l'IESG si cela vaut la peine de la tenir. L'IETF LLC doit évidemment travailler en toute transparence, informant l'IETF de la situation, des décisions possibles et d'un éventuel « plan B ». Il n'est pas toujours possible de procéder proprement et démocratiquement si la situation est urgente (tremblement de terre trois jours avant la réunion…). Dans ce cas, l'IETF LLC doit déterminer seule si la réunion peut se tenir (ce qui implique certaines garanties de sécurité pour les participants, de la restauration mais également un accès Internet qui marche ; les participants à l'IETF n'ont pas juste besoin de dormir et de manger, il leur faut aussi du réseau). L'IETF LLC doit aussi intégrer des paramètres internes comme la disponibilité de ses employés et des bénévoles, et bien sûr les conséquences financières du maintien ou de l'annulation (si le lieu de la réunion considère qu'il n'y avait pas force majeure et ne veut pas rembourser…). La section 3 du RFC 8718 contient des indications utiles à cette évaluation.

L'IESG, lui, doit déterminer s'il y aura suffisamment de monde à la réunion pour que ça vaille la peine. Il ne serait pas malin de maintenir une réunion pour que personne ne vienne.

La section 4 du RFC couvre les alternatives. Si on annule, que peut-on proposer à la place ? Il faut évaluer ces alternatives en tenant compte de leur efficacité (une réunion en ligne est moins efficace) et de leur coût (changer les billets d'avion au dernier moment coûte cher). Ces alternatives peuvent être, dans l'ordre décroissant de préférence :

  • Changer le lieu de la réunion. C'est ce qui dérange le moins le travail, surtout si le nouveau lieu est proche de l'ancien. Naturellement, le nouveau lieu doit correspondre aux critères des RFC 8718 et RFC 8719.
  • Passer en ligne, à une réunion « virtuelle », ce qui a été fait pour toutes les réunions annulées en raison de la Covid-19.
  • Repousser la réunion à plus tard. Ce n'est en général pas facilement faisable, puisque cela perturbe les agendas de tout le monde.
  • Annuler complètement, sans alternative. Le RFC note que cela aura des conséquences, non seulement sur le travail de normalisation, mais également sur des processus politiques comme la détermination de qui peut siéger dans des comités comme le NomCom (comité de nomination, cf. RFC 8788 et RFC 8989).

La section 5 de notre RFC couvre les questions financières. En gros, l'IETF ne remboursera pas les dépenses engagées par les participants (avion, hôtel, etc), seulement les frais d'inscription à la réunion, en totalité s'il y a annulation complète et partiellement dans les autres cas.


Téléchargez le RFC 9137


L'article seul

RFC 9132: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification

Date de publication du RFC : Septembre 2021
Auteur(s) du RFC : M. Boucadair (Orange), J. Shallow, T. Reddy.K (Akamai)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dots
Première rédaction de cet article le 10 octobre 2021


Le protocole DOTS (Distributed Denial-of-Service Open Threat Signaling) vise à permettre au client d'un service anti-dDoS de demander au service de mettre en route des mesures contre une attaque. Ce RFC décrit le canal de signalisation de DOTS, celui par lequel passera la demande d'atténuation de l'attaque. Il remplace le RFC 8782, mais les changements sont mineurs.

Si vous voulez mieux comprendre DOTS, il est recommandé de lire le RFC 8612, qui décrit le cahier des charges de ce protocole, et le RFC 8811, qui décrit l'architecture générale. Ici, je vais résumer à l'extrême : un client DOTS, détectant qu'une attaque par déni de service est en cours contre lui, signale, par le canal normalisé dans ce RFC, à un serveur DOTS qu'il faudrait faire quelque chose. Le serveur DOTS est un service anti-dDoS qui va, par exemple, examiner le trafic, jeter ce qui appartient à l'attaque, et transmettre le reste à son client.

Ces attaques par déni de service sont une des plaies de l'Internet, et sont bien trop fréquentes aujourd'hui (cf. RFC 4987 ou RFC 4732 pour des exemples). Bien des réseaux n'ont pas les moyens de se défendre seuls et font donc appel à un service de protection (payant, en général, mais il existe aussi des services comme Deflect). Ce service fera la guerre à leur place, recevant le trafic (via des manips DNS ou BGP), l'analysant, le filtrant et envoyant ce qui reste au client. Typiquement, le client DOTS sera chez le réseau attaqué, par exemple en tant que composant d'un IDS ou d'un pare-feu, et le serveur DOTS sera chez le service de protection. Notez donc que client et serveur DOTS sont chez deux organisations différentes, communiquant via le canal de signalisation (signal channel), qui fait l'objet de ce RFC.

La section 3 de notre RFC expose les grands principes du protocole utilisé sur ce canal de signalisation. Il repose sur CoAP, un équivalent léger de HTTP, ayant beaucoup de choses communes avec HTTP. Le choix d'un protocole différent de HTTP s'explique par les spécificités de DOTS : on l'utilise quand ça va mal, quand le réseau est attaqué, et il faut donc pouvoir continuer à fonctionner même quand de nombreux paquets sont perdus. CoAP a les caractéristiques utiles pour DOTS, il est conçu pour des réseaux où il y aura des pertes, il tourne sur UDP, il permet des messages avec ou sans accusé de réception, il utilise peu de ressources, il peut être sécurisé par DTLSTCP est également utilisable mais UDP est préféré, pour éviter le head-of-line blocking. CoAP est normalisé dans le RFC 7252. Parmi les choses à retenir, n'oubliez pas que l'encodage du chemin dans l'URI est un peu spécial, avec une option Uri-Path: par segment du chemin (RFC 7252, section 5.10.1). Par abus de langage, j'écrirai « le client CoAP demande /foo/bar/truc.cbor » alors qu'il y aura en fait trois options Uri-Path: :

Uri-Path: "foo"
Uri-Path: "bar"
Uri-Path: "truc.cbor" 
  

Par défaut, DOTS va utiliser le port 4646 (et non pas le port par défaut de CoAP, 5684, pour éviter toute confusion avec d'autres services tournant sur CoAP). Ce port a été choisi pour une bonne raison, je vous laisse la chercher, la solution est à la fin de cet article. Le plan d'URI sera coaps ou coaps+tcp (RFC 7252, section 6, et RFC 8323, section 8.2).

Le fonctionnement de base est simple : le client DOTS se connecte au serveur, divers paramètres sont négociés. Des battements de cœur peuvent être utilisés (par le client ou par le serveur) pour garder la session ouverte et vérifier son bon fonctionnement. En cas d'attaque, le client va demander une action d'atténuation. Pendant que celle-ci est active, le serveur envoie de temps en temps des messages donnant des nouvelles. L'action se terminera, soit à l'expiration d'un délai défini au début, soit sur demande explicite du client. Le serveur est connu du client par configuration manuelle, ou bien par des techniques de découverte comme celles du RFC 8973.

Les messages sont encodés en CBOR (RFC 8949). Rappelez-vous que le modèle de données de CBOR est très proche de celui de JSON, et notre RFC spécifie donc les messages avec une syntaxe JSON, même si ce n'est pas l'encodage utilisé sur le câble. Pour une syntaxe formelle des messages, le RFC utilise YANG (cf. RFC 7951). Le type MIME des messages est application/dots+cbor.

La section 4 du RFC décrit les différents messages possibles plus en détail. Je ne vais pas tout reprendre ici, juste donner quelques exemples. Les URI commencent toujours par /.well-known/dots (.well-known est normalisé dans le RFC 8615, et dots est désormais enregistré à l'IANA). Les différentes actions ajouteront au chemin dans l'URI /mitigate pour les demandes d'actions d'atténuation, visant à protéger de l'attaque, /hb pour les battements de cœur, etc.

Voici par exemple une demande de protection, effectuée avec la méthode CoAP PUT :

Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
Content-Format: "application/dots+cbor"

{
       ... Données en CBOR (représentées en JSON dans le RFC et dans
       cet article, pour la lisibilité).
}    
  

L'URI, en notation traditionnelle, sera donc /.well-known/dots/mitigate/cuid=dz6pHjaADkaFTbjr0JGBpw/mid=123. CUID veut dire Client Unique IDentifier et sert à identifier le client DOTS, MID est Mitigation IDentifier et identifie une demande d'atténuation particulière. Si ce client DOTS fait une autre demande de palliation, le MID changera mais le CUID sera le même.

Que met-on dans le corps du message ? On a de nombreux champs définis pour indiquer ce qu'on veut protéger, et pour combien de temps. Par exemple, on pourrait avoir (je rappelle que c'est du CBOR, format binaire, en vrai) :

     {
       "ietf-dots-signal-channel:mitigation-scope": {
         "scope": [
           {
             "target-prefix": [
                "2001:db8:6401::1/128",
                "2001:db8:6401::2/128"
              ],
             "target-port-range": [
               {
                 "lower-port": 80
               },
               {
                 "lower-port": 443
               }
              ],
              "target-protocol": [
                6
              ],
             "lifetime": 3600
           }
         ]
       }
     }
  

Ici, le client demande qu'on protège 2001:db8:6401::1 et 2001:db8:6401::2 (target veut dire qu'ils sont la cible d'une attaque, pas qu'on veut les prendre pour cible), sur les ports 80 et 443, en TCP, pendant une heure. (lower-port seul, sans upper-port indique un port unique, pas un intervalle.)

Le serveur va alors répondre avec le code 2.01 (indiquant que la requête est acceptée et traitée) et des données :

  {
     "ietf-dots-signal-channel:mitigation-scope": {
        "scope": [
           {
             "mid": 123,
             "lifetime": 3600
           }
         ]
      }
   }
  

La durée de l'action peut être plus petite que ce que le client a demandé, par exemple si le serveur n'accepte pas d'actions trop longues. Évidemment, si la requête n'est pas correcte, le serveur répondra 4.00 (format invalide), si le client n'a pas payé, 4.03, s'il y a un conflit avec une autre requête, 4.09, etc. Le serveur peut donner des détails, et la liste des réponses possibles figure dans des registres IANA, comme celui de l'état d'une atténuation, ou celui des conflits entre ce qui est demandé et d'autres actions en cours.

Le client DOTS peut ensuite récupérer des informations sur une action de palliation en cours, avec la méthode CoAP GET :

Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"    
  

Ce GET /.well-known/dots/mitigate/cuid=dz6pHjaADkaFTbjr0JGBpw/mid=123 va renvoyer de l'information sur l'action d'identificateur (MID) 123 :

   {
     "ietf-dots-signal-channel:mitigation-scope": {
       "scope": [
         {
           "mid": 123,
           "mitigation-start": "1507818393",
           "target-prefix": [
                "2001:db8:6401::1/128",
                "2001:db8:6401::2/128"
           ],
           "target-protocol": [
             6
           ],
           "lifetime": 1755,
           "status": "attack-stopped",
           "bytes-dropped": "0",
           "bps-dropped": "0",
           "pkts-dropped": "0",
           "pps-dropped": "0"
         }
       ]
     }
   }
  

Les différents champs de la réponse sont assez évidents. Par exemple, pkts-dropped indique le nombre de paquets qui ont été jetés par le protecteur.

Pour mettre fin aux actions du système de protection, le client utilise évidemment la méthode CoAP DELETE :

Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
  

Le client DOTS peut se renseigner sur les capacités du serveur avec un GET de /.well-known/dots/config.

Ce RFC décrit le canal de signalisation de DOTS. Le RFC 8783, lui, décrit le canal de données. Le canal de signalisation est prévu pour faire passer des messages de petite taille, dans un environnement hostile (attaque en cours). Le canal de données est prévu pour des données de plus grande taille, dans un environnement où les mécanismes de transport normaux, comme HTTPS, sont utilisables. Typiquement, le client DOTS utilise le canal de données avant l'attaque, pour tout configurer, et le canal de signalisation pendant l'attaque, pour déclencher et arrêter l'atténuation.

Les messages possibles sont modélisés en YANG. YANG est normalisé dans le RFC 7950. Notez que YANG avait été initialement créé pour décrire les commandes envoyées par NETCONF (RFC 6241) ou RESTCONF (RFC 8040) mais ce n'est pas le cas ici : DOTS n'utilise ni NETCONF, ni RESTCONF mais son propre protocole basé sur CoAP. La section 5 du RFC contient tous les modules YANG utilisés.

La mise en correspondance des modules YANG avec l'encodage CBOR figure dans la section 6. (YANG permet une description abstraite d'un message mais ne dit pas, à lui tout seul, comment le représenter en bits sur le réseau.) Les clés CBOR sont toutes des entiers ; CBOR permet d'utiliser des chaînes de caractères comme clés mais DOTS cherche à gagner de la place. Ainsi, les tables de la section 6 nous apprennent que le champ cuid (Client Unique IDentifier) a la clé 4, suivie d'une chaîne de caractères en CBOR. (Cette correspondance est désormais un registre IANA.) D'autre part, DOTS introduit une étiquette CBOR, 271 (enregistrée à l'IANA, cf. RFC 8949, section 3.4) pour marquer un document CBOR comme lié au protocole DOTS.

Évidemment, DOTS est critique en matière de sécurité. S'il ne fonctionne pas, on ne pourra pas réclamer une action de la part du service de protection. Et s'il est mal authentifié, on risque de voir le méchant envoyer de faux messages DOTS, par exemple en demandant l'arrêt de l'atténuation. La section 8 du RFC rappelle donc l'importance de sécuriser DOTS par TLS ou plutôt, la plupart du temps, par son équivalent pour UDP, DTLS (RFC 6347). Le RFC insiste sur l'authentification mutuelle du serveur et du client, chacun doit s'assurer de l'identité de l'autre, par les méthodes TLS habituelles (typiquement via un certificat). Le profil de DTLS recommandé (TLS est riche en options et il faut spécifier lesquelles sont nécessaires et lesquelles sont déconseillées) est en section 7. Par exemple, le chiffrement intègre est nécessaire.

La section 11 revient sur les questions de sécurité en ajoutant d'autres avertissements. Par exemple, TLS ne protège pas contre certaines attaques par déni de service, comme un paquet TCP RST (ReSeT). On peut sécuriser la communication avec TCP-AO (RFC 5925) mais c'est un vœu pieux, il est très peu déployé à l'heure actuelle. Ah, et puis si les ressources à protéger sont identifiées par un nom de domaine, et pas une adresse ou un préfixe IP (target-fqdn au lieu de target-prefix), le RFC dit qu'évidemment la résolution doit être faite avec DNSSEC.

Question mises en œuvre, DOTS dispose d'au moins quatre implémentations, dont l'interopérabilité a été testée plusieurs fois lors de hackathons IETF (la première fois ayant été à Singapour, lors de l'IETF 100) :

Notez qu'il existe des serveurs de test DOTS publics comme coaps://dotsserver.ddos-secure.net:4646.

Ah, et la raison du choix du port 4646 ? C'est parce que 46 est le code ASCII pour le point (dot en anglais) donc deux 46 font deux points donc dots.

L'annexe A de notre RFC résume les principaux changements depuis le RFC 8782. Le principal changement touche les modules YANG, mis à jour pour réparer une erreur et pour tenir compte du RFC 8791. Il y a aussi une nouvelle section (la 9), qui détaille les codes d'erreur à renvoyer, et l'espace des valeurs des attributs a été réorganisé… Rien de bien crucial, donc.


Téléchargez le RFC 9132


L'article seul

Indiquer la consommation énergétique par requête a-t-il un sens ?

Première rédaction de cet article le 9 octobre 2021


Dans les débats sur l'empreinte environnementale du numérique, on voit souvent citer des coûts énergétiques par opération élémentaire, du genre « un message consomme X joules » ou bien « une recherche Google brûle autant de charbon que faire chauffer N tasses de café ». Ces chiffres sont trompeurs, et voici pourquoi.

Lorsqu'ils sont cités, ces chiffres sont souvent accompagnés d'injonctions à la sobriété. « N'envoyez pas ce courrier que vous étiez en train d'écrire et vous sauverez un arbre. » En effet, annoncer des coûts environnementaux par requête donne à penser que, si on s'abstient d'une action, le coût diminuera d'autant. Mais ce n'est pas ainsi que les choses se passent. Ces chiffres « par opération » sont obtenus (normalement…) en divisant la consommation énergétique totale par le nombre d'opérations. C'est classique, c'est le calcul de la moyenne. Si on connait la consommation d'essence de toutes les voitures en France, et le nombre de voitures, calculer la consommation moyenne de chaque voiture est simple. Certes, il faudrait tenir compte du fait qu'une petite voiture consomme moins qu'un SUV mais, en première approximation, cela a du sens de dire « chaque voiture dévore N litres d'essence par an ». Et il est raisonnable d'en déduire que de mettre des voitures supplémentaires sur la route augmentera cette consommation, de façon proportionnelle à l'augmentation du nombre de véhicules. La proportionnalité s'applique également à la consommation d'essence rapportée au nombre de kilomètres : la quantité de carburant brûlé est à peu près proportionnelle à ce nombre de kilomètres. Si je roule deux fois moins, je consomme deux fois moins d'essence, et ça diminuera le relâchement de gaz à effet de serre. Dans tous ces cas, la moyenne est un concept mathématique parfaitement valable.

Mais tout ne fonctionne pas ainsi : la consommation électrique des équipements réseau, par exemple, n'est pas linéaire, elle est même souvent constante (cela dépend des équipements ; il y un coût constant et un variable, ce dernier étant en général plus faible que le coût constant). Que le routeur passe des paquets ou pas, il consommera la même quantité d'énergie. Envoyer deux fois moins de courriers ne diminuera donc pas la consommation énergétique de votre box, ou du reste de l'Internet. Ainsi, le tweet de France Culture « Savez-vous que chaque mail envoyé, chaque vidéo regardée, émet des gaz à effet de serre ? » est faux et trompeur. Si vous renoncez à votre soirée devant Netflix, la consommation électrique des routeurs, serveurs et autres équipements ne changera pas forcément, et calculer une moyenne par film ou série visionné n'a donc pas beaucoup de sens. La moyenne n'est légitime que si la dépendance est à peu près linéaire.

Bon, OK mais, même si la moyenne n'a pas de sens et que les déclarations sensationnalistes « envoyer un courrier, c'est relâcher X grammes de dioxyde de carbone dans l'atmosphère » sont à côté de la plaque, il n'en reste pas moins que le numérique a une empreinte environnementale, non ? Oui, la construction et l'exploitation des réseaux informatiques a un coût (y compris environnemental). Ce n'est pas un coût à l'utilisation, d'accord. Mais si les gens augmentent leur activité en ligne, par exemple si ce blog double son nombre de visiteurs, il faudra déployer davantage de matériels (dont la construction est le principal facteur d'empreinte environnementale du numérique) et il y aura donc bien un résultat (néfaste…) sur l'environnement. (Le matériel nouveau sera plus efficace : un routeur capable de 100 Gb/s ne consommera pas dix fois qu'un routeur capable de 10 Gb/s. Mais sa fabrication, on l'a vu, a un fort coût environnemental.) Bref, chaque requête individuelle ne pèse rien, mais leur augmentation va mener à une empreinte accrue sur l'environnement. (En sens inverse, on pourrait se dire que, si les gens arrêtent de regarder Netflix, cette société va éteindre certains équipements et que cela diminuera la consommation d'électricité. Mais c'est moins certain et, rappelez-vous, c'est surtout la fabrication qui coûte. Une fois le serveur installé dans l'armoire, il a déjà imprimé l'essentiel de sa marque sur l'environnement.)

Ce raisonnement (comme quoi l'effet attendu de la sobriété n'est pas de diminuer la consommation énérgétique aujourd'hui, mais de limiter les dépenses de matériel demain) est correct et justifie donc qu'on porte attention aux conséquences écologiques du numérique. La frugalité est donc une bonne chose mais attention à ne pas la justifier par des arguments faux, comme ces coûts par requête.

Est-ce qu'à défaut d'être scientifiquement pertinent, les arguments fondés sur une moyenne sont au moins efficaces pour la communication, sensibilisant les utilisatrices et utilisateurs à l'importance de l'empreinte environnementale du numérique ? Même si c'était le cas, ce ne serait pas à mon avis (mon avis de rationaliste convaincu) une raison suffisante pour l'utiliser. Tromper les gens n'est pas une bonne idée. Mais, en plus, je ne suis même pas sûr que l'argument soit efficace : la plupart des gens le comprendront de travers, croyant que tel ou tel geste d'extinction va vraiment diminuer tout de suite l'empreinte environnementale.

Le point essentiel de cet article était que la moyenne n'est pas forcément pertinente. Mais, sinon, que peut-on faire pour que l'empreinte environnementale cesse d'augmenter ou en tout cas que cette augmentation ralentisse ? Le discours médiatique dominant est plein de conseils absurdes et évite soigneusement de s'attaquer à des usages sacrés. On a vu ainsi un politicien qui dénonçait l'utilisation de l'Internet pour regarder du « porno dans l'ascenseur » mais qui se prenait en photo regardant un match de foot depuis sa voiture. (Le sport-spectacle est intouchable, quand on est un politicien ambitieux, pas question de le critiquer.)

Donc, voici ma liste de quelques « gisements d'économie énergétique » importants qui ne sont pas toujours mentionnés :

  • La publicité est une source importante de dégâts environnementaux, par l'encouragement à la consommation mais aussi par un effet plus direct, l'importance des infrastructures qui sont dédiées à son fonctionnement en ligne. Il est grinçant de voir sur le Web des articles critiquant vertueusement l'« enfer numérique » mais qui contiennent des publicités. Pour l'utilisateur·rice final·e, installer un bloqueur de publicité est une bien meilleure action écologique que renoncer à envoyer un message. Mais les médias n'en parleront pas (la publicité est également sacrée).
  • La surveillance de masse est également très coûteuse du point de vue environnemental, car elle aussi dépend d'infrastructures complexes et consommatrices (par exemple pour la vidéo-surveillance, et c'est encore pire avec la reconnaissance faciale). De même qu'on voit des articles anti-Internet (lui reprochant sa consommation électrique) qui sont hébergés sur des sites Web avec des publicités, il est fréquent de trouver des traqueurs comme ceux de Google Analytics sur ces sites. Lutter contre le capitalisme de surveillance est plus écologique que de ne pas envoyer le courrier que vous venez d'écrire.
  • La fabrication du matériel est très coûteuse du point de vue environnemental. Changer moins souvent de matériel est donc également une action utile.
  • Question frugalité, il est important de promouvoir les techniques qui imposent le moins de contraintes sur le réseau et sur les machines : LEDBAT (RFC 6297) comme algorithme de transport ou Gemini côté application.
  • En moins disruptif, on peut noter que les applications et sites Web d'aujourd'hui sont loin d'être des modèles de frugalité. Leur consommation importante de ressources (notamment de temps de processeur) pousse rapidement les machines les plus anciennes dans la catégorie « vieux trucs à jeter ». Si vous êtes développeur ou développeuse, une des choses les plus importantes que vous pouvez faire pour le climat est de développer des applications et sites plus frugaux. (Et d'envoyer promener le marketeux qui dira « c'est moche, c'est trop austère, le client ne va pas aimer ».) C'est ce que prône par exemple le courant small Web ou slow Web. (On peut aussi citer l'intéressant Low-tech magazine, pour les bricoleur·ses.)

On trouve en ligne (ou sur papier…) plein de ressources sur l'empreinte environnementale du numérique. Toutes ne sont pas sérieuses, loin de là. En voici quelques-unes qui sont utiles (ce qui ne veut pas dire que je suis 100 % d'accord avec leurs auteurs) :


L'article seul

Plusieurs domaines de premier niveau en panne

Première rédaction de cet article le 7 octobre 2021


Le monde des noms de domaine a vu aujourd'hui un incident rare : la panne complète d'un TLD, .club, et même de plusieurs autres.

Commençons par les faits : ce jeudi 7 octobre, vers 1035 UTC, plus moyen de résoudre aucun nom de domaine en .club. Tous les résolveurs renvoyaient le code de retour SERVFAIL (SERver FAILure). Une telle panne complète d'un TLD est rare (la dernière de .com a eu lieu en 1997).

Pour le déboguage, on peut regarder les jolies images de DNSviz, ou bien utiliser dig :


%  dig NS club

; <<>> DiG 9.16.21 <<>> NS club
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30784
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;club.			IN NS

;; Query time: 2606 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 07 13:55:28 CEST 2021
;; MSG SIZE  rcvd: 33

  

Un test avec les sondes RIPE Atlas montrait que le problème n'était pas juste avec mon résolveur :

% blaeu-resolve --type SOA -r 100 club
[ERROR: SERVFAIL] : 81 occurrences 
[ns1.dns.nic.club. admin.tldns.godaddy. 1633603168 1800 300 604800 1800] : 1 occurrences 
Test #32444898 done at 2021-10-07T11:55:21Z
  

La raison ? Les serveurs faisant autorité pour .club répondaient tous SERVFAIL :

    
 dig @2610:a1:1076::d7 SOA club

; <<>> DiG 9.16.21 <<>> @2610:a1:1076::d7 SOA club
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58363
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

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

;; Query time: 66 msec
;; SERVER: 2610:a1:1076::d7#53(2610:a1:1076::d7)
;; WHEN: Thu Oct 07 13:57:39 CEST 2021
;; MSG SIZE  rcvd: 33

  

Contrairement à la récente panne de Facebook, il ne s'agissait donc pas d'un problème de routage ; les serveurs répondaient bien, mais mal. (Typiquement, quand un serveur faisant autorité répond SERVFAIL, c'est qu'il n'a pas pu charger les données de la zone, par exemple suite à une erreur de syntaxe dans le fichier de zone.)

Le TLD .hsbc (même opérateur technique de registre et même hébergeur DNS) a été frappé de la même façon :

% blaeu-resolve --type SOA -r 100 hsbc
[ERROR: SERVFAIL] : 90 occurrences 
[ns1.dns.nic.hsbc. admin.tldns.godaddy. 1633405738 1800 300 604800 1800] : 1 occurrences 
Test #32445325 done at 2021-10-07T12:23:28Z
  

La panne semble avoir été complètement résolue vers 1410 UTC :

% blaeu-resolve --type SOA -r 100 club
[ns1.dns.nic.club. admin.tldns.godaddy. 1633615537 1800 300 604800 1800] : 90 occurrences 
[ns1.dns.nic.club. admin.tldns.godaddy. 1633613754 1800 300 604800 1800] : 1 occurrences 
[ns1.dns.nic.club. admin.tldns.godaddy. 1633615179 1800 300 604800 1800] : 4 occurrences 
Test #32446901 done at 2021-10-07T14:14:47Z
  

Quelques informations publiques :


L'article seul

La panne Facebook du 4 octobre 2021

Première rédaction de cet article le 4 octobre 2021
Dernière mise à jour le 5 octobre 2021


Aujourd'hui, Facebook a connu une panne importante. Que s'est-il passé ? On sait désormais que la cause racine était un problème de configuration des routeurs BGP. A-t-on des détails ?

Le message d'erreur de beaucoup d'utilisateurs : facebook-octobre-2021.jpg

Je vous le dis tout de suite, je n'ai pas d'informations internes à Facebook, et je n'ai pas fait une longue enquête. N'attendez donc pas de révélations extraordinaires. Commençons par les faits. Aujourd'hui, lundi 4 octobre vers 1550 UTC, les services de Facebook, y compris WhatsApp et Instagram étaient en panne. (La panne a duré environ 6 heures.) Les utilisateurs avaient typiquement un message faisant allusion au nom de domaine, qui ne marchait pas.

Arrivé là, il faut se rappeler que les noms de domaine et le protocole DNS sont critiques pour le fonctionnement de l'Internet. Quasiment toute activité sur l'Internet commence par une requête DNS. Si elle ne fonctionne pas, presque rien n'est possible. Mais il faut aussi se rappeler que ce DNS ne fonctionne pas sur un réseau parallèle : il utilise l'Internet lui aussi, les paquets DNS circulent dans des paquets IP et que donc un problème affectant IP va souvent se manifester comme un problème DNS (puisque c'est par le DNS qu'on commence une session).

Demandons aux sondes RIPE Atlas de trouver les serveurs de noms de facebook.com :

% blaeu-resolve -r 200 --type NS facebook.com
[a.ns.facebook.com. b.ns.facebook.com. c.ns.facebook.com. d.ns.facebook.com.] : 97 occurrences 
[ERROR: SERVFAIL] : 48 occurrences 
[] : 3 occurrences 
Test #32421708 done at 2021-10-04T16:16:14Z

Une partie y arrive, probablement parce que l'information était encore dans la mémoire de leur résolveur. Mais ce n'est pas le cas de toutes. En effet, pendant la panne, les serveurs DNS faisant autorité pour facebook.com ne répondaient pas. Voici la liste de ces serveurs, obtenue avec dig en demandant à un serveur de la zone parente, .com (on ne pouvait pas faire un dig « normal » puisque le résolveur qu'il utilise aurait essayé de joindre les serveurs en panne) :


% dig @a.gtld-servers.net. A a.ns.facebook.com. 

; <<>> DiG 9.16.15-Debian <<>> @a.gtld-servers.net. A a.ns.facebook.com.
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4686
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9
...
;; AUTHORITY SECTION:
facebook.com.		172800 IN NS a.ns.facebook.com.
facebook.com.		172800 IN NS b.ns.facebook.com.
facebook.com.		172800 IN NS c.ns.facebook.com.
facebook.com.		172800 IN NS d.ns.facebook.com.
...
;; ADDITIONAL SECTION:
a.ns.facebook.com.	172800 IN A 129.134.30.12
a.ns.facebook.com.	172800 IN AAAA 2a03:2880:f0fc:c:face:b00c:0:35
...
;; Query time: 16 msec
;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
;; WHEN: Mon Oct 04 18:24:55 CEST 2021
;; MSG SIZE  rcvd: 833

Maintenant, demandons aux sondes RIPE Atlas d'interroger un de ces serveurs, a.ns.facebook.com :

%  blaeu-resolve -r 200 --type NS --nameserver 129.134.30.12 --nsid facebook.com 
Nameserver 129.134.30.12
[] : 3 occurrences 
[TIMEOUT] : 189 occurrences 
Test #32421749 done at 2021-10-04T16:25:09Z

On le voit, l'échec est total. Un peu plus tard, ça marche un peu mieux :

%  blaeu-resolve -r 200 --type NS --nameserver 129.134.30.12 --nsid facebook.com 
Nameserver 129.134.30.12
[TIMEOUT] : 192 occurrences 
[ERROR: SERVFAIL] : 3 occurrences 
[a.ns.facebook.com. b.ns.facebook.com. c.ns.facebook.com. d.ns.facebook.com.] : 1 occurrences 
Test #32421800 done at 2021-10-04T16:35:54Z
  

Donc, les choses sont claires : les serveurs DNS faisant autorité ne marchaient pas. Cela explique la panne vue par les utilisateurs. Maintenant, pourquoi ces quatre serveurs (et davantage de machines physiques, en raison de l'anycast) seraient-ils tous tombés en même temps ? Il y a plusieurs hypothèses, comme une erreur de configuration propagée automatiquement à toutes les machines (automatiser les configurations simplifie la vie mais les erreurs ont des conséquences plus graves). Mais on peut noter autre chose : tous ces serveurs sont dans le même AS, le 32934, l'AS de Facebook. Un problème de routage dans l'AS, empêchant les paquets d'arriver, peut également empêcher les serveurs DNS de répondre. Mettre tous ses œufs dans le même panier est décidément une mauvaise pratique. (Notez que ZoneMaster teste cette mauvaise pratique et vous alerte.) C'est un problème connu, déjà signalé par le RFC 2182, en 1997…

Creusons cette idée. Plusieurs observateurs ont noté que les préfixes IP de Facebook ont subitement disparu de la DFZ. Cela explique que les serveurs DNS soient devenus injoignables. Les sondes RIPE Atlas montrent que les traceroute ne vont pas très loin, les préfixes n'étant plus annoncés :

% blaeu-traceroute -r 10 --format 129.134.30.12
Measurement #32421753 Traceroute 129.134.30.12 uses 10 probes
9 probes reported
Test #32421753 done at 2021-10-04T16:26:49Z
From:  89.152.207.6    2860    NOS_COMUNICACOES, PT
Source address:  89.152.207.6
Probe ID:  1001047
1    ['!', '!', '!']
2    10.137.196.193    NA    NA    [10.743, 10.446, 6.726]
3    10.255.48.82    NA    NA    [12.727, 15.974, 14.397]
4    ['*', '*', '*']
5    ['*', '*', '*']
6    ['*', '*', '*']
7    ['*', '*', '*']
8    ['*', '*', '*']
255    ['*', '*', '*']

From:  188.254.182.226    43205    BULSATCOM-BG-AS Sofia, BG
Source address:  192.168.88.13
Probe ID:  15646
1    192.168.88.1    NA    NA    [0.66, 0.415, 0.4]
2    188.254.180.1    43205    BULSATCOM-BG-AS Sofia, BG    [1.552, 1.614, 1.231]
3    46.40.64.1    43205    BULSATCOM-BG-AS Sofia, BG    [2.223, '*', '*']
4    ['*', '*', '*']
5    ['*', '*', '*']
6    ['*', '*', '*']
7    ['*', '*', '*']
8    ['*', '!', '!', '!', '!', '!', '!', '*', '*']
255    ['*', '*', '*']

Des préfixes IP plus généraux sont parfois restés. Ainsi, le 129.134.30.0/24 d'un des serveurs a disparu mais un /17 plus générique est resté. On voit ici (source: RIPEstat, le retrait du /24 puis son rétablissement (129.134.30.0/23, 129.134.31.0/24 et bien d'autres avaient subi le même sort) : facebook-octobre-2021-ripestat.jpg

La panne DNS semble donc avoir été une conséquence d'une fausse manœuvre BGP. Cela explique, par exemple, que le service Tor de Facebook, facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion, ne marche pas non plus (il ne dépend pas du DNS, .onion est spécial).

Le réseau social Instagram pendant la panne. Bien que ses serveurs DNS répondaient parfaitement, le serveur Web dépend de Facebook : facebook-octobre-2021-instagram.png

Plusieurs personnes sur les réseaux sociaux ont également noté que tous les serveurs faisant autorité pour facebook.com étaient sous le même domaine (ns.facebook.com). Ce n'est pas forcément une mauvaise idée. Certes, cela oblige à publier des colles (les adresses IP des serveurs), ce qui complique l'administration. Et, si le domaine en question a un problème, par exemple administratif, cela frappe tous les serveurs. D'un autre côté, cela évite de dépendre de tiers, ce qui est pourquoi cette pratique est parfois recommandée (par exemple par l'ANSSI).

En revanche, il était tout à fait justifié de noter que les TTL de Facebook sont anormalement bas : 300 secondes. Cela veut dire que si la panne dure plus de 5 minutes, ce qui a été le cas, les mémoires des résolveurs ne servent plus à rien. La robustesse du DNS nécessite des TTL bien plus longs (supérieurs à la durée d'une panne typique).

Ah, et puis rappelez-vous que Facebook n'est pas tout l'Internet : tous les autres services fonctionnaient parfaitement (sauf ceux qui avaient choisi de dépendre de Facebook).

Articles dans les médias :

La panne vue par l'excellent service de vérification DNSviz (le même résultat, en ligne) : facebook-octobre-2021-dnsviz.jpg


L'article seul

RFC 9117: Revised Validation Procedure for BGP Flow Specifications

Date de publication du RFC : Août 2021
Auteur(s) du RFC : J. Uttaro (AT&T), J. Alcaide, C. Filsfils, D. Smith (Cisco), P. Mohapatra (Sproute Networks)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF idr
Première rédaction de cet article le 28 septembre 2021


Le RFC 8955 spécifie comment utiliser BGP pour diffuser des règles de filtrage (dites « FlowSpec ») aux routeurs. On voit facilement qu'une annonce de règles de filtrage maladroite ou malveillante pourrait faire bien des dégâts et c'est pour cela que le RFC 8955 insiste sur l'importance de valider ces annonces. Mais les règles de validation étaient trop strictes et ce nouveau RFC les adoucit légèrement.

Le changement ? Le RFC 8955 imposait que la machine qui annonce une règle de filtrage pour un préfixe de destination donné soit également le routeur suivant (next hop) pour le préfixe en question. Cela limitait l'annonce aux routeurs situés sur le trajet des données. En iBGP (BGP interne à un AS, où les routeurs qui annoncent ne sont pas toujours ceux qui transmettent les paquets), cette règle était trop restrictive. (Pensez par exemple à un réflecteur de routes interne, par exemple géré par le SOC, réflecteur qui n'est même pas forcément un routeur.)

La règle nouvelle, plus libérale, ne concerne que du iBGP, interne à un AS ou à une confédération d'AS (RFC 5065). Entre des AS gérés par des organisations différentes (par exemple un AS terminal informant son opérateur Internet de ses désirs de filtrage), la règle de validation reste inchangée.

Plus formellement, la section 6 du RFC 8955, sur la validation des annonces de filtrage, est modifiée, l'étape « l'annonceur doit être également l'annonceur de la meilleure route » devient « l'annonceur doit être l'annonceur de la meilleure route ou bien le chemin d'AS doit être vide (ou n'inclure que des AS de la confédération, s'il y en a une) ». Le RFC précise également que cette validation relâchée doit pouvoir être désactivée par l'administrateur réseaux (s'ielle sait qu'il n'y aura pas d'annonces de filtrage par un routeur qui n'est pas sur le chemin des paquets). Vous noterez plus bas que, pour l'instant, seul Huawei le permet.

Il y a également un léger changement des règles de validation du chemlin d'AS, pour les cas des serveurs de route (a priori, ils ne relaient pas ce genre d'annonces et peuvent donc les rejeter). Le RFC note que, même avec une validation stricte, certaines faiblesses de BGP permettent quand même dans certains cas à tort l'envoi de règles de filtrage. C'est un problème fondamental du RFC 8955, qui n'est donc pas nouveau.

Les nouvelles règles de ce RFC sont déjà largement mises en œuvre chez les routeurs.


Téléchargez le RFC 9117


L'article seul

Fiche de lecture : L'enfer numérique

Auteur(s) du livre : Guillaume Pitron
Éditeur : Les Liens qui Libèrent
979-10-209-0996-1
Publié en 2021
Première rédaction de cet article le 28 septembre 2021


Nous sommes désormais noyés sous les publications qui parlent de l'empreinte environnementale du numérique et notamment de l'Internet. Mais ce nouveau livre est plus approfondi que beaucoup de ces publications et contient des récits intéressants.

Au passage, je ne sais pas si quelqu'un a calculé l'empreinte environnementale des livres qui critiquent l'empreinte environnementale de l'Internet ☺. Plus sérieusement, une bonne partie de ces livres sont juste de l'anti-numérique primaire, par des auteurs nostalgiques d'un passé où seule une minorité d'experts pouvaient décider et s'exprimer, auteurs qui regrettent le bon vieux temps (ils critiquent le numérique mais jamais l'automobile). Ces défauts se retrouvent aussi dans le livre de Guillaume Pitron (par exemple quand il mentionne, même s'il n'insiste pas là-dessus, qu'il faudrait que des autorités décident des usages légitimes de l'Internet) mais heureusement cela ne fait pas la totalité du livre.

Donc, de quoi parle ce livre ? De beaucoup de choses mais surtout des conséquences environnementales et (à la fin) géopolitiques de l'usage de l'Internet. L'auteur insiste sur la matérialité du monde numérique : loin des discours marketing lénifiants sur le « virtuel » ou sur le « cloud », le monde numérique s'appuie sur la matière, des métaux rares, des centrales électriques fonctionnant au charbon ou au nucléaire, des centres de données énormes. Ce discours n'est pas très original, cet argument de la matérialité a été souvent cité ces dernières années mais le poids du discours commercial est tel que beaucoup d'utilisateurs du numérique n'ont pas encore conscience de cette matérialité. Et elle a des conséquences concrètes, notamment en matière environnementale. Le numérique consomme de l'énergie, ce qui a des conséquences (par exemple en matière de relâchement de gaz à effet de serre, qui contribuent au réchauffement planétaire) et des matériaux dont l'extraction se fait dans des conditions souvent terribles et pas seulement pour l'environnement, mais surtout pour les humains impliqués.

Quelle que soit la part réelle du numérique dans les atteintes à l'environnement (les chiffres qui circulent sont assez « doigt mouillé »), il n'y a pas de doute que, face à la gravité du changement climatique, tout le monde devra faire un effort, le numérique comme les autres. Des techniques frugales comme LEDBAT (RFC 6817) ou Gemini sont des briques utiles de cet effort (mais l'auteur ne les mentionne pas).

C'est après que les choses se compliquent. Qui doit agir, où et comment ? Le livre contient beaucoup d'informations intéressantes et de reportages variés et met en avant certaines initiatives utiles. C'est par exemple le cas du Fairphone, un ordiphone conçu pour limiter l'empreinte environnementale et sociale. Beaucoup de critiques ont été émises contre ce projet, notant que les objectifs n'étaient pas forcément atteints, mais je les trouve injustes : une petite société locale n'a pas les mêmes armes qu'un GAFA pour changer le monde, et ses efforts doivent être salués, il vaut mieux ne faire qu'une partie du chemin plutôt que de rester assis à critiquer. C'est à juste titre que le projet Fairphone est souvent cité dans le livre. (Sur ce projet, je recommande aussi l'interview d'Agnès Crepet dans la série audio « L'octet vert ».)

Ces reportages sont la partie la plus intéressante du livre et une bonne raison de recommander sa lecture. Il comprend également une partie géopolitique intéressante, détaillant notamment l'exploitation de plus en plus poussée de l'Arctique (à la fois rendue possible par le changement climatique, et l'aggravant) et les projets gigantesques et pas du tout bienveillants de la Chine. Même si beaucoup de projets (comme le câble Arctic Connect) se sont cassés la figure, bien d'autres projets leur succèdent.

Par contre, le livre ne tient pas les promesses de son sous-titre « Voyage au bout d'un like ». S'il explique rapidement que le simple fait de cliquer sur un bouton « J'aime » va mettre en action de nombreuses machines, parcourir un certain nombre de kilomètres, et écrire dans plusieurs bases de données, il ne détaille pas ce parcours et ne donne pas de chiffres précis. Il est vrai que ceux-ci sont très difficiles à obtenir, à la fois pour des raisons techniques (la plupart des équipements réseau ont une consommation électrique constante et donc déterminer « la consommation d'un Like » n'a donc guère de sens) et politiques (l'information n'est pas toujours disponible et le greenwashing contribue à brouiller les pistes). L'auteur oublie de rappeler la grande faiblesse méthodologique de la plupart des études sur la question, et des erreurs d'ordre de grandeur comme l'affirmation p. 157 que les États-Unis produisent… 640 tonnes de charbon par an n'aident pas à prendre aux sérieux les chiffres.

Mais le livre souffre surtout de deux problèmes : d'abord, il réduit l'utilisation de l'Internet au Like et aux vidéos de chat, souvent citées. D'accord, c'est amusant et, comme beaucoup d'utilisateurs, je plaisante moi-même souvent sur ce thème. Mais la réalité est différente : l'Internet sert à beaucoup d'activités, dont certaines sont cruciales, comme l'éducation, par exemple. L'auteur critique le surdimensionnement des infrastructures par les opérateurs, jugeant qu'il s'agit d'un gaspillage aux conséquences environnementales lourdes. Mais il oublie que ce surdimensionnement est au contraire indispensable à la robustesse de l'Internet, comme on l'a bien vu pendant le confinement, avec l'augmentation du trafic (voir le RFC 9075). Outre les pandémies, on pourrait également citer les attaques par déni de service (la cybersécurité est absente du livre), qui sont une excellente raison de surdimensionner les infrastructures.

Et le deuxième problème ? Parce que l'auteur pourrait répondre qu'il est bien conscient de la coexistence d'usages « utiles » et « futiles » de l'Internet et qu'il suggère de limiter les seconds. C'est là qu'est le deuxième problème : qui va décider ? Personnellement, je pense que le sport-spectacle (par exemple les scandaleux jeux olympiques de Paris, monstruosité environnementale) est à bannir des réseaux (et du reste du monde, d'ailleurs). Mais je ne serais probablement pas élu avec un tel programme. Personne n'est d'accord sur ce qui est sérieux et ce qui est futile. Qui va décider ? Des phrases du livre comme le fait d'ajouter « sacro-sainte » devant chaque mention de la neutralité de l'Internet ont de quoi inquiéter. J'avais déjà relevé ce problème dans ma critique du dernier livre de Ruffin. Une décision démocratique sur les usages, pourquoi pas ; mais je vois un risque sérieux de prise de pouvoir par des sages auto-proclamés qui décideraient depuis leurs hauteurs de ce qui est bon pour le peuple ou pas.

Je ne vais pas citer les articles publiés dans les médias sur ce livre, tous unanimement élogieux et sans jamais une seule critique. La corporation médiatique se serre les coudes, face à un Internet qui a écorné leur monopole de la parole. Mais, sinon, une autre critique de ce livre, sous un angle assez différent, celle de laem.


L'article seul

RFC 9115: An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates

Date de publication du RFC : Septembre 2021
Auteur(s) du RFC : Y. Sheffer (Intuit), D. López, A. Pastor Perales (Telefonica I+D), T. Fossati (ARM)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF acme
Première rédaction de cet article le 21 septembre 2021


Ce nouveau RFC décrit un profil du protocole ACME d'obtention de certificat, profil qui permet de déléguer la demande à un tiers. C'est surtout utile pour le cas où vous sous-traitez l'hébergement de votre site Web (par exemple sur un CDN) : le sous-traitant peut alors demander un certificat, avec sa clé privée à lui, pour un nom de domaine que vous contrôlez et prouver qu'il héberge bien le serveur pour ce nom. Serveurs et clients TLS n'ont pas besoin d'être modifiés (seuls les serveurs et clients ACME le seront), et, bien entendu, le titulaire du nom de domaine garde un complet contrôle et peut, par exemple, révoquer les certificats obtenus par ses sous-traitants.

Ce profil utilise lui-même le profil STAR (Short-Term, Automatically Renewed) décrit dans le RFC 8739 donc faites bien attention à avoir lu le RFC 8739 avant. Le cas typique d'utilisation de ce mécanisme de délégation est le CDN. Un webmestre (l'IdO pour Identifier Owner car il est titulaire du nom de domaine, mettons foobar.example) a un site Web et sous-traite tout ou partie du service à un CDN, appelé ici NDC pour Name Delegation Consumer (et la ressemblance entre les sigles CDN et NDC est volontaire). Le CDN devra pouvoir répondre aux requêtes HTTPS pour www.foobar.example et donc présenter un certificat au nom www.foobar.example. Avec ACME, l'IdO peut obtenir un tel certifiat mais il ne souhaite probablement pas transmettre la clé privée correspondante au NDC. La solution de notre RFC est d'utiliser une extension à ACME, permettant la délégation du nom. Le NDC pourra alors obtenir un certificat STAR (de courte durée de vie, donc) pour www.foobar.example. Pas besoin de partager une clé privée, ni de transmettre des secrets de longue durée de vie (les délégations sont révocables, et les certificats STAR ne durent pas longtemps, le NDC devra renouveller souvent et ça cessera en cas de révocation). C'est l'utilisation typique de la délégation mais d'autres sont possibles (par exemple avec des certificats ordinaires, non-STAR). Le RFC note que la solution de délégation ne modifie qu'ACME, et pas TLS, et qu'elle marche donc avec les clients et serveurs TLS actuels (contrairement à d'autres propositions qui sont étudiées).

Pour que la délégation fonctionne, l'IdO doit avoir un serveur ACME, auquel le NDC devra se connecter, et s'être mis d'accord avec le NDC sur les paramètres à utiliser. C'est donc une étape relativement nouvelle, l'utilisateur d'ACME typique n'ayant qu'un client ACME, seule l'AC a un serveur. Mais c'est quand même plus simple que de monter une AC. Le serveur ACME chez l'IdO ne signera pas de certificats, il relaiera simplement la requête. Quand le NDC aura besoin d'un certificat, il enverra une demande à l'IdO, qui la vérifiera et, devenant client ACME, l'IdO enverra une demande à l'AC. Si ça marche, l'IdO prévient le NDC, et celui-ci récupérera le certificat chez l'AC (par unauthenticated GET, RFC 8739, section 3.4).

Le protocole ACME gagne un nouveau type d'objet, les délégations, qui indiquent ce qu'on permet au NDC. Comme les autres objets ACME, elles sont représentées en JSON et voici un exemple :

{
     "csr-template": {
       "keyTypes": [
         {
           "PublicKeyType": "id-ecPublicKey",
           "namedCurve": "secp256r1",
           "SignatureType": "ecdsa-with-SHA256"
         }
       ],
       "subject": {
         "country": "FR",
         "stateOrProvince": "**",
         "locality": "**"
       },
       "extensions": {
         "subjectAltName": {
           "DNS": [
             "www.foobar.example"
           ]
         },
         "keyUsage": [
           "digitalSignature"
         ],
         "extendedKeyUsage": [
           "serverAuth"
         ]
         }
     }
}
  

(Les champs des extensions comme keyUsage sont dans un nouveau registre IANA ; on peut ajouter des champs, selon la politique « spécification nécessaire ».) Ici, le NDC est autorisé à demander des certificats ECDSA pour le nom www.foobar.example. Quand le NDC enverra sa requête de certificat à l'IdO, il devra inclure cet objet « délégation », que l'IdO pourra comparer avec ce qu'il a configuré pour ce NDC. Voici un exemple partiel, envoyé lors d'un POST HTTPS au serveur ACME de l'IdO :

   {
     "protected": base64url({
       "alg": "ES256",
       "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
       "nonce": "Alc00Ap6Rt7GMkEl3L1JX5",
       "url": "https://acme.ido.example/acme/new-order"
     }),
     "payload": base64url({
       "identifiers": [
         {
           "type": "dns",
           "value": "www.foobar.example"
         }
       ],
       "delegation":
         "https://acme.ido.example/acme/delegation/gm0wfLYHBen"
     }),
     "signature":    ...
  

(Le nouveau champ delegation a été placé dans le registre IANA.) Le NDC enverra ensuite le CSR, et l'IdO relaiera la requête vers le serveur ACME de l'AC (moins l'indication de délégation, qui ne regarde pas l'AC).

Quand on utilise un CDN, il est fréquent qu'on doive configurer un alias dans le DNS pour pointer vers un nom indiqué par l'opérateur du CDN. Voici par exemple celui de l'Élysée :

% dig CNAME www.elysee.fr 
...
;; ANSWER SECTION:
www.elysee.fr.		3600 IN	CNAME 3cifmt6.x.incapdns.net.
...

L'extension au protocole ACME spécifiée dans notre RFC permet au NDC d'indiquer cet alias dans sa requête, l'IdO peut alors l'inclure dans sa zone DNS.

Tous les serveurs ACME ne seront pas forcément capables de gérer des délégations, il faudra donc l'indiquer dans les capacités du serveur, avec le champ delegation-enabled (mis dans le registre IANA).

Comme indiqué plus haut, l'IdO peut arrêter la délégation quand il veut, par exemple parce qu'il change de CDN. Cet arrêt se fait par une interruption explicite de la demande STAR (RFC 8739, section 3.1.2). Si les certificats ne sont pas des STAR, le mécanisme à utiliser est la révocation normale des certificats.

Après cet examen du protocole, la section 3 de notre RFC décrit le comportement de l'AC. Il n'y a pas grand'chose à faire pour l'AC (le protocole est entre le NDC et l'IdO) à part à être capable d'accepter des récupérations non authentifiées de certificats (car le NDC n'a pas de compte à l'AC).

On a parlé plus haut du CSR. Il doit se conformer à un certain gabarit, décidé par l'IdO. Ce gabarit est évidemment au format JSON, comme le reste d'ACME. La syntaxe exacte est décrite avec le langage CDDL (RFC 8610) et figure dans l'annexe A ou bien, si vous préférez, avec le langage JSON Schema, utilisé dans l'annexe B. Voici l'exemple de gabarit du RFC :

  {
     "keyTypes": [
       {
         "PublicKeyType": "rsaEncryption",
         "PublicKeyLength": 2048,
         "SignatureType": "sha256WithRSAEncryption"
       },
       {
         "PublicKeyType": "id-ecPublicKey",
         "namedCurve": "secp256r1",
         "SignatureType": "ecdsa-with-SHA256"
       }
     ],
     "subject": {
       "country": "CA",
       "stateOrProvince": "**",
       "locality": "**"
     },
     "extensions": {
       "subjectAltName": {
         "DNS": [
           "abc.ido.example"
         ]
       },
       "keyUsage": [
         "digitalSignature"
       ],
       "extendedKeyUsage": [
         "serverAuth",
         "clientAuth"
       ]
     }
   }

Dans cet exemple, l'IdO impose au NDC un certificat RSA ou ECDSA et rend impérative (c'est le sens des deux astérisques) l'indication de la province et de la ville. L'IdO doit évidemment vérifier que le CSRT reçu se conforme bien à ce gabarit.

Le RFC présente (en section 5) quelques autres cas d'utilisation de cette délégation. Par exemple, un IdO peut déléguer à plusieurs CDN, afin d'éviter que la panne d'un CDN n'arrête tout. Avec la délégation, ça se fait tout seul, chacun des CDN est authentifié, et demande séparément son certificat.

Autre cas rigolo, celui où le CDN délègue une partie du service à un CDN plus petit. Le modèle de délégation ACME peut s'y adapter (le petit CDN demande un certificat au gros, qui relaie à l'IdO…), si les différentes parties sont d'accord.

Enfin, la section 7 du RFC revient sur les propriétés de sécurité de ces délégations. En gros, il faut avoir confiance en celui à qui on délègue car, pendant la durée de la délégation, il pourra faire ce qu'il veut avec le nom qu'on lui a délégué, y compris demander d'autres certificats en utilisant sa délégation du nom de domaine. Il existe quelques mesures techniques que l'IdO peut déployer pour empêcher le NDC de faire trop de bêtises. C'est le cas par exemple des enregistrements DNS CAA (RFC 8659) qui peuvent limiter le nombre d'AC autorisées (voir aussi le RFC 8657).

Je ne connais pas encore d'opérateur de CDN qui mette en œuvre cette solution.


Téléchargez le RFC 9115


L'article seul

RFC 9098: Operational Implications of IPv6 Packets with Extension Headers

Date de publication du RFC : Septembre 2021
Auteur(s) du RFC : F. Gont (SI6 Networks), N. Hilliard (INEX), G. Doering (SpaceNet AG), W. Kumari (Google), G. Huston (APNIC), W. Liu (Huawei Technologies)
Pour information
Réalisé dans le cadre du groupe de travail IETF v6ops
Première rédaction de cet article le 20 septembre 2021


IPv6 souffre de réseaux mal gérés qui se permettent de jeter les paquets ayant des caractéristiques normales, mais qui déplaisent à certains équipements réseau. C'est par exemple le cas des paquets utilisant les en-têtes d'extension. Pourquoi les paquets utilisant ces en-têtes sont-ils souvent jetés ?

Ces en-têtes d'extension (qui n'ont pas d'équivalent en IPv4) sont normalisés dans le RFC 8200, section 4. Ils servent à la fois à des fonctions de base d'IPv6 (comme la fragmentation) et à étendre le protocole si nécessaire. Mais, en pratique, on observe trop souvent que les paquets IPv6 utilisant ces en-têtes d'extension ne passent pas sur certains réseaux. Ce RFC vise à étudier pourquoi, et à expliquer les conséquences. Comme toujours quand on explique un phénomène (la délinquance, par exemple), des gens vont comprendre de travers et croire qu'on justifie le phénomène en question (« expliquer, c’est déjà vouloir un peu excuser », avait stupidement dit un ancien premier ministre français, à propos du terrorisme djihadiste). Le cas est d'autant plus fréquent qu'en français, « comprendre » est ambigu, car il peut désigner l'explication (qui est utile aussi bien aux partisans qu'aux adversaires d'un phénomène) que la justification. Bref, ce RFC explique pourquoi des paquets innocents sont détruits, il ne dit pas qu'il faut continuer à le faire !

La section 4 du RFC explique la différence entre l'en-tête d'un paquet IPv6 et celui d'un paquet de l'ancienne version. Dans les deux versions, le problème est de placer des options dans les en-têtes. Le gros changement est l'utilisation par IPv6 d'un en-tête de taille fixe (40 octets), suivi d'une liste chainée d'en-têtes d'extension permettant d'encoder ces options. Au contraire, IPv4 avait un en-tête de taille variable (entre 20 et 60 octets), avec un champ indiquant sa longueur, champ qu'il fallait lire avant d'accéder à l'en-tête. Le mécanisme d'IPv4 n'était ni pratique, ni rapide, mais celui d'IPv6 n'est pas plus satisfaisant : il faut lire toute la liste chainée (dont la longueur est quelconque et non limitée) si on veut accéder aux informations au-dessus de la couche 3. Ce n'est pas un problème pour les routeurs, à qui la couche 3 suffit (à part le cas de l'en-tête Hop-by-hop options), mais c'est ennuyeux pour les autres boitiers situés sur le chemin, comme les pare-feux. Les évolutions récentes d'IPv6 ont aidé, comme l'obligation que tous les en-têtes d'extension soient dans le premier fragment, si le datagramme est fragmenté (RFC 7112), ou comme l'imposition d'un format commun aux futurs en-têtes d'extension (dans le RFC 6564), mais l'analyse de la liste des en-têtes d'extension reste un travail pénible pour les machines.

Le problème est identifié depuis longtemps. Il est analysé dans l'Internet-Draft draft-taylor-v6ops-fragdrop, dans draft-wkumari-long-headers, dans draft-kampanakis-6man-ipv6-eh-parsing, dans draft-ietf-opsec-ipv6-eh-filtering mais aussi dans des RFC, le RFC 7113 et le RFC 8900. Cela a mené à plusieurs changements dans la norme, je vous renvoie aux RFC 5722, RFC 7045, RFC 8021, etc. Plusieurs changements ont été intégrés dans la dernière révision du RFC principal de la norme, le RFC 8200. Ainsi, celui-ci dispense désormais les routeurs de chercher un éventuel en-tête d'extension Hop-by-hop options.

Parallèlement à ces analyses du protocole, diverses études ont porté sur le phénomène des paquets jetés s'ils contenaient des en-têtes d'extension. Cela a été documenté dans « Discovering Path MTU black holes on the Internet using RIPE Atlas », dans « IPv6 Extension Headers in the Real World v2.0 », également dans « Dealing with IPv6 fragmentation in the DNS » et « Measurement of IPv6 Extension Header Support » ainsi que dans le RFC 7872.

Comment est-ce que les équipements intermédiaires du réseau fonctionnent, et pourquoi est-ce que les en-têtes d'extension IPv6 peuvent parfois les défriser ? La section 6 du RFC rappelle l'architecture de ces machines. Un routeur de cœur de réseau est très différent de l'ordinateur de base, avec son processeur généraliste et sa mémoire de grande taille, ce qui le rend lent, mais souple. Au contraire, la transmission des paquets par le routeur est en général faite par du matériel spécialisé, ASIC ou NPU. (Vous pouvez consulter des explications dans l'exposé fait à l'IETF « Modern Router Architecture for Protocol Designers » et dans l'article « Modern router architecture and IPv6 ».) Avant de transmettre un paquet reçu sur l'interface de sortie, le routeur doit trouver quelle interface utiliser. Une méthode courante est de prendre les N premiers octets du paquet et de les traiter dans une TCAM ou une RLDRAM, où se fera la détermination du saut suivant (et donc de l'interface de sortie). Le choix du nombre N est crucial : plus il est petit, plus le routeur pourra traiter de paquets, mais moins il aura d'information sur le paquet. (En pratique, on observe des N allant de 192 à 384 octets.) Du fait qu'un routeur se limite normalement à la couche Réseau, et que l'en-tête IPv6 a une taille fixe, envoyer simplement les 40 octets de cet en-tête devrait suffire. Mais lisez plus loin : certains routeurs ou autres équipements intermédiaires sont configurés pour regarder au-delà, et voudraient des informations de la couche Transport, plus dure à atteindre.

Une solution, pour les routeurs qui ne lisent qu'un nombre limité d'octets avant de prendre une décision, est de lire les en-têtes d'extension un par un, et de réinjecter le reste du paquet dans le dispositif de traitement. Ça se nomme la recirculation, c'est plus lent, mais ça marche quelle que soit la longueur de la chaîne des en-têtes d'extension.

Comme le routeur comprend toujours un processeur généraliste (ne serait-ce que pour faire tourner les fonctions de contrôle comme SSH et les protocoles de routage), une autre solution serait d'envoyer à ce processeur les paquets « compliqués » (mais lire le RFC 6192 d'abord). L'énorme différence de performance entre le processeur généraliste et les circuits spécialisés fait que ce ne serait pas une solution réaliste sauf pour un trafic très modéré. (Le RFC note que certains routeurs ont trois dispositifs de traitement des paquets, et pas seulement deux comme présenté plus haut : outre le processeur généraliste, qui ne leur sert qu'aux fonctions de contrôle, et des circuits matériels spécialisés, ils ont un dispositif logiciel de transmission des paquets. Plus souple que les circuits spécialisés, il n'est pas forcément plus rapide que le processeur généraliste mais, au moins, il n'interfère pas avec les fonctions de contrôle.)

Bon, on l'a déjà dit, mais cela vaut la peine de le répéter : à part le cas (agaçant) de l'en-tête Hop-by-hop options, un routeur, équipement de couche 3 n'a normalement aucun besoin d'aller regarder tous les en-têtes d'extension (qui sont presque tous pour la machine terminale de destination uniquement). Encore moins de faire du DPI et d'aller chercher des informations dans les couches 4 à 7. Mais la section 7 du RFC explique pourquoi certains routeurs le font quand même (il s'agit d'une description de leurs pratiques, pas une approbation ; beaucoup des raisons données sont mauvaises).

D'abord, la répartition de charge et l'ECMP. Si un routeur peut faire passer un paquet via deux interfaces différentes, laquelle choisir ? Alterner (un coup à gauche, un coup à droite) augmenterait la probabilité d'une arrivée des paquets dans le désordre. On préfère la prédictabilité : tous les paquets d'un même flot doivent suivre le même chemin. Comment déterminer le « flot », notion parfois un peu floue ? En restant dans les couches basses, on peut utiliser uniquement les adresses IP de source et de destination mais elles ne sont pas assez discriminantes. En IPv6, on peut en théorie utiliser l'étiquette de flot (normalisé dans le RFC 6437, ainsi que les RFC 6438 et RFC 7098 pour son utilisation) mais elle n'est pas toujours présente, en partie (encore !) par la faute de middleboxes qui, ignorant ce concept d'étiquette de flot, jetaient les paquets qui en avaient une. (Voir les articles de I. Cunha, «  IPv4 vs IPv6 load balancing in Internet routes » et J. Jaeggli, «  IPv6 flow label: misuse in hashing ».) En pratique, les systèmes qui ont besoin d'identifier les flots utilisent plutôt une heuristique : le tuple à cinq élements {protocole de transport, adresse IP source, adresse IP destination, port source, port destination}. Ce n'est pas parfait mais, en pratique, cela marche à peu près. On voit que cela nécessite d'accéder à de l'information de la couche Transport, les ports. (Cette heuristique a d'autres limites : par exemple elle ne marche pas si une partie de la couche Transport est chiffrée, comme c'est le cas avec QUIC.)

Autre cas où un boitier intermédiaire ressent le besoin d'accéder aux informations des couches supérieures, les ACL. La plupart des pare-feux permettent d'utiliser comme critère de filtrage les numéros de ports, ce qui va nécessiter d'analyser la chaine des en-têtes d'extension IPv6 pour parvenir à la couche Transport. Entre les pare-feux mal faits qui cherchent les informations de la couche Transport immédiatement après l'en-tête fixe (car le programmeur a tout simplement sauté la partie du RFC qui parlait des en-têtes d'extension) et les difficultés posées par le fait, qu'avant le RFC 6564, les en-têtes d'extension inconnus étaient impossibles à analyser, on voit qu'arriver à la couche Transport n'est pas si facile que ça (le RFC dit qu'il est plus compliqué d'analyser IPv6 qu'IPv4, ce qui est très contestable ; mais ce n'est en effet pas plus facile). Cela peut avoir des conséquences en terme de sécurité, par exemple si un méchant ajoute des en-têtes d'extension dans l'espoir que ses paquets ne soient pas correctement identifiés (cf. RFC 7113).

Autre exemple, le réassemblage des paquets fragmentés nécessite un état (mémoriser les fragments en cours de réassemblage), ce qui peut être fatal à la mémoire du pare-feu, notamment en cas d'attaque. Pour les coûts de ce filtrage, voir l'article d'E. Zack « Firewall Security Assessment and Benchmarking IPv6 Firewall Load Tests ». Cette difficulté peut encourager les pare-feux à jeter les paquets ayant des en-têtes d'extension, surtout si un administrateur réseaux ignorant dit bien fort « ces en-têtes d'extension ne servent à rien de toute façon » (RFC 7872).

Un problème proche est celui de la protection contre les attaques par déni de service. Filtrer avec les adresses IP peut être fait rès efficacement (cf. RFC 5635) mais ne marche pas, par exemple si l'adresse IP source est usurpée. Une des méthodes utilisées alors est de repérer un motif récurrent dans les paquets envoyés par l'attaquant, et de filtrer sur ce motif (vous pouvez lire ici un exemple avec le DNS). Là encore, des informations au-delà de la couche Réseau sont nécessaires. Toujours en sécurité, les NIDS ont aussi besoin de plus d'informations que ce que fournit la couche Réseau.

Et, bien sûr, comme toute complexité, les en-têtes d'extension augmentent les risques de sécurité, d'autant plus qu'il y a un cercle vicieux : comme ils sont peu utilisés, le code qui les traite est peu testé, donc il y a des bogues, donc ils sont peu utilisés, etc.

Donc, un certain nombre de machines intermédiaires, qui assurent des fonctions allant au-delà de ce que fait un « simple » routeur, ont des problèmes avec les en-têtes d'extension IPv6 et choisissent souvent la solution de facilité, qui est de les jeter systématiquement.


Téléchargez le RFC 9098


L'article seul

Utiliser les « middleboxes » de censure pour des attaques par déni de service

Première rédaction de cet article le 17 septembre 2021


Une méthode courante pour réaliser une attaque par déni de service sur l'Internet est de trouver un réflecteur, une machine qui, sollicitée par l'attaquant, va envoyer des paquets vers la victime. Les bons (du point de vue de l'attaquant…) réflecteurs font en outre de l'amplification, émettant davantage de paquets et/ou d'octets qu'envoyés par l'attaquant. Un article à la conférence Usenix d'août 2021 expose un nouveau type de réflecteurs : les innombrables middleboxes placées pour censurer des communications sont tellement mal conçues qu'elles font d'excellents (du point de vue de l'attaquant…) réflecteurs.

Détaillons cet article, « Weaponizing Middleboxes for TCP Reflected Amplification ». Le but d'un attaquant est de trouver de nombreux réflecteurs (plus ils sont nombreux, plus l'attaque sera efficace) mais aussi de maximiser l'amplification (on parle de BAF - Bandwidth Amplification Factor - pour le gain en octets et de PAF - Packet Amplification Factor - pour le gain en paquets). On a ainsi vu des attaques exploitant l'amplification de protocoles utilisant UDP, comme par exemple le DNS ou bien NTP. Une des bases de l'attaque par réflexion étant de mentir sur son adresse IP, a priori, ces attaques ne sont pas possibles avec TCP, qui protège contre cette usurpation (RFC 5961). Mais, en fait, on sait déjà que des attaques par réflexion avec TCP sont possibles, et qu'elles ont parfois un bon BAF. C'est ce que développent les auteurs de l'article.

Comme réflecteurs, ils utilisent des middleboxes, ces engins installés en intermédiaires sur un grand nombre de chemins sur l'Internet, qui examinent le trafic et agissent, souvent n'importe comment. Une utilisation courante des middleboxes est la censure, soit étatique (au niveau d'un pays), soit au niveau d'un réseau local. Par exemple, la middlebox va examiner le trafic HTTP et, si l'adresse IP de destination est sur sa liste de blocage, empêcher la communication. Une des façons de le faire est de prétendre être le vrai serveur et de renvoyer une page indiquant que la connexion est bloquée : uae-web-blocked.jpg

Arrivé là, vous commencez à voir comment cela peut être exploité pour une attaque : l'attaquant envoie un paquet TCP d'ouverture de connexion (paquet SYN) vers une adresse IP censurée, en usurpant l'adresse IP de la victime, et le message de censure, avec l'image, sera envoyée à la victime, fournissant un BAF sérieux.

Mais, là, vous allez me dire que ça ne marchera pas, TCP ne fonctionne pas comme cela : la middlebox n'arrivera pas à établir une session TCP complète puisque la victime ne répondra pas aux accusés de réception, ou bien enverra un paquet de fin de session (paquet RST). Mais c'est là que l'article devient intéresssant : les auteurs ont découvert que de nombreuses middleboxes ne font pas du TCP correct : elles envoient le message de censure (une page Web complète, avec images), sans attendre qu'une session TCP soit établie.

Ce n'est pas uniquement de l'incompétence de la part des auteurs des logiciels qui tournent dans la middlebox. C'est aussi parce que, notamment dans le cas de la censure étatique, la middlebox ne voit pas forcément passer tous les paquets, le trafic Internet étant souvent asymétrique (si on a plusieurs liaisons avec l'extérieur). Et puis il faut aller vite et avoir le moins possible d'état à mémoriser. La middlebox ne se donne donc pas la peine de vérifier que la session TCP a été établie, elle crache ses données tout de suite, assomant la victime pour le compte de l'attaquant. L'amplification maximale observée (en octets, le BAF) a été de plus de 7 000… Et certains cas pathologiques permettaient de faire encore mieux.

Comment ont été trouvées les middleboxes utilisables ? Comme l'attaque ne marche que si la middlebox ne fait pas du TCP correct, les conditions exactes du déclenchement de la réflexion ne sont pas faciles à déterminer. Les auteurs ont donc envoyé une variété de paquets TCP (avec ou sans PSH, ACK, etc) et utilisé le système d'apprentissage Geneva pour découvrir la solution la plus efficace. (Au passage, le meilleur déclencheur de la censure semble être www.youporn.com, largement bloqué un peu partout.) En balayant tout l'Internet avec ZMap, ils ont pu identifier un grand nombre de réflecteurs. Ils ne les ont évidemment pas utilisé pour une vraie attaque, mais des méchants auraient pu le faire, montrant ainsi le danger que présente ces boitiers bogués et largement répandus (ils sont très populaires auprès des décideurs), alors qu'ils fournissent une armée de réflecteurs prêts à l'emploi.

Certains réflecteurs arrivent même à des facteurs d'amplification incroyables, voire infinis (une fois un paquet envoyé par l'attaquant, le tir de barrage du réflecteur ne cesse jamais). Les auteurs expliquent cela par des boucles de routage, faisant passer le paquet déclencheur plusieurs fois par la middlebox (et parfois sans diminuer le TTL), ainsi que par des réactions aux réactions de la victime (qui envoie des paquets RST).

Des bons réflecteurs d'attaque ont été identifiés à des nombreux endroits, comme l'université Brigham Young ou la municipalité de Jacksonville. Identifier les produits utilisés a été plus difficile mais on pu repérer le Dell SonicWALL NSA 220 ou un équipement Fortinet. D'un point de vue géopolitique, on notera que les réflecteurs sont situés un peu partout, avec évidemment davantage de présence dans les dictatures. Par contre, la Chine est assez peu représentée, leur système de censure étant (hélas) plus intelligement bâti.


L'article seul

Version 14 d'Unicode

Première rédaction de cet article le 16 septembre 2021


Le mardi 14 septembre est sortie la version 14 d'Unicode (retardée pour cause de Covid-19). Une description officielle des principaux changements est disponible mais voici ceux qui m'ont intéressé particulièrement. (Il n'y a pas de changement radical.)

Pour explorer plus facilement la grande base Unicode, j'utilise un programme qui la convertit en SQL et permet ensuite de faire des analyses variées. Faisons quelques requêtes SQL :

ucd=> SELECT count(*) AS Total FROM Characters;
 total  
--------
 144762

Combien de caractères sont arrivés avec la version 14 ?

ucd=> SELECT version,count(version) FROM Characters GROUP BY version ORDER BY version::float;
...
 11.0    |   684
 12.0    |   554
 12.1    |     1
 13.0    |  5930
 14.0    |   838

838 nouveaux caractères, c'est une version calme (la version 13 apportait bien davantage de caractères). Quels sont ces nouveaux caractères ?

ucd=> SELECT To_U(codepoint) AS Code_point, name FROM Characters WHERE version='14.0' ORDER BY Codepoint;
 code_point |                                    name                                    
-----------+----------------------------------------------------------------------------
...
 U+870      | ARABIC LETTER ALEF WITH ATTACHED FATHA
 U+871      | ARABIC LETTER ALEF WITH ATTACHED TOP RIGHT FATHA
 U+872      | ARABIC LETTER ALEF WITH RIGHT MIDDLE STROKE
 U+873      | ARABIC LETTER ALEF WITH LEFT MIDDLE STROKE
 U+874      | ARABIC LETTER ALEF WITH ATTACHED KASRA
...
 U+12F90   | CYPRO-MINOAN SIGN CM001
 U+12F91   | CYPRO-MINOAN SIGN CM002
 U+12F92   | CYPRO-MINOAN SIGN CM004
 U+12F93   | CYPRO-MINOAN SIGN CM005
 ...
 U+1CF00    | ZNAMENNY COMBINING MARK GORAZDO NIZKO S KRYZHEM ON LEFT
 U+1CF01    | ZNAMENNY COMBINING MARK NIZKO S KRYZHEM ON LEFT
 U+1CF02    | ZNAMENNY COMBINING MARK TSATA ON LEFT
...
 U+1E290   | TOTO LETTER PA
 U+1E291   | TOTO LETTER BA
 U+1E292   | TOTO LETTER TA
 U+1E293   | TOTO LETTER DA
...
 U+1FAAC    | HAMSA
 U+1FAB7    | LOTUS
 U+1FAB8    | CORAL
 U+1FAB9    | EMPTY NEST
 U+1FABA    | NEST WITH EGGS
 ...

Cette version amène en effet plusieurs écritures nouvelles comme le toto, le chypro-minoen (toujours pas déchiffré, ce qui explique que ses caractères aient un numéro et pas un nom), le vieil ouïghour (écriture pour laquelle ont été fabriquées les plus anciens caractères mobiles connus), le vithkuqi, ou le tangsa. On trouve également beaucoup de nouveaux caractères de l'alphabet arabe pour écrire des langues non-arabes.

Plus anecdotique, on trouve également la notation musicale Znamenny.

Si vous avez les bonnes polices de caractères, vous allez pouvoir voir quelques exemples (sinon, le lien mène vers Uniview). Un nouveau symbole apparait, le Som (), pour la monnaie officielle du Kirghizistan. Et on a l'habituelle succession de nouveaux émojis, plus ou moins utiles. Les recruteurs aimeront l'index pointé 🫵, les royalistes seront contents de la tête couronnée 🫅, les nostalgiques d'Usenet auront le troll 🧌, les fanas de Dune frémiront en voyant l'eau qu'on verse 🫗, les geeks s'angoisseront de la batterie vide 🪫 et les partisans de la surveillance de la population noteront qu'on a un émoji « carte d'identité » 🪪. Les personnes transgenres remarqueront l'homme enceint (🫃, ainsi que la personne enceinte 🫄, la femme enceinte 🤰 était arrivée en Unicode version 9).

Tiens, d'ailleurs, combien de caractères Unicode sont des symboles (il n'y a pas que les emojis parmi eux, mais Unicode n'a pas de catégorie « emoji ») :

 ucd=> SELECT count(*) FROM Characters  WHERE category IN ('Sm', 'Sc', 'Sk', 'So');
 count 
-------
  7741

Ou, en plus détaillé, et avec les noms longs des catégories :

ucd=> SELECT description,count(category) FROM Characters,Categories WHERE Categories.name = Characters.category AND category IN ('Sm', 'Sc', 'Sk', 'So') GROUP BY category, description;
   description   | count 
-----------------+-------
 Modifier_Symbol |   125
 Other_Symbol    |  6605
 Math_Symbol     |   948
 Currency_Symbol |    63

L'article seul

RFC 9109: Network Time Protocol Version 4: Port Randomization

Date de publication du RFC : Août 2021
Auteur(s) du RFC : F. Gont, G. Gont (SI6 Networks), M. Lichvar (Red Hat)
Chemin des normes
Première rédaction de cet article le 13 septembre 2021


Le protocole NTP utilisait traditionnellement un port bien connu, 123, comme source et comme destination. Cela facilite certaines attaques en aveugle, lorsque l'attaquant ne peut pas regarder le trafic, mais sait au moins quels ports seront utilisés. Pour compliquer ces attaques, ce RFC demande que NTP utilise des numéros de ports aléatoires autant que possible.

NTP est un très vieux protocole (sa norme actuelle est le RFC 5905 mais sa première version date de 1985, dans le RFC 958). Dans son histoire, il a eu sa dose des failles de sécurité. Certaines des attaques ne nécessitaient pas d'être le chemin entre deux machines qui communiquent car elles pouvaient se faire en aveugle. Pour une telle attaque, il faut deviner un certain nombre de choses sur la communication, afin que les paquets de l'attaquant soient acceptés. Typiquement, il faut connaitre les adresses IP source et destination, ainsi que les ports source et destination et le key ID de NTP (RFC 5905, section 9.1). NTP a plusieurs modes de fonctionnement (RFC 5905, sections 2 et 3). Certains nécessitent d'accepter des paquets non sollicités et, dans ce cas, il faut bien écouter sur un port bien connu, en l'occurrence 123. Mais ce n'est pas nécessaire dans tous les cas et notre RFC demande donc qu'on n'utilise le port bien connu que si c'est nécessaire, au lieu de le faire systématiquement comme c'était le cas au début de NTP et comme cela se fait encore trop souvent (« Usage Analysis of the NIST Internet Time Service »). C'est une application à NTP d'un principe général sur l'Internet, documenté dans le RFC 6056 : n'utilisez pas de numéros de port statiques ou prévisibles. Si on suit ce conseil, un attaquant en aveugle aura une information de plus à deviner, ce qui gênera sa tâche. Le fait d'utiliser un port source fixe a valu à NTP un CVE, CVE-2019-11331.

La section 3 du RFC résume les considérations à prendre en compte. L'idée de choisir aléatoirement le port source pour faire face aux attaques en aveugle est présente dans bien d'autres RFC comme le RFC 5927 ou le RFC 4953. Elle est recommandée par le RFC 6056. Un inconvénient possible (mais mineur) est que la sélection du chemin en cas d'ECMP peut dépendre du port source (calcul d'un condensat sur le tuple à cinq élements {protocole, adresse IP source, adresse IP destination, port source, port destination}, avant d'utiliser ce condendat pour choisir le chemin) et donc cela peut affecter les temps de réponse, troublant ainsi NTP, qui compte sur une certaine stabilité du RTT. D'autre part, le port source aléatoire peut gêner certaines stratégies de filtrage par les pare-feux : on ne peut plus reconnaitre un client NTP à son port source. Par contre, un avantage du port source aléatoire est que certains routeurs NAT sont suffisamment bogués pour ne pas traduire le port source s'il fait partie des ports « système » (inférieurs à 1 024), empêchant ainsi les clients NTP situés derrière ces routeurs de fonctionner. Le port source aléatoire résout le problème.

Assez de considérations, passons à la norme. Le RFC 5905, section 9.1, est modifié pour remplacer la supposition qui était faite d'un port source fixe par la recommandation d'un port source aléatoire.

Cela ne pose pas de problème particulier de mise en œuvre. Par exemple, sur un système POSIX, ne pas faire de bind() sur la prise suffira à ce que les paquets associés soient émis avec un port source aléatoirement sélectionné par le système d'exploitation.

À propos de mise en œuvre, où en sont les logiciels actuels ? OpenNTPD n'a jamais utilisé le port source 123 et est donc déjà compatible avec la nouvelle règle. Même chose pour Chrony. Par contre, à ma connaissance, ntpd ne suit pas encore la nouvelle règle.


Téléchargez le RFC 9109


L'article seul

RFC 9107: BGP Optimal Route Reflection (BGP ORR)

Date de publication du RFC : Août 2021
Auteur(s) du RFC : R. Raszuk (NTT Network Innovations), B. Decraene (Orange), C. Cassar, E. Aman, K. Wang (Juniper Networks)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF idr
Première rédaction de cet article le 13 septembre 2021


Les grands AS ont tellement de routeurs BGP qu'ils ne peuvent pas connecter chaque routeur à tous les autres. On utilise alors souvent des réflecteurs de route, un petit nombre de machines parlant BGP auxquelles tout le monde se connecte, et qui redistribuent les routes externes apprises. Mais une machine BGP ne redistribue que les routes qu'elle utiliserait elle-même. Or, le réflecteur risque de faire un choix en fonction de sa position dans le réseau, qui n'est pas la même que celle du routeur « client ». Les routeurs risquent donc d'apprendre du réflecteur des routes sous-optimales (la route optimale étant typiquement celle qui amène à la sortie le plus vite possible, en application de la méthode de la patate chaude). Ce RFC définit une extension de BGP qui va permettre de sélectionner des routes spécifiques à un client, ou à un groupe de clients.

Un petit rappel : un réflecteur de routes (route reflector) fonctionne sur iBGP (Internal BGP), à l'intérieur d'un AS, alors que les serveurs de routes (route server) font de l'eBGP (External BGP), par exemple sur un point d'échange. Ces réflecteurs sont décrits dans le RFC 4456. Ils ne sont pas la seule méthode pour distribuer l'information sur les routes externes à l'intérieur d'un grand AS, mais c'est quand même la solution la plus fréquente.

Le RFC 4456 notait déjà que, vu les coûts attribués aux liens internes à l'AS, le réflecteur ne choisirait pas forcément les mêmes routes que si on avait utilisé un maillage complet. Le routage « de la patate chaude » (qui consiste à essayer de faire sortir le paquet de son réseau le plus vite possible, pour que ce soit un autre qui l'achemine) risque donc de ne pas aussi bien marcher : le point de sortie lorsqu'on utilise le réflecteur sera peut-être plus éloigné que si on avait le maillage complet, surtout si le réflecteur est situé en dehors du chemin habituel des paquets et n'a donc pas la même vision que les routeurs « normaux ». Or, c'est un cas fréquent. Le réflecteur choisira alors des routes qui sont optimales pour lui, mais qui ne le sont pas pour ces routeurs « normaux ».

La solution ? Permettre à l'administrateur réseaux de définir une localisation virtuelle pour le réflecteur, à partir de laquelle il fera ses calculs et choisira ses routes, au lieu d'utiliser sa localisation physique. Cette localisation virtuelle sera une adresse IP. Le réflecteur peut avoir plusieurs de ces localisations virtuelles, adaptées à des publics différents. Bref, le texte du RFC 4271 qui concerne la sélection de la meilleure route (section 9.1.2.2 du RFC 4271) est modifié pour remplacer « en fonction du saut suivant » par « en fonction de l'adresse IP configurée dans le réflecteur ».

Pour que cela marche, il faut que le réflecteur ait une vue complète du réseau, pour pouvoir calculer des coûts à partir de n'importe quel point du réseau. C'est possible avec les IGP à état des liens comme OSPF, ou bien avec BGP-LS (RFC 7752).

Et si le réflecteur a plusieurs clients ayant des desiderata différents, par exemple parce qu'ils sont situés à des endroits différents ? Dans ce cas, il doit faire tourner plusieurs processus de décision, chacun configuré avec une localisation vituelle différente.

Les principales marques de routeurs mettent déjà en œuvre ce RFC, comme on peut le voir sur la liste des implémentations. Du côté des logiciels qui ne sont pas forcément installés sur des routeurs, il semble que BIRD ne sache pas encore faire comme décrit dans ce RFC.


Téléchargez le RFC 9107


L'article seul

RFC 9103: DNS Zone Transfer over TLS

Date de publication du RFC : Août 2021
Auteur(s) du RFC : W. Toorop (NLnet Labs), S. Dickinson (Sinodun IT), S. Sahib (Brave Software), P. Aras, A. Mankin (Salesforce)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dprive
Première rédaction de cet article le 12 septembre 2021


Traditionnellement, le transfert d'une zone DNS depuis le serveur maitre vers ses esclaves se fait en clair. Si l'authentification et l'intégrité sont protégées, par exemple par TSIG, le transfert en clair ne fournit pas de confidentialité. Or on n'a pas forcément envie qu'un tiers puisse lire l'entièreté de la zone. Ce RFC normalise un transfert de zones sur TLS, XoT (zone transfer over TLS). Il en profite pour faire quelques ajustement dans l'utilisation de TCP pour les transferts de zone.

Le RFC fait quarante-deux pages mais le principe est très simple. Au lieu de faire le transfert de zones (aussi nommé AXFR, RFC 5936) directement sur TCP, on le fait sur du TLS, comme le fait DoT (RFC 7858). Le reste du RFC est consacré à des détails pratiques, mais le concept tient en une seule phrase.

Le DNS sur TLS est normalisé depuis cinq ans, mais il ne couvre officiellement que la communication entre la machine terminale et le résolveur. Bien que des essais aient été faits pour communiquer en TLS avec des serveurs faisant autorité, rien n'est encore normalisé. Mais, au fait, est-ce que les transferts de zone ont vraiment besoin de confidentialité ? Le RFC 9076 ne traite pas le problème, le renvoyant aux RFC 5936 (la norme du transfert de zones, qui parle de la possibilité de restreindre ce transfert à des machines autorisées) et au RFC 5155 (qui parle des risques d'énumération de tous les noms d'une zone). Certes, le DNS étant public, tout le monde peut interroger les serveurs faisant autorité, et connaitre ainsi les données associées à un nom de domaine, mais il faut pour cela connaitre les noms. Si les petites zones n'ont rien de secret (elles ne contiennent que l'apex et www), si certaines zones sont publiques (la racine, par exemple), pour les autres zones, leur responsable ne souhaite pas forcément qu'on ait accès à tous les noms. Certains peuvent être le nom d'une personne (le-pc-de-henri.zone.example), et donc être des données personnelles, à protéger (le RFC note bien sûr que c'est une mauvaise pratique, mais elle existe), certains noms peuvent renseigner sur les activités et les projets d'une entreprise. Bref, il peut être tout à fait raisonnable de ne pas vouloir transmettre la zone en clair.

À noter qu'une surveillance du réseau pendant un transfert de zones fait en clair n'est pas la seule façon de trouver tous les noms. Une autre technique est l'énumération, utilisant par exemple les enregistrement NSEC de DNSSEC. Les enregistrement NSEC3 du RFC 5155 ont été conçus pour limiter ce risque (mais pas le supprimer ; le projet NSEC5 va essayer de résoudre le problème mais c'est loin d'être garanti).

Comment sécurise-t-on les transferts de zone aujourd'hui ? Les TSIG du RFC 8945 protègent l'intégrité mais pas la confidentialité. Vous pouvez trouver des détails pratiques sur la sécurisation des transferts de zone, combinant TSIG et ACL, dans un document du NIST en anglais et un document de l'ANSSI en français. On peut aussi en théorie utiliser IPsec entre maitre et esclaves mais cela semble irréaliste. D'où l'idée de base de ce nouveau RFC : mettre le transfert de zones sur TLS. Après tout, on utilise déjà TLS pour sécuriser la communication entre le client final et le résolveur : le protocole DoT, normalisé dans le RFC 7858.

Notre RFC introduit quelques nouveaux acronymes rigolos :

  • XFR : couvre à la fois AXFR (RFC 5936) et IXFR (transferts incrémentaux, RFC 1995). Donc, XFR-over-TLS, c'est un transfert de zones, complet ou incrémental, sur TLS.
  • XoT : acronyme pour XFR-over-TLS.
  • AXoT : AXFR sur TLS.
  • IXoT : IXFR sur TLS.

Pour la terminologie liée à la vie privée, voir le RFC 6973.

La section 3 du RFC spécifie le modèle de menace : on veut protéger le transfert de zones contre l'espionnage par un tiers, mais on n'essaie pas de cacher l'existence de la zone, ou le fait que telle machine soit serveur faisant autorité pour la zone. En effet, ces informations peuvent être obtenues facilement en interrogeant le DNS ou, dans le cas d'un maitre caché, en regardant le trafic réseau, sans même en décrypter le contenu.

Les principes de conception de XoT ? Fournir de la confidentialité et de l'authentification grâce à TLS, mais aussi en profiter pour améliorer les performances. Un certain nombre de programmes DNS ne peuvent pas, par exemple, utiliser la même connexion TCP pour plusieurs transferts de zone (même si le RFC 5936 le recommande). Il est difficile de résoudre ce problème sans casser les programmes existants et pas encore mis à jour. Par contre, XoT étant nouveau, il peut spécifier dès le début certains comportements qui améliorent les performances, comme l'utilisation d'une seule connexion pour plusieurs transferts.

Petit rappel de comment fonctionne le transfert de zones (RFC 5936, si vous voulez tous les détails). D'abord, le fonctionnement le plus courant : le serveur maitre (ou primaire) envoie un NOTIFY (RFC 1996) à ses esclaves (ou secondaires). Ceux-ci envoient une requête de type SOA au maitre puis, si le numéro de série récupéré est supérieur au leur, ils lancent l'AXFR sur TCP. Il y a des variations possibles : si le maitre n'envoie pas de NOTIFY ou bien s'ils sont perdus, les esclaves testent quand même de temps en temps le SOA (paramètre Refresh du SOA). Autre variante possible : les esclaves peuvent utiliser IXFR (RFC 1995) au lieu de AXFR pour ne transférer que la partie de la zone qui a changé. Et ils peuvent avoir à se rabattre en AXFR si le maitre ne gérait pas IXFR. Et les messages IXFR peuvent être sur UDP ou sur TCP (en pratique, BIND, NSD et bien d'autres font toujours l'IXFR sur TCP). Bref, il y a plusieurs cas. Les messages NOTIFY et SOA ne sont pas considérés comme sensibles du point de vue de la confidentialité et XoT ne les protège pas.

Maintenant, avec XoT, comment ça se passera (section 6 du RFC) ? Une fois le transfert de zones décidé (via SOA, souvent précédé du NOTIFY), le client (qui est donc le serveur secondaire) doit établir une connexion TLS (1.3 minimum), en utilisant ALPN, avec le nom dot (on notera que c'est donc le même ALPN pour XoT et pour DoT, l'annexe A du RFC explique ce choix). Le port est par défaut le classique 853 de DoT. Le client authentifie le serveur via les techniques du RFC 8310. Le serveur vérifie le client, soit avec des mécanismes TLS (plus sûrs mais plus compliqués à mettre en œuvre), soit avec les classiques ACL. Le client TLS (le serveur DNS esclave) fait ensuite de l'IXFR ou du AXFR classique sur ce canal TLS. Le serveur doit être capable d'utiliser les codes d'erreur étendus du RFC 8914.

Voilà, c'est tout. Maintenant, quelques détails pratiques. D'abord, rappelez-vous qu'il n'existe pas à l'heure actuelle de norme pour du DoT entre résolveur et serveur faisant autorité. Mais il y a des expériences en cours. Ici, par exemple, je fais du DoT avec un serveur faisant autorité pour facebook.com :

% kdig +tls @a.ns.facebook.com.  SOA facebook.com   
;; TLS session (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
...
;; ANSWER SECTION:
facebook.com.       	3600	IN	SOA	a.ns.facebook.com. dns.facebook.com. 1631273358 14400 1800 604800 300

;; Received 86 B
;; Time 2021-09-10 13:35:44 CEST
;; From 2a03:2880:f0fc:c:face:b00c:0:35@853(TCP) in 199.0 ms

Mais on pourrait imaginer des serveurs faisant autorité qui ne fournissent pas ce service, pas encore normalisé, mais qui veulent faire du XoT. Est-ce possible de réserver TLS aux transferts de zone, mais sans l'utiliser pour les requêtes « normales » ? Oui, et dans ce cas le serveur doit répondre REFUSED à ces requêtes normales, avec le code d'erreur étendu 21 (Not supported). Ceci dit, il est difficile de dire comment réagiront les clients ; ils risquent d'ignorer le code d'erreur étendu et de recommencer bêtement (ou au contraire d'arrêter complètement d'utiliser le serveur).

Le but de XoT est de protéger le contenu de la zone contre les regards indiscrets. Mais comme vous le savez, TLS ne dissimule pas la taille des données qui passent entre ses mains et l'observation de cette taille peut donner des informations à un observateur, par exemple la taille des mises à jour en IXFR indique l'activité d'une zone. Le RFC suggère donc de remplir les données. Cela peut nécessiter d'envoyer des réponses vides, ce qui était interdit par les précédents RFC mais est maintenant autorisé.

Et les différentes formes de parallélisme des requêtes que permet le DNS sur TCP (et donc DoT) ? Elles sont décrites dans le RFC 7766. Si elles sont nécessaires pour exploiter le DNS de manière satisfaisante, elles ne sont pas forcément utiles pour XoT et notre RFC explique qu'on n'est pas forcé, par exemple, de permettre le pipelining (envoi d'une nouvelle requête quand la réponse à la précédente n'est pas encore arrivée) quand on fait du XoT. Par contre, comme avec tous les cas où on utilise du DNS sur TCP, il est recommandé de garder les connexions ouvertes un certain temps, par exemple en suivant le RFC 7828.

J'ai parlé plus haut de l'authentification dans une session XoT. La section 9 du RFC revient en détail sur cette question. Quels sont les mécanismes existants pour authentifier un transfert de zones ? Ils diffèrent par les services qu'ils rendent :

  • Authentification de la source des données DNS.
  • Authentification du correspondant (qui n'est pas forcément la source des données).
  • Confidentialité.

Les mécanismes possibles sont :

  • TSIG (RFC 8945) ; utiisant des clés partagées (ce qui n'est pas pratique), il permet d'authentifier la source des données.
  • SIG(0) (RFC 2931) ; utilisant de la cryptographie asymétrique, il permet d'authentifier la source des données. Ceci dit, il n'est quasiment jamais mis en œuvre dans les programmes DNS.
  • TLS en mode « opportuniste » (sans authentification) ; il ne garantit rien, sauf peut-être contre un observateur passif.
  • TLS en mode strict (obligation d'authentification du serveur par le client, RFC 8310) ; cela permet l'authentification du correspondant, et la confidentialité (mais ne garantit pas que le correspondant est la vraie source des données).
  • TLS mutuel ; le client s'authentifie également.
  • ACL fondées sur l'adresse IP ; très répandu, ce mécanisme permet au serveur d'« authentifier » le client. Une faiblesse pour le cas de XoT : le serveur doit accepter l'établissement de la session TLS avant de savoir s'il s'agit de XoT ou de DNS ordinaire sur TLS.
  • ZONEMD (RFC 8976) ; ce n'est pas vraiment une technique d'authentification mais elle peut être utile, en combinaison avec XoT.

Quelles sont les mises en œuvres actuelles de XoT ? Une liste existe. Actuellement, il n'y a guère que NSD qui permet le XoT mais le travail est en cours pour d'autres. Voyons comment faire du XoT avec NSD. On télécharge la dernière version (XoT est apparu en 4.3.7), on la compile (pas besoin d'options particulières) et on la configure, par exemple ainsi :

server:
       port: 7053
       ...
       tls-service-key: "server.key"
       tls-service-pem: "server.pem"
       # No TLS service if the port is not explicit in an interface definition
       ip-address: 127.0.0.1@7153
       tls-port: 7153

zone:
        name: "fx"
        zonefile: "fx"
	# NSD 4.3.7 (september 2021) : not yet a way to restrict XoT
        provide-xfr: 127.0.0.1 NOKEY 
  

Ainsi configuré, NSD va écouter sur le port 7153 en TLS. Notons qu'il n'y a pas de moyen de configurer finement : il accepte forcément XoT et les requêtes « normales ». De même, on ne peut pas obliger un client DNS à n'utiliser que XoT. Testons avec kdig, un client DNS qui accepte TLS, d'abord une requête normale :

    
% kdig +tls @localhost -p 7153 SOA fx 
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 11413
...
;; ANSWER SECTION:
fx.                 	600	IN	SOA	ns1.fx. root.fx. 2021091201 604800 86400 2419200 86400
...
;; Time 2021-09-12 11:06:39 CEST
;; From 127.0.0.1@7153(TCP) in 0.2 ms

  

Parfait, tout marche. Et le transfert de zones ?


% kdig +tls @localhost -p 7153 AXFR fx
;; AXFR for fx.
fx.                 	600	IN	SOA	ns1.fx. root.fx. 2021091201 604800 86400 2419200 86400
...
;; Received 262 B (1 messages, 9 records)
;; Time 2021-09-12 11:07:25 CEST
;; From 127.0.0.1@7153(TCP) in 2.3 ms

  

Excellent, nous faisons du XoT. Wireshark nous le confirme :

% tshark -d tcp.port==7153,tls -i lo port 7153
...
4 0.001200185    127.0.0.1 → 127.0.0.1    TLSv1 439 Client Hello
...
6 0.006305031    127.0.0.1 → 127.0.0.1    TLSv1.3 1372 Server Hello, Change Cipher Spec, Application Data, Application Data, Application Data, Application Data
...
10 0.007385823    127.0.0.1 → 127.0.0.1    TLSv1.3 140 Application Data
  

Dans ce cas, on utilisait NSD comme serveur primaire, recevant les clients XoT. Il peut aussi fonctionner comme serveur secondaire et il est alors client XoT. Je n'ai pas testé mais John Shaft l'a fait et en gros la configuration ressemble à :

tls-auth:
   name: un-nom-pour-identifier-ce-bloc
   auth-domain-name: nom-du-serveur-principal
zone:
   ...
   request-xfr: AXFR 2001:db8::1 NOKEY un-nom-pour-identifier-ce-bloc
  

Téléchargez le RFC 9103


L'article seul

RFC 9108: YANG Types for DNS Classes and Resource Record Types

Date de publication du RFC : Septembre 2021
Auteur(s) du RFC : L. Lhotka (CZ.NIC), P. Spacek (ISC)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 9 septembre 2021


YANG est le langage standard à l'IETF pour décrire des modèles de données, afin de, par exemple, gérer automatiquement des ressources. Ce RFC décrit le module YANG iana-dns-class-rr-type, qui rassemble les définitions des types d'enregistrements DNS.

YANG est normalisé dans le RFC 7950, et d'innombrables RFC décrivent des modules YANG pour de nombreux protocoles. YANG est utilisé par des protocoles de gestion à distance de ressources, comme RESTCONF (RFC 8040) ou NETCONF (RFC 6241). Mais ce RFC est le premier qui va utiliser YANG pour le DNS. L'un des objectifs (à long terme pour l'instant) est d'utiliser RESTCONF ou un équivalent pour gérer des serveurs DNS, résolveurs ou serveurs faisant autorité. (C'est un très vieux projet que cette gestion automatisée et normalisée des serveurs DNS.) Un mécanisme standard de gestion des serveurs nécessite un modèle de données commun, et c'est là que YANG est utile. Notre RFC est encore loin d'un modèle complet, il ne définit que le socle, le type des données que le DNS manipule. C'est la version YANG de deux registres IANA, celui des types d'enregistrements DNS et celui des classes (même si ce dernier concept est bien abandonné aujourd'hui).

Le registre IANA pour le DNS contient treize sous-registres. Le RFC n'en passe que deux en YANG, les classes et les types d'enregistrement. Les autres devront attendre un autre RFC. Les types d'enregistrement sont modélisés ainsi :

typedef rr-type-name {
    type enumeration {
      enum A {
        value 1;
        description
          "a host address";
        reference
          "RFC 1035";
      }
      enum NS {
        value 2;
        description
          "an authoritative name server";
...
  

Et les classes (mais, rappelez-vous, seule la classe IN compte aujourd'hui) :

typedef dns-class-name {
    type enumeration {
      enum IN {
        value 1;
        description
          "Internet (IN)";
        reference
          "RFC 1035";
      }
      enum CH {
        value 3;
        description
          "Chaos (CH)";
        reference
          "D. Moon, 'Chaosnet', A.I. Memo 628, Massachusetts Institute of
Technology Artificial Intelligence Laboratory, June 1981.";
}
...
  

Le module YANG complet se retrouve dans le registre IANA (créé par le RFC 6020).

Le module YANG devra suivre l'actuel registre IANA, qui utilise un autre format. Pour faciliter la synchronisation, le RFC contient une feuille de style XSLT pour convertir l'actuel format, qui est la référence, vers le format YANG. La feuille de style est dans l'annexe A du RFC mais vous avez une copie ici. Voici comment produire et vérifier le module YANG :

% wget https://www.iana.org/assignments/dns-parameters/dns-parameters.xml

% xsltproc iana-dns-class-rr-type.xsl dns-parameters.xml > iana-dns-class-rr-type.yang

% pyang iana-dns-class-rr-type.yang
  

Le moteur XSLT xsltproc fait partie de la libxslt. Le vérificateur YANG Pyang est distribué via GitHub mais on peut aussi l'installer avec pip (pip install pyang).


Téléchargez le RFC 9108


L'article seul

RFC 9106: Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications

Date de publication du RFC : Septembre 2021
Auteur(s) du RFC : A. Biryukov, D. Dinu (University of Luxembourg), D. Khovratovich (ABDK Consulting), S. Josefsson (SJD AB)
Pour information
Réalisé dans le cadre du groupe de recherche IRTF cfrg
Première rédaction de cet article le 8 septembre 2021


En général, en informatique, on essaie de diminuer la consommation de mémoire et de processeur des programmes, afin de les rendre plus efficaces. Mais il y a aussi des cas où on va tenter de réduire délibérement l'efficacité d'un programme. C'est le cas des fonctions de condensation qui sont utilisées en sécurité : on ne veut pas faciliter la tâche de l'attaquant. Ainsi, Argon2, spécifié dans ce RFC est volontairement très consommatrice de mémoire et d'accès à cette mémoire. Elle peut être utilisée pour condenser des mots de passe, ou pour des sytèmes à preuve de travail.

L'article original décrivant Argon2 est « Argon2: the memory-hard function for password hashing and other applications » et vous pouvez également lire « Argon2: New Generation of Memory-Hard Functions for Password Hashing and Other Applications ». Notre RFC reprend la description officielle, mais en s'orientant davantage vers les programmeurs et programmeuses qui devront mettre en œuvre cette fonction. Argon2 est conçu pour être memory-hard, c'est-à-dire faire souvent appel à la mémoire de la machine. Cela permet notamment aux ordinateurs classiques de tenir tête aux systèmes à base d'ASIC. (Par exemple, nombreuses sont les chaînes de blocs utilisant des preuves de travail. La fonction utilisée par Bitcoin, SHA-256, conçue pour être simple et rapide, n'est pas memory-hard et le résultat est qu'il y a belle lurette qu'un ordinateur, même rapide, n'a plus aucune chance dans le minage de Bitcoin. Seules les machines spécialisées peuvent rester en course, ce qui contribue à centraliser le minage dans peu de fermes de minage.) Argon2 est donc dur pour la mémoire, comme décrit dans l'article « High Parallel Complexity Graphs and Memory-Hard Functions ». À noter qu'Argon2 est très spécifique à l'architecture x86.

Argon2 se décline en trois variantes, Argon2id (celle qui est recommandée par le RFC), Argon2d et Argon2i. Argon2d a des accès mémoire qui dépendent des données, ce qui fait qu'il ne doit pas être employé si un attaquant peut examiner ces accès mémoire (attaque par canal auxiliaire). Il convient donc pour du minage de cryptomonnaie mais pas pour une carte à puce, que l'attaquant potentiel peut observer en fonctionnement. Argon2i n'a pas ce défaut mais est plus lent, ce qui ne gêne pas pour la condensation de mots de passe mais serait un problème pour le minage. Argon2id, la variante recommandée, combine les deux et est donc à la fois rapide et résistante aux attaques par canal auxiliaire. (Cf. « Tradeoff Cryptanalysis of Memory-Hard Functions », pour les compromis à faire en concevant ces fonctions dures pour la mémoire.) Si vous hésitez, prenez donc Argon2id. La section 4 du RFC décrit plus en détail les paramètres des variantes, et les choix recommandés.

Argon repose sur une fonction de condensation existante (qui n'est pas forcément dure pour la mémoire) et le RFC suggère Blake (RFC 7693).

La section 3 du RFC décrit l'algorithme mais je n'essaierai pas de vous le résumer, voyez le RFC.

La section 5 contient des vecteurs de test si vous voulez programmer Argon2 et vérifier les résultats de votre programme.

La section 7 du RFC revient en détail sur certaines questions de sécurité, notamment l'analyse de la résistance d'Argon2, par exemple aux attaques par force brute.


Téléchargez le RFC 9106


L'article seul

RFC 9096: Requirements for Customer Edge Routers to Mitigate IPv6 Renumbering Events

Date de publication du RFC : Août 2021
Auteur(s) du RFC : F. Gont (SI6 Networks), J. Zorz (6connect), R. Patterson (Sky UK), B. Volz (Cisco)
Réalisé dans le cadre du groupe de travail IETF v6ops
Première rédaction de cet article le 7 septembre 2021


Quand un FAI modifie la configuration de son réseau IPv6, les routeurs chez les clients finaux, les CPE, ne retransmettent pas toujours rapidement ce changement, ce qui mène parfois à des problèmes de connectivité. Ce RFC décrit ce que doivent faire ces CPE pour minimiser les conséquence négatives d'une rénumérotation d'un réseau.

Le problème est documenté dans le RFC 8978 : par exemple, lorsqu'un routeur chez M. Toutlemonde (une « box ») redémarre et « oublie » sa configuration réseau précédente, si elle a changé chez le FAI entretemps, les machines du réseau local de M. Toutlemonde risquent de continuer à utiliser pendant un certain une ancienne configuration, désormais invalide. Comment éviter cela ?

Notre RFC se penche surtout sur le cas où le routeur de M. Toutlemonde a appris son préfixe IPv6 depuis le FAI via la délégation de préfixe DHCP du RFC 8415, et qu'il retransmet l'information sur ce préfixe dans le réseau local avec le SLAAC du RFC 4862 (via les RA, Router Advertisements, RFC 4861) ou bien DHCP. Les machines terminales sur le réseau local peuvent aussi agir (ce sera dans un futur RFC) mais l'actuel RFC ne concerne que les routeurs. Il consiste en une série d'exigences auxquelles doivent se prêter les routeurs, exigences qui s'ajoutent à celles déjà présentes dans le RFC 7084 ou bien qui modifient des exigences de ce RFC 7084.

Beaucoup de ces exigences nécessitent un mécanisme de stockage d'informations sur le routeur, stockage qui doit survivre aux redémarrages, ce qui ne sera pas évident pour tous les routeurs. Ainsi, le RFC demande que, du côté WAN, le routeur utilise toujours le même identificateur (IAID, Identity Association IDentifier, RFC 8415, section 4.2) en DHCP (pour essayer de garder le même préfixe). Certains routeurs choisissent apparemment l'IAID au hasard à chaque démarrage, ce qui leur obtient un nouveau préfixe. Il vaut mieux le garder, mais cela nécessite qu'il puisse être stocké et mémorisé même en cas de redémarrage. Comme tous les routeurs n'ont pas de mécanisme de stockage stable, les exigences du RFC sont exprimées (dans le langage du RFC 2119) par un SHOULD et pas un MUST.

Autre exigence, qui relève du bon sens, le routeur ne doit pas, lorsqu'il utilise un préfixe du côté LAN (le réseau local), utiliser une durée de vie plus longue (options Preferred Lifetime et Valid Lifetime du message d'information sur le préfixe envoyé par le routeur, RFC 4861, section 4.6.2) que celle qu'il a lui-même appris en DHCP côté WAN. On ne doit pas promettre ce qu'on ne peut pas tenir, la durée du bail DHCP s'impose au routeur et aux annonces qu'il fait sur le réseau local.

Enfin, le routeur ne doit pas, au redémarrage, envoyer systématiquement un abandon du préfixe appris en DHCP (message DHCP RELEASE). Certains routeurs font apparemment cela, ce qui risque de déclencher une renumérotation brutale (RFC 8978).

Lorsque le préfixe change, le routeur devrait aussi signaler cela sur le réseau local. Là encore, cela impose une mémoire, un stockage stable. Il doit se souvenir de ce qu'il a reçu, et annoncé, précédemment, pour pouvoir annoncer sur le réseau local que ces anciens préfixes ne doivent plus être utilisés (cela se fait en annonçant ces préfixes, mais avec une durée de vie nulle). Dans un monde idéal, le routeur sera prévenu des changements de préfixe parce que le FAI réduira la durée de vie de ses baux DHCP, permettant un remplacement ordonné d'un préfixe par un autre. Dans la réalité, on a parfois des renumérotations brutales, sans préavis (RFC 8978). Le routeur doit donc également gérer ces cas.


Téléchargez le RFC 9096


L'article seul

Articles des différentes années : 2021  2020  2019  2018  2017  2016  2015  Précédentes années

Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.

Un article de ce blog au hasard.