Re: [AVTCORE] RTP Header Extension Encryption

[Paul Kyzivat <[e-mail]>]

On 9/11/20 3: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.

I'm feeling we need a new term here. It has to cover a bundle group as 
well as a single media-description that isn't bundled. Is there a term 
for this within the RTP vocabulary?

	Thanks,
	Paul

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