3.3.1. Packet Index Determination, and ROC, s_l Update (Détermination de l'index de paquet et mise à jour de ROC, s_l)
3.3.1. Packet Index Determination, and ROC, s_l Update (Détermination de l'index de paquet et mise à jour de ROC, s_l)
Les implémentations SRTP utilisent un index de paquet "implicite" (implicit packet index) pour le séquencement, c'est-à-dire que tout l'index n'est pas explicitement transporté dans le paquet SRTP. Pour les transformations prédéfinies, l'index i est utilisé dans la protection contre la relecture (Section 3.3.2), le chiffrement (Section 4.1), l'authentification de message (Section 4.2) et pour la dérivation de clé (Section 4.3).
Lorsque la session démarre, le côté expéditeur DOIT définir le compteur de rollover ROC (rollover counter) à zéro. Chaque fois que le numéro de séquence RTP, SEQ, boucle modulo 2^16, le côté expéditeur DOIT incrémenter ROC d'un, modulo 2^32 (voir les aspects de sécurité ci-dessous). L'index de paquet de l'expéditeur est alors défini comme
i = 2^16 * ROC + SEQ.
Les implémentations côté récepteur utilisent le numéro de séquence RTP pour déterminer l'index correct d'un paquet, qui est l'emplacement du paquet dans la séquence de tous les paquets SRTP. Une approche robuste pour l'utilisation appropriée d'un compteur de rollover exige que sa gestion et son utilisation soient bien définies. En particulier, les paquets RTP hors séquence avec des numéros de séquence proches de 2^16 ou zéro doivent être correctement gérés.
L'estimation de l'index est basée sur les valeurs ROC et s_l maintenues localement par le récepteur. Lors de la configuration de la session, le ROC DOIT être défini à zéro. Les récepteurs rejoignant une session en cours DOIVENT recevoir la valeur ROC actuelle en utilisant une signalisation hors bande (out-of-band signaling) telle que la signalisation de gestion des clés. De plus, le récepteur DOIT initialiser s_l au numéro de séquence RTP (SEQ) du premier paquet SRTP observé (sauf si la valeur initiale est fournie par une signalisation hors bande telle que la gestion des clés).
Sur les paquets SRTP consécutifs, le récepteur DEVRAIT estimer l'index comme
i = 2^16 * v + SEQ,
où v est choisi dans l'ensemble { ROC-1, ROC, ROC+1 } (modulo 2^32) de sorte que i soit le plus proche (au sens modulo 2^48) de la valeur 2^16 * ROC + s_l (voir Appendix A pour le pseudocode).
Après que le paquet a été traité et authentifié (lorsqu'il est activé pour les paquets SRTP de la session), le récepteur DOIT utiliser v pour mettre à jour conditionnellement ses variables s_l et ROC comme suit. Si v=(ROC-1) mod 2^32, alors il n'y a pas de mise à jour de s_l ou ROC. Si v=ROC, alors s_l est défini à SEQ si et seulement si SEQ est plus grand que le s_l actuel; il n'y a pas de changement à ROC. Si v=(ROC+1) mod 2^32, alors s_l est défini à SEQ et ROC est défini à v.
Après qu'un renouvellement de clé (re-keying) se produit (passage à une nouvelle clé maîtresse), le compteur de rollover maintient toujours sa séquence de valeurs, c'est-à-dire qu'il NE DOIT PAS être réinitialisé à zéro.
Comme le compteur de rollover fait 32 bits de long et le numéro de séquence fait 16 bits de long, le nombre maximum de paquets appartenant à un flux SRTP donné pouvant être sécurisés avec la même clé est de 2^48 en utilisant les transformations prédéfinies. Après qu'un tel nombre de paquets SRTP a été envoyé avec une clé donnée (maîtresse ou de session), l'expéditeur NE DOIT PAS envoyer plus de paquets avec cette clé. (Il existe une limite similaire pour SRTCP, qui en pratique peut être plus restrictive, voir Section 9.2.) Cette limitation impose un avantage de sécurité en fournissant une limite supérieure sur la quantité de trafic pouvant passer avant que les clés cryptographiques ne soient changées. Le renouvellement de clé (voir Section 8.1) DOIT être déclenché avant cette quantité de trafic, et PEUT être déclenché plus tôt, par exemple, pour une sécurité accrue et un contrôle d'accès aux médias. La dérivation de clé récurrente au moyen d'un key_derivation_rate non nul (voir Section 4.3) offre également une sécurité plus forte mais ne change pas la valeur maximale absolue ci-dessus.
Du côté récepteur, il y a une mise en garde concernant la mise à jour de s_l et ROC: si l'authentification de message n'est pas présente, ni l'initialisation de s_l, ni la mise à jour de ROC ne peuvent être rendues complètement robustes. L'approche "index implicite" du récepteur fonctionne pour les transformations prédéfinies tant que le réordonnancement et la perte des paquets ne sont pas trop importants et que les erreurs de bits ne se produisent pas de manière malheureuse. En particulier, 2^15 paquets devraient être perdus, ou un paquet devrait être décalé de 2^15 paquets dans la séquence avant que la synchronisation ne soit perdue. Une perte ou un réordonnancement aussi drastique est susceptible de perturber l'application RTP elle-même.
L'algorithme pour l'estimation d'index et la mise à jour de ROC est une question d'implémentation, et devrait prendre en considération l'environnement (par exemple, le taux de perte de paquets) et les cas où la synchronisation est susceptible d'être perdue, par exemple, lorsque le numéro de séquence initial (choisi au hasard par RTP) n'est pas connu à l'avance (non envoyé dans le protocole de gestion des clés) mais peut être proche d'une boucle modulo 2^16.
Un schéma plus élaboré et plus robuste que celui donné ci-dessus est la gestion du propre "compteur de rollover" de RTP, voir Appendix A.1 de [RFC3550].