Résumé

  • RFC 3554 permet de protéger par IPsec une association SCTP multirésidente, mais impose de valider toutes les adresses proposées. Une identité Phase 1 valable ne vaut pas mandat général sur la liste.
  • La preuve exploitable relie la liste négociée à sa correction éventuelle, à son installation dans la SPD et la SAD, puis au chemin réellement utilisé. Aucun de ces étages ne peut témoigner seul pour les suivants.

Le mot « association » donne une impression d’unité. Le réseau, lui, voit une collection d’adresses sources et destinations qui ne forment pas nécessairement un préfixe commode. Ce décalage est le cœur opérationnel de RFC 3554, publié en juillet 2003 comme proposition de norme.

L’approche explicite consiste à créer une politique pour chaque couple d’adresses. Elle devient vite coûteuse. Le texte propose donc de traiter des ensembles d’adresses comme sélecteurs d’une même entrée de politique. Cette compression réduit le nombre d’objets, mais transforme la liste en frontière d’autorisation.

La liste n’hérite pas automatiquement de l’identité

IKE Phase 1 peut établir l’identité du pair et la validité de ses justificatifs. RFC 3554 précise que cela ne suffit pas. Le répondant doit disposer d’éléments prouvant que l’initiateur est autorisé à recevoir le trafic sur toutes les adresses qu’il déclare.

Les éléments peuvent venir des identités et certificats Phase 1 ou d’une politique hors bande. Un certificat peut comporter plusieurs noms alternatifs ; plusieurs certificats peuvent partager la même clé. Ce sont des moyens de construire la preuve, non des raccourcis pour supprimer l’examen de chaque membre.

Sinon, un pair parfaitement légitime pourrait annoncer l’adresse d’un autre pair. Le chiffrement fonctionnerait et l’association de sécurité serait valide, mais la décision de destination aurait déjà été contaminée. L’incident ne serait pas « IPsec a échoué » ; IPsec aurait protégé un trajet qui n’aurait jamais dû être admis.

Il faut donc conserver deux verdicts : « identité acceptée » et « ensemble d’adresses autorisé ». Le second contient la liste exacte, sa version, la source de l’autorité, sa durée et le décideur.

Le répondant peut devoir corriger la proposition

Au premier Quick Mode, l’initiateur ne connaît pas forcément toutes les adresses du répondant. RFC 3554 assume cette asymétrie. Si les sélecteurs sont incomplets ou inexacts, le répondant inverse les rôles, démarre un nouvel échange et corrige son propre ensemble.

Cette inversion n’est pas une répétition identique. Elle transforme une proposition fondée sur une connaissance partielle en proposition émise par la partie qui connaît mieux ses adresses. Les implémentations IKE compatibles SCTP doivent savoir effectuer ce passage.

Un journal qui ne retient que le dernier succès perd précisément l’information intéressante : la première liste, la raison du désaccord, le delta et l’autorité de la correction. Le succès final ne dit pas si chaque membre a été vérifié ; il dit seulement qu’un échange a abouti.

Le type ID_LIST sert à transporter plusieurs identifiants comme un ensemble. Les listes imbriquées sont interdites. Cette forme bornée facilite le traitement, mais la conformité syntaxique ne prouve ni propriété, ni exhaustivité, ni installation.

L’accord doit rester un dans la SPD et la SAD

La suggestion d’une seule entrée SPD portant un ensemble d’adresses exige une projection cohérente. Côté SAD, toute adresse destination négociée, associée au même SPI et au même protocole de sécurité, doit retrouver la même SA.

Trois divergences sont possibles sans casser l’échange IKE : une adresse acceptée mais absente de la SPD, une adresse pour laquelle la SAD ne retrouve pas la SA, ou un chemin SCTP sélectionné alors que la politique active n’est plus celle de la négociation. Tester seulement l’adresse principale laisse les chemins de secours sans témoin.

La recette de preuve est concrète. Conserver le hachage et la version de l’ensemble final ; obtenir un reçu d’installation SPD ; répéter la recherche SAD pour chaque destination ; provoquer un basculement contrôlé ; vérifier que les adresses hors ensemble sont rejetées. Le modèle logique n’est complet que lorsqu’il survit aux chemins concrets.

Une mise à jour authentifiée rouvre l’autorisation

Le SCTP de base utilisé en 2003 ne modifiait pas son ensemble d’adresses en cours d’association. RFC 3554 anticipait cependant cette évolution et décrivait le risque de redirection : faire ajouter une adresse contrôlée par l’attaquant pour y attirer le trafic suivant.

RFC 5061 a ensuite défini la reconfiguration dynamique avec des blocs de contrôle authentifiés. Ce document voisin ne prouve aucune mise en œuvre et ne rend pas l’autorisation implicite. Un message d’ajout authentique prouve qui a demandé le changement ; il ne prouve pas que l’adresse demandée appartient à ce demandeur.

Chaque changement doit donc produire une nouvelle version autorisée, mettre à jour la négociation et les bases IPsec, retirer l’ancienne politique puis observer les chemins. Tant que l’ancien état peut encore sélectionner ou accepter des paquets, « ajout accepté » ne signifie pas « transition terminée ».

Une chaîne de preuves vérifiable

Le dossier commence par le pair Phase 1 : identité, chaîne, clé, politique et instant de validation. Il ajoute ensuite une ligne par adresse, avec la preuve d’autorité, le verdict et sa durée.

L’association SCTP porte ses deux ensembles et une version. L’échange Phase 2 conserve la proposition initiale, tous les membres de ID_LIST, les sélecteurs, le SPI demandé et l’auteur. Une inversion de rôles devient une transaction liée, jamais un remplacement silencieux.

Les reçus SPD et SAD prouvent l’installation. La télémétrie de données prouve le chemin choisi, la SA utilisée et le destinataire qui a authentifié le paquet. Les tests négatifs prouvent que les adresses non autorisées restent dehors.

RFC 2960, puis RFC 4960, bornent le contexte SCTP. RFC 2401, RFC 2409 et RFC 2407 bornent l’architecture IPsec/IKE de l’époque ; RFC 4301 est le contexte ultérieur. Aucun ne témoigne d’un déploiement nommé. Ils permettent une conclusion plus étroite : une identité valide n’autorise pas une adresse par transitivité.

Limite des preuves

Cet Article ne nomme aucun opérateur, produit, certificat, adresse, association, attaque ou victime. Il n’affirme aucun taux de déploiement, aucune exploitation observée et aucune mesure de coût. Les scénarios découlent des mécanismes du protocole.

Les essais de Heng Lu sur la primauté du code exécuté et la spécification initiale minimale sont des angles éditoriaux déclarés. Ils invitent à distinguer le texte, son installation et son résultat, tout en laissant les politiques locales produire leurs propres reçus. Ils ne prouvent ni l’intention des auteurs de RFC 3554 ni un fait de réseau.

La frontière finale est simple : IKE peut authentifier un pair. Seule une décision traçable pour chaque adresse, projetée de façon cohérente et vérifiée sur le chemin, peut autoriser l’ensemble.

Sources