Par contre si la communauté peux remonter à WireGuard que c'est "pas classe" de se déguiser en AF41 pour établir le tunnel ou au moins laisser le choix de ne PAS le faire, cela serait bien.
Cela sera plus générique comme réponse

On a des experts open source ici qui pourraient prendre cela ?

LeVieux

Il faut également remonter la demande à OpenSSH, non ?

Oui ! effectivement, bien vu !

Après, je me demande si le plus efficace n'est pas de passer par les experts Linux chez Orange.

J'ai franchement été bluffé par le niveau de maîtrise des experts Linux Orange pour détecter puis faire corriger des sujets très complexes. Ils ont la capacité de proposer un code qui résout le bug et le faire remonter directement à la bonne personne en charge du code en question et que ce code soit déployé massivement.

Je pense que peu d'opérateur au niveau mondial ont ce niveau d'expertise en interne.

Chaque trois semaines, des centaines de correctifs dans le noyau Linux sont distribués, ils corrigent quoi ?

Il n'y a pas que des failles de sécurité qui sont corrigées. Il y a aussi des bugs qui peuvent vous impacter.

Je vais m'attarder sur un exemple précis de régression qui entraînait des période(s) de 200 millisecondes où le transfert réseau est interrompu, entraînant une baisse de débit moyen pouvant aller jusqu’à 10%, pour les connexions TCP impactées par cette violation de la RFC793. Les RFC sont des documents décrivant les aspects et spécifications techniques d'Internet. Celle-ci date de 1981 et décrit le standard TCP (Transmission Control Protocol) que nous utilisons systématiquement sur Internet, au-dessus d'IPv4 ou d'IPv6. L'alternative possible à TCP est UDP.

Ce bug qui impactait tous les serveurs équipés d'un Linux récent a été découvert et corrigé par... Orange France.
J'ai vraiment été admiratif du travail des équipes d'Orange, qui consiste, quand il y a un bug, à ne pas se limiter à trouver un contournent, mais à chercher l'origine du bug dans le code et proposer un correctif au mainteneur du code en question, pour que le monde entier profite du correctif.

Concrètement pour Ubuntu, le 1^er décembre 2020, le noyau 5.4.0-56-generic #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 était déployé pour succéder au noyau 5.4.0-54-generic.

Le noyau 5.4.0-55-generic qui intègre plus de 1300 correctifs de bug n'a pas été publié, car la CVE-2020-4788 classée "medium" est arrivée pendant sa phase de validation de non régression. Le 5.4.0-56-generic intègre le 5.4.0-55-generic et rajoute la correction de la CVE-2020-4788.

Dans la liste des 1300 correctifs, il y a tcp: fix receive window update in tcp_add_backlog(), le bug trouvé et corrigé par Orange. On va voir ce qui se cache derrière, les impacts et pourquoi ce type de bug est complexe à trouver.

La régression, découverte par Orange en octobre 2020, était dans le fichier tcp_ipv4.c:tcp_add_backlog(). Non seulement cela pouvait dégrader les performances réseau dans certaines circonstances mais c'était également la source d'un bug dans netfilter, un pare-feu intégré au sein du noyau Linux. Le patch (bugfix) proposé par Orange a été backporté dans la branche stable du noyau Linux et intégré par les différentes distributions plus ou moins rapidement. Pour Ubuntu, il a été poussé à tous le 1^er décembre 2020 avec des centaines d'autres correctifs, dont une faille de sécurité, c'est donc proposé comme une mise à jour de sécurité.

Voici quelques diapositives, publiées avec l'accord d'Orange, qui explique la problématique technique :

Détail technique du problème rencontré :

L’algorithme TCP a dans sa structure deux octets pour indiquer la taille de la fenêtre demandée, c'est-à-dire le nombre d'octets que le récepteur souhaite recevoir sans accusé de réception. Un émetteur n’a strictement pas le droit d’émettre un paquet excédant la RWIN indiquée par le récepteur, comme l’explique la RFC793.

Dans certains cas spécifiques, quand plusieurs paramètres sont réunis, notamment quand le client a une RWIN en diminution forte, jusqu’à devenir nulle nous observons une violation flagrante de la RFC par le serveur qui va envoyer 10ko de payload excédant la RWIN. La diminution de la RWIN est un mécanisme minoritaire, mais fréquent, qui a plus de chances de se déclencher lorsque le débit client est fort, car en situation de débit plus faible, les mécanismes de contrôle de congestion côté serveur prennent le dessus.

Les 10 ko de données envoyés en violation de la RFC793 sont peu, mais suffisant pour placer les piles TCP client et serveur dans un état non souhaité / non prévu :

• Le client va droper ces paquets supplémentaires, faute de mémoire pour les stocker.
• Par la suite le client n’émet que des acquittements TCP avec une RWIN qui continue de diminuer pour devenir nulle.
• Lorsque de la place est de nouveau disponible dans sa mémoire, le client envoie un acquittement au serveur, avec une RWIN non nulle, mais inférieure aux 10ko excédentaires.
• Le serveur reçoit cet acquittement TCP lui indiquant qu’il peut envoyer des paquets... qu’il a déjà envoyé. Le serveur ne fait donc rien.
• Émetteurs et récepteur restent en attente pendant environ 200ms, avant un TLP (Tail Loss Probe) envoyée par le serveur qui fait redémarrer les échanges.

Impacts sur les performances :

Cette problématique peut se produire plusieurs fois dans une même connexion TCP utilisée pour un transfert d’un fichier de 50 Mo.

Les conséquences sont une ou des période(s) de 200 millisecondes où le transfert est interrompu, entraînant une baisse de débit moyen pouvant aller jusqu’à 10%, pour les connexions TCP impactées par cette régression.

Tous les opérateurs sont potentiellement affectés cette violation de la RFC793, en IPv4 comme en IPv6. Cette baisse de débit moyen de 10% concerne uniquement des tests réalisés dans de très bonnes conditions radio.







Précision, ces diapositives ont été crées avant que le bug dans le code Linux soit identifié.

Le correctif, intitulé tcp: fix receive window update in tcp_add_backlog() est présent dans les changelog du noyau diffusé le 1^er décembre 2020 :
- Changelog du noyau Linux 5.4.0-56 du 1^er décembre 2020
- Changelog du noyau Linux 5.8.0-31 du 1^er décembre 2020

On peut remercier Orange pour le travail.

J'ai fait encore d'autres tests ce matin :

Merci pour ces tests (j'aurais jamais eu accès à autant de SIM sur autant d'offre différentes comme cela de mon coté !

L'alerte est lancée, on regarde comment adresser le problème par le bon bout ...

LeVieux

Par contre si la communauté peux remonter à WireGuard que c'est "pas classe" de se déguiser en AF41 pour établir le tunnel ou au moins laisser le choix de ne PAS le faire, cela serait bien.

Je suis de l'avis inverse, ce n'est "pas classe" de classifier tout le trafic a partir des premiers paquets ou la présence d'un seul paquet AF41. Ca devrait être stateless et "par paquet". Mais d'accord qu'on puisse le désactiver coté Wireguard.

Il faudrait voir ce que disent les RFCs en détails, mais je serais prêt a parier que la notion de flux (ou meme de TCP ou UDP vu que ca peut être un autre proto L4) n'a rien a  faire la. Ca devrait être du stateless L3 pur (IP pur) voir du L2 (avec mapping CoS), paquet par paquet.

Et quelle(s) raison(s) aurait eu Orange de classifier tout un flux sur quelques paquets ? je ne vois pas. On ne peut abuser du truc car au contraire on se retrouve pénaliser.

Je suis de l'avis inverse, ce n'est "pas classe" de classifier tout le trafic a partir des premiers paquets ou la présence d'un seul paquet AF41. Ca devrait être stateless et "par paquet". Mais d'accord qu'on puisse le désactiver coté Wireguard.

Il faudrait voir ce que disent les RFCs en détails, mais je serais prêt a parier que la notion de flux (ou meme de TCP ou UDP vu que ca peut être un autre proto L4) n'a rien a  faire la. Ca devrait être du stateless L3 pur (IP pur) voir du L2 (avec mapping CoS), paquet par paquet.

Et quelle(s) raison(s) aurait eu Orange de classifier tout un flux sur quelques paquets ? je ne vois pas. On ne peut abuser du truc car au contraire on se retrouve pénaliser.

La il faudra laisser les experts en discuter, là vu la question ils vont de toutes les manières devoir s'y pencher en profondeur.

Ce qui n'est pas "classe" dans l'absolu c'est de mettre cela en place sans option de garder le comportement précédent, voir de figer la classe a ce que l'utilisateur décide / a besoin.
On pourrait même avoir des FW qui interdisent le passage de Pkt de ce type avec une QoS différente de celle attendu. Trouver une QoS "Flux Real Time VIDEO" sur un paquet d'établissement de VPN, cela peut être vu comme une violation de règle de sécu.


Et si effectivement, ce que tu indiques (cela doit être vu stateless avec une évolution possible de la classe utilisé au long de la vie du flux) de toutes les manière cela va devoir se regarder en profondeur sur beaucoup d'éléments du réseau pour prendre cela en compte dans les architectures à venir

en tout cas, le sujet est pris en compte et cela sera vu sous tous les angles, celui là aussi

LeVieux