Résumé

  • Le nouveau TLV de contrôle permet de demander au réflecteur STAMP une longueur, un nombre et un intervalle de paquets, tandis que le réflecteur doit imposer ses propres plafonds de débit et de volume.
  • Le même drapeau C couvre la contrainte de MTU de sortie et le dépassement du débit ou du volume autorisé. La longueur reçue aide à distinguer les deux familles, mais elle ne remplace pas un reçu reliant la réponse à la politique locale et à l’usage analytique restant possible.

Le premier paquet d’une campagne de mesure n’est pas seulement une sonde. Il contient une proposition de charge adressée au réflecteur : quelle taille renvoyer, combien de paquets émettre et à quel intervalle. Le réflecteur répond aussi à une autre question, silencieuse mais plus urgente : quelle part de cette proposition peut traverser son interface sans dépasser la protection qu’il doit appliquer ?

Si la réponse contient un seul paquet marqué C, le protocole a transmis une décision compacte. Il n’a pas transmis le dossier de cette décision.

La révision 14 de draft-ietf-ippm-asymmetrical-pkts étend STAMP aux paquets asymétriques. Une réponse peut être plus courte ou plus longue que la requête, et un paquet reçu peut déclencher plusieurs paquets réfléchis. Cette souplesse sert à reproduire des profils de trafic différents, à soutenir certaines mesures de débit et à travailler dans un arbre multicast. Elle crée également un levier d’amplification : peu d’octets entrants peuvent demander davantage d’octets sortants, éventuellement à plusieurs feuilles.

Le texte ne laisse pas ce risque sans réponse. Le mécanisme doit être désactivé par défaut et soumis à un contrôle administratif. L’identité doit être protégée ; le mode authentifié de STAMP ou le TLV HMAC est recommandé. Surtout, chaque réflecteur compatible doit limiter à la fois le débit de données qu’il génère et le volume total de charge utile.

Deux décisions aboutissent au même bit

Le calcul de la longueur obéit d’abord au format. Le paquet réfléchi doit contenir le paquet de base et les extensions applicables, sans recopier mécaniquement le remplissage supplémentaire reçu. Il doit aussi atteindre la longueur demandée, alignée sur quatre octets. Un TLV de remplissage ajoute ce qui manque.

Si cette longueur calculée dépasse la MTU de l’interface de sortie vers le Session-Sender, le réflecteur met C à un et renvoie un seul paquet de la taille de cette MTU. La contrainte vient alors de la forme du chemin retour : le paquet demandé ne tient pas.

Une autre règle peut intervenir même si le paquet tient parfaitement. Le réflecteur compare la séquence demandée à ses plafonds de débit et de volume. Si l’un ou l’autre est dépassé, il met également C à un et ne renvoie qu’un paquet, cette fois à la longueur calculée. La contrainte vient de l’enveloppe locale de charge.

La spécification propose une manière de reconnaître ces familles. Un paquet reçu plus court que la longueur demandée indique la branche MTU. Un paquet de même longueur indique la branche débit et/ou volume. C’est une information utile, mais non un journal de politique. La seconde branche ne dit pas quel plafond a agi. Aucune branche ne donne la valeur du plafond, sa fenêtre de calcul, le traitement des rafales, le nombre de sessions concurrentes ou la version de configuration.

Le nom « Conformant Reflected Packet » pourrait inviter un lecteur pressé à réduire C à conforme/non conforme. Le comportement décrit est plus précis : C marque une réponse transformée par deux familles de limites. L’opérateur doit conserver cette précision quand le paquet quitte le laboratoire et rejoint une série chronologique, un rapport de capacité ou un dossier d’incident.

La sécurité du réseau peut invalider la forme de l’expérience

Une réduction à un paquet est parfois exactement la bonne décision. Le réflecteur est le mieux placé pour connaître sa MTU de sortie et la charge qu’il peut accepter. Refuser un train trop dense protège le trafic utile, les autres sessions de mesure et le réflecteur lui-même.

Mais le paquet restant ne reconstitue pas une rafale. Il peut prouver la réception de la requête, fournir des horodatages et confirmer certains éléments du chemin. Il ne prouve pas que le nombre de réponses et leur cadence demandés ont été produits. Un système qui classe le test comme « réussi » sans nommer l’objectif mélange réussite protocolaire et validité métrologique.

Le projet de texte garde cette frontière. Le TLV fournit les paramètres de longueur, de nombre et d’intervalle ; la méthode et la métrique de débit d’accès restent hors de son périmètre. Pour une mesure en service, la charge devrait commencer bas puis augmenter. Un test hors service peut au contraire chercher volontairement à créer de la congestion sur le goulet. Le même C n’a pas la même conséquence dans ces deux contextes.

Il faut aussi éviter de transformer une protection en résultat commercial. Une limite du réflecteur n’est pas automatiquement le débit de l’accès. Une MTU observée n’est pas une promesse de service. Un paquet authentifié n’accorde pas un droit illimité à générer de la charge. Le projet avertit même qu’une campagne intensive peut enfreindre les limites imposées au service par le fournisseur.

En multicast, il manque aussi le dénominateur

Un paquet multicast peut atteindre de nombreux Session-Reflectors. Les sous-TLV de groupe de niveau 2 et de niveau 3 permettent de sélectionner ceux qui répondent, par exemple au moyen d’un masque d’adresse ou d’un préfixe IP. La recommandation est de commencer prudemment, avec une seule réponse demandée, afin d’observer la charge avant d’augmenter la séquence.

Le nombre reçu ne raconte pourtant pas tout. Pour interpréter six réponses, il faut savoir combien de réflecteurs étaient éligibles, lesquels avaient rejoint l’arbre, quel filtre a été appliqué, quelles limites locales se sont déclenchées et quelles pertes sont survenues. Sans ce dénominateur, une baisse peut être un échantillonnage voulu, une suppression protectrice, une variation d’adhésion ou une défaillance.

Le texte envisage qu’un environnement multicast modifie les champs de sélection pour réduire les réponses. Si l’intégrité est protégée, une telle modification échoue sauf si l’élément se trouve dans le périmètre de confiance et peut recalculer la protection. Une modification autorisée peut donc produire un paquet cryptographiquement valide. Cette validité ne dit toujours pas qui a approuvé la réduction ni quel était le contenu antérieur.

Le besoin de gouvernance n’est pas d’interdire cette adaptation. Il est de rendre son autorité et son effet visibles après coup.

Le reçu des limites de réflexion

Un reçu utile commence par le contexte de session : identités du sender et du réflecteur, transport, mode STAMP, protection cryptographique, version logicielle et génération de configuration. Il reprend ensuite la demande exacte : longueur, nombre, intervalle, sélecteurs de groupe et instruction de chemin retour.

La finalité doit être explicite. Le test était-il en service ou hors service ? Quelle métrique devait-il alimenter ? Quelle enveloppe de charge avait été approuvée, pour quelle fenêtre et par quel responsable ? La conformité syntaxique de la requête ne répond pas à ces questions.

Du côté du réflecteur, le reçu lie l’interface de sortie et l’observation de MTU aux plafonds actifs de débit et de volume. Il indique les unités, la fenêtre d’accumulation, la règle de rafale, la prise en compte des sessions concurrentes et l’identifiant de version de la politique. Les valeurs sensibles peuvent rester internes ou être engagées par une empreinte, mais l’organisation doit pouvoir rejouer la décision.

Puis vient la cause. MTU, débit, volume, ou débit et volume ensemble ne sont pas interchangeables. Si le sender déduit la branche à partir de la longueur, le reçu doit dire « inféré ». Si le réflecteur conserve une cause locale plus précise, elle peut être attestée séparément. Il ne faut pas transformer une déduction de l’autre extrémité en déclaration du réflecteur.

Enfin, le reçu énonce ce que la mesure permet encore d’affirmer. Une réponse peut rester exploitable pour la joignabilité ou un horodatage, tout en étant impropre à une estimation fondée sur la rafale. Elle peut exiger une nouvelle requête, une fenêtre de maintenance ou un test hors service. L’approbateur, la date d’expiration, l’exception, la correction et l’autorité de retour complètent la trace.

Ce reçu demeure hors du paquet. Il n’ajoute ni code IANA ni champ STAMP. Il évite simplement qu’une politique locale disparaisse derrière un bit global.

Ne pas confondre les signaux voisins

Lorsque le nombre demandé vaut zéro, le réflecteur n’envoie aucune réponse et devrait abandonner la requête, sauf politique locale contraire. Si l’intention est réellement de ne recevoir aucune réponse, le mécanisme de contrôle du chemin retour est préférable. Ce cas ne doit pas être reclassé artificiellement comme un événement C.

Le drapeau U répond encore à d’autres situations : combinaisons incompatibles, fonction non comprise, ou réponse unique à un numéro de séquence non croissant. Le texte précise que ce dernier indice peut venir d’une attaque par rejeu, mais aussi d’un réordonnancement ou d’une duplication. U ne nomme donc pas davantage l’intention d’un attaquant que C ne nomme la limite locale exacte.

Le balisage ECN mérite la même retenue. CE indique une congestion naissante et non une perte. Le seuil jugé significatif et l’action qui suit relèvent du déploiement. Puisque la mesure active peut contribuer elle-même à la congestion, son interprétation doit relier la sonde, la protection et le trafic observé.

Sources

  1. Fiche courante du document
  2. Historique du document
  3. Révision 14 en HTML
  4. Révision 14 en texte
  5. Source XML de la révision 14
  6. Révision 13 en texte
  7. Comparaison officielle 13–14
  8. Groupe de travail IPPM
  9. Documents IPPM
  10. RFC 8762 : STAMP
  11. RFC 8972 : extensions optionnelles de STAMP
  12. RFC 9097 : test de débit UDP
  13. RFC 7497 : problème de la mesure du débit
  14. RFC 9503 : contrôle du chemin retour STAMP
  15. RFC 8085 : recommandations pour UDP
  16. RFC 1982 : arithmétique des numéros de série
  17. RFC 7799 : méthodes de mesure actives et passives
  18. RFC 7942 : état des implémentations
  19. Lu Heng : Minimum Initial Specification, Localized Future Decision
  20. Lu Heng : The Policy Mirror