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

[Sergio Garcia Murillo <[e-mail]>]

On Tue, Jun 14, 2022 at 10:53 AM Christer Holmberg <
[e-mail]> wrote:

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

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.



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


>
> Regards,
>
> Christer
>
>
>