4.2.1. 処理ガイドライン

4.2.1. 処理ガイドライン (Processing Guidelines)

DTLSレコードは順序が変更される可能性があるため、エポックMからのレコードは、エポックN(N > M)が開始された後に受信される可能性があります。実装は、以前のエポックからのレコードを破棄すべきですが、パケットの順序変更を可能にするため、TCP [RFC0793]に指定されたデフォルトのMSLまでの間、以前のエポックからの鍵マテリアルを保持することを選択してもかまいません。(ここでの意図は、実装者が[RFC0793]またはその後継文書で指定されているIETFのMSLに関する現在のガイダンスを使用することであり、システムTCPスタックが使用しているMSLを照会しようとすることではないことに注意してください。)

逆に、新しいエポックで保護されたレコードがハンドシェイクの完了前に受信される可能性があります。例えば、サーバーがFinishedメッセージを送信してからデータの送信を開始する場合があります。実装はこのようなレコードをバッファリングまたは破棄してもかまいませんが、DTLSが信頼できるトランスポート上で使用される場合(例えばSCTP [RFC4960])、それらはバッファリングされ、ハンドシェイクが完了した後に処理されるべきです。TLSのレコード送信時期に関する制限は引き続き適用され、受信者はレコードが正しい順序で送信されたかのように扱うことに注意してください。

実装は、元の送信と同じエポックおよび鍵マテリアルを使用して、失われたメッセージの再送信を送信しなければなりません。

実装は、シーケンス番号のラップアラウンドを許可する前に、アソシエーションを放棄するか、鍵を再生成しなければなりません。

実装はエポックのラップアラウンドを許可してはならず、代わりに古いアソシエーションを終了して新しいアソシエーションを確立しなければなりません。