Petit résumé des causeries que j'ai retenues de la JCSA 2015.

Enjeux et complexité de la mesure de la QoS Internet : présentation de l’Observatoire ARCEP (réseaux fixes)

L'ARCEP, le régulateur français des télécoms, réalise des observatoires afin d’être en mesure de justifier ses décisions : mesure de la couverture des opérateurs de téléphonie mobile, mesure de la qualité des accès à Internet fixe, etc.

Rien est facile :

• Faut-il mesurer la qualité de service (aspect technique) ou la qualité de l'expérience utilisateur (ressenti personnel) ? L'ARCEP utilise la QoS pour effectuer des contrôles (de couverture, par exemple) et la QoE pour l'accès fixe à Internet et des mesures intermédiaires ;
  
  
• Faut-il mesurer le cœur du réseau d'un FAI (qui est la seule partie placée sous son autorité) ou aussi ses interconnexions avec le reste d'Internet (qui influent lourdement sur le ressenti utilisateur) ? Faut-il prendre en compte l'installation d'un utilisateur comme le Wi-Fi ou un système d'exploitation, Windows, qui acquitte moins souvent les paquets IP quand le CPU est lourdement sollicité (ce qui fait que la sonde de mesure émet plus de paquets afin d'augmenter le débit, conformément à la norme TCP, débit que la ligne mesurée ne peut encaisser, ce qui induit de la perte de paquets artificielle) ?
  
  
• Il ne faut pas seulement des mesures, mais également tout un écosystème humain afin de maintenir les mesures dans le temps, de prendre des décisions, d'arbitrer une difficulté technique quand elle survient, etc.
  
  
• Cas concret pour illustrer que rien est simple : le prestataire retenu par l'ARCEP pour effectuer les mesures, IP-Label, utilisait des salves ICMP pour mesurer la perte de paquets. Oui, mais ICMP n'est pas représentatif de l'usage habituel car c'est un protocole de signalisation. De plus, les sondes émettaient 10 paquets par salves, ce qui est un très faible échantillon statistique. IP-Label a produit une nouvelle mesure qui déduit 240 indicateurs liés à la perte de paquets sur un téléchargement HTTP en mesurant les retransmissions TCP. Oui, mais que faire face à un OS qui fait de l'acquittement non régulier (voir 2e point ci-dessus) ? Il faut que l'outil de mesure soit peu gourmand en CPU. Oui, mais une retransmission TCP peut survenir après une perte de paquet ou un réordonnancement des paquets, comment savoir dans quel cas se situe une mesure ? Méthodologie non précisée par l'orateur. Quand l'outil a été utilisé en pratique, on a constaté une perte de paquets plus élevée sur des mires proches que sur des mires lointaines… Après analyse, il s'avère que c'est la file d'attente dans le DSLAM (buffer) qui était remplie (100 ms de décalage dans le pcap, car ce buffer était en moyenne capable de stocker 100ms)… Et, évidemment, cette taille est différente en fonction des équipementiers donc des FAI, ce qui fausse les mesures… Quid des proxy HTTP transparents ? Bref, c'est sans fin.

Détection d’usurpations BGP en temps réel

Depuis plusieurs années, l'Agence Nationale de la Sécurité des Systèmes d'Information étudie les usurpations BGP visant les opérateurs Internet français.

• Usurpations : erreurs commises par des humains travaillant chez les opérateurs ou appât du gain : détournement de Bitcoin, spam, etc. ;
  
  
• Méthodologie générale : récupérer les mouvements de l'Internet perçus depuis les collecteurs RIS du RIPE (mesure passive) et utiliser les sondes RIPE Atlas pour caractériser les différents conflits détectés (mesure active). Il faut être au bon endroit sur Internet pour caractériser un conflit, la répartition des sondes Atlas permet cela ;
  
  
• Les journaux des mouvements BGP enregistrés par le RIPE représentent 550 Go par an ;
  
  
• Machinerie interne pour analyser les mouvements BGP : parser maison qui envoie dans une moulinette Python parallélisée (orchestrateur Luigi et stockage "big-data-like" disco) qui simule un routeur en reconstruisant une table de routage et qui y applique des algos de détection des conflits. Une dernière étape de consolidation se fait en faisant correspondre les conflits potentiels avec un import quotidien des bases de données des IRR (whois) dans une base de données PostgreSQL (avec des modules maison permettant de s'adapter au format des whois) ;
  
  
• Sur un an, pour environ 1500 opérateurs français : 70 millions de messages BGP conflictuels qui, agrégés, donnent 5136 conflits dont 1096 sont des usurpations dont 300 sont anormaux et nécessitent un examen manuel (1 journée de taff de quelqu'un qui connaît très bien la topologie de l'Internet français ;

Utilisation pratique des sondes RIPE Atlas pour des mesures / diagnostics réseau

Présentation et tutoriel du système RIPE Atlas, qui est une plateforme de métrologie (mesures actives) d'Internet accessible à tout le monde.

• Il existe plusieurs systèmes de mesure :

  • Samknows (commission européenne) : petit ordinateur TP-Link qui réalise des mesures actives afin de déterminer la qualité de l'expérience utilisateur au sein de l'UE (téléchargement de fichiers, par exemple) ;
    
    
  • Logiciels d'analyse de la qualité d'un accès à Internet : Grenouille, Netalyzr, etc. ;
    
    
  • NLNOG Ring : machines virtuelles GNU/Linux Ubuntu avec des outils préinstallés afin de diagnostiquer une panne ;
    
    
  • Orientés recherche : Planet Lab, CAIDA (solution basée sur le Raspberry Pi) ;
    
    
  • Systèmes de mesures de sociétés commerciales privées : Dyn (ex-Renesys) ;
    
    
  • Tous ces systèmes sont différents : certains permettent des mesures personnelles (comme Atlas), certains nécessitent d'être un volontaire sélectionné (Samknows et CAIDA, qui refusent de distribuer une sonde à un résident d'un pays très bien couvert), certains sont communautaires et public (Atlas) alors que d'autres sont fermés (Dyn) ou se limitent à la publication d’un rapport annuel (Samknows), etc. ;

• Atlas : ensemble de sondes matérielles (petits ordinateurs TP-Link) qui réalise des mesures actives demandées par les autres utilisateurs, donc une sonde n'écoute pas le trafic Internet du lieu où elle est installée. Ces sondes sont fournies et gérées de manière centralisée (contrôleur qui distribue le travail à effectuer et permet de récupérer le résultat d'une mesure) par le RIPE, association néerlandaise qui distribue les ressources rares d’Internet (adresses IP) en Europe. Tout le monde peut héberger une sonde (à la maison, au boulot, au hackerspace du coin, etc.), il suffit de se porter volontaire. Le but est justement d'avoir des sondes dans un maximum de réseaux et dans un maximum de lieux géographiques ;

• Tout est question de choix.

  • Une solution matérielle a été retenue, car elle permet une stabilité dans le temps (on ne vire pas une sonde matérielle aussi fréquemment qu'on formate son winwin), et un contrôle complet de la chaîne, qui permet des mesures reproductibles (qui ne dépendent pas de la consommation CPU des applications lancées parallèlement à une sonde logicielle) ;
    
    
  • Une solution centralisée a été retenue car ça évite les attaques Sybil difficiles à résoudre, ça résout très bien le problème de NAT, et ça permet l'autoconfiguration sans intervention humaine ;
    
    
  • Les mesures sont publiques par défaut et cette publicité est encouragée (il n'est plus possible de créer une mesure privée depuis l'interface web) ;

• Atlas en chiffres : environ 18 000 sondes dans la nature en septembre 2018 dont seulement 8 500 environ sont connectées (les autres sont tombées en panne, ont été débranchées, ont été oublié lors d'un déménagement, etc., le taux de perte est plus important en Afrique). Environ 3 700 sondes sont marquées comme étant capable de communiquer en IPv6 (ça ne dit pas qu'IPv6 fonctionne pour de vrai !) ;
  
  

• Pour demander au réseau de sondes d'effectuer des mesures, il faut posséder des crédits. Ceux-ci s'obtiennent en hébergeant une sonde (son uptime et les mesures qu'elle réalise pour le compte d'autrui rapportent des crédits journaliers), en s'en faisant transférer par un autre utilisateur d’Atlas, en étant une organisation membre du RIPE (qu'on nomme un LIR) ou un de ses sponsors, ou en hébergeant une ancre Atlas (voir ci-dessous). Ce mécanisme limite fortement les abus ;
  
  

• En plus des crédits, Atlas implémente quelques mesures de protections : les mesures sont plutôt bas niveau (elles ne sont pas adaptées à une mesure de la qualité de l'expérience utilisateur) comme ping, traceroute, DNS, NTP, TLS, et HTTP [ avec pour seules cibles possibles les ancres] ), il peut y avoir qu'une seule cible par mesure, une mesure peut mobiliser 500 sondes tout au plus, il y a un nombre limité de mesures simultanées vers une même cible (c'est pour ça qu'une mesure vers 8.8.8.8 échoue souvent : car cette cible est très demandée) ;
  
  

• Atlas souffre d'un biais de représentativité : Atlas est un projet initié en Europe, donc on trouve beaucoup plus de sondes localisées en Europe, l'hébergement d'une sonde est volontaire, donc on trouve des Atlas chez des gens plutôt technophiles, plutôt bien informés, etc., ce qui fausse la représentativité (IPv6 et DNSSEC fonctionnent mieux qu'ailleurs, par exemple) ;
  
  

• Créer une mesure. Via l'interface web ou une API REST+JSON (l'interface web donne le bout de JSON correspondant à une mesure crée en clicodrome). Une mesure peut-être unique ou périodique. On peut sélectionner les sondes que l'on va utiliser (par pays, par réseau, par zone géographique, avec telle étiquettes, etc.). Cette granularité dans la sélection permet d'identifier des choses différentes : un problème de routage se met en évidence en sélectionnant des sondes à l’intérieur d’un même réseau alors qu'un problème de censure se met en évidence en travaillant à l'échelle d'un pays. Attention : le choix des sondes par le contrôleur n'est pas aléatoire, il repose sur un ensemble de critères internes ! Donc il n’est pas rare de retrouver les mêmes sondes entre deux mesures ;
  
  

• Analyser les résultats. Ils se récupèrent au format JSON avec une requête HTTP. Soit on peut demander régulièrement le fichier de résultat jusqu'à ce qu'il soit produit (polling) ou on peut utiliser Atlas Resultat Stream, un mécanisme synchrone pour les attendre. Tout un tas de programmes et de bibliothèques existent pour analyser les résultats : Sagan (qui est même packagé dans Debian), Magellan, ripe-atlas-community-contrib, etc. ;
  
  

• Conseils pour les développeurs : ne pas supposer que tous les attributs seront toujours présents (c'est le principe de JSON, qui est un format beaucoup moins strict que XML sur le caractère obligatoire de certains attributs), ne pas supposer que tout se passera bien (le contrôleur n'attribuera pas forcément le nombre de sondes demandé, des sondes ne retourneront pas forcément un résultat, etc.), toutes les données ne sont pas forcément retournées sous forme JSON (exemple : tous les attributs d'une réponse DNS ne sont pas représentés en JSON, si on les veut, il faut ouvrir le blob binaire contenues dans la réponse avec une librairie DNS) ;
  
  

• Conseils pour les utilisateurs : utiliser régulièrement Atlas et pas uniquement en cas de problème. Cela permet de se rendre compte de l'état nominal. Exemples : 10 % de perte sur un ping IPv6 était une situation normale en 2015. Il y a parfois des limitateurs de trafic qui compromettent la fiabilité d'une mesure (non, Atlas ne permet pas de demander un délai entre une même mesure réalisées par des sondes différentes) ;
  
  

• Ancres : ordinateur hébergé en datacenter par des organismes à but professionnels ou communautaire (l’achat de cet ordinateur est à la charge de l’organisme). Comme les sondes, elles permettent de réaliser des mesures, mais elles servent également d'amer, c'est-à-dire de cible "sans prise de tête" pour des mesures (pas besoin de réfléchir si une mesure est dangereuse, si elle peut surcharger une cible, etc. car les ancres sont là pour cela) ;
  
  

• Atlas peut être utilisé pour superviser un réseau ou un service. Il suffit de créer une mesure périodique et de l'interroger via l'API status_check d'Atlas avec le check_http standard de ton outil de supervision préféré. Cette API positionne un attribut JSON « "global_alert":false » s'il n'y a pas d'erreur, true sinon. Il suffit donc de demander à check_http de rechercher cette chaîne ;
  
  

• Par défaut, contrairement à GNU/Linux, les traceroute sont réalisés avec des paquets ICMP. Une option permet d'utiliser UDP ;
  
  

• Le RIPE utilise les sondes pour superviser sa propre infrastructure (exemple : l'instance K de la racine du DNS) et d'autres services. Exemple : DNSMon qui supervise les zones DNS cruciales (com., net., fr., etc.). Comme il s'agit d'un outil externe et que les mesures sont publiques (donc vérifiables), cela permet de produire des indicateurs et des rapports fiables. L’Afnic utilise ce service, entre autres, pour produire les indicateurs demandés par le gouvernement français dans la convention qui les lie ;
  
  

• Le type de mesure HTTP a été implémenté très récemment, car il pose des problèmes : quid des DoS (effet Slashdot) ? Quid des aspects politiques (HTTP est plus surveillé que ICMP ou DNS par les régimes autoritaires) ? Seule une ancre peut être utilisée comme cible d'une mesure HTTP ;
  
  

• Les sondes sont étiquetées. Deux types de tags : système et manuel. Les tags système, préfixés par « system- » sont fiables (exemple : avec « system-ipv6-works », on est sûr de sélectionner une sonde qui dispose d'un accès IPv6 fonctionnel). Ces étiquettes peuvent être utilisés pour choisir ou exclure des sondes dans une mesure.

Suivant l’exemple des épouses athéniennes imaginé par Aristophane dans « Lysistrata », des milliers d'Ougandaises ont fait savoir qu'elles entamaient « une grève du sexe » pour « punir les maris paresseux, dépensiers et irresponsables ». Le magazine « Amina » (septembre) précise que « ce qui était à l'origine une blague s'est répandu comme une traînée de poudre ». Mais la suite du mouvement laisse perplexe : certaines épouses « exigent désormais d'être payées pour un rapport sexuel si le mari ne change pas de comportement ».

Avec des réductions s'il prend une carte de fidélité ?

Dans le Canard enchaîné du 5 septembre 2018.

Gérard Collomb n’a pas les idées très claires sur les radicalisés. En août 2017, le premier flic de France affirmait qu’« à peu près un tiers [d’entre eux] présent[ai]ent des troubles psychologiques ». Interrogé par « Le Canard », le cabinet du ministre fournit aujourd’hui de tout autres chiffres. Qui lui ont sans doute été soufflée par la Préfecture de police de Paris. Dans une note confidentielle du 25 juillet consultée par « Le Canard », la Direction du renseignement de la Préfecture recense « 275 personnes inscrites au fichier des personnes radicalisées et affectées de troubles psychiatriques dans l’ensemble de l’agglomération parisienne » — soit 11 % des 2 475 inscrits à ce fichier francilien. On est loin du « tiers » de Collomb…

Dans le détail, les poulets en blouse blanche vont jusqu’à classer leurs « fous » en différentes catégories : « rouge plus, orange ou vert ». Hautement scientifique et propre à ravir les psychiatres, déjà enchantés à l’idée que la police fourre son nez dans le secret médical. Ce dont elle ne se prive pas. En mai, par exemple, la Direction générale de la sécurité intérieure somme un patron d’lîô» pital de la rancarder sur l’un de ses patients, à son insu. Tout y passe : téléphone portable, liste des personnes lui ayant rendu visite, contenu de ses conversations et comportement prosélyte vis-à-vis des autres malades…

Le 24 mai, Collomb a obtenu de Buzyn un décret ordonnant à toutes les agences régionales de santé de communiquer aux préfets l’identité des internés d’office, soit 60 OO0 personnes par an, répertoriées dans un fichier baptisé « Hopsyweb ». Selon le syndicat des psychiatres hospitaliers, pourtant, qui s’apprête à contester le décret devant le Conseil d’Etat, « il n’existe aucune association démontrée entre pathologie mentale et risque terroriste ».

Sans compter que surveiller de près 60 000 personnes va coûter un pognon… de dingue.

Dans le Canard enchaîné du 5 septembre 2018.