From nobody Mon Nov 1 20:04:38 2021 Return-Path: X-Original-To: sframe@ietf.org Delivered-To: sframe@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 048513A0955; Mon, 1 Nov 2021 20:04:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163582227699.25979.331673952738661925@ietfa.amsl.com> Date: Mon, 01 Nov 2021 20:04:37 -0700 Archived-At: Subject: [Sframe] The SFRAME WG has placed draft-omara-sframe in state "Call For Adoption By WG Issued" X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 03:04:37 -0000 The SFRAME WG has placed draft-omara-sframe in state Call For Adoption By WG Issued (entered by Martin Thomson) The document is available at https://datatracker.ietf.org/doc/draft-omara-sframe/ From nobody Mon Nov 8 10:51:01 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874A33A005C for ; Mon, 8 Nov 2021 10:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-s01r_whrjG for ; Mon, 8 Nov 2021 10:50:55 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812163A0788 for ; Mon, 8 Nov 2021 10:50:47 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id s13so17958517uaj.11 for ; Mon, 08 Nov 2021 10:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6eCoWVmOL5JPTdkB5R8qfRr6Yq2+AdGWk14eEZqPyac=; b=PzZGRWAFwMBjhvO+xdginSKsncIH1JOnMX8uiSXpqsyCLF6gKWaL+t3jxSHSpbNoiQ arMvprtCRH1SiXwWiG3w8C75j3mE/2nGCZFTEyI8BMZmszQf+WB4wxBI5lfkwXk+NFUB v/Gzg+ygUpsL0KpatsHlo0oJrk7olDjJQnpH29YJDcelwmZRqkg18c99GSF8LBZyRyKC Ow2CviHfZEPyZbbQgrKvRkT6OuxrqBIqzuuWlFLAunL9uP+KRnucGwHzQPHnINalxczQ 7HzmDuBvtrq9FEshmJiohjqKj+gwwnfCueHiUaguZDv0lwY5iL7cdcbGumoQ/XQJ3nlV wDUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6eCoWVmOL5JPTdkB5R8qfRr6Yq2+AdGWk14eEZqPyac=; b=alAkBD7yjr6YU/thJqL/h1A1X4bMyRI0ldDN5EUCYRnPsoxxh6y5SWLdeSvZYyjUBB EqBjWOK7XG+JqjXZVIj4t0lQmXxiP8f1PhL0gOykvyhvJwz59BgDR9Ey9nn2Va2GSx8d 4y5s8/npHMu32ukyPfdvtX1t9YFDDzAFyRU5AZZIkNwXBkUNl4Fids0EkMut6E6PUKjo nfmzuXQ4p6VgAy/1zpeZFS8mNA1txZM0cuwQMQLh1Uv4vkvkdcua/8+8RsL6bX/KRoy+ Zpj9s7OfhgAo3Vmen311ZYdG7rPdtimJzCV8llDyXJYAR0KXgqEIFwTT+HUP6bBvgBH1 IWlg== X-Gm-Message-State: AOAM532Fn2zODIDXkGWpe4Pp90N9q04HEYz8RVURbwLQGVe274hYmAPi Q2a8UnW3x6ax59BnWAUcD1nUJXVDR0JXScHVd+ZfnBzi X-Google-Smtp-Source: ABdhPJwqh6h7EarztY4ub9UQ67VPuTOev6Flqs8Xd46l87AwW9VOcGSkbHrK7tPuVZy/7pGDCj74//5yknyVkwyqoZU= X-Received: by 2002:a67:f9c6:: with SMTP id c6mr9144952vsq.20.1636397444356; Mon, 08 Nov 2021 10:50:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Suhas Nandakumar Date: Mon, 8 Nov 2021 10:50:33 -0800 Message-ID: To: Bernard Aboba Cc: Richard Barnes , sframe@ietf.org, Sergio Garcia Murillo Content-Type: multipart/alternative; boundary="00000000000061dd3305d04b785f" Archived-At: Subject: Re: [Sframe] Negotiating SFrame/RTP in SDP X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 18:51:00 -0000 --00000000000061dd3305d04b785f Content-Type: text/plain; charset="UTF-8" Taking a step back, it looks like we might want to achieve following 1. A way to indicate the media stream corresponding to a m= line uses end to end encryption based on sframe and if so, what mode of it I think Richard's proposal addresses this aspect but making it not tied to a codec format but to a media stream. We need to define Offer/Answer considerations for the same though. From a quick glance, it feels like a=sframe O/A implies, Offerer's intent on send direction and Answerer's intent on the recv direction for sendrecv streams. In cases where there is a mismatch that is unsatisfactory for the offerer, its application which needs to decide if it wants to proceed with the call and hence is outside O/A context. 2. Explain the behavior when multiple lines are bundled This needs a=sframe attribute or a similar one's multiplexing behavior be defined. IIUC the safest category seems to be IDENTICAL_PER_PT unless I am missing something. This would allow say audio m= and video m= to have different encryption properties and having that flexibility seems to be a nice thing 3. Behavior/Expectation from the SFU Given the focus is on E2EE, we can't trust SFU anyways. I agree with Sergio that the SDP attribute will provide a hint to SFU and enable it to adjust its flows accordingly. Am I missing something here ? On Thu, Sep 9, 2021 at 1:51 PM Bernard Aboba wrote: > "On the question of why we're doing SDP here at all, the main reason that > comes to my mind is: Giving SFUs fair notice of what's going on so that > they can act intelligently on E2E-encrypted streams. There might be some > secondary benefits to setting up endpoints. > > It is worth noting that the current round of implementations (both > IS-based ones and Webex) demonstrate that E2EE calls can be done without > any changes to SDP, as long as SFUs don't get upset when they can't > interpret the media. " > > [BA] By negotiating RTP header extensions designed to enable > payload-agnostic forwarding (e.g. framemarking, DD, etc.), the SFU can > obtain the information it needs to forward packets without having to parse > the payload. > > The question is whether this is sufficient. > > It seems to me that SDP can enable a compatible combination of RTP header > extension and codecs to be determined, but there can be complications. > > For example, the endpoint might support framemarking with the H.264 codec > but not with VP8 or VP9, which are also supported. Unfortunately, the SFU > only supports forwarding VP8, VP9 and AV1 as well as the Dependency > Descriptor RTP header extension but not framemarking. > > In this situation, O/A negotiation will result in the endpoint and SFU > negotiating VP8 or VP9 without a forwarding RTP header extension. If the > endpoint then attempts to encrypt E2E, the SFU will "get upset", because it > will attempt to parse the payload, having no other means available to > forward the packets. > > If E2E encryption is an endpoint requirement, the endpoint can refuse to > proceed with the call. That would probably be the appropriate outcome > since it knows that the SFU doesn't support the combination of codecs and > RTP header extensions necessary to make E2E encryption work. > > Richard also said: > > "The potential benefits of having some standardization of signaling would > be (1) to let SFUs react more intelligently in these situations, say by > requesting different RTP extensions, and (2) simplifying some of the > endpoint configuration that is needed to make SFrame work (or at least > letting an endpoint fail faster, say if it doesn't have any keys for > SFrame)." > > [BA] SDP allows the SFU to tell the endpoint what codecs and RTP header > extensions it supports, and for the endpoint to do the same. So the basic > info can be exchanged in a single found of Offer/Answer. Is it possible to > implement "Intelligence" at a higher layer, within the application? That > would simplify things. > > Richard also said: > > With regard to downgrade: First, in some applications, there is a > signaling level above SDP (like SIP, or some HTTP thing for WebRTC), that > is independent of the SFU and could thus distribute an E2EE signal to allow > detection of downgrade. Second, if all the infrastructure is adversarial, > then it's up to the clients to signal somehow whether a given call is E2EE. > > [BA] Could the client "signal" be provided in the media? Remember that > SFRAME isn't tied to RTP necessarily (e.g. SFRAMEs can be transmitted over > WebRTC data channel, WebTransport, etc.). So you have a lot of freedom > here. > > On Thu, Sep 9, 2021 at 11:49 AM Richard Barnes wrote: > >> Hi Bernard, >> >> On the question of why we're doing SDP here at all, the main reason that >> comes to my mind is: Giving SFUs fair notice of what's going on so that >> they can act intelligently on E2E-encrypted streams. There might be some >> secondary benefits to setting up endpoints. >> >> It is worth noting that the current round of implementations (both >> IS-based ones and Webex) demonstrate that E2EE calls can be done without >> any changes to SDP, as long as SFUs don't get upset when they can't >> interpret the media. The potential benefits of having some standardization >> of signaling would be (1) to let SFUs react more intelligently in these >> situations, say by requesting different RTP extensions, and (2) simplifying >> some of the endpoint configuration that is needed to make SFrame work (or >> at least letting an endpoint fail faster, say if it doesn't have any keys >> for SFrame). >> >> With regard to downgrade: First, in some applications, there is a >> signaling level above SDP (like SIP, or some HTTP thing for WebRTC), that >> is independent of the SFU and could thus distribute an E2EE signal to allow >> detection of downgrade. Second, if all the infrastructure is adversarial, >> then it's up to the clients to signal somehow whether a given call is E2EE. >> >> --RLB >> >> >> >> >> On Mon, Sep 6, 2021 at 7:39 PM Bernard Aboba >> wrote: >> >>> Richard said: >>> >>> "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." >>> >>> [BA] If the SFU is untrusted to have cleartext access to the payload, >>> why would the endpoint use SDP to negotiate with the SFU whether to use E2E >>> encryption? This potentially enables a downgrade attack. >>> >>> Such a negotiation only makes sense in a use case where there are some >>> clients that support E2E encryption and others that do not, and the SFU is >>> looking to gracefully keep the non-E2E endpoints out of the conference >>> (e.g. by failing the O/A negotiation, instead of succeeding and then having >>> the non-E2E endpoints being unable to parse the codec payloads). >>> >>> Sergio said: >>> >>> "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. " >>> >>> [BA] SDP negotiation between the endpoint and SFU is useful in >>> negotiating hop-by-hop parameters, such as the RTP header extensions needed >>> by the SFU to forward packets without inspecting the RTP payload. >>> >>> But in a CPaaS scenario, I agree that the application will determine >>> whether to use E2E encryption or not and the SFU need not know or care, >>> since it isn't parsing the codec payloads anyway. In that scenario you >>> won't have a mixture of E2E capable and non-capable endpoints, so the SDP >>> negotiation would serve no useful purpose. >>> >>> >>> >>> On Mon, Sep 6, 2021 at 12:14 PM Sergio Garcia Murillo < >>> sergio.garcia.murillo@cosmosoftware.io> wrote: >>> >>>> 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 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: [] >>>>> >>>>> 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 >>>>> >>>> -- >>>> Sframe mailing list >>>> Sframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sframe >>>> >>> -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --00000000000061dd3305d04b785f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Taking a step back, it looks like we might want to achieve= =C2=A0following=C2=A0

1. A way to indicate the media str= eam corresponding to a m=3D line uses end to end encryption based on sframe= and if so, what mode of it=C2=A0
=C2=A0 =C2=A0 =C2=A0I think Ric= hard's proposal addresses this aspect but making it not tied to a codec= format but to a media stream. We need to define Offer/Answer consideration= s for the same though. From a quick=C2=A0glance, it feels like a=3Dsframe O= /A implies, Offerer's intent on send direction=C2=A0and Answerer's = intent on the recv direction for sendrecv streams.
In cases where= there is a mismatch that is unsatisfactory for the offerer, its applicatio= n which needs to decide if it wants to proceed with the call and hence is o= utside O/A context.

2. Explain the behavior when m= ultiple=C2=A0lines are bundled=C2=A0
=C2=A0 =C2=A0 This needs a= =3Dsframe attribute or a similar one's multiplexing behavior be defined= . IIUC the safest category seems=C2=A0to be IDENTICAL_PER_PT unless I am=C2= =A0missing something. This would allow say audio m=3D and video m=3D to hav= e different encryption properties and having that flexibility seems to be a= nice thing

3. Behavior/Expectation from the SFU
=C2=A0 =C2=A0 Given the focus is on E2EE, we can't trust SFU a= nyways. I agree with Sergio that the SDP attribute will provide a hint to S= FU and enable it to adjust its flows accordingly.

= Am I missing something here ?



=
On Thu, Se= p 9, 2021 at 1:51 PM Bernard Aboba <bernard.aboba@gmail.com> wrote:
"On the question o= f why we're doing SDP here at all, the main reason that comes to my min= d is: Giving SFUs fair notice of what's going on so that they can act i= ntelligently on E2E-encrypted streams.=C2=A0 There might be some secondary = benefits to setting up endpoints.

It is worth noti= ng that the current round of implementations (both IS-based ones and Webex)= demonstrate that E2EE calls can be done without any changes to SDP, as lon= g as SFUs don't get upset when they can't interpret the media. &quo= t;

[BA] By negotiating RTP header extensions d= esigned to enable payload-agnostic forwarding (e.g. framemarking, DD, etc.)= , the SFU can obtain the information it needs to forward packets without ha= ving to parse the payload.=C2=A0

The question is w= hether this is sufficient.=C2=A0

It seems to me th= at SDP can enable a compatible combination of RTP header extension and code= cs to be determined, but there can be complications.

For example, the endpoint might support framemarking with the H.264 code= c but not with VP8 or VP9, which are also supported. Unfortunately, the SFU= only supports forwarding VP8, VP9 and AV1 as well as the Dependency Descri= ptor RTP header extension but not framemarking.=C2=A0

<= div>In this situation, O/A negotiation will result in the endpoint and SFU = negotiating VP8 or VP9 without a forwarding RTP header extension. If the en= dpoint then attempts to encrypt E2E, the SFU will "get upset", be= cause it will attempt to parse the payload, having no other means available= to forward the packets.

If E2E encryption is an e= ndpoint requirement, the endpoint can refuse to proceed with the call.=C2= =A0 That would probably be the appropriate outcome since it knows that the = SFU doesn't support the combination of codecs and RTP header extensions= necessary to make E2E encryption work.=C2=A0

Rich= ard also said:=C2=A0

"The potential benefits = of having some standardization of signaling would be (1) to let SFUs react = more intelligently in these situations, say by requesting different RTP ext= ensions, and (2) simplifying some of the endpoint configuration that is nee= ded to make SFrame work (or at least letting an endpoint fail faster, say i= f it doesn't have any keys for SFrame)."

<= div>[BA] SDP allows the SFU to tell the endpoint what codecs and RTP header= extensions it supports, and for the endpoint to do the same. So the basic = info can be exchanged in a single found of Offer/Answer.=C2=A0 Is it possib= le to implement "Intelligence" at a higher layer, within the appl= ication?=C2=A0 That would simplify things.=C2=A0

R= ichard also said:=C2=A0

With regard to downgrade: = First, in some applications, there is a signaling level above SDP (like SIP= , or some HTTP thing for WebRTC), that is independent of the SFU and could = thus distribute an E2EE signal to allow detection of downgrade.=C2=A0 Secon= d, if all the infrastructure is adversarial, then it's up to the client= s to signal somehow whether a given call is E2EE.

= [BA] Could the client "signal" be provided in the media?=C2=A0 Re= member that SFRAME isn't tied to RTP necessarily (e.g. SFRAMEs can be t= ransmitted over WebRTC data channel, WebTransport, etc.).=C2=A0 So you have= a lot of freedom here.

On Thu, Sep 9, 2021 at 11:49 AM Richard Barne= s <rlb@ipv.sx> wr= ote:
Hi Bernard,

On the question of why we&#= 39;re doing SDP here at all, the main reason that comes to my mind is: Givi= ng SFUs fair notice of what's going on so that they can act intelligent= ly on E2E-encrypted streams.=C2=A0 There might be some secondary benefits t= o setting up endpoints.

It is worth noting tha= t the current round of implementations (both IS-based ones and Webex) demon= strate that E2EE calls can be done without any changes to SDP, as long as S= FUs don't get upset when they can't interpret the media.=C2=A0 The = potential benefits of having some standardization of signaling would be (1)= to let SFUs react more intelligently in these situations, say by requestin= g different RTP extensions, and (2) simplifying some of the endpoint config= uration that is needed to make SFrame work (or at least letting an endpoint= fail faster, say if it doesn't have any keys for SFrame).

With regard to downgrade: First, in some applications, the= re is a signaling level above SDP (like SIP, or some HTTP thing for WebRTC)= , that is independent of the SFU and could thus distribute an E2EE signal t= o allow detection of downgrade.=C2=A0 Second, if all the infrastructure is = adversarial, then it's up to the clients to signal somehow whether a gi= ven call is E2EE.

--RLB




On Mon, Sep 6, 2021 at 7:39 PM Bernard Aboba = <bernard.ab= oba@gmail.com> wrote:
Richard said:=C2=A0

"= Just add an SFrame protect/unprotect before you do other processing on the = media payload.=C2=A0 Then you will have a payload that is as described in t= he SDP."

[BA]=C2=A0 If the SFU is untrusted t= o have cleartext access to the payload, why would the endpoint use SDP to n= egotiate with the SFU whether to use E2E encryption?=C2=A0 This potentially= enables a downgrade attack.=C2=A0=C2=A0

Such a ne= gotiation only makes sense in a use case where there are=C2=A0some clients = that support E2E encryption and others that do not, and the SFU is looking = to gracefully keep the non-E2E endpoints out of the conference (e.g. by fai= ling the O/A negotiation, instead of succeeding and then having the non-E2E= endpoints being unable=C2=A0to parse the codec payloads).=C2=A0
=
Sergio said:=C2=A0

"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. "

[BA]=C2=A0 SDP ne= gotiation between the endpoint and SFU is useful in negotiating hop-by-hop = parameters, such as the RTP header extensions needed by the SFU to forward = packets without inspecting the RTP payload.=C2=A0=C2=A0

But in a CPaaS scenario, I agree that the application will determine = whether to use E2E encryption or not and the SFU need not know or care, sin= ce it isn't parsing the codec payloads anyway.=C2=A0 In that scenario y= ou won't have a mixture of E2E capable and non-capable endpoints, so th= e SDP negotiation would serve no useful purpose.

<= br>

On Mon, Sep 6, 2021 at 12:14 PM Sergio Garcia Murillo <<= a href=3D"mailto:sergio.garcia.murillo@cosmosoftware.io" target=3D"_blank">= sergio.garcia.murillo@cosmosoftware.io> wrote:
From my point o= f view, all the mechanisms described on the multi codec payload format are = required:

The ability to differentiate a RTP packe= t 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 medi= a servers does not perform any payload inspection that will cause malfuncti= on (metadata gathering, layer switching, recording..)=C2=A0

<= /div>
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 t= he 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 com= mon practice in SFUs to send an SDP offer from the media server to the endp= oint, in which case, the media server will have to offer e2e encryption as = optional.

As an example, in Millicast we support b= oth e2ee and non-e2ee streams today (with the insertable stream per codec h= acks), it is a completely=C2=A0optional feature up to each customer to impl= ement and to decide when and if it is used. We are just carriers, and we do= not=C2=A0want the customer to have to configure if the stream is e2ee or n= ot. We are not (and must not be) involved in enforcing e2ee in any way.=C2= =A0

Best regards
Sergio

On Thu, Sep 2, 20= 21 at 10:23 PM Richard Barnes <rlb@ipv.sx> wrote:
Hi folks,

One of the major work it= ems left around SFrame is the work to specify how SFrame-encrypted media ar= e carried in RTP, and how that is signaled in SDP.=C2=A0 The finer points m= ight 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].=C2=A0 He presented t= his at AVTCORE @ IETF 111 [2].=C2=A0 Unfortunately, the discussion there do= esn'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.=C2=A0 ISTM that specifying a "generic" media format= and recovering the specificity in an RTP header is more complex than is ne= eded. Worse, it sets up implementations to send the same media both encrypt= ed and unencrypted -- obviously not great for security.

I'd like= to propose a simpler approach, drawing inspiration from cryptex [3]:
a=3Dsframe:<frame|packet> [<keying>]

Basically, just a= new SDP attribute per m-line, that specifies that SFrame encryption is bei= ng done and how.=C2=A0 The desired semantic is clear for SPacket: Just add = an SFrame protect/unprotect before you do other processing on the media pay= load.=C2=A0 Then you will have a payload that is as described in the SDP.
You can *almost* describe SFrame in this way as well.=C2=A0 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 l= ast).=C2=A0 If you constrained the sender to construct pre-SFrame packets = =C2=A0that were properly packetized according to the rest of the SDP, then = this would integrate cleanly with the rest of the SDP/RTP model.=C2=A0 The = problem is that that constraint is incompatible with Insertable Streams.=C2= =A0 So we need to decide how much we care about compatibility with IS as it= is.=C2=A0 Personally, it seems like WebRTC stacks and web apps are going t= o have to upgrade *anyway* if they're going to support SDP-based negoti= ation of SFrame, so if they have to make this one extra change, it shouldn&= #39;t be a big deal.

How does this approach strike folks?

--R= ichard

[1] https://www.i= etf.org/archive/id/draft-murillo-avtcore-multi-codec-payload-format-01.html=
[2] https://youtu.be/S-JR4Fa8VFY?t=3D3510
[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
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000061dd3305d04b785f-- From nobody Mon Nov 8 10:57:20 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B173A0788 for ; Mon, 8 Nov 2021 10:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns41sImbmZ5E for ; Mon, 8 Nov 2021 10:57:15 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE063A0C8A for ; Mon, 8 Nov 2021 10:57:10 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id c8so49765594ede.13 for ; Mon, 08 Nov 2021 10:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=/3U/hfxhnk1oXIwzqWSpQJe3QmcdQbTIC23auOhtQqU=; b=IKbbv9yntGNXaC5cdGYQklBcsAs/REsOOy7TVeWVUtZ0062rwClDL3tbMYvD1mNWig etyRdZEYOeUV4z6k6Gxpqyqeedi6r3OiKX6fc0rYloh8vn9WwPFHFxRUX6+rfag4CTmT 7paHqcG2l+3+FLn/HRE9XdPw+sfXpB309agbpBBAthivFFsdVJ80ZHLnvbOa01agH/Dc CMw1NIA5lcrv5m+JDVA0K0GcuTqs50C3c7KUn+sogQ2Q+PUTtxktdGKOUHE06CnSfS+b JVtjo1P6QNa2J7NQogmAwBhZQH79uaKBzF+NjtRuebfpN4RYuwhUk5f28AZOmTgQ7Cal LnPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/3U/hfxhnk1oXIwzqWSpQJe3QmcdQbTIC23auOhtQqU=; b=DRKH8OyL5bcWdF/7eBT+5YdfuiX7NczAUqqc/Bn+SvCIVs1ZKITc9WmYdIdDk2ucVL kpl1YprtyCK7YPDsWXPeTinbp9ISt0B0gVaII6Nx6O1eVyOFmxFjZegHQ9ap0D+lasc2 Nde1tSsT7DZB8OetcnlKCYwkVLTw87PhtGXVo2rCq1ITEClr/cZj53Zw1/sHF6aQnkMc OPqvo68Xbdpe0O5c0TfhtJjhPsykRuDXoaDlaviLkpTEJB6rtFttl0+QtB96+e9ef3Pp OdQJhlV3dQ1vWMvNGwWNwraue8p6MNLiewRR7VMcny2mgZyGkU6ag3TXmTNf5DK/zyjE kbaw== X-Gm-Message-State: AOAM532SzscOAQot+pyTCU08J2OTtUGQ4bLvkXng8vrOjS5bA7T8vf+H xbTXoETE4H0yuhz27tohcGXbxS3cw+26nOVx0ofk2q6+ X-Google-Smtp-Source: ABdhPJyQZtpO3fwazYStfj7Y+FsNV241IrbzQuuR9T+ATcYuNB7YXMHcjM0zIZCuN3pBYlu3pKGY9mGIyDSC7Lp3UCI= X-Received: by 2002:a17:907:961e:: with SMTP id gb30mr1780598ejc.436.1636397823876; Mon, 08 Nov 2021 10:57:03 -0800 (PST) MIME-Version: 1.0 From: Bobo Date: Mon, 8 Nov 2021 10:56:50 -0800 Message-ID: To: sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000000e3b505d04b8f3e" Archived-At: Subject: [Sframe] Adopting draft-omara-sframe-03 X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 18:57:20 -0000 --00000000000000e3b505d04b8f3e Content-Type: text/plain; charset="UTF-8" Hey Everyone, Thanks for your constructive feedback on adopting the latest SFrame draft, draft-omara-sframe-03 (https://datatracker.ietf.org/doc/draft-omara-sframe/ ). After reviewing the comments we think the appropriate next step is to adopt draft-omara-sframe-03 as an item for our working group. Adopting paves the way for the editors taking a first step at tackling the feedback raised. In particular, we note the following open issues for future work: 1. Agnostic approach to SFrame vs. SPacket - each has pros/cons 2. Splitting out E2EE / key management material into an appendix as stage setting 3. Articulate goals, threat model, and use cases more clearly (likely will be aided by refactoring non-SFrame/SPacket materials into appendix) Please see specific prior emails, e.g. from Bernard and Eric, for detailed feedback and discussion. Thanks, Bobo (for the Chairs) --00000000000000e3b505d04b8f3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Everyone,

Thanks for your constructive feedback on adopting the latest SFrame draft= , draft-omara-sframe-03 (https://datatracker.ietf.org/doc/draft-omara-sframe/).

After reviewing the comme= nts we think the appropriate next step is to adopt draft-omara-sframe-03 as= an item for our working group.

Adopting paves the way for the editors taking a first step at tac= kling the feedback raised.

In particular, we note the following open issues for future work:
<= div dir=3D"auto">
1. Agnostic approach to SFrame= vs. SPacket - each has pros/cons

2. Splitting out E2EE / key management material into an appendix = as stage setting

3. Arti= culate goals, threat model, and use cases more clearly (likely will be aide= d by refactoring non-SFrame/SPacket materials into appendix)

Please see specific prior emails, e.g= . from Bernard and Eric, for detailed feedback and discussion.

Thanks,
Bobo = (for the Chairs)
--00000000000000e3b505d04b8f3e-- From nobody Tue Nov 16 10:51:10 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B003A3A0788 for ; Tue, 16 Nov 2021 10:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alphaexplorationco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPSdznyLbI7q for ; Tue, 16 Nov 2021 10:51:03 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADAE73A07A4 for ; Tue, 16 Nov 2021 10:51:03 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id h16-20020a9d7990000000b0055c7ae44dd2so2778otm.10 for ; Tue, 16 Nov 2021 10:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphaexplorationco.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2SzTkvgF2zrrWPoatgSBbrmIqGG5S06Dg+bBHD0Lyv4=; b=BuaJ6Ka+Kb4b4nhG7gPs1mUIDMBqwMy3dE6RllV3hR2O7pX2uaml0SifLuWjuvl3D5 s43yl3VRhhPE3VuJ8BGhT5qEw974UznpON0HKatdcbK0aAPrv7mPHPEtS3JhdP+IrPVB 1GO9kDHaXSuVSe4VHb1tB0mZmgRzZspxZvdDBPhHKVQI3F0nRMszVOtDVsdAHs2GmfBD RTY8lk3zN1EWC4asZKYZKvaOq/tYu3zcYNL/wUkIPbw4y/Ytxf7UK5SOtYnS1hG1GIpU pAxedpWUFxFFksrZ4FokxqiS5MwaJ23XxQ/spnKibpJblBeLvZbMdPIJqHUc2KkPFdOG U32Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2SzTkvgF2zrrWPoatgSBbrmIqGG5S06Dg+bBHD0Lyv4=; b=RmvWG9vAYQlUCFXXTGzhNSBK9lJho3yChqqTaKzjVRqnHBVj01syoeuA9j6lsLB3po edBEJsmAgWdUdKrePz4om/xgduX+QA0uoO1ey9yYB3WT2TnKa2Jj/gl/S+ZBCcEnNttH yrx7AQytJ/k0t14zTKDO1rH8WZWhfgw1+7hnTQTXwM+AxNx23rF235/ELHozohXeofUB zEEZWjs6Mq3JZZbsXXnj4vdYfkeN8BudT6GizU42ZWsrzRPeRCtov1ZX5XLOKADBplcu xCxfra7KqZznFCIbOCh6AB+50NEqTQpQ4KxvZR3lFXUi57fM5kPRMG8R19otCwZKynO8 E14Q== X-Gm-Message-State: AOAM533uoyhBZub8ut8hYjRrihKJX9rfXNymsowb0BUK4iVzL59MSjgW MmDc9RdXiVYpBE/m9hL2q1XpFlrQUI2PSRNZ5ZW8O+9SpyE= X-Google-Smtp-Source: ABdhPJwiKLp6G6qoyMaeabvC9K9xYzqjtrdG2NAijvJiWU0HoyZ8s+VXAqjECbjnr26CjThGW5xkKebO6MU4dnyEhbU= X-Received: by 2002:a9d:7758:: with SMTP id t24mr8284399otl.264.1637088661918; Tue, 16 Nov 2021 10:51:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Tue, 16 Nov 2021 10:50:51 -0800 Message-ID: To: Richard Barnes Cc: Sergio Garcia Murillo , sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000028f24705d0ec6886" Archived-At: Subject: Re: [Sframe] Proposal: SFrame && SPacket && !SIDU X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2021 18:51:09 -0000 --00000000000028f24705d0ec6886 Content-Type: text/plain; charset="UTF-8" Richard, when you talk about "units" here, are you referring to things coming out of the codec? or the RTP packetizer for said codec? The recent IETF meeting ended with some confusion as to this specific question and it would be good for us on this list to make sure we're all in alignment. On Tue, Sep 7, 2021 at 12:46 PM Richard Barnes wrote: > I'm not totally sure what you mean by "spatial frames" here; looks like > the notion varies some by codec. Assuming "spatial frames" are frames in > the sense of "something that comes out of depacketizater", I think we're > probably on the same page. > > Maybe it would be clearer to state the proposal as: Encryption is done in > units of whole RTP payloads. One payload for SPacket; all payloads in the > frame for SFrame. We would not support cases where an encrypted unit would > span a partial RTP payload. For example: > > NOT OK > Payload 1: First part of SFrame unit A > Payload 2: Second part of A, first part of B > Payload 3: Second part of B > > OK > Payload 1: SFrame unit A > Payload 2: First part of Sframe unit B > Payload 3: Second part of B > > Does that line up with what you have in mind? > > --Richard > > On Mon, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo < > sergio.garcia.murillo@cosmosoftware.io> wrote: > >> Hi Richard, >> >> Just one minor comment, the "media frames", should be spatial frames if >> SVC is used so an SFU is able to not forward all spatial layers to the >> receiver. Apart from that, I am ok with removing "SIDUs" from the scope. >> >> Best regards >> Sergio >> >> On Thu, Sep 2, 2021 at 10:20 PM Richard Barnes wrote: >> >>> Hi folks, >>> >>> I'd like to see if we can agree to limit our scope a bit. There has >>> been discussion of multiple levels at which SFrame could be applied: >>> >>> * "SFrame" - Whole media frames >>> * "SPacket" - Individual RTP media payloads >>> * "SIDU" - Some codec-specific "independently decodeable units" >>> >>> I'd like to propose that we take "SIDU" off of the table, but keep the >>> other two. >>> >>> It seems like SFrame and SPacket both have strengths in certain >>> scenarios (depending on how you want to trade off bandwidth vs. >>> complexity), but they're both pretty straightforward in terms of how they >>> integrate with the media processing pipeline. In particular, they don't >>> have any codec-dependence. SIDU, by contrast, seems like a world of pain. >>> It requires that the encryption scheme be entangled with the codec, which >>> requires special per-codec integration logic in the specifications. And >>> the bandwidth gains for all that complexity are not that large. >>> >>> Is there anyone here who feels that SIDU is something this group needs >>> to spend time specifying? >>> >>> --Richard >>> -- >>> Sframe mailing list >>> Sframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/sframe >>> >> -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --00000000000028f24705d0ec6886 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Richard, when you talk about "units" here, are y= ou referring to things coming out of the codec? or the RTP packetizer for s= aid codec?

The recent IETF meeting ended with some confu= sion as to this specific question and it would be good for us on this list = to make sure we're all in alignment.

On Tue, Sep 7, 2021 at 12:46 = PM Richard Barnes <rlb@ipv.sx> wrot= e:
I'm not totally sure what you mean by "spatial frames&quo= t; here; looks like the notion varies some by codec.=C2=A0 Assuming "s= patial frames" are frames in the sense of "something that comes o= ut of depacketizater", I think we're probably on the same page.

Maybe it would be clearer to state the proposal as: = Encryption is done in units of whole RTP payloads.=C2=A0 One payload for SP= acket; all payloads in the frame for SFrame.=C2=A0 We would not support cas= es where an encrypted unit would span a partial RTP payload.=C2=A0 For exam= ple:

NOT OK
Payload 1: First par= t of SFrame unit A
Payload 2: Second part of A, first part of= B
Payload 3: Second part of B

OK
Payload 1: SFrame unit A
Payload 2: First part of Sframe = unit B
Payload 3: Second part of B

Does that line up with what you have in mind?

--Richar= d

On Mon, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo <sergio= .garcia.murillo@cosmosoftware.io> wrote:
Hi Richard,

Just one minor comment, the "media frames", should be spati= al frames if SVC is used so an SFU is able to not forward all spatial layer= s to the receiver. Apart from that, I am ok with removing "SIDUs"= =C2=A0from the scope.

Best regards
Sergi= o

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

= I'd like to see if we can agree to limit our scope a bit.=C2=A0 There h= as been discussion of multiple levels at which SFrame could be applied:
=
* "SFrame" - Whole media frames
* "SPacket" - In= dividual RTP media payloads
* "SIDU" - Some codec-specific &qu= ot;independently decodeable units"

I'd like to propose that= we take "SIDU" off of the table, but keep the other two.

= It seems like SFrame and SPacket both have strengths in certain scenarios (= depending on how you want to trade off bandwidth vs. complexity), but they&= #39;re both pretty straightforward in terms of how they integrate with the = media processing pipeline.=C2=A0 In particular, they don't have any cod= ec-dependence.=C2=A0 SIDU, by contrast, seems like a world of pain.=C2=A0 I= t requires that the encryption scheme be entangled with the codec, which re= quires special per-codec integration logic in the specifications.=C2=A0 And= the bandwidth gains for all that complexity are not that large.

Is = there anyone here who feels that SIDU is something this group needs to spen= d time specifying?

--Richard
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000028f24705d0ec6886-- From nobody Tue Nov 16 13:33:26 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503B03A096F for ; Tue, 16 Nov 2021 13:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20210112.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI8ShhjnJjjD for ; Tue, 16 Nov 2021 13:33:20 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D00C3A096A for ; Tue, 16 Nov 2021 13:33:20 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id n15so674274qta.0 for ; Tue, 16 Nov 2021 13:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eYBjIBBW7tBBDWTVVEKpLzFchWNlrPtQKImEDcZM0qI=; b=HOKS9WRvTnMRoy/w4hPhHmrMhLBmDHiempeEE4YDZA21xiDKiY/ScoPH9idiSL7Eiz /4qO/Vd+pe5HeE02VoL44i4kx42hf+ORcJ4J3FWN2pl8hv1CUu2F/sEcHyEQYTBxOpZo jwbR5W1oew8YudfQe3PqdOpQ9KvV2Z2OqyLHuTpa5vHZ+LkCuypXxoM/BuEln3vFe3iA lOQ8YgtaxxvOf4p9utAqrpQF1l8wMnWz4qcnjmb0hxcAKtwWvbfVKTPzg873f/SKlYjc djOn6MUFwR3zgzNv97SqDS3P/y5wvDm9xahEt8A8WqSOSz1WbRJ94vZQ51PSrrR/MpHz xerw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eYBjIBBW7tBBDWTVVEKpLzFchWNlrPtQKImEDcZM0qI=; b=Z5XerypuFsbZ/Dtm3PqMYuPKTJXmHbDYKgc2QCyvYgj9HuMZCfYS0sBFQQVBakuyr7 Db2B2V/MIUXimHPwmkvVW+1IVnE37se5VUSTLbZXy4uxdJvdK/giXZfbxML677IULZF3 by4vcW91zrz+SayC2sKaaIMZgu4AIRy5HpzvxtOfe+Lr5KIG0u4dmEpwIn7RWztdjDCx BV32axcta9PE+ONN5ufg2YyD5/o26XuyZtZGoNwi9p4dfpbCc34glf9yWiEs+/fOn/eK +W1e2nRjE7BMOqW/6M9GV+HrSmKMKc4Gya8DWBpR83exkFcQ7O9CZiTxR1FQf7yWyTRp 7+WQ== X-Gm-Message-State: AOAM533ngZcdZn8UjY7bAL+kpQa02KCaIh0zA+xFnk/S0I2sH3xpHrdL RiOHeMIpA5rQ4TxpdET2GekDf73sG/XD5LOHz3Y/OM4GYdw0jw== X-Google-Smtp-Source: ABdhPJxpBJ1cMh97ft5xGkY5BGBjkPVNpWogvnEqw6Ws6aoImbolnYcwm0ieMH20ogqTfucFZQ/8plibCRMfdJcLc/g= X-Received: by 2002:ac8:7f06:: with SMTP id f6mr11283273qtk.258.1637098398703; Tue, 16 Nov 2021 13:33:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 16 Nov 2021 16:33:07 -0500 Message-ID: To: Justin Uberti Cc: Sergio Garcia Murillo , sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000084733005d0eeac53" Archived-At: Subject: Re: [Sframe] Proposal: SFrame && SPacket && !SIDU X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2021 21:33:25 -0000 --00000000000084733005d0eeac53 Content-Type: text/plain; charset="UTF-8" Specifically, I mean the things that are AEAD-encrypted. My mental model is that there are two moving parts here: 1. A general SFrame encapsulation, defined in this group, that takes a "unit" of media data and encrypts it with an AEAD cipher 2. One or more ways to apply that encapsulation to a real-time media stream. Since AEADs deal with discrete quantities of data and not streams, one of the things (2) has to define is how to divide a media stream up into units that are fed into the SFrame encap/decap algorithms. (In other words, between which layers in the media stack you put in the SFrame layer.) And on decode, you need a way for the receiver to recognize when SFrame ciphertexts begin and end. For SFrame and SPacket, those answers are pretty clear: * For SPacket: SFrame goes between packetization and SRTP; ciphertext begin/end = packet begin/end * For SFrame: SFrame goes between encoding and packetization; ciphertext begin/end = packet begin/end (with generic depacketizer) Those answers would be appreciably more complicated and codec-dependent if we try to develop an SIDU approach as well as SFrame/SPacket. Thus my hope of ruling it out of scope. --RLB On Tue, Nov 16, 2021 at 1:51 PM Justin Uberti < juberti@alphaexplorationco.com> wrote: > Richard, when you talk about "units" here, are you referring to things > coming out of the codec? or the RTP packetizer for said codec? > > The recent IETF meeting ended with some confusion as to this specific > question and it would be good for us on this list to make sure we're all in > alignment. > > On Tue, Sep 7, 2021 at 12:46 PM Richard Barnes wrote: > >> I'm not totally sure what you mean by "spatial frames" here; looks like >> the notion varies some by codec. Assuming "spatial frames" are frames in >> the sense of "something that comes out of depacketizater", I think we're >> probably on the same page. >> >> Maybe it would be clearer to state the proposal as: Encryption is done in >> units of whole RTP payloads. One payload for SPacket; all payloads in the >> frame for SFrame. We would not support cases where an encrypted unit would >> span a partial RTP payload. For example: >> >> NOT OK >> Payload 1: First part of SFrame unit A >> Payload 2: Second part of A, first part of B >> Payload 3: Second part of B >> >> OK >> Payload 1: SFrame unit A >> Payload 2: First part of Sframe unit B >> Payload 3: Second part of B >> >> Does that line up with what you have in mind? >> >> --Richard >> >> On Mon, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo < >> sergio.garcia.murillo@cosmosoftware.io> wrote: >> >>> Hi Richard, >>> >>> Just one minor comment, the "media frames", should be spatial frames if >>> SVC is used so an SFU is able to not forward all spatial layers to the >>> receiver. Apart from that, I am ok with removing "SIDUs" from the scope. >>> >>> Best regards >>> Sergio >>> >>> On Thu, Sep 2, 2021 at 10:20 PM Richard Barnes wrote: >>> >>>> Hi folks, >>>> >>>> I'd like to see if we can agree to limit our scope a bit. There has >>>> been discussion of multiple levels at which SFrame could be applied: >>>> >>>> * "SFrame" - Whole media frames >>>> * "SPacket" - Individual RTP media payloads >>>> * "SIDU" - Some codec-specific "independently decodeable units" >>>> >>>> I'd like to propose that we take "SIDU" off of the table, but keep the >>>> other two. >>>> >>>> It seems like SFrame and SPacket both have strengths in certain >>>> scenarios (depending on how you want to trade off bandwidth vs. >>>> complexity), but they're both pretty straightforward in terms of how they >>>> integrate with the media processing pipeline. In particular, they don't >>>> have any codec-dependence. SIDU, by contrast, seems like a world of pain. >>>> It requires that the encryption scheme be entangled with the codec, which >>>> requires special per-codec integration logic in the specifications. And >>>> the bandwidth gains for all that complexity are not that large. >>>> >>>> Is there anyone here who feels that SIDU is something this group needs >>>> to spend time specifying? >>>> >>>> --Richard >>>> -- >>>> Sframe mailing list >>>> Sframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sframe >>>> >>> -- >> Sframe mailing list >> Sframe@ietf.org >> https://www.ietf.org/mailman/listinfo/sframe >> > --00000000000084733005d0eeac53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Specifically, I mean the things that are AEAD-encrypt= ed.

My mental model is that there are two movi= ng parts here:
1. A general SFrame encapsulation, defined in = this group, that takes a "unit" of media data and encrypts it wit= h an AEAD cipher
2. One or more ways to apply that encapsulat= ion to a real-time media stream.

Since AEADs deal = with discrete quantities of data and not streams, one of the things (2) has= to define is how to divide a media stream up into units that are fed into = the SFrame encap/decap algorithms.=C2=A0 (In other words, between which lay= ers in the media stack you put in the SFrame layer.)=C2=A0 And on decode, y= ou need a way for the receiver to recognize when SFrame ciphertexts begin a= nd end.

For SFrame and SPacket, those answers = are pretty clear:
* For SPacket: SFrame goes between packetiz= ation and SRTP; ciphertext begin/end =3D packet begin/end
* F= or SFrame: SFrame goes between encoding and packetization; ciphertext begin= /end =3D packet begin/end (with generic depacketizer)

<= div>Those answers would be appreciably more complicated and codec-dependent= if we try to develop an SIDU approach as well as SFrame/SPacket.=C2=A0 Thu= s my hope of ruling it out of scope.

--RLB

On Tue, Nov 16, 2021 at 1:51 PM Justin Uberti <juberti@alphaexplorationco.com> wrote:
R= ichard, when you talk about "units" here, are you referring to th= ings coming out of the codec? or the RTP packetizer for said codec?
The recent IETF meeting ended with some confusion as to this sp= ecific question and it would be good for us on this list to make sure we= 9;re all in alignment.

On Tue, Sep 7, 2021 at 12:46 PM Richard Barne= s <rlb@ipv.sx> wr= ote:
I'm not totally sure what you mean by "spatial frames&q= uot; here; looks like the notion varies some by codec.=C2=A0 Assuming "= ;spatial frames" are frames in the sense of "something that comes= out of depacketizater", I think we're probably on the same page.<= /div>

Maybe it would be clearer to state the proposal as= : Encryption is done in units of whole RTP payloads.=C2=A0 One payload for = SPacket; all payloads in the frame for SFrame.=C2=A0 We would not support c= ases where an encrypted unit would span a partial RTP payload.=C2=A0 For ex= ample:

NOT OK
Payload 1: First p= art of SFrame unit A
Payload 2: Second part of A, first part = of B
Payload 3: Second part of B

OK
<= /div>
Payload 1: SFrame unit A
Payload 2: First part of Sfram= e unit B
Payload 3: Second part of B

=
Does that line up with what you have in mind?

--Rich= ard

On Mon, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo <serg= io.garcia.murillo@cosmosoftware.io> wrote:
Hi Richard,

Just one minor comment, the "media frames", should be spat= ial frames if SVC is used so an SFU is able to not forward all spatial laye= rs to the receiver. Apart from that, I am ok with removing "SIDUs"= ;=C2=A0from the scope.

Best regards
Serg= io

On Thu, Sep 2, 2021 at 10:20 PM Richard Barnes <rlb@ipv.sx> wrote:
Hi folks,
I'd like to see if we can agree to limit our scope a bit.=C2=A0 There = has been discussion of multiple levels at which SFrame could be applied:
* "SFrame" - Whole media frames
* "SPacket" - I= ndividual RTP media payloads
* "SIDU" - Some codec-specific &q= uot;independently decodeable units"

I'd like to propose tha= t we take "SIDU" off of the table, but keep the other two.
It seems like SFrame and SPacket both have strengths in certain scenarios = (depending on how you want to trade off bandwidth vs. complexity), but they= 're both pretty straightforward in terms of how they integrate with the= media processing pipeline.=C2=A0 In particular, they don't have any co= dec-dependence.=C2=A0 SIDU, by contrast, seems like a world of pain.=C2=A0 = It requires that the encryption scheme be entangled with the codec, which r= equires special per-codec integration logic in the specifications.=C2=A0 An= d the bandwidth gains for all that complexity are not that large.

Is= there anyone here who feels that SIDU is something this group needs to spe= nd time specifying?

--Richard
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000084733005d0eeac53-- From nobody Tue Nov 16 13:35:47 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C48F3A09C6 for ; Tue, 16 Nov 2021 13:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20210112.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9e6_ytX_wcN for ; Tue, 16 Nov 2021 13:35:41 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41E23A09A3 for ; Tue, 16 Nov 2021 13:35:40 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id p4so361869qkm.7 for ; Tue, 16 Nov 2021 13:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H27BJBY/JWuIYnAHh4JfVlQQmeMbZTKHMjbWCJmFK1c=; b=oY9BXLET9uXzqMJPGPAYdeD2K3H8U3SU9do0Emby1BvTOr58kWeRMTKgvgfgp4DzNk U3GHxc+wIIVKFkh9X/fZgDl68ZfIO+hjgxYeYe9Pt/NYMTgmOiq3UjDRS5Z4IEjGWD8K vyeQ6nUOjgxkFibC6E+UwdlbipzxL26vbqK2QzF0Gq57vk+K8wOodE0B8u+3t0fKaV3k DhlDN2OZHB8ZrNGdCTB0w0TxtkYB7SgnOVN5kN7TWrxN1VEZvC4BA+pQT+TtiN59Ov+6 FRkvf3HFioBBXN1f6UtS0yMeZXUdjHNipbUJ1xT4w9/NdXrNCKDWt4aCEot8QQX/vo5X 74BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H27BJBY/JWuIYnAHh4JfVlQQmeMbZTKHMjbWCJmFK1c=; b=XizE7nc4+8wZgpG8W/zJEzykw4oHbE/xUpi2uuN/ZTxqhmQhnwOH/t4yEhPu1a/Wt9 CKwP/nOREfRBR6VMD5wng3aftEZvIDewi7hmZ2co+f2/XcorbEOYOVxrJdmM4GBYMyl4 8SRxJdzuLORCfmz6SvqFW6i+aZDuF37ZDqKKve6+WlsdL83LWGbnnaD3rDYNYydGdz/d iIAUaxbzLZoQlXMh5xBvPvNzGwAgMKbYKOsfe6ymG2+A++2o7Bt2woKj/FO10c9Tgwbx jF3s7GTGkYumm/SCWH5bJ6/Istu3v/US3QqbipnzfB9LS5H+dIkdODU//utfID5/OoIF iFig== X-Gm-Message-State: AOAM530CgW1WpRcuTd7ot5m5ubLG7DF73xZrgpoIAPnu8odPnWMYSP+E wkOYfwVQs87rAQaetEWxsHzD4ditkT9u5trAsYL7Og== X-Google-Smtp-Source: ABdhPJwPOPn6d8osBFvWjtzjt8PRqQxi9CPMjTMcVMYOxwGzNO0FqEME+aUBQrdOsBReCP6pcH/Rh9PdjaMC5MrdoUA= X-Received: by 2002:a05:620a:3707:: with SMTP id de7mr8957217qkb.125.1637098537883; Tue, 16 Nov 2021 13:35:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 16 Nov 2021 16:35:26 -0500 Message-ID: To: Justin Uberti Cc: Sergio Garcia Murillo , sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000d0270205d0eeb43c" Archived-At: Subject: Re: [Sframe] Proposal: SFrame && SPacket && !SIDU X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2021 21:35:46 -0000 --000000000000d0270205d0eeb43c Content-Type: text/plain; charset="UTF-8" BTW, if there are going to be SFrame-relevant discussions at other WGs, it would be helpful if folks could post notice on this list. Maybe I'm the only one not really following other media WGs, but I missed whatever discussions at the recent IETF you're referencing. On Tue, Nov 16, 2021 at 4:33 PM Richard Barnes wrote: > Specifically, I mean the things that are AEAD-encrypted. > > My mental model is that there are two moving parts here: > 1. A general SFrame encapsulation, defined in this group, that takes a > "unit" of media data and encrypts it with an AEAD cipher > 2. One or more ways to apply that encapsulation to a real-time media > stream. > > Since AEADs deal with discrete quantities of data and not streams, one of > the things (2) has to define is how to divide a media stream up into units > that are fed into the SFrame encap/decap algorithms. (In other words, > between which layers in the media stack you put in the SFrame layer.) And > on decode, you need a way for the receiver to recognize when SFrame > ciphertexts begin and end. > > For SFrame and SPacket, those answers are pretty clear: > * For SPacket: SFrame goes between packetization and SRTP; ciphertext > begin/end = packet begin/end > * For SFrame: SFrame goes between encoding and packetization; ciphertext > begin/end = packet begin/end (with generic depacketizer) > > Those answers would be appreciably more complicated and codec-dependent if > we try to develop an SIDU approach as well as SFrame/SPacket. Thus my hope > of ruling it out of scope. > > --RLB > > On Tue, Nov 16, 2021 at 1:51 PM Justin Uberti < > juberti@alphaexplorationco.com> wrote: > >> Richard, when you talk about "units" here, are you referring to things >> coming out of the codec? or the RTP packetizer for said codec? >> >> The recent IETF meeting ended with some confusion as to this specific >> question and it would be good for us on this list to make sure we're all in >> alignment. >> >> On Tue, Sep 7, 2021 at 12:46 PM Richard Barnes wrote: >> >>> I'm not totally sure what you mean by "spatial frames" here; looks like >>> the notion varies some by codec. Assuming "spatial frames" are frames in >>> the sense of "something that comes out of depacketizater", I think we're >>> probably on the same page. >>> >>> Maybe it would be clearer to state the proposal as: Encryption is done >>> in units of whole RTP payloads. One payload for SPacket; all payloads in >>> the frame for SFrame. We would not support cases where an encrypted unit >>> would span a partial RTP payload. For example: >>> >>> NOT OK >>> Payload 1: First part of SFrame unit A >>> Payload 2: Second part of A, first part of B >>> Payload 3: Second part of B >>> >>> OK >>> Payload 1: SFrame unit A >>> Payload 2: First part of Sframe unit B >>> Payload 3: Second part of B >>> >>> Does that line up with what you have in mind? >>> >>> --Richard >>> >>> On Mon, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo < >>> sergio.garcia.murillo@cosmosoftware.io> wrote: >>> >>>> Hi Richard, >>>> >>>> Just one minor comment, the "media frames", should be spatial frames if >>>> SVC is used so an SFU is able to not forward all spatial layers to the >>>> receiver. Apart from that, I am ok with removing "SIDUs" from the scope. >>>> >>>> Best regards >>>> Sergio >>>> >>>> On Thu, Sep 2, 2021 at 10:20 PM Richard Barnes wrote: >>>> >>>>> Hi folks, >>>>> >>>>> I'd like to see if we can agree to limit our scope a bit. There has >>>>> been discussion of multiple levels at which SFrame could be applied: >>>>> >>>>> * "SFrame" - Whole media frames >>>>> * "SPacket" - Individual RTP media payloads >>>>> * "SIDU" - Some codec-specific "independently decodeable units" >>>>> >>>>> I'd like to propose that we take "SIDU" off of the table, but keep the >>>>> other two. >>>>> >>>>> It seems like SFrame and SPacket both have strengths in certain >>>>> scenarios (depending on how you want to trade off bandwidth vs. >>>>> complexity), but they're both pretty straightforward in terms of how they >>>>> integrate with the media processing pipeline. In particular, they don't >>>>> have any codec-dependence. SIDU, by contrast, seems like a world of pain. >>>>> It requires that the encryption scheme be entangled with the codec, which >>>>> requires special per-codec integration logic in the specifications. And >>>>> the bandwidth gains for all that complexity are not that large. >>>>> >>>>> Is there anyone here who feels that SIDU is something this group needs >>>>> to spend time specifying? >>>>> >>>>> --Richard >>>>> -- >>>>> Sframe mailing list >>>>> Sframe@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sframe >>>>> >>>> -- >>> Sframe mailing list >>> Sframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/sframe >>> >> --000000000000d0270205d0eeb43c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BTW, if there are going to be SFrame-relevant discuss= ions at other WGs, it would be helpful if folks could post notice on this l= ist.=C2=A0 Maybe I'm the only one not really following other media WGs,= but I missed whatever discussions at the recent IETF you're referencin= g.


On Tue, Nov 16, 2021 at 4:33 PM Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx">rlb@ipv.sx> wrote:
Specifically, = I mean the things that are AEAD-encrypted.

My = mental model is that there are two moving parts here:
1. A ge= neral SFrame encapsulation, defined in this group, that takes a "unit&= quot; of media data and encrypts it with an AEAD cipher
2. On= e or more ways to apply that encapsulation to a real-time media stream.

Since AEADs deal with discrete quantities of data and= not streams, one of the things (2) has to define is how to divide a media = stream up into units that are fed into the SFrame encap/decap algorithms.= =C2=A0 (In other words, between which layers in the media stack you put in = the SFrame layer.)=C2=A0 And on decode, you need a way for the receiver to = recognize when SFrame ciphertexts begin and end.

For SFrame and SPacket, those answers are pretty clear:
* = For SPacket: SFrame goes between packetization and SRTP; ciphertext begin/e= nd =3D packet begin/end
* For SFrame: SFrame goes between enc= oding and packetization; ciphertext begin/end =3D packet begin/end (with ge= neric depacketizer)

Those answers would be appreci= ably more complicated and codec-dependent if we try to develop an SIDU appr= oach as well as SFrame/SPacket.=C2=A0 Thus my hope of ruling it out of scop= e.

--RLB

On Tue, Nov 16, 2021 at 1:51 PM = Justin Uberti <juberti@alphaexplorationco.com> wrote:
Richard, when yo= u talk about "units" here, are you referring to things coming out= of the codec? or the RTP packetizer for said codec?

The= recent IETF meeting ended with some confusion as to this specific question= and it would be good for us on this list to make sure we're all in ali= gnment.

On Tue, Sep 7, 2021 at 12:46 PM Richard Barnes <rlb@ipv.sx> wrote:
I'= m not totally sure what you mean by "spatial frames" here; looks = like the notion varies some by codec.=C2=A0 Assuming "spatial frames&q= uot; are frames in the sense of "something that comes out of depacketi= zater", I think we're probably on the same page.

Maybe it would be clearer to state the proposal as: Encryption is d= one in units of whole RTP payloads.=C2=A0 One payload for SPacket; all payl= oads in the frame for SFrame.=C2=A0 We would not support cases where an enc= rypted unit would span a partial RTP payload.=C2=A0 For example:
<= div>
NOT OK
Payload 1: First part of SFrame uni= t A
Payload 2: Second part of A, first part of B
Pa= yload 3: Second part of B

OK
Payload= 1: SFrame unit A
Payload 2: First part of Sframe unit B
Payload 3: Second part of B

Does that li= ne up with what you have in mind?

--Richard

On M= on, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo <sergio.garcia.murillo= @cosmosoftware.io> wrote:
Hi Richard,

Just one m= inor comment, the "media frames", should be spatial frames if SVC= is used so an SFU is able to not forward all spatial layers to the receive= r. Apart from that, I am ok with removing "SIDUs"=C2=A0from the s= cope.

Best regards
Sergio
On Thu, S= ep 2, 2021 at 10:20 PM Richard Barnes <rlb@ipv.sx> wrote:
Hi folks,

I'd like to = see if we can agree to limit our scope a bit.=C2=A0 There has been discussi= on of multiple levels at which SFrame could be applied:

* "SFra= me" - Whole media frames
* "SPacket" - Individual RTP med= ia payloads
* "SIDU" - Some codec-specific "independently= decodeable units"

I'd like to propose that we take "S= IDU" off of the table, but keep the other two.

It seems like SF= rame and SPacket both have strengths in certain scenarios (depending on how= you want to trade off bandwidth vs. complexity), but they're both pret= ty straightforward in terms of how they integrate with the media processing= pipeline.=C2=A0 In particular, they don't have any codec-dependence.= =C2=A0 SIDU, by contrast, seems like a world of pain.=C2=A0 It requires tha= t the encryption scheme be entangled with the codec, which requires special= per-codec integration logic in the specifications.=C2=A0 And the bandwidth= gains for all that complexity are not that large.

Is there anyone h= ere who feels that SIDU is something this group needs to spend time specify= ing?

--Richard
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000d0270205d0eeb43c-- From nobody Tue Nov 16 14:21:59 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5B23A09FA for ; Tue, 16 Nov 2021 14:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alphaexplorationco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kn3L6Mz59VU for ; Tue, 16 Nov 2021 14:21:52 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995503A09F7 for ; Tue, 16 Nov 2021 14:21:52 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id s139so1662359oie.13 for ; Tue, 16 Nov 2021 14:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphaexplorationco.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QaVLKWH1Kp4+Q3/xYXdGhhGTCF1yTP9dgB8B38kJ18Y=; b=gB3BOw1l/4L5c95DvAxBDhLygaS6bWLR0GH1EMgWRGLvUTMDnMUlTSsuJmMb3sxsOu 7OAJHPR34yKaxpuRSTvcxZDxOLwLSY16nDSOSfpAG4SFg1I1/EbsSRCwgme1dBoMQJIj CXDwaiT1hJADo/j1Mrz3H7qh7R06AeWg6Ys40ZCCvk4dpej4AzRbU3zn9NOzqPIMNHlF 4S66HEDorBMUwa7vWgnZ+T3Mi17E8r8asUkurN0z2XA62E6NxFDnfGuXCkW0eMs6FAJu Gkwn77zyyMawC50S1mnlAD9DTP3LjfPO2rHZerl9t2ISiXB2zeILX2PuwAMi2DC99L7s bEgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QaVLKWH1Kp4+Q3/xYXdGhhGTCF1yTP9dgB8B38kJ18Y=; b=g8nnCI+1+TFyR5qOyP5vZsGL8Pa3v1GVMG80bgqt1Q62p5FddyrJ1HycZmC4iUfnPF ONZJhm/+uN2Nb3hl739w3eC85Sje0Sax7T24O37qKzT7ycgQimZ61WppDzApqhrHVg6R SyV744SX/rWrcVqmCyF495+th5ItL6FhaaChV7se4k9KyHqDYWa+R+e45JULvTxG0mBn LTOR/4dAjxAZDF40coZeG7AwFeKHggFE8wklB5zyuqNV2FahI6ncgS3geESGXdyqZdt4 qh5mxCBiyPgPVilPe71JESuBgbmVc+u1MlvvkLus+ReC9NE4mVWxXBPUcTec2eP0lIKK HEQA== X-Gm-Message-State: AOAM531STh5lx+mQesCN6GAi/Fs72U7fMk9u8Dx1gLDMOYnvNNOY6+au p10CbfLbFsw74rkib4q1DLTWV2Mtn/V2JCXh/ewcjw== X-Google-Smtp-Source: ABdhPJz/bEh7y1jvKFr8vmd0QgQzZV1I8EZpQJUgwwhdglk3dLpUzmG+/HJT+623FA0RBcVg4s986b1k/CfzHGCd4Ds= X-Received: by 2002:a05:6808:53:: with SMTP id v19mr23494459oic.8.1637101310656; Tue, 16 Nov 2021 14:21:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Tue, 16 Nov 2021 14:21:40 -0800 Message-ID: To: Richard Barnes Cc: Sergio Garcia Murillo , sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000001555c405d0ef5aae" Archived-At: Subject: Re: [Sframe] Proposal: SFrame && SPacket && !SIDU X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2021 22:21:58 -0000 --0000000000001555c405d0ef5aae Content-Type: text/plain; charset="UTF-8" On Tue, Nov 16, 2021 at 1:33 PM Richard Barnes wrote: > Specifically, I mean the things that are AEAD-encrypted. > > My mental model is that there are two moving parts here: > 1. A general SFrame encapsulation, defined in this group, that takes a > "unit" of media data and encrypts it with an AEAD cipher > 2. One or more ways to apply that encapsulation to a real-time media > stream. > > Since AEADs deal with discrete quantities of data and not streams, one of > the things (2) has to define is how to divide a media stream up into units > that are fed into the SFrame encap/decap algorithms. (In other words, > between which layers in the media stack you put in the SFrame layer.) And > on decode, you need a way for the receiver to recognize when SFrame > ciphertexts begin and end. > > For SFrame and SPacket, those answers are pretty clear: > * For SPacket: SFrame goes between packetization and SRTP; ciphertext > begin/end = packet begin/end > * For SFrame: SFrame goes between encoding and packetization; ciphertext > begin/end = packet begin/end (with generic depacketizer) > Makes sense, but these are two very different things (although I suppose they may largely reduce to the same thing in trivial cases such as G.711). For one, SFrame requires defining some sort of generic packetization, whereas SPacket seems like it would reuse existing RTP packetization and dependencies. > > Those answers would be appreciably more complicated and codec-dependent if > we try to develop an SIDU approach as well as SFrame/SPacket. Thus my hope > of ruling it out of scope. > While I appreciate the desire to cut scope, to me SIDU is just a slight refinement of SFrame. IDUs are frames, after all. > > --RLB > > On Tue, Nov 16, 2021 at 1:51 PM Justin Uberti < > juberti@alphaexplorationco.com> wrote: > >> Richard, when you talk about "units" here, are you referring to things >> coming out of the codec? or the RTP packetizer for said codec? >> >> The recent IETF meeting ended with some confusion as to this specific >> question and it would be good for us on this list to make sure we're all in >> alignment. >> >> On Tue, Sep 7, 2021 at 12:46 PM Richard Barnes wrote: >> >>> I'm not totally sure what you mean by "spatial frames" here; looks like >>> the notion varies some by codec. Assuming "spatial frames" are frames in >>> the sense of "something that comes out of depacketizater", I think we're >>> probably on the same page. >>> >>> Maybe it would be clearer to state the proposal as: Encryption is done >>> in units of whole RTP payloads. One payload for SPacket; all payloads in >>> the frame for SFrame. We would not support cases where an encrypted unit >>> would span a partial RTP payload. For example: >>> >>> NOT OK >>> Payload 1: First part of SFrame unit A >>> Payload 2: Second part of A, first part of B >>> Payload 3: Second part of B >>> >>> OK >>> Payload 1: SFrame unit A >>> Payload 2: First part of Sframe unit B >>> Payload 3: Second part of B >>> >>> Does that line up with what you have in mind? >>> >>> --Richard >>> >>> On Mon, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo < >>> sergio.garcia.murillo@cosmosoftware.io> wrote: >>> >>>> Hi Richard, >>>> >>>> Just one minor comment, the "media frames", should be spatial frames if >>>> SVC is used so an SFU is able to not forward all spatial layers to the >>>> receiver. Apart from that, I am ok with removing "SIDUs" from the scope. >>>> >>>> Best regards >>>> Sergio >>>> >>>> On Thu, Sep 2, 2021 at 10:20 PM Richard Barnes wrote: >>>> >>>>> Hi folks, >>>>> >>>>> I'd like to see if we can agree to limit our scope a bit. There has >>>>> been discussion of multiple levels at which SFrame could be applied: >>>>> >>>>> * "SFrame" - Whole media frames >>>>> * "SPacket" - Individual RTP media payloads >>>>> * "SIDU" - Some codec-specific "independently decodeable units" >>>>> >>>>> I'd like to propose that we take "SIDU" off of the table, but keep the >>>>> other two. >>>>> >>>>> It seems like SFrame and SPacket both have strengths in certain >>>>> scenarios (depending on how you want to trade off bandwidth vs. >>>>> complexity), but they're both pretty straightforward in terms of how they >>>>> integrate with the media processing pipeline. In particular, they don't >>>>> have any codec-dependence. SIDU, by contrast, seems like a world of pain. >>>>> It requires that the encryption scheme be entangled with the codec, which >>>>> requires special per-codec integration logic in the specifications. And >>>>> the bandwidth gains for all that complexity are not that large. >>>>> >>>>> Is there anyone here who feels that SIDU is something this group needs >>>>> to spend time specifying? >>>>> >>>>> --Richard >>>>> -- >>>>> Sframe mailing list >>>>> Sframe@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sframe >>>>> >>>> -- >>> Sframe mailing list >>> Sframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/sframe >>> >> --0000000000001555c405d0ef5aae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 16, 2021 at 1:33 PM Richa= rd Barnes <rlb@ipv.sx> wrote:
Specifically, I mean the things that are AEAD-encrypted.
My mental model is that there are two moving parts here:
1. A general SFrame encapsulation, defined in this group, that take= s a "unit" of media data and encrypts it with an AEAD cipher
<= /div>
2. One or more ways to apply that encapsulation to a real-time me= dia stream.

Since AEADs deal with discrete quantit= ies of data and not streams, one of the things (2) has to define is how to = divide a media stream up into units that are fed into the SFrame encap/deca= p algorithms.=C2=A0 (In other words, between which layers in the media stac= k you put in the SFrame layer.)=C2=A0 And on decode, you need a way for the= receiver to recognize when SFrame ciphertexts begin and end.

For SFrame and SPacket, those answers are pretty clear:
=
* For SPacket: SFrame goes between packetization and SRTP; ciphe= rtext begin/end =3D packet begin/end
* For SFrame: SFrame goe= s between encoding and packetization; ciphertext begin/end =3D packet begin= /end (with generic depacketizer)

Makes sense, but these are two very different things (although I suppose = they may largely reduce to the same thing in trivial cases such as G.711). = For one, SFrame requires defining some sort of generic packetization, where= as SPacket seems like it would reuse existing RTP packetization and depende= ncies.
=C2=A0

Those answers would be appreciably= more complicated and codec-dependent if we try to develop an SIDU approach= as well as SFrame/SPacket.=C2=A0 Thus my hope of ruling it out of scope.

While I appreciate the desire to= cut scope, to me SIDU is just a slight refinement of SFrame. IDUs are fram= es, after all.

--RLB

On Tue, Nov 16, 2021 at 1:51= PM Justin Uberti <juberti@alphaexplorationco.com> wrote:
Richard, when= you talk about "units" here, are you referring to things coming = out of the codec? or the RTP packetizer for said codec?

= The recent IETF meeting ended with some confusion as to this specific quest= ion and it would be good for us on this list to make sure we're all in = alignment.

On Tue, Sep 7, 2021 at 12:46 PM Richard Barnes <rlb@ipv.sx> wrote:
I&= #39;m not totally sure what you mean by "spatial frames" here; lo= oks like the notion varies some by codec.=C2=A0 Assuming "spatial fram= es" are frames in the sense of "something that comes out of depac= ketizater", I think we're probably on the same page.
Maybe it would be clearer to state the proposal as: Encryption = is done in units of whole RTP payloads.=C2=A0 One payload for SPacket; all = payloads in the frame for SFrame.=C2=A0 We would not support cases where an= encrypted unit would span a partial RTP payload.=C2=A0 For example:

NOT OK
Payload 1: First part of SFrame= unit A
Payload 2: Second part of A, first part of B
Payload 3: Second part of B

OK
Pay= load 1: SFrame unit A
Payload 2: First part of Sframe unit B
<= /div>
Payload 3: Second part of B

Does tha= t line up with what you have in mind?

--Richard
=

= On Mon, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo <sergio.garcia.mur= illo@cosmosoftware.io> wrote:
Hi Richard,

Just o= ne minor comment, the "media frames", should be spatial frames if= SVC is used so an SFU is able to not forward all spatial layers to the rec= eiver. Apart from that, I am ok with removing "SIDUs"=C2=A0from t= he scope.

Best regards
Sergio

On Th= u, Sep 2, 2021 at 10:20 PM Richard Barnes <rlb@ipv.sx> wrote:
Hi folks,

I'd like= to see if we can agree to limit our scope a bit.=C2=A0 There has been disc= ussion of multiple levels at which SFrame could be applied:

* "= SFrame" - Whole media frames
* "SPacket" - Individual RTP= media payloads
* "SIDU" - Some codec-specific "independe= ntly decodeable units"

I'd like to propose that we take &qu= ot;SIDU" off of the table, but keep the other two.

It seems lik= e SFrame and SPacket both have strengths in certain scenarios (depending on= how you want to trade off bandwidth vs. complexity), but they're both = pretty straightforward in terms of how they integrate with the media proces= sing pipeline.=C2=A0 In particular, they don't have any codec-dependenc= e.=C2=A0 SIDU, by contrast, seems like a world of pain.=C2=A0 It requires t= hat the encryption scheme be entangled with the codec, which requires speci= al per-codec integration logic in the specifications.=C2=A0 And the bandwid= th gains for all that complexity are not that large.

Is there anyone= here who feels that SIDU is something this group needs to spend time speci= fying?

--Richard
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--0000000000001555c405d0ef5aae-- From nobody Tue Nov 16 14:22:49 2021 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9E93A0AB0 for ; Tue, 16 Nov 2021 14:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alphaexplorationco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL6OLKNjfBLh for ; Tue, 16 Nov 2021 14:22:42 -0800 (PST) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D2A3A0A6D for ; Tue, 16 Nov 2021 14:22:41 -0800 (PST) Received: by mail-oi1-x232.google.com with SMTP id bj13so1787487oib.4 for ; Tue, 16 Nov 2021 14:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphaexplorationco.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zk3QpcDJLSlrS4xNVJ0jpaISIJ1ueOQYqg8L/10uY/c=; b=StVCepyk3NfHoV04yYQezJmqHuweHhXz3lHqzpRL902tDnBNSpdhoPrIpWgpKrhcsy FLl5fAZFpiZd6XRtUrOHQxDbwW7tpBodAaadE13qTZSAuQpnd0tvI1dCoFwLv5HCqH45 eqJuqIyYWICLLw7VwziYaoWJt5yOYRGmBF+Ei0UxkDubk0YoHntedBq7BLgrZMoBPlj/ j8b31T4gdPjQXtNxKwbkiIU9AeZ62AaLwBWyhUfr87kZ8GR4kopdNdJABYsQShVZ6PrF hf/xDgn8WNNKDesD9uV+JE52Fft/hS+8NmFrE/wPvTj6HsENzv38P5Hlg89MjulWOxap j3VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zk3QpcDJLSlrS4xNVJ0jpaISIJ1ueOQYqg8L/10uY/c=; b=1pV4fKwvJRSfxqmLCdse1P0s9522ErAC+EntLrJ5HokDrD9fOq/gCr/EYLY1pdplmc mFAJe4r8FgxQhLrpsP/ouJNEVtDxo5khlTu+8uYw4X72mCDJ7NV/S6cyQGBObaaDyJ8a p0v3vNe9fYbrBeDrkewjCDPW4lPbQW3pJP/B/q7kZMcEgDhP6y9LvGCDbDxBig9Im6Vd tkVgfPV9P8g/RSofERxQBEtMVkzotvLhBjllY5EYQGESRX3c4dC3YfdQgHd+tTfj0yPj xzu2AO/G2h8/Iu2Pgmb/H70YxPi0bezd4sXkT93kZwNkfvilSsbOp+NzT9rsrDYdJ/Gq 4EPg== X-Gm-Message-State: AOAM533f6lDJSi+69uuBnHJhjq/plWEUCMjgwvO80eQeRsHy+l8OM0wf WLxXt0YvhXFJzg3P+LvzmxkwKaguzbuVg0PSL0Xf7Q== X-Google-Smtp-Source: ABdhPJwDVMO2Bucw+DPr21rqAxaHacp7bLjXnV+0F70dT/+LrLLjV9CYfqh6QiUsncQS+LIb/db0CJSdMs5n4cjEmSw= X-Received: by 2002:aca:afc6:: with SMTP id y189mr30600552oie.46.1637101359869; Tue, 16 Nov 2021 14:22:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Tue, 16 Nov 2021 14:22:29 -0800 Message-ID: To: Richard Barnes Cc: Sergio Garcia Murillo , sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000004466705d0ef5d9e" Archived-At: Subject: Re: [Sframe] Proposal: SFrame && SPacket && !SIDU X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2021 22:22:48 -0000 --00000000000004466705d0ef5d9e Content-Type: text/plain; charset="UTF-8" Here I am referring to the discussion in avtcore surrounding https://datatracker.ietf.org/doc/html/draft-murillo-avtcore-multi-codec-payload-format . On Tue, Nov 16, 2021 at 1:35 PM Richard Barnes wrote: > BTW, if there are going to be SFrame-relevant discussions at other WGs, it > would be helpful if folks could post notice on this list. Maybe I'm the > only one not really following other media WGs, but I missed whatever > discussions at the recent IETF you're referencing. > > > On Tue, Nov 16, 2021 at 4:33 PM Richard Barnes wrote: > >> Specifically, I mean the things that are AEAD-encrypted. >> >> My mental model is that there are two moving parts here: >> 1. A general SFrame encapsulation, defined in this group, that takes a >> "unit" of media data and encrypts it with an AEAD cipher >> 2. One or more ways to apply that encapsulation to a real-time media >> stream. >> >> Since AEADs deal with discrete quantities of data and not streams, one of >> the things (2) has to define is how to divide a media stream up into units >> that are fed into the SFrame encap/decap algorithms. (In other words, >> between which layers in the media stack you put in the SFrame layer.) And >> on decode, you need a way for the receiver to recognize when SFrame >> ciphertexts begin and end. >> >> For SFrame and SPacket, those answers are pretty clear: >> * For SPacket: SFrame goes between packetization and SRTP; ciphertext >> begin/end = packet begin/end >> * For SFrame: SFrame goes between encoding and packetization; ciphertext >> begin/end = packet begin/end (with generic depacketizer) >> >> Those answers would be appreciably more complicated and codec-dependent >> if we try to develop an SIDU approach as well as SFrame/SPacket. Thus my >> hope of ruling it out of scope. >> >> --RLB >> >> On Tue, Nov 16, 2021 at 1:51 PM Justin Uberti < >> juberti@alphaexplorationco.com> wrote: >> >>> Richard, when you talk about "units" here, are you referring to things >>> coming out of the codec? or the RTP packetizer for said codec? >>> >>> The recent IETF meeting ended with some confusion as to this specific >>> question and it would be good for us on this list to make sure we're all in >>> alignment. >>> >>> On Tue, Sep 7, 2021 at 12:46 PM Richard Barnes wrote: >>> >>>> I'm not totally sure what you mean by "spatial frames" here; looks like >>>> the notion varies some by codec. Assuming "spatial frames" are frames in >>>> the sense of "something that comes out of depacketizater", I think we're >>>> probably on the same page. >>>> >>>> Maybe it would be clearer to state the proposal as: Encryption is done >>>> in units of whole RTP payloads. One payload for SPacket; all payloads in >>>> the frame for SFrame. We would not support cases where an encrypted unit >>>> would span a partial RTP payload. For example: >>>> >>>> NOT OK >>>> Payload 1: First part of SFrame unit A >>>> Payload 2: Second part of A, first part of B >>>> Payload 3: Second part of B >>>> >>>> OK >>>> Payload 1: SFrame unit A >>>> Payload 2: First part of Sframe unit B >>>> Payload 3: Second part of B >>>> >>>> Does that line up with what you have in mind? >>>> >>>> --Richard >>>> >>>> On Mon, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo < >>>> sergio.garcia.murillo@cosmosoftware.io> wrote: >>>> >>>>> Hi Richard, >>>>> >>>>> Just one minor comment, the "media frames", should be spatial frames >>>>> if SVC is used so an SFU is able to not forward all spatial layers to the >>>>> receiver. Apart from that, I am ok with removing "SIDUs" from the scope. >>>>> >>>>> Best regards >>>>> Sergio >>>>> >>>>> On Thu, Sep 2, 2021 at 10:20 PM Richard Barnes wrote: >>>>> >>>>>> Hi folks, >>>>>> >>>>>> I'd like to see if we can agree to limit our scope a bit. There has >>>>>> been discussion of multiple levels at which SFrame could be applied: >>>>>> >>>>>> * "SFrame" - Whole media frames >>>>>> * "SPacket" - Individual RTP media payloads >>>>>> * "SIDU" - Some codec-specific "independently decodeable units" >>>>>> >>>>>> I'd like to propose that we take "SIDU" off of the table, but keep >>>>>> the other two. >>>>>> >>>>>> It seems like SFrame and SPacket both have strengths in certain >>>>>> scenarios (depending on how you want to trade off bandwidth vs. >>>>>> complexity), but they're both pretty straightforward in terms of how they >>>>>> integrate with the media processing pipeline. In particular, they don't >>>>>> have any codec-dependence. SIDU, by contrast, seems like a world of pain. >>>>>> It requires that the encryption scheme be entangled with the codec, which >>>>>> requires special per-codec integration logic in the specifications. And >>>>>> the bandwidth gains for all that complexity are not that large. >>>>>> >>>>>> Is there anyone here who feels that SIDU is something this group >>>>>> needs to spend time specifying? >>>>>> >>>>>> --Richard >>>>>> -- >>>>>> Sframe mailing list >>>>>> Sframe@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sframe >>>>>> >>>>> -- >>>> Sframe mailing list >>>> Sframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sframe >>>> >>> --00000000000004466705d0ef5d9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here I am referring to the discussion in avtcore surroundi= ng https://datatracker.ietf.org/doc/html/draft-muri= llo-avtcore-multi-codec-payload-format.

On Tue, Nov 16, 2021 at 1:35 PM = Richard Barnes <rlb@ipv.sx> wrote:<= br>
BTW, if there are going to be SFrame-relevant discussions at other WG= s, it would be helpful if folks could post notice on this list.=C2=A0 Maybe= I'm the only one not really following other media WGs, but I missed wh= atever discussions at the recent IETF you're referencing.

On Tue, Nov 16, 2021 at 4:33 PM Richard Barnes <rlb@ipv.sx> wrote:
Specifically= , I mean the things that are AEAD-encrypted.

M= y mental model is that there are two moving parts here:
1. A = general SFrame encapsulation, defined in this group, that takes a "uni= t" of media data and encrypts it with an AEAD cipher
2. = One or more ways to apply that encapsulation to a real-time media stream.

Since AEADs deal with discrete quantities of data a= nd not streams, one of the things (2) has to define is how to divide a medi= a stream up into units that are fed into the SFrame encap/decap algorithms.= =C2=A0 (In other words, between which layers in the media stack you put in = the SFrame layer.)=C2=A0 And on decode, you need a way for the receiver to = recognize when SFrame ciphertexts begin and end.

For SFrame and SPacket, those answers are pretty clear:
* = For SPacket: SFrame goes between packetization and SRTP; ciphertext begin/e= nd =3D packet begin/end
* For SFrame: SFrame goes between enc= oding and packetization; ciphertext begin/end =3D packet begin/end (with ge= neric depacketizer)

Those answers would be appreci= ably more complicated and codec-dependent if we try to develop an SIDU appr= oach as well as SFrame/SPacket.=C2=A0 Thus my hope of ruling it out of scop= e.

--RLB

On Tue, Nov 16, 2021 at 1:51 PM = Justin Uberti <juberti@alphaexplorationco.com> wrote:
Richard, when yo= u talk about "units" here, are you referring to things coming out= of the codec? or the RTP packetizer for said codec?

The= recent IETF meeting ended with some confusion as to this specific question= and it would be good for us on this list to make sure we're all in ali= gnment.

On Tue, Sep 7, 2021 at 12:46 PM Richard Barnes <rlb@ipv.sx> wrote:
I'= m not totally sure what you mean by "spatial frames" here; looks = like the notion varies some by codec.=C2=A0 Assuming "spatial frames&q= uot; are frames in the sense of "something that comes out of depacketi= zater", I think we're probably on the same page.

Maybe it would be clearer to state the proposal as: Encryption is d= one in units of whole RTP payloads.=C2=A0 One payload for SPacket; all payl= oads in the frame for SFrame.=C2=A0 We would not support cases where an enc= rypted unit would span a partial RTP payload.=C2=A0 For example:
<= div>
NOT OK
Payload 1: First part of SFrame uni= t A
Payload 2: Second part of A, first part of B
Pa= yload 3: Second part of B

OK
Payload= 1: SFrame unit A
Payload 2: First part of Sframe unit B
Payload 3: Second part of B

Does that li= ne up with what you have in mind?

--Richard

On M= on, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo <sergio.garcia.murillo= @cosmosoftware.io> wrote:
Hi Richard,

Just one m= inor comment, the "media frames", should be spatial frames if SVC= is used so an SFU is able to not forward all spatial layers to the receive= r. Apart from that, I am ok with removing "SIDUs"=C2=A0from the s= cope.

Best regards
Sergio
On Thu, S= ep 2, 2021 at 10:20 PM Richard Barnes <rlb@ipv.sx> wrote:
Hi folks,

I'd like to = see if we can agree to limit our scope a bit.=C2=A0 There has been discussi= on of multiple levels at which SFrame could be applied:

* "SFra= me" - Whole media frames
* "SPacket" - Individual RTP med= ia payloads
* "SIDU" - Some codec-specific "independently= decodeable units"

I'd like to propose that we take "S= IDU" off of the table, but keep the other two.

It seems like SF= rame and SPacket both have strengths in certain scenarios (depending on how= you want to trade off bandwidth vs. complexity), but they're both pret= ty straightforward in terms of how they integrate with the media processing= pipeline.=C2=A0 In particular, they don't have any codec-dependence.= =C2=A0 SIDU, by contrast, seems like a world of pain.=C2=A0 It requires tha= t the encryption scheme be entangled with the codec, which requires special= per-codec integration logic in the specifications.=C2=A0 And the bandwidth= gains for all that complexity are not that large.

Is there anyone h= ere who feels that SIDU is something this group needs to spend time specify= ing?

--Richard
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000004466705d0ef5d9e--