Résumé

  • GAAP-25 exige confidentialité et intégrité pour les Claims chiffrés et interdit ChaCha20 employé seul, mais le marqueur de chiffrement n’atteste ni l’identité ni le droit d’occuper une adresse multicast.
  • Des nœuds avec clé et sans clé peuvent former deux espaces de détection des collisions qui ne se voient pas ; même dans l’espace chiffré, une clé partagée prouve une appartenance technique, pas une autorisation opérationnelle.

Imaginons deux applications raccordées au même réseau. La première accepte uniquement les Claims chiffrés avec une clé commune. La seconde fonctionne dans le mode de base, sans clé. Elles choisissent la même adresse pour deux noms de groupe différents. Chacune écoute correctement selon sa configuration ; aucune n’entend la revendication de l’autre. Le problème n’est pas que le chiffrement aurait échoué. Il a précisément réussi à fermer une frontière.

Le projet GAAP dans sa révision 25 oblige donc à regarder simultanément la protection et l’angle mort qu’elle crée. Le protocole propose une allocation décentralisée et légère d’adresses multicast dans un domaine administratif. Un nom de groupe est haché pour produire une adresse candidate ; trois positions de repli peuvent être calculées en ajoutant 1, 2 ou 3. Le nœud émet un Claim initial, attend environ un intervalle périodique, puis entretient un état souple par des Claims réguliers. Libérer l’adresse revient à cesser de les envoyer.

Le statut doit rester exact. Le Datatracker de l’IETF classe le texte, prévu comme Experimental, en évaluation IESG avec suivi de l’Area Director. Son historique atteste une évolution du document, non un déploiement. Le texte précise d’ailleurs que cette méthode décentralisée fondée sur le hachage n’a pas été déployée et que ses taux de collision comme son passage à l’échelle n’ont pas été mesurés.

Ce que le chiffrement garantit vraiment

Par rapport à la révision 23, la révision 25 rend la règle cryptographique plus nette. Un Claim chiffré doit employer un mécanisme assurant à la fois confidentialité et intégrité, par exemple un chiffrement authentifié avec données associées. ChaCha20 seul est explicitement exclu. RFC 8439 permet de comprendre le choix : le flot chiffrant sans authentification reste malléable. Une modification calculée du texte chiffré peut se traduire par une modification de l’adresse, de l’horodatage ou du nom de groupe après déchiffrement.

La révision exige aussi l’unicité des nonces pour une clé, à travers tous les émetteurs qui la partagent, et impose au récepteur configuré avec une clé de refuser les Claims en clair. Ces mesures empêchent qu’un domaine protégé accepte discrètement une version moins sûre du message.

Elles ne fournissent pas pour autant un langage universel de confiance. Le Marker signale implicitement qu’un enregistrement est chiffré ; il ne publie ni l’algorithme, ni l’identité de l’émetteur, ni la source de son autorisation. Mécanisme, clés, structure de l’enregistrement, données associées, génération des nonces et renouvellement restent largement coordonnés hors bande. En cas d’échec, le récepteur abandonne le Claim. Une clé erronée, un mécanisme inconnu, une altération accidentelle ou une attaque aboutissent donc au même silence.

Il faut lire ce silence correctement. Une authentification réussie établit qu’une personne ou un processus possédant un secret admis a produit un enregistrement demeuré intact dans le périmètre cryptographique. Elle n’établit pas que tous les opérateurs concernés partagent ce secret, ni que l’émetteur avait qualité pour prendre l’adresse, ni qu’aucun groupe invisible n’utilise déjà celle-ci.

Le protocole tranche une collision, pas un droit

GAAP définit une collision de manière volontairement étroite : une même adresse pour des noms de groupe différents. Une même adresse avec le même nom ne constitue pas une collision. Cette mécanique suffit à coordonner des participants qui voient les mêmes Claims. Elle ne tranche aucun contrat, aucune responsabilité de service et aucun droit institutionnel.

La clé partagée ne résout pas ce manque, car un participant malveillant qui possède déjà la clé peut forger un Claim parfaitement authentifié. Les règles d’horodatage et de départage produiront éventuellement un gagnant protocolaire ; elles ne prouvent pas sa bonne foi. La prudence de la liste locale et bornée des mauvais acteurs est révélatrice : l’adresse source peut être usurpée et perdre un départage temporel ne suffit pas à établir une intention hostile.

RFC 1982 précise l’arithmétique nécessaire aux numéros de série, et RFC 8085 les précautions d’emploi d’UDP. Les textes historiques sur les portées et allocations multicast—RFC 2365, RFC 5771, RFC 2730 et RFC 2909—décrivent d’autres éléments de cette architecture. Les analyses contemporaines RFC 10019 et RFC 10028 expliquent l’intérêt d’un mécanisme plus simple. Aucun de ces textes ne fait d’un paquet valide une preuve de souveraineté sur la ressource.

La séparation utile est donc triple : la cryptographie protège le message ; GAAP compare les revendications visibles ; une politique externe décide qui était autorisé à revendiquer.

Le minimalisme doit déclarer ses dépendances

La thèse de Heng Lu sur une spécification initiale minimale et une évolution locale volontaire éclaire bien le caractère expérimental de GAAP. Il est raisonnable de ne pas charger le protocole d’une constitution mondiale. Mais il serait dangereux d’en conclure que les fonctions absentes n’existent pas.

Distribuer une clé, c’est admettre un membre. La retirer, c’est l’exclure. Définir qui peut déchiffrer, c’est définir le cercle à l’intérieur duquel les collisions deviennent visibles. Sans décision explicite, l’administrateur des clés peut ainsi devenir le gouverneur pratique du parc d’adresses.

La primauté du code effectivement exécuté fournit le contrôle de réalité : quels Claims les récepteurs voient-ils vraiment ? Que font les applications après un échec de clé ? Quel opérateur supporte l’interruption lorsque deux populations attribuent la même adresse ? Le mot « chiffré » ne répond à aucune de ces questions.

L’analyse précédente de BTW, consacrée aux plages corrigées de GAAP-23 et à la convergence après partition, traite un autre défaut : le même nom peut rester attaché à deux adresses de repli après le rétablissement du réseau. La révision 25 ne ferme pas ce débat. Elle montre surtout qu’une partition peut aussi être créée logiquement par la distribution des clés, sans rupture physique.

GAAP-25 améliore l’enveloppe. La gouvernance doit encore établir qui est fondé à y placer une revendication.

Sources