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

[Magnus Westerlund <[e-mail]>]

Den 2016-09-01 kl. 12:20, skrev Christer Holmberg:
>
> 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.

Yes, but the condition for reverting an m= line in an offer to a 
non-zero value in answer, is that the offer contained an offer for 
bundling the m= line with some others m= lines. That requirement for 
doing this reverting should be more explicit in this line I think.

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

Ok, which means it is currently in force address. But, no strong 
opinion, I do get either of them.

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

What I suggested was to add "also" to that bullet. This to make it clear 
that this option means adding the existing Bundle Address to the new 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_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?

 From a demultiplexing perspective a TCP/RFC4571 stream is equivalent to 
UDP flow. However, the existing test is written so that only the UDP one 
is defined and thus allowed to use. The TCP/RFC4571 case will not be 
defined unless some change is done. I rather address this part of the 
first sentence ", when UDP is used as transport-layer protocol," so that 
it covers TCP/RFC4571 case also, rather then having to write a separate 
doc for "Bundle and RFC 4571 framing over TCP".

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

Yes.

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

Yes, but when it comes to profiling I think the above is to unspecific 
to prevent profiling. One option is a very basic algorithm that everyone 
will implement identically. However, the ordering of the m= line and 
their media types etc etc may still allow fingerprinting of a device. 
One could define it to be cryptographically random 3 character tags. 
Then it would likely be difficult to get anything from it. The issue 
here is really that one moves the tags from a context where the tags is 
a minor issue, as the full SDP provides so much profiling possibilities, 
to a RTP where it can be provided to completely different set of 
attackers.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------