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.
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Fri, Jul 08, 2011 at 03:38:02PM +0200, Rémy Sanchez remy.sanc...@hyperthese.net wrote a message of 39 lines which said: http://code.google.com/p/napt66/ Je ne l'ai pas testé. Fail : c'est Network Address PORT Translation. Ah zut, j'avais pas fait attention. Je corrige mon article, merci. --- Liste de diffusion du FRnOG http://www.frnog.org/
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/
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Mon, Jul 04, 2011 at 08:37:47AM +0200, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote a message of 17 lines which said: Parce qu'en v6 on peut toujours scanner tout l'espace d'addressage plusieurs fois par mois, comme en v4 ? C'est plus dur en v6 mais pas impossible. RFC 5157 http://www.bortzmeyer.org/5157.html --- 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/
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Mon, 4 Jul 2011 09:04:31 +0200, Stephane Bortzmeyer bortzme...@nic.fr said: C'est plus dur en v6 mais pas impossible. RFC 5157 http://www.bortzmeyer.org/5157.html Sauf mour la mehtode P2P, ce n'est pas comme ca que l'ordi familial de la famille Michu fonctionne. Les privacy extensions sont utilises et abuses par default. --- 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
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Thu, Jun 30, 2011 at 08:11:54PM -0700, Michel Py mic...@arneill-py.sacramento.ca.us wrote a message of 19 lines which said: j'ai décrit en détail ce mécanisme (soumis draft-py-multi6-mhtp-00.txt, qui a évolué en draft-py-mhap-01a.txt). Ni tools.ietf.org, ni le Datatracker ne semblent pouvoir les retrouver. Un URL ? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Fri, Jul 01, 2011 at 09:53:49AM +0200, Raphaël Jacquot sxp...@sxpert.org wrote a message of 29 lines which said: j'y vois au moins trois inconvénients Mathieu Goessens a bien répondu à cet über-trollage. J'ajoute : * ca ne sécurise pas mieux que le NAT en v4 Il faudrait lire le RFC qui dit clairement que : 1) Le NAT en v4 ne sécurise guère, 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.) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Fri, Jul 01, 2011 at 09:59:32AM +0200, MM mm...@palpix.com wrote a message of 23 lines which said: ça peut éviter pas mal de bordel si le CPE fait un minimum pour que les réseaux domestiques fuitent, non ? La question est discutée. L'état de l'art est dans le RFC 6092 http://www.bortzmeyer.org/6092.html. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Fri, Jul 01, 2011 at 02:17:03PM +0200, Alain Richard alain.rich...@equation.fr wrote a message of 160 lines which said: un linux implémentant ce RFC. http://code.google.com/p/napt66/ Je ne l'ai pas testé. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Fri, Jul 01, 2011 at 07:20:33AM -0700, Michel Py mic...@arneill-py.sacramento.ca.us wrote a message of 18 lines which said: 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. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Fri, Jul 01, 2011 at 10:19:02AM +0200, Raphaël Jacquot sxp...@sxpert.org wrote a message of 21 lines which said: auquel cas, c'est un firewall configurable par l'utilisateur qu'il faut mettre dans le CPE, et pas ce bricolage de NAT C'est précisement ce que dit le RFC 6296 : il faut traiter l'adressage et la sécurité séparement. NPT (alias NAT66), spécifié dans le RFC 6296, ne traite que l'adressage (et s'en vante). --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Fri, Jul 01, 2011 at 08:28:44AM +0200, Guillaume Barrot guillaume.bar...@gmail.com wrote a message of 44 lines which said: truc comme lisp (lui aussi en draft) Justement, NPTv6 n'est pas en Internet-Draft, le RFC est sorti. Compte-tenu du travail que représente le déploiement de LISP (et surtout de sa fonction de mapping, pour laquelle pas grand'chose n'a été fait), NPTv6, bien plus simple et déployable, lui, de manière unilatérale, a ses chances. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Sun, Jul 03, 2011 at 09:37:46PM +0100, Thomas Mangin thomas.man...@exa-networks.co.uk wrote a message of 8 lines which said: http://tools.ietf.org/id/draft-py-multi6-mhtp-00.txt ? Je n'avais cherché que le plus récent, draft-py-mhap, et rien trouvé. --- Liste de diffusion du FRnOG http://www.frnog.org/
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/
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Fri, Jul 01, 2011 at 02:07:49PM +0200, Alain Richard alain.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. - est-ce normal docteur que mes postes aient une adresse publique ? Dr-HouseOui/Dr-House Le monde IPv6 serait tellement plus simple si on avait un consensus pour adresser notamment : Pourquoi aurait-on un consensus qu'on n'a pas en IPv4 ? (Et, en IPv4, lorsqu'il existe un consensus, il est souvent foireux, comme lorsque beaucoup d'administrateurs réseaux croient que le NAT les protège. Le consensus des ignorants ne me rassure pas.) Il y a des réseaux différents, des moyens différents, des risques différents, des cahiers des charges différents, il est tout à fait normal que les choix soient différents. C'est pour cela qu'on a besoin d'administrateurs réseaux compétents, capables de faire leur marché dans la boîte à outils existante, et pas de certifiés qui ne savent qu'appuyer sur un bouton. - la sécurité de base, surtout pour la TPE et le particulier La sécurité n'a jamais été un sujet consensuel. http://www.bortzmeyer.org/6092.html --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On Sat, Jul 02, 2011 at 11:19:02AM -0700, Michel Py mic...@arneill-py.sacramento.ca.us wrote a message of 62 lines which said: un hôte IPv6 peut avoir plusieurs adresses IPv6; tu crées un VLAN pour chaque FAI IPv6, et chaque PC a une adresse pour chaque FAI (dans le préfixe fourni par le FAI ou le tunnel broker). Cela veut dire que le choix de l'adresse IP source (et donc le FAI utilisé) est laissé à l'ordinateur individuel. Pas mal d'administrateurs réseaux préféreraient sans doute que ce choix soit centralisé dans le(s) routeur(s) de sortie, ce que permet NPTv6. --- 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/
