Résumé

  • La découverte d’un nœud, l’authentification du pair et la livraison intègre sont trois preuves utiles ; aucune n’établit à elle seule que le pair peut émettre cette commande pour cet appareil.
  • Le découpage du RFC 5164 conserve les sens métier dans les services Information, Event et Command, tandis que la couche commune ne voit qu’une charge opaque.

Un terminal arrive dans un réseau visité. Il lui faut trouver le service capable de l’aider à préparer une transition. Le résultat de découverte indique une adresse. Une association de sécurité reconnaît un pair. Le canal protège le message contre l’altération et la relecture.

Cette suite paraît constituer une autorisation. Elle n’en est pas une.

Le RFC 5164 est un énoncé de problème informatif publié en 2008. Il ne normalise pas un protocole MSTP déployé. Il part des travaux IEEE 802.21 sur le transfert indépendant du média et sépare deux objets : les éléments d’information propres au service et le mécanisme qui les découvre, les transporte et les sécurise. Plusieurs services spécialisés peuvent ainsi emprunter une même couche de transport au-dessus d’IP.

Dans le schéma proposé, l’en-tête de transport précède une charge utile opaque. Le transport ne l’inspecte pas. Les organismes responsables des services conservent la définition de son contenu et de sa signification. Ce partage évite que l’infrastructure commune absorbe tous les vocabulaires futurs. Il impose aussi une limite : la couche qui ne lit pas l’ordre ne peut pas en vérifier la portée opérationnelle.

La découverte produit une hypothèse périssable

Le document décrit trois familles de découverte. L’adresse d’un nœud peut être préconfigurée dans le terminal. Elle peut être poussée pendant une autre opération, par exemple via DHCP ou Router Discovery. Le terminal peut enfin interroger dynamiquement le réseau, éventuellement avec de la multidiffusion ou de l’anycast.

Chaque méthode optimise un coût différent. La préconfiguration évite une requête mais suppose que le nœud reste indépendant du réseau d’accès. Le poussage économise un échange propre au service mais étend un autre protocole de configuration. La recherche dynamique s’adapte au lieu présent, au prix d’un support supplémentaire et d’une surface d’usurpation.

Le RFC ne suppose pas que les nœuds de mobilité se trouvent dans un domaine précis. La découverte doit donc pouvoir franchir des frontières administratives. Sa vitesse, sa protection contre l’usurpation, son moment d’exécution et la durée de validité de la réponse deviennent des données de sécurité. Une adresse obtenue hier n’est pas une autorité actuelle. Un service annoncé dans le réseau visité n’est pas nécessairement autorisé pour tous les abonnés ni pour les trois classes de messages.

Le pair reconnu n’acquiert pas tous les pouvoirs

Le texte demande que l’information provienne d’une source digne de confiance et propose de réutiliser des relations AAA ou l’infrastructure de certificats de SEND. Il demande aussi une méthode commune de négociation d’association de sécurité, indépendante de l’utilisateur particulier de MSTP et capable de survivre à la mobilité du terminal.

Puis il ajoute une exigence distincte : les entités de service côté réseau doivent généralement prouver leur autorité à servir les appareils visiteurs. La nuance est décisive. L’authentification dit quel pair tient la clé. L’autorisation dit quels événements ou commandes ce pair peut produire, pour quelle cible, dans quel réseau, pendant quelle fenêtre et sous quelles conditions.

La confidentialité protège le contenu contre les intermédiaires. L’intégrité protège les octets. La défense contre la relecture protège une chronologie définie. Aucune de ces fonctions ne sait qu’un champ opaque demande un changement radio susceptible d’interrompre la connexion. Cette décision revient au service capable d’interpréter le message.

Trois services refusent une moyenne unique

Information Services, Event Services et Command Services n’ont ni la même fréquence ni la même taille. Les événements et commandes étaient envisagés à des intervalles de quelques centaines de millisecondes. Une information sur un nouveau réseau pouvait n’être échangée qu’après plusieurs heures ou jours. Les messages urgents typiques comptaient environ 50 à 100 octets ; certaines réponses d’information pouvaient dépasser 64 Ko.

Une connexion fiable créée à la demande ajoute un délai d’établissement. Une connexion durable exige un état entretenu et une relation prévisible. Un mode sans connexion réduit cette préparation mais déplace la question de la fiabilité. Le RFC présente donc deux emplacements possibles : accusé de réception dans le service si le transport n’est pas garanti, ou confiance dans un transport fiable sans mécanisme MIH redondant.

Dans les deux cas, « livré » ne signifie pas « autorisé », et « acquitté » ne signifie pas « exécuté ». La métrique doit conserver le reçu du transport, le reçu du service et le résultat du basculement.

Le lien peut changer sans changer de transaction

Le scénario multihébergé rend l’erreur de raisonnement visible. Une requête peut partir sur le lien courant et la réponse revenir sur le nouveau lien. Le transport doit accepter plusieurs liens ; l’utilisateur de MSTP doit réunir les éléments appartenant à la même session ou transaction.

L’adresse source, l’interface et même le chemin ne constituent donc pas l’identité logique de la transaction. Il faut conserver un identifiant, le contexte de confiance, les deux liens, les délais et la décision du service. Sinon, une réponse correcte sur un nouveau chemin ressemble à un intrus, ou une réponse étrangère sur un chemin familier ressemble à une continuation valide.

La confidentialité n’est pas seulement celle du contenu

Les échanges peuvent révéler le déplacement entre cellules ou permettre de prévoir un mouvement. Le RFC demande confidentialité et intégrité, protection de l’identité lorsque cela est possible pendant la création des associations, et minimisation : l’utilisateur ne devrait pas livrer plus d’identité pour obtenir le service qu’il n’en a déjà fourni pour s’authentifier.

La couche commune crée une tentation inverse. Un identifiant stable simplifie le diagnostic entre réseaux, mais devient aussi une clé de corrélation universelle. Le bon reçu porte l’habilitation nécessaire, pas une identité personnelle supplémentaire.

Enfin, les nœuds réseau peuvent subir un déni de service, surtout si les protocoles imposent un calcul lourd. Le RFC laisse ouverte la place de la défense : découverte, établissement du transport ou échange spécifique. Une architecture solide filtre tôt ce qui peut l’être sans lire la charge, puis applique l’autorisation là où son sens est connu.

Un problème défini n’est pas une solution adoptée

Le document ne choisit ni adaptation d’un protocole existant ni création d’un protocole nouveau. Il demande des objectifs de performance réalistes, tirés d’expériences et de déploiements plausibles, afin que les services définis ailleurs ne réclament pas l’impossible.

La publication prouve donc qu’un problème commun a été décrit. Elle ne prouve ni choix technique, ni mise en œuvre, ni autorité de production. La réalité commence avec le code, la configuration, l’adoption locale et les reçus séparés de chaque frontière.

Sources