La théorie
Le rejeu, c'est le fait qu'un attaquant sniff la phase d'authentification, et s'en serve pour se connecter à notre place en rejouant la trame sniffée.
L'anti-rejeu, c'est le fait que lorsqu'une authentification a été effectuée, le salt est blacklisté.
De ce fait, même si on se fait voler notre chaine d'authentification, l'attaquant ne pourra pas la réutiliser/la rejouer puisqu'elle est "grillée".
Donc par définition cette chaine d'authentification DOIT être différente à chaque requête d'authentification.
La pratique
Par rapport à ce que dit le gars d'Orange sur le thread.
Les options ...
- 60 en IPv4 / 16 en IPv6: vendor class identifer
- 61 en IPv4 / 1 en IPv6: client identifier
- 77 en IPv4 / 15 en IPv6: userclass
... DOIVENT être identiques entre IPv4 et IPv6. Sinon, Orange coupe la connexion.
Par contre, concernant donc les options 90 en IPv4 et 11 en IPv6, authsend, elles DOIVENT être différentes, entre IPv4 et IPv6, et à chaque requête. Je cite: "Concernant le CHAP challenge et idéalement le changer à chaque cycle complet DHCP quand on change le TransactionID DHCP4/6 (voir RFC)".
En réalité, l'anti-rejeu n'est pas actif coté Orange car il est quasiment impossible pour le commun des mortels de sniffer la trame d'authentification sur un arbre GPON, c'est pour ça qu'ils ne s'embête pas avec ce système d'anti-rejeu. Changer la chaine d'authentification à chaque requête, c'est juste pour la beauté du geste aujourd'hui, ou pour le cas où Orange activerait l'anti-rejeu un jour.