The geopolitics behind the routes data travels : a case study of Iran
Article de Loqman Salamatian, Frederick Douzet, Kevin Limonier, Kavé Salamatian
▻https://arxiv.org/abs/1911.07723
Un bon article sur l’organisation de l’Internet en Iran : peu de connexions extérieurres (pour faciliter le contrôle) mais beaucoup de connexions intérieures (contrairement à ce qu’on voit dans la plupart des dictatures qui veulent un Internet sain et civilisé.)
]]>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
]]>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
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.
]]>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
]]>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
Good Knight | Sniper In Mahwah #HFT
▻http://sniperinmahwah.wordpress.com/2013/11/02/good-knight
(le point le plus ahurissant de l’histoire) : en tentant de résoudre cette cacophonie, Knight décida de désactiver le nouveau code de #routage des 7 serveurs qui fonctionnaient pourtant parfaitement, et de fait Power Peg, l’ancien code désormais défectueux, prit le relais, enfonçant Knight dans ses problèmes (c’est sans doute à ce moment-là que la compagnie se retrouva avec des positions comptées en milliards de dollars). Au-delà des détails techniques, la morale de l’histoire est celle-ci : une défaillance humaine concernant un seul #algorithme de routage d’un seul serveur d’un seul opérateur peut avoir des conséquences, dans les marchés, sur la cotation de 75 titres dont Knight Capital fit bouger le cours de plus de 5% (plus de 10% pour 37 d’entre elles). Dans un univers où les machines travaillent vite et bien, une seule petite erreur humaine peut mener à la catastrophe.
And the winner is… #Goldman_Sachs
]]>Découverte d’une porte dérobée (mécanisme permettant de prendre le contrôle d’un système à distance, sans en avoir le droit) dans les routeurs #Dlink.
L’article original du chercheur :
►http://www.devttys0.com/2013/10/reverse-engineering-a-d-link-backdoor
Une explication en français :
▻http://korben.info/backdoor-les-routeurs-d-link.html
Leçons à en tirer : le logiciel privateur fait tout pour vous entuber, et le fait de ne pas avoir le code source n’est pas une garantie de sécurité, bien au contraire.
#sécurité_informatique #NSA (pour les paranos)
]]>NSA Laughs at PCs, Prefers Hacking Routers and Switches | Threat Level | Wired.com
▻http://www.wired.com/threatlevel/2013/09/nsa-router-hacking
The NSA’s focus on routers highlights an often-overlooked attack vector with huge advantages for the intruder, says Marc Maiffret, chief technology officer at security firm Beyond Trust. Hacking routers is an ideal way for an intelligence or military agency to maintain a persistent hold on network traffic because the systems aren’t updated with new software very often or patched in the way that Windows and Linux systems are.
“No one updates their routers,” he says. “If you think people are bad about patching Windows and Linux (which they are) then they are … horrible about updating their networking gear because it is too critical, and usually they don’t have redundancy to be able to do it properly.”
#NSA #surveillance #routage #infrastructure #cybersécurité via @stephane
Fondé en 1984 par Leonard Bosack et Sandra Lerner, un couple qui travaillait au service informatique de l’université Stanford, #Cisco n’a pas été la première société à créer et vendre des routeurs mais Cisco créa le premier routeur multi-protocoles permettant d’interconnecter des réseaux utilisant des protocoles de communication différents.
▻https://fr.wikipedia.org/wiki/Cisco_Systems
Révélations sur le Big Brother français - LeMonde.fr
▻http://abonnes.lemonde.fr/societe/article/2013/07/04/revelations-sur-le-big-brother-francais_3441973_3224.html
La France aussi dispose d’un dispositif d’espionnage des télécommunications à grande échelle. La DGSE collecte les métadonnées de nos communications d’une manière clandestine, « a-légale ». Tags : internetactu2net fing internetactu #surveillance
]]>RFC 6971 : Depth-First Forwarding in Unreliable Networks (#DFF)
Traditionnellement, l’acheminement à bon port d’un paquet #IP nécessitait deux processus distincts : le #routage (routing) à proprement parler, où les routeurs calculent des tables de routage indiquant, pour divers préfixes IP, la prochaine étape (next hop) à atteindre, et la transmission (forwarding) où les routeurs choisissent le prochain #routeur, et l’interface de sortie, pour un paquet donné. Le premier processus, le routage, est fait à l’avance, indépendemment d’un paquet précis, et nécessite des protocoles complexes comme OSPF. Le second processus, la transmission, nécessite de faire tourner l’algorithme de plus long préfixe, et se fait par contre en temps réel, pour chaque paquet entrant. Pourquoi cette séparation en deux ? Car ces deux processus ont des caractéristiques très différentes. Le premier, nécessitant des protocoles et des algorithmes élaborés, est mieux réalisé sur un processeur classique. Le second est typiquement le domaine d’ASIC spécialisés. Les routeurs haut de gamme utilisent d’ailleurs les deux types de matériel, selon la tâche. Mais cette séparation a aussi des inconvénients. Ainsi, la détection qu’un lien ne marche plus est typiquement du ressort des algorithmes de routage, qui ajusteront alors leurs routes. Pourtant, certains réseaux physiques permettent la détection, lors de la transmission d’un paquet, d’une panne et d’une impossibilité d’envoi. Pourquoi ne pas utiliser cette information pour que les paquets suivants aillent essayer une autre étape suivante ? C’est ce que propose ce #RFC.
]]>RFC 6956 : ForCES Logical Function Block (LFB) Library
Le protocole #ForCES vise à permettre la création d’équipements réseaux (par exemple des routeurs) en assemblant des pièces d’origines diverses, parlant un protocole commun et pouvant donc interagir. (Si ForCES réussit, on pourra avoir des routeurs moins chers et plus souples.) Ce #RFC marque l’achèvement de la première (et très longue) phase de ForCES, la normalisation complète de ce protocole. Notre RFC 6956 décrit la bibliothèque standard de ForCES, les parties d’un #routeur qu’on trouvera partout et qui assurent les fonctions indispensables comme faire suivre un paquet IP.
]]>Routage (2.2) - Symfony
►http://symfony.com/fr/doc/2.2/book/routing.html
Documentation du système de gestion des « URL propres » de Symphony : configurable et utilisable pour gérer non seulement le routage mais aussi les actions à lancer
]]>RFC 6952 : Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide
Dans le cadre du travail du groupe KARP de l’#IETF, consacré à la sécurisation des protocoles de #routage de l’Internet, ce #RFC est consacré à l’analyse de la sécurité des protocoles de routage utilisant TCP, notamment #BGP.
]]>Tout le monde le sait, un des meilleurs moyens de casser ou de détourner l’Internet, c’est de pirater un ou plusieurs routeurs. Ceux-ci ne sont pas toujours gérés de manière très propre, question sécurité (il est vrai qu’ils n’incluent pas d’applications écrites en PHP ou VB.net...). Pour ceux qui font de l’OSPF, par exemple, une question à laquelle il faut répondre honnếtement : depuis combien de temps n’avez-vous pas changé les mots de passe OSPF ? Combien d’employés connaissant ces mots de passe ont quitté l’entreprise/l’association sans que les mots de passe soient changés ? La pénibilité de la gestion des mots de passe, pour les principaux protocoles de routage, fait que les bonnes pratiques de sécurité ne sont pas toujours suivies. Deux nouveaux RFC viennent d’être publiés :
RFC 6862 : Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements : le tour d’horizon des problèmes auxquels va s’attaquer le groupe de travail KARP de l’IETF (gestion des clés dans les routeurs) ▻http://www.bortzmeyer.org/6862.html
RFC 6863 : Analysis of OSPF Security According to KARP Design Guide : l’analyse d’OSPF selon la méthode publiée dans le RFC 6518 ▻http://www.bortzmeyer.org/6863.html J’y ai appris des choses, notamment qu’OSPF est sensible aux attaques par rejeu
#OSPF #routeur #routage #sécurité #maya2012 #RFC #IETF #KARP
]]>« 10Gbps Open Source Routing » de Bengt Gördén, Olof Hagsand et Robert Olsson. Excellent article sur les performances d’un PC/Linux comme routeur sur de l’Ethernet 10 Gb/s. Les auteurs ont mesuré le débit qu’ils arrivaient à faire passer par un PC du commerce. Conclusion : c’est faisable, mais pas avec toutes les cartes et tous les pilotes, il faut passer du temps à faire des réglages et, le coût par paquet étant important, ce débit n’est atteint que pour les paquets de plus de 256 octets.
Deux avantages à de tels routeurs : 100 % logiciel libre (contrairement aux Cisco et Juniper) et le prix (un routeur Cisco ou Juniper dans ces gammes de performance se compte en dizaines de milliers d’euros.
]]>RFC 6810 : The RPKI/Router Protocol
▻http://www.bortzmeyer.org/6810.html
Le protocole décrit dans ce #RFC fait partie de la grande famille des RFC sur la #RPKI, un ensemble de mécanismes permettant de sécuriser le #routage sur l’Internet. Il traite un problème bien particulier : comme la validation des annonces de route, potentiellement complexe en cryptographie, se fait typiquement sur une machine spécialisée, le cache validateur, comment communiquer le résultat de ces validations au routeur, qui va devoir accepter ou rejeter des routes ? C’est le rôle d’un nouveau protocole, #RTR ("RPKI/Router Protocol"), un protocole très simple.
RFC 6811 : BGP Prefix Origin Validation
▻http://www.bortzmeyer.org/6811.html
Il manquait un élément dans les normes de la sécurisarion du routage avec RPKI+ROA, une description de la façon exacte dont on valide une annonce #BGP lorsqu’on a des #ROA ("Route Origin Authorizations") pour ce préfixe. Ce RFC comble ce manque. Jusqu’à présent, en suivant les RFC, on pouvait distribuer des certificats authentifiant le titulaire d’un préfixe IP (la RPKI) et on pouvait émettre des autorisations, pour un AS, d’annoncer un préfixe (les ROA). Désormais, on peut utiliser RPKI et ROA pour avoir une solution de sécurité complète.
]]>Le #routage, enjeu de cyberstratégie | Lois des réseaux
►http://reseaux.blog.lemonde.fr/2012/11/04/routage-enjeu-cyberstrategie
Aujourd’hui, #Internet connaît deux problèmes politiques majeurs au niveau mondial : la sécurité et les modèles économiques des échanges entre les acteurs. Quand on analyse le fond des choses, on tombe forcément sur le fonctionnement du routage.
De plus, les États ont besoin de définir leurs cyber-stratégies. Or, mis à part les États-Unis, la Chine et une poignée de petit pays, les autres États commencent tout juste à appréhender les informations et les raisonnements nécessaires pour comprendre ce qui se passe dans les couches basses.
L’Internet est un réseau virtuel bâti sur du réel. C’est un nuage qui prend solidement ses assises dans du béton. Par ses fibres optiques, par ses satellites, par l’environnement politique, légal et économique, l’Internet présente des contraintes physiques, géographiques, économiques, politiques qui ont nécessité des investissements colossaux. La géographie de l’Internet, ce qu’on appelle la cyber-géographie est un enjeu majeur de la cyber-stratégie.
]]>Le routage, enjeu de cyberstratégie | Lois des réseaux
►http://reseaux.blog.lemonde.fr/2012/11/04/routage-enjeu-cyberstrategie
Aujourd’hui, l’Internet connaît deux problèmes politiques majeurs au niveau mondial : la sécurité et les modèles économiques des échanges entre les acteurs. Quand on analyse le fond des choses, on tombe forcément sur le fonctionnement du routage.
De plus, les États ont besoin de définir leurs cyber-stratégies. Or, mis à part les États-Unis, la Chine et une poignée de petit pays, les autres États commencent tout juste à appréhender les informations et les raisonnements nécessaires pour comprendre ce qui se passe dans les couches basses.
L’Internet est un réseau virtuel bâti sur du réel. C’est un nuage qui prend solidement ses assises dans du béton. Par ses fibres optiques, par ses satellites, par l’environnement politique, légal et économique, l’Internet présente des contraintes physiques, géographiques, économiques, politiques qui ont nécessité des investissements colossaux. La géographie de l’Internet, ce qu’on appelle la cyber-géographie est un enjeu majeur de la cyber-stratégie.
Il existe bien des zones de non-droits dans l’Internet (Salamatian préfère dire « zones grises ») mais elles ne sont pas là où le grand public pense qu’elles sont. L’interconnexion des domaines (routage) est l’enjeu de stratégies politique et commerciales. Ce peut être, à mon avis, un puissant moyen de contrôle ou d’influence de l’opinion. #Internet
]]>RFC 6693 : Probabilistic Routing Protocol for Intermittently Connected Networks
Les protocoles traditionnels de #routage (comme, mettons, OSPF) sont conçus dans l’idée que les machines sont connectées et joignables en permanence, sauf rares pannes. Mais il existe des réseaux où cette hypothèse ne se vérifie pas. Par exemple, dans l’espace, il est fréquent que la communication soit l’exception plutôt que la règle. Comment router dans ces conditions ? Ce nouveau #RFC propose un mécanisme de routage adapté à des connexions intermittente, #Prophet.
]]>