4.2.1. Directives de traitement

4.2.1. Directives de traitement (Processing Guidelines)

Étant donné que les enregistrements DTLS peuvent être réordonnés, un enregistrement de l'époque M peut être reçu après le début de l'époque N (où N > M). Les implémentations DEVRAIENT rejeter les enregistrements des époques antérieures, mais PEUVENT choisir de conserver le matériel de clé des époques précédentes jusqu'au MSL par défaut spécifié pour TCP [RFC0793] pour permettre le réordonnancement des paquets. (Notez que l'intention ici est que les implémenteurs utilisent les directives actuelles de l'IETF pour le MSL, comme spécifié dans [RFC0793] ou ses successeurs, et non qu'ils tentent d'interroger le MSL utilisé par la pile TCP du système.)

Inversement, il est possible que des enregistrements protégés avec la nouvelle époque soient reçus avant l'achèvement d'une négociation. Par exemple, le serveur peut envoyer son message Finished puis commencer à transmettre des données. Les implémentations PEUVENT soit mettre en tampon soit rejeter de tels enregistrements, bien que lorsque DTLS est utilisé sur des transports fiables (par exemple, SCTP [RFC4960]), ils DEVRAIENT être mis en tampon et traités une fois la négociation terminée. Notez que les restrictions de TLS sur le moment où les enregistrements peuvent être envoyés s'appliquent toujours, et le récepteur traite les enregistrements comme s'ils avaient été envoyés dans le bon ordre.

Les implémentations DOIVENT envoyer les retransmissions de messages perdus en utilisant la même époque et le même matériel de clé que la transmission originale.

Les implémentations DOIVENT soit abandonner une association soit réinitialiser les clés avant de permettre le bouclage du numéro de séquence.

Les implémentations NE DOIVENT PAS permettre le bouclage de l'époque, mais DOIVENT plutôt établir une nouvelle association en terminant l'ancienne association.