Re: [MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
On Tue, Feb 2, 2021, at 07:54, Adrien Rivas wrote:
> Je suis pas certain, déjà ils prennent leur rôle au sérieux et le
> remplissent correctement.
On peut le voir comme ca quand on fait de la securite pour faire de la securite
et rien d'autre. La securite etant devenue aussi une religion ("tu fais ca et
tout va bien se passer" - errr...).
Pas mon metier, pas ma religion.
Dans mon travail je dois faire pour que la data peut se transmettre d'un point
A a un point B. La securite a pour bout d'empecher ca, base sur des criteres
parfois discutables.
> Après, pour le délire sécuritaire, ils fournissent un idéal à
> atteindre, et à toi de t'en approcher selon tes besoins / contraintes
> de temps, de compétences, de budget, d'équipe.
Encore une fois, pour moi leur delire n'est pas un ideal, mais plutot un
cauchemar qu'on risque de trouver de temps en temps/chez certains.
> Un de leurs derniers guides sur la passerelle internet sécurisée est
> intéressant par exemple, même si tous les clients n'ont pas les moyens
> d'avoir un Stormshield en périphérie et un palo en seconde ligne, et
> que souvent, avoir un UTM type Sophos, c'est déjà bien.
Mais bien-sur. Confirmation a ce que j'ecrivais plus haut.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
Je suis pas certain, déjà ils prennent leur rôle au sérieux et le remplissent correctement. Après, pour le délire sécuritaire, ils fournissent un idéal à atteindre, et à toi de t'en approcher selon tes besoins / contraintes de temps, de compétences, de budget, d'équipe. Un de leurs derniers guides sur la passerelle internet sécurisée est intéressant par exemple, même si tous les clients n'ont pas les moyens d'avoir un Stormshield en périphérie et un palo en seconde ligne, et que souvent, avoir un UTM type Sophos, c'est déjà bien. Le mar. 2 févr. 2021 à 07:42, Radu-Adrian Feurdean < fr...@radu-adrian.feurdean.net> a écrit : > On Mon, Feb 1, 2021, at 09:51, Oliver varenne wrote: > > Pourquoi ? > > Mes contacts avec l'ANSSI ont toujours été courtois et sympa moi. > > Oui, ils le sont. > C'est juste qu'en tant qu'Agence de "securite" (nationale en plus), il > leur arrive d'aller trop loin (au moins a mon gout) dans certains de leurs > delires securitaires. Au moins dans les discussions informelles. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
On Mon, Feb 1, 2021, at 15:57, Daniel Caillibaud wrote: > Ce que je disais c'est qu'il faudra probablement assez longtemps avant que > l'IPv4 ne fonctionne plus, et donc en tant que fournisseur de contenus je Avant que l'IPv4 ne fonctionne *plus*, on commence par "il fonctionne *mal* (de plus en plus mal)". --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
On Mon, Feb 1, 2021, at 12:53, JCLB wrote: > DNS64 / NAT64 est déjà une réalité sur la plupart des smartphones > récents chez les opérateurs en dehors de Free. Free compris. Normalement SFR aussi, mais je ne sais pas comment ca se passe la-bas. Chez Free et chez Orange c'est la variete 464XLAT, et je ne vois pas de raison pour avoir autre chose chez les autres (B et S). Les MVNO on les laisse de cote, ils n'ont pas les memes obligations, et ca depend fortement de ce qu'ils ont signe avec leurs HNO. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
On Mon, Feb 1, 2021, at 09:51, Oliver varenne wrote: > Pourquoi ? > Mes contacts avec l'ANSSI ont toujours été courtois et sympa moi. Oui, ils le sont. C'est juste qu'en tant qu'Agence de "securite" (nationale en plus), il leur arrive d'aller trop loin (au moins a mon gout) dans certains de leurs delires securitaires. Au moins dans les discussions informelles. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
> Daniel Caillibaud a écrit : > Ce qui risque d'arriver un peu plus tôt, c'est des client "only v6" qui > devront passer par une translation v6-v4 > qui va devenir plus pénalisante qu'aujourd'hui (parce que des acteurs qui > peuvent l'imposer l'auront décidé), Même ces acteurs-là ils ont mis de l'eau dans leur vin. On est en 2021, et chez plusieurs vendeurs connus, l'option "IPv4 only" est bien présente, et je parle de la version 2021 de leur produit. Attention appât à troll : j'ai des captures d'écran. Vendeurs, contenez vos trolls et vos bigots. > et qu'on devra s'y mettre pour éviter de trop détériorer leur accès, mais > même ça je pense que c'est > pas pour tout de suite, on a le temps de changer de génération d'infra > plusieurs fois avant. Précisément la raison pour laquelle il est urgent d'attendre. Ce que tu as très bien compris. > C'est exactement ça, j'en ai déjà pour 4~5ans à éponger la todolist que l'asso > m'a filé (la durée s'allonge au fil des années), et IPv6 n'est pas dedans. C'est exactement la même chose pour les entreprises. A part de très rares exceptions, il n'y a jamais assez de temps ou d'argent pour faire tout ce qu'on voudrait. Même quand on a du fric à dépenser; il y une todolist pareil. Je me rappelle de plein de sociétés qu'on considérait faire partie du paysage : IBM, Ashton-Tate, Borland, Compaq, Gateway, Computer Associates, Symantec, Novell, AOL, Nortel/Bay Networks, CII Honeywell-Bull, Aldus, NEC... Ils avaient pas la bonne todolist. > Pas sûr: pour rappel, de par l'ARCEP, les opérateurs mobiles 5G ont > obligation de rendre leur réseau compatible ipv6 et ce depuis fin 2020 Compatible IPv6, ca veut dire que ping6 marche. A part la liste au dessus, il y en a une autre a propos des technologies poussées par les gouvernements qui ont lamentablement foiré : ADA, GOSIP, ISDN... Je fais du copier/coller de ce que j'ai déjà écrit il y a 10 ans. Ce n'est pas parque que les gouvernements et autres régulateurs obligent quelque chose que çà marche. > À sa décharge, il a jamais dit impossible, Michel explique régulièrement > qu'IPv6 lui apporte du boulot > et des ennuis en plus sans lui apporter de contrepartie, et qu'il préfère > donc faire l'impasse dessus. Ah, merci. Ce qui n'a pas toujours été le cas. Pour les plus jeunes, je faisais déjà IPv6 le millénaire d'avant. J'ai configuré IPv6 sur un Cisco 2500, j'étais sur le 6bone. J'ai enseigné IPv6 à l'université de Californie au début des années 2000. Avant qu'il ne nous quitte, j'étais en bon termes (on a bu des bons coups) avec le type qui a écrit la première pile IPv6 : Jim Bound. J'étais un des bigots. > Stéphane Rivière a écrit : > Disclaimer - Je ne perçois aucun émoluments, salaires ou honoraires de la > part de Michel qui, d'ailleurs, > me doit le respect, avec ou sans Winchester - j'ai une petite longueur > d'avance à l'état civil :> (*) Lire le disclaimer Avec le plus grand respect pour ton âge avancé, ça ne fait pas tellement de temps que tu lis cette liste, et, comme tu n'es pas le seul, peut-être serait-il bon de revenir un peu en arrière. J'ai enterré IPX et Appletalk. Il y a environ 10 ans, quand j'ai commencé à dire publiquement que dual-stack n'était pas une solution, je me suis fait traité de tous les noms, en particulier par les vendeurs de FUD et les bigots "IPv6 only dans 3 ans". 10 ans on passé. Le temps a passé et les archives travaillent pour moi. Ceux qui (particulièrement en entreprise), ont déployé IPv6 et se trainent le boulet dual-stack depuis 10 ans ont généralement pris une retraite prématurée ou se sont reconvertis. Ceux qui ne sont pas encore à la retraite ont généralement la bonne idée de ne pas se rappeler à mes mauvais souvenirs; c'est souvent mauvais pour leur carrière quand je ressors le FUD qu'ils ont produit. La station Mir n'est pas tombée sur Paris, l'Internet ne s'est pas arrêté. Michel. (*) Disclaimer : quand Stéphane et moi on arrête de s'étriper en public, les lecteurs/lectrices de la liste se plaignent qu'ils n'ont pas fini le popcorn. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
>> Denis Fondras a écrit : >> Non, il faut absolument cesser de faire croire ca ! Combien >> d'"""administrateurs systeme""" se >> reposent là-dessus pour ne pas faire le minimum de sécurité (pas de >> correctifs de vulnerabilité, >> identifiants par defaut, etc) ? Et un jour, NAT slipstream passe par là et >> ca couine... > David Ponzone a écrit : > Hé ho, il avait utilisé le joker guillemets. NAT ça se contourne, mais au moins ça a l'avantage de forcer un pare-feu "diode" : tout qui sort, rien qui rentre. Sans NAT avec la grande majorité des bouses "IOT" ça serait un carnage. Déjà qu'avec NAT c'est pas glop, heureusement que c'est pas à poil sur l'Internet. NAT ou pas, slipstream ça expose aussi les machins qui sont derrière un pare-feu simple exactement de la même façon, pour la même raison : de la même façon que NAT stateful crée une association IP source / Port source / IP destination / Port destination, un pare-feu stateful fait la même chose sauf que l'adresse et le port ne changent pas. S'il y a un ver à l'intérieur qui peut envoyer des paquets avec une IP qui est celle d'un poste qui n'est pas la sienne, dans bien des cas, un pare-feu ce n'est pas mieux que NAT. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
Hé ho, il avait utilisé le joker guillemets. > Le 1 févr. 2021 à 20:21, Denis Fondras a écrit : > >> Nat sur IPV4.V6 a l'avantage d'apporter une *certaine* sécurité... c'est >> quand même un avantage > > Non, il faut absolument cesser de faire croire ca ! > Combien d'"""administrateurs systeme""" se reposent là-dessus pour ne pas > faire > le minimum de sécurité (pas de correctifs de vulnerabilité, identifiants par > defaut, etc) ? Et un jour, NAT slipstream passe par là et ca couine... > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
> Nat sur IPV4.V6 a l'avantage d'apporter une *certaine* sécurité... c'est > quand même un avantage Non, il faut absolument cesser de faire croire ca ! Combien d'"""administrateurs systeme""" se reposent là-dessus pour ne pas faire le minimum de sécurité (pas de correctifs de vulnerabilité, identifiants par defaut, etc) ? Et un jour, NAT slipstream passe par là et ca couine... --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Sessions TCP restant ouvertes après un switch BGP
Sympa de pouvoir copier le graphique, je savais pas qu’on pouvait faire ça. Le truc qui m’échappe, c’est pourquoi tu n’as pas OSPF entre les 3 sites, et laisser OSPF décider du routage ? Comme ça même si un lien tombe les sessions restent valides. Michel. From: frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] On Behalf Of Mickael Hubert Sent: Monday, February 1, 2021 7:29 AM To: frnog-tech Subject: [FRnOG] [TECH] Sessions TCP restant ouvertes après un switch BGP Bonjour à tous, j'ai un petit souci de sessions TCP restant actives après un switch de BGP. Pour infos ces 2 sessions sont à l'intérieur de tunnels IPSEC VTI. Je ne parle pas des sessions TCP du BGP en lui-même, mais de trafic TCP classique en fait. L'infra : [network interco (VPN) + BGP (FRNOG).png] Il y a 2 sessions BGP (1 par DC), les 2 connectées, avec une route map pour forcer le trafic a passer par un des 2 tunnels. Le failover BGP se fait très bien, un nouveau trafic passera correctement par le tunnel encore UP (standy -> active). Mais les sessions TCP déjà ouvertes entre le serveur C et les serveurs A ou B restent actives sur le serveur C. Pourtant, le routeur VPN C voit bien les sessions TCP comme closed. Il faut attendre un timeout sur le serveur C pour qu'il initie de nouvelles sessions TCP, mais c'est 8 mins de downtime chaud pour du failover ... Pour info le serveur C c'est un SBC Oracle qui fait du SIP TCP (pas possible de repasser en SIP UDP, trop facile ;) )... Le routeur VPN C c'est du Juniper. Avez-vous déjà vu ce genre de phénomène ? J'imagine bien qu'il faut changer le timer TCP sur l'Oracle, mais c'est à priori chaud pour mon client. N'y a-t'il pas un moyen sur un Juniper de balancer du TCP/RST lors d'une coupure de VPN ou autre palliatif ? Merci d'avance pour votre aide ! ++ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Sessions TCP restant ouvertes après un switch BGP
Quand tu dis routeur C c'est du Juniper, il fait quoi ? Routeur ? Firewall ? Ça ressemble à un grand classique d'une table de sessions quelque part sur une boite sur le chemin (firewall qui offloade le TCP dans un ASIC/NP, load-balancer quelque part) ? Je ne connais pas assez bien Juniper pour t'aider mais je dirais que si il y a perte de la route, le routeur devrait switch le trafic sur le path suivant, mais si tu rajoutes le VPN et donc potentiellement des SA/SP dans la boucle, tu as peut être un offload des paquets à chiffrer ou tout simplement des sessions TCP sur un type firewall ? T'as 2 trucs qui peuvent se télescoper la. Mais j'irais chercher de ce que côté la, surtout si en ICMP / UDP tu ne constates pas le soucis. Le 01-02-2021 16:28, Mickael Hubert a écrit : Bonjour à tous, j'ai un petit souci de sessions TCP restant actives après un switch de BGP. Pour infos ces 2 sessions sont à l'intérieur de tunnels IPSEC VTI. Je ne parle pas des sessions TCP du BGP en lui-même, mais de trafic TCP classique en fait. L'infra : Il y a 2 sessions BGP (1 par DC), les 2 connectées, avec une route map pour forcer le trafic a passer par un des 2 tunnels. Le failover BGP se fait très bien, un nouveau trafic passera correctement par le tunnel encore UP (standy -> active). Mais les sessions TCP déjà ouvertes entre le serveur C et les serveurs A ou B restent actives sur le serveur C. Pourtant, le routeur VPN C voit bien les sessions TCP comme closed. Il faut attendre un timeout sur le serveur C pour qu'il initie de nouvelles sessions TCP, mais c'est 8 mins de downtime chaud pour du failover ... Pour info le serveur C c'est un SBC Oracle qui fait du SIP TCP (pas possible de repasser en SIP UDP, trop facile ;) )... Le routeur VPN C c'est du Juniper. Avez-vous déjà vu ce genre de phénomène ? J'imagine bien qu'il faut changer le timer TCP sur l'Oracle, mais c'est à priori chaud pour mon client. N'y a-t'il pas un moyen sur un Juniper de balancer du TCP/RST lors d'une coupure de VPN ou autre palliatif ? Merci d'avance pour votre aide ! ++ -- Fabien VINCENT _@beufanet_ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Sessions TCP restant ouvertes après un switch BGP
Bonjour à tous, j'ai un petit souci de sessions TCP restant actives après un switch de BGP. Pour infos ces 2 sessions sont à l'intérieur de tunnels IPSEC VTI. Je ne parle pas des sessions TCP du BGP en lui-même, mais de trafic TCP classique en fait. L'infra : [image: network interco (VPN) + BGP (FRNOG).png] Il y a 2 sessions BGP (1 par DC), les 2 connectées, avec une route map pour forcer le trafic a passer par un des 2 tunnels. Le failover BGP se fait très bien, un nouveau trafic passera correctement par le tunnel encore UP (standy -> active). Mais les sessions TCP déjà ouvertes entre le serveur C et les serveurs A ou B restent actives sur le serveur C. Pourtant, le routeur VPN C voit bien les sessions TCP comme closed. Il faut attendre un timeout sur le serveur C pour qu'il initie de nouvelles sessions TCP, mais c'est 8 mins de downtime chaud pour du failover ... Pour info le serveur C c'est un SBC Oracle qui fait du SIP TCP (pas possible de repasser en SIP UDP, trop facile ;) )... Le routeur VPN C c'est du Juniper. Avez-vous déjà vu ce genre de phénomène ? J'imagine bien qu'il faut changer le timer TCP sur l'Oracle, mais c'est à priori chaud pour mon client. N'y a-t'il pas un moyen sur un Juniper de balancer du TCP/RST lors d'une coupure de VPN ou autre palliatif ? Merci d'avance pour votre aide ! ++
Re: [MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
D'ailleurs ceci expliquant cela (le cout des mécanisme de NAT44 est pas nécessairement élevé / user mais il est pas nul, donc tout ce que tu peux passer en IPv6 te fais économiser un pouillème pour chaque subscribers) et des gros opérateurs mobile y ont trouvé un intérêt au. Typiquement, Jio, 300Millions de subscribers en Inde, full IPv6 natif (y compris la VoLTE et ca honnêtement j'aurai pas voulu être le premier à tester...) https://conference.apnic.net/50/assets/files/APCS790/Harnessing-the-power-of-IPv6.pdf Le lun. 1 févr. 2021 à 12:55, JCLB a écrit : > DNS64 / NAT64 est déjà une réalité sur la plupart des smartphones récents > chez les opérateurs en dehors de Free. > Les utilisateurs subissent donc un NAT PAT stateful. > > Il faut toutefois relativiser, auparavant 100% de la data mobile subissait > du NAT PAT 44. > Aujourd'hui le trafic IPv6 natif sort en direct, et on peut supposer que > 20 à 30% du trafic échappe donc à NAT64. > > Sur le fixe les mécanismes sont stateless avec des approches Adress+Port > (4rd, MAP T/E,...) > > Au besoin la précédence des OS se configure si on a besoin de conserver la > priorité IPv4 et d'outrepasser la RFC 6724. > Voir ici pour Windows http://support.microsoft.com/kb/929852 > Et pour Linux GetAddressInfo /etc/gai.conf > > Attention, certaines applications comme les navigateurs implémentent leur > propre priorisation de v6 sur v4, indépendante de la configuration du stack > de l’OS. De plus l’implémentation du mécanisme Happy eyeballs 2 (RFC 8305) > peut également varier. (Délai entre les requête DNS A et , temps > d’attente du retour, délai de timeout du socket distant avec bascule…) > > Jean-Charles BISECCO > > > -Message d'origine- > De : frnog-requ...@frnog.org De la part de > Daniel Caillibaud > Envoyé : lundi 1 février 2021 12:33 > À : frnog@frnog.org > Objet : Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent > > Le 29/01/21 à 22h29, Laurent Barme <5...@barme.fr> a écrit : > > Ce n'est par le client qui est en cause. > > Je parlais du client réseau, au sens client / serveur… > > > Aujourd'hui je constate que c'est déjà l'IPv6 qui est prioritaire, > > demain j'anticipe que ce sera, parfois d'abord et toujours ensuite, la > > seule disponible par défaut... et là, il faudra bien y passer. > > Je pense que ce sera peut-être après-demain, et je serai sûrement à la > retraite avant ;-) > > Ce qui risque d'arriver un peu plus tôt, c'est des client "only v6" qui > devront passer par une translation v6-v4 qui va devenir plus pénalisante > qu'aujourd'hui (parce que des acteurs qui peuvent l'imposer l'auront > décidé), et qu'on devra s'y mettre pour éviter de trop détériorer leur > accès, mais même ça je pense que c'est pas pour tout de suite, on a le > temps de changer de génération d'infra plusieurs fois avant. > > -- > Daniel > > Si le temps vous semble long, prenez-le dans le sens de la largeur. > Grégoire Lacroix > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
Le 01/02/21 à 12h30, Daniel via frnog a écrit : > Pas sûr: pour rappel, de par l'ARCEP, les opérateurs mobiles 5G ont > obligation de rendre leur réseau compatible ipv6 et ce depuis fin 2020 Oui bien sûr, ça me paraît normal qu'un fournisseur de réseau (fixe ou mobile) doive être compatible IPv6 en 2021. Ce que je disais c'est qu'il faudra probablement assez longtemps avant que l'IPv4 ne fonctionne plus, et donc en tant que fournisseur de contenus je peux encore rester IPv4 only un moment. Et peut-être qu'un jour, si la plupart des terminaux qui s'adressent à moi tentent le le faire en v6 et que de passer par v4 les arrange pas, et que l'on a envie d'être gentil avec eux, alors je me pencherai sur la question de tout configurer en double. -- Daniel Tout a été dit ; mais comme personne n'écoute, il faut toujours répéter. André Gide --- Liste de diffusion du FRnOG http://www.frnog.org/
[MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
On en revient à: Nat sur IPV4.V6 a l'avantage d'apporter une *certaine* sécurité... c'est quand même un avantage Enfin, jusqu’à ce qu'un vilain pirate s'introduise dans le réseau du client... (arrivé deux fois en un mois, acces PPTP laissé ouvert par un prestataire, sans raison... bien sûr, une fois sur le LAN, tous les mots de passes des périphériques SIP sont "admin/admin") Cordialement, Olivier Varenne Co-gérant, Commercial & Développeur T +33 (0)4 27 04 40 00 | ipconnect.fr Suivez-nous ! > -Message d'origine- > De : frnog-requ...@frnog.org De la part de > David Ponzone > Envoyé : lundi 1 février 2021 15:30 > À : Radu-Adrian Feurdean > Cc : frnog@frnog.org > Objet : Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent > > Tu prêches un convaincu. > > J’aurais dû parler de la manière dont la sécurité d’IPv6 était perçue. > Ici même, j’ai plusieurs fois lu qu’un préfixe IPv6 était trop grand pour > être scanné. > Moi j’y crois pas trop. > Ça fait pourtant plusieurs siècles qu’il explose les limites qu’il se met à > lui-même. > Soit par la force, soit par l’intelligence. > > > > > Le 31 janv. 2021 à 07:36, Radu-Adrian Feurdean adrian.feurdean.net> a écrit : > > > > E, NON. > > La securite de l'IPv6, comme celle de l'IPv4 repose sur le fait qu'il n'y a > pas de de failles/trous/vulnerabilites . ce qui n'est pas exactement la > situation dans la realite. > > D'ailleurs la taille de l'espace d'adressage ne protege pas > completement, ca fait juste augmenter (tres sensiblement) le niveau de > motivation pour un attaque "au hasard". Si en IPv4 tout "skr1pt k1dd13" > pouvait se permettre de scanner l'internet, en v6 faut bien cibler (c'est > meme essentiel) et avoir de la patience pour scanner un /64. > > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
Tu prêches un convaincu. J’aurais dû parler de la manière dont la sécurité d’IPv6 était perçue. Ici même, j’ai plusieurs fois lu qu’un préfixe IPv6 était trop grand pour être scanné. Moi j’y crois pas trop. Ça fait pourtant plusieurs siècles qu’il explose les limites qu’il se met à lui-même. Soit par la force, soit par l’intelligence. > Le 31 janv. 2021 à 07:36, Radu-Adrian Feurdean > a écrit : > > E, NON. > La securite de l'IPv6, comme celle de l'IPv4 repose sur le fait qu'il n'y a > pas de de failles/trous/vulnerabilites . ce qui n'est pas exactement la > situation dans la realite. > D'ailleurs la taille de l'espace d'adressage ne protege pas completement, ca > fait juste augmenter (tres sensiblement) le niveau de motivation pour un > attaque "au hasard". Si en IPv4 tout "skr1pt k1dd13" pouvait se permettre de > scanner l'internet, en v6 faut bien cibler (c'est meme essentiel) et avoir de > la patience pour scanner un /64. > --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] Recherche de stage
Bonjour. Je suis étudiant à l'IUT d'Aix-Marseille en Informatique et je suis à la recherche d'un stage pour la validation de mon diplôme. J'ai des compétences dans la programmation en général, dans le web et aussi quelques notions de réseaux. Je vous laisse mon github pour voir quelques projets réalisés dans et hors IUT (https://github.com/rouxPanda). De nature consciencieuse et sérieuse, je suis quelqu’un qui s’adapte très rapidement à de nouvelles situations dans le travail. Je suis également très autonome. Je suis disponible pour tous renseignements complémentaire. Merci à vous. Cordialement TRONC Clément --- Liste de diffusion du FRnOG http://www.frnog.org/
[MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
DNS64 / NAT64 est déjà une réalité sur la plupart des smartphones récents chez les opérateurs en dehors de Free. Les utilisateurs subissent donc un NAT PAT stateful. Il faut toutefois relativiser, auparavant 100% de la data mobile subissait du NAT PAT 44. Aujourd'hui le trafic IPv6 natif sort en direct, et on peut supposer que 20 à 30% du trafic échappe donc à NAT64. Sur le fixe les mécanismes sont stateless avec des approches Adress+Port (4rd, MAP T/E,...) Au besoin la précédence des OS se configure si on a besoin de conserver la priorité IPv4 et d'outrepasser la RFC 6724. Voir ici pour Windows http://support.microsoft.com/kb/929852 Et pour Linux GetAddressInfo /etc/gai.conf Attention, certaines applications comme les navigateurs implémentent leur propre priorisation de v6 sur v4, indépendante de la configuration du stack de l’OS. De plus l’implémentation du mécanisme Happy eyeballs 2 (RFC 8305) peut également varier. (Délai entre les requête DNS A et , temps d’attente du retour, délai de timeout du socket distant avec bascule…) Jean-Charles BISECCO -Message d'origine- De : frnog-requ...@frnog.org De la part de Daniel Caillibaud Envoyé : lundi 1 février 2021 12:33 À : frnog@frnog.org Objet : Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent Le 29/01/21 à 22h29, Laurent Barme <5...@barme.fr> a écrit : > Ce n'est par le client qui est en cause. Je parlais du client réseau, au sens client / serveur… > Aujourd'hui je constate que c'est déjà l'IPv6 qui est prioritaire, > demain j'anticipe que ce sera, parfois d'abord et toujours ensuite, la > seule disponible par défaut... et là, il faudra bien y passer. Je pense que ce sera peut-être après-demain, et je serai sûrement à la retraite avant ;-) Ce qui risque d'arriver un peu plus tôt, c'est des client "only v6" qui devront passer par une translation v6-v4 qui va devenir plus pénalisante qu'aujourd'hui (parce que des acteurs qui peuvent l'imposer l'auront décidé), et qu'on devra s'y mettre pour éviter de trop détériorer leur accès, mais même ça je pense que c'est pas pour tout de suite, on a le temps de changer de génération d'infra plusieurs fois avant. -- Daniel Si le temps vous semble long, prenez-le dans le sens de la largeur. Grégoire Lacroix --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
Le 01/02/2021 à 11:33, Daniel Caillibaud a écrit : [...] Je pense que ce sera peut-être après-demain, et je serai sûrement à la retraite avant ;-) Ce qui risque d'arriver un peu plus tôt, c'est des client "only v6" qui devront passer par une translation v6-v4 qui va devenir plus pénalisante qu'aujourd'hui (parce que des acteurs qui peuvent l'imposer l'auront décidé), et qu'on devra s'y mettre pour éviter de trop détériorer leur accès, mais même ça je pense que c'est pas pour tout de suite, on a le temps de changer de génération d'infra plusieurs fois avant. Pas sûr: pour rappel, de par l'ARCEP, les opérateurs mobiles 5G ont obligation de rendre leur réseau compatible ipv6 et ce depuis fin 2020 -- Daniel --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
Le 31/01/21 à 8h22, Stéphane Rivière a écrit : > > Rappelle-moi, c'est une asso (a.k.a "a but non-lucratif") ou une vraie > > TPE déguisé en "asso" pour éviter quelques taxes ? > > L'idée qu'être en asso va t'éviter des taxes est une idée reçue. La > plupart des assos (ce n'est pas obligatoire) ne récupèrent pas la TVA. > Ce qu'il fait qu'elles sont pénalisées de 20% sur leurs investissements. > > Et elles peuvent être contrôlées comme les sociétés et payent leurs > charges sociales, impôts et autres comme les entreprises. Ça dépend des assos. Même une asso 1901 peut avoir des activités lucratives, qui du coup sont imposées. Si c'est non-lucratif (avec gestion désintéressée et qq autres contraintes), alors tu peux quand même vendre des trucs et ne pas avoir d'IS, et tu n'es pas assujetti à la TVA (y'a un plafond). Effectivement tu peux pas la récupérer sur les achats mais t'as pas à la payer sur les ventes et ça simplifie tellement la compta que c'est quand même tout bénéf (et si tu veux récupérer la TVA alors tu demande à changer de case et tu paies IS & TVA). Ensuite, y'a "intérêt général" et "utilité publique", ça change certaines règles fiscales (notamment la déduction de 60% de leurs impôts pour tes donateurs). Dans tous les cas les charges salariales sont évidemment exactement les mêmes que pour n'importe quel employeur, heureusement pour les salariés (y'a que les trucs genre UNESCO qui sont exemptées de cotisations salariales, et je crois aussi de qq règles du droit du travail… comme le renouvellement des CDD). > > En tant qu'association tu devras etre dans une des meilleures positions > > pour faire des experiments de ce type. > > Les assos sont comme les entreprises : manque de temps et de moyens. > Elles ne sont pas en meilleure position, qu'il y ait des bénévoles ou > pas. C'est la mission première de l'asso qui va déterminer les priorités. > > Dans le cas de Daniel, sans m'avancer mais connaissant un peu > l'activité, la priorité de son asso n'est probablement pas > d'expérimenter ipv6 ;> C'est exactement ça, j'en ai déjà pour 4~5ans à éponger la todolist que l'asso m'a filé (la durée s'allonge au fil des années), et IPv6 n'est pas dedans. Pour les curieux l'asso en question est https://www.sesamath.net/ -- Daniel Il est parfaitement monstrueux de s'apercevoir que les gens disent dans notre dos des choses qui sont absolument et entièrement vraies. Oscar Wilde --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
Le 01/02/2021 à 11:33, Daniel Caillibaud a écrit : > > Je pense que ce sera peut-être après-demain, et je serai sûrement à la > retraite avant ;-) > > Ce qui risque d'arriver un peu plus tôt, c'est des client "only v6" qui > devront passer par une translation v6-v4 qui va devenir plus pénalisante > qu'aujourd'hui (parce que des acteurs qui peuvent l'imposer l'auront > décidé), et qu'on devra s'y mettre pour éviter de trop détériorer leur > accès, mais même ça je pense que c'est pas pour tout de suite, on a le > temps de changer de génération d'infra plusieurs fois avant. > J'ai bossé chez un fabricant de box de 2010 à 2017. Et il fallait des réseaux IPv6 only pour certains clients cablo-opérateurs qui voulaient valider les box dans ce contexte. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
Le 29/01/21 à 22h29, Laurent Barme <5...@barme.fr> a écrit : > Ce n'est par le client qui est en cause. Je parlais du client réseau, au sens client / serveur… > Aujourd'hui je constate que c'est déjà l'IPv6 qui est prioritaire, demain > j'anticipe que ce sera, parfois d'abord et toujours ensuite, la seule > disponible par défaut... et là, il faudra bien y passer. Je pense que ce sera peut-être après-demain, et je serai sûrement à la retraite avant ;-) Ce qui risque d'arriver un peu plus tôt, c'est des client "only v6" qui devront passer par une translation v6-v4 qui va devenir plus pénalisante qu'aujourd'hui (parce que des acteurs qui peuvent l'imposer l'auront décidé), et qu'on devra s'y mettre pour éviter de trop détériorer leur accès, mais même ça je pense que c'est pas pour tout de suite, on a le temps de changer de génération d'infra plusieurs fois avant. -- Daniel Si le temps vous semble long, prenez-le dans le sens de la largeur. Grégoire Lacroix --- Liste de diffusion du FRnOG http://www.frnog.org/
[MISC] RE: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent
Pourquoi ? Mes contacts avec l'ANSSI ont toujours été courtois et sympa moi. Seul bémol: c'est long. Mais bon... l'administration à la française quoi ! Mais y'a pire: faire un dossier de bien à double usage avec le SDBU Cordialement, Olivier Varenne Co-gérant, Commercial & Développeur T +33 (0)4 27 04 40 00 | ipconnect.fr Suivez-nous ! > -Message d'origine- > De : frnog-requ...@frnog.org De la part de > Radu-Adrian Feurdean > Envoyé : dimanche 31 janvier 2021 07:12 > À : frnog@frnog.org > Objet : Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent > > On Fri, Jan 29, 2021, at 17:10, Cyrille JERABEK wrote: > > > Une question un peu générale, excusez-moi si elle est trop basique > > et/ou vaste et/ou mal posée : > > comment on fait pour scanner les adresses exposées indûment en IPV6 > et > > les ports ouverts illicitement ? > > Faut demander a l'ANSSI. Par contre prepare le pop-corn pour les > reponses. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
