Subject: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32

From: Magnus Westerlund <[email-masked]>
Date: Wed, 31 Aug 2016 11:58:07 +0200

Hi,

As I promised in Berlin I have done a review of BUNDLE.

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.

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"?
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

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

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.

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.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------