Re: [AVTCORE] RTP Header Extension Encryption

[Harald Alvestrand <[e-mail]>]

I think this scope is called "TRANSPORT" when talking about the bundle 
category of SDP extensions in general.

On 9/11/20 9:00 PM, Bernard Aboba wrote:
> Paul said:
>
> "Can you please clarify the scope for which you want the encryption to be
> consistent? Above you variously mention all MIDs and all m-lines. I'm
> concerned with what "all" applies to.
>
> I think I can agree if you are talking about "all within a bundle
> group". Anything broader has major problems."
>
> [BA] Thanks for pointing this out.
>
> Mixing unencrypted and encrypted RTP header extensions within a bundle 
> group is problematic because all of the RTP packets arrive on the same 
> port, and the receiver needs to know the MID (which could be 
> encrypted) in order to figure out which packets should have encrypted 
> and unencrypted RTP header extensions.  But if you have different 
> bundle groups, then it is possible for each group to have different 
> settings (e.g. encrypted RTP header extensions on one group and 
> unencrypted RTP header extensions on another bundle group) without 
> that problem arising.  So this is an argument only for consistency 
> within each bundle group, not for requiring all bundle groups to have 
> the same setting.
>
> On Fri, Sep 11, 2020 at 11:31 AM Paul Kyzivat <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Bernard,
>
>     On 9/10/20 5:42 PM, Bernard Aboba wrote:
>
>     > There was also some discussion of whether encryption could be
>     negotiated
>     > per m-line or just a blanket on/off for all m-lines. IMHO,
>     negotiating
>     > encryption per m-line is more complex, particularly if we also
>     choose to
>     > extend the scope of encryption, so as to cover the ID field (e.g.
>     > encrypt the entire RTP header extension block). Extending the
>     scope of
>     > encryption means that the entire MID header extension (including
>     the ID
>     > field) could be encrypted.
>     >
>     > Having encryption on for some m-lines and off for other m-lines
>     seems
>     > like it would open up a number of corner cases.  If some MIDs
>     have RTP
>     > header extensions encrypted and others do not, how does an RTP
>     receiver
>     > know whether a particular RTP packet it receives has RTP header
>     > extensions encrypted or not?
>     >
>     > To determine this, the receiver needs to determine the MID
>     value, but
>     > for some packets the MID header extension is encrypted, and for
>     other
>     > RTP packets it isn't. The implementer might have to do some
>     error-prone
>     > and potentially non-interoperable gymnastics, like using
>     heuristics to
>     > guess whether the RTP header extension block is unencrypted or
>     > encrypted, or attempting to decrypt the RTP header extension
>     block on
>     > all received RTP packets, then checking for a MID header
>     extension to
>     > confirm that yes, the RTP header extension block should have been
>     > encrypted.
>     >
>     > This complexity can be avoided if RTP header extension
>     encryption is
>     > either on or off for all MIDs. It is hard to come up with a use
>     case in
>     > which you'd only want some m-lines to have RTP header extension
>     > encryption on and you'd want other m-lines to have RTP header
>     extensions
>     > sent in the clear. So the added complexity doesn't seem to have a
>     > corresponding benefit.
>
>     Can you please clarify the scope for which you want the encryption
>     to be
>     consistent? Above you variously mention all MIDs and all m-lines. I'm
>     concerned with what "all" applies to.
>
>     I think I can agree if you are talking about "all within a bundle
>     group". Anything broader has major problems.
>
>             Thanks,
>             Paul
>
>     _______________________________________________
>     Audio/Video Transport Core Maintenance
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/avt
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt