Résumé

  • Publiée le 10 septembre 2026, la révision 08 de draft-nir-ipsecme-big-payload entretient le texte : dates, expiration, correction d’un mot et référence Classic McEliece actualisée. Elle ne remanie pas le mécanisme de la révision 07.
  • Le bit L proposé fait passer la longueur de l’en-tête générique de charge de deux à quatre octets, à condition que le pair ait envoyé LARGE_PAYLOAD_SUPPORTED pendant IKE_SA_INIT.
  • Cette notification ne porte aucune limite de taille, de mémoire, de calcul ou de requêtes concurrentes. Le projet autorise explicitement des limites de bon sens propres à l’implémentation.
  • Datatracker affiche encore un Internet-Draft candidat, à l’état « Call For Adoption By WG Issued », sans shepherd ni approbation de l’IESG. Le code IANA demandé ne figure pas dans le registre actuel.

Le mot « supporté » ne donne pas une quantité

Imaginons deux équipements qui établissent une association IKE. Le premier annonce qu’il comprend le nouveau format long. Le second prépare alors une charge de plusieurs centaines de kilo-octets. Quelle quantité le premier s’est-il engagé à conserver en mémoire ? Combien d’opérations coûteuses accepte-t-il en parallèle ? La notification ne répond à aucune de ces questions.

Elle résout une question de syntaxe : le récepteur sait-il interpréter un autre agencement de l’en-tête ? Elle ne contient pas de plafond en octets, pas de classe de charge autorisée, pas de liste d’échanges, pas de réserve de mémoire, pas de durée de traitement et pas de quota de concurrence. Lui attribuer la signification « toute longueur sur 32 bits est recevable » reviendrait à fabriquer une obligation absente du message.

Le besoin d’encodage est néanmoins concret. Dans RFC 7296, l’en-tête du message IKE complet dispose d’un champ Length sur quatre octets. L’en-tête générique de chaque charge n’en utilise que deux, ce qui empêche une charge individuelle d’atteindre 65 536 octets. Le projet réaffecte un bit réservé, nommé L. À zéro, l’en-tête reste inchangé ; à un, la longueur est codée sur quatre octets.

La surface de représentation grandit. Le budget du récepteur, lui, reste local.

Une négociation directionnelle, pas une réservation commune

Le signal LARGE_PAYLOAD_SUPPORTED est une notification de statut sans données, envoyée pendant IKE_SA_INIT. Le projet interdit toutefois les grandes charges dans cet échange initial. Lorsqu’un échange initial de clés exige davantage de place, il recommande l’échange intermédiaire d’IKE défini par RFC 9242.

Le support peut être dissymétrique. Celui qui émet la notification promet de traiter l’en-tête étendu. S’il ne reçoit pas la même annonce, il ne peut pas expédier ce format dans l’autre sens. Cette dissymétrie décrit les parseurs disponibles dans chaque direction ; elle ne crée pas une caisse commune de mémoire entre les deux pairs.

Le contrôle de cohérence est également précis. Le destinataire vérifie que la longueur déclarée tient dans les octets restants du message. Si ce n’est pas le cas, le texte prévoit INVALID_SYNTAX. Si les octets sont présents, la charge suit le traitement ordinaire et ne peut être rejetée uniquement parce qu’un en-tête court aurait suffi. Cela empêche une interprétation arbitraire du fil. Cela n’interdit pas une règle locale qui refuse un objet bien formé parce qu’il dépasse une limite opérationnelle documentée.

La liste DELETE rend la limite visible

L’exemple du projet permet de mesurer la différence. Une charge DELETE peut énumérer des SPI IPsec de quatre octets. Le champ court empêche de réunir toutes les valeurs possibles dans une seule charge. Avec l’en-tête étendu, 65 535 SPI occuperaient 262 150 octets selon le calcul du document.

Ce cas justifie l’espace d’encodage supplémentaire. Il ne transforme pas 262 150 octets en minimum universel de mémoire disponible. Le projet précise qu’une implémentation peut imposer une limite raisonnable au nombre de SPI d’un DELETE. L’idée dépasse ce seul type de charge : comprendre une longueur n’oblige pas à admettre tout objet que cette longueur peut représenter.

Sans frontière explicite, le vrai plafond apparaîtrait de la pire manière : expiration, erreur générale, pression mémoire ou comportement variable selon les versions. Un opérateur ne pourrait pas dire si un refus prouve une absence de support, une protection volontaire ou un défaut. Le bit de capacité deviendrait alors un écran devant la politique de ressources.

Le transport ne négocie pas davantage de mémoire

RFC 7383 fragmente un message IKE chiffré afin qu’il traverse un chemin où un paquet unique serait trop grand. RFC 9329 permet de transporter IKE et IPsec sur TCP lorsque UDP est bloqué ou fonctionne mal. Ces mécanismes changent la façon de transporter les octets ; ils ne déclarent pas la quantité d’état applicatif que le pair doit accepter.

Une charge fragmentée doit toujours être reçue, réassemblée, vérifiée puis traitée. Un flux TCP fiable peut livrer le travail avec régularité et néanmoins dépasser le rythme admissible. L’encodage long, la fragmentation et TCP répondent donc à trois problèmes distincts : représenter, acheminer et admettre.

Une révision d’entretien dans un statut encore ouvert

Le fichier de comparaison officiel entre les révisions 07 et 08 montre une actualisation des dates et de l’expiration, le remplacement de « than » par « that » et une référence Classic McEliece mise à jour. Aucun plafond chiffré n’a été ajouté. Présenter la révision du 10 septembre comme une nouvelle architecture serait exagéré.

Le statut mérite la même prudence. Datatracker associe le document à IPSECME et indique « Call For Adoption By WG Issued ». L’historique consigne le rattachement au groupe et au flux IETF ainsi que l’appel du 22 juillet ; le courriel de l’appel fixait le 15 août pour les commentaires. L’annonce automatique de la révision 08 le qualifie de « work item » d’IPSECME.

Mais la fiche courante conserve le mot « Candidate », n’affiche aucun shepherd, laisse l’état IESG à « I-D Exists » et ne donne ni directeur de zone responsable ni téléconférence. Le nom draft-nir apporte un indice de continuité individuelle, pas une décision formelle. Il faut publier ces éléments côte à côte plutôt que choisir l’un d’eux comme verdict d’adoption.

Le corps du projet vise le Standards Track et dit que RFC 7296 serait mis à jour en cas d’approbation. La métadonnée actuelle affiche pourtant « (None) » pour l’intended status. C’est une différence de métadonnées, non une approbation. Enfin, le registre IANA des types de notification IKEv2 ne comporte pas LARGE_PAYLOAD_SUPPORTED. Le projet demande une valeur ; elle n’est pas encore attribuée. Les sources examinées ne démontrent ni consensus IETF, ni approbation IESG, ni RFC, ni implémentation, ni interopérabilité, ni déploiement, ni incident.

Sources