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

[David Ponzone]

C’est corrigé!

Maintenant, on va voir si la transparence est là….


> Le 1 juin 2022 à 10:02, Raphael Mazelier  a écrit :
> 
> Ah mais c'est dans la session pppoe. Ok c'est n'importe quoi mais différent.
> 
> --
> Raphael Mazelier
> 
> On 01/06/2022 09:15, Jérôme Marteaux wrote:
>> 
>> J'ai un lien dans le lot, je confirme, le CPE reçoit des paquets dans la 
>> session PPPoE qui ne sont pas pour lui et le pire c'est qu'il les traite car 
>> ils ont tout l'air d'être correct.
>> 
>> Incroyable ! Quel bug !
>> 
>> 
>> Jérôme
>> 
> ---
> 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 ?

[Raphael Mazelier]

Ah mais c'est dans la session pppoe. Ok c'est n'importe quoi mais 
différent.


--
Raphael Mazelier

On 01/06/2022 09:15, Jérôme Marteaux wrote:


J'ai un lien dans le lot, je confirme, le CPE reçoit des paquets dans 
la session PPPoE qui ne sont pas pour lui et le pire c'est qu'il les 
traite car ils ont tout l'air d'être correct.


Incroyable ! Quel bug !


Jérôme


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

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

[Jérôme Marteaux]

Le 01/06/2022 à 00:48, David Ponzone a écrit :

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!)


> [...]
>

--- 5.134.101.211 ping statistics ---
1 packets transmitted, 1 packets received, +55 duplicates, 0.0% packet loss
round-trip min/avg/max/stddev = 20.505/83.371/148.402/33.396 ms

Je jure que je n’ai absolument pas altérer le résultat, j’ai juste fait un 
ctrl-C pour arrêter les frais :)

Y a des réponses venant de Kertel, de Convergence, d'Alphalink, de Networth, 
etc….

Le truc amusant, c’est que si je veux arrêter de recevoir ce traffic parasite 
chez mon client, j’ai juste à faire tomber le PPPoE.
Quand il remonte, c’est clean, pendant quelques minutes et après ça revient.



J'ai un lien dans le lot, je confirme, le CPE reçoit des paquets dans la 
session PPPoE qui ne sont pas pour lui et le pire c'est qu'il les traite 
car ils ont tout l'air d'être correct.


Incroyable ! Quel bug !


Jérôme

--
Jérôme Marteaux


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

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

[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 

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

[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/

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

[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 ?

[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 ?

[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 ?

[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 ?

[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 ?

[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, vraiment ?

[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 ?

[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 ?

[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 ?

[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 ?

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

[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 ?

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

[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 ?

[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 ?

[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 ?

[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/

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

[David Ponzone]

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/