Re: [Sframe] Negotiating SFrame/RTP in SDP

>From my point of view, all the mechanisms described on the multi codec
payload format are required:

The ability to differentiate a RTP packet encrypted end to end (either by
SFrame or SPacket) is a must, both from a formal point of view about how
RTP works, but also to ensure that the media servers does not perform any
payload inspection that will cause malfunction (metadata gathering, layer
switching, recording..)

The optionality of the encryption also comes from various factors. First,
end to end encryption is an "endpoint" decision, the SDP negotiation with
the media server should not be the place to enforce it or not. Also, not
always the media server and the endpoints are provided by the same company
(i.e. CPaaS) and they will have to support both end to end encryption and
non end to end encryption calls. Note that it is quite a common practice in
SFUs to send an SDP offer from the media server to the endpoint, in which
case, the media server will have to offer e2e encryption as optional.

As an example, in Millicast we support both e2ee and non-e2ee streams today
(with the insertable stream per codec hacks), it is a completely optional
feature up to each customer to implement and to decide when and if it is
used. We are just carriers, and we do not want the customer to have to
configure if the stream is e2ee or not. We are not (and must not be)
involved in enforcing e2ee in any way.

Best regards
Sergio

On Thu, Sep 2, 2021 at 10:23 PM Richard Barnes <rlb@ipv.sx> wrote:

> 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
> --
> Sframe mailing list
> Sframe@ietf.org
> https://www.ietf.org/mailman/listinfo/sframe
>