SRTP protocol support

[josuah]

Summary

Moving media over the network requires a protocol in a way or another for:

• Describing the media content in a way suitable for UDP (i.e. allowing packet loss)
• Conventions over how encryption is setup

Zephyr RTOS does not currently support such feature as part of its ecosystem, and the current issue propose an initiative for a vendor-neutral implementation to integrate in any suitable way depending on how it turns out.

Describe the solution you'd like

Integrate the SRTP protocol, which is used for the main 3 media + network use-cases:

• Telephony (it is the foundation of the SIP protocol stack)
• Conferencing (it is the foundation of the WebRTC protocol stack)
• CCTV (it is the foundation of the RTSP+ONVIF-based protocol stacks)

Everything except SRT (more narrow purpose for live TV broadcasts, i.e. news, sport events...) and HTTP-based protocols.

Alternatives

• Rely on custom protocols (i.e. raw video over UDP like in current samples)

• Move this discussion downstream altogether

Additional Context

This discussion got split away from this PR which gives the example of one possible method of integration, as well as illustrates how much code it takes to support the SRTP protocol at Zephyr level:

• [RFC] Support for libsrtp #99132

[josuah]

I've added a few assignee just for visibility, and offering the maintainers to tell their favorite approach.

Insights from @seyednasermoravej porting effort:

Implement SRTP natively in Zephyr:

• Re-implementing srtp.c which contains SRTP (transport) and SRTCP (QoS statistics)
• Re-implementing the crypto integration layer

Port libSRTP as an external module:

• IPv6 support requires Zephyr to have its own rtp.h and rtp.c or a PR to change them on libsrtp
• Migration to Mbed TLS 4.0 / TF-PSA Crypto 1.0 with changes to aes_gcm.h, aes_gcm_mbedtls.c, aes_icm_ext.h, aes_icm_mbedtls.c, and hmac_mbedtls.c

(S)RTP-based stacks:

• WebRTC => SRTP/SRTCP
• SIP => (S)RTP/(S)RTCP
• ONVIF and CCTV => RTSP => (S)RTP/(S)RTCP

Stacks using other protocols:

• SRT "low latency between sites in different cities, countries or even continents"
• RTMP (TCP-based) from adobe flash player websites era, used by web-based broadcasting like YouTube, twitch...
• HLS and DASH: on top of HTTP, oriented towards web servers streaming already-compressed files

[seyednasermoravej]

Implement SRTP natively in Zephyr:

* Re-implementing [`srtp.c`](https://github.com/cisco/libsrtp/blob/main/srtp/srtp.c) which contains SRTP (transport) and SRTCP (QoS statistics)

* Re-implementing the [crypto integration layer](https://github.com/cisco/libsrtp/tree/main/crypto)

It seems no one supports the first option. As @rlubos clarified, his suggestion referred to possibly re-implementing the RTP module, not the entire SRTP stack.

Port libSRTP as an external module:

* IPv6 support requires Zephyr to have its own `rtp.h` and `rtp.c` or a PR to change them on libsrtp

* Migration to Mbed TLS 4.0 / TF-PSA Crypto 1.0 with changes to `aes_gcm.h`, `aes_gcm_mbedtls.c`, `aes_icm_ext.h`, `aes_icm_mbedtls.c`, and `hmac_mbedtls.c`

From my side, I would like to know which one should be prioritized first: IPv6 support or the Mbed TLS / PSA Crypto migration?

[jukkar]

From my side, I would like to know which one should be prioritized first: IPv6 support or the Mbed TLS / PSA Crypto migration?

As mbedtls requires use of PSA crypto in the next mbedtls version that zephyr will be using, then that is priority 1.

[rlubos]

(S)RTP-based stacks:

...

• SIP => (S)RTP/(S)RTCP

Is this actually correct? Still a newbie in the area, so I could misunderstand something, but it appears to me that SIP is not built on top of (S)RTP, but rather used in parallel to establish (S)RTP streaming sessions.

[josuah]

Oh yes you are right, I do not mean the actual SIP protocol, but the overall SIP stack: what is typically associated with it.
As like you said, SIP alone will not transfer any media. The user is free to pick everything they want, and very often, it's RTP in the secure form.

Likewise for the other stacks, their job is often to just prepare networking (i.e. inform each other of address for NAT traversal, describe endpoint address port etc.) so that an SRTP feed can start. At least from what I've seen.

So... as you said!