Résumé

  • La révision draft-ietf-scone-protocol-09 explique ce que signifie, au minimum, traiter avec succès le paquet QUIC joint à un signal SCONE : il faut authentifier ce paquet comme valide. Si les paquets qui suivent sont écartés ou ignorés, notamment comme doublons possibles, le conseil de débit doit l’être aussi.
  • La même révision interdit d’émettre SCONE lorsqu’aucun paquet QUIC n’aurait été envoyé pour une autre raison. Un flux au repos peut laisser son ancien conseil expirer. Le texte demeure un Internet-Draft en examen, pas une norme RFC approuvée.

La difficulté ne se voit pas sur un graphique de débit. Un datagramme arrive, un nombre est lisible et un tableau de bord ajoute un point. Pourtant, si le paquet QUIC qui accompagne ce nombre n’est pas accepté par le destinataire, le projet SCONE dit de ne pas faire de ce point une instruction utilisable. Le journal d’arrivée et l’état du protocole racontent deux histoires différentes.

SCONE propose aux éléments du réseau situés sur le trajet d’indiquer aux applications un débit soutenable sur une durée plus longue que les réactions ordinaires à la congestion. L’élément modifie un petit paquet SCONE que l’émetteur a joint à son trafic QUIC. La condition générale existait déjà aux versions 07 et 08 : le conseil n’était valable que si un autre paquet du même datagramme avait été traité avec succès. La version 09 ne crée donc ni l’association avec QUIC ni l’idée d’un filtre à la réception.

Elle rend le filtre vérifiable : l’authentification d’un paquet QUIC valide constitue le minimum, et les paquets abandonnés ou ignorés, y compris les doublons supposés, n’ouvrent pas la porte au conseil.

Une copie tardive illustre l’enjeu. Un attaquant ou un incident peut remettre sur le chemin un datagramme dont le paquet chiffré a déjà été reçu. Si le destinataire rejette ce paquet comme doublon, la valeur SCONE ajoutée devant lui ne peut rafraîchir le débit conseillé. Mais cette protection ne doit pas être surinterprétée. Le paquet QUIC est authentifié ; la valeur SCONE, elle, ne l’est pas. La section consacrée à la sécurité envisage encore un adversaire qui observe un vrai paquet et fait parvenir une copie modifiée avant l’original.

L’acceptation du transporteur ne prouve ni l’identité de l’élément qui a écrit le nombre ni l’autorité commerciale qui aurait décidé de ce plafond.

La nouveauté relative au silence est aussi nette. Le projet conserve une période de surveillance de 67 secondes et décrit une cadence d’envoi pour les terminaux qui souhaitent recevoir des conseils. La version 09 ajoute cependant qu’un émetteur ne doit pas fabriquer du trafic QUIC seulement pour transporter SCONE. Avec du trafic utile, l’occasion d’obtenir une mise à jour existe ; sans lui, l’ancien conseil peut cesser d’être courant. Cela ne ferme pas à lui seul la connexion QUIC, ne supprime pas une politique de limitation indépendante du conseil et n’interdit pas une émission QUIC nécessaire pour un autre motif.

Confondre l’expiration d’un avis avec l’abandon d’une politique de réseau serait une erreur d’exploitation.

Il faut donc conserver plusieurs états plutôt qu’un seul compteur « dernier signal ». A-t-on vu un champ SCONE ? Le paquet joint a-t-il été authentifié et effectivement traité ? A-t-il été reconnu comme répétition ? Quel minimum a été communiqué à l’application pour la période précédente ? Quand le conseil a-t-il expiré, et une nouvelle émission QUIC avait-elle une justification étrangère à SCONE ? La révision 09 clarifie aussi que, lorsqu’un terminal transmet le conseil à une application, il lui rapporte la valeur la plus basse reçue pendant la période de surveillance précédente. Un nombre isolé ne suffit plus à expliquer la décision.

Le registre de l’IETF classe encore le document comme Internet-Draft actif, en suivi par le directeur de zone après évaluation par l’IESG, avec une position DISCUSS en suspens ; l’examen IANA doit être repris après changement de version. Aucune de ces mentions ne constitue une preuve de déploiement. L’avancée vérifiable est plus précise : le texte impose une frontière entre signal observé, signal admissible et trafic réellement nécessaire. Un exploitant peut déjà préparer les essais correspondant à cette frontière, sans prétendre que la norme est achevée.

Sources