Re: [AVTCORE] [MMUSIC] SDP Directorate review: draft-ietf-avtcore-cryptex

[Christer Holmberg <[e-mail]>]

Hi,

... 

Q4:

>>>> Section 4 says:
>>>>
>>>>   "If BUNDLE is in use and the a=cryptex attribute is present for a
>>>>   media line, it MUST be present for all media lines belonging to the
>>>>   same bundle group.  This ensures that the encrypted MID header
>>>>   extensions used to demux BUNDLE can be processed correctly.  When
>>>>   used with BUNDLE, this attribute is assigned to the TRANSPORT
>>>>   category [RFC8859]."
>>>>
>>>> First, as the usage of Cryptex is optional, why mandate it on all media lines? Could you explain the MID header processing justficiation?
>>>>
>>> If ssrc info is not exchanged in the SDP O/A, then the only way to assign a packet to an m-line is by the mid value which is encrypted if cryptex is in use. So if the peer signals that it supports receiving cryptex in one m-line, it must support it on all of them.
>> 
>> Sure, but if you only indicate cryptex support for m- line X, then the peer is only allowed to use cryptex for the RTP packets associated with X. 
>>
>> But, the peer is not allowed to use cryptex for RTP packets associated with m- line Y. 
>>
>> But, in general I think it would be good to add some more text on the BUNDLE impacts, e.g., that intermediary nodes might not be able to distinguish/process bundled media if the MID is encrypted.
>>
>> For example, in some networks there are intermediaries that "un-BUNDLE" media into individual 5-tuples, and that won't work unless such nodes have access to the MIDs.
>
> There could be two different intermediaries that un-bundle media and forward them to individual 5-tuples, the ones which terminate the SRTP encryption and  the ones that don't.
> For the ones that terminate SRTP, if they are able to support cryptex on one m-line, they should be able to support it on all others. It could be argued that the receiver may want to only protect the header extensions on some media in order to reduce the processing workload, but not sure if this is a common or desirable scenario.
>
> https://www.omavahti.fi/tuote/turvapuhelin/For the ones that doesn't terminate SRTP and just forward the SRTP packets to individual 5-tuples, they will may not be able to process any SRTP
> packet with cryptex if no ssrc info is negotiated in the SDP (which is the intended way of doing BUNDLE, right?).
>
> I will try to add some more text about BUNDLE impacts based on the outcome of the discussion above. 

Thanks!

Also, coming back to the mandate to indicate cryptex support for all BUNDLED m- line: Assume an intermediary get an offer, where each m- line has a separate 5-tuple, and only m- line X indicates support for cryptex, while m- line Y does not. Now the intermediary want to BUNDLE the m- lines, but is now forced to indicate cryptes support also for m- line Y in the offer describing the BUNDLE.

>>Second, if mandated on all media lines, it will apply also to non-RTP media lines (e.g., a WebRTC data channel), and then I think you need to have some explicit text about that.
>>
>>What would be the best term for a "media m-line"?
>>
>>- media m-line
>>- media m line
>>- media "m=" line
>>
>> My suggestion would be to say "m- lines for RTP transported media", or something like that, because technically you could transport media also using non-RTP mechanisms.
>
> I have just checked the BUNDLE rfc and they us the term: "m=" section and RTP-based media. What do you think about using this instead?
> 
> If BUNDLE is in use and the a=cryptex attribute is present in a "m=" section, it MUST be present for all the "m=" sections for RTP-based media belonging to the same bundle group. 
   
That sounds good. But, it makes me wonder whether the category should be SPECIAL instead of TRANSPORT, as it only applies to RTP.

I still also wonder whether it is really needed to mandate the cryptex attribute for all BUNDLEd RTP m= lines. 

Regards,

Christer