Un excellent document de l’#IAB, sur les tentatives maladroites de « réguler » l’Internet via une action sur l’infrastructure, et pourquoi c’est une mauvaise idée. (Le #DNS, et notamment les résolveurs menteurs comme en France, est cité, mais aussi #BGP et autres technologies.)
À faire lire à tous vos amis députés ou ministres.
▻https://www.iab.org/documents/correspondence-reports-documents/2019-2/avoiding-unintended-harm-to-internet-infrastructure
Disabled, but at What Cost? An Examination of Wheelchair Routing Algorithms
▻https://www.researchgate.net/publication/325626008_Disabled_but_at_What_Cost_An_Examination_of_Wheelchair_Routi
“When routers try to be smart and helpful, they end up being dumb and harmful”
▻https://huitema.wordpress.com/2018/03/03/having-fun-and-surprises-with-ipv6
#IPv6 #internetworking #interréseautage #routage #routing
C’est un exercice facile, parmi les gens qui connaissent un peu (mais pas beaucoup) l’#Internet de critiquer le protocole de #routage #BGP. Un exemple est ce mauvais article
▻https://networkingnerd.net/2017/12/15/should-we-build-a-better-bgp, dont l’auteur n’a même pas compris la différence entre IGP (protocole de routage interne, toutes les machines sont sous la même administration et se font confiance) et
EGP (protocole de routage externe, entre organisations concurrentes, voire ennemies). BGP est un EGP et cela explique bien des choses dans sa conception.
Cet article explique bien pourquoi BGP est comme il est et ce qui fait qu’il n’est pas facile de faire « mieux » :
Annonces #BGP plus spécifiques : bien ou mal ?
L’article de Geoff Huston « BGP More Specifics : Routing Vandalism or Useful ? » aborde une question qui a toujours déclenché de chaudes discussions dans les forums d’opérateurs réseaux : est-ce que les opérateurs qui, au lieu d’annoncer un et un seul préfixe IP très général, annoncent plusieurs sous-préfixes, sont des salauds ou pas ? Est-ce l’équivalent de polluer et de taguer ? Après une étude soignée et pas mal de graphiques, il apporte une réponse originale.
Son article :
▻https://blog.apnic.net/2017/06/26/bgp-specifics-routing-vandalism-useful
Mon résumé :
The Unreasonable Effectiveness of Spectral Graph Theory
▻https://www.youtube.com/watch?v=8XJes6XFjxM
Partitionnement spectral
▻https://fr.wikipedia.org/wiki/Partitionnement_spectral
#spectral_graph_theory #machine_learning #clustering #routage
Se former à Tcp/Ip en environnement #Windows
▻http://www.dsfc.net/formations/formations-systeme-et-reseau/se-former-tcp-ip-environnement-windows
Au cours de ces 3 journées de formation, vous apprendrez à déployer, configurer, optimiser Tcp / Ip sur les serveurs et les stations Windows.
#Système_et_Réseau #ARP #Dns #Ethernet #Firewall #Formateur_IP #Formateur_IPv4 #Formateur_IPv6 #Formateur_Réseau #Formateur_Tcp/Ip #Formation_IPv4 #Formation_IPv6 #Formation_Réseau #Formation_Tcp/Ip #IPv4 #ipv6 #LAN #Modèle_DoD #Modèle_OSI #Pare-feu #Réseau #Routage #SSH #Subnetting #Tcp/Ip #VPN #WAN #Windows_Server #Wins
Design principles for origin-destination flow maps
▻http://cartography.oregonstate.edu/pdf/2017_Jenny_etal_DesignPrinciplesForODFlowMaps.pdf
ABSTRACT
Origin-destination flow maps are often difficult to read due to overlapping flows. Cartographers
have developed design principles in manual cartography for origin-destination flow maps to
reduce overlaps and increase readability. These design principles are identified and documented
using a quantitative content analysis of 97 geographic origin-destination flow maps without
branching or merging flows. The effectiveness of selected design principles is verified in a user
study with 215 participants. Findings show that (a) curved flows are more effective than straight
flows, (b) arrows indicate direction more effectively than tapered line widths, and (c) flows
between nodes are more effective than flows between areas. These findings, combined with
results from user studies in graph drawing, conclude that effective and efficient origin-destination
flow maps should be designed according to the following design principles: overlaps between
flows are minimized; symmetric flows are preferred to asymmetric flows; longer flows are curved
more than shorter or peripheral flows; acute angles between crossing flows are avoided; sharp
bends in flow lines are avoided; flows do not pass under unconnected nodes; flows are radially
distributed around nodes; flow direction is indicated with arrowheads; and flow width is scaled
with represented quantity
#cartographie #ligne #flux #circulation #sémiologie #sémiologie_graphique #sémantique
RFC 8092 : BGP Large Communities Attribute
Ce #RFC normalise un nouvel attribut des annonces #BGP, « Large Communities ». Les « communautés » BGP sont des courtes données collées aux annonces BGP et qui permettent d’indiquer certaines caractéristiques des routes. Les décisions des routeurs peuvent utiliser ces caractéristiques. Mais les communautés originales étaient trop courtes (seulement quatre octets) : le nouvel attribut permet des communautés de douze octets.
RFC 1997 : BGP Communities Attribute
Il n’y a pas de rapport simple entre la longueur d’un #RFC et l’importance de la norme technique qu’il spécifie. Ce RFC (vieux de plus de vingt ans) ne fait que cinq pages mais décrit une technique qui est essentielle au bon fonctionnement du routage sur l’Internet, la technique des communautés #BGP.
Galton : instant availability zones – Urbica.co
►https://medium.com/@Urbica.co/hello-galton-e6e07a7164b7
Using Open Source Routing Machine, Turf and Concaveman open code and #OpenStreetMap open data, we developed a fast and lightsome Node.js server for availability zones computing.
▻http://galton.urbica.co
#accessibilité #cartographie #routage
(et #facepalm pour le nom : ▻http://www.newstatesman.com/society/2010/12/british-eugenics-disabled )
RFC 7920 : Problem Statement for the Interface to the Routing System
Autrefois, la configuration des #routeurs était relativement statique. On indiquait la politique de #routage (le coût de tel ou tel lien, par exemple), les préfixes IP, les pairs BGP, parfois des routes statiques, et le routeur parlait avec ses copains routeurs, construisant ses tables qu’il allait ensuite utiliser pour la transmission des paquets. La configuration n’était pas modifiée tous les jours et quand c’était nécessaire, on se connectait à tous les routeurs qu’il fallait changer et on modifiait la config. Dans les organisations plus modernes, on édite la config, on la commite dans un VCS et on la pushe vers les routeurs avec Ansible ou un truc équivalent. Aujourd’hui, même cela ne suffit pas, on voudrait être plus agile. On voudrait modifier la configuration des routeurs à peu près en temps réel, pour répondre à des considérations de business (créer un nouveau service pour un client, profiter de variations de prix chez les transitaires...) ou à des problèmes de sécurité (déployer des filtres subtils). Cette exigence nécessite une interface vers le routeur, utilisable par des programmes. C’est le projet #I2RS, Interface To the Routing System. Ce premier #RFC du groupe de travail décrit précisement le problème qu’on essaie de résoudre. (Notez que le buzzword SDN n’apparait pas une seule fois dans ce RFC...)
Vous connaissez le « routage Schengen » ou le « tromboning » ? Ces deux termes sont utilisés dans le monde des réseaux informatiques dans le contexte des discussions sur un problème de « souveraineté numérique » : faire en sorte que le trafic national (ou européen) ne circule que sur les réseaux nationaux (ou européens). Le « #routage_Schengen » désigne l’assurance que le trafic entre deux acteurs européens (soumis, donc, aux règles comme la protection des données personnelles) ne passe pas par un pays non-Schengen, qui peut espionner, par exemple pour le compte de la NSA. (Chose qu’un pays européen ne fera jamais, non.)
Le « #tromboning » est l’inverse : c’est l’envoi des données par une route détournée qui est non seulement non-optimale mais qui, en prime, facilite l’espionnage.
Cet excellent article « Characterizing and Avoiding Routing Detours Through Surveillance States » (qui avait été présenté par une des auteures, Anne Edmundson, à NANOG en 2016) présente d’utiles mesures sur le tromboning et sur la lutte contre ces détours. On ne s’étonnera pas d’apprendre qu’il est difficile d’éviter le détour par les États-Unis... (Éviter la France, un autre pays de surveillance, est bien plus facile.)
▻https://arxiv.org/abs/1605.07685
Et « Schengen Routing : A Compliance Analysis » fait la même analyse pour le cas spécifique du Schengenistan :
▻https://www.researchgate.net/publication/300791629_Schengen_Routing_A_Compliance_Analysis
Le tromboning est un classique du roaming sur les réseaux telco... L’opérateur « home » veut toujours garder le contrôle de l’activité de son abonné - non seulement les circuits mais aussi le trafic avec l’Internet qui passe toujours par un routeur dans le pays « home » alors que la sortie dans le pays visité est une architecture tout aussi valable techniquement.
Par contre le routage Schengen je n’avais encore jamais vu !
@liotier C’est même dans Wikipédia :-) ▻https://en.wikipedia.org/wiki/Schengen_Routing
Une version résumée de l’article d’Edmundson ▻https://labs.ripe.net/Members/annie_edmundson/routing-detours-can-we-avoid-nation-state-surveillance
RFC 7855 : Source Packet Routing in Networking (SPRING) Problem Statement and Requirements
Traditionnellement, la transmission d’un paquet IP au routeur suivant était faite uniquement sur la base de l’adresse de destination, sans tenir compte du reste du paquet. Et la décision est prise par chaque routeur, sur le trajet, en complète indépendance. Or, l’émetteur d’un paquet voudrait souvent décider de la route suivie ou, au minimum, l’influencer. C’est pour cela qu’il existe des mécanismes de #routage par la source (#source_routing). Leurs défauts et leurs limites ont mené à la recherche d’une meilleure solution, dite SPRING (Source Packet Routing In NetworkinG). Ce #RFC est la description du problème.
RFC 7682 : IRR & Routing Policy Configuration Considerations
On le sait, il n’y a pas de chef de l’Internet. Personne ne reste dans un bureau toute la journée avec pour mission l’envoi de règles qui seront immédiatement appliquées par tous les acteurs de l’Internet. C’est même le cas des fonctions les plus essentielles de l’Internet comme l’échange des tables de #routage. Tout l’Internet ne tient que parce que les opérateurs sont d’accord entre eux pour s’échanger l’information qui se retrouvera dans ces tables « pour joindre le préfixe 2001:db8:fe2: :/48, passez par moi, je connais un chemin que j’ai appris des AS 64499 puis 429496613 ». Cet accord de principe se double d’un accord technique sur le protocole à utiliser : #BGP. Et au delà, rien, aucun accord : chaque opérateur est libre de sa politique et notament de ce qu’il accepte ou refuse. Un opérateur peut refuser les préfixes plus spécifiques que /32, par exemple. Chacun est maître chez soi. En pratique, bien des opérateurs refusent les préfixes qui ne sont pas dans un #IRR. C’est quoi, un IRR ? Qui les gère ? Qui décide de ce qu’on met dans un IRR ?. Ce nouveau #RFC explore la question.
RFC 7608 : IPv6 Prefix Length Recommendation for Forwarding
Comme IPv4, #IPv6 route les paquets en fonction d’un préfixe d’adresses, préfixe qui a une longueur comprise entre 0 (tout l’Internet) et 128 bits (une seule machine). Ce très court #RFC a juste pour but de rappeler cette règle : la longueur d’un préfixe est quelconque, les mises en œuvres de IPv6, logicielles ou matérielles, ne doivent pas imposer ou favoriser une longueur de préfixe particulière (même pas 64, souvent considéré, à tort, comme spécial). Le #routage se fait exclusivement sur le plus long préfixe, quelle que soit sa longueur.
Internet : une partie des sites inaccessible à cause d’un problème de routage
▻http://www.nextinpact.com/news/95399-internet-partie-sites-inaccessibles-a-cause-dun-probleme-routage.h
Les différents retours des spécialistes convergent tous plus ou moins dans le même sens : Telekom Malaysia aurait envoyé ses tables de routage BGP internes sur Internet, alors que cela ne devrait pas être le cas. Les annonces BGP permettent concrètement de diriger le trafic Internet vers un serveur ou un autre, par exemple pour diriger les connexions des internautes vers les serveurs à proximité. Le service de protection de sites Cloudflare dispose de serveurs dans toutes les régions du monde, et renvoie les internautes vers celui qui est le plus proche d’eux.
Les annonces de Telekom Malaysia auraient été reprises par Level3, sans plus de vérification malheureusement. Ce dernier étant l’un des plus gros opérateurs de transit, on comprend que cela peut poser de nombreux problèmes sur l’Internet mondial. En effet, une grosse partie de son trafic passerait donc par la Malaisie, avec un réseau pas vraiment taillé pour.
#Border_Gateway_Protocol #Internet #Level_3_Communications #Malaisie #Routage_ #Telekom_Malaysia
RFC 7503 : OSPFv3 Auto-Configuration
Le protocole de #routage #OSPF est traditionnellement configuré statiquement, et à la main par l’administrateur réseaux. Certains réseaux, comme par exemple des réseaux un peu complexes à la maison (#Homenet), ont besoin d’un protocole de routage, mais sans avoir d’administrateur réseaux disponible. Il faudrait un OSPF qui se configure tout seul, « plug and play ». Ce court #RFC montre que c’est possible, avec très peu de modifications des mises en œuvre d’OSPF.
Router Manufacturers Secretly added TCP 32764 Backdoor Vulnerability Again - The Hacker News
▻http://thehackernews.com/2014/04/router-manufacturers-secretly-added-tcp.html
The Reverse-engineer from France Eloi Vanderbeken, who discovered this backdoor has found that although the problem has been patched in the latest firmware release, (...) SerComm has added the same backdoor again in another way.
(...) another mysterious tool called ‘ft_tool’ with “-f”option that could re-activates the TCP backdoor.
#surveillance #NSA #backdoor via @ybon
Cf. How the NSA tampers with US-made internet routers ▻http://www.theguardian.com/books/2014/may/12/glenn-greenwald-nsa-tampers-us-internet-routers-snowden
RFC 7181 : The Optimized Link State Routing Protocol version 2
Il existe désormais plusieurs protocoles de #routage pour le problème difficile des #MANETs, ces réseaux ad hoc (c’est-à-dire non organisés et non gérés) de machines diverses connectées de manière intermittente. On est loin des réseaux structurés classiques, avec leurs routeurs bien administrés qui se parlent en OSPF. Dans un MANET, le réseau doit se configurer tout seul, il n’y aura pas d’administrateur pour cela. Notre nouveau #RFC décrit la version 2 d’un de ces protocoles de routage les plus répandus, #OLSR.
▻http://www.bortzmeyer.org/7181.html
#cccp
« Nation-State Routing : Censorship, Wiretapping, and BGP » de Josh Karlin, Stephanie Forrest et Jennifer Rexford.
Une excellente étude de 2009 sur les conséquences de la #censure sur l’#Internet. Certaines techniques de censure affectent tout le trafic passant par le pays, même si les deux parties qui communiquent ne sont pas dans le pays en question. Ce n’est pas trop grave pour certains pays très censeurs, comme l’Iran, car ils ne servent jamais de lieu de transit pour d’autres pays. Mais c’est beaucoup plus grave pour la Grande-Bretagne qui, certes, censure moins, mais sert beaucoup plus souvent de transit.
Pour quantifier cet effet, les auteurs ont utilisé un indice d’intermédiation (« betweenness centrality » ▻http://en.wikipedia.org/wiki/Betweenness_centrality ). Ils en ont dérivé une « country centrality » qui vaut 0 quand le pays ne sert jamais de transit entre deux autres pays et 1 quand son usage comme transit est obligatoire. Deux techniques différentes (fondées sur des #traceroute et sur l’analyse des annonces #BGP) servent ensuite à calculer la country centrality.
On ne s’étonnera pas que les États-Unis aient une country centrality d’environ 0,35 ; concrètement, cela veut dire que deux interlocuteurs non situés aux USA ont une chance sur trois de voir leurs paquets IP passer par les USA. Autant dire qu’une censure par adresse IP aux États-Unis toucherait plein de gens n’ayant rien à voir avec ce pays. La Grande-Bretagne est seconde (0,19 à 0,24 selon la technique de calcul). Ça baisse très vite ensuite. Si Malek Boutih réussit à faire censurer l’Internet en France, cela affectera surtout des français. La Chine, grand censeur, est encore plus loin derrière et les cas où sa censure déborde sur d’autres pays sont donc rares.
Intéressant ! Est-ce que ça a un rapport aussi avec les possibilités d’écoute du trafic de la part de ces pays ?
@severo Oui. Un des tous premiers documents Snowden publiés, celui sur PRISM, contenait une phrase disant en gros « nous avons de la chance, nous sommes sur le trajet de beaucoup de communications, profitons-en pour écouter »
En passant, Internet est formé d’environ 30000 systèmes autonomes
The Internet is currently comprised of roughly 30,000 Autonomous Systems , which are typically independently operated, multi-homed networks. Each AS is allocated IP address space, which is a contiguous blocks of IP addresses called IP pre-fixes. The interdomain routing protocol that allows ASes to reach one another’s pre-fixes is called the Border Gateway Protocol (BGP)
RFC 7132 : Threat Model for BGP Path Security
Tout le monde le sait, le système de #routage de l’Internet, fondé sur le protocole #BGP, n’est pas sûr. Il est trop facile d’y injecter des annonces de routes mensongères. Le premier pas vers une sécurité plus forte était de sécuriser la communication entre routeurs (RFC 5925). Un second pas a été réalisé avec le déploiement de la #RPKI. Un troisième pas avec la normalisation de la solution RPKI+ROA. Cette dernière protège uniquement l’origine d’une annonce BGP. Cela suffit à arrêter pas mal d’erreurs mais une attaque délibérée gardera probablement l’origine authentique et trichera sur le chemin d’AS présent dans l’annonce BGP. D’où la nécessité de continuer le travail. C’est le projet #PATHSEC (Path Security) pour lequel ce nouveau RFC énumère les motivations. (Le terme de #BGPSEC avait été utilisé dans le passé mais PATHSEC semble plus fréquent aujourd’hui.)
RFC 7128 : RPKI Router Implementation Report
Le protocole #RTR (#RPKI to Router Protocol), normalisé dans le RFC 6810, est utilisé entre un routeur et un cache/validateur qui vérifie les objets signés de la RPKI. Ce nouveau #RFC fait le point sur les mises en œuvre effectives de RTR et leur degré de couverture de la norme.
Le modèle du routage de l’internet appliqué au monde physique - Technology Review
▻http://www.technologyreview.com/view/522471/how-internet-style-routing-for-gas-could-dramatically-improve-euro
Si on acheminait le gaz en Europe sur le modèle du routage décentralisé de l’internet, est-ce que cela pourrait réduire la crise de l’énergie ? Oui, estiment les spécialistes de la complexité. Tags : internetactu internetactu2net fing #infrastructures #internetphysique
Resilience of natural gas networks during conflicts, crises and disruptions
▻http://arxiv.org/abs/1311.7348
Une énorme faille de l’Internet permet de détourner du trafic à volonté
►http://www.01net.com/editorial/609854/une-enorme-faille-de-l-internet-permet-de-detourner-du-trafic-a-volonte
usurper les annonces BGP n’est suffisant. Pour réaliser un « bon détournement », il faut également faire en sorte que les données siphonnées arrivent à bon port, pour ne pas éveiller des soupçons côté destinataire. Et ça, c’est beaucoup plus compliqué. « Ce n’est pas à la portée du premier lycéen venu. Il faut une équipe de spécialistes et un certain budget pour pouvoir réaliser cette opération », explique @Stephane Bortzmeyer, ingénieur réseau
Titre sensationnaliste mais le contenu est bien meilleur. Sinon, l’article original de Rensys avait déjà été mentionné sur SeenThis (excellent rézosocio, ma foi) ►http://seenthis.net/messages/198338
