[TLS] DTLS epoch handling
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[TLS] DTLS epoch handling



Dear all,

I'm trying to understand the epoch handling described in
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-01.txt

As far as I can see, an endpoint needs two variables,
epoch_r and epoch_w.
When sending a DTLS message it puts epoch_w in the epoch field
in the DTLS header. When it receives a DTLS message it compares
the epoch field in the header to epoch_r. If it is matches, it
processes the packet. If epoch = epoch_r - 1, it may process it
according to the text on page 7.

Is this understanding correct?

At the end of a handshake the following should happen:

          -----------ChangeChiperSpec-\
epoch_w++                              \
                                        \
                                         -------->
                                                   epoch_r++
          ------------Finished------------------->
                   --ChangeChipherSpec------------
                  /                                epoch_w++
                 /
          <-----/
epoch_r++
          <------------Finished--------------------

Is this understanding correct?

I have now the following questions:
- Can we add a statement to the ID, that an DTLS endpoint
  MUST process a DTLS message if the epoch field matches epoch_r?
- The left side can start sending messages after receiving the
  Finished message and can be sure that the messages can be processed
  by the other end. When can the right node start sending application
  data? If the ChangeChipherSpec message did not make it to the
  left side, all application data will be thrown away by the left side.
- I'm incrementing epoch_r and epoch_w by 1, but this is not specified
  in the ID.

Best regards
Michael

_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.