Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - Magnus' comments

[Christer Holmberg <[e-mail]>]

Hi Magnus,

Thanks for your comments! Please see inline.

>1. Section 1:
>    The update allows an answerer to assign a non-zero port
>    value to an "m=" line in an SDP answer, even if the "m=" line in the
>    associated SDP offer contained a zero port value.
>
>I think this sentence could be more explicit that this is allowed given
>that the Offer included this "m=" line in an bundle group.

The ³m=³ line has not been accepted into the BUNDLE group at that stage:
the offerer has suggested the ³m=³ line to be accepted (by the answerer)
into the BUNDLE group.



>2. Section 8.5.2:
>
>    o  Assign the previously selected offerer BUNDLE address to the added
>       "m=" line; or
>
>Two things.
>
>A. Should "previously" be "currently"?

Well, it¹s the address that was selected in a previous Offer/Answer
transaction.


>B. Add an "also" to the above sentence to make it clearer that it is for
>the added m= line.
>
>    o  Assign the currently selected offerer BUNDLE address also to the
>       added "m=" line; or

Not sure I understand. The bullets describe different options.



>3. Section 9:
>
>    This document describes a mechanism to identify the protocol of
>    received data among the STUN, DTLS and SRTP protocols (in any
>    combination), when UDP is used as transport-layer protocol, but does
>    not describe how to identify different protocols transported on DTLS.
>    While the mechanism is generally applicable to other protocols and
>    transport-layer protocols, any such use requires further
>    specification around how to multiplex multiple protocols on a given
>    transport-layer protocol, and how to associate received data with the
>    correct protocols.
>
>I note that this formulation when it comes to other protocols results
>that there is no BUNDLE demultiplexing defined for transports that are
>not UDP but has a datagram semantics. I note that this is do effect
>WebRTC as there is a definition for using RFC 4571 framing over TCP for
>all type of protocols. See Section 3.4 of
>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/?include_tex
>t=1
>
>   If TCP connections are used, RTP framing according to [RFC4571] MUST
>    be used for all packets.  This includes the RTP packets, DTLS packets
>    used to carry data channels, and STUN connectivity check packets.
>
> From BUNDLEs perspective, such a framing will behave equivalent to UDP
>when it comes to demultiplexing. Thus my question is if TCP with RFC4571
>framing also should be defined? Otherwise we will end up with an feature
>mismatch in regards to BUNDLE depending on transport layer.

But, does the de-multiplexing of STUN, DTLS and SRTP actually change if
everything is sent over TCP (sing the 4571 framing mechanism)? Once you
³un-frame² the content, it can be processed as if it had been transported
over UDP. Or?



>4. Section 10.1:
>
>    o  The RTP MID header extension MUST be enabled, by associating an
>       SDP 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp-
>       hdrext:sdes:mid' URI value, with each bundled RTP-based "m=" line
>       in every offer and answer.
>
>I think the list is missing a bullet prior to the above one:
>
>    * The MID SDES item MUST periodically be sent in RTCP SDES items for
>      any SSRC originating from a "m=" line that is part of any BUNDLE
>      group.
>
>What I see is the important goal here is that BUNDLE supporting
>implementations also support the MID SDES item in RTCP, not only the
>header extension.


So, you want to add the bullet you suggested?


>5. Section 15.2:
>
>      The SDES item does not reveal privacy information about the users.
>      It is simply used to associate RTP-based media with the correct SDP
>      media description (m- line) in the SDP used to negotiate the media.
>
>I do not fully agree with this statement. As the MIDs are transmitted
>over the RTP/RTCP channel the actual used values as well as the
>implementation algorithm for creating such IDs are exposed. This can
>allow for tracking of instances if they have unusual combinations of
>media streams as well if the MID values are poorly constructed from
>privacy perspective leak additional information.
>
>I think this threat needs to be made more explicit. I also think it
>might be better to move this discussion to the Security Consideration
>section. I note that the security consideration section is focused on
>only the SDP BUNDLE mechanism, not the other defined protocol elements,
>i.e. the new SDP attributes as well as the MID.


Note the following text in section 14.2:

	"The identification-tag MUST NOT contain any user information, and
applications SHALL avoid generating
	the identification-tag using a pattern that enables application
identification.²

Regards,

Christer