Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet David Ponzone 
> Le 31 mai 2022 à 21:55, Raphael Mazelier  a écrit :
> 
> Alors déjà que tu puisse voir le trafic downstream des autres clients c'est 
> étrange. Mais soit admettons les datas sont la à ta porte donc si le trafic 
> est en clair et que l'ont se met en mode sniffing (ca doit exister) pourquoi 
> pas. 
> 
> Mais alors l'upstream alors la je vois même pas comment c'est possible. Si tu 
> vois l'upstream cela veut dire que tu l'as d'abord reçu pour le renvoyer ?! 
> une sorte de bounce. Mais ca doit créer un bazar pas possible.
> 
> 
J’arrive plus à reproduire, donc au temps pour moi, je me suis peut-être 
planté, je finis par m’embrouiller à force, surtout que certains clients 
semblent avoir des VPN IPsec encore 2 opérateurs clients de Kosc.
Je vais chercher encore, mais je préfère autant ça, parce que c’était vraiment 
incohérent/impossible.

> En tout cas c'est plutôt rigolo et intéressant si tu as le fin mot de 
> l'histoire. (ça sent quand même la méga mauvaise config coté kosc)

Oui.
Pour ceux qui encore un doute, petit exemple de ce que ça donne sur un client 
de Paritel dont je viens de voir le traffic sur le FTTH de mon client.

Ping depuis mon FTTH perso Bouygues à Paris:

% ping 5.134.101.211
PING 5.134.101.211 (5.134.101.211): 56 data bytes
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=20.505 ms
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=26.913 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=33.350 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=36.826 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=36.839 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=37.523 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=41.796 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=43.910 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=48.683 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=235 time=54.345 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=54.361 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=54.812 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=229 time=55.675 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=59.009 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=59.186 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=61.327 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=61.769 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=63.421 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=64.797 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=64.807 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=66.407 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=67.501 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=67.837 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=229 time=77.831 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=77.885 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=78.357 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=78.899 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=80.323 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=235 time=80.638 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=80.646 ms (DUP!)
36 bytes from host.211-101-134-5.rev.paritel.fr (5.134.101.211): Time to live 
exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  28 5400 9755   0   01  01 f8ed 192.168.253.60  5.134.101.211

36 bytes from host.211-101-134-5.rev.paritel.fr (5.134.101.211): Time to live 
exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  28 5400 9755   0   01  01 f8ed 192.168.253.60  5.134.101.211

64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=84.338 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=237 time=84.342 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=86.014 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=86.288 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=86.290 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=231 time=89.717 ms (DUP!)
64 bytes from 5.134.101.211: icmp_seq=0 ttl=243 time=89.951 ms (DUP!)
36 bytes from 158.255.97.54: Time to live exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  00 5400 9755   0   01  01 f915 192.168.253.60  5.134.101.211

36 bytes from v3.ae10.ter3.eqx2.par.as8218.eu (64.125.30.183): Time to live 
exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  28 5400 9755   0   01  01 f8ed 192.168.253.60  5.134.101.211

36 bytes from v3.ae10.ter3.eqx2.par.as8218.eu (64.125.30.183): Time to live 
exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  28 5400 9755   0   01  01 f8ed 192.168.253.60  5.134.101.211

64 bytes from 5.134.101.211: icmp_seq=0 ttl=229 time=96.406 ms (DUP!)
36 bytes fr

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet Jérôme Marteaux 

Le 30/05/2022 à 14:50, David Ponzone a écrit :

Il y a quelque chose de pourri au royaume du FTTH.

Chez un client FTTH (sur Kosc) dans le Grand Est, je reçois du traffic entrant 
destiné à d’autres clients.
Difficile de se tromper: IP source et destination ne sont pas celles de mon 
client, et par contre au moins une des 2 appartient à un confrère: Keyyo, 
Alphalink, Flux Network, Paritel, pour citer quelques-unes des IP que j’ai 
tracées.

Je pensais même pas qu’il était possible pour un ONT de décrypter les trames de 
plusieurs clients….

Si un confrère veut se lancer dans un debug fou avec moi, ou au moins me 
fournir la confirmation que l’IP de son client est bien dans le Grand Est et 
que le FTTH est chez Kosc, on aura déjà le nom du responsable.


David


Et si ce n'était tout simplement pas une FTTH mais une FTTO ?
Et si tous les liens n'étaient pas isolés entres eux (genre le même 
domaine de broadcast).


L'ONT ne serait alors qu'un bête équipement de démarcation sans la 
couche FTTH.


J'ai l'impression que sur une infra type DSP qui loue des fibres 
non-activées, l'archi technique est plutôt FTTO et le nom commercial est 
FTTH qui n'en a alors que le nom.



Jérôme
--
Jérôme Marteaux


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [MISC] Metrics Prime Vidéo Roland Garros

2022-05-31 Par sujet Romain 
Bonsoir à tous,

J’ai peu d’espoir mais savez-vous s’il existe un endroit où on serait
susceptible d’avoir une idée (en direct ou via un post sur un blog
post-match) des metrics de Prime Vidéo pendant un match comme celui de ce
soir ?

Ou à défaut une estimation de ce que ça entraîne comme usage de BP, etc ?

Peut-être des weather maps du peering des différents opérateurs avec les
infras d’Amazon (désolé si je n’utilise pas le bon terme) ?

Romain

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet Raphael Mazelier 
Alors déjà que tu puisse voir le trafic downstream des autres clients 
c'est étrange. Mais soit admettons les datas sont la à ta porte donc si 
le trafic est en clair et que l'ont se met en mode sniffing (ca doit 
exister) pourquoi pas.


Mais alors l'upstream alors la je vois même pas comment c'est possible. 
Si tu vois l'upstream cela veut dire que tu l'as d'abord reçu pour le 
renvoyer ?! une sorte de bounce. Mais ca doit créer un bazar pas possible.


En tout cas c'est plutôt rigolo et intéressant si tu as le fin mot de 
l'histoire. (ça sent quand même la méga mauvaise config coté kosc)


--
Raphael Mazelier

On 31/05/2022 17:29, David Ponzone wrote:

Chez un client je vois le traffic descendant des autres mais chez un autre 
client, je vois le traffic montant des autres.
Et ça c’est plus embêtant, parce qu’en GPON, les splitters sont filtrants dans le 
sens montant, donc c’est pas possible, sauf si c’est l’OLT qui renvoie le traffic 
up->down.
Bref, encore beaucoup de zones d’ombre, et je suis presque sûr que la 
correction ne va pas venir avec une belle explication transparente :)


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet Patrick Chollat 
Non. Un ONT sans port-id ne peut pas faire passer de trafic.
Le port-id correspond à un n° de GEM (canal de transmission) associé à
l'ONT et négocié entre OLT et ONT au démarrage de l'ONT.



Le mar. 31 mai 2022 à 17:46, David Ponzone  a
écrit :

> Ok donc dans mon cas, on a bien 2 problèmes:
> -que ça soit en clair
> -que je puisse voir le traffic d’autres Port-Id
>
> Est-ce qu’un ONT sans Port-ID n’aurait pas tendance à prendre tout le
> traffic ?
>
> > Le 31 mai 2022 à 17:43, Patrick Chollat  a écrit :
> >
> > Le Port-Id dans la Gem Frame (après le pcbd) permet d'identifier l'ONT...
> >
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet David Ponzone 
Ok donc dans mon cas, on a bien 2 problèmes:
-que ça soit en clair
-que je puisse voir le traffic d’autres Port-Id

Est-ce qu’un ONT sans Port-ID n’aurait pas tendance à prendre tout le traffic ?

> Le 31 mai 2022 à 17:43, Patrick Chollat  a écrit :
> 
> Le Port-Id dans la Gem Frame (après le pcbd) permet d'identifier l'ONT...
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet Patrick Chollat 
Le Port-Id dans la Gem Frame (après le pcbd) permet d'identifier l'ONT...

Le mar. 31 mai 2022 à 17:24, Raphael Mazelier  a écrit :

> Les spécialistes du GPON me corrigeront mais il me semble que le chiffrage
> peut être optionnel (même si c'est vivement déconseillé)
>
> Cela n’empêche pas l'ont de faire le tri entre ce qui le concerne ou pas
> (via un id, le pcbd je crois). Donc pas de risque de saturer le lien entre
> l'ont et le cpe normalement.
>
> Je suis quand même surpris que tu puisse passé l'ONT capturer des paquets
> qui ne te sont pas destiné (sauf s'ils sont mal catégorisé upstream)
>
> --
> Raphael Mazelier
>
> On 31/05/2022 16:44, David Ponzone wrote:
>
> Ok donc la sélection du traffic qui concerne le CPE ne repose que sur le 
> cryptage (coucou Gary), parce que effectivement, et merci pour la correction, 
> dans le sens descendant, il n’y a qu’un émetteur donc pas de problème de 
> collision, donc pas besoin de TDM.
>
> Si c’est donc bien ça qui déconne sur certains OLT Altitude, je suis quand 
> même surpris par le peu de traffic que je reçois pour les autres clients, 
> mais néanmoins quasi-permanent (c’est comme un bruit de fond de 500Kbps, ça 
> ressemble pas du tout à du traffic Internet habituel).
>
> Ca veut aussi dire que si le traffic est en clair, il peut saturer la capa du 
> port 1G entre l’ONT et le CPE de tous les clients sur le PON.
> Rien que pour cette raison, cela ne devrait pas être optionnel, sauf 
> peut-être pour des tests.
>
>
> Le 31 mai 2022 à 16:19, Patrick Chollat  
>  a écrit :
>
> Dans la technologie GPON tous les ONT d'un PON reçoivent le trafic de tous 
> les ONT du PON dans le sens descendant ,d'où la nécessité de l'encryptage.
> Le TDMA n'est utilisé que dans le sens montant.
>
> Le mar. 31 mai 2022 à 16:09, David Ponzone   > a écrit :
> Que le traffic ne soit pas crypté ne signifie pas que tous les ONT le 
> forwardent vers le CPE.
> Sinon je vois mal comment le CPE du client va faire pour gérer sur son port 
> 1G un max de 2.4Gbps de traffic dont une grrrande partie n’est pas pour lui.
> Ca serait pathétique de la part de la techno.
> L’ONT est censé faire une extraction TDM il me semble, avec décryptage 
> optionnel.
>
>
> Le 31 mai 2022 à 16:01, Benoît Grangé   > a écrit :
>
> Bonjour,
>
> dans beaucoup de technologies réseau que connaît on à le choix de définir les 
> algo de chiffrement utilisées, le premier niveau étant "None".
>
> J'ai déjà vu des déploiements ou c'était le cas ;-) et c'est peut être ce que 
> vous observez.
>
>
> ---
> Liste de diffusion du FRnOGhttp://www.frnog.org/  
> 
>
> ---
> Liste de diffusion du FRnOGhttp://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet David Ponzone 
Chez un client je vois le traffic descendant des autres mais chez un autre 
client, je vois le traffic montant des autres.
Et ça c’est plus embêtant, parce qu’en GPON, les splitters sont filtrants dans 
le sens montant, donc c’est pas possible, sauf si c’est l’OLT qui renvoie le 
traffic up->down.
Bref, encore beaucoup de zones d’ombre, et je suis presque sûr que la 
correction ne va pas venir avec une belle explication transparente :)

> Le 31 mai 2022 à 17:24, Raphael Mazelier  a écrit :
> 
> Les spécialistes du GPON me corrigeront mais il me semble que le chiffrage 
> peut être optionnel (même si c'est vivement déconseillé)
> 
> Cela n’empêche pas l'ont de faire le tri entre ce qui le concerne ou pas (via 
> un id, le pcbd je crois). Donc pas de risque de saturer le lien entre l'ont 
> et le cpe normalement.
> 
> Je suis quand même surpris que tu puisse passé l'ONT capturer des paquets qui 
> ne te sont pas destiné (sauf s'ils sont mal catégorisé upstream)
> 
> --
> Raphael Mazelier
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet Raphael Mazelier 
Les spécialistes du GPON me corrigeront mais il me semble que le 
chiffrage peut être optionnel (même si c'est vivement déconseillé)


Cela n’empêche pas l'ont de faire le tri entre ce qui le concerne ou pas 
(via un id, le pcbd je crois). Donc pas de risque de saturer le lien 
entre l'ont et le cpe normalement.


Je suis quand même surpris que tu puisse passé l'ONT capturer des 
paquets qui ne te sont pas destiné (sauf s'ils sont mal catégorisé upstream)


--
Raphael Mazelier

On 31/05/2022 16:44, David Ponzone wrote:

Ok donc la sélection du traffic qui concerne le CPE ne repose que sur le 
cryptage (coucou Gary), parce que effectivement, et merci pour la correction, 
dans le sens descendant, il n’y a qu’un émetteur donc pas de problème de 
collision, donc pas besoin de TDM.

Si c’est donc bien ça qui déconne sur certains OLT Altitude, je suis quand même 
surpris par le peu de traffic que je reçois pour les autres clients, mais 
néanmoins quasi-permanent (c’est comme un bruit de fond de 500Kbps, ça 
ressemble pas du tout à du traffic Internet habituel).

Ca veut aussi dire que si le traffic est en clair, il peut saturer la capa du 
port 1G entre l’ONT et le CPE de tous les clients sur le PON.
Rien que pour cette raison, cela ne devrait pas être optionnel, sauf peut-être 
pour des tests.


Le 31 mai 2022 à 16:19, Patrick Chollat  a écrit :

Dans la technologie GPON tous les ONT d'un PON reçoivent le trafic de tous les 
ONT du PON dans le sens descendant ,d'où la nécessité de l'encryptage.
Le TDMA n'est utilisé que dans le sens montant.

Le mar. 31 mai 2022 à 16:09, David Ponzone mailto:david.ponz...@gmail.com>> a écrit :
Que le traffic ne soit pas crypté ne signifie pas que tous les ONT le 
forwardent vers le CPE.
Sinon je vois mal comment le CPE du client va faire pour gérer sur son port 1G 
un max de 2.4Gbps de traffic dont une grrrande partie n’est pas pour lui.
Ca serait pathétique de la part de la techno.
L’ONT est censé faire une extraction TDM il me semble, avec décryptage 
optionnel.


Le 31 mai 2022 à 16:01, Benoît Grangé mailto:benoit.gra...@gmail.com>> a écrit :

Bonjour,

dans beaucoup de technologies réseau que connaît on à le choix de définir les algo de 
chiffrement utilisées, le premier niveau étant "None".

J'ai déjà vu des déploiements ou c'était le cas ;-) et c'est peut être ce que 
vous observez.



---
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] [TECH] Hmm GPON Kosc, étanche, vra iment ?

2022-05-31 Par sujet adminet59 via frnog 
Bonjour,

Déjà eu un souci  à peu près similaire sur la métropole lilloise avec Kosc en
2019 .

Je recevais les session ppp d'autres clients avec des magicnumber différents
et mon routeur n'aimait pas vraiment (il faisait tomber ma propre session)

Du retour que j'en ai eu, il s'agissait d'un souci d'isolation de vlan et pas
lié au GPON. Kosc avait fixé la conf durant une nuit.




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet David Ponzone 
Ok donc la sélection du traffic qui concerne le CPE ne repose que sur le 
cryptage (coucou Gary), parce que effectivement, et merci pour la correction, 
dans le sens descendant, il n’y a qu’un émetteur donc pas de problème de 
collision, donc pas besoin de TDM.

Si c’est donc bien ça qui déconne sur certains OLT Altitude, je suis quand même 
surpris par le peu de traffic que je reçois pour les autres clients, mais 
néanmoins quasi-permanent (c’est comme un bruit de fond de 500Kbps, ça 
ressemble pas du tout à du traffic Internet habituel).

Ca veut aussi dire que si le traffic est en clair, il peut saturer la capa du 
port 1G entre l’ONT et le CPE de tous les clients sur le PON.
Rien que pour cette raison, cela ne devrait pas être optionnel, sauf peut-être 
pour des tests.

> Le 31 mai 2022 à 16:19, Patrick Chollat  a écrit :
> 
> Dans la technologie GPON tous les ONT d'un PON reçoivent le trafic de tous 
> les ONT du PON dans le sens descendant ,d'où la nécessité de l'encryptage.
> Le TDMA n'est utilisé que dans le sens montant.
> 
> Le mar. 31 mai 2022 à 16:09, David Ponzone  > a écrit :
> Que le traffic ne soit pas crypté ne signifie pas que tous les ONT le 
> forwardent vers le CPE.
> Sinon je vois mal comment le CPE du client va faire pour gérer sur son port 
> 1G un max de 2.4Gbps de traffic dont une grrrande partie n’est pas pour lui.
> Ca serait pathétique de la part de la techno.
> L’ONT est censé faire une extraction TDM il me semble, avec décryptage 
> optionnel.
> 
> > Le 31 mai 2022 à 16:01, Benoît Grangé  > > a écrit :
> > 
> > Bonjour,
> > 
> > dans beaucoup de technologies réseau que connaît on à le choix de définir 
> > les algo de chiffrement utilisées, le premier niveau étant "None".
> > 
> > J'ai déjà vu des déploiements ou c'était le cas ;-) et c'est peut être ce 
> > que vous observez.
> > 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet Patrick Chollat 
Dans la technologie GPON tous les ONT d'un PON reçoivent le trafic de tous
les ONT du PON dans le sens descendant ,d'où la nécessité de l'encryptage.
Le TDMA n'est utilisé que dans le sens montant.

Le mar. 31 mai 2022 à 16:09, David Ponzone  a
écrit :

> Que le traffic ne soit pas crypté ne signifie pas que tous les ONT le
> forwardent vers le CPE.
> Sinon je vois mal comment le CPE du client va faire pour gérer sur son
> port 1G un max de 2.4Gbps de traffic dont une grrrande partie n’est pas
> pour lui.
> Ca serait pathétique de la part de la techno.
> L’ONT est censé faire une extraction TDM il me semble, avec décryptage
> optionnel.
>
> > Le 31 mai 2022 à 16:01, Benoît Grangé  a écrit
> :
> >
> > Bonjour,
> >
> > dans beaucoup de technologies réseau que connaît on à le choix de
> définir les algo de chiffrement utilisées, le premier niveau étant "None".
> >
> > J'ai déjà vu des déploiements ou c'était le cas ;-) et c'est peut être
> ce que vous observez.
> >
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[TECH] RE: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet Gary BLUM via frnog 
Bonjour,
https://chiffrer.info/

A bientôt.

> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de David
> Ponzone
> Envoyé : mardi 31 mai 2022 16:09
> À : Benoît Grangé 
> Cc : Xavier Beaudouin ; frnog-tech 
> Objet : Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?
> 
> Que le traffic ne soit pas crypté ne signifie pas que tous les ONT le 
> forwardent
> vers le CPE.
> Sinon je vois mal comment le CPE du client va faire pour gérer sur son port 
> 1G un
> max de 2.4Gbps de traffic dont une grrrande partie n’est pas pour lui.
> Ca serait pathétique de la part de la techno.
> L’ONT est censé faire une extraction TDM il me semble, avec décryptage
> optionnel.
> 
> > Le 31 mai 2022 à 16:01, Benoît Grangé  a écrit :
> >
> > Bonjour,
> >
> > dans beaucoup de technologies réseau que connaît on à le choix de définir 
> > les
> algo de chiffrement utilisées, le premier niveau étant "None".
> >
> > J'ai déjà vu des déploiements ou c'était le cas ;-) et c'est peut être ce 
> > que vous
> observez.
> >
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet David Ponzone 
Que le traffic ne soit pas crypté ne signifie pas que tous les ONT le 
forwardent vers le CPE.
Sinon je vois mal comment le CPE du client va faire pour gérer sur son port 1G 
un max de 2.4Gbps de traffic dont une grrrande partie n’est pas pour lui.
Ca serait pathétique de la part de la techno.
L’ONT est censé faire une extraction TDM il me semble, avec décryptage 
optionnel.

> Le 31 mai 2022 à 16:01, Benoît Grangé  a écrit :
> 
> Bonjour,
> 
> dans beaucoup de technologies réseau que connaît on à le choix de définir les 
> algo de chiffrement utilisées, le premier niveau étant "None".
> 
> J'ai déjà vu des déploiements ou c'était le cas ;-) et c'est peut être ce que 
> vous observez.
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet Benoît Grangé 
Bonjour,

dans beaucoup de technologies réseau que connaît on à le choix de définir
les algo de chiffrement utilisées, le premier niveau étant "None".

J'ai déjà vu des déploiements ou c'était le cas ;-) et c'est peut être ce
que vous observez.

Le mar. 31 mai 2022 à 15:39, David Ponzone  a
écrit :

> Et un ONT pourrait décoder sans connaitre le SLID des autres ONT sur la
> boucle ?
> Ca serait quand même une faiblesse légendaire dans la techno….
>
> Ce qui est quand même étonnant c’est que je ne vois pas tout le traffic
> (ou alors les autres clients font pas grand chose avec leur FTTH).
>
> Je vais finir par tenter de sniffer des mots de passe et les balancer sur
> twitter, ça fera peut-être se bouger les champions chez AI….
>
> > Le 31 mai 2022 à 15:35, Xavier Beaudouin via frnog  a
> écrit :
> >
> > Techniquement y a des gens qui ont réussi a bidouiller le linux dedans
> pour ce genre de chose...
> >
> > Donc si le machin est foireux, ou avec un bug qui est apparu dans le
> temps... c'est faisable vu la qualité du code dans le linux embarqué...
> >
> > /Xavoer
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
*Benoît Grangé*
Mobile: 06 58 58 05 59

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Problème de QoS sur FTTH Altitude Grand Est

2022-05-31 Par sujet David Ponzone 
C’est rentré dans l’ordre sur 54 et 55.

> Le 31 mai 2022 à 14:18, Daniel via frnog  a écrit :
> 
> Je viens de tester une ligne Vialis/67, tout est également fonctionnel.
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet David Ponzone 
> 
> En PPPoE ?
> Si oui, Tu reçois ça au niveau "E" ou "PPP" ???

Les 2 :)

Si je prends la trace au niveau E, je vois les trames PPPoE de « tout le monde 
».
Si je la prends au niveau de ma session PPPoE, je vois les paquets IP aussi de 
tout le monde...
Ca, c’est pas normal, donc je pense que c’est mon Mikrotik qui s’embrouille en 
voyant passer des paquets PPPoE pour une session qu’il n’a pas monté.

Pour être propre, j’ai coupé ma session PPPoE et je vois entre 500Kbps et 1Mbps 
entrant sur le port E.

Assez bizarrement, un des 3 clients est impacté au niveau QoS, son FTTH est 
inutilisable. Pas les 2 autres à priori.
Je crois qu’un des MK avec une configuration particulière (ingress DNAT) n’aime 
pas ces paquets PPPoE qui contiennent des paquets IP qui ne sont pas pour lui. 
Très très étrange.

> (...)
> 
>> Je pensais même pas qu???il était possible pour un ONT de décrypter
>> les trames de plusieurs clients???.
> 
> A priori, non.
> Mais il est possible que les flux OLT => ONT ne soient pas chiffrés.
> ( c'est optionnel )

Ben si y a un vrai journaliste spécialisé sur FRnOG, il sera peut-être 
intéressé d’aller questionner AI à ce sujet.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet Dominique Rousseau 
Le Mon, May 30, 2022 at 02:50:52PM +0200, David Ponzone 
[david.ponz...@gmail.com] a écrit:
> Il y a quelque chose de pourri au royaume du FTTH.
> 
> Chez un client FTTH (sur Kosc) dans le Grand Est, je reçois du traffic
> entrant destiné à d???autres clients.

En PPPoE ?
Si oui, Tu reçois ça au niveau "E" ou "PPP" ???

(...)

> Je pensais même pas qu???il était possible pour un ONT de décrypter
> les trames de plusieurs clients???.

A priori, non.
Mais il est possible que les flux OLT => ONT ne soient pas chiffrés.
( c'est optionnel )


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Contact SFR ? (pas de route IPv6 SFR/Renater)

2022-05-31 Par sujet Florent Guillot 

Bonjour,

On 31/05/2022 10:26, Willy Manga wrote:
Il y a pourtant plusieurs routes qui mènent vers AS2200 (RENATER) pour 
ce préfixe IPv6 . Exemple en regardant ici

https://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:660::/32
A mon humble avis, il faudrait regarder du côté du réseau de SFR.


On a également remarqué le soucis entre notre réseau et une partie de 
celui de SFR.
Ça concernait un bon nombre d'AS qui peer sur FranceIX Lyon. Pas juste 
Renater.
On recevait des ICMP TTL Expiré de la part de fc00:0:0:100::39 (routeur 
chez SFR), donc probablement boucle de routage.


Ils semblent avoir coupé l'ensemble de leur sessions de peering IPv6 sur 
LyonIX hier soir, et depuis la connectivité est de nouveau OK.
Plus qu'a espérer que le vrai soucis soit identifié rapidement et que 
les sessions v6 soient rallumés.

On n'a pas eu de retour de leur NOC pour l'instant.

Cordialement
Florent



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet David Ponzone 
Et un ONT pourrait décoder sans connaitre le SLID des autres ONT sur la boucle ?
Ca serait quand même une faiblesse légendaire dans la techno….

Ce qui est quand même étonnant c’est que je ne vois pas tout le traffic (ou 
alors les autres clients font pas grand chose avec leur FTTH).

Je vais finir par tenter de sniffer des mots de passe et les balancer sur 
twitter, ça fera peut-être se bouger les champions chez AI….

> Le 31 mai 2022 à 15:35, Xavier Beaudouin via frnog  a écrit :
> 
> Techniquement y a des gens qui ont réussi a bidouiller le linux dedans pour 
> ce genre de chose...
> 
> Donc si le machin est foireux, ou avec un bug qui est apparu dans le temps... 
> c'est faisable vu la qualité du code dans le linux embarqué...
> 
> /Xavoer
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet Xavier Beaudouin via frnog 
Techniquement y a des gens qui ont réussi a bidouiller le linux dedans pour ce 
genre de chose...

Donc si le machin est foireux, ou avec un bug qui est apparu dans le temps... 
c'est faisable vu la qualité du code dans le linux embarqué...

/Xavoer


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet David Ponzone 
Un ONT qui arrive à décrypter les trames de tous les clients d’une boucle PON ?
J’en veux bien un d’ONT comme ça, ça peut servir :)

J’ai ça chez 3 clients, au moins.

> Le 31 mai 2022 à 15:12, Xavier Beaudouin via frnog  a écrit :
> 
> Hello David,
> 
> T'es certain que c'est pas l'ONT qui fait n'importe quoi ?
> Ou qui a été provisionné en mode "doigt" mouillé... 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

2022-05-31 Par sujet Xavier Beaudouin via frnog 
Hello David,

T'es certain que c'est pas l'ONT qui fait n'importe quoi ?
Ou qui a été provisionné en mode "doigt" mouillé... 

/Xavier

- Mail original -
> De: "David Ponzone" 
> À: "frnog-tech" 
> Envoyé: Lundi 30 Mai 2022 14:50:52
> Objet: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?

> Il y a quelque chose de pourri au royaume du FTTH.
> 
> Chez un client FTTH (sur Kosc) dans le Grand Est, je reçois du traffic entrant
> destiné à d’autres clients.
> Difficile de se tromper: IP source et destination ne sont pas celles de mon
> client, et par contre au moins une des 2 appartient à un confrère: Keyyo,
> Alphalink, Flux Network, Paritel, pour citer quelques-unes des IP que j’ai
> tracées.
> 
> Je pensais même pas qu’il était possible pour un ONT de décrypter les trames 
> de
> plusieurs clients….
> 
> Si un confrère veut se lancer dans un debug fou avec moi, ou au moins me 
> fournir
> la confirmation que l’IP de son client est bien dans le Grand Est et que le
> FTTH est chez Kosc, on aura déjà le nom du responsable.
> 
> 
> David
> gsm:   06 66 98 76 34
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Problème de QoS sur FTTH Altitude Grand Est

2022-05-31 Par sujet Daniel via frnog 

Je viens de tester une ligne Vialis/67, tout est également fonctionnel.

Le 31/05/2022 à 14:15, David Ponzone a écrit :

Ok comme Hughes donc.

C’est donc plutôt 54 et 55, justement le secteur où j’ai des FTTH Kosc étranges 
(voir mon mail d’hier).
Et après analyse avec Kosc hier, il s’agit en fait de FTTH sur RIP Altitude sur 
OLT Nokia.
Je ne sais pas s’il y a un rapport avec le problème de ce jour cependant.


Le 31 mai 2022 à 14:12, Daniel  a écrit :


Le 31/05/2022 à 14:11, David Ponzone a écrit :

Quel secteur ?

67


Le 31 mai 2022 à 14:10, Daniel via frnog  a écrit :

Bonjour,

perso je ne note rien sur mes 2 liens (Free et Adista)

Le 31/05/2022 à 14:07, David Ponzone a écrit :

Depuis quelques minutes, des RTT à 70ms et packet loss massif sur tous les FTTH 
de AI dans le Grand Est.


--
Daniel


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Problème de QoS sur FTTH Altitude Grand Est

2022-05-31 Par sujet David Ponzone 
Ok comme Hughes donc.

C’est donc plutôt 54 et 55, justement le secteur où j’ai des FTTH Kosc étranges 
(voir mon mail d’hier).
Et après analyse avec Kosc hier, il s’agit en fait de FTTH sur RIP Altitude sur 
OLT Nokia.
Je ne sais pas s’il y a un rapport avec le problème de ce jour cependant.

> Le 31 mai 2022 à 14:12, Daniel  a écrit :
> 
> 
> Le 31/05/2022 à 14:11, David Ponzone a écrit :
>> Quel secteur ?
> 
> 67
> 
>>> Le 31 mai 2022 à 14:10, Daniel via frnog  a écrit :
>>> 
>>> Bonjour,
>>> 
>>> perso je ne note rien sur mes 2 liens (Free et Adista)
>>> 
>>> Le 31/05/2022 à 14:07, David Ponzone a écrit :
 Depuis quelques minutes, des RTT à 70ms et packet loss massif sur tous les 
 FTTH de AI dans le Grand Est.
>>> -- 
>>> Daniel
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
> 
> -- 
> Daniel Huhardeaux
> +33.368460...@tootai.netsip:8...@sip.tootai.net
> +41.445532...@swiss-itech.ch  tootaiNET


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Problème de QoS sur FTTH Altitude 54/55

2022-05-31 Par sujet David Ponzone 
Après analyse plus fine, c’est plutôt sur 54 et 55.

> Le 31 mai 2022 à 14:10, Hugues Voiturier  a écrit :
> 
> RAS ici sur une FTTH pro Altitude dans le 67, donc pas général a minima 
> 
> Hugues - AS2027
> 
>> On 31 May 2022, at 14:07, David Ponzone  wrote:
>> 
>> Depuis quelques minutes, des RTT à 70ms et packet loss massif sur tous les 
>> FTTH de AI dans le Grand Est.
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Problème de QoS sur FTTH Altitude Grand Est

2022-05-31 Par sujet Daniel via frnog 



Le 31/05/2022 à 14:11, David Ponzone a écrit :

Quel secteur ?


67


Le 31 mai 2022 à 14:10, Daniel via frnog  a écrit :

Bonjour,

perso je ne note rien sur mes 2 liens (Free et Adista)

Le 31/05/2022 à 14:07, David Ponzone a écrit :

Depuis quelques minutes, des RTT à 70ms et packet loss massif sur tous les FTTH 
de AI dans le Grand Est.

--
Daniel


---
Liste de diffusion du FRnOG
http://www.frnog.org/


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Problème de QoS sur FTTH Altitude Grand Est

2022-05-31 Par sujet David Ponzone 
Quel secteur ?

> Le 31 mai 2022 à 14:10, Daniel via frnog  a écrit :
> 
> Bonjour,
> 
> perso je ne note rien sur mes 2 liens (Free et Adista)
> 
> Le 31/05/2022 à 14:07, David Ponzone a écrit :
>> Depuis quelques minutes, des RTT à 70ms et packet loss massif sur tous les 
>> FTTH de AI dans le Grand Est.
> 
> -- 
> Daniel
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Problème de QoS sur FTTH Altitude Grand Est

2022-05-31 Par sujet Daniel via frnog 

Bonjour,

perso je ne note rien sur mes 2 liens (Free et Adista)

Le 31/05/2022 à 14:07, David Ponzone a écrit :

Depuis quelques minutes, des RTT à 70ms et packet loss massif sur tous les FTTH 
de AI dans le Grand Est.


--
Daniel


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Problème de QoS sur FTTH Altitude Grand Est

2022-05-31 Par sujet Hugues Voiturier 
RAS ici sur une FTTH pro Altitude dans le 67, donc pas général a minima 

Hugues - AS2027

> On 31 May 2022, at 14:07, David Ponzone  wrote:
> 
> Depuis quelques minutes, des RTT à 70ms et packet loss massif sur tous les 
> FTTH de AI dans le Grand Est.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [ALERT] Problème de QoS sur FTTH Altitude Grand Est

2022-05-31 Par sujet David Ponzone 
Depuis quelques minutes, des RTT à 70ms et packet loss massif sur tous les FTTH 
de AI dans le Grand Est.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Contact SFR ? (pas de route IPv6 SFR/Renater)

2022-05-31 Par sujet Willy Manga 

Bonjour,

On 30/05/2022 12:42, geoffroy desvernay via frnog wrote:

Bonjour à toustes,

Depuis bien 2 semaines, les utilisateurs SFR (mobile et dsl) ne peuvent 
plus joindre l'IPv6 du réseau renater (as2200), j'ai l'impression que ça 
concerne (au moins) le préfixe 2001:660::/32.


la seule source d'infos que j'ai trouvé est leur looking-glass 
http://peering.sfr.net/index.php?task=lg (le traceroute se perd avant de 
sortir du réseau SFR)



Il y a pourtant plusieurs routes qui mènent vers AS2200 (RENATER) pour 
ce préfixe IPv6 . Exemple en regardant ici


https://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:660::/32


A mon humble avis, il faudrait regarder du côté du réseau de SFR.




--
Willy Manga
@ongolaboy
https://ongola.blogspot.com/


OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] RFC 9234: Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages

2022-05-31 Par sujet Pierre-E 
Bonjour Stephane,

Article très intéressant concernant cette RFC dont j'avais déjà entendu parler, 
mais que je n'ai encore jamais vu implémenter.

J'ai juste une question, à la fin de l'article tu mentionnes que Bird 
l'implémente à travers l'option “local_role”, je ne trouve pas mention de ce 
paramètre dans la documentation.
Sais-tu si l'implémentation vient d'un fork ou d'un patch de Bird ? Ou 
simplement une erreur de recherche de ma part ?

Pierre-Emmanuel

> On 25 May 2022, at 10:26, Stephane Bortzmeyer  wrote:
> 
> Intéressant : mettre les relations plutôt « business » dans l'échange
> BGP.
> 
> https://www.bortzmeyer.org/9234.html
> 
> Quelqu'un a déployé ça ?
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/