Résumé

  • Le cookie LTP est un état de session évolutif. Dès qu’une valeur plus longue est acceptée, l’ancienne n’est plus bonne ; une retransmission doit porter la valeur correcte au moment du nouvel envoi.
  • Le cookie complique certaines attaques par déni de service mais n’authentifie pas son auteur. AuthVal peut protéger le segment, tandis que la distribution des clés, le sens de KeyID et la décision de retrait restent hors de RFC 5327.

Une retransmission n’est pas une archive réseau

Un segment part avec un cookie valable. Pendant sa traversée, le pair ajoute des bits aléatoires au cookie déjà connu. Plus tard, une minuterie réclame une retransmission. L’intuition la plus dangereuse consiste à reprendre les octets enregistrés et à les remettre sur la liaison.

RFC 5327 impose une autre logique. Le segment retransmis doit contenir le cookie correct au moment de la retransmission, qui peut être différent de celui du premier départ. L’identité de la charge utile ne suffit donc pas à déterminer l’identité de l’acte de sécurité.

Une preuve exploitable conserve deux empreintes : celle du contenu protocolaire et celle du segment encodé avec ses extensions du moment. Elle rattache aussi chaque tentative à la version du cookie, à la cause du nouvel envoi et au résultat du contrôle distant lorsqu’il est disponible.

Sans cette séparation, un rejet silencieux paraît inexplicable. L’ancienne valeur était effectivement correcte autrefois, mais elle a cessé de l’être après l’adoption d’une extension. Le receveur peut appliquer parfaitement la règle pendant que le tableau de bord accuse à tort la liaison ou le pair.

Le cookie est une relation de préfixe soumise au temps

Le mécanisme n’est pas une négociation unique avant le trafic. Chaque moteur peut introduire un cookie à tout moment. Après un délai acceptable tenant compte de la propagation, tous les segments des deux directions doivent porter une bonne valeur. Avant l’échéance, certains segments déjà en vol peuvent encore être admis sans cookie.

La mise en œuvre choisit ce délai. Une même absence peut donc être recevable à une heure et conduire à un rejet plus tard. La décision dépend du plan de contact, du temps de propagation estimé et d’une politique locale que le paquet ne contient pas.

Une valeur peut être allongée par concaténation de bits aléatoires. Une valeur est bonne si elle commence par la valeur stockée, ou si elle est nouvelle alors qu’aucune n’a encore été observée. Une fois la valeur étendue acceptée, la version courte ne l’est plus. Ce n’est ni une simple égalité ni un ensemble de jetons interchangeables ; c’est une transition monotone de préfixes.

Le journal doit enregistrer le prédécesseur, l’extension, son auteur apparent, l’heure de réception, l’échéance calculée et les premières décisions sous le nouvel état. Ne garder que la dernière valeur rend impossible l’explication du délai de grâce.

Deux cookies peuvent créer deux obligations

Le délai permet aux deux moteurs d’émettre chacun un cookie initial avant d’avoir vu celui du pair. La spécification ne les fusionne pas. Lorsque le trafic a rattrapé l’état, les segments suivants portent deux extensions indépendantes et les deux valeurs doivent être bonnes.

Le cookie initial du pair doit aussi parvenir dans une fenêtre finie : après que l’obligation locale est devenue effective, une nouvelle seconde origine ne peut plus être admise comme si elle avait toujours existé. Une colonne unique cookie_session ne représente ni cette fenêtre ni les deux chaînes de préfixes.

La multiplicité concerne également l’authentification. Le système d’extensions LTP permet plusieurs occurrences d’un même tag. Un stockage qui transforme la liste en dictionnaire écrase souvent l’instance qui a réellement justifié l’acceptation.

Il faut conserver l’ordre, la direction, le nombre, les valeurs protégées et le résultat de chaque contrôle. La réduction doit venir après la preuve, pas la remplacer.

Un rejet silencieux ne nomme pas la cause

Après l’expiration du délai, un segment dont le cookie manque ou est incorrect doit être supprimé sans réponse. Ce silence protège des ressources mais produit une évidence ambiguë pour l’émetteur.

Il peut correspondre à une ancienne valeur, une extension jamais reçue, un calcul de délai erroné, une multiplicité mal encodée, un échec AuthVal, une absence de support ou simplement un contact manqué. L’expiration côté émetteur ne permet pas de choisir entre ces scénarios.

Le receveur peut documenter sa propre décision : tel segment a échoué à la règle de préfixe stockée à telle heure. Il ne peut pas en déduire seul une intention hostile, un rejeu de la liaison ou une faute d’exploitation distante.

Une chronologie d’incident joint donc les deux vues : transitions de cookie, échéances, empreintes avant et après réencapsulation, compteurs de suppression, résultats d’authentification et fenêtres de contact.

Un cookie imprévisible n’est pas une identité

Un cookie suffisamment imprévisible augmente le coût du trafic aveugle. Il ne prouve pas qui a demandé son extension. RFC 5327 avertit que, sans authentification d’origine, un intermédiaire peut allonger une valeur et exclure le pair légitime. Le receveur rejettera ensuite la valeur courte précisément parce que son automate fonctionne.

Cookie et AuthVal répondent donc à des questions différentes. Le premier vérifie la compatibilité avec l’état local courant de la session. Le second vérifie le segment encodé dans un contexte cryptographique choisi. Lorsque les couches inférieures n’offrent ni intégrité ni fraîcheur, le document recommande de les employer ensemble.

Le cookie ne survit pas à la session LTP. Il ne constitue pas un registre durable contre le rejeu entre sessions ou après redémarrage. Même avec AuthVal, aucune de ces extensions ne prouve l’approbation de l’application, la remise Bundle ou un résultat de mission.

Une authentification réussie peut cacher l’ancienne clé

L’en-tête LTP-auth contient un numéro de suite cryptographique et un KeyID facultatif traité comme des octets bruts. La signification de KeyID est explicitement hors périmètre. Le protocole ne distribue pas la clé, n’établit pas son propriétaire, ni ses dates d’autorisation.

Le premier segment d’une session authentifiée doit porter cet en-tête ; les suivants peuvent l’omettre. Pour limiter l’effet d’une perte initiale, le texte recommande de le répéter lorsque la bande passante le permet. La retransmission du premier segment doit à nouveau le contenir.

Pendant une migration de clés, un émetteur peut joindre plusieurs couples en-tête/AuthVal. Le receveur doit les chercher et peut accepter si au moins une valeur se vérifie. Cette souplesse évite une coupure, mais le booléen authentifié ne dit plus quelle époque a gagné.

Si l’ancienne clé reste installée, le trafic peut être déclaré valide alors que la nouvelle clé n’est jamais utilisée. Le suivi doit donc nommer l’AuthVal vérifié, le KeyID, la suite, le contexte local et l’état d’autorisation externe. Inversement, l’échec d’un candidat n’est pas une attaque si un autre réussit dans le chevauchement prévu.

Un numéro de suite n’est pas un avis de sécurité

Le RFC attribuait initialement HMAC-SHA1-80, RSA-SHA256 et NULL. NULL emploie une clé codée en dur et fournit un contrôle robuste, pas une authentification ; il reste exposé aux attaques actives. Un calcul réussi avec la valeur 255 ne doit donc jamais être présenté comme identité vérifiée.

Le registre IANA constate des attributions numériques. Il ne recommande pas un algorithme pour un risque actuel, ne prouve aucune négociation et ne valide aucun cycle de vie de clé. RFC 5327 est Experimental et décrit la gestion des clés comme une question de recherche ouverte. Un déploiement actuel doit fournir sa propre analyse cryptographique et opérationnelle.

Sources et limite de preuve

Ces sources établissent les règles, les attributions et le statut de publication. Elles ne prouvent aucun déploiement, aucune clé configurée, aucune attaque, aucune conformité, aucune session ni aucun résultat applicatif.