Résumé

  • Le masque de la RFC 3594 vise la copie persistante de deux classes de billets : serveur de provisionnement et groupe de serveurs de gestion d’appel. Il ne révoque pas à lui seul l’état détenu ailleurs et ne prouve aucune réauthentification.
  • Effacer simultanément cette économie locale réintroduit simultanément le travail évité. Sans lots, gigue et seuils d’arrêt, une action de sécurité peut fabriquer une vague de charge contre le KDC et les serveurs applicatifs.

À la fin d’une intervention, deux équipes peuvent annoncer des résultats contradictoires et avoir toutes les deux raison. L’équipe de provisionnement a vu le masque partir et les billets locaux disparaître. L’équipe sécurité voit seulement commencer les demandes de remplacement. Entre ces deux observations se trouve tout le risque opérationnel.

Publiée en septembre 2003 sur la voie Standards Track, la RFC 3594 ajoute la sous-option 9 à l’option DHCP de configuration des clients CableLabs. Son objet tient dans un masque de seize bits. Sa portée, elle, doit rester rigoureusement bornée.

Deux bits, deux périmètres

Le bit 0 désigne le billet du serveur de provisionnement utilisé par l’équipement. Le bit 1 désigne l’ensemble des billets des serveurs de gestion d’appel employés par celui-ci. Les bits 2 à 15 sont réservés et doivent être envoyés à zéro. Une valeur un ordonne l’invalidation immédiate du billet persistant correspondant ; zéro renvoie aux règles normales d’invalidation.

Cette différence interdit de résumer l’opération par « remise à zéro des identifiants ». Le premier bit touche un objet singulier. Le second peut toucher un ensemble dont la taille dépend de la configuration et des points d’extrémité. Un journal digne de ce nom conserve les deux octets exacts, la classe visée et l’état antérieur.

Un équipement qui ne conserve pas de billets doit ignorer la sous-option. Il doit également ignorer les bits qu’il ne connaît pas. La réception du paquet n’est donc jamais une preuve suffisante du changement. Il faut savoir quelle version du parseur s’est exprimée, quel choix il a fait, puis vérifier le stockage non volatil.

Le mot « persistant » est essentiel. PacketCable permettait de réutiliser après redémarrage des billets encore valides, évitant notamment des opérations de clé publique sur le chemin PKINIT. La spécification CableLabs ultérieure impose à un MTA de conserver le billet du serveur de provisionnement et assez de billets CMS. Effacer ces objets supprime une optimisation de reprise ; cela ne supprime pas automatiquement tous les états de sécurité vivants.

L’effacement n’est pas une révocation universelle

La sous-option ne transporte aucun accusé du KDC, aucun identifiant d’association IPsec, aucun résultat AP-REQ/AP-REP et aucun résultat d’appel. Elle s’adresse à une représentation détenue par le client. Rien dans la RFC 3594 n’autorise à conclure qu’un serveur a détruit sa clé, qu’un billet en mémoire a disparu ou qu’une association déjà installée a été démontée.

La spécification CableLabs gelée rend la séparation encore plus nette : l’obtention d’un nouveau billet peut s’achever sans modifier les paramètres de sécurité existants. Les billets servent ensuite à établir ou renouveler d’autres états. Chaque étape a son propriétaire et son horloge.

Un tableau de bord devrait donc afficher au moins quatre états : billet persistant invalidé, billet de remplacement obtenu, association reconstruite, service vérifié. Une seule couleur ne peut pas porter ces quatre affirmations. Si la deuxième étape échoue, la première reste vraie ; elle ne doit pas être réécrite. Si l’association réussit mais que le serveur applicatif a perdu son contexte, la troisième ne prouve pas la quatrième.

Cette discipline change aussi le retour arrière. On ne « réactive » pas un billet effacé en restaurant un drapeau d’interface. Il faut acquérir de nouveau, établir de nouveau et tester de nouveau. Le plan doit traiter l’effacement comme potentiellement irréversible à l’échelle de l’objet local.

La maintenance crée son propre trafic

La RFC 3594 décrit un scénario de déni de service : beaucoup de MTA sont réinitialisés ou remis sous tension, un serveur DHCP malveillant leur fait invalider tous leurs billets, puis ils tentent ensemble de s’authentifier et d’en obtenir de nouveaux. La file d’attente est produite par des demandes peut-être légitimes, mais synchronisées.

La malveillance n’est pas indispensable au mécanisme. Une fenêtre honnête qui traite tout le parc au même instant peut recréer la même corrélation. Plus l’économie offerte par la persistance était grande, plus le travail libéré par son retrait peut être important.

La spécification CableLabs fournit un écho remarquable. Lors d’un changement routinier de clé de service, les anciennes clés encore valides sont conservées pendant la durée des billets afin d’éviter qu’un grand nombre de MTA n’inonde soudain le KDC de requêtes PKINIT. La compatibilité temporaire est ici une stratégie de maîtrise de la demande.

Une autorisation de changement doit donc préciser les lots, la gigue, le débit maximal d’arrivées, les budgets CPU cryptographiques, la profondeur de file acceptable, les règles de temporisation et le pourcentage de récupération exigé avant de poursuivre. Le nombre de sous-options envoyées n’est pas une mesure de réussite.

La frontière de confiance reste observable

La RFC juge le scénario malveillant peu probable dans l’architecture décrite : un CMTS correctement configuré relaie vers des adresses DHCP autorisées et n’accepte en aval que les sources prévues. Elle reconnaît toutefois que ce filtrage n’empêche pas un serveur usurpé situé derrière le CMTS ; la partie interne du réseau est supposée étroitement contrôlée.

Ce texte énonce une hypothèse et un contrôle, pas une mesure contemporaine du risque. Il faut conserver l’identité du serveur DHCP, le relais, le chemin CMTS, la version de la politique de filtrage et la correspondance de transaction côté équipement. L’authentification DHCP de la RFC 3118 constitue encore un autre mécanisme ; sa normalisation ne prouve pas son emploi.

L’enregistrement IANA de la sous-option 9 prouve qu’un code a été coordonné. Il ne prouve ni support, ni émission, ni interprétation, ni effacement. Une architecture crédible transforme chacune de ces transitions en reçu distinct.

Frontière des preuves

Cet Article ne nomme aucun opérateur, modèle de MTA, CMTS, produit DHCP, KDC, CMS, incident, abonné ou appel. Il ne mesure aucun déploiement. Le statut Standards Track et le registre IANA ne valent pas preuve d’exécution.

La RFC 3495 définit l’option CableLabs plus large ; la RFC 2131 apporte le cadre DHCP ; la RFC 3118 décrit l’authentification séparée. La RFC 1510 est le Kerberos cité à l’époque et la RFC 4120 sa lignée ultérieure. La RFC 3634 traite une autre sous-option. Les RFC 2434 et 8126 encadrent l’allocation des registres. La spécification CableLabs de 2005 est un contexte primaire ultérieur, non le texte normatif de la RFC 3594.

Les essais de Heng Lu sur la primauté du code en fonctionnement et la spécification initiale minimale sont des grilles éditoriales déclarées. Ils invitent à vérifier le dispositif réel sans élargir la règle commune au-delà de ce qu’elle coordonne. Ils ne prouvent ni intention d’auteur ni déploiement.

La conclusion reste volontairement petite : un billet local a été invalidé. Tout ce qui suit — remplacement, association, capacité, service — réclame sa propre preuve.

Sources