Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
Pour les ignorants comme moi, tu peux rappeler rapidement ce que sont les ERX car je ne trouve pas d’informations sur le RIPE, à part des histoires de transfert de vieux blocs depuis ARIN ou le RIPE vers le RIR local (AFRINIC par exemple). Le 22 sept. 2014 à 22:46, Jérôme Nicolle jer...@ceriz.fr a écrit : Bonjour à tous, Avec la raréfaction des ressources IPv4, on commence à être un paquet à lorgner sur des /16 ERX qui n'ont jamais été annoncés de mémoire de RIS. Il parait qu'il y a des cas de figure ou l'on peut légitimement réserver un bloc sans le router, hors des blocs réservés (RFC 990, 1700, 1918, 2544, 3068, 3927, 5737, 5771, 6333, 6598 et 6890). On m'a cité, en vrac : - Pour des VPN [non publics] - Pour des réseaux privés susceptibles de s'interconnecter à d'autres réseaux [non publics] - Pour éviter d'avoir à renuméroter quand tout le monde est en 1918 et doit s'interconnecter Bref, que des cas de réseaux non connectés à Internet (par définition, puisque les adresses ne sont pas routées). Mais pourquoi donc utiliser des blocs enregistrés auprès de l'IANA ou d'un RIR ? Le problème de base est celui de l'unicité de l'adresse. Le registre global d'Internet est bien géré et permet de garantir qu'un bloc n'est pas assigné deux fois. Autant utiliser un registre existant, non ? Mais ça, c'était avant. Là, il y a pénurie. Un réseau d'entreprise, d'administration ou de recherche, n'a pas forcement vocation à _faire partie_ d'Internet. Mais on va bien volontiers s'y interconnecter pour bénéficier de quelques services présents sur ce dernier. Deux possibilités : - NAT : dans ce cas le masquage d'adresses publiques par des adresses du réseau privé est un problème bien réel dans certains réseaux qui ont numéroté au pif sans respecter les RFC. - Passerelles applicatives : les proxy sont parfaits pour lier le web, le mail, la voix et bien d'autres services dès lors qu'ils sont nommés au moyen d'un espace sans collision, c'est à dire par DNS et non par adresses littérales. Alors, si le resolver interne ne connait pas la zone, il répond l'adresse d'un proxy qui lui résout via la racine correspondante. J'y vois d'ailleurs un autre avantage : ça permet d'avoir une chaine de confiance intégrale dans l'ensemble du réseau, puisqu'on peut déployer RPKI+ROA et DNSSEC, voir systématiser SSL quitte à recourir aux proxy, de bout en bout dans un environnement contrôlé bien plus facilement qu'on ne le ferait sur Internet. Il est donc techniquement facile d'interconnecter les services de deux réseaux, mais pas possible simplement d'interconnecter les réseaux eux-même. C'est presque heureux puisqu'on va souvent, dans le cas de l'interconnexion de deux réseaux, vouloir contrôler un peu ce qui passe de l'un à l'autre (log des proxy). C'est d'autant plus heureux qu'un réseau bien conçu, avec adressage et nommage donc, sera facile à renuméroter. Il y a d'ailleurs même au moins un protocole basé sur le concept de séparation de l'adresse logique et physique : LISP (RFC 6830). Du coup, la fusion de deux réseaux dont les adressages peuvent être en collision passe logiquement par une étape préalable (voir qui aurait du avoir lieu bien avant) : virer les adresses en dur, tout nommer sur le DNS. C'est d'ailleurs une recommandation forte, à défaut d'être considéré comme obligatoire, pour le déploiement d'IPv6 en entreprise. De la même façon, la tenue d'un registre des allocations, du genre avec génération dynamique des zones DNS, s'impose rapidement. Le tableau excel montre trop vite ses limites. C'est une bonne pratique pour tout administrateur réseau, privé ou public, non ? (un appeau à commercial efficient-IP est caché dans ce paragraphe, saurez vous le trouver ?) Reste le cas de l'historique : Avant, il n'y avait pas de NAT. Avant, les proxy étaient chers. Avant, il y avait plein d'adresses. Mais ça... On ne change pas quelque chose qui marche. C'est d'ailleurs bien une des raisons pour lesquelles IPv6 peine à arriver sur le LAN. Depuis ces allocations, on peut légitimement se demander si tout le reste du réseau n'a pas été refait de fond en combles, et que seul l'adressage reste un vestige d'une époque bénie. Après tout, des machines qui ne supportent pas CIDR, ni le NAT, ni le nommage DNS, ni IPv6, c'est tellement vieux que c'est même plus sous contrat de maintenance, donc qu'on ne peut plus les utiliser dans une entreprise sérieuse, non ? Du coup, quand on me dit qu'il est normal d'adresser un LAN _non connecté à Internet_ avec des IP publiques, que dois-je en déduire ? Bref, ces ERX et autres reliquats, on vote tous pour leur destruction à la prochaine AG du RIPE ? @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
Et donc le problème est que le RIPE ne sait pas qui utilise exactement quoi dans un /16 de ce genre, c’est ça ? Si j’en crois RIPEDB d’ailleurs: # whois -h whois.ripe.net -M 158.156.0.0/16 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the -B flag. % Information related to '158.156.155.0/24AS8220' route: 158.156.155.0/24 descr: CDCGROUPNET origin: AS8220 mnt-by: COLT-FR-MNT source: RIPE # Filtered % Information related to '158.156.162.0/24AS8220' route: 158.156.162.0/24 descr: Route Object origin: AS8220 mnt-by: COLT-FR-MNT source: RIPE # Filtered % Information related to '158.156.172.0/24AS8220' route: 158.156.172.0/24 descr: CDCGROUPNET origin: AS8220 mnt-by: COLT-FR-MNT source: RIPE # Filtered % Information related to '158.156.182.0/24AS8220' route: 158.156.182.0/24 descr: CDCGROUPNET origin: AS8220 mnt-by: COLT-FR-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.75 (DB-1) Hmmm si cela signifie que la CDC n’utilise que 4 /24 dans le /16, c’est effectivement un problème :) Sinon, je vois un lien dans l’enregistrement inetnum du /16: http://www.ripe.net/projects/erx/erx-ip/network-158.html donc je clique dessus naïvement et paf, 404…. C’est pas gagné-gagné. Le 23 sept. 2014 à 10:31, Jérôme Nicolle jer...@ceriz.fr a écrit : Salut David, Le 23/09/2014 07:58, David Ponzone a écrit : Pour les ignorants comme moi, tu peux rappeler rapidement ce que sont les ERX car je ne trouve pas d’informations sur le RIPE, à part des histoires de transfert de vieux blocs depuis ARIN ou le RIPE vers le RIR local (AFRINIC par exemple). Pas de souci. Les ERX sont peu documentés vu que les transferts ont eu lieu il y a un bail maintenant. Ce sont bien les transferts de blocs historiques qui sont enregistrés ERX à l'IANA. Ces enregistrements ont tous été délégués à l'ARIN qui les a ensuite délégué aux RIR appropriés, avec la charge de contractualiser et mettre à jour les infos. Exemple : NetRange: 158.156.0.0 - 158.156.255.255 CIDR: 158.156.0.0/16 OriginAS: NetName:RIPE-ERX-158-156-0-0 NetHandle: NET-158-156-0-0-1 Parent: NET-158-0-0-0-0 NetType:Early Registrations, Transferred to RIPE NCC Comment:These addresses have been further assigned to users in Comment:the RIPE NCC region. Contact information can be found in Comment:the RIPE database at http://www.ripe.net/whois ... C'est donc l'ARIN qui a répondu en disant que le bloc est de la responsabilité du RIPE. Le whois interoge donc le RIPE dans la foulée, ce qui donne : inetnum:158.156.0.0 - 158.156.255.255 status: LEGACY remarks:For information on status: attribute read https://www.ripe.net/data-tools/db/faq/faq-status-values-legacy-resources remarks: remarks:This inetnum has been transfered as part of the ERX. remarks:It was present in both the ARIN and RIPE databases, so remarks:the information from both databases has been merged. remarks:If you are the mntner of this object, please update it remarks:to reflect the correct information. remarks: remarks:Please see the information for this process: remarks:http://www.ripe.net/projects/erx/erx-ip/network-158.html ... -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
On Tue, 2014-09-23 at 11:24 +0200, David Ponzone wrote: Hmmm si cela signifie que la CDC n’utilise que 4 /24 dans le /16, c’est effectivement un problème :) Ca signifie juste que la CDC n'utilise que 4 /24 *publiquement*, dans ce /16, et ca n'indique pas que le reste n'est pas/plus utilisé en interne. C'est pareil chez EDF par exemple, ils ont l'équivalent (de mémoire) d'un /13 en blocs PI, dont seulement un pouillème se retrouve annoncé dans la DFZ Internet... Le problème avec ce genre de raisonnements, c'est que pour leur éviter de se faire emmerder, ils (les titulaires de blocs du marais/erx/legacy/whatever) pourraient juste se contenter d'annoncer la route, sans pour autant l'utiliser de facon effective... et continuer de l'utiliser en privé. -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
On Mon, Sep 22, 2014, at 22:46, Jérôme Nicolle wrote: - Pour des VPN [non publics] - Pour des réseaux privés susceptibles de s'interconnecter à d'autres réseaux [non publics] - Pour éviter d'avoir à renuméroter quand tout le monde est en 1918 et doit s'interconnecter Bref, que des cas de réseaux non connectés à Internet (par définition, Les gens ont tendance a confondre publiquement accessible sur Internet avec globallement unique. Les adresses aloues par les RIR (et avant eux par IANA directement) n'ont pas necessairement vocation a etre publiques. Leur vocation est celle d'etre globallement uniques. Permier pas sera donc d'arreter de parler IP publique / IP prive ici meme. puisque les adresses ne sont pas routées). Mais pourquoi donc utiliser des blocs enregistrés auprès de l'IANA ou d'un RIR ? Par ignorance ? Parce-qu'a la base Internet n'etait pas juste le reseau du porn, spam, warez, malware et DoS, mais une interconnexion de plusieurs reseaux. De nos jour, l'aspect interconnexion etre reseaux ne partageant pas les meme politiques a ete un peu oubliee. Ah, tiens, si on mettait les serveurs DNS/AD de la bien-aimee zone .local dans une des reseaux suivants: - 192.36.148.0/24 - 192.112.36.0/24 - 192.5.5.0/24 (joli !!!) - 192.228.79.0/24 - plein d'autres reseaux commencant par 192.petit numero Huh quoi ? 192.*.*.* c'etait pas tout reserve pour des IP privees ??? Le problème de base est celui de l'unicité de l'adresse. Le registre global d'Internet est bien géré et permet de garantir qu'un bloc n'est pas assigné deux fois. Autant utiliser un registre existant, non ? Mais ça, c'était avant. Là, il y a pénurie. Penurie de quoi ? D'adresses RFC1918 ? C'est hyper-rare. Parce-que le reflexe a la mode aujourd'hui, c'est de mettre systematiquement et sans possibilite d'appel des RFC1918 partout. Le NAT c'est bien-sur le holy grail, meme pour des services qui doivent etre accessibles depuis l'internet par design. - NAT : dans ce cas le masquage d'adresses publiques par des adresses du réseau privé est un problème bien réel dans certains réseaux qui ont numéroté au pif sans respecter les RFC. Parfois aussi dans d'autres qui respectent au moins le RFC1918. - Passerelles applicatives : les proxy sont parfaits pour lier le web, le mail, la voix et bien d'autres services dès lors qu'ils sont nommés au moyen d'un espace sans collision, c'est à dire par DNS et non par Notre produit fait tout (sauf les choses auxquelles le marketing n'a pas pense. Expliquer aussi SSH au marketing que le sans le trafic marque rouge-danger dans l'IDP/IPS/FWNG (coucou PaloAlto) il y a des gens (dont les marketeux eux-memes) qui vont au pole emploi. J'y vois d'ailleurs un autre avantage : ça permet d'avoir une chaine de confiance intégrale dans l'ensemble du réseau, puisqu'on peut déployer RPKI+ROA et DNSSEC, voir systématiser SSL quitte à recourir aux proxy, de bout en bout dans un environnement contrôlé bien plus facilement qu'on ne le ferait sur Internet. ??? Il est donc techniquement facile d'interconnecter les services de deux réseaux, mais pas possible simplement d'interconnecter les réseaux eux-même. Quoi qu'il arrive, ca finit toujours par la casse des bien detestees addresses publiques^Wglobalement uniques. de l'un à l'autre (log des proxy). C'est d'autant plus heureux qu'un réseau bien conçu, avec adressage et nommage donc, sera facile à renuméroter. Il y a d'ailleurs même au moins un protocole basé sur le concept de séparation de l'adresse logique et physique : LISP (RFC 6830). On ne doit pas vivre sur la meme planete. Sur la mienne, le permier consultat externe qui passe (et qui a forcement raison, parce-qu'il est consultant) va expliquer les bien-faits des addresses IP en dur et de l'addressage RFC1918, meme pour des services qui DOIVENT etre exposes a des tiers. avoir lieu bien avant) : virer les adresses en dur, tout nommer sur le DNS. C'est d'ailleurs une recommandation forte, à défaut d'être considéré comme obligatoire De ce cote de l'univers, il y a plutot le DSI qui decrete on touche rien; ca fait 10 ans que ca marche comem ca et c'est tres bien. pour le déploiement d'IPv6 en entreprise. IPvquoi ? Dans la meme serie: 640K should be enough for everyone. Mon reseau IPX repond a tous nos besoins. Je vois pas l'interet de l'IP. En plus ,de nos jours on m'explique que Il va falloir attendre longtemps avant qu'un client (TPE/PME) demande de l'IPv6, et que donc pas besoin. Après tout, des machines qui ne supportent pas CIDR, ni le NAT, ni le nommage DNS, ni IPv6, c'est tellement vieux que c'est même plus sous contrat de maintenance, donc qu'on ne peut plus les utiliser dans une entreprise sérieuse, non ? La machine, oui,ok. Par contre l'appli qui tourne dessus, c'est parfois une totalement autre histoire. Du coup, quand on me dit qu'il est normal d'adresser un LAN _non connecté à Internet_ avec des IP publiques, que dois-je en déduire ? non
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
Le 23/09/14 13:11, Radu-Adrian Feurdean a écrit : Bref, ces ERX et autres reliquats, on vote tous pour leur destruction à la prochaine AG du RIPE ? Non. Yep, tout ça ressemble à une énième chasse aux sorcières en période de pénurie... Je rebondis là dessus du coup. Si les gens mettaient plus d'énergie à déployer IPv6 qu'à chercher des méthodes pour continuer en IPv4, on serait déjà dans le futur. Alors on va dire que beaucoup n'ont pas de problème en IPv4 et ne vont pas faire l'effort de déployer IPv6 et qu'à cause d'eux les autres doivent bien trouver des solutions, mais bon le jour où ces gens se sentiront un peu seuls et derniers de la classe, ça se passera peut-être mieux aussi. Au passage, pas merci aux FAIs qui devraient être les moteurs dans l'histoire parce que leurs eyeballs ont de la valeur pour basculer vers IPv6 aussi, pas juste pour le peering. D'ailleurs comme l'argent est souvent le facteur bloquant, l'état devrait favoriser les FAIs qui fournissent de l'IPv6 aux français et pénaliser les FAIs qui ne le font pas. Le combat se situe là pour moi, les fournisseurs de contenu suivront plus facilement derrière et les gens qui ont besoin de plus d'IPs sont souvent dans ces 2 secteurs. Bien sûr je prends l'exemple de la France, mais ça s'applique à l'Europe tout aussi bien. Avec ces axes on pourrait avancer : - L'Etat/Europe subventionne un peu les FAIs qui fournissent IPv6 et mettent une amende à ceux en retard - Les FAIs refusent de peerer avec les gens qui ne font pas de trafic IPv6 Ca bougerait surement un peu plus de cette manière et on éviterait de bricoler IPv4 continuellement parce que passer à IPv6 n'est pas important pour le business. Les IX pourraient aussi jouer un rôle en offrant une tarification plus avantageuse aux gens qui décident de peerer sur les RS IPv6, pourquoi pas... C'est un peu subjectif et difficile à défendre, mais ça montre un certain engagement. Après y'aura toujours des gens pour tricher et juste monter la session et annoncer un préfixe, mais a contrario ça donne aussi rapidement l'impression qu'IPv6 s'est généralisé et qu'on y arrive. Peut-être ce genre de discussion pourrait être à creuser plus que comment on peut récupérer des IPv4 non ? My 2 cents, Frédéric --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
On Tue, 2014-09-23 at 13:55 +0200, Frederic Dhieux wrote: Je rebondis là dessus du coup. Si les gens mettaient plus d'énergie à déployer IPv6 qu'à chercher des méthodes pour continuer en IPv4, on serait déjà dans le futur. +1000 Pour moi, il faut laisser les vieux blocs où ils sont. Et surtout ne pas chercher à les récupérer/réutiliser pour donner un énième sursis à IPv4. -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Adresses publiques non annoncées : légitime ou pas ?
On Mon, Sep 22, 2014 at 10:46:34PM +0200, Jérôme Nicolle jer...@ceriz.fr wrote a message of 102 lines which said: - Pour des réseaux privés susceptibles de s'interconnecter à d'autres réseaux [non publics] - Pour éviter d'avoir à renuméroter quand tout le monde est en 1918 et doit s'interconnecter Ce sont, à mon avis, les meilleures raisons. Les neuneus qui numérotent en RFC 1918 seront bien marris quand la fusion/acquisition sera venue. Du coup, la fusion de deux réseaux dont les adressages peuvent être en collision passe logiquement par une étape préalable (voir qui aurait du avoir lieu bien avant) : virer les adresses en dur, tout nommer sur le DNS. Je suggère de lire d'abord le RFC 5887. Par exemple, la config des ACL dans le pare-feu va être faite avec des noms et pas des adresses IP ? http://www.bortzmeyer.org/5887.html Bref, ces ERX et autres reliquats, on vote tous pour leur destruction à la prochaine AG du RIPE ? Non. Laissons IPv4 tranquille, aucune raison de persécuter les malheureux qui l'utilisent encore, et occupons-nous du protocole d'aujourd'hui (IPv6). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
On Tue, Sep 23, 2014, at 13:11, Radu-Adrian Feurdean wrote: Les gens ont tendance a confondre publiquement accessible sur Internet avec globallement unique. ... puisque les adresses ne sont pas routées). Mais pourquoi donc utiliser des blocs enregistrés auprès de l'IANA ou d'un RIR ? Par ignorance ? Parce-qu'a la base Internet n'etait pas juste le reseau du porn, spam, warez, malware et DoS, mais une interconnexion de plusieurs reseaux. De nos jour, l'aspect interconnexion etre reseaux ne partageant pas les meme politiques a ete un peu oubliee. Pour clarifier un peu mes propos, imaginez un instant une entite (boite, administration, .), qui n'a variment rien a faire de l'Internet (le vrai), mais qui doit s'interconnecter avec quelques centaines (voire milliers) d'entites externes. Une partie de ces entites sont de taille comparable, voire parfois superieure. Traduction barbare : mon 10.10.10.1 doit parler avec ton 10.10.10.2 x 1000. Bien-sur dans chaque cas, il y a X adresses d'un cote qui doivent communiquer avec Y adresses de l'autre, et que bien-sur, ca se passe pas dans un seul endroit, mais dans plusieurs. Les autres entites connectes ne veulement pas se parler entre eux non-plus (ou pas via l'entite a laquelle se conenctent tous). Les interconnectes etant divers et varies, certains peuvent bien vouloir interconnecter toute ou une partie de leur infra au vrai Internet, certains non. On a de facto un internet parallele, avec les bonnes pratiques et l'experience du vrain internet en moins. Sauf si l'entite en question decide justement d'utiliser toute la connaissance aquise sur le vrai Internet et de la transposer sur le sien. Voila comment on peut arriver a utiliser des adresses globalement uniques (aussi connues sur le nom IPs publiques) pour des reseaux qui ne sont pas visibles sur le vrai Internet. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
On Tue, 2014-09-23 at 14:25 +0200, Radu-Adrian Feurdean wrote: On a de facto un internet parallele, avec les bonnes pratiques et l'experience du vrain internet en moins. Sauf si l'entite en question decide justement d'utiliser toute la connaissance aquise sur le vrai Internet et de la transposer sur le sien. (...) - Et ce n'est pas juste un cas d'école, ca existe vraiment, j'ai bossé sur certains réseaux dans ce genre genre (réseaux financiers, notamment). Il n'y a pas que des IP du marais là dedans, il y a même des IP de LIR ou des blocs PI récents. -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
Remarque c’est pas con si tu veux augmenter ta productivité: tu numérotes en interne avec les IP de Facebook :) Le 23 sept. 2014 à 14:33, Clement Cavadore clem...@cavadore.net a écrit : On Tue, 2014-09-23 at 14:25 +0200, Radu-Adrian Feurdean wrote: On a de facto un internet parallele, avec les bonnes pratiques et l'experience du vrain internet en moins. Sauf si l'entite en question decide justement d'utiliser toute la connaissance aquise sur le vrai Internet et de la transposer sur le sien. (...) - Et ce n'est pas juste un cas d'école, ca existe vraiment, j'ai bossé sur certains réseaux dans ce genre genre (réseaux financiers, notamment). Il n'y a pas que des IP du marais là dedans, il y a même des IP de LIR ou des blocs PI récents. -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
On Tue, Sep 23, 2014, at 14:33, Clement Cavadore wrote: - Et ce n'est pas juste un cas d'école, ca existe vraiment, j'ai bossé sur certains réseaux dans ce genre genre (réseaux financiers, notamment). Il n'y a pas que des IP du marais là dedans, il y a même des IP de LIR ou des blocs PI récents. Meme le cas d'ecole, de memoire est bien reel: le 51/8 de la secu britannique. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
Bonsoir, Le 23/09/2014 14:15, Stephane Bortzmeyer a écrit : Non. Laissons IPv4 tranquille, aucune raison de persécuter les malheureux qui l'utilisent encore, et occupons-nous du protocole d'aujourd'hui (IPv6). Voila une remarque constructive. Pour ma part, ce n'est pas comme si je tentais de prôner la bonne parole autour de moi depuis plus de 5 ans, et que tout le monde s'en fout ... (et je ne suis pas admin réseaux de formation) Pire, même encore maintenant, je suis convaincu que bon nombre d'admin sys/réseaux, ne se sont même pas penchés sur la question. Et quand je vois ce qui peut encore se vendre sur le Web comme étant des routeurs, ça me fout réellement la chair de poule. Loin de moi l'idée du terme evangelist (Beurk). Je m’intéresse seulement de toute part à ce qu'est Internet, et tiens à ce qu'il reste tel que les concepteurs l'ont imaginé au départ ; Un échange de données entre deux points du réseau. A mon sens, c'est juste ce qu'on demande au Réseau des réseaux peut importe ce qu'il y transite et de quelle façon. Ces tentatives désespérées de vouloir à tout prix conserver IPv4 ne font que reculer, reculer, reculer, pour sauter dans un gouffre sans fond à un moment donné, étant donné le nombre de rustines déjà conséquentes (et les problématiques qui vont avec) mises en place pour le conserver, et ça ne date pas d'hier. Je ne dirais jamais assez que le commerce a pris le pas sur la technique. La tendance est bien malheureusement que la technique doit se plier au commerce, que les intermédiaires sont entre deux feux, et n'ont probablement pas les moyens de s'investir dans ce genre d'évolutions. Sauf qu'à un moment donné, la technique prendra nécessairement le pas. Quand le commerce obtiendra des réponses négatives systématiques à la majorité de leur demande, le commerce prendra conscience probablement trop tard que les alertes soulevées par la technique dans le passé deviennent (très) problématiques et que cela va vite nuire au chiffre. L'anticipation est à mon sens le maître mot, surtout en ce qui concerne ce sujet qui est encore considéré pour beaucoup, comme une lubie de Geek fondamentalement asocial. (autant je pouvais le concevoir il y a 5 ans ... mais maintenant ?) Aucune attaque contre qui que se soit dans ces remarques ; Le monde des opérateurs est de loin bien plus évolué dans ce domaine que mon simple jugement de ce qu'il se passe d'une manière générale. Reste que je suis connecté en IPv6 à titre personnel depuis déjà bien des années, et qu'il me semble totalement inconcevable, à ce jour de passer à côté. A bientôt. Christophe. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
il y a des cas ou il est légitime d'avoir des ip publiques et ou elles ne sont pas annoncées sur internet exemple : grx - Mail original - De: Jérôme Nicolle jer...@ceriz.fr À: frnog-m...@frnog.org frnog@frnog.org Envoyé: Lundi 22 Septembre 2014 22:46:34 Objet: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ? Bonjour à tous, Avec la raréfaction des ressources IPv4, on commence à être un paquet à lorgner sur des /16 ERX qui n'ont jamais été annoncés de mémoire de RIS. Il parait qu'il y a des cas de figure ou l'on peut légitimement réserver un bloc sans le router, hors des blocs réservés (RFC 990, 1700, 1918, 2544, 3068, 3927, 5737, 5771, 6333, 6598 et 6890). On m'a cité, en vrac : - Pour des VPN [non publics] - Pour des réseaux privés susceptibles de s'interconnecter à d'autres réseaux [non publics] - Pour éviter d'avoir à renuméroter quand tout le monde est en 1918 et doit s'interconnecter Bref, que des cas de réseaux non connectés à Internet (par définition, puisque les adresses ne sont pas routées). Mais pourquoi donc utiliser des blocs enregistrés auprès de l'IANA ou d'un RIR ? Le problème de base est celui de l'unicité de l'adresse. Le registre global d'Internet est bien géré et permet de garantir qu'un bloc n'est pas assigné deux fois. Autant utiliser un registre existant, non ? Mais ça, c'était avant. Là, il y a pénurie. Un réseau d'entreprise, d'administration ou de recherche, n'a pas forcement vocation à _faire partie_ d'Internet. Mais on va bien volontiers s'y interconnecter pour bénéficier de quelques services présents sur ce dernier. Deux possibilités : - NAT : dans ce cas le masquage d'adresses publiques par des adresses du réseau privé est un problème bien réel dans certains réseaux qui ont numéroté au pif sans respecter les RFC. - Passerelles applicatives : les proxy sont parfaits pour lier le web, le mail, la voix et bien d'autres services dès lors qu'ils sont nommés au moyen d'un espace sans collision, c'est à dire par DNS et non par adresses littérales. Alors, si le resolver interne ne connait pas la zone, il répond l'adresse d'un proxy qui lui résout via la racine correspondante. J'y vois d'ailleurs un autre avantage : ça permet d'avoir une chaine de confiance intégrale dans l'ensemble du réseau, puisqu'on peut déployer RPKI+ROA et DNSSEC, voir systématiser SSL quitte à recourir aux proxy, de bout en bout dans un environnement contrôlé bien plus facilement qu'on ne le ferait sur Internet. Il est donc techniquement facile d'interconnecter les services de deux réseaux, mais pas possible simplement d'interconnecter les réseaux eux-même. C'est presque heureux puisqu'on va souvent, dans le cas de l'interconnexion de deux réseaux, vouloir contrôler un peu ce qui passe de l'un à l'autre (log des proxy). C'est d'autant plus heureux qu'un réseau bien conçu, avec adressage et nommage donc, sera facile à renuméroter. Il y a d'ailleurs même au moins un protocole basé sur le concept de séparation de l'adresse logique et physique : LISP (RFC 6830). Du coup, la fusion de deux réseaux dont les adressages peuvent être en collision passe logiquement par une étape préalable (voir qui aurait du avoir lieu bien avant) : virer les adresses en dur, tout nommer sur le DNS. C'est d'ailleurs une recommandation forte, à défaut d'être considéré comme obligatoire, pour le déploiement d'IPv6 en entreprise. De la même façon, la tenue d'un registre des allocations, du genre avec génération dynamique des zones DNS, s'impose rapidement. Le tableau excel montre trop vite ses limites. C'est une bonne pratique pour tout administrateur réseau, privé ou public, non ? (un appeau à commercial efficient-IP est caché dans ce paragraphe, saurez vous le trouver ?) Reste le cas de l'historique : Avant, il n'y avait pas de NAT. Avant, les proxy étaient chers. Avant, il y avait plein d'adresses. Mais ça... On ne change pas quelque chose qui marche. C'est d'ailleurs bien une des raisons pour lesquelles IPv6 peine à arriver sur le LAN. Depuis ces allocations, on peut légitimement se demander si tout le reste du réseau n'a pas été refait de fond en combles, et que seul l'adressage reste un vestige d'une époque bénie. Après tout, des machines qui ne supportent pas CIDR, ni le NAT, ni le nommage DNS, ni IPv6, c'est tellement vieux que c'est même plus sous contrat de maintenance, donc qu'on ne peut plus les utiliser dans une entreprise sérieuse, non ? Du coup, quand on me dit qu'il est normal d'adresser un LAN _non connecté à Internet_ avec des IP publiques, que dois-je en déduire ? Bref, ces ERX et autres reliquats, on vote tous pour leur destruction à la prochaine AG du RIPE ? @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG
[FRnOG] [MISC] L'Adtrap du geek barbu
Avant d'en venir au coeur du sujet, quelques commentaires en-ligne: Vincent Bernat a écrit : Si tu ne fais pas d'auto hébergement, tu t'en fous un peu d'avoir ton IP résidentielle blacklistée. Ben justement je m'auto-héberge, et je ne suis sûrement pas le seul geek barbu à le faire. Il y a aussi le petit coté qui fait de moi un saint qui dit qu'avoir un spambot ou autre merdiciel à la maison, envoyer de la merde à l'Internet entier, et s'en foutre, c'est pas très propre. Laurent GUERBY a écrit : Un tunnel vers une autre IP publique jetable (VM/VPN a pas cher) pour le reseau invité ? Oui oui, un peu usine à gaz mais pourquoi pas; deux commentaires ceci dit : - Soit on le fait avec une des IP de [$job] on y perds un peu de son indépendance, et quand on fait job++ faut nettoyer les restes à [$job-1]. - Soit on achète l'animal en question, qu'est-ce que tu as qui serait moins cher que de demander un /29 au FAI ? Bon revenons-en à l'Adtrap (was: parefeu) du geek barbu. Le matos avec 2 ou 3 Ethernet, pas trop poussif, petit consommateur d'énergie, pas trop cher : check, merci à tous ceux qui ont contribué à la machinbox du geek barbu. Moi je veux qu'il fonctionne en mode transparent, donc: - Fonctionne en mode bridge, mais possède aussi sa propre IP. - Interception des requêtes DNS. - Ne pas forwarder / mentir si nécessaire. - Dans le cas ou on ment, on retourne sa propre IP avec l'apache et les scripts et redirects à la mode Cyril Lacoux. - Dans le cas ou on ne ment pas, rien. Ce n'est donc pas un proxy. [Cyril, t'en penses quoi, ton truc en mode bridge?] Ca doit faire le café, aussi. Tant qu'on y est, on mets aussi dedans l'ExaBGP de Thomas Mangin, qui donne à bouffer au routeur les IPs louches qu'on route sur null0 et qu'on dégage dès l'entrée avec RPF en mode strict (*). Comment on détecte les IPs louches: - Avec - Avec des listes (snort) - Avec certains logs (j'ai quelques attrape-cons..) - Avec un IDS Gaëtan Duchaussois a écrit : Dans ce cas tu peux utiliser un ids en mode ips sur le réseau visiteur. Suricata ou autre. Mais c'est peut être un peu gourmand en ressources. C'est quoi, gourmand ? Autres ? Sinon tu dl les listes de snort ou de emerging threats que tu injectes dans ton pare feu. J'ai jamais fait de snort en mode bridge, commentaires ? snort est un des domaines ou je manque cruellement d'expérience. (*) Oui je sais BCP38 c'est beaucoup d'emmerdes, mais là on parle d'un réseau stub, donc sur mon routeur j'ai ip verify unicast source reachable-via rx comme çà les bogons et autres saloperies ne traversent même pas l'interface externe. Michel. ___ ___ +-/ Ze claoud \--+ +--/ Ze rézo local \+ !! ! ! ! +-++---++---+ ! ! +---++---+ ! ! ! FAI !! x !! y ! ! !Cafetière -+ +- Serveur +---+ Switch Garage + ! ! +--+--++-+-++-+-+ ! ! ! S !! +---+ ! !! !! ___ ! W +- PCs +---+ ! !++ +++--/ Cisco \+! I !!+-- DVR ! ! ! ! Tu100Tu200 !! T ++! ! ! ! ! NAT + Log ! +-+ ! C ! +---+--+ ! ! +--+ +---+ ATM0/0/0/0.35 Reflx ACL F0/0 +---+ Adtrap +--+ H +-+ Wifi +--- NeoTV ! ! ! Team Cymru ! ! ! +-+ ! ! +-+-+--+Netflix ! ! ! FullBogon #1 +---+ ! eBGP eBGP eBGP iBGP !! +- Ooma ! ! ! ! +--+ ! ++--+--+---+--+! ! ! +-- PC films ! ! !! ! ! ! ! ! ++ ! +- Pi ! ! ! +--+ ++ ! ! ! ! +--+ ExaBGP +---+ ! ! ! ! ! Team Cymru ! ! ! ! ! !+ ! ! ! ! ! ! FullBogon #2 +---+ ! ! ! +-+-+ ((( o ))) (((geek))) ! ! +--+ ! ! ! ! ! !! ! ! +-+-+
