Subject: [AVTCORE] Defined by RTP profile ids for encrypted header extensions

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 31 Jul 2020 00:54:56 +0200

Hi all,

Not sure if we got to a consensus regarding the need to introduce new 
defined by profile ids for being able to tell if an incoming packet is 
using the new encryption scheme to protect the csrcs and the rtp headers 
or not.

I think we should, but in that case we need to specify two different 
profiles ids, one for the encrypted one byte header extension and 
another different one for the 2 bytes one. I have some doubts regarding 
what to do with the appbits of the 2 byte header extension profile id:

       0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         0x100         |appbits|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If I have read the rfc correctly (never understood their meaning until 
today), it is reserved for carrying the value of the header extension 
with id 256. This would mean that the appbits for extension 256 are sent 
unencrypted with the new approach if we keep this format. Probably the 
best would be to forbid the usage of extension 256 if cryptex is signaled.

Regarding, ids values, I love 0xC0DE for 1 byte extensions, but not sure 
if it would be better to be consistent and use 0x1010 for 1 byte 
encrypted extensions and 0x1020 for two byte encrypted extensions.

Best regard

Sergio

---

From: Justin Uberti <[email-masked]>
Date: Thu, 30 Jul 2020 16:22:58 -0700

For id 256, this is news to me too. 4 bits isn't a lot of room, but if we
widened this to 8 bits you could stick ssrc-audio-level in here, saving two
bytes per packet. So the options become:
1a) forbid
1b) leave as-is, but encrypt
1c) widen and encrypt

I would go with either 1a) or 1c). 1c) would still need to fall back to a
typical extension when not encrypting. (Do we know why this field was
historicaly chosen to be 4 bits?)

Regarding id, I'm open to the simplicity argument that you make, although
there's also some value in having a value that's immediately obvious from a
Wireshark trace (0xC0DE, 0xC0D2). I think I'd lean more toward the numeric
approach if we went with something like 1c).

On Thu, Jul 30, 2020 at 3:55 PM Sergio Garcia Murillo <
[email-masked]> wrote:

> using the new encryption scheme to protect the csrcs and the rtp headers or
> not.
>
> profiles ids, one for the encrypted one byte header extension and another
> different one for the 2 bytes one. I have some doubts regarding what to do
> with the appbits of the 2 byte header extension profile id:
>
>       0                   1
> today), it is reserved for carrying the value of the header extension with
> id 256. This would mean that the appbits for extension 256 are sent
> unencrypted with the new approach if we keep this format. Probably the best
> would be to forbid the usage of extension 256 if cryptex is signaled.
>
> if it would be better to be consistent and use 0x1010 for 1 byte encrypted
> extensions and 0x1020 for two byte encrypted extensions.
>
> Best regard
>
> Sergio
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 1 Aug 2020 00:44:52 +0200

I am more prone to 1a) forbid

If we add support for id=256 extension, it would have to be backward 
compatible with the non-encrypted version as we can't negotiate 
different extensions for cryptex, so we should not widen it (id 256 is 
not valid id for a "normal" 2 byte extension). Having only 4 bits makes 
it kind of useless and I don't think any implementation supports it anyway.

Regarding ids value, I don't have a strong preference (0xC0DE, 0xC0D2 
would work for me as well), as long as we agree that we need to use two 
new different ids.

Best regards
Sergio

On 31/07/2020 1:22, Justin Uberti wrote:
> For id 256, this is news to me too. 4 bits isn't a lot of room, but if 
> we widened this to 8 bits you could stick ssrc-audio-level in here, 
> saving two bytes per packet. So the options become:
> 1a) forbid
> I would go with either 1a) or 1c). 1c) would still need to fall back 
> to a typical extension when not encrypting. (Do we know why this field 
> was historicaly chosen to be 4 bits?)
>
> Regarding id, I'm open to the simplicity argument that you make, 
> although there's also some value in having a value that's immediately 
> obvious from a Wireshark trace (0xC0DE, 0xC0D2). I think I'd lean more 
> toward the numeric approach if we went with something like 1c).
>
> On Thu, Jul 30, 2020 at 3:55 PM Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     Not sure if we got to a consensus regarding the need to introduce
>     new defined by profile ids for being able to tell if an incoming
>     packet is using the new encryption scheme to protect the csrcs and
>     the rtp headers or not.
>
>     I think we should, but in that case we need to specify two
>     different profiles ids, one for the encrypted one byte header
>     extension and another different one for the 2 bytes one. I have
>     some doubts regarding what to do with the appbits of the 2 byte
>     header extension profile id:
>
>            0                   1
>     If I have read the rfc correctly (never understood their meaning
>     until today), it is reserved for carrying the value of the header
>     extension with id 256. This would mean that the appbits for
>     extension 256 are sent unencrypted with the new approach if we
>     keep this format. Probably the best would be to forbid the usage
>     of extension 256 if cryptex is signaled.
>
>     Regarding, ids values, I love 0xC0DE for 1 byte extensions, but
>     not sure if it would be better to be consistent and use 0x1010 for
>     1 byte encrypted extensions and 0x1020 for two byte encrypted
>     extensions.
>
>     Best regard
>
>     Sergio
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 31 Jul 2020 16:04:41 -0700

yeah, in the interest of not taking on more scope (i.e., an extension of
8285) I think 1a is best. We could always extend later if needed.

On Fri, Jul 31, 2020 at 3:45 PM Sergio Garcia Murillo <
[email-masked]> wrote:

> compatible with the non-encrypted version as we can't negotiate different
> extensions for cryptex, so we should not widen it (id 256 is not valid id
> for a "normal" 2 byte extension). Having only 4 bits makes it kind of
> useless and I don't think any implementation supports it anyway.
>
> would work for me as well), as long as we agree that we need to use two new
> different ids.
>
> Best regards
> Sergio
>