Compte rendu du FRnog 29

L’équipe Odiso était présente lors de la 29° réunion FRnOG qui s’est tenu à Paris le vendredi 15 septembre 2017.

Pour rappel, le FRench Network Operators Group (FRnOG) est un groupe d’échange d’informations entre professionnels du réseau et de la sécurité.

Voici les différents thèmes abordés :

Présentation d’AOTA

par Nicolas Guillaume de l’AOTA

Dans le paysage actuel des opérateurs télécoms, les OCER (opérateurs commerciaux d’envergure régionale) n’était jusqu’à récemment pas représentés à l’échelle nationale, alors qu’elle sont les premières au contact des initiatives publiques, qu’elles participent à l’aménagement du territoire, et que d’autres groupes ont déjà leurs représentations, notamment la FFT, la FiRIP, ou la FFDN.

Pour ces raisons, l’association des opérateurs télécoms alternatifs (AOTA) a été créée en mars 2017. Elle aura pour but de mieux représenter les opérateurs dits « alternatifs » auprès des pouvoirs publiques qui ont la main sur l’aménagement numérique du territoire (préfecture de région, département), les institutions nationales (ARCeP, mission France Très Haut Débit), et les régulateurs européens.

Concrètement par exemple, elle a déjà permis de faire remonter auprès de l’ARCEP des anomalies sur les conditions d’accès aux NRO d’Orange, le but étant de permettre de faciliter leur accès aux opérateurs tiers pour produire du FFTE/FTTH pro.

Il est question aussi de batailler ardemment sur la question du bitstream FTTH dans un marché largement dominé par Orange et SFR, et sans réelle concurrence libre.

C-RAN – far more than 5G

par James Merchant de HUBER+SUHNER Cube Optics

Les déploiements des réseaux sans fils modernes, notamment la 5G, se font désormais en C-RAN, Centralized-Remote Access Network, plutôt qu’en D-RAN, Distributed-Remote Access Network, qui correspond à l’architecture précédemment utilisée depuis l’apparition de la 3G. Le déploiement en C-RAN offre de meilleures performances, une souplesse de (re)déploiement (notamment lors d’événements ponctuels où une couverture particulière doit être opérée) avec l’usage de plateformes ouvertes et des technos de virtualisation.

Mise à jour sur BGPSec

par Stephane Bortzmeyer de l’AFNIC

Internet, de par les faiblesses de sécurité de BGP, connaît depuis toujours des accidents mondiaux de hijacks/route leaks BGP, souvent accidentels, comme les bien connus hijacks de préfixes de Youtube par un opérateur pakistanais, ou la très récente mauvaise manip de Google impactant une grosse partie du Japon. S’il existe déjà des mécanismes de sécurisation comme RPKI+ROA, ce dernier ne garantit que l’origine des routes, pas tout le chemin d’AS. BGPSec a donc été élaboré depuis quelques temps dans ce but.

BGPSec utilise la même RPKI que pour les ROA. La subtilité de BGPSec est que non seulement l’origine doit signer son annonce, mais chaque routeur du chemin d’AS doit aussi signer ses annonces afin de garantir l’intégrité du chemin d’AS. Il faut donc une chaîne complète de routeurs BGPSec pour que le système fonctionne. Techniquement, l’ancien attribut AS_PATH disparaît, et fait place à un nouvel attribut BGPSec_path, soit une nouvelle capacité BGP que les routeurs négocieront entre eux.

Parmi les faiblesses du protocole, si BGPSec protège l’AS Path, il ne protège par les communautés qui sont pourtant beaucoup utilisées. De plus, autre problème majeur : si on décide de refuser des annonces invalides sur un routeur BGPSec, que faire sur un éventuel autre peer BGP non-BGPSec qui les acceptera par défaut ? Cela implique que le déploiement partiel de BGPSec le rendra très peu efficace, et donc finalement très peu adopté. Mais comme le dit Bortzmeyer, tout le monde dit vouloir davantage de sécurité mais, en pratique, personne ne veut en payer le prix. 🙂

Introduction à NetConf, YANG et OpenConfig

par Khelil Sator de Juniper

NetConf est un standard IETF pour la configuration et les données d’états des équipements réseaux, en gros SNMP en mieux, YANG un langage de modélisation des données de ces configs envoyées à travers le protocole netconf, et Openconfig un groupe d’admins réseaux (Google est le principal contributeur par exemple) qui veut promouvoir cette manière de manager les équipements réseaux dans une approche libre et ouverte (au sens « vendor-neutral »).

Sur du Juniper, cela utilise un serveur gRPC qui se comporte comme un publisher qui envoie ses données netconf à des collecteurs, des clients gRPC, qui se comporte comme des subscribers. Ensuite les données peuvent par exemple être poussées sur de l’influxDB puis graphées dans grafana.

Pour plus d’infos sur l’implémentation de netconf par Juniper : https://www.juniper.net/documentation/en_US/junos/topics/concept/open-config-grpc-junos-telemetry-interface-understanding.html

Pour plus d’infos sur netconf et yang : https://fr.slideshare.net/cmoberg/a-30minute-introduction-to-netconf-and-yang

Flows, Trafic Engineering et DDoS

par Pierre-Yves Maunier de Dailymotion

Afin d’avoir de la visibilité sur les flux réseaux de Dailymotion, notamment où va le trafic, ils ont mis en place PMACCT avec le module BGP et PostgreSQL, le premier pour corréler les quantités des données avec les AS PATH correspondants, le second pour requêter facilement les données.

Quelques problèmes avec cette solution : la configuration et la maintenance de PMACCT n’est pas aisée quand on commence à vouloir faire des choses plus compliquées/customisées, cela prend beaucoup de temps, et sa scalability est difficile quand on commence à traiter un volume de données aussi importante que celles de Dailymotion : pour 2,8Tbps de capacité, avec un sampling à 1/8000, cela fait 55Go de data journalière en BDD, soit 300 millions de lignes, les performances commencent à poser problème.

De plus, PMACCT n’offre aucune GUI, il faut tout faire soi-même : pour Dailymotion, un collectd poussait les données dans des RRD, et le graphing avec graphite (pour les besoins internes d’ODISO j’utilise influxDB et grafana pour faire la même chose).

Dailymotion avait aussi besoin de détection DDoS, ce que ne permet pas de faire PMACCT, ainsi que d’une fonction de scrubbing center pour le nettoyage du trafic en live.

Pour répondre à tous ces problèmes/besoins, Dailymotion a choisi d’externaliser avec la solution payante Kentik, qui permet de faire tout ça dans une application SaaS user-friendly.

GScan

par Charles-Antoine Mathieu d’OVH

Pour tenir ses engagements de qualité de service, OVH développe un outil de scan du réseau pour obtenir en cas d’incident une meilleur perception de ce qu’il se passe, réagir plus rapidement et la chose la plus difficile parfois : trouver la rootcause rapidement.

Le challenge de base : pinger 5 millions d’IPs en 5 secondes.

Pour cet outil, OVH utilise :

  • une librairie développée en Go par Google : gopacket, qui permet de crafter, capturer et parser les packets réseaux,
  • pf_ring ZC (équivalent de libpcap, en mieux), ZC pour Zero Copy qui permet de transférer les paquets directement de la carte réseau à l’application, sans passer par le kernel,
  • le Receive Side Scaling (techno des cartes réseaux Intel) : permet de multithreader le traitement des packets réseaux.
  • Ajout des timestamps dans les headers IP des paquets ICMP directement en IO des cartes réseaux, et non pas applicativement.

Actuellement, seul le shortest path vers les hosts est monitoré. Pour scanner à travers tous les chemins possibles, ils envisagent d’utiliser du segment routing (alias source routing) qui permet d’ajouter des headers dans les paquets pour forcer l’emprunt d’un chemin réseau bien précis.

Au delà du scan, les paquets sont taggés pour rattacher chaque item à un switch/routeur/DC/rack/serveur/zone géographique, etc. et agréger les données par ces tags et permettre de grapher les résultats par tag. Cela permet par exemple de détecter qu’une anomalie qui touche plusieurs clients à priori sans lien apparents entre eux provient d’un switch ou un routeur en amont pour qui tous les assets rencontrent des problèmes.

Avec ce tagging, OVH essaye de créer des recoupements par hypergraphes pour les tags qui englobent le plus d’actifs défectueux, et ainsi faciliter le travail des équipes d’intervention.

FRR

par Vincent Jardin de 6Wind

Je n’ai malheureusement pas assisté à cette présentation.

Détection DoS/DDoS

par Gilles Roudière du LAAS/CNRS

Dans le cadre d’un projet de recherche, Gilles Roudière a cherché à développer un algorythme de détection des attaques DdoS qui ne soit pas basé sur une signature (donc connue), appelé en interne « AATAC » pour Autonomous Algorythm Traffic Anomaly Characterization.

L’algo doit être autonome, extrait automatiquement des classes de trafic (pour créer ensuite des règles de filtrage), bien que cette fonction demande beaucoup de ressources de calcul car du datamining est réalisé, les éléments étant comparé deux à deux, et doit produire des résultats simples à interpréter.
L’algo a été testé sur un rejeu de vrai trafic de production fourni par un tiers, et 100 % des attaques (insérées manuellement dans le rejeu) ont été détectées. Comparativement à d’autres outils comme FastNetMon basé sur des signatures, il est 3 fois plus lent et ne détecte que la moitié des attaques.

L’algo pourra à l’avenir générer automatiquement des signatures d’attaques.

Plus d’info ici : https://ressi2017.sciencesconf.org/133770/document

Le #MAN en #CollTerr, est-ce encore raisonnable aujourd’hui ?

Par Cem Carfil de la Mairie de Dammarie-Lès-Lys

La mairie ayant pour projet de rénover et rationaliser son infrastructure réseau, cette dernière a été presque intégralement refaite, avec une purge des liens historiques Orange (LS, SDSL, MPLS notamment) qui avaient des coûts exhorbitants. L’objectif était aussi de rendre le réseau de la commune le plus autonome possible.

Aussi, en moins d’un an, la nouvelle infra, reposant notamment sur de nombreuses antennes en FH (faisceau hertzien, précisément pour conserver l’autonomie) a été déployée avec comme deadline la rentrée scolaire et la coupure franche des liens Orange : des LS, des SDSL, 400 SDA (téléphonie) à migrer… et la construction d’un petit DC « maison » !

Résultat : budget télécoms de 350.000€ en 2008 à 80.000€ en 2010. Débits en 2008 : de la LS 2Mb, de l‘ADSL 1Mb, du RNIS. En 2010 : Fibre optique 100Mb, Trunk SIP 10Mb, site à site,…

Au délà de l’aspect technique et financier, ce projet constitue un patrimoine pour les années à venir de la commune. Retrouvez les slides ici : http://blog.cemavec1c.fr/public/prez/FRNOG/FRnOG29_DSI_DLL_v2-150dpi.pdf

Voici pour le compte-rendu de ce FRnog très dense et très sympa.