[FRnOG] LISP : besoin d'avis
Bonjour, Je m’intéresse depuis quelques mois à LISP, pas le langage, mais le Locator/ID Separation Protocol. Pour ceux qui ne connaissent pas encore, LISP a pour principes et objectifs : - Dissocier les rôles de localisation et d'identification des adresses, c'est à dire d'avoir des adresses RLOC (Routing Locator) routées vers leurs destinations naturelles et des adresses EID assignées à un end-user mais routées vers des passerelles LISP (probablement en anycast). - Permettre de supprimer de nombreux préfixes de la table globale en supprimant le besoin de more specifics pour les préfixes actuels - Ainsi, permettre d'avoir deux plans de routage : un plan inter-opérateur (la table globale actuelle) et un plan intra-LISP, inter-opérateur ou non, et du coup permettre par exemple de multihomer un /32 v4 ou un /64 v6 via LISP plutôt que de voir le préfixe filtré en bordure d'AS. - Avec un protocole plus riche et quelques subtilités dans les annonces entre les xTR et les PxTR, via les MR et MS, (oui ça rajoute beaucoup de terminologie, voir plus bas), de faire du trafic engineering entrant et sortant - Réaliser la liaison entre les deux plans de routage par encapsulation / décapsulation de niveau 3 (IP in IP) ou 4 (avec une spec optionnelle pour LISP-MobileNode), permettant du coup de faire passer du v6 sur du v4 et inversement de façon quasi transparente. En gros, on garde le backbone en v4 mais des edge LISP gèrent le v6 en plus de proposer toutes les features de ce protocole. - Tout plein d'autres choses amusantes mais que je suis pas sur d'avoir encore bien compris, alors je vous invite à compléter. Sur le papier, LISP c'est vachement sexy, ça règle tous les problèmes, au prix d'un leger overhead (encapsulation). Mais je me pose quand même une question : est ce que ça ne reviens pas finalement juste à rajouter une couche de merde sur un réseau déjà bancal ? En version plus politiquement correcte, est ce qu'on a un réel intérêt à déployer un plan de routage supplémentaire, ou est ce qu'il ne vaut pas mieux faire le ménage dans l'existant ? Accessoirement, la seule implémentation de LISP qui a l'air production grade (pour un protocole pas fini de spécifier quoi), c'est chez cisco, sur les ISR, 7200 et ASR. Je n'ai pas l'impression que ce soit dispo sur les 7600 ni sur les CRS. De là à être interopérable, certes c'est spécifié (enfin en cours) à l'IETF, mais de là à être implémenté partout... Bref, d'après vous : LISP, un soufflé qui va retomber; ou bien LISP, l'avenir d'Internet ? Merci pour vos avis ! Ressources : http://www.lisp4.net/ (http://www.lisp6.net/ ne marche pas :s) http://lisp.cisco.com/ https://datatracker.ietf.org/wg/lisp/ OpenLISP.org (on FreeBSD) LISPmob.org (on Linux) Glossaire : EID : End-point ID (adresse IP coté LISP-site, derrière un ITR) RLOC : Routing LOCATOR (adresse IP d'un ETR) ITR : Ingress Tunnel Router : encapsule des packets émis par des EID pour les ressortir sur l'Internet non LISP ETR : Egress Tunnel Router : Décapsule des paquets LISP xTR : indiférement ETR ou ITR ou les deux en fonction du sens du flux PxTR : Proxy xTR : fais la jonction entre l'Internet LISP et l'Internet normal MR : Mapping Resolver / mapping Request, mapping == correspondance ou routes entre RLOC et EID Methodes de mapping : - Statique - ALT-T : à base de BGP over GRE , semble le meilleur compromis actuel - Tree : à base de DNS - NERD : push des informations de routage à tous les noeuds - EMAC : pull des infos de routage sur du multicast - CONS : push par link-state protocol -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: LISP : besoin d'avis
On Fri, Oct 14, 2011 at 11:54:45AM +0200, Jérôme Nicolle jer...@ceriz.fr wrote a message of 102 lines which said: Je m'intéresse depuis quelques mois à LISP, pas le langage, mais le Locator/ID Separation Protocol. Chic, c'est vendredi ! - Dissocier les rôles de localisation et d'identification des adresses, Et c'est le dixième ou le vingtième protocole à faire cela. Le plus achevé, avant la mode LISP, était HIP. - Permettre de supprimer de nombreux préfixes de la table globale en supprimant le besoin de more specifics pour les préfixes actuels Ici, je ricane. On avait déjà dit ça d'IPv6. « Ça va enfin permettre aux opérateurs d'empêcher leurs clients de mettre les pieds dans notre DFZ à nous qu'on voudrait garder pour nous. ». En gros, on garde le backbone en v4 Quel intérêt ? C'est justement l'endroit où il est le plus facile de faire du v6 (homogénéité du logiciel, administration unique, machines et logiciels récents). au prix d'un leger overhead (encapsulation). Léger ? Même d'un seul octet, cela abaisse la MTU et cela veut dire tous les problèmes qu'on a actuellement avec les tunnels, généralisés. OpenLISP.org (on FreeBSD) www.OpenLISP.org Ce sont des barbus, OpenLISP.org n'a pas d'adresse. Methodes de mapping : Le nouveau truc à apprendre. En effet, *toute* solution de séparation de l'identificateur et du localisateur a ce problème. C'est bien joli d'ajouter une indirection, mais comment on la suit, de manière sécurisée ? Allez, je retourne jouer avec lig, les gens de BGP me snobaient parce que je déboguais mes services avec dig, demain, je vais rigoler, ils vont devoir redécouvrir tout ce que les opérateurs DNS ont appris dans la douleur depuis vingt ans. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: LISP : besoin d'avis
Stéphane, Le 14 octobre 2011 12:19, Stephane Bortzmeyer bortzme...@nic.fr a écrit : On Fri, Oct 14, 2011 at 11:54:45AM +0200, Jérôme Nicolle jer...@ceriz.fr wrote - Dissocier les rôles de localisation et d'identification des adresses, Et c'est le dixième ou le vingtième protocole à faire cela. Le plus achevé, avant la mode LISP, était HIP. Ah peut être mais je dois être trop jeune pour en avoir vu une implémentation qui marche. oH, wait... - Permettre de supprimer de nombreux préfixes de la table globale en supprimant le besoin de more specifics pour les préfixes actuels Ici, je ricane. On avait déjà dit ça d'IPv6. « Ça va enfin permettre aux opérateurs d'empêcher leurs clients de mettre les pieds dans notre DFZ à nous qu'on voudrait garder pour nous. ». Sauf que, vu de l’intérieur, les GrozOperateurs, ils font plus de conneries avec l'adressage v6 qu'avec le v4. Ou plus exactement, comme ce ne sont pas les mêmes personnes qui gèrent le routage et l'adressage, main gauche qui sait pas ce que fait la main droite, tout ça... Ca va être un pire fiasco. heureusement, on a assez d'adresses pour faire plusieurs fois la connerie... En gros, on garde le backbone en v4 Quel intérêt ? C'est justement l'endroit où il est le plus facile de faire du v6 (homogénéité du logiciel, administration unique, machines et logiciels récents). Waip, alors qund tu te traines de vielles bouses de ton backbone parce que upgrader en ethernet ou avec du nouveau matos POS ça coute un bras, et comme si tu casse le backbone avec un firmware pas sec tu réveilles la moitié de la boite, c'est beaucoup plus simple et moins risqué de casser les réseaux clients que le tiens. au prix d'un leger overhead (encapsulation). Léger ? Même d'un seul octet, cela abaisse la MTU et cela veut dire tous les problèmes qu'on a actuellement avec les tunnels, généralisés. Mais non, voyons, avec PMTUd on devrait plus avoir de problème ! www.OpenLISP.org Ce sont des barbus, OpenLISP.org n'a pas d'adresse. Waip, truc de barbus. Mais les browsers hype affichent plus http://www.; dans les URL, c'est trop has been ! Le nouveau truc à apprendre. En effet, *toute* solution de séparation de l'identificateur et du localisateur a ce problème. C'est bien joli d'ajouter une indirection, mais comment on la suit, de manière sécurisée ? Alors là, je veux bien profiter de tes lumières, j'ai pas l'impression que ce soit spécifié encore... Allez, je retourne jouer avec lig, les gens de BGP me snobaient parce que je déboguais mes services avec dig, demain, je vais rigoler, ils vont devoir redécouvrir tout ce que les opérateurs DNS ont appris dans la douleur depuis vingt ans. Ah il build lig ? Il est pas encore packagé... Quelqu'un à un binaire à slapper dans un JunOS ? -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: LISP : besoin d'avis
On Fri, Oct 14, 2011 at 12:37:28PM +0200, Jérôme Nicolle jer...@ceriz.fr wrote a message of 88 lines which said: Léger ? Même d'un seul octet, cela abaisse la MTU et cela veut dire tous les problèmes qu'on a actuellement avec les tunnels, généralisés. Mais non, voyons, avec PMTUd on devrait plus avoir de problème ! C'est une blague ? Le nouveau truc à apprendre. En effet, *toute* solution de séparation de l'identificateur et du localisateur a ce problème. C'est bien joli d'ajouter une indirection, mais comment on la suit, de manière sécurisée ? Alors là, je veux bien profiter de tes lumières, j'ai pas l'impression que ce soit spécifié encore... En effet. Et pour cause, c'est *la* difficulté de tout projet de séparation identificateur/localisateur, le reste étant relativement simple. Ah il build lig ? % make gcc -Wall -Wno-implicit-function-declaration -c -o lig.o lig.c lig.c: In function 'main': lig.c:100:10: warning: variable 'eid_length' set but not used [-Wunused-but-set-variable] lig.c:99:10: warning: variable 'eid_addrtype' set but not used [-Wunused-but-set-variable] gcc -Wall -Wno-implicit-function-declaration -c -o send_map_request.o send_map_request.c gcc -Wall -Wno-implicit-function-declaration -c -o lib.o lib.c gcc -Wall -Wno-implicit-function-declaration -c -o cksum.o cksum.c gcc -Wall -Wno-implicit-function-declaration -c -o print.o print.c gcc -Wall -Wno-implicit-function-declaration -c -o get_my_ip_addr.o get_my_ip_addr.c gcc -o lig lig.o send_map_request.o lib.o cksum.o print.o get_my_ip_addr.o % % ./lig -m l3-london-mr-ms.rloc.lisp4.net 153.16.10.254 Send map-request to l3-london-mr-ms.rloc.lisp4.net for 153.16.10.254 ... Received map-reply from 173.36.254.163 with rtt 0.23900 secs Mapping entry for EID '153.16.10.254': 153.16.10.0/24, via map-reply, record ttl: 1440, auth, not mobile Locator State Priority/Weight 173.36.254.163 up1/100 Quelqu'un à un binaire à slapper dans un JunOS ? Et, pourquoi dans JunOS ? On utilise rarement un Juniper comme console d'administration :-) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: LISP : besoin d'avis
On 14/10/2011 12:37, Jérôme Nicolle wrote: www.OpenLISP.org Ce sont des barbus, OpenLISP.org n'a pas d'adresse. Waip, truc de barbus. Mais les browsers hype affichent plus http://www.; dans les URL, c'est trop has been ! Bon... c'est vrai que j'ai la barbe ;-) et c'est vrai que ca fait longtemp que je fait pas une nouvelle release (presque prete la nouvelle) Mais je suis open pour vos commentaires vous pouvez aussi les envoyer a g...@openlisp.org ciao Luigi --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: LISP : besoin d'avis
Sans rentrer dans la polémique ouais mais ça fait vingt fois qu'on nous le sort, mais ça marche jamais et autre c'est poussé par un constructeur donc caca, moi j'y vois un intérêt : - j'ai dans mon entourage proche des gens du système qui ne jure que par le Vmotion, et qui n'ont pas compris que ça ne servait pas à faire du HA. Du coup, ils me demandent des vlans étendus entre plusieurs sites à chaque fois... bien entendu, on leur a dit d'aller mourir, mais ces immondes systèmeux sont super resistants. - il faut quand même admettre que le GSLB a ses limites (du genre temps de bascule limité par le cache DNS, et autre ttl pas pris en compte) - conserver son @IP (ie, gérer la mobilité au niveau 3) c'est un poil foireux : depuis quand l'@IP est un gage d'identité ??? (C'est philosophique comme question) N'empèche que quand on a pas le choix (cas d'une VM qui se déplace), c'est bien pratique de pouvoir conserver son @IP en mobilité. - or Cisco a déjà implémenté LISP sur ASR1K (super), et Nexus7K : LISP sur un routeur de Datacenter ? Du coup, ça ouvre la possibilité de l'utilisé pour un serveur se déplaçant d'un site à un autre ! Or comme le code du Nexus est en partie commun entre N7K, N5K et surtout N1000v, on peut espérer que LISP sera un jour dispo sur le premier équipement réseau traversé par un flux d'une VM : le switch intégré à l'hyperviseur. Et là du coup, on peut envisager d'avoir une VM se déplaçant d'un site A à un site B sans pour autant utiliser de vlan étendu, en gardant un vrai réseau routé et pas du bricolage de haut niveau (VPLS and Co) pour étendre un vlan mais sans vraiment l'étendre ... Perso j'avais commencé à bosser sur un proto à base de DHCP sur les interfaces physiques, d'un démon de routage et le service porté sur une loopback, mais l'idée d'avoir une table de routage peuplée de /32 dans tous les coins ... du bricolage je vous dit ! Evidemment, si ça marche pour une VM qui se déplace, ça peut marcher pour un téléphone ou un PC qui se déplace et connecté en wireless (adieu GTP). L'avantage c'est que le client n'est pas conscient de la couche LISP, donc pas de modification à y apporter, donc c'est mieux. A vous de voir si c'est philosophiquement pas bien, mais moi, sur le terrain et avec des VMs, ça me tente bien. Le 14 octobre 2011 15:24, Stephane Bortzmeyer bortzme...@nic.fr a écrit : On Fri, Oct 14, 2011 at 12:37:28PM +0200, Jérôme Nicolle jer...@ceriz.fr wrote a message of 88 lines which said: Léger ? Même d'un seul octet, cela abaisse la MTU et cela veut dire tous les problèmes qu'on a actuellement avec les tunnels, généralisés. Mais non, voyons, avec PMTUd on devrait plus avoir de problème ! C'est une blague ? Le nouveau truc à apprendre. En effet, *toute* solution de séparation de l'identificateur et du localisateur a ce problème. C'est bien joli d'ajouter une indirection, mais comment on la suit, de manière sécurisée ? Alors là, je veux bien profiter de tes lumières, j'ai pas l'impression que ce soit spécifié encore... En effet. Et pour cause, c'est *la* difficulté de tout projet de séparation identificateur/localisateur, le reste étant relativement simple. Ah il build lig ? % make gcc -Wall -Wno-implicit-function-declaration -c -o lig.o lig.c lig.c: In function 'main': lig.c:100:10: warning: variable 'eid_length' set but not used [-Wunused-but-set-variable] lig.c:99:10: warning: variable 'eid_addrtype' set but not used [-Wunused-but-set-variable] gcc -Wall -Wno-implicit-function-declaration -c -o send_map_request.o send_map_request.c gcc -Wall -Wno-implicit-function-declaration -c -o lib.o lib.c gcc -Wall -Wno-implicit-function-declaration -c -o cksum.o cksum.c gcc -Wall -Wno-implicit-function-declaration -c -o print.o print.c gcc -Wall -Wno-implicit-function-declaration -c -o get_my_ip_addr.o get_my_ip_addr.c gcc -o lig lig.o send_map_request.o lib.o cksum.o print.o get_my_ip_addr.o % % ./lig -m l3-london-mr-ms.rloc.lisp4.net 153.16.10.254 Send map-request to l3-london-mr-ms.rloc.lisp4.net for 153.16.10.254 ... Received map-reply from 173.36.254.163 with rtt 0.23900 secs Mapping entry for EID '153.16.10.254': 153.16.10.0/24, via map-reply, record ttl: 1440, auth, not mobile Locator State Priority/Weight 173.36.254.163 up1/100 Quelqu'un à un binaire à slapper dans un JunOS ? Et, pourquoi dans JunOS ? On utilise rarement un Juniper comme console d'administration :-) --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Cordialement, Guillaume BARROT
Re: [FRnOG] Re: LISP : besoin d'avis
Le 14 oct. 2011 à 16:42, Guillaume Barrot a écrit : Sans rentrer dans la polémique ouais mais ça fait vingt fois qu'on nous le sort, mais ça marche jamais et autre c'est poussé par un constructeur donc caca, moi j'y vois un intérêt : - j'ai dans mon entourage proche des gens du système qui ne jure que par le Vmotion, et qui n'ont pas compris que ça ne servait pas à faire du HA. Du coup, ils me demandent des vlans étendus entre plusieurs sites à chaque fois... bien entendu, on leur a dit d'aller mourir, mais ces immondes systèmeux sont super resistants. - il faut quand même admettre que le GSLB a ses limites (du genre temps de bascule limité par le cache DNS, et autre ttl pas pris en compte) - conserver son @IP (ie, gérer la mobilité au niveau 3) c'est un poil foireux : depuis quand l'@IP est un gage d'identité ??? (C'est philosophique comme question) N'empèche que quand on a pas le choix (cas d'une VM qui se déplace), c'est bien pratique de pouvoir conserver son @IP en mobilité. - or Cisco a déjà implémenté LISP sur ASR1K (super), et Nexus7K : LISP sur un routeur de Datacenter ? Du coup, ça ouvre la possibilité de l'utilisé pour un serveur se déplaçant d'un site à un autre ! Bravo Guillaume... bonne intuition. C'est ce que nous sommes en train de tester dans notre coins de barbus, avec OpenLisp (merci Luigi), et XeN. Pas philosophique, opensource, et ça marche C'est la vraie motivation pour LISP. -- Stefano Secci Associate Professor PHARE - LIP6 - UPMC - Sorbonne Universités Bureau 25-26/318, Boite Courrier 169 4 place Jussieu, 75005 Paris, France Tel: +33 (0) 1 4427 3678 Fax: +33 (0) 1 4427 8783 http://www-phare.lip6.fr/~secci/
RE: [FRnOG] Re: LISP : besoin d'avis
Jérôme Nicolle a écrit: Je m'intéresse depuis quelques mois à LISP, pas le langage, mais le Locator/ID Separation Protocol. Stephane Bortzmeyer Chic, c'est vendredi ! Et c'est mon troll favori! Voir aussi la discussion sur la liste policy de RIPE récemment à propos de 2011-12. - Dissocier les rôles de localisation et d'identification des adresses, Et c'est le dixième ou le vingtième protocole à faire cela. Tiens, ça me rappelle quelques souvenirs ;-) Et oui Et ce n'est pas nouveau non plus, ci-dessous la version 1996 de LISP par Steve Deering en personne. http://arneill-py.sacramento.ca.us/ipv6mh/map-n-encap.pdf Il y a quinze ans à peine, Il y a quinze ans déjà, Ma mémoire est incertaine Mais mon coeur lui, n'oublie pas [Un été de porcelaine - Mort Schuman] Le plus achevé, avant la mode LISP, était HIP. Je me rappelle bien de HIP; j'ai rencontré Pekka Nikander plusieurs fois, un mec brillant. On avait un peu réfléchi à la possibilité d'inter-opérer HIP et MHAP, dans le temps. - Permettre de supprimer de nombreux préfixes de la table globale en supprimant le besoin de more specifics pour les préfixes actuels Ici, je ricane. On avait déjà dit ça d'IPv6. « Ça va enfin permettre aux opérateurs d'empêcher leurs clients de mettre les pieds dans notre DFZ à nous qu'on voudrait garder pour nous.». Comme c'est bien dit :-D En plus, c'est une illusion: Dans un gros site, la table entre les locateurs et l'identifiant va être pratiquement aussi grande que la DFZ. au prix d'un leger overhead (encapsulation). Léger ? Même d'un seul octet, cela abaisse la MTU et cela veut dire tous les problèmes qu'on a actuellement avec les tunnels, généralisés. Dans ce domaine LISP a fait un pas de 10 ans en arrière; on avait compris l'importance de préserver le MTU il y a 10 ans: les versions primaires de MHAP étaient basées sur des tunnels. Le nouveau truc à apprendre. En effet, *toute* solution de separation de l'identificateur et du localisateur a ce problème. C'est bien joli d'ajouter une indirection, mais comment on la suit, de manière sécurisée ? gros soupir En plus, même si on pouvait ignorer le problème de la sécurité, ce qui a toujours été la pierre d'achoppement de tous ces systèmes c'est la complexité ajoutée. Bref, d'après vous : LISP, un soufflé qui va retomber; ou bien LISP, l'avenir d'Internet ? Un soufflé qui va retomber. Même si je vois certaines applications internes au datacenter ce n'est pas le Saint Graal du multihoming IPv6. Guillaume Barrot a écrit: Sans rentrer dans la polémique ouais mais ça fait vingt fois qu'on nous le sort Ca fait 20 fois et 20 ans qu'on nous le sort, ID/LOC c'est comme la recherche du Saint Graal. Je n'essaie pas d'empêcher les gens de creuser, mais maintenant ça me fait sourire; moi aussi, je me suis pris pour Indiana Jones. @ @ : : : : : : : : : : : : : : : @ @@@ | | | \|/%%%\|/ | | -t- % -t- | | /|\ \ %%% / /|\ | | \ / %%% \ / | \- | %%% | -/ \ - | %%% | - / \ / \ / \ / \/ --- \/ \ ! ! / \ __ ___ __ ___ ___ / ( ___ ___ __ _ ___ ) (8) --\ - /-- ((o)) \ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _(I)_ __/_\__ /___\ /_\ (___) Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: LISP : besoin d'avis
Alors je vais tenter un petit résumé : - Ya déjà eu des essais de choses similaires et ça n'a jamais pris - L'encapsulation nuit au MTU - C'est implémenté et utilisable pour des problématiques de virtualisation - Manque les protocoles de mapping dynamique pour que ça prenne tout son sens A part le problème de MTU, qu'on a déjà sur tout autre mécanisme de transition utilisant l'encapsulation, il n'y a rien de négatif auquel on ne puisse trouver de solution, et au moins une application concrète qui semble marcher. Donc c'est un WiP prometteur ? Pour ces histoires de MTU, est ce qu'il y a déjà eu des expérimentations concrètes pour essayer de les augmenter ? Quels MTU tiennent nos IX nationaux ? (nan parce que ça ma bien donné envie d'expérimenter les jumbo frames sur not'FAI associatif local et son IX préféré ;) ) @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Re: LISP : besoin d'avis
On Fri, 14 Oct 2011 09:53:30 -0700, Michel Py mic...@arneill-py.sacramento.ca.us said: En plus, c'est une illusion: Dans un gros site, la table entre les locateurs et l'identifiant va être pratiquement aussi grande que la DFZ. Ca tombe bien pour tout ce matos qui n'a plus les ressources de tenir une vraie DFZ (256K routes et bientot les 512K routes). Ca va tenir des mappings internes :) Effet secondaire, a long terme ca permet d'uniformiser le materiel --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Pour ceux qui ont trouvé que DNSSEC était trop simple...
On Wed, Oct 12, 2011 at 07:33:01PM -0700, Michel Py mic...@arneill-py.sacramento.ca.us wrote a message of 38 lines which said: 1. Question d'ignorant à propos de DNSSEC (DNS n'ayant jamais été quelque chose que je connais bien). Est-ce que DNSSEC apporte une valeur ajoutée dans le domaine de la sécurité par la complexité? En d'autres termes: DNSSEC va me stopper parce que je n'y connais rien, mais est-ce que ça va stopper le quidam qui y connait quelque chose. Oui, cela va le stopper. DNSSEC repose sur la cryptographie et la cryptographie permet de fournir ce genre de services. Casser RSA-1024bits est l'une des choses qu'on peut qualifier d'impossible. Évidemment, comme avec tout système de sécurité (ou comme avec les Trois Lois de la Robotique), un malin peut toujours trouver une faille (une bogue dans une implémentation, par exemple). Et DNSSEC ne protège pas contre les attaques GIGO (Garbage In, Garbage Out : si les données envoyées au registre sont celles du pirate, car le mot de passe du client auprès du Bureau d'Enregistrement était simplement ilovestevejobs, le registre va signer des données erronées). Est-ce que RPKI apporte une valeur ajoutée dans le domaine de la sécurité par la complexité ? C'est difficile à dire pour l'instant. Il faut un peu prendre le problème en sens inverse : que fait-on contre les détournements BGP ? Répondre : « rien » n'est pas acceptable. Répondre : « une combinaison de filtres à partir des IRR et de vigilance constante » l'est déjà plus. Il faut donc comparer RPKI non pas avec l'inaction mais avec les autres solutions de sécurité. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: LISP : besoin d'avis
On Fri, Oct 14, 2011 at 09:00:37PM +0200, Jérôme Nicolle jer...@ceriz.fr wrote a message of 29 lines which said: - Ya déjà eu des essais de choses similaires Pour de bonnes raisons, d'ailleurs. La séparation identificateur/localisateur est une bonne idée. A part le problème de MTU, qu'on a déjà sur tout autre mécanisme de transition utilisant l'encapsulation, Tout à fait exact. Pour ces histoires de MTU, est ce qu'il y a déjà eu des expérimentations concrètes pour essayer de les augmenter ? En IPv6, on est souvent amené à la *diminuer* pour arriver à passer tous les pare-feux mal configurés :-( https://www.dns-oarc.net/files/workshop-201010/expose-octobre-2010.pdf Franchement, quand je vois le mal qu'on a à obtenir que les gens déploient IPv6 (un truc simple et qui ne change pas grand'chose), et le fassent correctement, je suis pessimiste pour des techniques très intéressantes, mais bien plus « disruptives » comme LISP ou HIP. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: LISP : besoin d'avis
Le 14/10/2011 22:48, Stephane Bortzmeyer a écrit : En IPv6, on est souvent amené à la *diminuer* pour arriver à passer tous les pare-feux mal configurés :-( Oui enfin tout comme http://xkcd.com/936/ à propos des passwords, on a passé 10 ans à expliquer aux lusers et (l)admins que le ping c'est le mal et qu'il faut bloquer l'ICM tout en bloc pour pas se faire scanner. Va leur désaprendre ça maintenant... Franchement, quand je vois le mal qu'on a à obtenir que les gens déploient IPv6 (un truc simple et qui ne change pas grand'chose), et le fassent correctement, je suis pessimiste pour des techniques très intéressantes, mais bien plus « disruptives » comme LISP ou HIP. Il y a une grosse différence entre le déploiement IPv6 et l'hypothétique déploiement de LISP : on a pas besoin de tous s'y mettre pour que ça marche. Moi j'y vois bien deux ou trois applications pratiques par endroit, principalement pour remplacer des cochoncetés à base de vtun+iptables+bird par quelque chose de plus corporate compliant. J'ai pas pour autant besoin que mes FAI s'y mettent pour l'utiliser à la maison, et pas besoin de refondre tout un réseau d'opérateur pour l'utiliser juste là ou il y aurait son utilité... -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: LISP : besoin d'avis
Pour ces histoires de MTU, est ce qu'il y a déjà eu des expérimentations concrètes pour essayer de les augmenter ? En IPv6, on est souvent amené à la *diminuer* pour arriver à passer tous les pare-feux mal configurés :-( Un papier sur le sujet : http://staff.psc.edu/mathis/MTU/ Je pense que nos collegues du LIP6 ont des trucs dans le meme style sous le coude, mais personne n'ose sortir des MTU 9216 (deja passer un reseau en Jumbo, c'est fun ...). Je suis persuade d'avoir vu passer une commande sur un Cisco ou un Junip avec une MTU allant jusqu'a 16000 et quelques, je vais essayer de retrouver ca. Maintenant, je me dis la chose suivante : si on commence a raisonner sur les mauvaises configurations en essayant d'avancer ... ben on avance juste pas en fait ! Perso, quand je vois certaines configuration de collectes FAI avec quasiment autant d'entete que de payload, je me dis qu'un GRE-like a cote, c'est petit joueur en terme de reduction de taille de payload. (j'ai en tete 1 exemple : ip over ppp over l2tp over deuxieme l2tp over ip. C'est ce qu'on pourrait appeler un WTF-backbone, mais on peut toujours faire pire et rajouter de l'IPSEC par dessus !) A+ Guillaume
