Petit résumé des causeries que j'ai retenues des JRES 2015.

Centralisé, décentralisé, pair à pair, quels mots pour l'architecture des systèmes répartis ?

Une causerie sur le vocabulaire permettant de décrire des systèmes répartis à l'échelle de l'Internet, c'est-à-dire des systèmes multi-entités. L'objectif est d'éviter les débats épidermiques comme « IRC est acentré » ou « dns est centralisé » ou « dns est décentralisé car il y a plusieurs serveurs qui servent la racine ».

• Proposition d'une nouvelle classification axée sur une seule question : qui décide de modifier l'état du système, qui empêche ou permet cette autorisation ?

  • Classe 1 : une seule entité décide via le code ou des règles explicites. Exemple : les GAFA. Ces systèmes créent des conflits de gouvernance (qui autorise l'usage de tel identificateur ?), mais ils simplifient beaucoup de choses par leur similitude avec des systèmes répartis au sein d'une même organisation (déployer tel protocole ou telle règle, attribuer un identificateur, etc.) ;
    
    
  • Classe 2 : tout le monde gère un bout du système, mais il existe des entités privilégiées dans le système. Exemple : DNS. Ces systèmes-là sont des systèmes répartis efficaces, mais ils posent encore des conflits de gouvernances (exemple : le choix des nouveaux TLD) ;
    
    
  • Classe 3 : tout le monde gère un bout du système, tout le monde est égal, mais il faut un accord des autres, via des règles majoritaires, pour faire des choses. Exemples : Bitcoin (on ne peut pas écrire tout ce que l'on veut dans le journal des opérations, il y a des contrôles par les pairs), BGP (il faut des accords d'interconnexions basés sur des tas de règles explicites et implicites) ;
    
    
  • Classe 4 : tout le monde gère un bout du système, tout le monde est égal et il y a aucune dépendance aux autres. Exemples : GNUnet (qui, dans son mode radical permet de se passer d'IP via un nouveau protocole et son propre mécanisme de routage et, qui, dans sa version "over IP", propose un système de nommage de proche en proche comme ce que proposait l'UUCP des débuts) ou Babel (réseau pair-à-pair avec routage autoconfiguré) ;

• Rien est parfait :

  • TOR : Les services cachés sont accessibles via un nom dérivé d'une clé cryptographique générée localement (ce qui en fait un système de classe 4) peu lisible ou par un nom parlant choisi localement mais approuvé par un vote du réseau (ce qui en fait un système de classe 3). Stéphane ne mentionne pas le choix des nœuds de sortie via un consensus du réseau afin de limiter certaines attaques… ;
    
    
  • BitTorrent : un système de classe 4 majoritairement utilisé avec des moteurs de recherche spécialisés (de classe 1) ou de la recherche dans la DHT (classe 3) et des trackers pour accélérer la mise en relation (classe 1) ;
    
    
  • Courrier : système de classe 4 (tout le monde peut installer son serveur emails), mais il est vite compliqué de s'envoyer des emails sans noms, or DNS, le principal mécanisme pour les résoudre, est un système de classe 2;
    
    
  • Les systèmes de classe 3 et 4 compliquent la lutte contre les comportements asociaux (spam dans BitMessage, pédoporn, etc.) ;
    
    
  • Les systèmes de classe 4 reposent majoritairement sur de la cryptographie pénible à gérer : il faut veiller à avoir des copies de sa clé privée sans quoi tout est perdu… tout en veillant à sa confidentialité, ce qui forme deux objectifs contradictoires ;

• Internet lui-même n'est pas de classe 4 : tout le monde peut monter un réseau TCP/IP (mais pas à l'échelle internationale), mais il faut se mettre d'accord sur les protocoles utilisés (classe 3), il faut un système de nommage (l'actuel est de classe 2), etc.

FranceConnect : un accès universel aux services en ligne

• Service ministériel de tiers de confiance selon une architecture OpenID (fournisseurs d'identité, fournisseurs de services, fournisseurs de données, etc.) ;
  
  
• Les fournisseurs d'identité vérifient plus ou moins fortement les identités et l'existence d'un lien entre une identité et une personne physique (ce qui différencie FranceConnect de FacebookConnect, par exemple). FranceConnect pourra utiliser des fournisseurs d'identités européens (utile pour un résident UE qui doit remplir de la paperasse en France, par exemple). L'harmonisation en matière de contrôle de l'identité sera cadrée par le règlement européen iDAS ;
  
  
• Afin d'éviter les doublons, il y a une recherche dans le Registre National des Identités des Personnes Physiques, fichier géré par l'INSEE et accessible sur décision ministérielle ;
  
  
• FranceConnect permet de mettre en relation des services qui ont besoin de données (exemple : un revenu fiscal de référence) et un fournisseur de données (exemple : la DGFIP). Les données échangées ne circulent pas par FranceConnect, seulement la mise en relation sécurisée ;
  
  
• FranceConnect : OpenID ; Fédération d'identité Enseignement Supérieur et Recherche : SAML. Passerelle afin de faire communiquer ces deux mondes technologiques ;

Passage à l'échelle de l'infrastructure réseau d'une solution de virtualisation avec VXLAN

• Architecture : VLANs entre des pare-feux (OpenBSD) et des machines virtuelles (KVM-libvirt), avec tout un réseau dorsal entre les deux ;
  
  
• Limites de 802.1q : explosion de la taille des tables de commutation, limitation à 4096 VLANs, et exploitation pénible (pour ajouter/modifier/supprimer un VLAN, il faut configurer l'hyperviseur, les pare-feux et toooous les switchs entre les deux) ;
  
  
• Autre solution envisagée : MVRP, protocole de signalisation et de remontée automatique des VLANs à travers tout le réseau, depuis les commutateurs auxquels sont branchés les hyperviseurs, jusqu'aux commutateurs auxquels sont reliés les pare-feux. Ce protocole ne répond pas au cahier des charges : le nombre de VLANs reste limité et l'explosion de la table de commutation n'est pas endiguée ;
  
  
• VXLAN : overlay network, encapsulation des trames ethernet dans des entêtes VXLAN qui fonctionne lui-même sur UDP ;
  
  
• Comment gérer le trafic broadcast, multicast et unicast sans association MAC<->IP ? Préremplir les tables de commutation VXLAN des VTEP (nom des points d'entrés d'un réseau VLAN), ce qui dupliquera le trafic vers toutes les entrées de cette table, ou utiliser un groupe multicast pour transporter le trafic VXLAN, ainsi les infos clés (IP, MAC) sont distribuées partout et les tables de commut' se remplissent ;
  
  
• Les pare-feux OpenBSD sont également des passerelles VXLAN entre le réseau VXLAN et l'extérieur (IP vers Internet, etc.) ;
  
  
• VXLAN-EVPN permet d'avoir un control plane basé sur MP-BGP ;
  
  
• VXLAN nécessite de réduire la MTU des hyperviseurs ou d'augmenter la MTU sur le réseau transportant VXLAN, car VXLAN induit un overhead de 50 octets minimum (14 octets pour Ethernet, 20 octets pour IP, 8 octets pour UDP, 8 octets pour les entêtes VXLAN).

Bonnes pratiques de sécurisation de BGP

Quelques rappels concernant la sécurité du routage Internet : bonnes pratiques (RFC 7454), RPKI+ROA pour valider cryptographiquement l'origine des annonces de route, BGPSec pour valider cryptographiquement le chemin complet des routes.

• Le route flap dampering (suppression temporaire des routes instables) s'est remis de sa disgrâce d'il y a quelques années : le RFC 7196 le conseille avec une pénalité de 6000 (ce qui laisse la possibilité de 6 instabilités, chacune ayant une pénalité de 1000 points) ;
  
  
• RFC 8097 : communauté BGP étendue non-transitive pour transmettre l'état de validation RPKI+ROA d'une route au sein d'un même AS.

Caliopen - retrouver une vie privée en ligne

Présentation de Caliopen par Laurent Chemla : écosystème (association, charte, garanties) libre d'instances fédérées agrégeant les communications (email, jabber, XMPP, message privé, SMS, etc.) par personnes participant à la conversation, plus par sujet de la conversation ou par protocole. La confidentialité s'améliorera grâce à des indices de confidentialité, des conseils, et un jeu pour faire progresser son évaluation publique. Projet peu soutenu par la communauté.

• La publication des documents fuités par Snowden a permis une prise de conscience autour de la vie privée, mais cela n'a pas suffit à faire changer les habitudes. En cause, la surveillance coûte peu cher grâce à la centralisation des acteurs Internet, mais la vie privée demande d'importants efforts alors que les citoyens ne lui reconnaissent qu'une importance faible ;
  
  
• La simplicité d'utilisation et la gratuité des plateformes centralisées empêchent l'émergence de solutions identiques, mais sécurisée et payantes, ce qui fait qu'un utilisateur de Protonmail, par exemple, a 1 chance sur 1000 de communiquer avec un autre utilisateur de Protonmail… tous ses autres échanges ne seront pas confidentiels. Les solutions plus radicales, comme Pond ou BitMessage font perdre l'essentiel des contacts ;
  
  
• Dans Caliopen, améliorer la confidentialité de ses communications ne sera pas la fonctionnalité principale : d'abord on attire l'utilisateur par l'agrégation de ses communications et une expérience utilisateur satisfaisante, ensuite on l'aide à améliorer sa sécurité ;
  
  
• Les indices de confidentialité permettent de retrouver une notion perdue avec le numérique : étudier l'aspect d'une enveloppe voire celui des enveloppes scellées par le sceau royal permettait d'attribuer un niveau de confidentialité à son courrier. Exemples d'indices évalués : chiffrement de bout en bout, chiffrement des métadonnées (TLS), utilisation d'un protocole acentré, utilisation d'un service sécurisé (pas un ordinateur dans un cybercafé à l'étranger, double authentification, etc) ;
  
  
• Sur un terminal jugé de faible confidentialité, Caliopen affichera uniquement les messages d'un niveau de confidentialité faible. L'utilisateur pourra contourner cela, mais il perdra des points, et ses correspondants seront informés que tels messages sont devenus moins confidentiels, ceci afin de prendre conscience qu'il n'y a pas que lui dans une conversation et que le choix de sacrifier la confidentialité devrait être discuté ;
  
  
• Caliopen utilisera DANE OpenPGP pour la diffusion et la récupération des clés publiques de chiffrement. Car les serveurs de clés OpenPGP sont compliqués à utiliser, qu'ils peuvent être submergés (xxxx clés soumises par un attaquant pour un même utilisateur) et que les certificats S/MIME dépendent d'autorités de certification qui ont montré leurs faiblesses ;
  
  
• Un projet d'échange des clés publiques par le protocole d'envoi des mails (SMTP) a échoué sa normalisation : SMTP and SUBMISSION Service Extensions For Address Query. Selon moi, sa sécurité repose sur DANE TLSA qui permet de protéger un échange STARTTLS, donc autant utiliser DANE OpenPGP ;
  
  
• Un RFC normalise le format des indices de confidentialité dans l'entête des emails ;

Le SDN pour les nuls

Une causerie sur les solutions de réseaux informatiques programmés (Software Defined Network - SDN).

• SDN englobe beaucoup de choses. La définition a évolué avec le temps ;
  
  
• À l'origine, il s'agissait de dissocier le plan de contrôle (intelligence, routage) et le plan de données (transport des données), dans le but de gérer plusieurs équipements réseaux avec un même contrôleur. Le réseau devient programmable. Exemple : OpenFlow permet de programmer des états dans les équipements réseaux ;
  
  
• Objectif : faire évoluer rapidement le réseau informatique, qui est constamment sous pression (déploiement rapide d'applis, SaaS, Cloud), mais sur lequel les modifs sont moins rapides à déployer que le déploiement d'un logiciel (Docker, etc.) ;
  
  

• Plusieurs catégories de solutions SDN :

  • Une application configure le réseau via différents mécanismes : SNMP, API REST, Puppet, CLI+rancid, OpenFlow, Opflex, etc. Il y a plusieurs solutions, car les besoins sont variés. Exemple : les opérateurs préfèrent Netconf ou OpenFlow pour maîtriser une certaine hétérogénéité de leur parc) ;

    • OpenFlow : protocole qui suit un modèle impératif (fais ça, ci, puis cela) ou hybride, qui intervient en couche basse pour créer une table des flux avec des actions (ajouter un entête GRE, transférer sur tel port, ajouter le paquet en file d'attente, etc.), qui sera parcourue pour chaque paquet reçu ;
      
      
    • Netconf (protocole de transport) + YANG (langage de description de ce que l'on veut faire), tous deux normalisés à l’IETF : modèle déclaratif (on déclare un objectif à atteindre, l'état voulu et l'équipement l'implémente comme il le souhaite) ;
      
      
    • Utiliser le matériel de commutation (qu'on nomme white box) et le logiciel de son choix qui utilise des API pour causer aux ASIC. Exemple : Cumulus OS. On perd la dépendance à un fournisseur de matériel grâce à l'abstraction… pour aller vers un modèle de dépendance envers un fournisseur d'ASIC ? Ce modèle peine à trouver son modèle de support (qui prend en charge un dysfonctionnement dans sa globalité, matériel+logiciel, sans se renvoyer la balle ?) ;
      
      
    • Le matériel est différent… Une API ne fait pas tout… Il existe des ASIC, des ASIC programmables, des CPU, des FPGA… Compromis entre la flexibilité / les fonctionnalités et le prix ;

  • Une application communique avec un contrôleur qui communique avec le réseau (OpenFlow, Netconf, etc.). Le contrôleur abstrait le réseau en une seule et même entité, un même système, mais le fonctionnement reste identique à celui de la première catégorie. Il existe plusieurs API de chaque côté (API nord entre l'application et le contrôleur, API sud entre le contrôleur et le réseau). On est dans un modèle déclaratif. Exemple de contrôleur : le consortium OpenDaylight, qui était cependant très peu utilisé en 2015 ;
    
    

  • Virtualisation des fonctions réseaux (NFV). Il s'agit de réseaux overlay qui abstraient les contraintes physiques. Exemples : VXLAN, firewall virtuel pour x clients plutôt qu'un firewall physique par client, box Internet virtuelle, etc. Cette catégorie suppose un effet de masse pour être rentable, ce qui suppose un outil d'orchestration, c'est-à-dire une abstraction des contrôleurs qui eux-mêmes sont une abstraction du réseau. Exemple : pour déployer telle application, il faut déployer tels VLAN et telles règles de filtrage dans le datacenter, ajouter telle QoS dans le LAN, faire telle modif sur le WAN, etc.