Re: [AVTCORE] RTP Header Extension Encryption

[Bernard Aboba <[e-mail]>]

Speaking only for myself (Chair hat off), the lesson from the RFC 6904
implementation experience described in the slides is that complexity is the
enemy of implementation correctness and also interoperability.   So a goal
should be to simplify the new proposal as much as possible. This includes
the potential to negotiate encryption of all RTP header extensions "on" or
"off" rather than allowing individual RTP header extensions to be
negotiated as encrypted or not.

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.

On Thu, Sep 10, 2020 at 2:14 PM Bernard Aboba <[e-mail]>
wrote:

> At IETF 108, Justin Uberti lead a side meeting relating to RTP header
> extension encryption:
>
> https://www.ietf.org/proceedings/108/slides/slides-108-avtcore-rtp-header-extension-encryption-full-01
>
> As presented in the slides there are a number of potential options for
> moving forward. It is quite likely that we will discuss this more at IETF
> 109, but I thought it would be useful to get mailing list discussion going
> beforehand.
>