Résumé

  • Dans la révision 25 du projet GAAP du groupe PIM, la section 5 devient « Illustrative GAAP API ». Le texte précise que GAAP est un protocole, ni une bibliothèque ni une API Python : une implémentation peut choisir une autre interface, voire aucune, si elle respecte les échanges Claim sur le réseau. La version 24 décrivait déjà l’exemple comme non normatif.
  • La même révision sépare les quatre champs effectifs d’un Claim des paragraphes qui en expliquent l’usage et détaille la malléabilité de ChaCha20 sans code d’authentification. Elle n’annonce ni nouveau format de paquet, ni première interdiction de ce montage, ni incident constaté.

Le glissement est facile à imaginer : une équipe lit une méthode dans un exemple, une autre la reprend dans sa documentation, puis chacun finit par parler d’une « API GAAP » officielle. Or un réseau n’observe pas le nom de la fonction appelée par une application. Il observe les Claims échangés et les décisions prises à partir d’eux. GAAP cherche à attribuer des adresses de groupe multicast sans serveur d’attribution unique. Sa révision datée du 25 septembre 2026 réaffirme que la surface commune est le protocole sur le fil, pas un modèle particulier de programmation.

La nouveauté doit être décrite précisément. La version 24 présentait déjà le pseudo-Python comme illustratif et non normatif. La version 25 ne libère donc pas les développeurs d’une ancienne obligation d’utiliser Python. Elle explicite une distinction jusque-là moins catégorique : GAAP n’est pas une bibliothèque et ses exemples ne prescrivent pas une API. Le texte autorise toute interface de programmation, ou pas d’interface du tout, sous réserve de suivre le protocole Claim. Un composant intégré et un processus séparé seraient deux choix d’architecture possibles ; ce ne sont pas des installations dont cet article aurait vérifié l’existence.

La section 4 traite d’une ambiguïté voisine, mais au niveau du message. Elle énumère quatre champs d’un enregistrement Claim : adresse de groupe multicast IPv4, adresse de groupe multicast IPv6, horodatage et nom du groupe. Les paragraphes suivants abordent leur utilisation, leur comparaison et leur analyse. La révision 25 précise qu’il s’agit d’explications, non de champs supplémentaires. Il serait erroné de déduire de la nouvelle présentation l’apparition d’un cinquième champ, un nouvel ordre des octets ou une migration de format. Le texte rend sa frontière plus lisible ; il ne présente pas une mesure d’interopérabilité.

Un ajout de sécurité complète le tableau. La version 24 disait déjà que ChaCha20 seul, sans code d’authentification de message, ne répond pas à l’exigence d’intégrité et ne doit pas être utilisé ainsi. La version 25 explique le mécanisme : sans intégrité authentifiée, un chiffrement par flot est malléable. Un adversaire situé sur le trajet pourrait modifier des bits du chiffré et faire déchiffrer une autre adresse de groupe, un autre horodatage ou un autre nom sans alerte. Le projet souligne qu’un sentiment de protection trompeur pourrait s’avérer plus dangereux qu’un mode de base ouvertement non chiffré.

C’est une analyse de risque du document, pas le récit d’une attaque ni la preuve d’un déploiement fautif.

Ces deux sujets rejoignent une même question de gouvernance technique : que faut-il rendre identique entre systèmes indépendants ? L’interface locale peut varier, tandis que la signification des Claims et la propriété d’intégrité, si le chiffrement est retenu, doivent rester vérifiables entre pairs. Un contrôle qui ne voit qu’une méthode Python nommée comme dans l’exemple manquerait l’échange réel. Un contrôle qui ne constate que du chiffré manquerait la possibilité de modification non détectée. Cette lecture n’est pas une certification proposée par l’IETF.

Selon le Datatracker, la révision 25 demeure un Internet-Draft du groupe PIM au stade IESG Evaluation, avec AD Followup et une visée Experimental. Elle n’est pas un RFC. Un précédent article de BTW sur GAAP-23 portait sur les plages d’adresses fixes et sur la convergence de revendications de même nom après une partition réseau. La présente version ne tranche pas ce problème. Son fait distinct est la clarification des limites entre protocole, exemple et garantie d’intégrité.

Sources