RE: [FRnOG] [TECH] IPSec pour tunneliser SIG SIP
Bonjour, Je fork légèrement le sujet mais est-ce que certains, on déjà testé SoftEther comme solution VPN apparemment assez global ? Seb si tu veux le rajouter a ta liste. Xavier -Message d'origine- De : Sébastien Lesimple [mailto:sebastien.lesim...@iguanetel.fr] Envoyé : jeudi 16 février 2017 23:13 À : David Ponzone; Xavier ROCA Cc : frnog-tech Objet : Re: [FRnOG] [TECH] IPSec pour tunneliser SIG SIP Du SIP-TLS un truc de dingue ça Xavier :) Nan mais déjà une Interco SIP toute basique, qui fonctionne correctement, du premier coups, et construite dans les règles de l'art, ce serait un grand pas en avant... Donc oui, il s'agit bien de SIP tout court, avec Verizon qui impose, au niveau de l'interco, de lui transmettre la Sig via un Tunnel IPSec. Bon ben c'est déjà moins moche que d'envoyer le RTP et Sig dans ledit tunnel IPSec de la SIP Gateway v1.0 des années 2005/2007. Je vais essayer un StrongSWan pour voir. Tant que j'ai pas de prod, c'est le moment d'en profiter pour essayer les différents fork de FreeSWan après tout. Seb On 16/02/2017 19:31, David Ponzone wrote: > Je crois que Seb parlait d’interco SIP avec Verizon, et ils imposent de faire > passer la signalisation dans un tunnel IPSec. > Je ne pense pas qu’il ait le choix de SIPS ou SIP-TLS... > > >> Le 16 févr. 2017 à 19:22, Xavier ROCA a écrit : >> >> Hello, >> >> Du SIPS, SIP-TLS ! >> >> Quand tu as ce qu'il faut bien entendu :) des deux côtés > avance h-5> >> >> Par expérience certains proposent du SIPS mais selon ce que tu configure >> (présentation numéro, Protocol) l'équipement d'en face bien il fait la tête >> ou il ne te regarde même plus. >> >> Xavier >> >> -Message d'origine- >> De : Sébastien Lesimple [mailto:sebastien.lesim...@iguanetel.fr] >> Envoyé : mercredi 15 février 2017 13:55 À : frnog-tech Objet : >> [FRnOG] [TECH] IPSec pour tunneliser SIG SIP >> >> Salut! >> >> Petit sondage rapide, vous utiliseriez quoi comme solution VPN pour shooter >> de la Sig SIP dans un tunnel IPSEC? >> >> On me reparle d'Interco SIP avec Verizon ces derniers temps... >> >> Dans mes lointains souvenirs, il fallait tunneliser SIG et Media, >> aujourd'hui, seule la Sig est a tunneliser. >> >> Donc, Tomato, OpenVPN, OpenSwan...? >> >> Seb. >> >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> >> >> >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] IPSec pour tunneliser SIG SIP
Du SIP-TLS un truc de dingue ça Xavier :) Nan mais déjà une Interco SIP toute basique, qui fonctionne correctement, du premier coups, et construite dans les règles de l'art, ce serait un grand pas en avant... Donc oui, il s'agit bien de SIP tout court, avec Verizon qui impose, au niveau de l'interco, de lui transmettre la Sig via un Tunnel IPSec. Bon ben c'est déjà moins moche que d'envoyer le RTP et Sig dans ledit tunnel IPSec de la SIP Gateway v1.0 des années 2005/2007. Je vais essayer un StrongSWan pour voir. Tant que j'ai pas de prod, c'est le moment d'en profiter pour essayer les différents fork de FreeSWan après tout. Seb On 16/02/2017 19:31, David Ponzone wrote: > Je crois que Seb parlait d’interco SIP avec Verizon, et ils imposent de faire > passer la signalisation dans un tunnel IPSec. > Je ne pense pas qu’il ait le choix de SIPS ou SIP-TLS... > > >> Le 16 févr. 2017 à 19:22, Xavier ROCA a écrit : >> >> Hello, >> >> Du SIPS, SIP-TLS ! >> >> Quand tu as ce qu'il faut bien entendu :) des deux côtés >> >> >> Par expérience certains proposent du SIPS mais selon ce que tu configure >> (présentation numéro, Protocol) l'équipement d'en face bien il fait la tête >> ou il ne te regarde même plus. >> >> Xavier >> >> -Message d'origine- >> De : Sébastien Lesimple [mailto:sebastien.lesim...@iguanetel.fr] >> Envoyé : mercredi 15 février 2017 13:55 >> À : frnog-tech >> Objet : [FRnOG] [TECH] IPSec pour tunneliser SIG SIP >> >> Salut! >> >> Petit sondage rapide, vous utiliseriez quoi comme solution VPN pour shooter >> de la Sig SIP dans un tunnel IPSEC? >> >> On me reparle d'Interco SIP avec Verizon ces derniers temps... >> >> Dans mes lointains souvenirs, il fallait tunneliser SIG et Media, >> aujourd'hui, seule la Sig est a tunneliser. >> >> Donc, Tomato, OpenVPN, OpenSwan...? >> >> Seb. >> >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> >> >> >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] TCP mangling et net-neutrality
Bonjour Jérôme, La problématique est que l'internet à été défini sur un MTU IP de 1500. grand bien. Actuellement, les technologie SD-WAN, tendent a vouloir bâtir de infrastructure logique en overlay sur Internet, via des protocoles du tunneling (IPsec, L2TP, GRE) Donc forcement, cela bloque. 2 possibilités: - Soit les infra client sont agnostique de cela, et c est au réseau de retailler le trames. - Soit les infra (serveurs, etc) prennent cela en compte dès la source. Personnellement, sur ces archis , j'impose un MTU à 1300 sur chaque machine. La perte en rendement de transmission n est pas si grave que cela, et cela passe partout. ++ Marc Le 15/02/2017 à 22:11, Jérôme Nicolle a écrit : Plop, Ce post pour une seule simple question : d'après vous, est ce que réécrire les entêtes TCP, ou même juste le MRU et MTU sur un service de tunneling, est une fonction compatible avec l'obligation de neutralité du transporteur de paquets ? Merci d'avance pour vos réflexions ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] TCP mangling et net-neutrality
Bonjour, Il y a pas mal de réseaux où l'abus de firewall paranos qui filtrent icmp fait que le path mtu discovery ne marche pas. du coup, on a pas vraiment d'autres choix que de réécrire le mss si on veut communiquer avec eux. A ce propos, il me manque une boite à outil pour déterminer facilement la "vraie" MTU entre 2 points. Je dis la "vraie" parce que ce je voudrais pouvoir détecter un tunnel qui fragmente/recombine et qui induit de brusques variations de latence quand on passe le seuil de fragmentation. Le 16/02/2017 à 17:01, Radu-Adrian Feurdean a écrit : On Wed, Feb 15, 2017, at 22:11, Jérôme Nicolle wrote: Ce post pour une seule simple question : d'après vous, est ce que réécrire les entêtes TCP, ou même juste le MRU et MTU sur un service de tunneling, est une fonction compatible avec l'obligation de neutralité du transporteur de paquets ? Salut, Si c'est un vrai "transporteur de paquets" (transit provider), j'aurai tendance a dire que non. Ca fait au minima "service de mauvaise qualite". Pour du transport L2 ou plus bas (Ethernet, Wave, ) ca doit etre definitivement NON (ca touche la "payload"). Par contre pour le FAI ou le fournisseur de VPN, j'ai tendance a dire que oui; c'est d'ailleurs un cas assez courant. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] IPSec pour tunneliser SIG SIP
Hello David, Je m'en doute d’où le Je n'ai pas mis la balise du début pour voir s'il y en avait un qui était plus fatigué que les autres en fin de semaine :) Après pour être plus sérieux un bon UTM (Physique ou Virtuel) qui vérifie entre autre aussi la sécurité autour de l'IPSec c'est pas mal aussi. @+ -Message d'origine- De : David Ponzone [mailto:david.ponz...@gmail.com] Envoyé : jeudi 16 février 2017 19:31 À : Xavier ROCA Cc : Sebastien LESIMPLE; frnog-tech Objet : Re: [FRnOG] [TECH] IPSec pour tunneliser SIG SIP Je crois que Seb parlait d’interco SIP avec Verizon, et ils imposent de faire passer la signalisation dans un tunnel IPSec. Je ne pense pas qu’il ait le choix de SIPS ou SIP-TLS... > Le 16 févr. 2017 à 19:22, Xavier ROCA a écrit : > > Hello, > > Du SIPS, SIP-TLS ! > > Quand tu as ce qu'il faut bien entendu :) des deux côtés avance h-5> > > Par expérience certains proposent du SIPS mais selon ce que tu configure > (présentation numéro, Protocol) l'équipement d'en face bien il fait la tête > ou il ne te regarde même plus. > > Xavier > > -Message d'origine- > De : Sébastien Lesimple [mailto:sebastien.lesim...@iguanetel.fr] > Envoyé : mercredi 15 février 2017 13:55 À : frnog-tech Objet : [FRnOG] > [TECH] IPSec pour tunneliser SIG SIP > > Salut! > > Petit sondage rapide, vous utiliseriez quoi comme solution VPN pour shooter > de la Sig SIP dans un tunnel IPSEC? > > On me reparle d'Interco SIP avec Verizon ces derniers temps... > > Dans mes lointains souvenirs, il fallait tunneliser SIG et Media, > aujourd'hui, seule la Sig est a tunneliser. > > Donc, Tomato, OpenVPN, OpenSwan...? > > Seb. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] IPSec pour tunneliser SIG SIP
Je crois que Seb parlait d’interco SIP avec Verizon, et ils imposent de faire passer la signalisation dans un tunnel IPSec. Je ne pense pas qu’il ait le choix de SIPS ou SIP-TLS... > Le 16 févr. 2017 à 19:22, Xavier ROCA a écrit : > > Hello, > > Du SIPS, SIP-TLS ! > > Quand tu as ce qu'il faut bien entendu :) des deux côtés > > > Par expérience certains proposent du SIPS mais selon ce que tu configure > (présentation numéro, Protocol) l'équipement d'en face bien il fait la tête > ou il ne te regarde même plus. > > Xavier > > -Message d'origine- > De : Sébastien Lesimple [mailto:sebastien.lesim...@iguanetel.fr] > Envoyé : mercredi 15 février 2017 13:55 > À : frnog-tech > Objet : [FRnOG] [TECH] IPSec pour tunneliser SIG SIP > > Salut! > > Petit sondage rapide, vous utiliseriez quoi comme solution VPN pour shooter > de la Sig SIP dans un tunnel IPSEC? > > On me reparle d'Interco SIP avec Verizon ces derniers temps... > > Dans mes lointains souvenirs, il fallait tunneliser SIG et Media, > aujourd'hui, seule la Sig est a tunneliser. > > Donc, Tomato, OpenVPN, OpenSwan...? > > Seb. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] IPSec pour tunneliser SIG SIP
Hello, Du SIPS, SIP-TLS ! Quand tu as ce qu'il faut bien entendu :) des deux côtés Par expérience certains proposent du SIPS mais selon ce que tu configure (présentation numéro, Protocol) l'équipement d'en face bien il fait la tête ou il ne te regarde même plus. Xavier -Message d'origine- De : Sébastien Lesimple [mailto:sebastien.lesim...@iguanetel.fr] Envoyé : mercredi 15 février 2017 13:55 À : frnog-tech Objet : [FRnOG] [TECH] IPSec pour tunneliser SIG SIP Salut! Petit sondage rapide, vous utiliseriez quoi comme solution VPN pour shooter de la Sig SIP dans un tunnel IPSEC? On me reparle d'Interco SIP avec Verizon ces derniers temps... Dans mes lointains souvenirs, il fallait tunneliser SIG et Media, aujourd'hui, seule la Sig est a tunneliser. Donc, Tomato, OpenVPN, OpenSwan...? Seb. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] TCP mangling et net-neutrality
On Wed, Feb 15, 2017, at 22:11, Jérôme Nicolle wrote: > Ce post pour une seule simple question : d'après vous, est ce que > réécrire les entêtes TCP, ou même juste le MRU et MTU sur un service de > tunneling, est une fonction compatible avec l'obligation de neutralité > du transporteur de paquets ? Salut, Si c'est un vrai "transporteur de paquets" (transit provider), j'aurai tendance a dire que non. Ca fait au minima "service de mauvaise qualite". Pour du transport L2 ou plus bas (Ethernet, Wave, ) ca doit etre definitivement NON (ca touche la "payload"). Par contre pour le FAI ou le fournisseur de VPN, j'ai tendance a dire que oui; c'est d'ailleurs un cas assez courant. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] FrNOG 24 Mars
Bonjour, Comment pourrai-je participer à la prochiane rencontre FrNOG? Cordialement, UM --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] TCP mangling et net-neutrality
On Wed, Feb 15, 2017 at 10:11:04PM +0100, Jérôme Nicolle wrote a message of 18 lines which said: > Ce post pour une seule simple question : d'après vous, est ce que > réécrire les entêtes TCP, ou même juste le MRU et MTU sur un service > de tunneling, est une fonction compatible avec l'obligation de > neutralité du transporteur de paquets ? Dans ce cas précis, et pour ce protocole, je pense que ce n'est pas grave car TCP est censé fournir un service de flot d'octets, pas un service de paquets, donc que les données soient découpées en N paquets ou en M, avec M ≠ N, ne changera rien pour le destinataire. (Ce serait tout à fait différent en UDP.) Évidemment, c'est un cas assez limite. Changer le MSS (pas le MTU, qui n'est pas dans les paquets) peut passer, tripoter les autres en-têtes... Pour le reste, je suis d'accord avec les critères de Kavé Salamatian. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
Sylvain, quel est le temps de réponse que tu obtiens? Et quelle taille de window as-tu lors des transferts? Le 15 février 2017 à 23:22, a écrit : > 100Mb nous sommes en 2017…… en IDF… > > > > *De :* Ducassou laurent [mailto:laurent.ducas...@spaceshell.fr] > *Envoyé :* mercredi 15 février 2017 17:52 > *À :* frnog@frnog.org; sbu123fr; Louis > *Cc :* Liste FRnoG > *Objet :* Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens > (MPLS) 500Mo mais plutot 5 x 100Mo > > > > Totalement cohérent alors. > > Le 15 février 2017 17:50:24 GMT+01:00, sbu123fr a > écrit : > > C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ en > "mono" 100 et des bananes > > Message d'origine > De : Louis > Date : 15/02/2017 17:22 (GMT+01:00) > À : sbu123fr > Cc : Ducassou Laurent , Liste FRnoG > > Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 > x 100Mo > > Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez > fiable. Pas de lecture disque > Le 15 février 2017 à 17:20, Louis a écrit : > 280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le > débit. Avec un transfert multi-session, la tête de lecture/écriture d'un > disque classique est obligé de faire en permanence des aller-retours. > Le 15 février 2017 à 17:07, sbu123fr a écrit : > BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur > la chaîne de liaison > > Message d'origine > De : Ducassou Laurent > Date : 15/02/2017 16:36 (GMT+01:00) > À : frnog@frnog.org > Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x > 100Mo > > Plus simplement : > > Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS > 500Mbit/s. > > Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est > que chaque site est relié que avec une fibre optique à 100Mbit/s. > > Ca arrive souvent dans les nuages MPLS des DSP ce "problème de > compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le > client final crois disposer de 500Mbit/s entre chaque site, mais en > réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à > 100Mbit/s sur D et que E est au repos. > > Je crois avoir compris cela... > > > Le 15/02/2017 à 15:35, Louis a écrit : > > Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus > d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping. > > J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites). > > "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur > une session TCP entre 2 liens" > > > > Le 15 février 2017 à 15:19, Benjamin Bachelart a écrit : > > Oui mais non, > > Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les > liens de façon parfaitement aléatoire, souvent les équipements balancent le > trafic de manière *déterministe* sur l'un des liens physiques, en se basant > sur le couple adresse source-destination, cela peut-être Adresse IP source > / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être > par flux (Source IP+Port - Dest IP+Port), il existe sûrement des > exceptions, et sûrement des solutions propriétaires. > > Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas > (exception faite des solutions propriétaires ou solutions non déterministes > de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de > 100Mbps sur un LAG 5x100Mbps pour un même flux. > > cordialement, > > 2017-02-15 14:56 GMT+01:00 Louis : > > Après quelques recherche, j'arrive à la conclusion que la limitation du > temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps > (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres > de l'OS. > > L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur > les (très) vieux OS, la valeur maxi de window size était 65535 octets > parce > que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC > 1323 est largement utilisée. Elle introduit un paramètre window size > scaling factor (8 bits) qui est un multiplcateur de la valeur de window > size. Le window size est étendu 16Mo au lieu de 64Ko. > > Calculateur de bande passante sur une session TCP : > https://www.switch.ch/network/tools/tcp_throughput/ > Pour la formule, c'est ici : > http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu > ghput-for-long-distance-links/ > > Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il > faudrait une taille window de ~1800 Ko. > > Il faut regarder les paramètres de l'OS pour voir si les paramètres > permettent d'avoir une window de cette taille. > > Sur les windows récents, les paramètres sont décrits ici : > http://www.speedguide.net/articles/windows-8-10-2012-server- > tcpip-tweaks-5077 > - para
[MISC] Re: [FRnOG] Re: [ALERT] La Poste et les services secrets français
Le Tue, Feb 07, 2017 at 03:45:54PM +0100, Richard DEMONGEOT a écrit: > Mais non. D'après black mirror, c'est des drones abeilles qui > peuvent être piratées pour tuer. Ne rigolons pas avec ça: http://www.lesechos.fr/idees-debats/sciences-prospective/0211796855657-des-drones-pour-remplacer-les-abeilles-2064647.php http://www.forbes.fr/technologie/beeonic-le-drone-abeille-pour-polliniser-lamerique-du-nord/ AYEZ PEUR ! Arnaud. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] FRNOG 28.0 - BETA
Bonjour, Il me manque un sponsor Silver, pour le beer/social event de la prochaine réunion (du 24 Mars). Merci de me contacter off-list si ça peut vous intéresser. Par contre le programme est bouclé et les inscriptions ouvriront en fin de mois. Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] TCP mangling et net-neutrality
Le 15/02/2017 à 22:11, Jérôme Nicolle a écrit : > Plop, > > Ce post pour une seule simple question : d'après vous, est ce que > réécrire les entêtes TCP, ou même juste le MRU et MTU sur un service de > tunneling, est une fonction compatible avec l'obligation de neutralité > du transporteur de paquets ? > > Merci d'avance pour vos réflexions ! > Yop, A mon avis, si au résultat de ces modifications n'est pas la discrimination de certains flux par rapport à d'autres (genre QoS, genre dégrader / prioriser de la VOD, VoIP ...) et que les données ne sont pas altérées alors non la net-neutralité n'est pas affectée. Donc que tu modifie le MRU/MTU de *toutes* les sessions TCP quelque soit la destination, le port destination ... Il n'y a alors pas de discrimination de trafic. Surtout que ce mécanisme ne joue qu'au moment du three-way handshake et ne rentre plus en jeu une fois que la session TCP est établie. Preuve que ça n'altère pas le flux de données sur la fonction transport de paquet. De plus, les MRU et MTU ne sont pas garantis être calés sur ceux d'Ethernet sur Internet, d'où les mécanismes PMTU directement inclus dans IPv6. Comme IPv4 n'a pas ce mécanisme, modifier les MRU / MTU à la volée lors du transport ne me semble pas violer quoique ce soit (vaut mieux préciser vu le contexte :)). Mais vaut mieux écrire & décrire le processus pour tes clients, si troubleshooting il y a, il permettra d'éliminer cette incongruité (en 2017). -- Jérôme Marteaux --- Liste de diffusion du FRnOG http://www.frnog.org/
