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

[Justin Uberti <[e-mail]>]

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 <
[e-mail]> wrote:

> 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
> 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 <
> [e-mail]> 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
>>        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
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt
>>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>