4.2.1. Linee guida per l'elaborazione

4.2.1. Linee guida per l'elaborazione (Processing Guidelines)

Poiché i record DTLS potrebbero essere riordinati, un record dall'epoca M può essere ricevuto dopo che è iniziata l'epoca N (dove N > M). Le implementazioni DOVREBBERO scartare i record dalle epoche precedenti, ma POSSONO scegliere di conservare il materiale di chiave dalle epoche precedenti fino al MSL predefinito specificato per TCP [RFC0793] per consentire il riordinamento dei pacchetti. (Si noti che l'intenzione qui è che gli implementatori utilizzino le attuali linee guida dell'IETF per MSL, come specificato in [RFC0793] o successori, non che tentino di interrogare il MSL che lo stack TCP del sistema sta utilizzando.)

Al contrario, è possibile che i record protetti con la nuova epoca vengano ricevuti prima del completamento di un handshake. Ad esempio, il server può inviare il suo messaggio Finished e quindi iniziare a trasmettere dati. Le implementazioni POSSONO bufferizzare o scartare tali record, anche se quando DTLS viene utilizzato su trasporti affidabili (ad esempio, SCTP [RFC4960]), DOVREBBERO essere bufferizzati e elaborati una volta completato l'handshake. Si noti che le restrizioni di TLS su quando i record possono essere inviati si applicano ancora, e il ricevitore tratta i record come se fossero stati inviati nell'ordine corretto.

Le implementazioni DEVONO inviare ritrasmissioni di messaggi persi utilizzando la stessa epoca e lo stesso materiale di chiave della trasmissione originale.

Le implementazioni DEVONO abbandonare un'associazione o rigenerare le chiavi prima di consentire il wrap del numero di sequenza.

Le implementazioni NON DEVONO consentire il wrap dell'epoca, ma DEVONO invece stabilire una nuova associazione, terminando la vecchia associazione.