I’ve been digging into the DTLS packet structure, looking for free bytes for some security related ideas I have been playing with.
This following is the DTLS packet structure:
| Type | Version | Epoch | Sequence Number | Length | IV | Data | MAC | Padding |
Type = (1 byte), Version (2 byte)
Epoch is incremented each rekey (2 byte)
Seq Num incremented per packet (6 byte)
Epoch + sequence number = IV for MAC
Length (2 byte) = IV + MAC + Padding
IV = Initial Vector = randomizer / seed used by encryption
Encrypted section: Data, MAC, Padding
MAC uses epoch and seq number for its sequence number (similar to an IV)
Padding added to get block size for crypto (16 or AES, 8 for DES)

According to the RFC’s, the type field supports the same types as the TLS version – this basically translates to:
SSL3_RT_CHANGE_CIPHER_SPEC 20 (x’14’)
SSL3_RT_ALERT 21 (x’15’)
SSL3_RT_HANDSHAKE 22 (x’16’)
SSL3_RT_APPLICATION_DATA 23 (x’17’)

Back to the DTLS packet structure… The encrypted portion of the packet is the Data, Mac and Padding fields. Hence, when a packet is decrypted, the padding is checked first, then the MAC for data authenticity. This is a design flaw in TLS/DTLS allowing for Padding Oracle Attack if CBC block mode encryption is used.