Re: [FRnOG] Re: [TECH] La longue marche de la sécurité du routage Internet : une étape importante, RPKI+ROA
On Sat, 4 Feb 2012 21:54:35 +0100, Stephane Bortzmeyer bortzme...@nic.fr said: On Sat, Feb 04, 2012 at 07:21:30PM +0100, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote a message of 28 lines which said: Un route plus precise, sans alternative, sans ROA, voir avec ROA invalide, ca passerait mieux qu'une lettre a La Poste. C'etait le cas avec YouTube + PakTel. Je ne comprends pas. Du temps de YouTube-PakistanTelecom, la RPKI n'existait pas. Aujourd'hui, si les routeurs BGP validaient les ROA (un très gros si) et si YouTube avait émis un ROA pour ses préfixes (un autre si), alors, l'attaque PK serait bien été détectée et bloquée. Le fait d'être sur un préfixe plus spécifiqe n'aurait rien changé (attribut maxLength du ROA http://www.bortzmeyer.org/6483.html). Donc 1 des 2: - soit avec l'implementation des RPKI il y aura aussi du code pour detecter des more specific (a voir) - soit l'attaque PakTel aurait marche de toute facon (puisque base sur une annonce unique plus precise) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] La longue marche de la sécurité du routage Internet : une étape importante, RPKI+ROA
On Mon, Feb 06, 2012 at 09:45:25AM +0100, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote a message of 27 lines which said: - soit avec l'implementation des RPKI il y aura aussi du code pour detecter des more specific (a voir) La question ne se pose pas : c'est dans la norme (RFC 6483, section 2 and the route's address prefix is a more specific prefix of the ROAIPAddress). Et toutes les implémentations actuelles le font. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] Règles d'enregistrement dans .FR
On Sat, 4 Feb 2012 17:30:51 -0800, Michel Py mic...@arneill-py.sacramento.ca.us said: Question naïve: est-ce qu'une lettre recommandée avec AR ne suffirait pas? Deja ca coute 5 EUR (salaire du mec qui la met sous pli compris), et ca prend un delai *tres* *aleatoire* pour avoir l'AR (jusqu'a un mois de Paris a Paris). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Règles d'enregistrement dans .FR
On Sun, 05 Feb 2012 19:21:02 +0100, Patrick Maigron patrick.maig...@institut-telecom.fr said: Un autre aspect intéressant du contrat Neustar/NTIA est que les serveurs de noms des titulaires doivent être physiquement sur le territoire US. En tout cas on demande aux titulaires de le certifier dans leur demande, ça serait là aussi difficile à vérifier en pratique par le registre. D'ailleurs Neustar n'était pas favorable à cette restriction mais c'est dans leur contrat. Non applique dans la vraie vie. Ou alors avoir des DNS en .com/.net compte comme etant sur le territoire US. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] VRRP et Quagga
Bonjour, On Sat, Feb 04, 2012 at 10:30:20PM +0100, Stephane Bortzmeyer wrote: On Thu, Feb 02, 2012 at 10:57:38AM +, Antoine Durant antoine.duran...@yahoo.fr wrote a message of 24 lines which said: Faut-il activer un iBGP entre Routeur1 et Routeur2 ?? Je ne comprends pas pourquoi. Si Routeur1 tombe, la session iBGP coupera et ce sera comme si elle n'avait pas été configurée. De même, ça ne sert à rien de monter des sessions iBGP entre des routeurs qui n'ont rien à s'échanger. Typiquement ça ne sert à rien entre ceux qui n'ont ni clients, ni transits. Sylvain signature.asc Description: Digital signature
[FRnOG] [TECH] Man in the middle SSL proxy
Voici un proxy SSL très pratique pour déboguer des applications SSL. http://mitmproxy.org/index.html -- Bien cordialement, Ch. Meessen --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] VRRP et Quagga
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 06/02/2012 12:07, Sylvain Rochet a écrit : De même, ça ne sert à rien de monter des sessions iBGP entre des routeurs qui n'ont rien à s'échanger. Typiquement ça ne sert à rien entre ceux qui n'ont ni clients, ni transits. Il lui reste quoi, au routeur BGP qui n'a ni client ni transit ni iBGP ? Autant pas mettre de routeur, non ? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPL8O3AAoJEC1hvjYyHGwWB0wH/ixcyY0G1fOwVUj/5DsPdxvT smmJTaEoOwNGAU8794W2Q898ExZP7YhNwdIy+5cWa1Kwf1LKWkVBbh2M85gI+0// KKqzdNMO8qM9K8NUNKYUL15380FxVoNbXaNKpmkCkdgkzVfjvb0RhwwrW2RM5aRg H257OJOM5ocfmbmXerze2hH6UIsGe2/CyBJ2T707b9cOK/NO1JKB/Hzmyw/BubRf r7LXZVlrt7vZRB7cyZfZaeq6I1vfIr8R3rp+cZxJbbIQv8O73oEVofX2KWH9CsQd a/W+v/AEdOe3Pw0/jIB79YzYijLapirZ23B1hbQsz9Vr8i0gZZXgZdAzCKEJK1M= =fedV -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] VRRP et Quagga
Le 4 févr. 2012 à 22:30, Stephane Bortzmeyer a écrit : Antoine Durant antoine.duran...@yahoo.fr wrote Faut-il activer un iBGP entre Routeur1 et Routeur2 ?? Je ne comprends pas pourquoi. Si Routeur1 tombe, la session iBGP coupera et ce sera comme si elle n'avait pas été configurée. Sauf que si le lien vers ISPA tombe (ou tout bêtement la session eBGP) et qu'il n'y a pas d'iBGP entre R1 et R2, il n'y aura plus rien du tout. À moins de mettre une default de R1 vers R2 à la rigueur. Ou de faire du VRRP tracking éventuellement. En même temps l'iBGP au sein d'un AS c'est un peu un principe de base dans ce contexte-là. Olivier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] VRRP et Quagga
Bonjour, On Mon, Feb 06, 2012 at 01:12:39PM +0100, Spyou wrote: Le 06/02/2012 12:07, Sylvain Rochet a écrit : De même, ça ne sert à rien de monter des sessions iBGP entre des routeurs qui n'ont rien à s'échanger. Typiquement ça ne sert à rien entre ceux qui n'ont ni clients, ni transits. Il lui reste quoi, au routeur BGP qui n'a ni client ni transit ni iBGP ? Autant pas mettre de routeur, non ? Il faut bien lire, ni clients, ni transits, MAIS de l'iBGP, et uniquement ENTRE ceux qui sont dans ce cas-là. .-transit customers--A---B---C--customers | DE---transit 'customers B a à apprendre des autres mais n'apprend rien aux autres D a à apprendre des autres mais n'apprend rien aux autres B et D n'ont rien à apprendre aux autres donc aussi entre eux, donc ils n'ont pas besoin de session iBGP -entre eux deux-. == pas besoin de session iBGP entre B et D Sylvain signature.asc Description: Digital signature
[FRnOG] [BIZ] NOKIA/Siemens
Bonjour, Quelqu’un aurait-il un contact chez Nokia/Siemens. Je suis intéressé pour échanger avec eux sur leurs offres d'équipements concernant les backbone opérateur télécom Fixe/Mobile. Avez vous une expérience avec ce constructeur ? Merci Fred. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Man in the middle SSL proxy
Hello, 2012/2/6 Meessen Christophe christo...@meessen.net Voici un proxy SSL très pratique pour déboguer des applications SSL. http://mitmproxy.org/index.**html http://mitmproxy.org/index.html Pour les aficionados de la pieuvre, ca ressemble au SSLBump de Squid 3.1 : http://wiki.squid-cache.org/Features/SslBump Couplé a des ACLs, on doit même pouvoir scruter des data sur de l'existant. Bonne soirée. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] VRRP et Quagga
Sylvain Rochet a écrit: De même, ça ne sert à rien de monter des sessions iBGP entre des routeurs qui n'ont rien à s'échanger. Typiquement ça ne sert à rien entre ceux qui n'ont ni clients, ni transits. De même, ça ne sert à rien d'enfoncer une porte ouverte. BGP ça veut dire Border Gateway Protocol donc rien que par le nom on avait compris que c'était pour la périphérie du réseau, pas l'intérieur. Rien à voir avec la configuration d'Antoine, sur laquelle je reviens. Antoine Durant a écrit: +---+ +---+ | ISP A | | ISP B | +---+---+ +---+---+ | | +--E0---+ +--E0---+ | | | | | R1 E1---E1 R2 | | | | | +--E2---+ +--E2---+ | | | +-+ | +--+ SW +--+ +--+--+ | | +--+--+ | X | +-+ Données de base: R1 a une session eBGP avec ISP A R2 a une session eBGP avec ISP B R1 et R2 sont dans le même AS, et tous les deux annoncent les préfixes d'Antoine à leurs pairs eBGP respectifs. A noter: pour ce qui est de la partie VRRP, ça se passe forcément sur E2. Ce n'est PAS parce qu'un des deux routeurs est le passif pour VRRP qu'il ne va pas envoyer ou recevoir de trafic du coté ISP, donc il va forcément y avoir du trafic entre R1 et R2. C'est le multihoming de base; la question n'est pas s'il faut configurer iBGP entre R1 et R2, mais comment; il y a plusieurs possibilités. 1. Entre R1-E2 et R2-E2. Pas terrible; ça marche mais dans ce cas-là le lien E1-E1 ne sert qu'à s'attirer des ennuis. Ca serait la bonne manière s'il n'y avait pas le lien E1-E1, ce qui serait une configuration valable. 2. Entre R1-E1 et R2-E1. Mieux; le trafic entre R1 et R2 passe par le lien dédié, et si le switch tombe la session BGP entre R1 et R2 est préservée, ce qui améliore les choses quand le switch revient. Ceci dit, pas de redondance; si E1 meurt, pas glop. 3. Entre R1-LOO0 et R2 LOO0. La bonne manière; on privilégie le lien E1-E1, mais s'il tombe on a toujours le lien E2-E2. Inconvénient majeur: il faut mettre OSPF entre R1 et R2 en plus de BGP. C'est pour ça que j'écrivais plus tôt que cette configuration avec le lien E1-E1 est mieux que sans le lien, mais nettement plus compliquée. Autres remarques: Si R1 et R2 servent également de firewall, il faut impérativement que l'état des sessions soit synchronisé entre les deux (pas forcément facile). Le même raisonnement vaut aussi pour NAT, ce qui va bien souvent faire que le firewall/NAT va être X sur le diagramme, et que R1, R2 et le switch vont être dans la DMZ. Ceci est l'exemple minimaliste de pouvoir opérer BGP sans défaut si on le voulait, mais dans un cas simple comme celui-ci il est bien plus intéressant de s'assoir sur la gloriole d'être un opérateur de DFZ et plutôt d'avoir ISP A et B annoncer 0.0.0.0/0 en plus des autres routes. A vous les studios. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] VRRP et Quagga
On Mon, 6 Feb 2012 12:06:19 -0800, Michel Py mic...@arneill-py.sacramento.ca.us said: 1. Entre R1-E2 et R2-E2. Pas terrible; ça marche mais dans ce cas-là le lien E1-E1 ne sert qu'à s'attirer des ennuis. Ca serait la bonne manière s'il n'y avait pas le lien E1-E1, ce qui serait une configuration valable. 2. Entre R1-E1 et R2-E1. Mieux; le trafic entre R1 et R2 passe par le lien dédié, et si le switch tombe la session BGP entre R1 et R2 est préservée, ce qui améliore les choses quand le switch revient. Ceci dit, pas de redondance; si E1 meurt, pas glop. 3. Entre R1-LOO0 et R2 LOO0. La bonne manière; on privilégie le lien E1-E1, mais s'il tombe on a toujours le lien E2-E2. Inconvénient majeur: il faut mettre OSPF entre R1 et R2 en plus de BGP. C'est pour ça que j'écrivais plus tôt que cette configuration avec le lien E1-E1 est mieux que sans le lien, mais nettement plus compliquée. 4. (version du pauvre qui veut juste le chose le plus simple au plus vite) On prend la bouteille de Stroh et on laisse tomber l'iBGP. Le routeur actif (VRRP) poussera tout le traffic sortant via son uplink. Le VRRP traque le lien vers l'upstream. Chaque routeur poussera le traffic entrant de chez son upstream vers le reseau local. Certains diront meme que c'est que l'actif qui est suppose recevoir du traffic entrant, mais ici on sait tous que ce n'est pas comme ca que ca marche... Pas la moindre trace de load-balancing du traffic sortant via les deux upstreams non plus. Il y a aussi d'autres objections (e.g. upstream down veut pas forcement dire link down, ), mais devant le DSI de base ca passe tres bien dans l'etat. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Man in the middle SSL proxy
c'est Claude Guéant qui l'a codé? très fort ce truc. William Gacquer Le 6 févr. 2012 à 12:08, Meessen Christophe a écrit : Voici un proxy SSL très pratique pour déboguer des applications SSL. http://mitmproxy.org/index.html -- Bien cordialement, Ch. Meessen --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] VRRP et Quagga
Radu-Adrian Feurdean a écrit: 4. (version du pauvre qui veut juste le chose le plus simple au plus vite) [SNIP] Quelle horreur. Le bûcher! Si tu es sage on te laissera avoir un peu de Stroh avant de s'en servir pour allumer le feu. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Man in the middle SSL proxy
Bin euh, Rien de neuf sous le soleil depuis sslstrip qui a déja quelques années ... Le 6 févr. 2012 à 22:00, William Gacquer a écrit : c'est Claude Guéant qui l'a codé? très fort ce truc. William Gacquer Le 6 févr. 2012 à 12:08, Meessen Christophe a écrit : Voici un proxy SSL très pratique pour déboguer des applications SSL. http://mitmproxy.org/index.html -- Bien cordialement, Ch. Meessen --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Colin Brigato co...@brigato.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Règles d'enregistrement dans .FR
Patrick Maigron a écrit: [géoloc potable] Le problème est l'aspect potable justement. J'ouvrirai un autre fil à ce sujet bientôt. Le problème qui avait été débattu est celui de l'entrave à la libre concurrence. Un grand compte français qui aurait mis tous ses domaines chez un même registrar français pour des raisons de facilité de gestion serait obligé d'avoir un deuxième contrat avec un registrar américain pour ses noms .us (si son registrar français n'offre pas ce service). Je n'avais pas regardé cet aspect des choses. Merci pour toutes tes précisions très éducatives. Mais le gouvernement additionne les bâtons quand même : ils peuvent facilement demander à Neustar de bloquer un nom comme ils le font régulièrement avec VeriSign, mais ils veulent aussi pouvoir virer les serveurs de noms... Que veux-tu, c'est la nature de l'animal. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Problème de bande passante sur un liaison longue distance
Bonjour je suis opérateur sur une ile distante, et nous sommes reliés à l'europe par un cable longue distance à plus de 200 ms de rtt. Pour améliorer notre bande passante, nous voudrions augmenter le window size des paquets envoyés sur ce lien, sans avoir à modifier les paramètres de mes clients. Est-ce que quelqu'un a déja une expérience de ce genre et peut nous conseiller la dessus ? Nos routeurs actuels sont des Cisco 7304 merci Martin ___ Les 10 commandements pour une Saint-Valentin réussie sont sur Voila.fr http://actu.voila.fr/evenementiel/Saint-Valentin/reussir-sa-st-valentin/ --- Liste de diffusion du FRnOG http://www.frnog.org/
