Qu'est-ce que réduire l'EMS de 42 ?

J'exécute plusieurs VM dans Azure. Les VMs fonctionnent dans un sous-réseau avec NSG. Les cartes réseau n'utilisent pas de NSG, nous n'utilisons pas de réseau accéléré.

J'ai remarqué que lorsqu'une VM communique avec une autre VM du même sous-réseau en utilisant TCP, la valeur MSS dans les paquets SYN est réduite de 42. Cela signifie que si j'envoie un TCP SYN avec MSS=876 à une autre VM du même réseau, l'autre VM capturera un TCP SYN avec MSS=834 :

Client :

18:49:27.526527 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 876,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.528398 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1418,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.528430 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0

Serveur :

18:49:27.527362 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 834,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.527682 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1460,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.529167 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0

Nous utilisons de multiples NVA, et nos paquets SYN voyagent à travers de multiples sauts, et nous voyons effectivement le MSS être réduit plusieurs fois, nous avons initialement mesuré une réduction de 84, nous avons également mesuré une réduction de 138 dans certains cas (en effet pas un multiple de 42), cela signifie que nous réduisons de plus de 10% l'efficacité de notre réseau.

J'ai passé un certain temps à examiner comment divers appareils de réseau fonctionnent avec le MSS. Dans la plupart des cas, le MSS est fixé à un montant fixe, en étant soit bridé à une valeur statique, soit au MTU du chemin. PaloAlto utilisera un "ajustement" relatif au MTU d'une interface réseau, qui est une valeur fixe. Arista vous permettra d'imposer une valeur plafond au trafic d'entrée ou de sortie, là encore des valeurs absolues. Certains fournisseurs de pare-feu, comme PaloAlto, réduiront le MSS en cas d'attaque DoS et si les témoins SYN sont activés, mais le MSS sera l'une des 8 valeurs possibles dans ce cas.

Je pense que ce mécanisme MSS -= 42 casse le TCP : si le client supporte les trames jumbo et envoie un MSS de 8860, le serveur dans Azure reçoit 8876, lui-même répond 1330, mais le client reçoit 1246, le client acceptera que les paquets aient une charge utile de 1246 octets, alors que le serveur enverra 1330 octets de charge utile.

Le plus gros problème est que nous avons des cas où le trafic fonctionne "par hasard". Le serrage n'est pas effectué correctement du côté de la route express, et pourtant, à cause de ce -42 ici et là, le MSS est en fait réduit à une valeur qui "convient", jusqu'à ce qu'il y ait un léger changement dans la façon dont les paquets sont acheminés, et vous découvrez tout à coup qu'il y avait une mauvaise configuration quelque part.

Une idée pour expliquer cette réduction ? Je crois que ce comportement n'est documenté nulle part.

EDIT

Je lis juste RFC879

Le MSS peut être utilisé de manière totalement indépendante dans chaque direction du flux de données. Le résultat peut être des tailles maximales très différentes dans les deux directions.

Il semble donc légitime selon le RFC. Quand même, un comportement bizarre.