Résumé

  • RFC 2908 séparait l’allocation des adresses multicast en trois niveaux : client-serveur, coordination dans un domaine et allocation entre domaines. RFC 2909, expérimental, proposait MASC pour que des domaines revendiquent des préfixes temporaires, puis les subdivisent ou les délèguent.
  • RFC 2909 avertissait qu’IPsec pouvait protéger deux pairs sans authentifier l’origine d’un UPDATE relayé : un nœud MASC non fiable, situé ailleurs dans la topologie, pouvait injecter des mises à jour malveillantes. La réponse proposée reposait sur la confiance administrative dans les pairs, pas sur une preuve de déploiement, d’exploitation ou de trafic.

En septembre 2000, l’architecture d’allocation des adresses multicast devait répondre à deux questions souvent confondues : qui remet une adresse de groupe à une application, et qui réserve la plage dans laquelle cette adresse sera choisie ? RFC 2908 a refusé d’en faire une transaction unique. Il a divisé le travail en trois couches. Le client demande une adresse à un serveur ; les serveurs coordonnent leurs allocations dans un domaine ; un mécanisme interdomaines fournit des plages à ces domaines. MADCAP pouvait servir à la première couche, AAP ou une configuration manuelle à la deuxième, et MASC à la troisième.

Cette séparation éloignait l’allocation multicast d’un compteur mondial unique. Un nœud MASC — généralement envisagé sur un routeur de bordure — agissait pour un domaine, souvent assimilé à un système autonome. Il choisissait un préfixe dans une plage plus large, adressait sa revendication aux pairs configurés et attendait de voir si d’autres revendications entraient en collision. La hiérarchie parent-enfant permettait ensuite au domaine de découper le préfixe reçu pour ses serveurs d’allocation ou d’en déléguer des sous-préfixes à ses propres enfants. Le préfixe obtenu pouvait aussi alimenter les informations de routage multicast.

Ce sont des surfaces de contrôle liées, mais distinctes : une allocation MASC ne crée pas à elle seule une route, une appartenance à un groupe ni la livraison de paquets.

Les revendications avaient une échéance. Chaque préfixe était associé à une durée de vie ; le domaine devait la renouveler avant son expiration s’il voulait conserver la plage. À défaut, la spécification lui demandait de cesser d’utiliser le préfixe et de retirer l’état de route correspondant. La ressource déléguée n’était donc pas perpétuelle par défaut. Mais l’état d’allocation, celui du routage et l’usage applicatif pouvaient diverger si l’opérateur n’en observait qu’un seul. Une entrée de contrôle n’est pas une capture de paquets.

L’architecture rendait également son compromis explicite. Lorsque l’espace est rare, une partition stricte peut empêcher toute collision, mais les marges nécessaires en cas de partition ou de bascule morcellent le pool. RFC 2908 privilégiait donc un bon remplissage et la disponibilité plutôt qu’une garantie absolue d’absence de collision. Il visait une probabilité très élevée d’éviter les conflits tout en acceptant qu’elle ne soit pas nulle. Les revendications, le délai d’attente et la sélection d’un autre préfixe en cas de collision traduisaient cette tolérance ; ils ne constituaient pas une certitude mathématique.

RFC 2909 a ensuite isolé une autre frontière : celle de la provenance. Un UPDATE ne s’arrêtait pas nécessairement au pair qui l’avait reçu en premier. Les nœuds MASC le conservaient et le relayaient entre parents, frères, enfants et pairs internes. Le texte précise qu’IPsec peut protéger deux nœuds qui se peerent. Mais si un nœud MASC non fiable rejoint la topologie, il peut injecter des UPDATE malveillants que les autres n’identifieront pas nécessairement comme tels. La recommandation est donc que chaque nœud n’établisse des relations qu’avec des pairs dignes de confiance.

Pour restaurer l’état après un redémarrage, les informations d’un parent ou d’un pair interne sont généralement jugées fiables ; un nœud peut en revanche écarter ses propres UPDATE reçus d’un frère ou d’un enfant.

Ce constat ne signifie pas qu’« IPsec ne sert à rien ». La protection d’une liaison sécurise une adjacence précise. La lacune apparaît lorsque l’information la dépasse : le prochain saut sait quel pair la lui a envoyée, sans nécessairement établir qui l’a créée ni si chaque relais avait le droit de la répéter. Les horodatages et identifiants de nœud de MASC servent à départager des revendications concurrentes ; RFC 2909 ne les présente pas comme une authentification cryptographique de l’origine. Il ne rapporte pas non plus d’exploitation réelle.

Il décrit une menace et laisse le choix opérationnel aux personnes qui configurent le graphe de pairs.

L’enjeu est que le préfixe revendiqué peut influencer plus d’un serveur d’allocation. Acceptée puis propagée, une mise à jour peut contraindre des revendications voisines et alimenter l’état de routage multicast avant même qu’une application ne demande une adresse. La réponse proposée n’est pas une autorité mondiale qui certifierait chaque revendication : c’est une politique de confiance entre pairs, complétée par des règles sensibles au chemin pour accepter les UPDATE relayés. La topologie et son administration concentrent donc un pouvoir réel.

Les statuts des RFC bornent la conclusion historique. RFC 2908 est informatif et décrit une architecture proposée ; RFC 2909 est expérimental, pas une norme Internet. Leur publication prouve que leurs auteurs ont formulé une architecture à plusieurs couches et ses risques. Elle ne révèle ni le nombre de réseaux ayant implémenté MASC, ni sa fréquence d’usage, ni l’existence d’une perturbation de service causée par une mise à jour malveillante. GLOP, dans RFC 3180, et l’enregistrement IANA de RFC 3171 sont d’autres choix d’allocation ; aucun ne démontre un déploiement de MASC.

La leçon est plus précise : une revendication de préfixe, une liaison protégée, une origine digne de confiance, une route et un flux effectivement reçu sont des faits distincts. Un plan de contrôle sûr doit préciser quelles preuves autorisent chaque transition.

Sources