Re: [AVTCORE] RTP Header Extension Encryption

[Bernard Aboba <[e-mail]>]

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]> 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]
> https://www.ietf.org/mailman/listinfo/avt
>