Résumé

  • RFC 2411 attribuait chaque catégorie de règle IPsec à une famille de documents afin d’éviter qu’ESP, AH, la gestion des clés et les textes d’algorithmes ne recopient des prescriptions divergentes.
  • Cette carte informative permettait de trouver la norme compétente ; elle ne démontrait ni la version réellement codée, ni l’algorithme négocié, ni l’installation des SA, ni le résultat observé.

La bonne question, face à une exigence technique, n’est pas toujours « que dit la norme ? ». Elle peut être plus élémentaire : « quel texte a le droit de répondre ? »

RFC 2411 part de ce problème. IPsec n’est déjà plus un document unique. L’architecture décrit le système. ESP et AH définissent des formats et des traitements. Des textes séparés expliquent comment employer tel chiffrement ou tel mécanisme d’authentification. Le DOI porte des valeurs communes. ISAKMP, Oakley et leur résolution s’occupent de la gestion des clés. À mesure que de nouveaux algorithmes apparaissent, chaque auteur pourrait être tenté de résumer l’ensemble avant de présenter sa contribution.

Ce résumé serait pratique la première fois, dangereux la dixième.

Une définition copiée vieillit. Une valeur par défaut diverge. Une mise en garde disparaît. Deux textes réputés compatibles finissent par décrire deux systèmes voisins mais non identiques. Les auteurs de RFC 2411 donnent un nom presque administratif à cette dérive : l’« explosion des brouillons ». Leur réponse est pourtant une décision d’ingénierie. Il faut attribuer les règles, pas seulement numéroter les documents.

La feuille de route dessine sept ensembles. L’architecture garde les notions communes et les exigences de sécurité. ESP possède son format de paquet et son comportement général. AH possède les siens. Les documents de chiffrement expliquent le raccordement d’un algorithme à ESP. Les documents d’authentification définissent une fois les mécanismes utilisables avec ESP et AH. Le DOI fournit les identifiants et paramètres qui permettent aux autres pièces de se désigner. Les documents de gestion des clés décrivent la création et la manipulation du matériau cryptographique.

Cette division n’est pas une hiérarchie politique. Le DOI ne devient pas supérieur à l’algorithme parce qu’il lui attribue un numéro. La feuille de route ne devient pas supérieure à ESP parce qu’elle place ESP dans un schéma. Chaque texte possède une surface limitée, et l’interopérabilité dépend de leur composition.

Le cas des clés rend la logique concrète. Le protocole de gestion doit produire assez de bits, avec une force suffisante, pour les algorithmes retenus. Mais il ne devrait pas mémoriser lui-même les particularités de chaque algorithme. La longueur, l’ordre des sous-clés, les bits de parité, le traitement des clés faibles ou le format du matériau appartiennent au document qui lie l’algorithme à IPsec.

L’architecture explique ensuite comment extraire plusieurs clés d’un bloc lorsque ESP combine confidentialité et authentification. Puis RFC 2411 refuse d’aller plus loin : que le noyau reçoive le bloc complet et effectue le découpage, ou que le processus de gestion des clés le fasse auparavant, reste une question d’implémentation.

Le résultat partagé est spécifié. L’emplacement interne du travail ne l’est pas.

C’est une forme précise de décision locale. Elle ne signifie pas que chacun peut improviser le résultat sur le réseau. Elle signifie que le système commun n’acquiert pas un pouvoir sur une frontière interne sans nécessité d’interopérabilité.

RFC 2411 applique la même retenue aux options. Lorsque plusieurs valeurs n’apportent rien de décisif, le document d’algorithme devrait choisir une valeur fixe et réduire la combinatoire de négociation. Chaque option supplémentaire multiplie les chemins de code et les couples de paramètres que deux produits doivent partager. Une flexibilité nominale peut produire une incompatibilité réelle.

Lorsqu’une option doit rester ouverte, elle ne doit pas devenir un trou. Le texte doit justifier ce choix, fixer des valeurs par défaut ou des plages, et préciser l’effet sur les champs et le traitement. Une option expliquée est une frontière. Une option abandonnée au lecteur est une dette.

La liste recommandée aux futurs auteurs ressemble moins à un plan académique qu’à un dossier d’exploitation : tailles de clés minimales et recommandées, clés faibles, source d’aléa, renouvellement, performances, format des champs, bourrage, interactions entre algorithmes, attaques connues, pièges d’implémentation, procédures de validation et vecteurs de test. La feuille de route ne fournit pas ces preuves. Elle exige que le document le plus proche du mécanisme permette de les construire.

Cette nuance interdit un raccourci fréquent. Citer RFC 2411 ne prouve pas qu’un produit suit la bonne version d’ESP. Trouver un algorithme dans le registre IANA ne prouve pas qu’il est recommandé. Lire « obligatoire à implémenter » ne signifie pas « obligatoire à utiliser ». Voir une proposition acceptée dans IKE ne prouve pas que les deux noyaux ont installé leurs SA. Observer une SA locale ne prouve pas qu’un paquet utile a été accepté de l’autre côté.

La carte peut indiquer le dossier où chercher. Elle ne peut pas fabriquer le reçu absent.

Son propre statut le confirmait. RFC 2411 était informatif et déclarait ne spécifier aucune norme Internet. Sa section de sécurité renvoyait aux documents d’architecture, de protocole et d’algorithme. Même l’avertissement selon lequel beaucoup de chiffrements ne sont pas sûrs sans authentification n’était pas une attestation de déploiement. C’était une instruction de ne pas lire une pièce isolément.

Treize ans plus tard, RFC 6071 a remplacé la première feuille de route. Le corpus avait proliféré dans plusieurs groupes de travail et dans des protocoles qui utilisaient IPsec. Le nouveau texte s’est présenté comme un instantané. Il a daté ses tableaux d’exigences, indiqué que des RFC ultérieurs pouvaient les modifier et posé une règle d’autorité limpide : en cas de conflit, l’autre RFC l’emportait.

Une carte saine explique où elle cesse de faire foi.

RFC 6071 a également conservé une contradiction apparente qui était en réalité un fait de terrain. Le nouvel IPsec avait rendu l’ancien obsolète, mais l’ancien restait fréquent dans les implémentations. IKEv2 avait remplacé IKEv1, sans le faire disparaître instantanément. « Obsolète » décrivait le graphe documentaire. « Déployé » décrivait un parc de machines. Aucun des deux mots ne pouvait répondre à la place de l’autre.

La structure documentaire avait elle-même changé. Les algorithmes combinant chiffrement et intégrité avaient obtenu leur propre famille. Les exigences obligatoires avaient été sorties des documents de format pour pouvoir évoluer. IKEv2 avait regroupé des matières que la première génération distribuait entre ISAKMP, Oakley et le DOI, parfois au prix de contradictions. La modularité avait évité un monolithe ; son accumulation avait créé un coût de découverte.

La leçon n’est donc ni « tout séparer », ni « tout réunir ». Il faut placer une règle là où son rythme de changement, son expertise et sa frontière d’interopérabilité la rendent maintenable. Le format d’ESP n’a pas à changer chaque fois qu’un algorithme vieillit. Les recommandations cryptographiques, elles, doivent pouvoir bouger plus vite que les paquets.

RFC 8221 suit cette logique. Il traite séparément les exigences d’implémentation et les conseils d’usage parce que la cryptanalyse avance, que les matériels diffèrent et que les algorithmes sûrs d’aujourd’hui peuvent devenir insuffisants. Le numéro IANA reste stable pour que les machines parlent sans ambiguïté. La recommandation reste révisable pour que cette stabilité ne se transforme pas en approbation éternelle.

RFC 9395 a ensuite déprécié IKEv1 et des algorithmes anciens. Il n’a pas effacé les archives ni désinstallé les équipements. Un opérateur devait toujours inventorier ses versions, ses transformations activées, ses propositions, ses SA et son trafic.

Voilà la portée historique de RFC 2411. L’IETF n’a pas seulement essayé de publier de bons textes. Il a tenté d’empêcher la documentation de devenir une source autonome de contradictions. Il a limité le commun, placé le spécifique près de son mécanisme et laissé une décision interne locale lorsque le réseau n’avait pas besoin de l’uniformiser.

Mais il n’a jamais pu sauter de la page au paquet.

La feuille de route rangeait les règles. Le code, la négociation, les noyaux et le trafic devaient encore montrer lesquelles étaient devenues réelles.

Sources