DTLS encoder and decoder

[gavv]

Last revised: Oct 2023

Overview

Create minimal DTLS encoder and decoder. See #229 for background.

DTLS works on transport level. Instead of sending RTP packets over UDP, we will pack RTP packets into DTLS packets and send DTLS packets over UDP.

Basically DTLS encoder should protect the whole RTP packet (RTP header + RTP payload) and add DTLS header and footer, and DTLS decoder should remove DTLS header and footer and unprotect the RTP packet.

Preparations

First, we should choose a library that implements DTLS. Several implementations exist, e.g. OpenSSL. We have specific requirements to such a library:

• It should be well-maintained.
• It should be portable (linux, unix, macos, windows).
• It should allow to use our own network loop. It should be possible to use it on packet level instead of the socket level. We will use it to encrypt and decrypt our packets, but not to send and receive packets.
• Preferably, it should allow to use custom user-provided allocator. So that we can configure it to use our own.
• Preferably, its license should not be very strict: some permissive license or LGPL would be OK.

Implementation

Then, we should add corresponding dependency and target directory to scons, and implement DtlsEncoder and DtlsDecoder.

See #317 for detailed instructions. It provides steps for adding SRTP support. DTLS support will be basically the same.

We should place new classes into a new module roc_tls. See #200 for instruction on adding a new module.

Just like with SRTP, we should start with some form of self-signed pre-shared certificates configured via command-line. We will add key management later.

Reading

• https://tools.ietf.org/html/draft-tschofenig-avt-rtp-dtls-00
• https://tools.ietf.org/html/draft-fischl-mmusic-sdp-dtls-04

[gavv]

I think we should start with OpenSSL. We already integrated it into our build system.

Here are related usage examples:

• https://github.com/nplab/DTLS-Examples/tree/master/src
• https://github.com/stepheny/openssl-dtls-custom-bio

[baranovmv]

I propose we support three use-cases:

• no crypto
• SRTP only, when key-management is done outside roc (e.g. out-of-band signaling and/or simulcast)
• DTLS-SRTP: key management is done by DTLS handshake, and the following media stream is wrapped by SRTP, this is preferrable, as it is more secure than pure SRTP approach, and disadvantages of DTLS are compensated by SRTP. In that case roc-send becomes a server waiting for incoming requests from each roc-recv.

Worth noting that it would be beneficial to support bundling RTP and RTCP on a single udp port, so that they be covered by a single SRTP session (not mentioning possible ICE feature).

[gavv]

Note: DTLS-SRTP can't work with FECFRAME, so actually it should be DTLS-SRTP for audio (and control?) stream(s) + DTLS for repair stream?

disadvantages of DTLS are compensated by SRTP

What disadvantages, exactly?

[baranovmv]

What disadvantages, exactly?

DTLS + RTP has some overhead over SRTP. Plus Seqnums in dtls are encrypted, which is less flexible (can't easily discard doubles, put in a queue etc). Also, key derivation is more expensive on DTLS (SHA256) then in SRTP (AES) (I'm not sure on that regard, that's what I get after first glance on TLS RFC)

Note: DTLS-SRTP can't work with FECFRAME, so actually it should be DTLS-SRTP for audio (and control?) stream(s) + DTLS for repair stream?

That's a problem. I'd rather thing of other possible solution. What comes first to my mind:

• add another FEC framework e.g. ULP
• send fecrame packets via dedicated RTP stream with its own SSRC
• ...

By doing so we would not only reuse crypto context on FEC packets (no need for extra handshake), but also enable bundling, which could make ICE faster.