[Sframe] Implementation report: SPacket in Webex

[Richard Barnes <[e-mail]>]

Hi folks,

I wanted to share some implementation news: Webex has shipped SFrame as
part of its new end-to-end encrypted meetings feature [1], using an
open-source SFrame stack in C++ [2].  It is now being used for several
thousand meetings per day.

A few findings:

1. Keys for SFrame are provided from an MLS group associated to the
meeting.  In particular, this means that the SFrame keys change whenever
someone joins or leaves the meeting.  This works smoothly as long as the
key roll-over is coordinated so that senders don't encrypt with the new key
before receivers have it to decrypt with.

2. The SFrame encryption framing is applied to individual RTP media
payloads, as opposed to full frames (i.e., this is "SPacket".)  This
approach made integration very simple; you simply add an SFrame
protect/unprotect whenever you do an SRTP protect/unprotect.  Everything
else, including things like recovery, works as before.

3. With the algorithms and parameters we are using (AES-GCM, E=4), the
overall bandwidth overhead from SFrame in a typical meeting with voice,
video, and content share is around 80kbps.  Applying SFrame per-frame in
this setting would reduce this to about 45kbps.  With a base bandwidth of
around 3Mbps, this puts SFrame at around 3% overhead per-packet / 1.5%
per-frame.

4. SFrame usage is not signaled in SDP, much like the WebRTC uses of SFrame
based on Insertable Streams.

Overall, SFrame seems to be working well for this use case.  We should
carry on getting it an RFC number :)

--Richard

[1]
https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html
[2] https://github.com/cisco/sframe