Encryption support

[gavv]

We need to add support for encryption of RTP, RTCP, and RTSP traffic. For that purpose, we likely want to use SRTP, SRTCP, and encrypted RTSP.

We need to choose protocols and a library for encryption and integrate it in our pipeline.

[Caynosadler]

Hi @gavv is this issue still open, can i take a look at it ?

[gavv]

Hi @Caynosadler!

The issue is open, you're welcome to work on it.

For now we don't have RTCP (#14) and RTSP (#216) support yet. They're planned on 0.2.

So we can start with SRTP support. We can start with a simple scheme with pre-shared master key provided via command-line both at sender and receiver. When we'll get it working, we can add some key-exchange mechanism like ZRTP.

I'd prefer to rely on some well-established library for encryption. There are some requirements to such a library:

• It should be portable (linux, unix, macos, windows).
• Highly desirable, it should allow to use our own network loop. So that we will use it to encrypt/decrypt our packets but not to send/receive packets. We will integrate it in our pipeline.
• 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.

We can either find libraries for SRTP and ZRTP, or we can select one or a few lower-level generic cryptographic libraries that are not protocol-aware but instead implement all necessary ciphers. In the later case we'll have to implement the protocol part by ourselves. I'm OK with that.

Do you have any suggestions?

[Caynosadler]

@gavv I suggest we go with the generic cryptographic libraries and implement the ciphers and protocols.

also, i came across a ccRTP and libsrtp which satisfies some of the requirements above. Not too sure if they allows custom user-provided allocator.

[gavv]

IIRC ccRTP provides a full RTP stack. On the other hand, we have our own and it's tightly integrated in our pipeline. Using foreign RTP stack for SRTP would be a pain I guess.

[Caynosadler]

Then I suggest we go with this

We can either find libraries for SRTP and ZRTP, or we can select one or a few lower-level generic cryptographic libraries that are not protocol-aware but instead implement all necessary ciphers

[gavv]

I've just took a look at libSRTP and it looks promising. It fulfills almost all requirements: portable, doesn't implement its own network loop, doesn't force its own RTP stack (you just pass bytes to it), permissive license.

The only thing missing is using custom allocator. This requirement is not critical though.

I suggest to try it. Specifically, we can start with the following:

• Add target_libsrtp to SConstruct. Add libsrtp to 3rdparty.py. You can find example of adding a new dependency in libsndfile source and sink #246 and Implement backtrace printing for non-glibc targets #265.

• Add rtp::SRTPWriter (for sender), implementing packet::IWriter, and rtp::SRTPReader (for receiver), implementing packet::IReader. The idea is that we write unprotected packets to the writer and it protects them and in turn writes to the next writer. The opposite for the reader. Place them to roc_rtp/target_libsrtp.

• Add unit tests for SRTPWriter and SRTPReader.

• Integrate SRTPWriter and SRTPReader into roc_pipeline. They should be enabled conditionally. An example of conditionally enabled pipeline element is packet::Interleaver. We should also add necessary configuration to roc_pipeline/config.h.

• Add command-line options to enable SRTP in roc-recv and roc-send and configure it. We can start with a pre-shared key specified via command-line.

• It would be also desirable to add pipeline-level tests for SRTP. See src/tests/roc_pipeline.

These docs may be helpful: https://roc-project.github.io/roc/docs/internals.html

A note regarding rtp::SRTPWriter. It will need to obtain the byte representation of packet::Packet. You'll have to use packet::IComposer for that. Take a look at fec::Writer. It uses IComposer for the same reason.

[gavv]

However, there are a few important questions we need to answer first.

We use FECFRAME, which uses two separate streams for source and repair packets. Two modes are possible: 1) both streams are RTP 2) source stream is RTP, and repair stream use custom FECFRAME-specific protocol.

FECFRAME supports multiple FEC schemes. Each FEC scheme defines which mode to use. Some schemes define RTP payload formats for their repair packets and thus the first mode is used. Other schemes define custom header format for repair packets and thus the second mode is used.

Also, all FEC schemes define custom footer added to RTP source packets.

Currently we support Reed-Solomon and LDPC-Staircase. Both schemes use second mode, i.e. repair packets are non-RTP. We have plans to support Raptor (#236), which uses the first mode, i.e. repair packets are RTP.

So the questions are:

• Can we use SRTP with FECFRAME?
• If yes, what schemes can we use with SRTP? Reed-Solomon, LDPC, Raptor?
• What other options, except SRTP, do we have, that will work with FECFRAME?

The following RFCs may be useful:

• https://tools.ietf.org/html/rfc6363
• https://tools.ietf.org/html/rfc3711
• https://tools.ietf.org/html/rfc7201

I didn't read the last two yet.

[gavv]

Answering my questions:

Can we use SRTP with FECFRAME?

Only with FEC schemes that use RTP for repair packets. SRTP requires RTP header to be present.

If yes, what schemes can we use with SRTP? Reed-Solomon, LDPC, Raptor?

Only with Raptor. Reed-Solomon and LDPC don't use RTP for repair packets and there is no standardized way to pack them into RTP.

What other options, except SRTP, do we have, that will work with FECFRAME?

RTP over DTLS.

[gavv]

So there are SRTP and RTP over DTLS:

• SRTP is widely used, standard, and required by RTSP 2.0 (which we're adding in 0.2) and WebRTC (which we may want to add in future). SRTP is RTP-specific. It gives lower overhead compared to DTLS. However, it wont allow us to use Reed-Solomon and LDPC FEC schemes. Only Raptor (which we're going to implement) and Opus (which is not a FEC scheme but provides some sort of lossy FEC). This is quite limiting because FEC is an important feature.

• DTLS is not widely used with RTP and such usage is not standardized well, except SIP (I found only some expired RFC drafts). It gives larger overhead. It's not RTP-specific and can be used with any protocol, including any FEC scheme.

In other words, SRTP is widely used and standard, but DTLS is needed to support all FEC schemes. For these reasons, I think we should implement both of them and allow the user to make a choice.

I think we can close this issue and open two new issues instead:

• Implement minimal SRTP codecs using libSRTP, with pre-shared keys / certificates.
• Implement minimal DTLS codecs using OpenSSL, with pre-shared certificates.

Then we'll open issues for other related features (key management, integration with RTSP, complete support of RTP/SAVP(F), etc).

@Caynosadler What do you think? Would you like to work on one of those issues?

[gavv]

Related readings

DTLS:

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

SRTP:

• https://tools.ietf.org/html/rfc3711
• https://tools.ietf.org/html/rfc4567

(S)RTCP:

• https://tools.ietf.org/html/rfc4585
• https://tools.ietf.org/html/rfc5124
• https://tools.ietf.org/html/rfc7022

Other:

• https://tools.ietf.org/html/draft-jholland-mboned-ambi-04

[Caynosadler]

@gavv yeah i think that works, we can open two new issues first

I'll like to take up the Implementation of minimal SRTP codecs using libSRTP, with pre-shared keys / certificates.

[gavv]

Two new issues:

• SRTP encoder and decoder #317
• DTLS encoder and decoder #318

@Caynosadler please leave a comment there so I can assign you.

Closing this one.