[FRnOG] [TECH] Le retour de la vengeance du fils du port 0
À la réunion Frnog 19, le 29 juin dernier, certains se sont étonnés des statistiques présentées dans le rapport de Nicolas Strina (Jaguar) Matthieu Texier (Arbor Networks) montrant plein d'attaques DoS sur le « port zéro ». De mémoire, il n'y avait pas eu de réponse pendant la réunion. Comme l'explique sur Nanog un gourou d'Arbor, c'est un artefact de Netflow, qui compte tous les fragments comme « port 0 ». Les attaques en question étaient probablement du DNS. --- Liste de diffusion du FRnOG http://www.frnog.org/ ---BeginMessage--- Frank Bulk frnk...@iname.com wrote: Unfortunately I don't have packet captures of any of the attacks, so I can't exam them for more detail, but wondering if there was some collective wisdom about blocking port 0. Yes - don't do it, or you will break the Internet. These are non-initial fragments. You or your customers are on the receiving end of DNS reflection/amplification attacks, and the large unsolicited DNS responses being used to packet you/them are fragmented. Use S/RTBH, flowspec, IDMS, and/or coordination with your peers/upstreams to block these attacks when they occur. Do *not* perform wholesale blocking of non-initial fragments (i.e., src/dst port 0), or you will have many unhappy customers and soon-to-be former customers. ; --- Roland Dobbins rdobb...@arbor.net ---End Message--- ---BeginMessage--- On Jul 25, 2012, at 12:08 PM, Jimmy Hess wrote: The packet is a non-initial fragment if and only if, the fragmentation offset is not set to zero. Port number's not a field you look at for that. I understand all that, thanks. NetFlow reports source/dest port 0 for non-initial fragments. That, coupled with the description of the attack, makes it a near-certainty that the observed attack was a DNS reflection/amplification attack. Furthermore, most routers can't perform the type of filtering necessary to check deeply into the packet header in order to determine if a given packet is a well-formed non-initial fragment or not. And finally, many router implementations interpret source/dest port 0 as - yes, you guessed it - non-initial fragments. Hence, it's not a good idea to filter on source/dest port 0. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ---End Message---
[FRnOG] Re: [TECH] Le retour de la vengeance du fils du port 0
On Thu, Jul 26, 2012 at 04:52:18PM +0200, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote a message of 15 lines which said: Sinon, si ceux ayant presente peuvent partager leur presentations, ca sera pas mal non plus. http://www.bortzmeyer.org/rpki-frnog.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Nouveau préfixe à filtrer : 0100::/64
RFC : A Discard Prefix for IPv6 http://www.bortzmeyer.org/.html Auteur(s) du RFC: N. Hilliard (INEX), D. Freedman (Claranet) Une technique couramment utilisée en cas d'attaque par déni de service est le *RTBH* : Remote Triggered Black Hole où la victime demande à son FAI, via un protocole, de jeter des paquets sur tel ou tel critère. On utilise pour cela les protocoles de routage standards comme BGP ou OSPF. Mëme chose lorsqu'un opérateur réseaux veut propager en interne, entre ses routeurs, la décision de jeter ou de rediriger tel ou tel type de paquets. Pour cela, il est bien pratique de disposer d'un préfixe IP spécial, qui désigne le trou noir (ou l'IDS, si on redirige le trafic vers un équipement d'analyse spécial). Il n'existait pas de tel préfixe pour IPv6, c'est désormais fait avec ce RFC, qui enregistre 0100::/64. Les RFC 5635 et RFC 3882 décrivent plus en détail cette idée de RTBH dans le cas d'une DoS. On sélectionne les paquets en fonction de leur adresse IP source ou destination et on les jette (trou noir) ou bien on les envoie (par exemple via un tunnel) vers un dispositif d'analyse. Pour configurer cela, il faut des adresses IP (plusieurs, car on peut avoir plusieurs traitements différents selon les attaques, donc une seule adresse IP ne suffit pas). Certains utilisent des adresses privées ou bien les adresses IP réservées pour la documentation (RFC 3849). Ce n'est pas très satisfaisant (et cela peut interférer avec les politiques de filtrage en interne, cf. section 2 du RFC) d'où le nouveau préfixe. Si on voit 0100::/64 dans la configuration d'un routeur, on sait désormais exactement ce que cela implique. Ce préfixe peut être propagé, à l'intérieur du réseau de l'opérateur, ou bien entre l'opérateur et ses clients, par les protocoles de routage dynamiques habituels comme OSPF. Il ne doit pas être transmis à l'extérieur et il est recommandé de le filtrer en entrée, sur les liens de peering ou de transit. Comme il sert pour gérer des attaques qui peuvent être de taille impressionnante, une fuite de ce préfixe vers un autre opérateur pourrait potentiellement entraîner un reroutage de l'attaque vers cet autre opérateur (sections 3 et 5 du RFC). Prudence, donc ! Ce préfixe 0100::/64 est désormais dans le registre des adresses IPv6 spéciales http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Les routeurs quantiques tendent vers l'infiniment petit
[Envoyé vers MISC et pas TECH pour des raisons qui seront évidentes à la lecture de l'article.] http://www.itespresso.fr/routeurs-quantiques-tendent-infiniment-petit-56115.html [...] Une méthode de superposition permettrait notamment de coupler aux données le bit de contrôle du routage, celui qui gère la redirection du trafic. Mais un frein s'impose à la lecture de ce bit : il est nécessaire de décomposer les paquets superposés et donc de les détruire, une solution préjudiciable à l'intégrité de l'information qu'ils contiennent. [Et ça continue pareil...] La prochaine fois que traceroute montre des trucs bizarres, je dirais que j'ai perdu le « bit de contrôle du routage ». --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Les routeurs quantiques tendent vers l'infiniment petit
On Mon, Sep 03, 2012 at 12:33:09PM +0200, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 25 lines which said: La prochaine fois que traceroute montre des trucs bizarres, je dirais que j'ai perdu le « bit de contrôle du routage ». Et l'article originel, beaucoup moins rigolo, http://arxiv.org/abs/1207.7265. C'est intéressant de chercher les pertes d'information entre cet article et celui d'IT Espresso (qui devrait plutôt s'appeler IT Cocaïne). Certaines des énormités de l'article d'IT Espresso étaient en effet en germe dans l'article originel. Bon, sinon, pour résumer l'article, très jolie expérience de physique mais qui n'a pas lien avec les réseaux informatiques, les auteurs sont manifestement d'excellents physiciens mais n'ont aucune idée de ce qu'est un routeur (bien qu'ils utilisent ce terme à tout bout de champ). --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
Je crois que c'est une question qui concerne directement les
opérateurs réseau (j'ai cité Free pour les exemples mais cela n'a rien
de spécifique à Free). Avis bienvenus.
http://www.bortzmeyer.org/que-pinguer.html
Lorsqu'on met en place une infrastructure de surveillance de serveurs
Internet, il est agaçant de recevoir autant d'alarmes que de serveurs
surveillés, alors que c'était simplement la connectivité Internet de la
sonde de surveillance qui était en panne. Tous les grands logiciels de
surveillance de réseau ont une option pour éviter cela, qui permet de
dire que le test d'un serveur dépend du succès d'un test sur un autre
composant, par exemple le routeur de sortie (si ce dernier est en
panne, il n'y a pas besoin de tester les serveurs et d'alerter si ça
rate). Mais quel composant tester pour déterminer qu'on a un accès
Internet qui marche ?
Avec les logiciels de la famille Nagios comme Icinga, l'option qui
permet d'indiquer la dépendance d'un test envers un autre se nomme
parents. Si on écrit :
define host {
host_name freebox
address 192.168.1.1
}
define host {
host_nameremote-host
parents freebox
...
}
alors on déclare que le test de remote-host
dépend de celui de freebox. Si on est connecté à
l'Internet par ce seul routeur, c'est logique. Si
freebox est injoignable, le reste de l'Internet
l'est aussi.
Mais si freebox fonctionne mais ne route plus
http://bugs.freeplayer.org/task/10258 ? Ou bien si quelque chose
déconne dans le réseau de Free bloquant tout accès à l'extérieur ?
C'est là qu'il est utile de tester autre chose que le premier routeur.
On voudrait en fait tester si on a toujours un accès Internet et
pouvoir écrire :
define host {
host_nameremote-host
parents Internet
...
}
Mais comment faire ce test ? En pinguant des
machines distantes, bien évidemment. Il « suffit » de sélectionner des
machines stables, qui répondent aux paquets
ICMP d'écho, et qui n'ont elles-mêmes que très
peu de pannes. Mais lesquelles choisir ?
Il faut bien voir que ces machines sur l'Internet, ces amers ou mires
http://www.bortzmeyer.org/amer-mire.html (target en anglais) ne
nous appartiennent pas. Si chaque petit réseau local, pour tester sa
connectivité, pingue 192.0.2.1 toutes les trois minutes, et qu'il y a
dix millions de petits réseaux qui le font dans le monde, 192.0.2.1
recevra 50 000 paquets/seconde, ce qui est une charge sérieuse même
pour un gros serveur. (En débit, cela ne fera pas grand'chose car les
paquets de test seront de petite taille. Mais pour les routeurs et les
serveurs, ce n'est pas que le nombre de bits par seconde qui compte,
celui des paquets par seconde est également important, chaque paquet
nécessitant un traitement, indépendemment de sa taille.) Utiliser le
premier serveur qu'on a choisi pour des tests répétitifs, c'est comme
jeter une canette vide par terre : si une seule personne le fait, c'est
juste un peu agaçant, si tout le monde le fait, on détruit
l'environnement. Ce n'est pas parce qu'un service est publiquement
accessible qu'on peut le bombarder de requêtes pour son usage
personnel. Dans le passé, il est déjà arrivé qu'un constructeur
configure (bêtement) ses machines pour utiliser un serveur public sans
autorisation, l'écroulant ainsi sous la charge
http://slashdot.org/story/06/04/07/130209/d-link-firmware-abuses-open-n
tp-servers.
Qu'est-ce que cela nous laisse comme possibilités ? En posant la
question, on obtient des réponses (plus ou moins dans l'ordre
décroissant du nombre de suggestions) :
* 8.8.8.8 (ou, à la rigueur, 8.8.4.4, qui est sans doute moins
sollicité), à savoir Google Public DNS
http://www.bortzmeyer.org/google-dns.html. Un service très fiable,
qui a très peu de chances de tomber en panne. Mais peut-on l'utiliser
ainsi, de manière automatique, dans des tests répétés ? Cela ne figure
certainement pas dans les conditions d'utilisation de ce service, et
Google pourrait donc décider de couper les réponses ICMP écho du jour
au lendemain (ou de mettre en place une limitation de débit).
* www.facebook.com (ou www.google.com) avec l'argument « Si Facebook
est en panne, de toute façon, tout l'Internet est fichu ». Cela pose un
peu les mêmes problèmes que précédemment.
* Pinguer un des serveurs DNS de la racine. Ils marchent en permanence
(c'est sans doute un des composants les plus robustes de l'Internet),
répondent à l'ICMP écho et, n'étant pas gérés dans un but lucratif, on
n'est pas à la merci d'un changement soudain de politique commerciale.
Mais ces serveurs ne sont pas prévus pour un tel test automatisé. Ils y
résisteront, bien sûr, mais est-ce un usage légitime ? Je ne pense pas
et les opérateurs des serveurs racine, interrogés, sont également de
cet avis. Il faut aussi se rappeler qu'il s'agit d'un service
critique : toute perturbation est à éviter.
* Pinguer des équipements du
[FRnOG] Re: [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
On Wed, Sep 05, 2012 at 11:03:27PM +0200, Fabien V. list-fr...@beufa.net wrote a message of 305 lines which said: _ping_._ovh_._net_ ? Je ne connaissais pas, merci. Il ne semble pas documenté. ta question soulève un autre point, es tu sûr de pinguer le bon host ? Parce que dans mon cas, je peux te dire de pinguer un site, ce ne sera pas pour autant le serveur qui délivre (cache ou front end) qui te répondra mais le load balancer Aucune importance : je ne veux pas tester si la mire marche, je veux tester si mon accès Internet marche. Si je teste www.arcep.fr et que c'est le load balancer situé devant qui répond, aucun problème. Perso, même si c'est pas dans les conditions d'utilisation, je continuerai à pinguer 8.8.8.8 et 8.8.4.4 pour test Puisque tous les abonnés à cette liste gèrent une infrastructure réseau, un test simple : que diriez-vous si des milliers de gens se servaient de *votre* infrastructure pour tester *leur* accès ? Je ne crains pas pour Google, ils sont assez grands pour se défendre seuls mais je ne suis pas sûr que l'approche « je m'en fous, je pingue ce que je veux, autant que je veux » soit bonne pour l'avenir de l'Internet. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
On Wed, Sep 05, 2012 at 11:12:10PM +0200, Sebastien WILLEMIJNS sebast...@willemijns.com wrote a message of 20 lines which said: vont t-ils apprécier un téléchargement régulier de données ? C'est un peu pour cela que je demandais sur une liste d'opérateurs réseaux... Que diriez-vous si c'était fait sur *vos* machines ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
On Wed, Sep 05, 2012 at 11:46:41PM +0200, Sylvain Vallerot sylv...@gixe.net wrote a message of 46 lines which said: On veut tester son accès à internet ? Alors on veut tester qu'on arrive bien jusqu'au coeur de son provider, Non, pas seulement, certaines pannes (rares, il est vrai, par rapport aux coupures du « dernier kilomètre ») sont entre le FAI et le reste du monde. c'est à dire typiquement le premier ou le deuxième hop après la passerelle qu'il nous a fournie (voire même ladite passerelle). Quand j'ai posé la question sur Twitter, un employé d'un gros FAI français a vigoureusement protesté contre l'utilisation des routeurs du FAI comme mires pour des tests automatisés, avec l'argument que les routeurs étaient faits pour router, pas pour répondre à Nagios. Et là forcément il n'y a pas de réponse qui tienne en un ping tout simplement parce que si un test binaire unique permettait de tester internet, alors internet ne serait pas internet. Merci, mais je connais un peu Internet, je suis au courant. En pratique, la majorité des pannes sont radicales : on n'a plus accès à rien. Un algorithme simple pour tester si on a toujours une liaison avec l'Internet est d'utiliser N mires et de dire « si M (avec M = N) mires répondent, c'est bon ». Cela permet aussi de traiter le cas où une mire est en panne. Des plugins Nagios comme check_cluster mettent en oeuvre cet algorithme. Enfin vérifier sa connectivité suppose que la notion de qualité, de neutralité, de stabilité, de latence... soit binaire ? Tiens, j'ai vu la même chose dans le groupe de travail ARCEP sur la mesure des performances de l'accès Internet : en pinaillant suffisamment, on peut faire dérailler n'importe quel projet de métrologie. Il s'agit ici de tester des pannes simples, genre de celle qui est citée dans mon article. Elles représentent la majorité. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
On Thu, Sep 06, 2012 at 12:39:15AM +0200, Steven Le Roux ste...@le-roux.info wrote a message of 209 lines which said: le check internet_www est un check_http vers www.google.fr le check internet_dns est un check_tcp(53) vers 8.8.4.4 ou 8.8.8.8 Et ce n'est pas un problème de se servir de Google pour cela ? Ce n'est pas le cours de leur action en bourse qui m'inquiète, c'est le principe « je me sers comme je veux des infras des autres, mais pas touche à la mienne ». --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
On Thu, Sep 06, 2012 at 11:01:33AM +0200, Guillaume Leclanche guilla...@leclanche.net wrote a message of 58 lines which said: Genre un des serveurs dns du tld d'un pays lointain? Alors là, je mets ma casquette d'opérateur d'un TLD et je crie NON ! Les serveurs DNS reçoivent assez de junk comme ça. Ce ne sont pas des mires publiques ! --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Detecter DDos outils et null-router sur quagga
On Thu, Sep 06, 2012 at 12:37:44PM +0100, Antoine Durant antoine.duran...@yahoo.fr wrote a message of 17 lines which said: J'aimerais connaitre les outils que vous utilisez pour détecter les attaques DDoS. L'AFNIC utilise DSC http://dns.measurement-factory.com/tools/dsc/ Sur un routeur linux quagga, comment vous faites pour null-router une IP qui est méchante iptables -A INPUT -s mé.ch.an.t -j DROP Test à faire : mesurer à partir de combien d'adresses filtrés ça devient insupportable. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Detecter DDos outils et null-router sur quagga
On Thu, Sep 06, 2012 at 02:51:52PM +0200, Emmanuel D. dupl...@gmail.com wrote a message of 40 lines which said: Pour le null-routing, au niveau du quagga : ip route a.b.c.d/32 null0 Ça ne marche que pour les paquets à *destination* du méchant. Lors d'une DoS, cela peut ne pas suffire (attaque en aveugle). mais je privilégierais l'iptables proposé par Stéphane, car il agit vraisemblablement à un niveau inférieur L'énorme avantage d'iptables (enfin, Netfilter) est surtout la souplesse : cela permet d'utiliser plein d'autres critères que la seule adresse IP. Ceci dit, pour des mesures anti-DoS, il n'y a qu'un seul critère de choix, la performance. Est-ce que les deux solutions tiennent lorsque l'attaque est vraiment méchante (en b/s ou surtout en p/s) ? Lorsqu'il y a des millions d'adresses à filtrer ? À tester. Pour la détection et le blocage de DDOS avec du libre / opensource, je suivrai le sujet avec attention :-) http://www.bortzmeyer.org/rate-limiting-dos.html http://www.bortzmeyer.org/rate-limiting-dns-open-resolver.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Detecter DDos outils et null-router sur quagga
On Thu, Sep 06, 2012 at 03:11:01PM +0200, Alain Thivillon a...@rominet.net wrote a message of 19 lines which said: iptables -A INPUT -s mé.ch.an.t -j DROP Sur un routeur comme demandé c'est plutot -A FORWARD , non ? Oui, tout à fait, je me fais régulièrement avoir, depuis l'époque où tous les paquets passaient par INPUT (même ceux qui n'étaient pas pour la machine locale). --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
On Thu, Sep 06, 2012 at 05:33:16PM +0200, Sarah Nataf sarah.na...@gmail.com wrote a message of 13 lines which said: Tu parles de ping, as-tu envisagé l'echo plus UDP ? Pour moi, c'est un détail. Le point important est « quelles machines peut-on pinguer ? » (Avec « pouvoir » s'interprétant sous l'angle technique, politique, juridique, financier, moral...) Si on a le « droit » de pinguer 8.8.8.8, je suppose qu'envoyer de l'UDP ne pose pas trop de problème. C'est amusant, d'ailleurs, la différence entre cette liste et dns-operations, où j'ai posé la même question. Les états-uniens ont tous répondu que se servir des machines des autres étaient immoral, les français ne se sont même pas posé la question. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
On Fri, Sep 07, 2012 at 01:38:45PM +0200, sola...@ultrawaves.fr sola...@ultrawaves.fr wrote a message of 33 lines which said: Les requêtes DNS vont d'abord chercher un enregistrement (IPv6). Si cet enregistrement n'existe pas, ils prennent l'entrée A (IPv4). Précisons que ce comportement est celui du « stub resolver » (en gros, la libc), par défaut (cela se règle, par exemple, sur Linux, /etc/gai.conf) http://www.bortzmeyer.org/5220.html Celà rajoute donc du délai de connexion en cas de panne de l'IPv6, Normalement, c'est réglé dans les applications sérieuses et modernes http://www.bortzmeyer.org/globes-oculaires-heureux.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Téléphones et paranoïa
On Sat, Sep 08, 2012 at 08:38:41PM +0200, Guillaume Barrot guillaume.bar...@gmail.com wrote a message of 39 lines which said: si il est équipé d'un GPS, n'importe quelle appli locale peut récuperer cette info, Nuançons : ça dépend du modèle de sécurité du téléphone. Sur Android, ce n'est certainement pas « n'importe quelle appli ». Ceci dit, les faiblesses des modèles de sécurité des smartphones, combinés avec la priorité donnée à l'« expérience utilisateur » et au manque de culture Sécurité des développeurs de smartphones fait que, en pratique, c'est en effet souvent le meilleur angle d'attaque. http://www.bortzmeyer.org/malware-iphone.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Téléphones et paranoïa
On Sat, Sep 08, 2012 at 08:22:39PM +0200, Maxence Rousseau mrouss...@ate.tm.fr wrote a message of 48 lines which said: Pas besoin d'être en comm évidemment, ta position étant toujours transmise aux cellules autrement tu ne recevrais pas d'appel entrant Le réseau n'a besoin que de la base la plus proche pour transmettre les appels. Cela ne donne pas une granularité suffisante pour toutes les applications (par exemple, si on veut envoyer un missile sur le propriétaire, il faut sa position à mieux que cinq kilomètres près.) Outre les différents trucs mentionnés ici en utilisant des possibilités peu connues de normes comme 3G, le plus simple, étant donné que d'ici peu, 99 % des téléphones auront un GPS, est encore de pirater le téléphone pour qu'il transmette sa position GPS... C'est du logiciel, et pas du meilleur. Donc, il y a de nombreuses failles de sécurité. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Téléphones et paranoïa
On Sun, Sep 09, 2012 at 02:40:17AM +0200, Henry GUNS acce...@free.fr wrote a message of 80 lines which said: mais il se trouve que l'envoi de message crypté sur le réseau GSM est soumis à une autorisation délivrée par les autorités militaires ou de police, Je suppose que ce n'est plus le cas en 3G (qui inclut lui-même des possibilités de chiffrement) ? Autrement, je vais avoir des ennuis avec le client SSH (ConnectBot) que j'utilise sur mon téléphone Android. donc si tu leur dis que tu vas crypter il y a encore plus de chance qu'ils t'écoutent Non, ils vont dire que ce terme n'existe pas en français :-) http://www.bortzmeyer.org/cryptage-n-existe-pas.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Téléphones et paranoïa
On Sat, Sep 08, 2012 at 08:33:07PM +0200, Guillaume Barrot guillaume.bar...@gmail.com wrote a message of 82 lines which said: Maintenant on peut toujours imaginer un virus permettant de faire ça, mais bonjour le code pour qu'il soit portable multiplateforme Pourquoi devrait-il être multi-plateformes ? Il y a, quoi, trois plate-formes à gérer (iOS, Android et peut-être Blackberry ou Windows Phone). Faire trois malwares est certainement moins de travail que d'en faire un portable... 1) - le code source d'Android etant publié, je pense qu'on aurait trouvé depuis longtemps les lignes de codes faisant ça; il faudrait donc sur ces téléphones installer une appli tierce. Il faudrait donc un acte volontaire. C'est une protection mais elle est loin d'être parfaite. Un peu d'ingéniérie sociale (« voyez la nouvelle version d'Oiseaux Pas Contents 3D ! ») et l'appli est installée. Bref, c'est très peu crédible (pour rester gentil et correct, pas dire direct que c'est de la science fiction). Euh, des trucs de ce genre se sont déjà faits et pas qu'une seule fois. http://scripting.com/stories/2010/11/15/theTechIndustryIsAVirus.html http://www.lemondeinformatique.fr/actualites/lire-soundminer-un-malware-espionne-et-vole-les-donnees-des-smartphones-android-32698.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Téléphones et paranoïa
On Sun, Sep 09, 2012 at 12:04:46AM +0200, Henry GUNS acce...@free.fr wrote a message of 103 lines which said: Dans des organisations de protection et de sécurité publique, les appels vocaux et la transmission des données via le réseau TETRA sont de par nature confidentiels et par conséquent protégés par un cryptage radio. Dans ces types de réseaux, les fonctions du sont assurées par l?option Static/Dynamic Air Interface Ecnryption. L'algorithme de cryptage (TEA 1 à 4) et les clés de cryptage doivent être fournis par l'utilisateur. C'est pour cela que l'utilisateur normalement prudent fera du chiffrement de bout en bout (les smartphones ont désormais largement assez de puissance pour cela). Et ne fera pas confiance à un algorithme « local ». Qui connait un client SIP pour Android avec chiffrement sérieux ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Detecter DDos outils et null-router sur quagga
On Sun, Sep 09, 2012 at 04:17:58PM +0200, Mohamed Touré mohamed.to...@secresys.com wrote a message of 100 lines which said: Des modules qui pourraient aider à contrer un DoS (qui ne sature pas forcément le lien upstream vers ISP), sont *ipset, recent*, *iplimit*, *condition, geoip*... Combinés ou non, ils peuvent donner de bons résultats. Et hashlimit ! http://www.bortzmeyer.org/rate-limiting-dos.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [ALERT] Panne SFR ? Courbevoie ? Ailleurs ?
Si personne n'en parle sur FRnog, c'est parce que tout le monde est occupé à réparer ou mitiger ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [ALERT] Go Daddy planté, une des plus grosses pannes dans le DNS
http://www.bortzmeyer.org/go-daddy-down.html Go Daddy est de loin le plus gros bureau d'enregistrement de .com et de nombreux autres TLD. Il sert aussi d'hébergeur DNS. Ce soir, tous leurs serveurs de noms sont injoignables, entraînant l'impossibilité de joindre des millions de noms de domaine, et donc les serveurs situés derrière. C'est l'une des plus grandes pannes qu'ait jamais connu le DNS. Elle illustre une nouvelle fois l'importance de s'assurer de la *résilience* de son service DNS, notamment par le biais de la *redondance*. Il est 19h00 UTC et la panne dure depuis déjà un certain temps (premier signalement sur la liste outages vers 18h00 UTC). Prenons un hasard un nom de domaine hébergé chez Go Daddy, 1stoptr.com. Tentons une interrogation : % dig A 1stoptr.com ; DiG 9.8.1-P1 A 1stoptr.com ;; global options: +cmd ;; connection timed out; no servers could be reached Pas de réponse. Qu'arrive-t-il aux serveurs de noms ? Demandons au parent (VeriSign) les serveurs de noms de 1stoptr.com : % dig @a.gtld-servers.net NS 1stoptr.com ; DiG 9.8.1-P1 @a.gtld-servers.net NS 1stoptr.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 38711 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;1stoptr.com. IN NS ;; AUTHORITY SECTION: 1stoptr.com.172800 IN NS wsc1.jomax.net. 1stoptr.com.172800 IN NS wsc2.jomax.net. ... ;; ADDITIONAL SECTION: wsc1.jomax.net. 172800 IN A 216.69.185.1 wsc2.jomax.net. 172800 IN A 208.109.255.1 Ces deux serveurs sont bien chez Go Daddy comme on peut le vérifier avec whois : % whois 216.69.185.1 # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=216.69.185.1?showDetails=trueshowARIN=falseext=netref2 # NetRange: 216.69.128.0 - 216.69.191.255 CIDR: 216.69.128.0/18 OriginAS: NetName:GO-DADDY-COM-LLC NetHandle: NET-216-69-128-0-1 Parent: NET-216-0-0-0-0 NetType:Direct Allocation ... Et ils ne répondent pas : % dig @216.69.185.1 A 1stoptr.com ; DiG 9.7.3 @216.69.185.1 A 1stoptr.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached Et, surtout, c'est la même chose pour tous les serveurs de noms de Go Daddy. Le domaine de l'hébergeur lui-même, godaddy.com n'est pas davantage accessible : % dig +nodnssec +nssearch godaddy.com ; DiG 9.7.3 +nodnssec +nssearch godaddy.com ;; global options: +short +cmd ;; connection timed out; no servers could be reached Et comme pas de DNS égal pas de Web, ni d'autres services, on voit l'ampleur de la panne... Que s'est-il passé ? À l'heure actuelle (19h30 UTC), on ne sait pas vraiment. Une personne se prétendant Anonymous a revendiqué l'action. Mais sans donner aucun détail technique, il est donc difficile de savoir si c'est vrai. Pourquoi Anonymous aurait-il attaqué Go Daddy ? Peut-être parce qu'ils aiment les éléphants http://www.huffingtonpost.com/2011/03/31/bob-parsons-godaddy-ceo-elepha nt-hunt_n_843121.html ? Ou parce qu'ils sont choqués des publicités de mauvais goût de Go Daddy, à base de pinups vulgaires en bikini ? Mais Go Daddy est aussi connu pour son soutien à SOPA (voir Wikipédia), et pour être un des hébergeurs les plus rapides à censurer ses clients lorsque le gouvernement ou l'industrie du divertissement le demande (voir l'affaire JotForm http://arstechnica.com/tech-policy/2012/02/secret-service-asks-for-shut down-of-legit-website-over-user-content-godaddy-complies/ ou celle de RateMyCop http://www.wired.com/threatlevel/2008/03/godaddy-silence/). Comme disent les policiers, il y a donc beaucoup trop de suspects... Autres articles : * GoDaddy's DNS Servers Down, Taking Thousands of Sites With It http://mashable.com/2012/09/10/godaddy-down/ * GoDaddy Outage Takes Down Millions Of Sites, Anonymous Member Claims Responsibility http://techcrunch.com/2012/09/10/godaddy-outage-takes-down-millions-of- sites/ Une amusante ligne de script shell pour détecter si un de vos sites Web dépend de Go Daddy (merci à climagic https://twitter.com/climagic/). À exécuter dans le répertoire où se trouve la config Apache : grep ServerName * | grep -io [a-z0-9-]*\.[a-z]*$ | \ sort -u | while read -r d; do whois $d | grep -q GODADDY echo $d; done # site check --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Annonces BGP / désagrégation de préfixe
On Mon, Sep 17, 2012 at 12:21:33AM +0200, Gille Fergusson gille.fergus...@gmail.com wrote a message of 22 lines which said: Non, SFR ne filtre rien, nous pouvons annoncer les blocs que nous souhaitons sans rien leur déclarer. Que SFR (votre opérateur) filtre ou pas, ce n'est pas le problème, ce qui compte, c'est ce que font les autres opérateurs. Imaginons que SFR accepte les /32 IPv4 et les transmette. Ils ne seraient quand même pas propagés car les autres les refuseraient. http://ris.ripe.net/ pour voir la propagation de vos annonces. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Annonces BGP / désagrégation de préfixe
On Mon, Sep 17, 2012 at 12:34:46AM +0200, Frederic Dhieux frede...@syn.fr wrote a message of 70 lines which said: sur Internet, le plus petit préfixe est /24. 1) En IPv4, le protocole du siècle dernier. En IPv6, heureusement, les /32 passent. 2) Il vaut mieux éviter des termes comme petit ou grand car il n'est pas clair qu'on parle de la longueur du préfixe ou bien du nombre d'adresses dans le préfixe. Plutôt plus spécifique ou moins spécifique. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Datacenter DC3 d'Iliad
Bon compte-rendu de visite, très détaillé : http://lafibre.info/datacenter/datacenter-dc3-diliad/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Annonces BGP / désagrégation de préfixe
On Mon, Sep 17, 2012 at 09:12:54AM +0200, Stefano Secci stefano.se...@lip6.fr wrote a message of 78 lines which said: Pour le long terme, suggérez à votre opérateur de déployer LISP Très long terme. Les RFC ne sont même pas sortis. Et je ne connais pas d'implémentation pour Juniper. Les opérateurs qui n'ont toujours pas été capables de déployer IPv6 arriveront à déployer LISP ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Maintenant qu'on a tous IPv6 et RPKI, déployons LISP (Was: Annonces BGP /
On Mon, Sep 17, 2012 at 06:48:29PM +0200, Jérôme Nicolle jer...@ceriz.fr wrote a message of 22 lines which said: maintenant qu'on peut plus avoir de PI IPv4, et sans autoriser de préfixes plus longs dans la DFZ, LISP est la seule façon de multihommer à peu près proprement une connectivité IPv4 pour un nouvel entrant. Donc, pour vendre de l'interco multi-opérateur haut de gamme, LISP et quelques accords entre ces opérateurs sont indispensables. Je me lance avant vendredi et je pose la question méchante. 1) Combien d'abonnés à cette liste ont LISP en production ? 2) Combien d'abonnés à cette liste ont un banc de test LISP avec au moins trois routeurs ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [ALERT] Perturbation Renater
Une partie des sites Renater est affectée. Ils ne peuvent plus joindre certains sites comme Météo France. Aucune nouvelle de Renater, apparemment. Pas de ticket. À noter que le problème ne touche que IPv4. Les sites non joignables en v4 et qui ont de l'IPv6 marchent. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [ALERT] Perturbation Renater
On Wed, Sep 19, 2012 at 04:48:49PM +0200, Emmanuel Lesouef e.leso...@crbn.fr wrote a message of 27 lines which said: Et rien dans le ticket sur l'origine de la panne... Pas même de clôture. Si, si : Historique : 19/09/2012 16:45:22 - Une sollution palliative a été mise en place. Les investigations sont toujours en cours. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Annonces BGP / désagrégation de préfixe
On Mon, Sep 17, 2012 at 06:48:29PM +0200, Jérôme Nicolle jer...@ceriz.fr wrote a message of 22 lines which said: LISP est la seule façon de multihommer à peu près proprement une connectivité IPv4 pour un nouvel entrant. Puisqu'on est vendredi, je recommenderais plutôt cjdns : http://cjdns.info/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] RFC 6707: Content Distribution Network Interconnection (CDNI) Problem Statement
Je suppose que pas mal de gens ici ont un CDN. Ceci devrait les intérersser. http://www.bortzmeyer.org/6707.html Auteur(s) du RFC: B. Niven-Jenkins (Velocix (Alcatel-Lucent)), F. Le Faucheur (Cisco), N. Bitar (Verizon) Aujourd'hui, les CDN sont partout. Ces serveurs munis de nombreux disques et disposés dans les réseaux des FAI, au plus près de l'abonné, afin de servir du contenu numérique le plus rapidement possible, sont derrière un grand nombre de sites Web (non, ce blog n'utilise pas de CDN) et derrière bien des fournisseurs de streaming. La plus connue des entreprises de CDN est Akamai mais il en existe bien d'autres. Et c'est là que le problème commence : il n'existe aucun mécanisme d'interconnexion des CDN. Chacun utilise ses protocoles spécifiques et pas question de les faire travailler ensemble. L'IETF a donc créé un groupe de travail, CDNI http://tools.ietf.org/wg/cdni, chargé de réfléchir à l'interconnexion des CDN. Ce RFC est le premier du groupe, et il essaie de définir le problème (les solutions viendront plus tard). L'extension massive des CDN est bien sûr liée à l'augmentation considérable du contenu numérique : présentations PowerPoint ennuyeuses, vidéos de chats mignons, communiqués de presse en PDF qui prennent plusieurs mégaoctets pour ne pas dire grand'chose, publicités débiles, webinars en haute définition et au contenu vide, etc. Sans le CDN, un site Web qui veut distribuer un fichier de N mégaoctets à M clients va voir N*M mégaoctets passer sur sa liaison Internet. Avec le CDN, le fournisseur de contenu (CSP dans le RFC pour Content Service Provider) n'aura à faire passer le contenu qu'une fois, vers le CDN. Le contenu sera ensuite distribué par les serveurs du CDN, situés typiquement chez les FAI (notez aussi que certains FAI ont leur propre CDN). Meilleure latence, meilleure résilience (attaques dDoS et flash crowds), meilleur débit, bref, tous les avantages. Aujourd'hui, les CDN ne coopèrent pas. Si un fournisseur de CDN est très présent en Europe et en Amérique, mais pas en Asie, un CSP client de ce CDN verra ses clients asiatiques mécontents. Pour les satisfaire, il devra signer un contrat avec un autre CDN, très présent en Asie. Il serait pourtant plus simple que le premier fournisseur de CDN puisse s'appuyer sur l'infrastructure du second et lui transmettre données et instructions. Mais, en l'absence de normes techniques pour l'interconnexion des CDN, cela n'est possible aujourd'hui que par des arrangements privés. C'est l'une des principales motivations pour la création du groupe de travail CDNI. L'idée est que, dans le futur, le premier fournisseur de CDN cité (celui qui est trés présent en Europe et en Amérique) aura juste à signer un contrat avec le second fournisseur et, techniquement, tout se passera tout seul, il utilisera le réseau du second sans que le fournisseur de contenu n'y voit rien. Avant d'attaquer la question de l'interconnexion, notre RFC 6707 précise qu'il vaut mieux connaître les CDN pour suivre. Si ce n'est pas le cas, il recommande la lecture des RFC 3040 qui décrit les composants d'un CDN, RFC 3466 et RFC 3570, les deux derniers étant le résultat du travail du précédent groupe de travail IETF sur les CDN. Le RFC recommande également la lecture de « A Taxonomy and Survey of Content Delivery Networks http://www.gridbus.org/reports/CDN-Taxonomy.pdf ». La section 2 de notre RFC précise les cas où il est intéressant d'interconnecter les CDN. À la raison donnée plus haut (permettra à des CDN de s'allier pour avoir une meilleure couverture géographique), s'ajoute le désir de permettre l'interconnexion des CDN que gèrent certains FAI : en se regroupant, ils pourraient former un CDN alternatif aux CDN indépendants des FAI comme Akamai. Il y a aussi des cas où un FAI a déployé plusieurs CDN spécialisés et souhaite après les regrouper. Enfin, un dernier scénario envisagé est celui où un CDN doit faire appel temporairement à un autre (suite à une grosse panne, par exemple) et doit le faire vite, sans programmer des scripts spécifiques. Mais qu'est-ce que veut dire « Interconnecter des CDN » ? Des essais ont déjà été tentés, montrant qu'il y avait des choses qui marchaient et d'autres qui étaient vraiment pénibles en l'absence de normes. La section 3 identifie quatre *interfaces* par lesquelles on voudrait connecter des CDN, et pour lesquelles il n'existe pas de normes : * Interface de contrôle du CDN, par laquelle on démarre et arrête le service, on indique les politiques suivies (« aucun contenu ne doit pas être distribué en dehors des États-Unis », par exemple), on déclenche la copie de contenu, on vire le contenu qui ne doit plus être servi, etc. * Interface de routage des requêtes du CDN, qui n'est pas le routage de la couche 3. Il s'agit ici de s'assurer que les requêtes des utilisateur seront routées vers un CDN et un seul
[FRnOG] Re: [TECH] Apres la fin du dernier /8 ipv4
On Fri, Sep 28, 2012 at 11:19:32AM +0200, Arnaud Fenioux afeni...@gmail.com wrote a message of 55 lines which said: Que va t'il se passer quand on ne pourra plus obtenir d IPv4? C'est déjà le cas depuis des années. J'ai quatre ou cinq machines IPv4 chez moi et je n'ai jamais réussi à obtenir de mon FAI plus d'une adresse. C'est étonnant que des gens prétendent découvrir la pénurie (tomber à court de *chiffres*) maintenant. Plus sérieusement, et concrètement on va se trouver dans le cas ou le client (eyeball) est v4 only et le serveur et v6 only, et c est pas le NAT64 qui va nous aider si je ne m'abuse... NAT64 aide dans le cas inverse. Celui que vous décrivez doit être couvert par un des innombrables RFC qui documentent les innombrables techniques de coexistence mais je ne trouve pas de référence tout de suite. -les LIR vont louer les PA qu'ils possèdent et on va se retrouver avec des PA annoncées a plusieurs transitaires -forte désagrégation et une DFZ avec bcp bcp plus de routes qu'aujourd'hui -fin du filtrage des préfix plus petits que /24 et annonce de tout petits réseaux /25 /26 et ? -vol d'ip : annonce par des AS peu scrupuleux d'IP non annoncées ne leur appartenant pas -vol d'ip : annonce par des AS peu scrupuleux d'IP déja annoncées... mais non tout le monde va utiliser RPKI + ROA ;) -début des gros problèmes Tout ceci est très probable. La pénurie ne fait pas ressortir les meilleures qualités de l'être humain, en général. Maintenant, comme il fait beau, je vais être optimiste : - les DSI qui, en 2012, n'ont toujours rien fait pour le déploiement d'IPv6 vont tous être mis à la retraite d'office, - leurs successeurs, jeunes et brillants et ayant appris IPv6 à la fac, vont déployer rapidement IPv6, - le bonheur va régner dans les globes oculaires, - IPv4 sera encore raconté à la veillée par les ingénieurs les plus anciens (« en ce temps-là, on n'avait encore que 32 bits pour une adresse IP ») et des fous furieux chez Google programmeront une pile IPv4 en Dart pour faire des démos sur des pages Web http://klabs.org/history/build_agc/ à l'usage des geeks nostalgiques. Trop optimiste ? - J'ai des PI/PA que je vends aux enchères, meme si les RIR ne l'autorisent pas, peuvent il l'empecher? Bonne question. IANAL. http://www.bortzmeyer.org/nettoyage-marais.html et, pour les zUSA http://www.internetgovernance.org/2012/09/22/its-official-legacy-ipv4-address-block-holders-own-their-number-blocks/. et dans ce cas, pour le client final : adieu le choix des transitaires, optimisation des flux, et projets ayant besoin d'un grand nombre d'adresses Et enfin la fin de ce dogme abominable de la neutralité du Net http://www.numerama.com/magazine/23847-orange-heureux-d-une-victoire-contre-le-dogme-absolu-de-la-neutralite-du-net.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Apres la fin du dernier /8 ipv4
On Fri, Sep 28, 2012 at 10:39:14AM +0100, Thomas Mangin thomas.man...@exa-networks.co.uk wrote a message of 51 lines which said: Le transfer d'IP est autorise par RIPE. Mais, semble-t-il, personne n'en a encore profité http://www.internetgovernance.org/2012/08/31/the-first-study-of-the-emerging-market-for-ipv4-numbers. Tu as vu les réserves d'IP chez les LIR / FAI ? Perso, je suis tranquille au moins pour 5 ans. Ah, c'est ce que les DSI disaient il y a 10 ans, pour justifier de ne rien faire sur IPv6. Dix ans ont passé, et le problème devient plus aigü. Vu le temps que prennent les migrations dans certaines boîtes, 5 ans, ce n'est pas trop. Les nouveaux réseaux sont ceux pour qui la penurie est la plus embêtante mais je suis sur que tu pourras trouver des FAI pour te donner un /22 pour moins cher que RIPE demandait l'année dernière comme cotisation. Le paradoxe, c'est que certains sont au contraire prêts à payer *plus* cher, juste pour ne pas avoir à supporter la bureaucratie des RIR http://seenthis.net/messages/84904 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Apres la fin du dernier /8 ipv4
On Fri, Sep 28, 2012 at 02:15:22PM +0200, Solarus sola...@ultrawaves.fr wrote a message of 18 lines which said: Oh que si, non seulement on peut faire passer de l'HTTP, mais toutes sortes de paquets IP. Laurent parlait de l'*opposé*, faire passer du DNS sur HTTP (pour simplifier la config des pare-feux, deux ports seulement ouverts et on a fini avec ce dogme absolu de la neutralité du Net). --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Apres la fin du dernier /8 ipv4
On Fri, Sep 28, 2012 at 01:53:36PM +0200, Frédéric GANDER fgan...@corp.free.fr wrote a message of 43 lines which said: ps : sur les 5 dernières années le %tage d'ipv6 baisse par rapport à l'ipv4 Des références plus détaillées ? Il y a des tas de façons de mesurer « le %tage d'ipv6 » et, vu de l'AFNIC, l'augmentation (des dans le DNS, des requêtes DNS reçues en IPv6) est constante. trolldiIl y en a surement qui vont tomber des nues comme lui : http://youtu.be/8OxIV7o6OCY /trolldi ps2: marche pas chez moi, ca saccade Depuis Free, c'est normal http://www.numerama.com/magazine/23787-youtube-trop-lent-chez-free-l-ufc-demande-a-l-etat-d-intervenir.html. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Apres la fin du dernier /8 ipv4
On Fri, Sep 28, 2012 at 01:05:59PM +0100, Thomas Mangin thomas.man...@exa-networks.co.uk wrote a message of 47 lines which said: La petite startup n'a pas besoin de PI, Je me méfie toujours lorsque les fournisseurs disent aux clients de quoi ils ont besoin (ou pas). --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Apres la fin du dernier /8 ipv4
On Sat, Sep 29, 2012 at 12:51:20AM +0200, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote a message of 15 lines which said: Oui, mais comme youtube () ca rame, ils essayent chez dailymotion (A). Pourtant, sur YouTube, il y a des bons films, comme le Nième pastiche de la Chute http://fr.wikipedia.org/wiki/La_Chute_(film,_2004)#Les_parodies_sur_Internet consacré à... IPv6 http://www.youtube.com/watch?v=8OxIV7o6OCY --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Apres la fin du dernier /8 ipv4
On Mon, Oct 01, 2012 at 05:03:33PM +0200, Sylvain Rochet grada...@gradator.net wrote a message of 44 lines which said: C'est légitime, ça permet de garantir l'unicité des adresses, le rêve et presque une nécessité lors de toute fusion/acquisition, surtout pour des si grands groupes. Tout à fait. Ajoutons que, aujourd'hui, renuméroter le réseau interne de Ford ou d'Apple pour un adressage RFC 1918 aurait un coup que je vous laisse estimer... Sur ce sujet, le RFC 5887 est à faire lire absolument par tous les yakafokoneurs http://www.bortzmeyer.org/5887.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Apres la fin du dernier /8 ipv4
On Mon, Oct 01, 2012 at 05:03:53PM +0200, Solarus sola...@ultrawaves.fr wrote a message of 20 lines which said: Ca sert à spéculer. [...] Donc ils les conservent sans s'en servir, Pure hypothèse. Les gens qui ont travaillé dans ces entreprises témoignent plutôt que ces adresses sont bel et bien utilisées en interne. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [BIZ] FAI pour un château dans village perdu en Provence ?
On Wed, Oct 03, 2012 at 06:21:59AM +0200, Jérôme Nicolle jer...@ceriz.fr wrote a message of 17 lines which said: T'as oublié de préciser le budget ! En nature le paiement vu le client ! --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] NATv6 dans Linux
On Fri, Oct 05, 2012 at 12:03:21AM +0200, Samuel Thibault samuel.thiba...@ens-lyon.org wrote a message of 14 lines which said: C'est désormais dans la branche principale, et donc dans le futur Linux 3.7 d'ici quelques mois: Il existait déjà une autre mise en oeuvre de NAT66 pour Linux http://nfnat66.sourceforge.net/. J'ignore pourquoi c'est celle-ci qui a été intégrée dans le noyau officiel. http://www.bortzmeyer.org/6296.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Re: Go Daddy planté, une des plus grosses pannes dans le DNS
On Mon, Sep 10, 2012 at 10:32:50PM +0200, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 144 lines which said: http://www.bortzmeyer.org/go-daddy-down.html Bon, c'était bien un problème de routeurs, de FIB et de route reflector. Go Daddy vient de publier une analyse technique très détaillé, qui semble cohérente et compatible avec les faits observés. http://inside.godaddy.com/inside-story-happened-godaddy-com-sept-10-2012/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] NATv6 dans Linux
On Fri, Oct 05, 2012 at 07:00:32PM +0200, Emmanuel Thierry m...@sekil.fr wrote a message of 28 lines which said: Le minimum legal c'est un /64 (un seul subnet) Euh... Peux-tu définir légal s'il te plait ? Les RFC ? Certainement pas, ils disent même le contraire : http://www.bortzmeyer.org/6164.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] NATv6 dans Linux
On Fri, Oct 05, 2012 at 06:49:46PM +0200, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote a message of 14 lines which said: Pour les ayatollahs c'est /48 ou rien. Malgré http://www.bortzmeyer.org/6177.html, je reste un ayatollah, barbu et fier de l'être. Mort à IPv4, IPv6 est grand (dans tous les sens du terme) ! --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] NATv6 dans Linux
On Mon, Oct 08, 2012 at 11:46:20AM +0100, Surya ARBY arbysu...@yahoo.fr wrote a message of 50 lines which said: C'est ce que je reproche à IPv6; c'est un foutoir innommable; IPv4 en devient plus simple car mieux maitrisé (un comble pour un protocole qui devait tout simplifier !) Pas du tout d'accord. D'ailleurs, je vais reformuler votre question : « Existe-t-il un endroit où on puisse trouver toutes les best practices IPv4 qui soient à jour ? » :-) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] NATv6 dans Linux
On Mon, Oct 08, 2012 at 12:37:06PM +0100, Surya ARBY arbysu...@yahoo.fr wrote a message of 56 lines which said: du natv6 (c'est dans le sujet de ce mail) - on nous avait pas dit que le NAT c'est nul et qu'il y en aura pas en ipv6 pasque y-en-a-plus-besoin ? Des tas de gens pensent cela. Des tas d'autres qu'il y a un vrai besoin pour du NAT66. C'est disponible techniquement, on verra si le marché est intéressé. Ceux qui n'aiment pas le NAT n'ont qu'à pas le déployer. un coup faut mettre des /64 pour les point-à-point, après des /127 et j'en passe... Si on veut un métier où les choses sont stables et où les best practices ne changent pas, il ne faut peut-être pas être opérateur réseaux... --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Le gage de sérieux est-il toujours Made in US ?
On Mon, Oct 08, 2012 at 03:35:40PM +0200, Dominique Lacroix d...@panamo.eu wrote a message of 32 lines which said: En ces temps où la cyberguerre est nulle part et partout, dans tous les pays on s'interroge sur ses fragilités et on tente de mettre ses sites critiques ^^^ Justement, http://elysee.fr n'est PAS un site critique. En cas de cybercrise, rien à f... qu'on ne puisse pas regarder les photos de Flanby. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] NATv6 dans Linux
On Mon, Oct 08, 2012 at 07:22:51PM +0200, Sylvain Vallerot sylv...@gixe.net wrote a message of 38 lines which said: Pour ce qui est d'être LIR, 150 euros HT/mois c'est pas la mer à boire De mon expérience avec deux LIR, ce n'est pas la cotisation qui coûte cher, c'est le temps passé à lire et à comprendre des papiers, puis à discuter avec le staff du NCC :-( À moins que tu bosses gratuitement, auquel cas je t'embauche :-) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] A votre avis ...
On Wed, Oct 24, 2012 at 05:14:26PM +0200, Jérémy Martin li...@freeheberg.com wrote a message of 29 lines which said: ... Combien faut-il de routeurs dans le monde pour générer 750 Mb/s de flood UDP avec du SNMP non sécurisé ? Bah, avec le DNS, on fait bien plus :-) http://blog.cloudflare.com/65gbps-ddos-no-problem --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
On Tue, Jan 17, 2012 at 10:19:49AM +0100, Sarah Nataf sarah.na...@gmail.com wrote a message of 47 lines which said: J'attends que Stéphane nous poste une synthèse de http://tools.ietf.org/html/draft-ietf-grow-va-06 http://tools.ietf.org/html/draft-ietf-grow-va-auto-05 http://tools.ietf.org/html/draft-ietf-grow-simple-va-04 Le RFC 6769 ayant été publié, c'est l'occasion de revisiter le dossier :-) http://www.bortzmeyer.org/6769.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Re: [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
On Thu, Oct 25, 2012 at 01:51:31PM +0200, Jérôme Nicolle jer...@ceriz.fr wrote a message of 50 lines which said: pourquoi donc le FIR aurait besoin d'une FIB ? Ca peut être un simple route-server, donc 100% logiciel, Ce cas ne semble pas couvert dans le RFC. Mais, oui, il me semble logique qu'un FIR qui n'est pas un routeur (juste un serveur de routes) va en effet se passer de FIB et donc ne rien y installer. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] zone .org
On Fri, Oct 26, 2012 at 05:15:08PM +0200, Gaël gag...@gmail.com wrote a message of 25 lines which said: Je recherche la liste des domaines .org déjà enregistrés, On peut l'avoir par le système Zone file access de l'ICANN http://www.icann.org/en/about/agreements/registries/org/appendix-03-08dec06-en.htm En fait, vous l'aurez deviné, c'est pour trouver un domaine non enregistré... Quelques whois avec les différentes hypothèses à tester ne suffit pas ? Je propose de l'hébergement à prix libre, et mon domain actuel est un .fr, donc pas super pour les non-francophones... Mais si, mais si, c'est super :-) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] zone .org
On Fri, Oct 26, 2012 at 05:57:25PM +0200, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote a message of 11 lines which said: Mass dig/nslookup/. par contre ca doit pas trop poser des problemes. Enregistré != publié dans le DNS... Par exemple, lundi dernier, culturecommunication.gouv.fr était enregistré mais pas publié. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] zone .org
On Fri, Oct 26, 2012 at 09:54:52PM +0200, Cyril Bouthors cy...@bouthors.org wrote a message of 21 lines which said: http://www.premiumdrops.com/zones.html Cf. ma réponse à Radu-Adrian Feurdean. Leur doc' dit bien : Just because a domain doesn't exist in the zone doesn't mean it's available. Zone files contain only domains with nameservers. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Il faut faire payer les clients ! (Et les contribuables, aussi)
« Le secteur peut retrouver une segmentation de l'offre, avec des tarifs plus élevés pour les offres plus rapides... » http://www.lefigaro.fr/medias/2012/10/28/20004-20121028ARTFIG00169-louette-les-telecoms-doivent-remonter-les-prix-pour-la-4g.php Après les pigeons, les vaches à lait enragées ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Rapport sur les sources de Mal, OVH fait son entrée dans le Top 10
Le rapport HostExploit 2012 sur les plus grandes sources de Mal de l'Internet http://www.bortzmeyer.org/hostexploit-2012.html Les gérants du groupe HostExploit http://www.hostexploit.com/ compilent un rapport régulier sur les plus grosses sources de Mal de l'Internet, c'est à dire les systèmes autonomes hébergeant le plus de centres de commande de botnets, le plus de serveurs de hameçonnage, envoyant le plus de spam... Un Who's who des acteurs de l'Internet, sous l'angle négatif. Dans le dernier rapport, numéroté Q32012, on note un nouveau n° 1 de ce classement, Confluence, et l'arrivée du français OVH dans le sommet. Avant de commenter ce rapport, il convient d'être prudent et de bien prendre connaissance de la méthodologie. Celle-ci est décrite dans une annexe au rapport (le rapport est fait en Word avec des couleurs et l'annexe en LaTeX...). En gros, HostExploit http://www.hostexploit.com/ utilise un certain nombre de sources qui listent des adresses IP qui ont participé à des comportements négatifs, comme héberger un serveur de malware, ou bien un serveur Zeus (voir le Zeus Tracker https://zeustracker.abuse.ch/). De l'adresse IP, on remonte à l'AS et au pays (cette dernière information étant moins fiable). Le tout est pondéré par la taille de l'espace d'adressage annoncé par l'AS (pour éviter que les petits AS hébergant proportionnellement beaucoup de Mal ne se glissent sous la couverture du radar.) Ces sources ne sont pas parfaites : tout n'est pas signalé, certains le sont à tort. D'autre part, malgré mon introduction sensationnaliste, il faut bien voir que le fait qu'un AS (donc, en pratique, un opérateur ou hébergeur) soit bien placé dans la liste ne signifie pas que c'est lui qui envoie du spam ou héberge du malware. Il peut être « victime » de ses clients. Des fois, c'est même encore plus indirect : un hébergeur loue des machines, un client en prend une, son site Web se fait pirater, un serveur de hameçonnage est installé dessus et l'AS de l'hébergeur va remonter dans le classement « source de Mal ». Alors, que contient le classement Q32012 http://www.hostexploit.com/blog/14-reports/3540-familiar-hosts-a-open-r esolvers.html ? Ce classement est peu stable : un opérateur envahi par des zombies va être mis sur des listes noires (et ne sera donc plus intéressant pour les maîtres des zombies) ou bien va prendre des mesures radicales (faire le ménage) et, l'année suivante, rétrogradera loin dans le classement. Cette année, l'AS 40034, Confluence, hébergé dans le paradis fiscal des Îles Vierges, arrive en numéro un du classement général (p. 9 du rapport). Coïncidence amusante, deux jours avant de lire ce dossier, je citais le cas d'un détournement de noms de domaine (l'affaire ben.edu), faite via une machine chez Confluence. L'AS 16276, le français OVH est numéro 4, en très nette progression. Si on regarde le type de Mal hébergé (p. 11), on note que Confluence fait surtout de l'hébergement de Zeus alors qu'OVH est nettement moins spécialisé, on y trouve de tout. Cela semble indiquer qu'il n'y a pas de choix délibéré d'OVH, ni même d'envahissement de ses serveurs par un méchant décidé : la raison du score d'OVH est plus probablement que beaucoup de ses clients sont nuls en sécurité, installent un LAMP sans rien y connaître, se font pirater via une faille PHP, et ne corrigent pas le problème même quand on leur signale. En attachant les AS à un pays (ce qui est parfois difficile, ainsi Confluence a été classé comme états-unienne malgré son adresse officielle aux Îles Vierges britanniques et, plus drôle, VeriSign a été classé aux Pays-Bas), on voit (p. 16) la Russie en numéro 1, ce qui ne surprendra guère, et le paradis fiscal de l'Union européenne en numéro 4. Grâce à OVH, la France est en huitième position. Si on classe les AS en prenant chaque cause de Mal séparement, on voit que, pour l'hébergement de serveurs CC, c'est l'AS 50465, IQhost, qui gagne, devant un autre russe. Pour le hameçonnage, les États-Unis prennent l'avantage avec l'AS 53665, Bodis. Confluence, on l'a vu, gagne nettement pour l'hébergement Zeus. Pour l'envoi du spam, les indiens sont loin devant avec le record chez l'AS 55740, Tata. Plus surprenant est le classement des AS où on trouve du malware (p. 26), car l'AS 26413, VeriSign et l'AS 15169, Google, se retrouvent dans les dix premiers. Le rapport ne propose pas d'explication. Et je vois mal comment dissimuler du code malveillant dans un Google document... Maintenant, qu'est-ce qui devrait être fait ? Un AS a évidemment intérêt à nettoyer ces sources de Mal. Sinon, il va retrouver ses adresses IP dans plein de listes noires dont il est très difficile de sortir http://www.bortzmeyer.org/pas-de-listes-noires-statiques.html. Certains AS ont manifestement choisi de rester dans le business de l'hébergement de délinquants et se moquent de leur réputation (ils sont dans le sommet du
[FRnOG] Re: [TECH] Rapport sur les sources de Mal, OVH fait son entrée dans le Top 10
On Wed, Oct 31, 2012 at 01:02:25PM +0100, o...@ovh.net o...@ovh.net wrote a message of 22 lines which said: (ça fait vendre de mettre ovh dans les url/subject ?) Mon blog me permet d'assurer ma retraite et, en effet, à chaque fois que je cite OVH, le trafic triple et les brouzoufs rentrent. oui si pas de dialogue, pas de serveur. si pas d'action, pas de serveur. sur spamhaus ça sera clean à la fin de la semaine (il reste 14 alertes). et les autres rbl c'est une question de 2 à 3 semaines. J'ai ajouté cette analyse à l'article. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Rapport sur les sources de Mal, OVH fait son entrée dans le Top 10
On Wed, Oct 31, 2012 at 02:57:04PM +0100, Fabien V. list-fr...@beufa.net wrote a message of 48 lines which said: vu que plus l'hébergeur self-service est gros, plus il a de chances d'avoir des machines dégueu' sur son AS Ah, là, il fallait lire mon article (et, encore mieux, le texte originel) qui explique pourquoi cet argument ne tient pas (autrement, c'est Chinanet qui serait numéro 1 partout, et OVH serait derrière Amazon EC2). Quand tu parles de Mal, Georges Senior Bortzmeyer, tu te rends compte que c'est grâce à ce genre de classement avec cette terminologie qu'on a explosé 2 fois la tête à Saddam, sans réels chiffres ? Il est pourtant prouvé qu'Octave stocke des armes de destruction massive dans un champ de betteraves dans le Nord. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Le routage, enjeu de cyberstratégie
http://reseaux.blog.lemonde.fr/2012/11/04/routage-enjeu-cyberstrategie/ Un interview de Kavé Salamatian, chercheur en réseaux, expliquant le routage, BGP, les AS, etc (vous connaissez déjà, je sais) et insistant que le fait que ces questions qui semblaient purement techniques ont une forte composante politique et stratégique. (Rafik Dammak me fait remarquer que c'est un effet WCIT : la renégociation en cours des accords internationaux sous l'égide de l'UIT fait qu'on se met à parler de ces questions de routage que l'ICANN, par exemple, a toujours soigneusement ignorées.) Des formules choc (« BGP est le gluant de l'Internet », « le syndrome de la mobylette pakistanaise », « [l'Internet est] un nuage qui prend solidement ses assises dans du béton »), et pas trop d'erreurs techniques (bon, je suis sûr que, sûr Frnog, quelqu'un trouvera à redire aux AS de 32 bits et, personnellement, le fait qu'il confonde DNS et noms de domaines - quand il prétend qu'on peut aller sur facebook.com sans le DNS - m'embête). Mais pas d'information inédite, rien de nouveau. Et, surtout, après les promesses du titre et du chapô, une grande frustration : aucune opinion politique exprimée, pas de ligne stratégique. L'auteur nous répète qu'il y a des enjeux politiques super-importants derrière le routage mais n'en expose aucun. Sa seule prise de position est qu'il faut réguler le peering (« une régulation mondiale pourrait poser les cadres d'une connectivité minimale » et « pour les problèmes de BGP hijack et autres attaques informatiques, il faudrait pouvoir recourir à un tribunal arbitral »). mais il ne dit même pas dans quel sens. Obliger les récalcitrants à peerer ? Au contraire, devoir faire approuver chaque accord de peering par le Haute Autorité de Régulation de l'Internet National ? PS : je ne suis pas d'accord avec son analyse du DNS. Certes, selon le modèle abstrait, le DNS est dans la couche Applications. Mais ce n'est pas une bonne façon de le décrire. Le DNS est une infrastructure, quelque chose qu'on ne voit pas mais qui est indispensable. Il est donc bien plus proche de BGP que des applications. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] zone .org
On Fri, Oct 26, 2012 at 09:54:52PM +0200, Cyril Bouthors cy...@bouthors.org wrote a message of 21 lines which said: Je recherche la liste des domaines .org déjà enregistrés http://www.premiumdrops.com/zones.html Un responsable juridique de nos collègues de .SE me fait remarquer que ce site promet les listes des domaines dans les ccTLD européens (comme .SE ou .FR) depuis... 2008. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Le routage, enjeu de cyberstratégie
On Mon, Nov 05, 2012 at 11:57:43AM +0100, Kavé Salamatian kave.salamat...@univ-savoie.fr wrote a message of 50 lines which said: Prenez en compte que 99.9% des décideurs stratégiques n'imagine même pas que cela puisse arriver. Euh, ils n'ont même pas lu le rapport ODRIF http://www.bortzmeyer.org/rapport-resilience-internet-france.html ? Si c'est le cas, en effet, tout va s'écrouler en décembre 2012. Blague à part, le détournement de YouTube par Pakistan Telecom, ce n'est pas vraiment un scoop... --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Le routage, enjeu de cyberstratégie
On Mon, Nov 05, 2012 at 10:54:54AM +0100, Kavé Salamatian kave.salamat...@univ-savoie.fr wrote a message of 122 lines which said: quand il prétend qu'on peut aller sur facebook.com sans le DNS - m'embête). Je ne pense pas avoir dit cela. Peut être c'est pas bien indiqué dans l'article. Facebook commence de façon expérimentale à retourner directement des adresses IP à la place d'URL dans son contenu HTML. N'étant pas sur Facebook, je n'avais pas vu cela. Par contre, pour aller sur facebook.com, le discours à la mode « le DNS ne sert plus » me laisse froid. (Oui, j'ai testé http://69.171.234.21/ et il redirige vers www.facebook.com. Sans DNS, rien ne marche.) J'expose des faits certes non-inédits. Si vous pensez que les problèmes que je décrit ne sont pas des enjeux politiques super-importants, alors c'est quoi les enjeux super-important :-). J'en expose quelqu'uns pas tous. Le BGP hijack, le marché de la connectivité inter-domaine. C'est quand même beaucoup de l'enfonçage de portes ouvertes il y a longtemps. Le piratage de préfixes via BGP, des zillions d'électrons ont déjà été massacrés pour en parler. Et la connectivité inter-domaine aussi, surtout quand on essaie de regarder YouTube depuis Free. (Cf. le récent très bon rapport ARCEP au Parlement sur la neutralité.) Si vous m'invitez à plancher devant une audience de geeks, je ferais bien évidemment un discours beaucoup plus spécialisé et je donnerai des enjeux concrets. Alors, là, je ne comprends plus rien. Les enjeux concrets sont uniquement pour les geeks ? Autant le lecteur du monde ne devrait pas être assommé avec BGP, LISP, RPKI, HIP, ILNP et MPLS, autant les enjeux concrets de ces techniques sont pour lui. Là, l'article publié dit « il se passe des choses super-importantes mais on ne vous dira pas lesquelles ». Regardez l'IGP à Bakou, on parle même pas de l'interdomaine. L'IGF, non, plutôt ? L'IGP a fait d'excellentes études, à la fois correctes techniquement et très accessibles au non-geek, sur le routage, l'allocation d'adresses, la sécurité, etc. Mais, cette semaine à Bakou, c'est l'IGF, la réunion la plus inutile de toute la gouvernance Internet (ce qui n'est pas peu dire). JE l'ai dit, c'est une erreur stratégique que de ne pas prendre en compte le DNS, mais vous en conviendrez le DNS est moins important que la connectivité. Or, on en parle largement moins :-). J'ai un biais personnel et professionnel à ce sujet :-) Ceci dit, à part les lecteurs de Frnog (qui croient que l'Internet a été construit pour faire des traceroute avec l'option -n), pour l'utilisateur normal, une panne du DNS est exactement équivalent à une panne de l'Internet. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Le routage, enjeu de cyberstratégie
On Mon, Nov 05, 2012 at 11:35:29AM +0100, Kavé Salamatian kave.salamat...@univ-savoie.fr wrote a message of 156 lines which said: En effet, la régulation ne permettra pas de supprimés le hijack de préfixe, mais l'absence de régulation, ne le permet pas aussi. Je suis très sceptique. En outre, comme Raphaël Maunier (« on commence à réguler pour avoir une petite adresse postale et bam, on doit demander la permission pour aller aux toilettes »), je constate que les États (Russie, Chine, USA de SOPA, France de LOPPSI et Hadopi) ne parlent de réguler que pour faire avancer des projets de censure au service de la dictature ou bien d'intérêts privés. Croire que ces États, qui paniquent devant la liberté et le partage, et ne savent que répéter « on ne peut pas laisser l'Internet sans régulation » se mettraient soudain à réguler pour le bien public, c'est d'une naïveté abyssale. Vous auriez dû étudier les sciences politiques plutôt que les réseaux :-) Comment se fait il qu'on puisse envoyer un courrier d'un point à l'autre du globe en utilisant des coupons postaux internationaux, mais qu'il n'existe pas de notion de peering minimal dans l'internet. J'en appelle à une régulation minimale, du genre garantie de connectivité minimale. La connectivité minimale existe. Quel problème essaie t-on de résoudre, au juste ? Pinguer n'importe quel A depuis n'importe quel B ? Cela marche déjà (en tout cas en IPv4, c'est moins bon en IPv6). Les réunions d'opérateurs français m'ont l'air beaucoup plus fermée que celles des states et ressemble plus à un club très select. Fermé ? Select ? Frnog ??? Je rêve... Vous m'invitez à participer à l'une de vos réunions ? Sur papier glacé et en relief, l'invitation ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Soyez un peu plus responsables !
http://questions.assemblee-nationale.fr/q14/14-9279QE.htm Il [le député] lui [la ministre de la Justice] demande en conséquence comment il compte enrayer les escroqueries dans les nouvelles technologies, responsabiliser davantage les FAI et opérateurs, [...] --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Free vs Google (doubleclick)
On Mon, Nov 05, 2012 at 08:35:20PM +0100, Jean Praloran jeanpr...@gmail.com wrote a message of 31 lines which said: On a constaté assez recemment chez nous des soucis de lenteur de chargement voir des pages qui ne se chargent pas Date et heure ? Ça peut être la faute des chinois, non, des mayas, non, des indonésiens. http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Le routage, enjeu de cyberstratégie
On Tue, Nov 06, 2012 at 01:11:32PM +0100, Kavé Salamatian kave.salamat...@univ-savoie.fr wrote a message of 59 lines which said: devient par ce biais plus rapide que les autres browser car il n'y a plus de resolution DNS. Pipeau. La résolution DNS de l'adresse renvoyée par Google, c'est moins de 10 % (dans le cas de cnn.com, moins de 1 %) des résolutions DNS nécessaires pour charger la page (c'est d'ailleurs pour cela que l'argument « pas besoin de DNS, il suffit de taper http://192.0.2.1/ » montre une profonde ignorance de HTML). --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Le routage, enjeu de cyberstratégie
On Tue, Nov 06, 2012 at 01:17:26PM +0100, Pierre Beyssac p...@fasterix.frmug.org wrote a message of 17 lines which said: Donc on est bien d'accord sur le fait que cela réclame des altérations substantielles dans le navigateur. On est bien d'accord que c'est du grand n'importe quoi. Mais cette théorie fumeuse ne provient pas de la technique : elle provient des gens de la gouvernance, qui ne sont pas satisfaits de la façon dont les noms de domaine sont gérés et qui voudraient croire qu'on peut s'en passer, résolvant (ah, ah) ainsi leur problème. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Le routage, enjeu de cyberstratégie
On Tue, Nov 06, 2012 at 01:18:01PM +0100, Francois Petillon fan...@proxad.net wrote a message of 28 lines which said: C'est techniquement possible, Même pas. Car il y a une autre erreur dans le raisonnement, c'est d'oublier à quoi sert le DNS. Son utilisation pour avoir des noms plus mémorisables n'est qu'anecdotique. Son rôle principal est de fournir de la stabilité http://www.bortzmeyer.org/pourquoi-le-dns.html. Google ne renverra pas d'adresses IP lors des résultats de recherche car cela casserait tous les liens qui ont changé d'adresse IP depuis le passage du GoogleBot. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Le routage, enjeu de cyberstratégie
On Tue, Nov 06, 2012 at 10:48:57PM +0100, Simon Morvan gar...@zone84.net wrote a message of 68 lines which said: Je saisis pas la question de respect mutuel. J'ai la nette impression que Kavé Salamatian ne connait pas l'Internet et voudrait qu'on l'invite aux réunions d'opérateurs, avec papier glacé pour l'invitation, qu'on lui paie le voyage et l'hôtel, et qu'on lui donne les données Netflow en sortant. Concernant les relations institutionnels vs. privé, on a quand même quasi systématiquement un talk de Stéphane que je classe tout de même plutôt dans la catégorie Universitaire que Opérateur privé. :-) La dernière fois que j'étais à un jury de thèse, j'étais classé « Industriel ». Dans un groupe de travail ARCEP, je suis « Société civile ». Et, parfois, je me retrouve « Gouvernement ». Cela illustre l'absurdité de ces classifications :-) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Le routage, enjeu de cyberstratégie
On Tue, Nov 06, 2012 at 09:19:22PM +0100, Kavé Salamatian kave.salamat...@univ-savoie.fr wrote a message of 59 lines which said: Tout cet l'arsenal légal n'a aucune valeur à l'international et pourtant c'est à l'international que ces attaques arrivent. Et alors ? Quelles sont les solutions ? Évidemment pas techniques. Une police internationale pouvant frapper où elle veut et quand elle veut ? Elle existe déjà, elle se nomme FBI + CIA + NSA + US Army. Mais le problème n'est pas spécifique à l'Internet, toute activité internationale a le même problème. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Le routage, enjeu de cyberstratégie
On Wed, Nov 07, 2012 at 10:30:53PM +0100, Eric Freyssinet eric.freyssi...@m4x.org wrote a message of 135 lines which said: En réalité c'est cet article de Numérama qui ne tient pas la route... Merci de confirmer que l'article est correct : il compare les peines *maximales* encourues pour différents délits. Pour la copie illégale (qui est dans « contrefaçon »), 3 ans. Pour les violences ayant entraîné une incapacité de travail inférieure ou égale à huit jours ou n'ayant entraîné aucune incapacité de travail, 3 ans aussi. C'est donc aussi grave de contrefaire que de tabasser quelqu'un. Après, j'espère bien qu'en effet, les juges fassent preuve de bon sens. Mais la loi communique aussi une échelle de valeurs et, là, elle est inquiétante. Il y aurait un problème en pratique si pour la contrefaçon d'un seul morceau de musique sur Internet des personnes étaient effectivement condamnées à trois ans de prison, mais ce ne sera jamais le cas. L'article de Numérama, à juste titre, regardait le texte de la loi et pas des promesses, qui ne sont pas forcément tenues. Un exemple typique est le Fichier national automatisé des empreintes génétiques, « vendu » comme ne devant servir qu'à des crimes graves (mais cela n'a pas été écrit dans la loi) et désormais généralisé. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Les RFCs sur le protocole réseau ILNP sont sortis
Je vous ai déjà embêté plusieurs fois avec les protocoles réseaux qui séparent l'identificateur d'une machine de son localisateur (contrairement à l'adresse IP actuelle, qui mélange les deux). Il existe trois de ces protocoles qui sont normalisés ou proches de l'être, un qui fonctionne dans les routeurs, en tunnelant le trafic (LISP, dont les RFC sont prêts mais bloqués par deux drafts auxiliaires pas encore publiés). Et deux qui ne fonctionnent que dans les machines terminales (pas besoin de toucher à votre infra) et sont considérés par leurs promoteurs comme les seuls « vrais » protocoles de séparation ID/Loc. Ce sont HIP et le nouveau ILNP, dont les RFC viennent de sortir. Par contre, si vous êtes impatients de déployer, notez que ILNP est le moins implémenté des trois. Pour l'instant, ces RFC sont surtout utiles au programmeur, à l'étudiant, au curieux. L'opérateur réseau devra attendre la prochaine phase pour tester ILNP. http://www.bortzmeyer.org/6740.html Auteur(s) du RFC: RJ Atkinson (Consultant), SN Bhatti (U. St Andrews) Le protocole ILNP vient d'être spécifié dans une série de neuf RFC, dont ce RFC 6740 est le point de départ, décrivant l'architecture générale d'ILNP. ILNP appartient à la famille des protocoles à séparation de l'identificateur et du localisateur http://www.bortzmeyer.org/separation-identificateur-localisateur.html. Ces protocoles visent à résoudre une limite fondamentale de l'Internet : l'adresse IP est utilisée à la fois comme *identificateur* (nommer une machine, par exemple pendant la durée d'une session TCP) et comme localisateur (indiquer son point d'attachement au réseau). Cette confusion rend certaines configurations, notamment le multi-homing et la mobilité, très difficiles. Ce n'est pas qu'ILNP soit le premier protocole à vouloir séparer ces deux fonctions. Avant de donner le feu vert à la publication de ces RFC, l'IESG a notamment examiné HIP http://www.bortzmeyer.org/hip-resume.html et LISP http://www.bortzmeyer.org/lisp-wg.html, avant de conclure qu'ILNP avait des caractéristiques suffisamment originales pour qu'il soit intéressant qu'il soit décrit dans des RFC. ILNP avait été choisi par les présidents du groupe de recherche Routage de l'IRTF comme étant la base des futurs travaux sur une meilleure architecture pour l'Internet (travaux décrits dans le RFC 6115). S'il faut le résumer en cinq points : * ILNP est défini comme une architecture abstraite, avec plusieurs concrétisations possibles. Celle décrite dans ces RFC est compatible avec l'Internet actuel (une autre, plus « table rase », serait possible). * ILNP fonctionne entièrement dans les machines terminales, les routeurs ne sont pas changés. * Chaque machine ILNP a au moins un Identificateur et au moins un Localisateur. En IPv6, ils sont indiqués dans chaque paquet (ILNP peut aussi tourner au dessus d'IPv4 mais c'est plus complexe.) * Pour trouver le Localisateur d'une machine qu'on veut contacter, la méthode standard est d'utiliser le DNS (ILNP repose nettement plus sur le DNS que ses concurrents). * Les changements de localisateur en cours de session sont faits par un nouveau message ICMP, Locator Update. Ces derniers sont sécurisés par un *numnique http://www.bortzmeyer.org/nonce.html*, nombre imprévisible envoyé au début de la session. Bon, après cette introduction rapide, voyons tout en détail. D'abord, pourquoi veut-on à tout prix séparer identificateur et localisateur ? Le mieux est de relire le RFC 4984 pour avoir tous les détails. Disons que l'actuelle confusion de l'identificateur et du localisateur est pénible pour : * La croissance des tables de routage : pour avoir des adresss IP stables, certains réservent du PI et l'annoncent dans la table de routage globale. * Le multi-homing : sans adresses PI, pas de moyen facile de gérer les adresses de ses fournisseurs d'accès. * La mobilité : changer d'endroit ou de fournisseur casse les connexions TCP en cours. Face à ces problèmes, des tas de propositions pour améliorer les mécanismes d'adressage et de nommage dans l'Internet ont été faites : RFC 814, RFC 1498, RFC 2101, RFC 2956 et bien d'autres. La conclusion était souvent la même : le mélange de fonctions d'identification d'une machine et de sa localisation dans le réseau est une mauvaise idée. Ces fonctions devraient être séparées. Il y a un petit poblème terminologique ici : les architectures où ces fonctions sont séparées sont parfois toutes appelées « séparation de l'identificateur et du localisateur ». Mais notre RFC adopte un vocabulaire plus strict. Il réserve ce terme de « séparation de l'identificateur et du localisateur » aux architectures (comme ILNP) où la séparation est faite dès le début (dans les machines terminales) et utilise le terme de « map and encapsulate » (qu'on trouve souvent abrégé en map-and-encap) aux architectures qui utilisent un tunnel pour transporter
[FRnOG] [TECH] RFC 6770: Use Cases for Content Delivery Network Interconnection
http://www.bortzmeyer.org/6770.html Auteur(s) du RFC: G. Bertrand (France Telecom - Orange), E. Stephan (France Telecom - Orange), T. Burbridge, P. Eardley (BT), K. Ma (Azuki Systems), G. Watson (Alcatel-Lucent - Velocix) Le groupe de travail CDNI http://tools.ietf.org/wg/cdni de l'IETF travaille à normaliser les interfaces entre CDN pour permettre à deux de ces systèmes de distribution de contenu de coopérer pour servir un client. Ce second RFC du groupe (le premier, le RFC 6707, décrivait en détail le problème à résoudre et l'état de l'art) rassemble trois études de cas, illustrant ainsi par ces scénarios l'utilité du travail du groupe. Un ancien effort de normalisation des CDN à l'IETF avait eu lieu, produisant des documents comme le RFC 3570, qui décrivait déjà des scénarios d'usage. Ce nouveau RFC remplace ce RFC 3570 ; la terminologie est notamment très différente et reprend celle du RFC 6707. Conjointement avec ce RFC 6707, il va servir de base au document « cahier des charges » du groupe de travail CDNI. Interconnecter des CDN offre en théorie de nombreux avantages : améliorer le vécu de l'utilisateur (temps de réponses plus courts, voir le RFC 6390) et diminuer les coûts pour l'opérateur (on n'utilise que le réseau interne au lieu des lignes extérieures) notamment. Mais, actuellement, chaque CDN fonctionne de manière indépendante des autres, ce qui fait qu'il n'est pas toujours possible de récolter ces bénéfices. Voyons les trois études de cas. D'abord (section 2), le cas d'un CDN qui a une couverture géographique insuffisante. Un opérateur de CDN est présent dans une région donnée (mettons l'Europe) mais ne peut pas fournir de service aux lecteurs en Asie ou en Amérique. Et imaginons un autre opérateur de CDN en Amérique qui n'a pas de présence en Europe. Les interconnecter permettrait au nouvel ensemble de servir les deux continents, sans que chaque opérateur n'ait eu à supporter d'énormes investissements. Un autre cas proche est celui où un FAI a construit un CDN en interne pour distribuer du contenu dont il a les droits. Un autre fournisseur de contenu a déjà un contrat avec un autre opérateur de CDN. Dans ce cas, le FAI va recevoir un gros trafic de la part de ce CDN, qui va saturer ses liaisons externes, alors que ce contenu pourrait être distribué plus efficacement par le CDN du FAI. Pour le FAI en question, il serait utile que cet autre CDN puisse s'interconnecter avec le CDN du FAI (section 2.3), afin d'améliorer les performances et de décongestionner les liens d'interconnexion. Deuxième étude de cas (section 3), celle où le CDN a une couverture géographique jugée suffisante mais des capacités trop petites pour la charge. Cela peut être à cause d'une énorme augmentation temporaire de la demande (effet Slashdot, dit aussi flash crowd) par exemple suite à un événement particulier. Cet événement peut être prévu - match de football à diffuser - ou imprévu. (Le RFC cite l'exemple de la vidéodiffusion du mariage d'une célébrité ; il est triste de penser que des technologies si sophistiquées servent à de telles conneries.) Le CDN menace alors de s'écrouler sous la charge. Appelons un autre CDN à son secours ! L'idée est que le gestionnaire du CDN trop petit va payer un autre CDN, s'interconnecter à lui, et que les deux CDN feront face ensemble à la charge. (Une autre solution serait d'agrandir le CDN, mais, avec l'interconnexion des CDN, on peut prendre des marges de dimensionnement moins importantes, sans pour autant perdre sa capacité de faire face à d'éventuels pics de trafic.) Une variante de ce cas est la résilience en cas de problème, par exemple une attaque par déni de service ou une panne massive d'une partie d'un CDN (section 3.2). S'interconnecter à un autre CDN permet alors de continuer à fonctionner. Actuellement, chaque CDN doit se débrouiller seul en cas de panne. Dernière étude de cas (section 4), celui où le CDN n'a, ni problème de couverture géographique, ni problème de capacité, mais un problème de fonctions : le client a des exigences techniques particulières que le CDN ne sait pas remplir. Par exemple, un CDN sert du contenu en HTTP mais un client réclame qu'une partie du contenu soit servie en HTTPS (qui, entre autres, nécessite des processeurs plus rapides, pour les calculs cryptographiques) qu'il ne sait pas faire. S'allier avec un CDN qui, lui, sait faire du HTTPS, permettrait de rendre le client heureux (en lui évitant de signer deux contrats). Autre exemple donné par le RFC (mais peu convaincant depuis l'échec ridicule de WAP), celui d'un client qui demanderait tout à coup un protocole de distribution qui soit spécifique aux engins mobiles, alors que le CDN habituel de ce client n'a pas mis en #339;uvre ce protocole. Et, bien sûr, exemple évident, un CDN qui serait toujours, en 2012, uniquement en IPv4 et à qui des clients réclameraient
[FRnOG] Re: [MISC] [MICHU] Trolldi / phénomène étrange Orange end-user
On Fri, Nov 16, 2012 at 04:23:23PM +0100, Emmanuel Thierry m...@sekil.fr wrote a message of 32 lines which said: D'ailleurs je suis étonné que Stéphane Bortzmeyer ne se soit pas fendu d'un mail précisant que les adresses RFC 1918 n'étaient pas faites pour faire du CGN ! :) Tout le personnel de l'AFNIC était absent pour un séminaire de très haut niveau https://twitter.com/mathieuweill/status/269548073859051520 donc pas de temps pour troller. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Décret sur les contrôles de sécurité par l'ANSSI
Le décret donnant à l'ANSSI le droit de vérifier notre sécurité (« yen a bien besoin, ma bonne dame », dirait Mme Michu) est sorti pendant que Frnog discutait du CGN qui n'est pas chez Orange : http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT26638421dateTexte=categorieLien=id DECRET Décret n° 2012-1266 du 15 novembre 2012 relatif au contrôle de la sécurité et de l'intégrité des installations, réseaux et services des opérateurs de communications électroniques Quelqu'un de doué en droit peut-il retrouver la définition d'« opérateur » dans ce contexte ? Orange est concerné, OK. OVH et Gandi sont-ils concernés ? Et quid d'autres acteurs (au hasard, ceux qui gèrent les noms de domaine ou bien les points d'échange) ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Décret sur les contrôles de sécurité par l'ANSSI
On Tue, Nov 20, 2012 at 02:20:36PM +0100, Alexandre Archambault aarchamba...@corp.free.fr wrote a message of 26 lines which said: Pour faire simple, opérateur = tout opérateur d'accès / transit / interco (IXP), que ce soit fixe, mobile, TDM ou IP, privé comme public. Donc d'Orange au FAI / hotspot associatif, Donc, FranceIX est concerné mais pas Gandi ou OVH (en tout cas pour l'activité d'hébergement de ce dernier), ni l'AFNIC. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Serveur DHCP et base SQL
On Fri, Nov 30, 2012 at 08:39:47AM +0100, Sebastien Maillet sebastien.mail...@covage.com wrote a message of 41 lines which said: Nous avons trouvé des solutions, mais celles-ci fonctionnent sur une gestion des adresses IP vs adresse MAC à travers un fichier texte. Etant donné les nombreuses modifications/ajouts prévu il me semble plus saint de travailler sur une base de donnée que sur un fichier texte. Je n'en suis pas du tout convaincu. L'ajout du SGBD ajoute un composant de plus, donc de la supervision en plus et des pannes en plus. Un cron qui transforme la base en texte et recharge le serveur DHCP me semble une solution plus fiable. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Patriot Act - Datacenter
On Wed, Nov 21, 2012 at 04:00:46PM +0100, Adrien Pestel pestoui...@gmail.com wrote a message of 17 lines which said: Une discussion entre collègue concernant l'hébergement de nos infras dans un Datacenter américain sur le sol français est-il soumis au Patriot Act ? Une analyse intéressante par Olivier Itéanu : http://ip.eurocloud.fr/2012/11/23/patriot-act-mythes-et-verites/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Les données du Conseil Régional de Bretagne chez Amazon ! (was [Patriot Act - Datacenter])
On Fri, Nov 30, 2012 at 03:59:49PM +0100, Pierre Col - p...@9online.fr p...@9online.fr wrote a message of 20 lines which said: http://www.letelegramme.com/ig/generales/regions/bretagne/bretagne-le-conseil-regional-confie-des-donnees-a-amazon-30-11-2012-1926142.php Je regrette surtout que, comme alternative tricolore à Amazon, l'article ne cite que deux projets vaporware de « cloud français » et pas les vrais acteurs qui ont du vrai cloud depuis longtemps (Gandi et OVH bien sûr, mais aussi des petites boîtes moins connues). --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] RFC 6789: ConEx Concepts and Use Cases
http://www.bortzmeyer.org/6789.html Auteur(s) du RFC: B. Briscoe (BT), R. Woundy (Comcast), A. Cooper (CDT) Premier RFC du groupe de travail CONEX http://tools.ietf.org/wg/conex de l'IETF, ce documentt expose les principes de bases du m�canisme de ��publication de la congestion�� (CONgestion EXposure). L'id�e est d'indiquer dans les paquets la congestion pr�vue, pour que les �quipements r�seaux puissent prendre des d�cisions appropri�es. Une fois normalis�e (ce RFC 6789 n'est qu'une toute premi�re �tape), ce sera une des nombreuses techniques permettant de g�rer la congestion dans les r�seaux TCP/IP et notamment l'Internet. Il n'y a pas encore de protocole normalis� pour cette ��publication de la congestion�� (les deux premiers utiliseront une option IPv6 et une option de TCP). Pour l'instant, notre RFC s'en tient � des usages�: � quoi cela pourrait servir. La congestion est clairement une des plaies du r�seau. La force de TCP/IP est de multiplexer la capacit� des liens au niveau des paquets et pas des circuits. Cela permet une utilisation bien plus efficace du r�seau. Mais cela ne cr�e pas magiquement de la capacit��: quand trop de paquets rencontrent trop peu de capacit�, la congestion survient. Elle se manifeste par des pertes de paquets (le routeur, n'arrivant pas � suivre, abandonne certains paquets), mais aussi par des retards (si les tampons du routeur amortissent la congestion, ils augmentent les d�lais d'acheminement), et par le marquage ECN (RFC 3168) de certains paquets. Le r�cepteur des donn�es est cens� d�tecter ces signaux (un trou dans la s�quence TCP, des RTT qui augmentent, les marques ECN) et il doit alors dire � l'�metteur de ralentir. Ce fonctionnement o� seules les machines terminales agissent (les routeurs interm�diaires, � part �ventuellement des marques ECN, n'ont pas grand'chose � faire, ils se contentent de router) est typique de l'Internet mais, dans certains cas, expos�s dans ce RFC, il est insuffisant. L'id�e de base de ConEx est que l'�metteur mette dans les paquet IP qu'il envoie des indications sur la congestion qu'on lui a signal�. Ainsi, des �quipements qui sont purement de niveau 3 sur le trajet peuvent �tre inform�s de la congestion (ECN les informe aussi mais ne concerne que les �quipements en *aval* du point o� est d�tect�e la congestion, cf. figure 1 du RFC). Ainsi, le r�seau pourra avoir une meilleure vision de la congestion, comptant les paquets qui vont rencontrer de la congestion aussi facilement qu'il compte aujourd'hui les paquets ou les octets. Pourquoi est-ce important de conna�tre les paquets qui vont circuler dans des parties du r�seau o� il y a congestion�? D�j�, cela a une importance �conomique�: un r�seau ne co�te pas plus cher qu'il soit utilis� ou pas. Un trafic qui emprunte le r�seau � un moment o� celui-ci est peu charg� ne co�te donc rien � l'op�rateur du r�seau. Par contre, la congestion co�te cher puisqu'elle est le signe qu'il faut sortir son carnet de ch�ques pour mettre � jour le r�seau, vers des capacit�s plus grandes. Ainsi, ConEx pourrait �tre une brique de base pour un syst�me qui p�naliserait uniquement les flots de donn�es qui contribuent � la congestion. La section 2 pr�sente en d�tail les concepts et la terminologie ConEx. D'abord, �videmment, la *congestion*. Tout le monde en parle mais il n'y a pas de d�finition rigoureuse et unique pour ce concept. Pour une analyse de ce terme, voir ��The Evolution of Internet Congestion http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_2009.pdf�� de S. Bauer, S., D. Clark et W. Lehr. Dans ConEx, la congestion est d�finie comme la probabilit� de perte de paquet (ou de marquage par ECN). Un autre effet de la congestion, le retard, n'est pas pris en compte (donc, ConEx ne mesurera pas l'effet du bufferbloat). Deuxi�me concept, le *volume de congestion*. Il s'agit du nombre d'octets perdus suite � la congestion. L'id�e est de rendre les �metteurs responsables�: envoyer 10 Go sur un lien congestionn� n'est pas la m�me chose que d'y envoyer quelques octets. Par exemple, si Alice envoie un fichier d'un Go sur un lien o� la probabilit� de perte est de 0,2�%, son volume de congestion est de 2 Mo. Si, plus tard dans la journ�e, elle envoie un fichier de 30 Go alors que la ligne, moins encombr�e, ne perd plus que 0,1�% des paquets, elle ajoutera 3 Mo � son volume de congestion (donc, 5 Mo en tout). L'un des int�r�ts de cette m�trique est qu'elle est tr�s facilement mesurable par un routeur�: il lui suffit de compter le volume total des paquets qu'il a d� jeter (ou marquer avec ECN, s'il utilise cette technique). C'est donc quasiment la m�me chose que les compteurs de volume actuels. Troisi�me concept important, la *congestion aval* (Rest-of-path congestion ou downstream congestion dans la langue de Van Jacobson). C'est celle que le flot de donn�es va supporter entre le point de
[FRnOG] [TECH] RFC 6789: ConEx Concepts and Use Cases
[Avec le bon encodage, cette fois, désolé] http://www.bortzmeyer.org/6789.html Auteur(s) du RFC: B. Briscoe (BT), R. Woundy (Comcast), A. Cooper (CDT) Premier RFC du groupe de travail CONEX http://tools.ietf.org/wg/conex de l'IETF, ce document expose les principes de bases du mécanisme de « publication de la congestion » (CONgestion EXposure). L'idée est d'indiquer dans les paquets la congestion prévue, pour que les équipements réseaux puissent prendre des décisions appropriées. Une fois normalisée (ce RFC 6789 n'est qu'une toute première étape), ce sera une des nombreuses techniques permettant de gérer la congestion dans les réseaux TCP/IP et notamment l'Internet. Il n'y a pas encore de protocole normalisé pour cette « publication de la congestion » (les deux premiers utiliseront une option IPv6 et une option de TCP). Pour l'instant, notre RFC s'en tient à des usages : à quoi cela pourrait servir. La congestion est clairement une des plaies du réseau. La force de TCP/IP est de multiplexer la capacité des liens au niveau des paquets et pas des circuits. Cela permet une utilisation bien plus efficace du réseau. Mais cela ne crée pas magiquement de la capacité : quand trop de paquets rencontrent trop peu de capacité, la congestion survient. Elle se manifeste par des pertes de paquets (le routeur, n'arrivant pas à suivre, abandonne certains paquets), mais aussi par des retards (si les tampons du routeur amortissent la congestion, ils augmentent les délais d'acheminement), et par le marquage ECN (RFC 3168) de certains paquets. Le récepteur des données est censé détecter ces signaux (un trou dans la séquence TCP, des RTT qui augmentent, les marques ECN) et il doit alors dire à l'émetteur de ralentir. Ce fonctionnement où seules les machines terminales agissent (les routeurs intermédiaires, à part éventuellement des marques ECN, n'ont pas grand'chose à faire, ils se contentent de router) est typique de l'Internet mais, dans certains cas, exposés dans ce RFC, il est insuffisant. L'idée de base de ConEx est que l'émetteur mette dans les paquet IP qu'il envoie des indications sur la congestion qu'on lui a signalé. Ainsi, des équipements qui sont purement de niveau 3 sur le trajet peuvent être informés de la congestion (ECN les informe aussi mais ne concerne que les équipements en *aval* du point où est détectée la congestion, cf. figure 1 du RFC). Ainsi, le réseau pourra avoir une meilleure vision de la congestion, comptant les paquets qui vont rencontrer de la congestion aussi facilement qu'il compte aujourd'hui les paquets ou les octets. Pourquoi est-ce important de connaître les paquets qui vont circuler dans des parties du réseau où il y a congestion ? Déjà, cela a une importance économique : un réseau ne coûte pas plus cher qu'il soit utilisé ou pas. Un trafic qui emprunte le réseau à un moment où celui-ci est peu chargé ne coûte donc rien à l'opérateur du réseau. Par contre, la congestion coûte cher puisqu'elle est le signe qu'il faut sortir son carnet de chèques pour mettre à jour le réseau, vers des capacités plus grandes. Ainsi, ConEx pourrait être une brique de base pour un système qui pénaliserait uniquement les flots de données qui contribuent à la congestion. La section 2 présente en détail les concepts et la terminologie ConEx. D'abord, évidemment, la *congestion*. Tout le monde en parle mais il n'y a pas de définition rigoureuse et unique pour ce concept. Pour une analyse de ce terme, voir « The Evolution of Internet Congestion http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_2009.pdf » de S. Bauer, S., D. Clark et W. Lehr. Dans ConEx, la congestion est définie comme la probabilité de perte de paquet (ou de marquage par ECN). Un autre effet de la congestion, le retard, n'est pas pris en compte (donc, ConEx ne mesurera pas l'effet du bufferbloat). Deuxième concept, le *volume de congestion*. Il s'agit du nombre d'octets perdus suite à la congestion. L'idée est de rendre les émetteurs responsables : envoyer 10 Go sur un lien congestionné n'est pas la même chose que d'y envoyer quelques octets. Par exemple, si Alice envoie un fichier d'un Go sur un lien où la probabilité de perte est de 0,2 %, son volume de congestion est de 2 Mo. Si, plus tard dans la journée, elle envoie un fichier de 30 Go alors que la ligne, moins encombrée, ne perd plus que 0,1 % des paquets, elle ajoutera 3 Mo à son volume de congestion (donc, 5 Mo en tout). L'un des intérêts de cette métrique est qu'elle est très facilement mesurable par un routeur : il lui suffit de compter le volume total des paquets qu'il a dû jeter (ou marquer avec ECN, s'il utilise cette technique). C'est donc quasiment la même chose que les compteurs de volume actuels. Troisième concept important, la *congestion aval* (Rest-of-path congestion ou downstream congestion dans la langue de Van Jacobson). C'est celle que le
[FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases
On Thu, Dec 06, 2012 at 04:57:34PM +0100, Michel Hostettler michel.hostett...@telecom-paristech.fr wrote a message of 400 lines which said: (1) La congestion est définie comme la probabilité de perte de paquet (ou de marquage par ECN. Lorsque le réseau est congestionné, on perd tout, on ne marque pas. Oui, c'est le terme traditionnel mais ce n'est pas la définition du RFC. Le marquage est issu du contrôle de conformité d'un trafic par rapport à un profil préalablement souscrit par le client. Non, il s'agissait là de marquage ECN http://www.bortzmeyer.org/3168.html (3) Un autre effet de la congestion, le retard, n'est pas pris en compte. Quel retard ? Si les tampons des routeurs sont de grande taille, un trafic intense ne va pas entraîner de pertes de paquets (tant que les tampons ne sont pas pleins), mais des retards (le paquet va attendre longtemps dans le tampon). C'est le phénomène parfois critiqué sous le nom de « bufferbloat » (car certains réclament des tampons plus petits). --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases
On Fri, Dec 07, 2012 at 10:30:48AM +0100, Michel Hostettler michel.hostett...@telecom-paristech.fr wrote a message of 56 lines which said: Je crains que la compréhension fine des mécanismes télécoms passe par le bon usage du français, Ben, c'est pas ce que j'ai fait ? Et comment dois-je prendre « traduction approximative et simplificatrice » ? Comme une critique ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases
On Fri, Dec 07, 2012 at 11:49:32AM +0100, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote a message of 26 lines which said: Pour moi la congestion c'est quand le *LIEN* (et non pas les buffers) est plein pendant assez longtemps. S'il y a deja plus de 2 paquets en attente dans les buffers, pour moi il y a congestion. À noter que ce n'est pas la définition adoptée par le groupe de travail CONEX de l'IETF, probablement parce qu'elle est plus difficile à mesurer en pratique. Mais ce n'est pas un problème. Contrairement à ce que laisse entendre Michel Hostettler, il n'y a pas UNE définition correcte de la congestion, chacun a la sienne. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 6789: ConEx Concepts and Use Cases
On Fri, Dec 07, 2012 at 11:00:03AM +0100, Michel Hostettler michel.hostett...@telecom-paristech.fr wrote a message of 36 lines which said: Dans la congestion d'une file d'attente, l'état pathologique se traduit par la perte de données. Ce n'est pas la définition du groupe de travail CONEX (puisqu'il inclut aussi le marquage ECN, pas seulement l'abandon de paquets). Et je me méfie de termes sensationnalistes comme « état pathologique ». Il n'y a rien de pathologique à jeter des paquets, c'est un mécanisme normal d'IP. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] le super nouveau standard sorti du WCIT
On Thu, Dec 06, 2012 at 06:08:28PM +0100, sxpert sxp...@sxpert.org wrote a message of 9 lines which said: http://cryptome.org/2012/12/itu-future-networks.pdf Le texte adopté est décrit là http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11566 mais je n'ai pas encore trouvé le moyen de le télécharger (apparemment perdu lors d'une mise à jour du site). --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] le super nouveau standard sorti du WCIT
On Fri, Dec 07, 2012 at 12:16:08PM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 15 lines which said: Le texte adopté est décrit là http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11566 mais je n'ai pas encore trouvé le moyen de le télécharger (apparemment perdu lors d'une mise à jour du site). Ah ben voilà, il suffit d'attendre : http://www.itu.int/rec/T-REC-Y.2770/en In force mais pas encore publié, c'est l'ouverture à la mode UIT. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] [iab-ch...@iab.org: Feedback Requested: Proposed IEEE RAC OUI Tier Restructuring]
Ceux et celles qui gèrent de gros datacenters seront peut-être intéressés par ce débat au sein de l'IEEE sur une réforme de la politique d'allocation des adresses MAC, notamment en raison de l'impact de la virtualisation. Il y a notamment l'idée de faire payer les adresses MAC à l'utilisateur (le datacenter) et plus au vendeur. --- Liste de diffusion du FRnOG http://www.frnog.org/ ---BeginMessage--- The IEEE Registration Authority Committee (RAC) has requested IETF feedback on a proposal for restructuring of the Organizational Unique Identifier (OUI) within the IEEE 802 Medium Access Control (MAC) Address. Information on the proposal is available here: http://www.ietf.org/iesg/ieee/20120725/RAC_Virtualization_July2012.pdf http://ieee802.org/secmail/msg15524.html Comments should be sent to Glenn Parsons gpars...@ieee.org and cc’d to i...@iab.org. ---End Message---
[FRnOG] Re: [MISC] [iab-ch...@iab.org: Feedback Requested: Proposed IEEE RAC OUI Tier Restructuring]
On Mon, Dec 17, 2012 at 12:41:38PM +0100, Jean-Tiare LE BIGOT j...@lebigot.net wrote a message of 26 lines which said: Pourquoi la virtualisation est-elle un problème ? Les MAC ne peuvent pas dépasser le lien local si ? La norme officielle dit que les adresses MAC globales doivent être... globales (et qu'elles ne doivent être attribuées qu'à du matériel, ce que les VM ignorent...). En pratique, bien sûr, il n'y a des problèmes que si deux adresses dans le même domaine L2 sont identiques. Si on n'utilise pas d'adresses globales, il faut veiller à faire respecter cette règle. Et c'est là que la virtualisation joue un rôle : des dizaines de milliers de machines peuvent coexister dans le même domaine L2... Difficile d'être sûr de l'unicité dans ce cas. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)
La question qui tue : qui ici est prêt à faire une réduction de tarifs à ses clients pour des applications « gentilles », qui utiliseraient cet algorithme LEDBAT pour ne pas charger le réseau ? http://www.bortzmeyer.org/6817.html Auteur(s) du RFC: S. Shalunov (BitTorrent Inc), G. Hazel (BitTorrent Inc), J. Iyengar (Franklin and Marshall College), M. Kuehlewind (University of Stuttgart) Alors que tant d'efforts de recherche ont été dépensés pour faire des réseaux informatiques et des protocoles qui permettent d'aller *plus vite*, d'attendre moins longtemps avant de voir la page d'accueil de TF1, le groupe de travail LEDBAT http://tools.ietf.org/wg/ledbat (Low Extra Delay Background Transport ) de l'IETF travaillait à un tout autre projet : un protocole de transport de données qui aille *moins vite*, de façon à être un bon citoyen du réseau, à n'utiliser celui-ci que lorsqu'il est vide et qu'on peut donc faire passer ses bits sans gêner personnne. Ce RFC décrit l'*algorithme* LEDBAT, un algorithme « développement durable ». LEDBAT n'est donc pas un protocole complet, mais un algorithme de contrôle de la *fenêtre de congestion*, ce mécanisme par lequel les protocoles de transport évitent de saturer le réseau. Le plus connu et le plus utilisé de ces mécanismes est celui de TCP (RFC 5681) et ses objectifs sont d'utiliser le réseau à fond et d'assurer une relative égalité entre les flots de données qui se concurrencent sur ce réseau. LEDBAT, au contraire, vise avant tout à *céder* la place aux autre flots, non-LEDBAT. Mais pourquoi diable voudrait-on être si généreux ? Cela peut être parce qu'on estime les autres flots plus importants : si je télécharge Plus belle la vie pendant que je passe un coup de téléphone via SIP, je souhaite que le téléchargement ne prenne pas de capacité si SIP en a besoin (c'est la différence entre applications d'« arrière-plan » comme le transfert de gros fichiers et d'« avant-plan » comme un coup de téléphone ou une session SSH interactive). Ou bien cela peut être pour profiter de réductions offertes par le réseau : après tout, un routeur ou une fibre optique ne coûtent pas plus cher à l'usage, que les octets circulent ou pas (contrairement à un autoroute ou une voie ferrée). Il serait donc logique que les transports « charognards », comme LEDBAT, qui n'utilisent la capacité réseau que lorsque personne n'en veut, reçoivent une récompense financière, par exemple une réduction des prix (parlez-en à votre FAI). Pour les détails sur les motivations de LEDBAT et les raisons pour lesquelles des technqiues comme le shaping ne conviennent pas, voir le premier RFC du groupe LEDBAT, le RFC 6297. Ici, je vais me focaliser sur l'algorithme spécifié par LEDBAT et qui répond au cahier des charges : céder la place le plus vite possible. Le principe de cet algorithme est simple : utiliser les variations du temps de voyage des paquets pour détecter l'approche de la congestion et refermer alors la fenêtre de transmission. TCP utilise essentiellement le taux de pertes de paquets comme indicateur (ou les marques ECN du RFC 3168). Les routeurs ayant des tampons d'entrée-sortie, lorsque la ligne de sortie est saturée, les paquets commencent à s'entasser dans ce tampon. Lorsqu'il est plein, le routeur jette des paquets (et TCP va alors réagir). On voit que l'augmentation du temps de voyage (dû au séjour dans le tampon) *précède* la perte de paquets. En réagissant dès cette augmentation, LEDBAT atteint son objectif de céder la place à TCP. (À noter qu'il existe des variantes de TCP qui utilisent également le temps de voyage comme indicateur de l'approche de la congestion, par exemple TCP Vegas, documenté dans « TCP Vegas: New techniques for congestion detection and avoidance http://www.cs.umd.edu/class/spring2010/cmsc711/vegas.pdf » de Brakmo, L., O'Malley, S., et L. Peterson, mais voir le RFC 6297 pour un tour d'horizon général.) Où est-ce que LEDBAT va être mis en œuvre ? Cela peut être dans un protocole de transport, par exemple comme une extension de TCP, ou bien dans l'application. LEDBAT est un algorithme, pas un protocole précis. Il peut être utilisé dans plusieurs protocoles, du moment que ceux-ci permettent l'estampillage temporel des paquets, pour que les deux machines qui communiquent puissent mesurer le temps de voyage (section 4.1). La section 2 décrit l'algorithme exact. LEDBAT a une fenêtre de congestion, notée cwnd qui indique combien d'octets l'émetteur peut envoyer avant un nouvel accusé de réception. L'émetteur met dans chaque paquet le moment où il a envoyé ce paquet. Le récepteur regarde l'heure, en déduit le temps de voyage (aller simple, puisque l'encombrement n'est pas forcément le même dans les deux sens, une mesure aller-retour ne servirait pas à grand'chose) et retransmet cette indication à l'émetteur. Lorsque celui-ci voit le temps de voyage
[FRnOG] [MISC] Rions un peu avec les Mayas
http://www.lepoint.fr/chroniqueurs-du-point/guerric-poncet/la-fin-du-cyber-monde-20-12-2012-1604398_506.php La fin du (cyber)monde On imagine l'Apocalypse avec du feu et des larmes. Et si c'était plutôt la fin d'Internet ? [...] En France, seuls cinq à dix bâtiments stratégiques contrôlent la quasi-totalité des télécommunications et de l'accès à Internet. Ces lieux appelés datacenters (centres de données) réunissent des milliers de serveurs qui desservent Internet. Les bâtiments banalisés sont sécurisés, leur accès est soumis à des autorisations très strictes. Ils font partie des infrastructures vitales de la Défense nationale et sont à ce titre surveillés d'un oeil plus qu'attentif par les autorités. [...] Lorsque le Japon avait été durement frappé en 2011, plusieurs câbles avaient été sectionnés, et l'île avait été presque coupée du monde pendant plusieurs jours. [L'auteur n'a manifestement pas lu les rapports techniqes précis sur les effets de ce tremblement de terre, comme l'excellent http://archive.psg.com/111206.conext-quake.pdf] --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)
On Fri, Dec 21, 2012 at 10:53:13AM +0100, Simon Perreault simon.perrea...@viagenie.ca wrote a message of 20 lines which said: La question qui tue : qui ici est prêt à faire une réduction de tarifs à ses clients pour des applications « gentilles », qui utiliseraient cet algorithme LEDBAT pour ne pas charger le réseau ? Es-tu sérieux? À moitié. L'idée te semble ridicule ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)
On Fri, Dec 21, 2012 at 11:12:38AM +0100, Simon Perreault simon.perrea...@viagenie.ca wrote a message of 21 lines which said: Quel serait l'incitatif pour l'ISP? Encourager les utilisateurs à adopter un algorithme qui charge moins le réseau. Techniquement, comment est-ce que l'ISP pourrait identifier les paquets utilisant LEDBAT? Bonne question. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] RFC 6821: Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality
Des rappels intéressants sur la sélection du pair en pair-à-pair : http://www.bortzmeyer.org/6821.html Auteur(s) du RFC: E. Marocco, A. Fusco (Telecom Italia), I. Rimac, V. Gurbani (Bell Labs, Alcatel-Lucent) Le trafic du pair-à-pair peut, on le sait, représenter une bonne part de l'activité d'un réseau, malgré les efforts de l'industrie du divertissement pour diaboliser cette technique. Il y a donc depuis plusieurs années de gros efforts de recherche pour optimiser ce trafic, notammment via l'amélioration de la *sélection des pairs*. Si je veux télécharger la saison 1 de Being human, et que trois pairs ont les données, auquel demander ? Le bon sens répond « au plus proche ». Mais le concept de « plus proche » est plus flou qu'il n'y parait, et, de toute façon, le logiciel pair-à-pair installé sur ma machine n'a pas forcément accès à toutes les informations nécessaires pour déterminer « le plus proche ». Il existe plusieurs solutions pour résoudre ce problème, mais notre RFC se penche plutôt sur le méta-problème : *la sélection des pairs améliore-t-elle les choses ?* Tellement de choses ont été dites à ce sujet que l'ingénieur ou l'étudiant débutant qui se penche sur l'optimisation du pair-à-pair peut avoir une impression de grande confusion. Ce RFC choisit donc l'approche « retours aux faits ». Parmi toute la littérature scientifique et technique existante, peut-on trancher sur la question de l'intérêt de la sélection des pairs ? Je préviens tout de suite que le titre de ce RFC, inutilement sensationnaliste, ne correspond pas à son contenu : le RFC ne dynamite pas de mythes, il examine un certain nombre de questions posées par la sélection des pairs et, pour chacune, en se basant sur des mesures ou des simulations déjà effectuées et publiées, fait une synthèse de leurs conclusions. A priori, l'intérêt de la sélection est grand : comme les machines, dans un réseau pair-à-pair, ne connaissent pas la topologie sous-jacente (elles ne savent pas si les pairs sont proches ou lointains, s'ils sont joignables par des liens de peering gratuits ou par du transit payant, etc), elles risquent de ne pas choisir le meilleur pair. Une des conséquences fâcheuses sera l'utilisation d'inter-connexions lointaines, au lieu de rester dans le réseau du FAI. Il est donc logique que cette idée de sélection « intelligente » des pairs ait fait l'objet de nombreux travaux (résumés dans le RFC 6029 ; sinon, voir les articles « Can ISPs and P2P systems co-operate for improved performance? http://www.sigcomm.org/sites/default/files/ccr/papers/2007/July/1273445 -1273449.pdf » d'Aggarwal, V., Feldmann, A., et C. Scheidler, ou « Taming the Torrent: A practical approach to reducing cross-ISP traffic in P2P systems http://www.sigcomm.org/sites/default/files/ccr/papers/2008/October/1402 946-1403000.pdf » de Choffnes, D. et F. Bustamante, ou encore « P4P: Explicit Communications for Cooperative Control Between P2P and Network Providers http://www.dcia.info/documents/P4P_Overview.pdf » de Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., et A. Silberschatz) et qu'un groupe de travail de l'IETF, ALTO http://tools.ietf.org/wg/alto, travaille entièrement sur ce sujet (voir ses RFC 5693 et RFC 6708). (À noter que j'avais fait un exposé sur ces techniques en 2010 http://www.bortzmeyer.org/thd-meilleur-pair.html.) L'évaluation de ces techniques n'est pas évidente, notamment de leur passage à l'échelle lorsque le réseau comprend des dizaines de millions de pairs. Notre RFC suit le schéma suivant pour synthétiser la littérature existante : * Décrire une croyance (un mythe, dit le RFC, terme très exagéré), * Lister les faits (études, mesures, simulations, etc) disponibles, * Discuter ces données, * Conclure à la véracité ou à la fausseté de la croyance. Naturellement, cette synthèse n'est valable qu'aujourd'hui : les progrès de la sciénce pourront changer les conclusions. Ah et, sinon, question terminologie, en l'absence d'une norme unique du pair-à-pair, ce RFC utilise largement le vocabulaire de BitTorrent (section 2), comme lee terme d'essaim pour désigner un groupe de pairs ayant les données convoitées. Place maintenant aux croyances et à leur évaluation. La première : « la sélection des pairs permettra de diminuer le trafic entre domaines ». Les différents essais ou simulations montrent des réductions allant de 20 à 80 % (la variation importante donne une idée de la difficulté à estimer cette réduction). 70 % pour la simulation de Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., et A. Silberschatz déjà citée. 34 % en sortie et 80 % en entrée pour les mesures du RFC 5632. Et jusqu'à 99,5 % si le trafic est fortement localisé (beaucoup de pairs dans le même domaine) selon « Pushing BitTorrent Locality to the Limit http://hal.inria.fr/inria-00534117/en/ » de Stevens Le Blond, Arnaud Legout et Walid Dabbous. Bref, cette
[FRnOG] [MISC] Fiche de lecture : Tubes: A journey to the center of the Internet
Les lecteurs de cette liste n'apprendront rien dans ce livre, je pense mais, si lors du réveillon de Noël, la mamie du Cantal ou le papy du Périgord demandent à vos grand-parents « et votre petit-fils, là, il fait quoi dans la vie au juste ? », ce livre peut être un début de réponse. Tubes par Andrew Blum chez Harper Collins 978-0-06-199493-7 http://www.bortzmeyer.org/tubes.html Contrairement à ce qu'on pourrait croire en prêtant attention aux niaiseries comme le discours sur le « virtuel » ou sur le « cloud », l'Internet n'est pas un concept évaporé. Il s'appuie sur de grosses et lourdes machines, qui sucent beaucoup d'électricité, et qui sont hébergées dans de grands bâtiments industriels. Ceux-ci sont connectés par des liens bien physiques, les ondes radio étant marginales. C'est cet enracinement physique de l'Internet que décrit Andrew Blum. L'auteur vivait autrefois dans l'ignorance de l'endroit où passait son trafic Internet. Il a eu son chemin de Damas lorsqu'un écureuil insolent a eu l'audace de ronger son accès Internet. Blum a alors compris la physicalité du réseau et est parti visiter la planète pour trouver les *lieux physiques d'Internet*. (Au passage, ceux qui aiment les écureuils et se demandent pourquoi une si charmante bête est peu aimée des professionnels du réseau doivent lire l'excellent article de Pierre Col http://www.zdnet.fr/actualites/la-faune-americaine-ennemie-d-internet-3 9764091.htm.) Car Blum regrette qu'on ne prête plus attention à cette physicalité : comme le dit Leonard Kleinrock, interrogé par l'auteur sur les lieux des débuts d'Arpanet, « Students no longer take things apart », on ne démonte plus les choses. À défaut de les démonter, Blum les visite. Il se rend dans plusieurs points d'échange et décrit de manière très vivante ces points d'interconnexion où bat le cœur du réseau. Il ne peint pas que l'état physique actuel mais aussi son histoire compliquée et conflictuelle. Le livre contient une passionnante histoire du célèbre MAE-East. Lorsque je travaillais au CNAM, c'était un endroit mythique et lointain où l'Internet, l'interconnexion des réseaux, même entre opérateurs français, se faisait. Dans le livre de Blum, on suit sa difficile naissance, mais aussi celle de son opposé Equinix. (Pendant que je lisais ce chapitre, j'ai appris la naissance d'un des tous derniers points d'échange créés, à Kinshasa, le Kinix http://www.ispa-drc.cd/kinix.ht.) Blum visite aussi DE-CIX, AMS-IX, le LINX (contrairement à ce qu'on lit parfois chez des amateurs de sensationnalisme, ces lieux n'ont rien de secret, puisque tout le monde s'y connecte) et suit les réunions de NANOG pour y entendre les mystérieures négociations sur le peering, les exposés des acteurs essayant d'encourager les autres à peerer avec eux, en se vendant et en vendant leurs abonnés comme s'ils étaient une marchandise (« I have eyeballs. If you have content, peer with me. », en utilisant le terme péjoratif de « globes oculaires » pour parler des abonnés, supposés être des consommateurs passifs et bêtes). On croise dans le livre des figures familières de ce genre de réunions comme Sylvie LaPerrière, qui vient de rentrer au Conseil d'Administration d'AMS-IX https://www.ams-ix.net/newsitems/69. Après les points d'échange, l'auteur se tourne vers les câbles sous-marins, par lesquels passent l'essentiel du trafic international. Ces câbles ne relient pas n'importe quels points. Comme « People go where things are », on s'installe là où il y a déjà quelque chose), la plupart de ces câbles atterrissent aux mêmes endroits où atterrissaient les fils du télégraphe, des lieux comme Porthcurno (un des meilleurs reportages du livre) ou 60 Hudson. Andrew Blum a même suivi l'atterrissage d'un nouveau câble de Tata, le WACS, au Portugal, encore un passionnant récit. Ces câbles ne sont pas posés n'importe où : la résilience de l'Internet dépend d'une répartition de ces liens à différents endroits, pour ne pas risquer qu'ils soient victimes du même problème, comme la fameuse panne de Luçon en 2006 où un tremblement de terre avait coupé plusieurs câbles d'un coup. (Au passage, si vous aimez les histoires de pose de câbles sous-marins, vous pouvez aussi relire l'excellent reportage de Neal Stephenson http://www.wired.com/wired/archive/4.12/ffglass_pr.html.) Après les points d'échange où se connectent les opérateurs, et les câbles qui les relient, où se trouve physiquement l'Internet ? Bien sûr dans les grands data centers où sont hébergées les données. C'est la troisième partie du livre. L'auteur revient sur le scandale de The Dalles, où Google était arrivé en terrain conquis, imposant même au maire de ne pas informer son propre conseil municipal sur les projets en cours. Et, alors que visiter les points d'échange et les stations d'atterrissage des câbles n'avait posé aucun problème au journaliste, il s'est par contre heurté à un mur en
[FRnOG] [MISC] France Culture : Data-centers : les ogres énergivores d'Internet
http://www.franceculture.fr/emission-le-choix-de-la-redaction-data-centers-les-ogres-energivores-d-internet-2012-12-25-0 Les data centers sont en quelque sorte les usines de l'ère numérique. A l'intérieur, des milliers de serveurs sollicités à chaque courriel envoyé, à chaque vidéo visionnée, à chaque requête sur un moteur de recherche. Les data centers font la preuve que numérique ne signifie pas dématérialisé, loin s'en faut. Aux Etats-Unis, certains data-centers de Google et Facebook ont une consommation électrique comparable à des villes comme Strasbourg ou Bordeaux. En France, ils consomment environ 9% de notre électricité. [...] --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Mieux que l'HADOPI, Free !
On Thu, Jan 03, 2013 at 05:52:55PM +0100, Jean Praloran jeanpr...@gmail.com wrote a message of 17 lines which said: http://www.numerama.com/magazine/24665-blocage-des-pubs-free-pete-un-cable.html On reparle de la neutralité un peu ? Sur les aspects techniques. Je vais vous décevoir, il n'y a pas de BGP dedans : http://www.bortzmeyer.org/free-adgate.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Mieux que l'HADOPI, Free !
On Sat, Jan 05, 2013 at 10:22:21PM +0100, MulX (Aymeric) m...@aplu.fr wrote a message of 35 lines which said: Sur ma Freebox v6 avec la vieux firmware 1.1.8 je vais sur cette page http://freebox-server/settings.php?page=net_dhcp (Rsx local - Serveur dhcp) et on peut choisir les serveurs DNS qui seront diffusé par DHCP Oui, merci, j'ai une Freebox depuis longtemps et je ne regardais que le panneau de http://portail.free.fr pas le panneau de contrôle de la Freebox elle-même, qui a en effet ces deux options. Merci, j'ai corrigé l'article. --- Liste de diffusion du FRnOG http://www.frnog.org/
