RE: [FRnOG] [TECH] Numericable L2TP
Totalement d'accord avec toi. J'ai l'expérience d'un client qui a voulu faire l'expérience vu le cout, il a en moyenne 5 MO voir parfois 30 MO, mais la qualité est totalement aléatoire, avec en cas de panne un rétablissement en fonction du soleil et de la température :) Leur offre Pro n'a de nom que le mot Pro, service IDEM. En conclusion, c'est bien pour une ligne de Backup. Bonne réception David Marciano 14, rue Crespin du Gast - 75011 Paris - France Tel : +33 (0)1 48 24 07 07 - Fax : +33 (0)1 48 24 07 08 Mail : dmarci...@adenis.fr -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Yoann Gini Envoyé : mardi 31 janvier 2012 11:19 À : Mario Valetti Cc : frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] Numericable L2TP Bonjour, Le 30 janv. 2012 à 17:29, Mario Valetti a écrit : Nous avons des connexions ADSL internet via Numéricâble. Sur ces lignes, nous avons demandé à notre provider des adresses IP statiques et apparemment la seule façon d'obtenir des adresses IP fixes est l'utilisation d'un tunnel L2TP. Petite précision à ce sujet puisque certains de mes clients utilisent Numéricable. Il existe une offre « pro » chez eux, pas spécialement plus chère et qui propose une IP publique fixe. Par contre il faut faire attention à une chose, Numéricable interdit contractuellement l'hébergement de serveur sur ses lignes, y compris avec l'offre « pro ». Il n'est pas inutile de rappeler au client que malgré le bas cout et la pseudo bande passante annoncée par ce FAI cela resta un opérateur fait pour madame Michu. Yoann --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Numericable L2TP
Le 31 janvier 2012 11:18, Yoann Gini yoann.g...@gmail.com a écrit : Bonjour, Le 30 janv. 2012 à 17:29, Mario Valetti a écrit : Nous avons des connexions ADSL internet via Numéricâble. Sur ces lignes, nous avons demandé à notre provider des adresses IP statiques et apparemment la seule façon d'obtenir des adresses IP fixes est l'utilisation d'un tunnel L2TP. Petite précision à ce sujet puisque certains de mes clients utilisent Numéricable. Il existe une offre « pro » chez eux, pas spécialement plus chère et qui propose une IP publique fixe. Par contre il faut faire attention à une chose, Numéricable interdit contractuellement l’hébergement de serveur sur ses lignes, y compris avec l’offre « pro ». Il n’est pas inutile de rappeler au client que malgré le bas cout et la pseudo bande passante annoncée par ce FAI cela resta un opérateur fait pour madame Michu… C'est terrible cela, même en usage dit pro, ce mode minitel FAI-Client. As-t'il droit d'envoyer du mail ? ou quelconques données montantes ? Les gros FAI de eyeballs se plaignent que leur traffic est déséquilibré, cela permettrait de ré-équilibrer les flux, d'autant plus sur des supports qui permettent de l'upload à des débits dépassant les 1M de BP Cdlt, -- PR --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Cherche client de SFR/Cegetel pour faire une requête DNS
Le numéro de série de la zone google.fr est actuellement
2012010600. Toutefois, il semble que les résolveurs DNS de SFR/Cegetel
annoncent 1475653, ce qui pourrait indiquer quelque chose de bizarre.
Quelqu'un a-t-il un compte dans SFR, pour faire un dig ou un drill
('dig SOA google.fr') et mettre le résultat (intégral, bien sûr) ici
ou sur un pastebin ?
Il n'existe quasiment pas de looking glass DNS, à part les
résolveurs ouverts, et je n'en ai pas trouvé ici.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
[FRnOG] Re: [TECH] Cherche client de SFR/Cegetel pour faire une requête DNS
On Wed, Feb 01, 2012 at 10:36:06AM +0100,
Stephane Bortzmeyer bortzme...@nic.fr wrote
a message of 16 lines which said:
Quelqu'un a-t-il un compte dans SFR, pour faire un dig ou un drill
('dig SOA google.fr') et mettre le résultat (intégral, bien sûr) ici
ou sur un pastebin ?
C'est bon, j'ai les infos, merci, SFR est prévenu.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] Cherche client de SFR/Cegetel pour faire une requête DNS
Bonjour,
; DiG 9.8.1 SOA google.fr
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 26922
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.fr.INSOA
;; ANSWER SECTION:
google.fr.7INSOAns1.google.com. dns-admin.google.com.
1475654 21600 3600 1209600 300
;; Query time: 36 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Feb 1 10:50:17 2012
;; MSG SIZE rcvd: 87
Le 1 février 2012 10:36, Stephane Bortzmeyer bortzme...@nic.fr a écrit :
Le numéro de série de la zone google.fr est actuellement
2012010600. Toutefois, il semble que les résolveurs DNS de SFR/Cegetel
annoncent 1475653, ce qui pourrait indiquer quelque chose de bizarre.
Quelqu'un a-t-il un compte dans SFR, pour faire un dig ou un drill
('dig SOA google.fr') et mettre le résultat (intégral, bien sûr) ici
ou sur un pastebin ?
Il n'existe quasiment pas de looking glass DNS, à part les
résolveurs ouverts, et je n'en ai pas trouvé ici.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
--
Vincent DOBA
文森特
---
Liste de diffusion du FRnOG
http://www.frnog.org/
RE: [FRnOG] [TECH] Cherche client de SFR/Cegetel pour faire une requête DNS
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de
Stephane Bortzmeyer
Envoyé : mercredi 1 février 2012 10:36
Quelqu'un a-t-il un compte dans SFR, pour faire un dig ou un drill
('dig SOA google.fr') et mettre le résultat (intégral, bien sûr) ici
ou sur un pastebin ?
Bonjour,
comme indiqué dans de précédents messages, il est également possible de joindre
les personnes en charge des DNS chez SFR à travers l'adresse support arobase
dns.sfr.net :)
Concernant le pb de la zone google.fr, il semble en effet que certains caches
aient une info pour le moins erronée ...
Avant de clearer les entrées, je vais essayer de déterminer d'où on a récupéré
ces infos ...
--
David Gavarret
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] Cherche client de SFR/Cegetel pour faire une requête DNS
Le Wed, 1 Feb 2012 11:00:57 +0100 GAVARRET, David david.gavar...@sfr.com écrit: Bonjour, comme indiqué dans de précédents messages, il est également possible de joindre les personnes en charge des DNS chez SFR à travers l'adresse support arobase dns.sfr.net :) Concernant le pb de la zone google.fr, il semble en effet que certains caches aient une info pour le moins erronée ... Avant de clearer les entrées, je vais essayer de déterminer d'où on a récupéré ces infos ... Bonjour, j'ai pas l'impression que cela ne touche que SFR. Sur mes résolveurs, j'ai les serial 2012010600 ou 1475656 selon le serveur. Est-ce qu'il sera possible d'avoir plus de détail sur l'origine du problème ? Google a propagé une mauvaise zone ? Bonne journée -- Laurent Papier - 03 88 75 80 50 Resp. système - SdV Plurimedia - http://www.sdv.fr/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Cherche client de SFR/Cegetel pour faire une requête DNS
On Wed, Feb 01, 2012 at 11:00:57AM +0100, GAVARRET, David david.gavar...@sfr.com wrote a message of 23 lines which said: comme indiqué dans de précédents messages, il est également possible de joindre les personnes en charge des DNS chez SFR à travers l'adresse support arobase dns.sfr.net :) Ce que j'ai fait, mais *après* avoir vérifié les infos. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Re : [FRnOG] [MISC] MegaUpload
Truc marrant, mais depuis peu, thepiratebay.org (droit US) renvoie sur thepiratebay.se (droit pas US). Comme quoi, le pirate apprend vite ! Apres, si le domaine en .org existe encore, même s'il renvoie sur un .se, il doit bien y avoir un moyen pour le FBI de toujours trouver une pirouette pour intervenir, non ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Re : [FRnOG] [MISC] MegaUpload
Eh bien le FBI pourra supprimer la redirection de piratebay.org. vers les serveurs de noms de Piratebay et les pointer vers les siens comme il le fait avec mégaupload. Par contre, les gens vont progressivement prendre l'habitude d'utiliser le .SE plutôt que le .ORG donc ça ne posera pas de problème. Si les gens ne sont pas au courant de la nouvelle extension, ils la trouveront facilement sur l'Internet. La seule chose potentiellement faisable serait d'indiquer des serveurs de noms pour le domaine piratebay.se. au niveau des serveurs racines situés aux États-Unis. En plus d'entrainer un sacré merdier et le développement de racines alternatives, cette méthode serait peu efficace. Si par manque de chance, je contacte un serveur racine aux É-U et que c'est la première fois que je résouds un nom de domaine suèdois, je pourrais toujours demander google.se pour me voir retourner les adresses des serveurs de noms suèdois qui sont sous juridiction suèdoise. Je demanderai ensuite tous les autres noms de domaine suèdois aux serveurs du registre suèdois jusqu'à ce que le TTL expire. En gros, c'est pas faisable. Il faudrait faire des trucs comme en France : empecher les résolveurs des FAI de résoudre ce domaine suèdois pour ceux qui l'utilisent, ou en méthode bien pire et portant atteinte à la couche réseau, ne pas router les IP associées à ce nom de domaine. Il existera de toute façon toujours un moyen de coutourner le problème. Le 2012-02-01 16:54, Guillaume Barrot a écrit : Truc marrant, mais depuis peu, thepiratebay.org (droit US) renvoie sur thepiratebay.se (droit pas US). Comme quoi, le pirate apprend vite ! Apres, si le domaine en .org existe encore, même s'il renvoie sur un .se, il doit bien y avoir un moyen pour le FBI de toujours trouver une pirouette pour intervenir, non ? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: Re : [FRnOG] [MISC] MegaUpload
Guillaume Barrot a écrit: Truc marrant, mais depuis peu, thepiratebay.org (droit US) renvoie sur thepiratebay.se (droit pas US). Comme quoi, le pirate apprend vite ! Le pirate savait déjà ça depuis des lustres. Apres, si le domaine en .org existe encore, même s'il renvoie sur un .se, il doit bien y avoir un moyen pour le FBI de toujours trouver une pirouette pour intervenir, non ? Pfff qu'est-ce que ça changerait ? Pour l'hypothèse (à laquelle je ne crois pas) admettons que le FBI arrive à bloquer le domaine sous .se, que se passerait-il ? 30 secondes après sur tweeter et fessebouc tout le monde aurait le nom du nouveau domaine. Et même sans tweeter et fessebouc ça serait pareil, le téléphone ça continuerait de marcher. Autant pisser dans un violon. Quoi que, ne pas sous-estimer la connerie incommensurable du FBI non plus, mais résultat des courses toujours le même. Faut pas faire l'amalgame entre MU et TPB, ce n'est pas du tout la même chose. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Sécurité du routage : RFC 6518: Keying and Authentication for Routing Protocols Design Guidelines
http://www.bortzmeyer.org/6518.html Auteur(s) du RFC: G. Lebovitz, M. Bhatia (Alcatel-Lucent) Dans l'ensemble du travail engagé pour améliorer la sécurité du routage sur l'Internet, un sous-problème important est celui de la gestion des clés. En cryptographie, c'est souvent par une faiblesse dans cette gestion que les systèmes de sécurité sont compromis. Le groupe de travail KARP http://tools.ietf.org/wg/karp de l'IETF est occupé à améliorer les protocoles de gestion de clés et son premier RFC, ce RFC 6518, expose les propriétés attendues des futurs protocoles de gestion des clés des routeurs. Prenons par exemple N routeurs OSPF qui veulent s'authentifier les uns les autres. La technique du RFC 2328 est d'avoir un secret partagé par tous les routeurs du même réseau local. Les messages OSPF sont concaténés avec ce secret, le résultat de la concaténation est ensuite condensé cryptographiquement, ce qui permettra au destinataire de s'assurer que l'émetteur connaissait bien le secret. Ce secret partagé est une clé cryptographique. Qui va la générer ? Comment la distribuer de façon sûre ? Comment la changer facilement et rapidement si le secret est compromis (ou, tout simplement, si un employé quitte l'entreprise) ? Ce genre de questions est la problématique de *gestion de clés*. Dans le cas d'OSPF, actuellement, la quasi-totalité des opérateurs de routeurs fait cela à la main (on se logue sur chaque routeur et on change le secret...) ou, à la rigueur, via un protocole général de configuration des routeurs. Peut-on faire mieux ? C'est en tout cas ce que va essayer de faire le groupe KARP. C'est que les mécanismes actuels ne sont pas satisfaisants. Comme le rappelle la section 1 du RFC, lors d'un colloque en 2006 (cf. RFC 4948), les participants avaient dénoncé la vulnérabilité des routeurs aux tentatives de prise de contrôle et appelé à durcir leur sécurité. Quatre axes d'amélioration avaient été identifiés, améliorer la gestion des routeurs (groupe de travail OPSEC http://tools.ietf.org/wg/opsec), améliorer les IRR, valider les annonces de route (groupe de travail SIDR http://tools.ietf.org/wg/sidr), et enfin sécuriser les communications entre routeurs (groupe de travail KARP http://tools.ietf.org/wg/karp), ce qui fait l'objet de ce RFC. Les informations de routage sont échangées via un protocole et la protection de ce protocole se fait par la cryptographie. Qui dit cryptographie dit clés. Lorsqu'un routeur cherche une clé pour protéger un message, où demande-t-il ? Pour l'instant, il n'y a pas de mécanisme standard et KARP va essayer d'en développer un. Le plus courant aujourd'hui est la gestion manuelle des clés (l'opérateur configure les clés, les change à la main - lorsqu'il y pense, les communique via PGP, SCP voire sans aucune sécurité) mais le RFC estime que le futur est dans des mécanismes automatisés de gestion de clés, les *KMP* (pour Key Management Protocol). Un KMP, par exemple, change automatiquement les clés au bout d'une période pré-définie. Compte-tenu de la variété des protocoles de routage, et du transport qu'ils utilisent, ce sera un mécanisme abstrait, pas un protocole précis (ce RFC 6518 n'a donc pas d'implémentation, il définit juste un cadre). Plus précisement, KARP va concevoir les interfaces abstraites entre le système de gestion de clés et le protocole de routage, puis, pour chaque protocole de routage, la correspondance entre cette interface abstraite et le protocole réel. Un projet ambitieux. Maintenant, au boulot. Qu'est-ce qui est déjà fait dans ce RFC ? La section 2 classe les protocoles de routage selon leurs propriétés. L'idée est que les protocoles de routage qui partagent les mêmes propriétés pourront, avec un peu de chance, utiliser les mêmes mécanismes de gestion de clés. Première propriété, le type de message. Certains protocoles sont de type un-vers-un : les messages d'un routeur sont envoyés à un autre routeur. Les UPDATE BGP (RFC 4271) fonctionnent ainsi. Mais c'est aussi le cas de LDP (RFC 5036), de BFD (RFC 5880) et même d'OSPF (RFC 2328 dans certaines conditions (liens point -à-point). D'autres protocoles fonctionnent en un-vers-plusieurs. Un routeur diffuse sur le réseau local l'information de routage. C'est le mode de fonctionnement le plus courant d'OSPF et c'est aussi celui de RIP (RFC 2453). Enfin, il y a les protocoles utilisés pour le multicast. Deuxième propriété pour classer les protocoles de routage, proche de la précédente mais pas identique, le fait que la clé soit par groupe ou par pair. Dans BGP ou LDP, les clés sont individuelles, on a une clé différente par pair. Dans OSPF, la clé est la même pour tous les pairs d'un groupe. La section 3 liste ensuite les points auxquels il faut penser lorsqu'on envisage un protocole de gestion de clés, un KMP. Le RFC 4107 fournit les bases générales et notre RFC l'adapte aux
