[Sframe] Negotiating SFrame/RTP in SDP

[Richard Barnes <[e-mail]>]

Hi folks,

One of the major work items left around SFrame is the work to specify how
SFrame-encrypted media are carried in RTP, and how that is signaled in
SDP.  The finer points might need to be worked out in AVTCORE / MMUSIC, but
since this group knows the intricacies better, it seems like having some
agreement here on general approach would be good.

Sergio put together a first stab at this in
draft-murillo-avtcore-multi-codec-payload-format [1].  He presented this at
AVTCORE @ IETF 111 [2].  Unfortunately, the discussion there doesn't seem
to have provided a clear path forward, thus this thread.

Personally, I think the proposal in Sergio's draft is a little wide of the
mark.  ISTM that specifying a "generic" media format and recovering the
specificity in an RTP header is more complex than is needed. Worse, it sets
up implementations to send the same media both encrypted and unencrypted --
obviously not great for security.

I'd like to propose a simpler approach, drawing inspiration from cryptex
[3]:

a=sframe:<frame|packet> [<keying>]

Basically, just a new SDP attribute per m-line, that specifies that SFrame
encryption is being done and how.  The desired semantic is clear for
SPacket: Just add an SFrame protect/unprotect before you do other
processing on the media payload.  Then you will have a payload that is as
described in the SDP.

You can *almost* describe SFrame in this way as well.  Assemble all the RTP
packets in a frame, then do SFrame across all of their payloads (in
particular, adding the header to the first packet and the tag to the
last).  If you constrained the sender to construct pre-SFrame packets  that
were properly packetized according to the rest of the SDP, then this would
integrate cleanly with the rest of the SDP/RTP model.  The problem is that
that constraint is incompatible with Insertable Streams.  So we need to
decide how much we care about compatibility with IS as it is.  Personally,
it seems like WebRTC stacks and web apps are going to have to upgrade
*anyway* if they're going to support SDP-based negotiation of SFrame, so if
they have to make this one extra change, it shouldn't be a big deal.

How does this approach strike folks?

--Richard

[1]
https://www.ietf.org/archive/id/draft-murillo-avtcore-multi-codec-payload-format-01.html
[2] https://youtu.be/S-JR4Fa8VFY?t=3510
[3]
https://www.ietf.org/archive/id/draft-ietf-avtcore-cryptex-02.html#name-signaling