Résumé

  • RFC 9916 est une norme proposée de l’IETF, publiée en juillet 2026, qui met à jour RFC 8253.
  • Ses deux ajouts sont stricts : une implémentation qui prend en charge plusieurs versions TLS DOIT préférer la plus récente qu’elle prend en charge ; une implémentation PCEPS prenant en charge TLS 1.3 ou une version ultérieure NE DOIT PAS utiliser les données précoces.
  • Les données précoces, ou 0-RTT, exigent une PSK partagée, ne fournissent pas de confidentialité persistante et ne sont pas protégées contre la relecture entre connexions. Ce compromis est particulièrement délicat pour une intention de contrôle de chemin.

PCEP relie un client de calcul de chemin (PCC) à un élément de calcul de chemin (PCE), et peut aussi fonctionner entre PCE. Les extensions PCEP avec état et l’établissement de LSP initié par un PCE rendent la continuité de session et la réconciliation opérationnelles. Cela ne signifie pas que chaque message PCEP est rejouable ; cela signifie qu’il faut traiter explicitement l’acceptation d’une intention de contrôle avant la fin sûre de la négociation.

RFC 9916 n’impose pas la prise en charge de TLS 1.3 et n’interdit pas TLS 1.2. Il n’établit pas non plus la prise en charge par les fournisseurs ni l’achèvement d’un déploiement. Il laisse inchangés l’initiation de connexion, le cadrage des messages, la fermeture, la validation des certificats, l’identité du pair et la gestion des échecs définis par RFC 8253. La modification porte donc sur la préférence de version et l’usage des données précoces, non sur un remplacement général de PCEPS.

Le point opérationnel est précis. Avec une PSK, une reprise de session TLS 1.3 peut rendre le 0-RTT disponible ; pour PCEPS, RFC 9916 impose alors de ne pas utiliser les données précoces lorsque l’implémentation prend en charge TLS 1.3 ou une version ultérieure. Le chiffrement ne suffit pas : il faut observer la version négociée, l’état des données précoces, la chaîne de certificats, l’identité du pair et le chemin d’échec.

Registre des affirmations et des preuves RFC

Affirmation Preuve
Mise à jour de PCEPS et deux règles ajoutées RFC 9916
Initiation, cadrage, fermeture, certificats, identité et échecs inchangés RFC 8253
Contexte du protocole PCC/PCE et des sessions RFC 5440
Synchronisation et opérations PCEP avec état RFC 8231
Opérations de changement d’état initiées par un PCE RFC 8281
Limite de conséquence dans une architecture de contrôle centralisé RFC 8283
Recommandations opérationnelles pour TLS RFC 9325
PSK, confidentialité persistante et relecture entre connexions en TLS 1.3 RFC 9846

Séparation selon cinq dimensions

Ce briefing traite du risque de relecture et de la négociation de version TLS à la frontière d’une session de contrôle PCEP protégée par TLS. Il ne traite pas du cycle de vie des baux DHCPv6 de RFC 9915, des routes projetées RPL de RFC 9914, ni de la récupération RAW de RFC 9912. Ces trois RFC explicitent la frontière de collision des cinq dimensions ; elles ne constituent pas les preuves de la modification apportée par RFC 9916.

Sources