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

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Sep 2016 10:20:15 +0000

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 6 Sep 2016 15:43:10 +0200

> the offerer has suggested the ³m=³ line to be accepted (by the answerer)

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.

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

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

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

> ³un-frame² the content, it can be processed as if it had been transported

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

> So, you want to add the bullet you suggested?

Yes.

> 	the identification-tag using a pattern that enables application

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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 6 Sep 2016 15:22:22 -0400

On 9/6/16 9:43 AM, Magnus Westerlund wrote:

> to a RTP where it can be provided to completely different set of attackers.

IMO this is becoming ridiculous. Using cryptographically random tags 
would be annoying to implement, and would make the SDP even harder to read.

I've been annoyed at the examples using small integers because that 
makes them hard to read. I'd be more inclined to use mnemonics, at least 
for examples, if not for production code.

Are we getting to the point where we need to define an SDP Obfuscator 
(along with a SIP Obfuscator)?

If that is what we need then I think we would be better off doing it 
that way than doing it piecemeal, one token at a time.

	Thanks,
	Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 7 Sep 2016 13:17:10 +0200

> for examples, if not for production code.

The point I tried to raise above is that the text in draft is 
insufficient to prevent information leakage. This because at least the 
implementation for the MIDs will be detectable unless one actually 
specify it very strictly. It might be that the possibility to identify 
the implementation is a very  minor issue here and also something that 
is likely leaking in so many other ways.

The more serious issue is being able to identify specific devices based 
on the MID values. So how many MIDs that are being used or at least 
offered will depend on the endpoints configuration in combination with 
the software.

> (along with a SIP Obfuscator)?

Well, that is a separate problem from the one I am bringing up here. My 
main concern here is that due to the RTP header extension there is 
information that exist in SDP that are leaking to some degree to the RTP 
layer where it becomes observable by another set of potential attackers.

The first mechanism that can be applied which will ensure protection 
towards third parties is to use RTP header extension encryption 
[RFC6904]. Then this information only leaks to nodes inside the security 
context. And they likely anyway have access to the SDP. Thus removing 
the issue.

 From my perspective mandating the use of RFC 6904 to encrypt the MID 
RTP header extension might be the simplest choice here and provides 
better protection against third parties. It may not give as good 
protection against semi trusted entities. But, they already have so much 
other information that this doesn't matter at this point.

> that way than doing it piecemeal, one token at a time.

The SDP and SIP layer issues in regards to these tracking possibilities 
are much harder, and clearly needs a more all encompassing approach. 
What I think is important here is the leakage to another layer. That 
should be prevented.

Cheers

Magnus Westerlund

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 7 Sep 2016 10:36:56 -0400

Magnus,

Thanks for highlighting your main issue - leakage across layers from SDP 
to RTP. I see how that could be a different sort of vulnerability. 
Encrypting RTP headers sounds like a better answer than obfuscating 
specific ids in the SDP.

	Thanks,
	Paul

On 9/7/16 7:17 AM, Magnus Westerlund wrote:
> From my perspective mandating the use of RFC 6904 to encrypt the MID RTP
> header extension might be the simplest choice here and provides better
> protection against third parties. It may not give as good protection
> against semi trusted entities. But, they already have so much other
> information that this doesn't matter at this point.
>
>>