Résumé

  • Un équipement PPP qui propose l’option Magic-Number ne peut pas refuser cette même option à son pair. Cette réciprocité rend un refus reçu instructif dans le modèle de fonctionnement conforme.
  • Deux nombres égaux pendant la négociation peuvent signaler une liaison rebouclée ou une collision fortuite. Les échanges suivants cherchent une divergence, sous réserve de choix réellement indépendants.
  • Le nombre appartient à un état local de liaison. Il ne fournit ni identité authentifiée, ni preuve de service applicatif, ni règle universelle de rétablissement.

Le « non » que la machine n’aurait pas envoyé

Voici une situation moins banale qu’une négociation réussie. Un équipement demande à utiliser Magic-Number. Il reçoit un Configure-Reject. L’option ne sera pas utilisée par son interlocuteur; pourtant, le refus apporte quelque chose.

La raison se trouve dans une obligation imposée à celui qui a pris l’initiative. Une implémentation proposant Magic-Number doit aussi permettre à son pair de proposer cette option. Elle ne peut pas exiger pour elle-même la faculté qu’elle refuse à l’autre. Si ses propres messages lui reviennent par une liaison en boucle, son comportement conforme ne devrait donc pas produire ce refus-là.

Le RFC 1661, publié en juillet 1994, exploite cette asymétrie. Le rejet reçu indique, dans le modèle défini, que l’équipement ne dialogue pas simplement avec son propre reflet. La négociation peut poursuivre son cours comme si l’offre avait été acquittée, tout en tenant compte du fait que le pair n’utilisera pas de Magic-Number.

Il faut conserver les deux moitiés de cette phrase. Un autre entité a manifesté un comportement distinct; il n’a pas accepté la même capacité. Et rien, dans ce raisonnement, ne prouve son identité administrative. Le protocole reconnaît une différence de conduite, pas une personne.

Pourquoi le retour d’un paquet ne suffisait pas

PPP devait relier deux extrémités, notamment sur des circuits série. Cette simplicité apparente pouvait masquer une anomalie élémentaire: les données émises revenaient au même équipement sans qu’un pair indépendant les ait traitées.

Une liaison rebouclée n’a pas besoin d’abîmer les bits. Le contrôle de trame et la détection de réflexion répondent donc à deux questions différentes. Dans le RFC 1662, également daté de juillet 1994, le FCS de l’encapsulation de type HDLC vérifie les champs qu’il couvre; il occupe par défaut deux octets, avec une variante sur quatre octets. Une trame revenue intacte peut satisfaire ce contrôle.

C’est précisément le problème: une copie parfaite peut constituer une mauvaise preuve de communication. Pour distinguer le retour local d’une réaction distante, il faut observer quelque chose que l’autre extrémité choisit elle-même.

Magic-Number apporte ce petit élément d’indépendance. Il ne corrige pas les erreurs de bits et n’empêche pas physiquement une boucle. Il fournit aux machines un moyen de reconnaître certaines situations à partir de leur propre historique.

Une place réservée, puis une conduite définie

Le nombre n’apparaît pas soudainement en 1994. Le RFC 1134, de novembre 1989, présentait déjà PPP comme l’association d’une encapsulation, d’un protocole de contrôle de liaison, LCP, et de protocoles NCP chargés de configurer les protocoles réseau.

Cette séparation permettait de traiter les conditions de la liaison avant d’y faire circuler les échanges réseau correspondants. Le format des messages Echo et Discard comportait déjà quatre octets de Magic-Number. En l’absence d’une option donnant un autre sens à ce champ, ils devaient être envoyés à zéro et ignorés à la réception; leur usage plus avancé restait hors du propos à cet endroit.

Le RFC 1172, publié en juillet 1990 par D. Perkins et R. Hobby, précisait les options initiales. Il exposait déjà la comparaison des nombres, les collisions, la qualité des sources de hasard et l’obligation de réciprocité. Le RFC 1331, de mai 1992, reprenait le mécanisme.

Cette continuité importe davantage qu’un récit artificiel de rupture. Une capacité d’extension était devenue une procédure partagée. Le texte de 1994 rendait explicite la façon de l’utiliser; sa publication ne pouvait cependant pas créer de bonnes sources d’aléa dans des équipements déjà installés.

Deux extrémités, deux choix — normalement

Avant d’envoyer une proposition, l’implémentation choisit son nombre. L’objectif n’est pas l’unicité mondiale. Il est d’obtenir une très forte probabilité de distinction entre les deux extrémités concernées.

Lorsqu’un Configure-Request contenant l’option arrive, son nombre est comparé à celui du dernier Configure-Request envoyé localement. Des valeurs différentes écartent la simple réflexion dans le modèle prévu. Des valeurs égales ne permettent pas encore de conclure: un pair véritable peut avoir fait le même choix.

La réponse à cette égalité est un Configure-Nak proposant un autre nombre. Un nouveau Configure-Request ne doit pas être ajouté immédiatement, en dehors du déroulement normal; la réception d’un Nak ou l’expiration du temporisateur de reprise fournit le déclenchement approprié.

La comparaison suivante change de référence. Le nombre d’un Nak reçu est rapproché de celui du dernier Nak émis localement. S’ils sont encore égaux, l’hypothèse de boucle se renforce et il faut choisir une nouvelle valeur. S’ils diffèrent, une décision distincte apparaît. Un nouveau Configure-Request peut alors porter le nouveau nombre.

Sur une vraie boucle, les requêtes et les propositions de remplacement peuvent revenir successivement à leur auteur. Entre deux implémentations indépendantes, les choix devraient diverger. Le protocole ne se contente donc pas d’un test d’égalité: il organise une tentative de sortir de l’égalité.

Le hasard annoncé n’est pas une mesure de terrain

Les textes historiques donnent une estimation de collision pour des choix uniformes sur 32 bits: environ 2,3 × 10^-10 pour une égalité. Cette estimation explique l’idée, mais ne mesure pas la fiabilité d’un parc.

Deux machines démarrant avec la même graine et suivant le même calcul ne correspondent pas à deux tirages indépendants. Recevoir plusieurs fois la même requête n’ajoute pas non plus autant d’expériences indépendantes. Même l’espace exact des valeurs doit être décrit avec soin: zéro est interdit dans une proposition de l’option, alors que la formule publiée est présentée comme un modèle uniforme sur 32 bits.

Le conseil des RFC est révélateur. Faute de bonne source d’unicité ou d’aléa, mieux vaut ne pas proposer l’option. L’implémentation peut acquitter ou refuser l’offre du pair, mais ne doit pas prétendre obtenir une détection locale fiable avec un mécanisme de choix inadéquat.

Cette prudence ne rend pas le protocole inutile. Elle précise la responsabilité de l’implémenteur: la grammaire commune ne remplace pas la qualité de l’état produit localement.

Un acquittement doit justement répéter le nombre

L’égalité peut aussi être le résultat attendu. Un Configure-Ack valide reproduit exactement les options du Configure-Request, sans les modifier ni les réordonner, et conserve l’Identifier correspondant.

Le nombre local revenu dans cet acquittement est donc normal. Le même nombre dans une nouvelle proposition du pair déclenche une autre analyse. Un outil qui compte toutes les occurrences égales sans regarder le code du paquet détruit la distinction que le protocole avait construite.

Il existe une seconde séparation utile dans les messages de diagnostic. Après négociation, un Echo-Reply utilise le Magic-Number de son propre émetteur. Son Identifier est repris de la requête pour corréler les deux messages; le Magic-Number n’est pas pour autant une simple copie de celui du demandeur.

Echo-Request et Echo-Reply ne sont envoyés que dans l’état LCP Opened. Le mécanisme n’est pas un sondage libre utilisable avant toute négociation. Quant au Discard-Request, il sert de réceptacle de données et n’appelle pas de réponse.

Zéro n’est pas toujours une erreur

Dans le champ de diagnostic, l’absence de négociation réussie impose l’envoi de zéro. Le pair qui n’a pas négocié son propre nombre dispose ainsi d’un comportement défini. En revanche, proposer zéro comme valeur de l’option Magic-Number est illégal: il faut répondre par un Nak, à moins de rejeter l’option.

Une fois l’état pertinent établi, recevoir son propre nombre signale une réflexion dans le modèle du protocole. Recevoir le nombre attendu du pair, ou son zéro valide, correspond à la situation ordinaire. Une autre valeur suggère une communication avec un pair différent.

Cela ne donne pas une preuve universelle de topologie. Un adversaire peut produire une valeur visible. Les nombres ne sont pas secrets, et leur comparaison ne constitue pas une authentification.

Le RFC 1994, consacré à CHAP en août 1996, illustre cette autre fonction: une réponse calculée dépend d’un défi et d’un secret partagé. Le contraste est historique, pas une recommandation d’employer aujourd’hui un ancien algorithme. Vérifier une trame, reconnaître un état indépendant et authentifier un interlocuteur sont trois tâches distinctes.

Le registre ne connaît pas votre numéro

Le registre PPP d’IANA répertorie Magic-Number comme option LCP de type 5. L’option Authentication-Protocol, de type 3, reste séparée. Le registre donne aux implémentations une langue commune pour identifier une option; il ne distribue pas les valeurs choisies à chaque extrémité.

Le format de Magic-Number reste modeste: six octets pour l’option complète, dont quatre pour le nombre. Ce petit coût suffit à soutenir une déduction locale, à condition de ne pas lui demander de certifier davantage.

La suite demeure une décision d’exploitation. Le RFC 1661 ne prescrit pas une seule procédure de récupération. Il évoque notamment une reprise après événement Down, ou une observation par Echo permettant de constater la fin de la réflexion, dans les états appropriés.

C’est là que l’histoire rejoint son point de départ. Même un refus peut être une information utile, mais aucune information ne devient automatiquement une autorité générale. PPP définit comment reconnaître certaines différences; les entités restent responsables de ce qu’ils en font.