Auteur Sujet: Orange DHCP conformité protocolaire 2023 - lire depuis le début du sujet  (Lu 154830 fois)

0 Membres et 1 Invité sur ce sujet

levieuxatorange

  • Expert Orange
  • Expert
  • *
  • Messages: 167
Bonjour

J'ai un ensemble  d'informations à vous communiquer vous qui avez remplacé votre LB par un routeur.

Très prochainement va commencer le déploiement d'un changement dans le réseau Orange.

Concrètement, ce qui va changer (et qui peut vous impacter)  :
- le contrôle du mot de passe dans l'option 90 (DHVPv4) et 11 (DHCPv6) va être total.
Vous devez mettre en place ce qui se trouve dans ces posts :
https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/
https://jsfiddle.net/kgersen/3mnsc6wy/
- contrôle de la cohérence entre les demandes entre DHCPv4 et DHCPv6 => il faut donc bien mettre une trame valide en DHCPv4 mais aussi en DHCPv6
- contrôle du respect protocolaire des stack DHCPv4 et DHCPv6 va être renforcé.

Il est à noter que en cas de non respect de la cohérence (soit entre les deux protocoles, soit au sein d'un même protocole) la ligne sera déconnectée.
La ligne => les 2 stacks v4 et v6

Si votre option 90 / 11 n'est pas valide avec un comportement protocolaire valide, vous serez "parqué" avec une IP en 172.19.x.y

levieux

Nota : pourquoi "levieuxatorange" : parce que c'est dingue le nombre de mail contenant "orange" que l'on trouve sur gmail.
Nota 2 : le niveau technique des gens ici m'étonne toujours ! Y'a des furieux, furieusement compétents !


Voir le post 2 de ce thread dans lequel j'ai mis le résumé des échanges
« Modifié: 02 mars 2023 à 12:37:09 par levieuxatorange »

levieuxatorange

  • Expert Orange
  • Expert
  • *
  • Messages: 167
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #1 le: 08 novembre 2022 à 09:18:30 »
Bonjour

Je vais utiliser ce post là pour reprendre un peu le contenu de tous les échanges.

Principe général

Une LB, c'est BIEN, si vous ne vous en tirez pas, ressortez vos LB :)
Ce qui suit ne concerne QUE le OneP internet Only.
Pour tout ce qui est 3P (Internet + VoIP + TV) j'ai vu des tentatives de bidouilles mais mon conseil reste : ressortez vos LB dans ce cas ...
Il existe plein de mécanismes dans la LB pour assurer une qualité maximale. Chose que je ne vois pas dans vos confs ... ni dans les capacités de vos routeurs => ressortez vos LB (Ok, promis, c'est la dernière fois que je le mets)

Ce qui est exposé ici est une clarification d'un nombre certain de choses que vous aviez déjà trouvés en reverse analyse de la conf Orange.
On pose des clarifications pour plusieurs raisons:
  • La communauté de lafibre est compétente et motivée, donc vous y arriverez c'est juste une question de temps
  • Vos erreurs de confs sont riches d'enseignement pour nous dans nos analyses. Vous êtes inventifs aussi
  • Vous êtes des techs, et on aime bien les techs ...
  • Entre temps, cela ne perturbera pas les analyses des cas tordus "légitimes"

Principe d'évolution courante du réseau :
On finalise le changement de mode de fonctionnement du réseau Orange (passage du PPP à du vrai DualStack). Cela sur le long chemin du IPv6 prioritaire avec du partage d'IPv4 qui arrivera quelque part dans le futur (CGN)
Cette finalisation passe par un changement de fonctionnement de l'accroche au réseau avec une consolidation du comportement des 2 stacks IPv4 IPv6 (principe de fonctionnement d'un BNG où on gère un contexte client indépendamment de sa connectivité IPv4 IPv6 ou CGN)
Cela passe donc pour vous par une mise aux normes de vos connexions DHCPv4 et DHCPv6 pour que les deux soient cohérentes entre elles.
En cas d'incohérence, le comportement du réseau est de déconnecter le client et toutes ses connexions.
A noter que le PPPoE reste en activité, il n'y a aucune date de suppression à ce jour. Mais le DHCPv4v6, c'est mieux pour tout un tas de raisons.

Indicateur pour savoir si vous avez été migré :
Comme on commence les migrations en nombre, il n'est pas évident de savoir si vous avez été migré ou pas.
Les marqueurs sont les suivants :
- en DHCPv4, si vous recevez une IP en 172.16.x.y avec un code retour option 125 (voir plus bas) vous donnant une erreur c'est que vous avez probablement migré et que vous avez une erreur. Attention, l'ancien système donne déjà certain code d'erreur, donc ce n'est pas un marqueur absolu
- en DHCPv6, si vous recevez une option 17, c'est que vous avez migré (même si le code retour (voir plus bas) est OK). Cette option 17 n'est PAS présente dans l'ancien système
- en DHCPv6, si vous recevez un préfix avec une lease de 231 jours une option 17 avec un code erreur (voir plus bas) , c'est que vous avez migré et que vous avez une erreur.
 
Les modes supportés :
  • IPv4 Only est supporté
  • IPv6 Only est supporté, il manque les DNS pour le moment qui ne sont pas donnés par le DHCPv6 (cela devrait changer dans le futur moyen proche), à vous de trouver un DNS IPv6 qui répond
  • IPv4 + IPv6  est supporté et là la cohérence entre les deux stacks est importante. Pour la résolution DNS, IPv4 Only est suffisant pour le moment
Attention cependant, IPv4 only c'est pas le "futur' et de plus en plus d'accès deviennent meilleurs en réseau en IPv6 au niveau inter opérateurs . . .

le DHCP et l'IPv4 Fixe est supporté.

Traitement des erreurs : le parcage  :
Un des grands principes mis en place, c'est que en cas d'erreur, on ne laisse pas le device boucler et charger pour rien le réseau.
On lui donne un bail v4 et v6, mais avec des adresse/prefix qui sont non routable / non routé.
Et cela s'accompagne d'un message dans la trame DHCP retour qui donne la cause de ce parcage
Ce parcage est 100% dynamique.
En cas d'erreur de config, un simple reboot (après correction ...) suffit à vous sortir du parcage
Dans les cas ou le code retour vous signal un blacklistage de ligne ou fermeture de compte, là, vous ressortez vos LB avant d'appeler le service client.
Le blacklistage de ligne peut se produire si vous pilonner le réseau n'importe comment ...

Le "Deep inside"


Les messages DHCP4/6 supportés :
Se limiter aux messages
  • IPv4 : DORA + RENEW / REBIND + RELEASE
  • IPv6 : SARR + RENEW / REBIND + RELEASE
Respecter les cycle de vie définis dans les RFC idoines et relancer depuis le DORA / SARR en cas de perte de la connectivité montante (à tester avec ARP et ICMPv6 NS/NA) comme le fait la LiveBox
Si le fait que l'on ne donne pas de DNS en DHCP6 ne plait pas à votre stack, faire attention à ne pas flooder le réseau avec des DHCP6 INFORM ou autre

Attention: l'option DHCPv6 "Rapid Commit" n'est PAS supportée

Les DNS :
Actuellement, le DNS est donné dans le DHCPv4 seulement
Cela changera dans un futur plus ou moins proche pour être donné en DHCPv4 et DHCPv6
La préco ici est qu'à partir du moment où cela sera donné en DHCPv6, il faudra utiliser en priorité les DNS IPv6.
Pour le moment il est tout à fait fonctionnel d'utiliser un DNSv4 pour la résolution des AAAA, donc cela marche très bien.
Si vous souhaitez mettre en place des conf IPv6 Only dès à présent, à vous de trouver un DNS IPv6 qui répond à vos requêtes.
Attention, pour la TV et la VoIP (voir la remarque de début sur le 3P et les LB) il FAUT utiliser les DNS resolver Orange qui sont donnés dans le DHCP de Orange.

L'encodage des information d'authentification  :
Le gros morceau. Chez Orange on a choisi de gérer une identification client "in line". L'objectif n'est pas ici de discuter de la pertinence de ce choix, mais de vous aider à faire marcher cela.
Cette identification / authentification se loge dans les options DHCPv4 90 et DHCPv6 11.
C'est fondamentalement un CHAP ou le challenge est choisi par vous.
Comme il manque 2 PKts au CHAP, le IDENTIFIER et le CHALLENGE sont à choisir par vous
Concernant le CHAP challenge et idéalement le changer à chaque cycle complet DHCP quand on change le TransactionID DHCP4/6 (voir RFC)

Ici vous trouverez un bon générateur issu du long thread de reverse engenering de ces options
https://jsfiddle.net/kgersen/3mnsc6wy/

Le canal retour :
Dans la réponse DHCP il y a un canal de retour du réseau.
C'est l'option 125 en DHCPv4, l'option 17 en DHCPv6
Le contenu (attention, les entêtes des options sont différentes, voir les RFC) est le même et dans le format suivant avec en rouge 2 octets de code d'information : 0001000000ffffffffff
Les grandes classes de réponses sont :
- 00xx : OK vu du réseau Orange et tout doit fonctionner. Si ce n'est pas le cas le problème vient de chez vous.
- 01xx : Le modèle de box, le firmware ou votre ligne est bloquée (0102 ce qui peut arriver si le comportement de votre routeur est trop agressif ...) 0199 en cas de mauvaise COS sur le DHCP
- 02xx : erreur de Login ou de Mot de passe ou d'encodage
- 03xx : compte ou service probablement résilié
- 04xx : problème de règlement de la facture avec de possibles limitation de débit ou blocage.

La mystérieuse COS6 ... :
La COS6 sert à prioriser les pkts DHCP(4/6), ARP et ICMP NS/NA entre la boxe et la BNG (premier routeur qui gère les IPs)  qui gère le contexte client.
Normalement, une COS0 sur ces paquets ne devrait pas marcher, mais un bug de certain équipement le permet.
Comme vous ne pouvez pas savoir sur quel équipement vous êtes ni si vous allez rester dessus (upgrade / changement / réaménagement) je conseille fortement de passer la conf en COS6
La COS6 ne va pas plus loin que le BNG et est remplacé par une COS0 à ce point, il ne sert donc à rien de taguer tous vos paquets en COS6. De plus le trafic en COS6 est fortement limité en débit, donc là aussi, si vous pouvez limiter proprement uniquement aux paquets ci dessus, c'est nettement mieux.
La COS6 jusqu'au BNG sert à protéger le trafic d'établissement et de maintient de la connexion en cas de surcharge sur le segment client <-> BNG. Plein de cas possible.

La COS6 (et idéalement le pendant dscp) doit être appliqué :
  • Au DHCPv4v6 issu de la boxe
  • Au ARP issu de la boxe
  • A l'ICMPv6 code NS/NA issu de la boxe et à destination de l'ipv6 fe80::ba0:bab
  • A l'ICMPv6 code RS issu de la boxe et à destination de l'ipv6 multicast idoine (c'est ba0bab qui répond)
  • Rien d'autre ...

Le BNG peut avoir utilité à avoir un marquage DSCP en plus de la COS.
Cependant très peu de chance que ce BNG soit à saturation, ni sur les cartes d'interface, ni en coeur.
Je maintiens donc : DSCP cohérent avec la COS, c'est mieux. Mais dans > 99% des cas cela se passera bien même sans le DSCP en ligne avec la COS

Adrese MAC et DUID :
Les informations de MAC et de DUID sont obligatoires.
En DHCPv4, l'option 61 devient obligatoire
En DHCPv6, la DUID est aussi impératif
Les options ClientID sont les MAC en HEXA, SANS les ":" entre les bloc ...
DHCPv4 :
Option: (61) Client identifier
    Length: 7
    Hardware type: Ethernet (0x01)
    Client MAC address: 44d454XXXXXX

l'encodage Hexa de ce qui est ci dessus :    3d 07 01 44 d4 54 XX XX XX

DHCPv6:
Client Identifier
    Option: Client Identifier (1)
    Length: 10
    Value: 0003000144d454XXXXXX
    DUID: 0003000144d454XXXXXX
    DUID Type: link-layer address (3)
    Hardware type: Ethernet (1)
    Link-layer address: 44:d4:54:XX:XX:XX

l'encodage Hexa de ce qui est ci dessus :   00 01 00 0a 00 03 00 01 44 d4 54 XX XX XX
Comme indiqué dans l'encodage des RFC

DUID et MAC : Principe général : éviter de jouer avec pour en changer trop vite ... On a des fonctions dans le réseau qui limitent le nbe de DUID / MAC derrière un même accès. Mais cela vous le saviez déjà.
Avec une temporisation de clear "d 'un certain temps" ..
Eteindre ou débrancher l'ONT, je ne suis pas certain que cela nettoie à 100% de chance ton contexte dans le OLT/DSLAM face à ta ligne, je vais vérifier ce point, mais je ne pense pas.

Attention quand vous faites vos tests, les baux sont à 3 jours et vont être allongés (en fin de migration, donc pas tout de suite )

Toujours pour protection, certains équipements n'autorisent que qq baux en parallèle sur une ligne, donc :
- faire un RELEASE (v4 et V6) avant de jouer avec votre DUID
- ne pas changer de DUID pour le fun à la volé ...
Si tous les contextes sont pris sur l'équipement, il faut attendre la fin du plus vieux des baux pour pouvoir vous relancer ... (cela peut donc durer .... 3 jours ....)

Dernier principe général : quand vous perdez la connectivité, faire un RELEASE v4 et V6 (un truc propre quoi .. comme fait une box nativement :) )

Un conseil: choisissez une MAC (celle de votre LB est une bonne candidate) et garder la. Y'a pas de contrainte sur la MAC, mais évitez d'en changer à la volé ou n'importe comment.

De l'importance des tests de vie :
La cnx de la LB peut être interrompue sur plusieurs segments entre la LB et le BNG.
Si vous ne testez pas la cnx montante, vous allez vous retrouver hors séquence et donc vous faire blaster régulièrement.
Cela doit être fait sur LES DEUX stacks Ipv4 et IPv6
Une capture minimal de ce que fait la LB vous permettra de comprendre la puissance de ces deux algos ....
Et quand vous détectez une fin de vie sur un stack, vous relancez celui ci (cycle DORA ou SARR suivant le stack) proprement
Faite un RELEASE (du bon stack) AVANT de relancer le cycle ....
Durant votre capture, vous verrez que le BNG fait de même dans l'autre sens ... d'où l'importance de bien répondre à ces message avec la bonne COS6


Exemple de trames :
En IPv6 le ClientID (DHCPv6 option 1) est obligatoire. Nettement mieux si c'est cohérent avec l'adresse LLA et là MAC du Pkt IPv6

En IPv4 il te faut :
Dynamic Host Configuration Protocol (Discover)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x6ac82ac7
    Seconds elapsed: 1
    Bootp flags: 0x8000, Broadcast flag (Broadcast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: 44:d4:54:XX:XX:XX
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Discover)
    Option: (55) Parameter Request List
        Length: 12
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (15) Domain Name
        Parameter Request List Item: (28) Broadcast Address
        Parameter Request List Item: (51) IP Address Lease Time
        Parameter Request List Item: (58) Renewal Time Value
        Parameter Request List Item: (59) Rebinding Time Value
        Parameter Request List Item: (90) Authentication
        Parameter Request List Item: (119) Domain Search
        Parameter Request List Item: (120) SIP Servers
        Parameter Request List Item: (125) V-I Vendor-specific Information
    Option: (60) Vendor class identifier
    Option: (61) Client identifier
    Option: (77) User Class Information
    Option: (90) Authentication
    Option: (255) End

En DHCPv6
DHCPv6
    Message type: Solicit (1)
    Transaction ID: 0x1eace9
    Client Identifier
        Option: Client Identifier (1)
        Length: 10
        Value: 0003000144d454XXXXXX
        DUID: 0003000144d454XXXXXX
        DUID Type: link-layer address (3)
        Hardware type: Ethernet (1)
        Link-layer address: 44:d4:54:XX:XX:XX
    Elapsed time
        Option: Elapsed time (8)
        Length: 2
        Value: 0000
        Elapsed time: 0ms
    Option Request
        Option: Option Request (6)
        Length: 8
        Value: 000b001100170018
        Requested Option code: Authentication (11)
        Requested Option code: Vendor-specific Information (17)
        Requested Option code: DNS recursive name server (23)
        Requested Option code: Domain Search List (24)
    Identity Association for Prefix Delegation
    Authentication
        Option: Authentication (11)
        Length: 70
        Value: 00000000000000000000001a0900000558010341010dXXXX…
        Protocol: 0
        Algorithm: 0
        RDM: 0
        Replay Detection: 0000000000000000
        Authentication Information: 1a0900000558010341010dXXXX…
    User Class
        Option: User Class (15)
        Length: 45
        Value: 002b46535644534c5f6c697665626f782e496e7465726e65…
    Vendor Class
        Option: Vendor Class (16)
        Length: 11
        Value: 0000040e0005736167656d
        Enterprise ID: SAGEMCOM SAS (1038)
        vendor-class-data: sagem


LeVieux
« Modifié: 06 mars 2023 à 10:51:28 par levieuxatorange »

cyayon

  • Abonné Orange Fibre
  • *
  • Messages: 648
  • Cordon 74 - Orange Fibre Pro
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #2 le: 08 novembre 2022 à 14:07:55 »
Merci pour ces infos.

En espérant que cela ne bloque pas trop pour qu'on puisse debugger quand il y a problème.

Typiquement, je viens de passer de dhclient à systeme-networkd, j'ai fait un paquet de restart en sniffant pour trouver un problème de DUID, je ne suis pas certain que le serveur DHCP orange ai apprécié.
Tout est rentré dans l'ordre, mais si on doit appeler le 3900 ou 3901 pour dé-parquer l'IP ou faire un reset du status, ca pas être simple de donner des explications :-(

 Ce serait tellement plus simple un mode bridge sur la livebox comme chez Free avec une bonne deleguation de prefix ipv6 en mode routeur.

levieuxatorange

  • Expert Orange
  • Expert
  • *
  • Messages: 167
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #3 le: 08 novembre 2022 à 15:43:06 »
Bonjour

Le parcage n'est pas définitif, il est purement dynamique.
Un simple reboot / redémarrage des stack v4/v6 en respectant le protocole et les champs 90/11 correct permet d'en sortir.
Aucun appel au 3900 n'est nécessaire (3900 qui ne soutient que un client avec une LB)

Sur les demandes de soutien et d'évolution, le point d'entré sera la responsable Market Orange Grand Public

levieux

cyayon

  • Abonné Orange Fibre
  • *
  • Messages: 648
  • Cordon 74 - Orange Fibre Pro
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #4 le: 08 novembre 2022 à 16:08:14 »
Bonjour

Le parcage n'est pas définitif, il est purement dynamique.
Un simple reboot / redémarrage des stack v4/v6 en respectant le protocole et les champs 90/11 correct permet d'en sortir.
Aucun appel au 3900 n'est nécessaire (3900 qui ne soutient que un client avec une LB)

Sur les demandes de soutien et d'évolution, le point d'entré sera la responsable Market Orange Grand Public

levieux

Merci ;)

PS : à l'occasion, passe le bonjour de la part du forum au responsable marketing :)

Nao

  • Abonné FAI autre
  • *
  • Messages: 152
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #5 le: 09 novembre 2022 à 06:39:26 »
Merci pour ces informations très intéressantes.

Ce changement serait-il dû a une modernisation du réseau ou autre chose ?

dmfr

  • Abonné Orange adsl
  • *
  • Messages: 275
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #6 le: 12 novembre 2022 à 01:03:38 »
Il va y avoir des scènes de ménage chez ceux qui ont remplacé leur livebox à la va-vite.
A la va-vite = en laissant de côté l'IPv6.

levieuxatorange

  • Expert Orange
  • Expert
  • *
  • Messages: 167
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #7 le: 14 novembre 2022 à 09:20:54 »
Bonjour

IPv4 Only est supporté
IPv6 Only est supporté, il manque les DNS pour le moment qui ne sont pas donnés par le DHCPv6 (cela devrait changer dans le futur moyen proche), à vous de trouver un DNS IPv6 qui répond
IPv4 + IPv6  est supporté et là la cohérence entre les deux stacks est importante. Pour la résolution DNS, IPv4 Only est suffisant pour le moment.

Attention cependant, IPv4 only c'est pas le "futur' et de plus en plus d'accès deviennent meilleurs en réseau en IPv6 au niveau inter opérateurs . . .


Le vieux

N3o

  • Abonné Orange Fibre
  • *
  • Messages: 24
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #8 le: 15 novembre 2022 à 18:48:20 »
Bonsoir,

J'essaie de comprendre un peu le durcissement de l'option 90 avec la prise en compte du password.
Quand on passe par le générateur, il y a 2 champs : SALT et Byte.
Je ne comprends pas ce que l'on doit y mettre la dedans, quelqu'un peut m'expliquer ?

Merci par avance

Neo

N3o

  • Abonné Orange Fibre
  • *
  • Messages: 24
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #9 le: 15 novembre 2022 à 19:16:51 »
Bonsoir,

J'essaie de comprendre un peu le durcissement de l'option 90 avec la prise en compte du password.
Quand on passe par le générateur, il y a 2 champs : SALT et Byte.
Je ne comprends pas ce que l'on doit y mettre la dedans, quelqu'un peut m'expliquer ?

Merci par avance

Neo

Je pense avoir compris, le SALT c'est la serie de caractères qui sert à MD5 le password.
J'ai modifié les option 90 (DHCP V4) & Option11 (DHCP V6) et visiblement c'est tout bon  :D



renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 345
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #10 le: 16 novembre 2022 à 13:58:12 »
Merci d'avoir prévenu.

Je suis toujours en chaine courte en v4 mais longue en v6, je verrais bien ce que ça donne. Si j'ai plus de co, je saurais d'où ça vient.

fttmeh

  • Abonné Orange Fibre
  • *
  • Messages: 242
  • Hauts-de-Seine
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #11 le: 17 novembre 2022 à 11:22:36 »
- IPv6 : SARR + RENEW / REBIND + RELEASE
respecter les cycle de vie définis dans les RFC idoines et relancer depuis le DORA / SARR en cas de perte de la connectivité montante (à tester avec ARP et ICMPv6 NS/NA) comme le fait la LiveBox
Pour IPv6 : peut-on continuer à utiliser rapid commit (seulement SR au lieu de SARR) ?