Résumé

  • Dans l'expérience SEAL de RFC 5320, l'entrée laisse fragmenter un paquet IPv4 externe, demande éventuellement un rapport à la sortie, rattache ce rapport à une fenêtre de SEAL_ID, puis modifie le S_MSS de la génération suivante.
  • Le reçu fiable sépare l'intention de sonder, le mode d'identité 32 ou 16 bits, l'observation du premier fragment, le réglage, les deux réassemblages, la remise au protocole supérieur et le statut Experimental du document.

Le réglage commence là où la certitude s'arrête

Un paquet encapsulé traverse une topologie virtuelle dont les liens physiques peuvent imposer des MTU différentes. RFC 5320 propose que l'enveloppe IPv4 conserve DF=0. Si un routeur la fragmente, la sortie du tunnel peut renvoyer un message à l'entrée. L'entrée réduit alors la taille des futurs segments jusqu'à ce que cette manifestation disparaisse.

La boucle est ingénieuse parce qu'elle exploite un événement que beaucoup de systèmes ne voient que comme une panne. Mais elle ne change pas la nature de l'événement. Le premier fragment observé indique qu'un paquet a rencontré une limite plus étroite. Il ne nomme pas le routeur, ne démontre pas une MTU permanente et ne dit rien, à lui seul, des fragments manquants.

Une console qui affiche « chemin validé » après l'acceptation d'un rapport élargit donc illégitimement l'autorité de la mesure. Le rapport autorise une correction bornée. Il ne clôt pas l'enquête sur la livraison.

Une identité de 32 bits peut devenir 16 bits

En fonctionnement ordinaire, SEAL_ID assemble l'extension de 16 bits du champ ID de SEAL et les 16 bits de l'Identification IPv4 externe. L'entrée initialise cette valeur au hasard pour l'état souple de chaque sortie et l'incrémente modulo 2^32. Cette continuité aide à distinguer les duplications, les segments et les retours récents.

Le passage par un NAT IPv4 change le contrat. Puisque le traducteur peut réécrire l'Identification externe, SEAL ne peut plus prétendre conserver les 32 bits de bout en bout. Dans ce mode, seule l'extension de 16 bits est l'identité suivie; le champ IPv4 reçoit une valeur aléatoire et le compteur avance modulo 2^16.

Le reçu doit enregistrer le mode. Reconstituer 32 bits après une réécriture NAT fabriquerait une identité qu'aucun terminal n'a maintenue. Mais une correspondance correcte ne prouve toujours qu'une association avec l'état récent, pas l'authenticité cryptographique d'un chemin ni le sort de la charge utile.

S_MRU n'est pas S_MSS

L'entrée conserve deux paramètres par sortie. S_MRU, initialisé à au plus 2 KB, borne ce que la sortie devra réassembler. S_MSS borne chaque segment SEAL et part de la MTU de l'interface IPv4 sous-jacente, moins les en-têtes, avec une limite liée à S_MRU/8.

Les fusionner en une seule « MTU du tunnel » détruit une décision importante. Le premier paramètre décrit une obligation de reconstruction; le second, une taille d'émission. Une variation de S_MSS ne modifie pas automatiquement la taille de paquet présentée à la source interne. Un paquet interne non fragmentable et trop grand peut encore être abandonné avec un PTB renvoyé à sa source.

Le journal doit donc conserver la MTU d'interface, les surcharges, S_MRU, la génération de S_MSS, la longueur interne, la fragmentabilité et la preuve exacte qui a déclenché le prochain réglage.

Segmenter, fragmenter, réassembler : trois contrats

SEAL peut découper un paquet de couche intermédiaire en huit segments non chevauchants au maximum. Les segments non finaux ont une longueur égale; le dernier n'est pas plus grand; un bit More Segments et un numéro sur trois bits décrivent la suite. La sortie restaure le paquet avant de le remettre vers le haut.

Cette segmentation n'est ni une fragmentation de l'IPv4 interne, ni la fragmentation de l'enveloppe IPv4 par un routeur du sous-réseau. Les trois opérations ont des producteurs, identifiants, points de réassemblage et remèdes différents. Un compteur unique nommé « fragments » perd précisément l'information nécessaire pour décider.

L'IPv4 externe peut lui-même être réassemblé avant que SEAL voie les segments. Puis SEAL applique sa politique de reconstruction. Enfin, la couche supérieure accepte ou refuse le paquet restauré. Voir une étape ne permet pas d'inférer les deux suivantes.

R demande une observation, A demande une réponse

Avec R=1 sur le segment zéro, l'entrée souhaite un rapport de fragmentation externe. Avec A=1, elle demande un accusé. Une sonde explicite peut transporter des données ou être un paquet NULL avec No Next Header; sa valeur SEAL_ID entre dans une fenêtre des émissions en attente.

Lorsque R et A sont tous deux présents et qu'une fragmentation survient, la sortie n'envoie pas deux certitudes indépendantes. Un même message Fragmentation Needed répond aux deux intentions. L'opérateur doit donc préserver la raison de l'émission et la signification exacte de la réponse.

L'absence de message reste ambiguë. La sortie peut limiter le débit des rapports sans accusé, le paquet peut être perdu, la réponse aussi, ou le chemin peut réellement ne pas avoir fragmenté. Le silence ne choisit pas entre ces branches.

Le premier fragment donne parfois une limite trompeuse

Un rapport ICMP brut est traité comme un conseil souple, parce qu'il est facile à falsifier et difficile à rattacher sans contexte. Un message encapsulé par SEAL est plus fort s'il correspond à la fenêtre courante. Pourtant, même ce retour ne révèle pas nécessairement la MTU du lien contraignant.

Un routeur peut produire un premier fragment particulièrement court. Cette « runt fragmentation » fait apparaître une taille qui n'est pas la limite réelle du lien. RFC 5320 prévoit donc une recherche itérative. Le système réduit, observe et reteste; il ne transforme pas une valeur isolée en vérité permanente.

Une seule observation applicable doit modifier S_MSS pour une génération. Après le changement, l'entrée attend des paquets et des rapports produits sous le nouveau réglage. Plusieurs retours anciens ne doivent pas provoquer plusieurs réductions successives comme s'ils décrivaient des états nouveaux.

Le nonce borne la corrélation, pas la confiance

Le document emploie aussi un nonce et une fenêtre récente pour limiter l'acceptation de certains messages. Ce mécanisme élève la qualité de l'association par rapport à un ICMP nu. Il ne constitue pas une attestation de chemin. L'en-tête SEAL peut rester en clair hors IPsec et le contrôle de niveau 2 ne protège qu'un voisinage limité.

La bonne formulation est donc « retour associé à une émission encore vivante », non « réseau authentifié ». La fenêtre doit être enregistrée avec son époque d'état souple, le mode NAT, la génération de paramètre et le motif de sonde.

Le réassemblage dispose du droit d'abandonner

La sortie maintient des repères de réassemblage et peut rejeter des fragments anciens, en double, incohérents ou trop coûteux. Une expiration de 15 secondes borne l'attente. Sous pression mémoire, un mécanisme conforme peut jeter un ensemble incomplet même après qu'un rapport valable a été renvoyé à l'entrée.

Voilà pourquoi la chaîne de preuve doit avoir des cases séparées : enveloppe reçue, IPv4 externe réassemblé, segments SEAL reconstruits, paquet remis au protocole supérieur, résultat observé. Le succès de la boucle de réglage n'est pas le succès applicatif.

Experimental signifie une limite institutionnelle

RFC 5320 est une publication Experimental de l'Independent Submission Stream datée de février 2010. L'avis de l'IESG précise qu'elle ne suit pas le processus normal de consensus IETF. Les valeurs SEAL_PROTO, SEAL_PORT et SEAL_OPTION sont réservées à l'expérience et le texte interdit de les utiliser dans des produits expédiés ou dans un déploiement ordinaire.

Les documents ultérieurs sur l'Identification IPv4, la fragmentation et la validation de MTU apportent un contexte précieux. Ils ne convertissent pas rétroactivement SEAL en norme. Une équipe peut étudier le mécanisme dans un périmètre contrôlé; elle ne peut pas présenter son numéro RFC comme une autorisation de production.

Le reçu minimal

Pour chaque décision, conserver l'heure, l'entrée et la sortie, le mode 32 ou 16 bits, l'époque d'état, le SEAL_ID, R, A, NULL ou données, la taille envoyée, la fenêtre active, les valeurs et générations de S_MRU et S_MSS, le fragment observé, le type de rapport, le réglage appliqué, puis les résultats distincts des deux réassemblages et de la remise supérieure.

Ce reçu transforme une boucle adaptative en système explicable. Sans lui, le réseau devient plus silencieux à mesure qu'il apprend, tandis que la raison de son état disparaît.

Sources