Re: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Sunday 03 July 2011 22:39:53 Stephane Bortzmeyer wrote: http://code.google.com/p/napt66/ Je ne l'ai pas testé. Fail : c'est Network Address PORT Translation. Le même qu'en IPv4 : « IPv6-to-IPv6 Network Address Port Translation (NAPT66) is a stateful IPv6 NAT mechanism. Just like IPv4 NAT, NAPT66 technique makes several hosts share a public IPv6 address. As a result, NAPT66 helps to hide the private network topology and promote network security. » -- Rémy Sanchez signature.asc Description: This is a digitally signed message part.
Re: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Sun, 03 Jul 2011 23:46:28 +0200, e-t172 e-t...@akegroup.org said: À l'époque ou la plupart des gens avaient une adresse publique sur leur PC, les attaques se faisaient bien par connexion directe (exemple : Blaster). Si, avec IPv6, tout le monde récupère à nouveau des adresses publiques non protégées, je te parie ma chemise que la vermine va de nouveau exploiter ce vecteur de transmission. Parce qu'en v6 on peut toujours scanner tout l'espace d'addressage plusieurs fois par mois, comme en v4 ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
Bonjour, 2011/7/3 e-t172 e-t...@akegroup.org Il est un peu facile cet argument. Si les attaques ne se font pas par connexion IP directe c'est justement parce que le pékin moyen (ou plutôt devrais-je dire « victime moyenne ») a une box de FAI qui, justement, fait du NAT et ne laisse donc pas passer par défaut les connexions entrantes. Il est possible de bloquer les connexions entrantes sans faire du NAT. Ca s'appelle du filtrage. Voir à ce sujet la RFC 6204 (Basic Requirements for IPv6 Customer Edge Routers) présentée ici il y a une paire de mois. À l'époque ou la plupart des gens avaient une adresse publique sur leur PC, les attaques se faisaient bien par connexion directe (exemple : Blaster). Si, avec IPv6, tout le monde récupère à nouveau des adresses publiques non protégées, je te parie ma chemise que la vermine va de nouveau exploiter ce vecteur de transmission. La plupart des systèmes modernes (supportant IPv6) utilisés par des particuliers fournissent en standard un pare-feu qui bloque par défaut les connexions entrantes. Quoique j'imagine qu'en IPv6 certains ports (partage de fichiers?) vont être ouvert sur le lien local ou aux connexions provenant du même préfixe. Le principal problème est que, apparemment, il subsiste des gens qui ne comprennent pas qu'un simple pare-feu qui filtre les connexions entrantes offre une sécurité exactement identique à un NAT IPv4 typique, mais avec des inconvénients en moins. Parce que même si le NAT permet de filtrer les connexions entrantes, le pare-feu offre des avantages en plus? Personnellement, je suis un fervent partisan du End-to-End Principle, et par conséquent, je milite pour que ce genre de filtrage de connexions se fasse sur la machine finale, pas sur un nœud du réseau, parce que ça permet d'utiliser un pare-feu applicatif qui est bien mieux placé pour prendre ces décisions qu'une boite noire branchée sur un câble. Et qu'on ne vienne pas me dire que c'est pas Michu-compliant : la configuration par défaut du pare-feu de Windows depuis XP SP2 offre une sécurité au moins équivalente à un NAT. Mais j'imagine que c'est là encore une idée à ranger dans le monde des bisounours. Comment peut-on être partisan du End-to-End Principle *et* du NAT? Est-ce que ce n'est pas antinomique? -- Cdlt B. Garcia --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On 07/04/2011 08:45 AM, Benoit Garcia wrote: Personnellement, je suis un fervent partisan du End-to-End Principle, et par conséquent, je milite pour que ce genre de filtrage de connexions se fasse sur la machine finale, pas sur un nœud du réseau, parce que ça permet d'utiliser un pare-feu applicatif qui est bien mieux placé pour prendre ces décisions qu'une boite noire branchée sur un câble. Et qu'on ne vienne pas me dire que c'est pas Michu-compliant : la configuration par défaut du pare-feu de Windows depuis XP SP2 offre une sécurité au moins équivalente à un NAT. Mais j'imagine que c'est là encore une idée à ranger dans le monde des bisounours. Comment peut-on être partisan du End-to-End Principle *et* du NAT? Est-ce que ce n'est pas antinomique? C'est surtout que tu as lu totalement de travers mon message. Où est-ce que tu as lu que je suis partisan du NAT ? C'est exactement le contraire ! Je suis tout à fait opposé à toute forme de NAT, ça ne m'empêche pas de critiquer les arguments (comme celui de Stéphane) que je trouve invalides, même si ils vont dans mon sens. On ne peut pas avoir une discussion ici sans devoir choisir son camp ? Il est un peu facile cet argument. Si les attaques ne se font pas par connexion IP directe c'est justement parce que le pékin moyen (ou plutôt devrais-je dire « victime moyenne ») a une box de FAI qui, justement, fait du NAT et ne laisse donc pas passer par défaut les connexions entrantes. Il est possible de bloquer les connexions entrantes sans faire du NAT. Ca s'appelle du filtrage. Oui, c'est ce que j'ai dit deux paragraphes plus bas dans mon message. À l'époque ou la plupart des gens avaient une adresse publique sur leur PC, les attaques se faisaient bien par connexion directe (exemple : Blaster). Si, avec IPv6, tout le monde récupère à nouveau des adresses publiques non protégées, je te parie ma chemise que la vermine va de nouveau exploiter ce vecteur de transmission. La plupart des systèmes modernes (supportant IPv6) utilisés par des particuliers fournissent en standard un pare-feu qui bloque par défaut les connexions entrantes. C'est pour ça que j'ai précisé non protégées. Le principal problème est que, apparemment, il subsiste des gens qui ne comprennent pas qu'un simple pare-feu qui filtre les connexions entrantes offre une sécurité exactement identique à un NAT IPv4 typique, mais avec des inconvénients en moins. Parce que même si le NAT permet de filtrer les connexions entrantes, le pare-feu offre des avantages en plus? Le NAT a pour inconvénient principal de modifier les adresses source et destination des paquets qui passent par lui. Le pare-feu n'a pas cet inconvénient, tout en gardant la possibilité de filtrer les connexions entrantes. D'où pare-feu NAT. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
Le 4 juil. 2011 à 08:37, Radu-Adrian Feurdean a écrit : Parce qu'en v6 on peut toujours scanner tout l'espace d'addressage plusieurs fois par mois, comme en v4 ? si tu veux une adresse fiable, il te suffit de faire un spam avec une belle image : le client se fera un plaisir de venir chez toi chercher la belle image et te donner au passage une adresse ipv6 fiable... Bon d'accord, avec des adresses temporaires (RFC 3041), les adresses récupérées ont une durée de vie limitée (quand même une semaine), mais cela est bien suffisant pour une attaque. La sécurité par offuscation n'est pas, et n'a jamais été, une solution de sécurisation, et ce n'est pas les 2^64 adresses d'IPV6 qui vont changer ça. Cordialement, -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr
Re: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
Plus sérieusement, pourquoi vouloir limiter cette solution (le multihomage) à ceux qui ont « une raison valable » ? À la maison, je suis multihomé (3G Bouygues, 3G Orange et ADSL Free) et, plus d'une fois, cela m'a sauvé la mise. Moi aussi je suis multihome, DSL et 3G backup avec les même IPs sur les deux services :p Oui c'est possible d'avoir les réseaux mobile vous donner une terminaison L2TP - c'est juste dur :p Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
C'est pas multihome au sens IP ça. William Gacquer Le 3 juil. 2011 à 22:48, Thomas Mangin thomas.man...@exa-networks.co.uk a écrit : Plus sérieusement, pourquoi vouloir limiter cette solution (le multihomage) à ceux qui ont « une raison valable » ? À la maison, je suis multihomé (3G Bouygues, 3G Orange et ADSL Free) et, plus d'une fois, cela m'a sauvé la mise. Moi aussi je suis multihome, DSL et 3G backup avec les même IPs sur les deux services :p Oui c'est possible d'avoir les réseaux mobile vous donner une terminaison L2TP - c'est juste dur :p Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
Stephane Bortzmeyer a écrit: 2) NPT v6 ne prétend pas sécuriser mieux que le NAT v4, le RFC dit clairement que NPT v6 ne sécurise pas du tout ! (Ce n'est pas son rôle.) On est bien d'accord, et c'est du en grande partie au fait que les ports ne sont pas utilisés et qu'il n'y a pas d'état. Michel Py a écrit: Si tu as une raison valable d'être multihomé, Personnellement, je pense que le droit au multihomage est un droit de l'homme fondamental. Plus sérieusement, pourquoi vouloir limiter cette solution (le multihomage) à ceux qui ont « une raison valable » ? À la maison, je suis multihomé (3G Bouygues, 3G Orange et ADSL Free) et, plus d'une fois, cela m'a sauvé la mise. Tu devrais lire mes drafts d'il y a 10 ans :P comme objectif officiel on avait 1 milliard de sites multihomés. Je n'avais cherché que le plus récent, draft-py-mhap, et rien trouvé. Celui-là il n'a pas été soumis par le circuit officiel. C'était bien rigolo: on piratait les salles de l'hôtel de l'IETF pour faire no petites réunions du WG non-officiel... http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-intro-00.txt http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt C'est très mal écrit; le draft en l'état est une collection de copier/coller, je n'ai jamais fini le nouveau draft. A lire vite, plutôt regarder les exemples. En bref: si RFC6296 c'est NAT66, MHAP c'est NAT66-66, la deuxième occurrence étant exactement l'inverse de la première. Avec un voyage dans le temps, RFC6296 aurait été un précurseur de MHAP. Dans le contexte de l'époque: pas encore de ULA et les adresses site-local en train d'être dé-commissionnées, d'ou le choix des adresses géographiques. Autres reliques de cette époque: http://arneill-py.sacramento.ca.us/ipv6mh/ Il y a quelques trucs intéressants, comme le précurseur de GSE (8+8) Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On 2011-07-03 22:54, Stephane Bortzmeyer wrote: On Fri, Jul 01, 2011 at 02:07:49PM +0200, Alain Richardalain.rich...@equation.fr wrote a message of 226 lines which said: f - La plupart des petits utilisateurs s'appuient sur le NAT44 pour sécuriser leur accès C'est un fait, mais cela n'empêche pas qu'ils ont tort et sérieusement tort. Je rappelle que Stuxnet n'a même pas eu besoin d'une connexion Internet pour infecter le site visé, alors croire qu'on est protégé par NAT44, alors que la plupart des attaques se font par charge utile et pas par connexion IP de l'extérieur, c'est de l'acte de foi, pas de la science. Il est un peu facile cet argument. Si les attaques ne se font pas par connexion IP directe c'est justement parce que le pékin moyen (ou plutôt devrais-je dire « victime moyenne ») a une box de FAI qui, justement, fait du NAT et ne laisse donc pas passer par défaut les connexions entrantes. À l'époque ou la plupart des gens avaient une adresse publique sur leur PC, les attaques se faisaient bien par connexion directe (exemple : Blaster). Si, avec IPv6, tout le monde récupère à nouveau des adresses publiques non protégées, je te parie ma chemise que la vermine va de nouveau exploiter ce vecteur de transmission. Le principal problème est que, apparemment, il subsiste des gens qui ne comprennent pas qu'un simple pare-feu qui filtre les connexions entrantes offre une sécurité exactement identique à un NAT IPv4 typique, mais avec des inconvénients en moins. Personnellement, je suis un fervent partisan du End-to-End Principle, et par conséquent, je milite pour que ce genre de filtrage de connexions se fasse sur la machine finale, pas sur un nœud du réseau, parce que ça permet d'utiliser un pare-feu applicatif qui est bien mieux placé pour prendre ces décisions qu'une boite noire branchée sur un câble. Et qu'on ne vienne pas me dire que c'est pas Michu-compliant : la configuration par défaut du pare-feu de Windows depuis XP SP2 offre une sécurité au moins équivalente à un NAT. Mais j'imagine que c'est là encore une idée à ranger dans le monde des bisounours. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
