Subject: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Apr 2014 11:09:00 +0200

WG,
(As author)

Based on the discussion we authors have drafted a proposal for changing
the CNAME creation usage to be created unique between PeerConnections.
Our draft text is the below one. Please review. If we receive no
feedback we will include this in the next version of the draft that we
hope to be able to produce next week.

Section 4.1:

   o  Support for multiple synchronisation contexts.  Participants that
      send multiple simultaneous RTP packet streams do so as part of a
      single synchronisation context, using a single RTCP CNAME for all
      streams and allowing receivers to play the streams out in a
      synchronised manner.  Receivers MUST support reception of multiple
      RTCP CNAMEs in an RTP session, and hence multiple synchronisation
      contexts, to support RTP middleboxes, and future evolution needing
      multiple CNAMEs in an endpoint.  See also Section 4.9.

Section 4.9:

4.9.  Generation of the RTCP Canonical Name (CNAME)

   The RTCP Canonical Name (CNAME) provides a persistent transport-level
   identifier for an RTP end-point.  While the Synchronisation Source
   (SSRC) identifier for an RTP end-point can change if a collision is
   detected, or when the RTP application is restarted, its RTCP CNAME is
   meant to stay unchanged, so that RTP end-points can be uniquely
   identified and associated with their RTP packet streams within a set
   of related RTP sessions.  For proper functionality, each RTP end-
   point needs to have at least one unique RTCP CNAME value.  From an
   RTP perspective an end-point can have multiple CNAMEs, as the CNAME
   also identifies a particular synchronisation context, i.e. all SSRC
   associated with a CNAME share a common reference clock, and if an
   end-point have SSRCs associated with different reference clocks it
   will need to use multiple CNAMEs.  This ought not be common, and if
   possible reference clocks ought to be mapped to each other and one
   chosen to be used with RTP and RTCP.  Taking the discussion in
   Section 11 into account a regular WebRTC end-point MUST NOT use more
   than a single CNAME in the RTP sessions belonging to single
   RTCPeerConnection.  RTP middleboxes MAY send RTP packet streams
   identified by more than one CNAME, to allow them to avoid having to
   resynchronize media from multiple different end-points part of a
   multi-party RTP session.

   The RTP specification [RFC3550] includes guidelines for choosing a
   unique RTP CNAME, but these are not sufficient in the presence of NAT
   devices.  In addition, long-term persistent identifiers can be
   problematic from a privacy viewpoint (Section 13).  Accordingly,
   support for generating a short-term persistent RTCP CNAMEs following
   [RFC7022] is REQUIRED to be implemented and RECOMMENDED to be used.
   Unless a persistent CNAME is explicitly configured, a unique CNAME(s)
   MUST be generated for each synchronization context an end-point has
   within each RTCPeerConnection, i.e. normally one across all the RTP
   sessions within the scope of the RTCPeerConnection.

      There are no known reasons for WebRTC end-points that aren't RTP
      middleboxes or servers to configure a persistent identifiers,
      these considerations are limited to RTP middleboxes.  Thus, such
      configuration options SHOULD NOT be present in most WebRTC end-
      point implementations to prevent misconfiguration or malicious
      configuration that allows tracking or linking of a user.

   An WebRTC end-point MUST support reception of any CNAME that matches
   the syntax limitations specified by the RTP specification [RFC3550]
   and cannot assume that any CNAME will be chosen according to the form
   suggested above.

Section 11:

   The same MediaStreamTrack can also be included in multiple
   MediaStreams, thus multiple sets of MediaStreams can implicitly need
   to use the same synchronisation base.  To ensure that this works in
   all cases, and don't forces a end-point to change synchronisation
   base and CNAME in the middle of a ongoing delivery of any packet
   streams, which would cause media disruption; all MediaStreamTracks
   and their associated SSRCs originating from the same end-point needs
   to be sent using the same CNAME within one RTCPeerConnection.  This
   is motivating the strong recommendation in Section 4.9 to only use a
   single CNAME.

      Note: It is important that the same CNAME is not used in different
      communication session contexts or origins, as that could enable
      tracking of a user and its device usage of different services.
      See Section 4.4.1 of Security Considerations for WebRTC
      [I-D.ietf-rtcweb-security] for further discussion.

      The requirement on using the same CNAME for all SSRCs that
      originates from the same end-point, does not require middleboxes
      that forwards traffic from multiple end-points to only use a
      single CNAME.

   The above will currently force a WebRTC end-point that receives an
   MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing
   on any RTCPeerConnection to perform resynchronisation of the stream.
   This, as the sending party needs to change the CNAME, which implies
   that it has to use a locally available system clock as timebase for
   the synchronisation.  Thus, the relative relation between the
   timebase of the incoming stream and the system sending out needs to
   defined.  This relation also needs monitoring for clock drift and
   likely adjustments of the synchronisation.  The sending entity is
   also responsible for congestion control for its the sent streams.  In
   cases of packet loss the loss of incoming data also needs to be
   handled.  This leads to the observation that the method that is least
   likely to cause issues or interruptions in the outgoing source packet
   stream is a model of full decoding, including repair etc followed by
   encoding of the media again into the outgoing packet stream.
   Optimisations of this method is clearly possible and implementation
   specific.

   A WebRTC end-point MUST support receiving multiple MediaStreamTracks,
   where each of different MediaStreamTracks (and their sets of
   associated packet streams) uses different CNAMEs.  However,
   MediaStreamTracks that are received with different CNAMEs have no
   defined synchronisation.

      Note: The motivation for supporting reception of multiple CNAMEs
      are to allow for forward compatibility with any future changes
      that enables more efficient stream handling when end-points relay/
      forward streams.  It also ensures that end-points can interoperate
      with certain types of multi-stream middleboxes or end-points that
      are not WebRTC.

-- 

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: Martin Thomson <[email-masked]>
Date: Fri, 4 Apr 2014 08:59:38 -0700

That's a lot of text.

In the interests of maintaining privacy (specifically unlinkability),
or the ability to do so, applications should be able to request that a
given RTCPeerConnection use a different CNAME to other
RTCPeerConnection instances in the same session context.  Otherwise, a
site operating a service would be unable to provide callers with
anonymity or pseudonymity toward different remote peers.

That's my minimum ask, but even that isn't ideal.

Better yet would be to be privacy protecting by default.  To avoid
issues where CNAME needs to be consistent, allow sites to link
RTCPeerConnections to allow for consistent CNAME use across
"sessions".

I haven't thought it through, but I can't think of a reason off the
top of my head not to allow sites to specify a CNAME directly.  After
all, a site is perfectly able to use signaling to link sessions, so
we're not giving anything away.  A random value could be chosen in the
absence of an explicit one.

I realize that this does - to some extent - compromise the purity and
integrity of your RTP usage.  I think that it's worth it.  The text
you've provided gives good context for that.  It just needs a
different conclusion.

Nits:

   This ought not be common, and if
   possible reference clocks ought to be mapped to each other and one
   chosen to be used with RTP and RTCP.

I can't parse this.

   Accordingly,

That's a strange statement.  How will you know if someone has
implemented 7022 if they aren't using it?  Seems like a SHOULD to me.

On 4 April 2014 02:09, Magnus Westerlund <[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Colin Perkins <[email-masked]>
Date: Fri, 4 Apr 2014 17:34:53 +0100

Martin,

I’m perhaps misunderstanding something, or we may not have phrased the text clearly, but what you say you want generally matches my understanding of what the draft provides. Can you expand on what parts of the text you think are problematic?

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Apr 2014 10:37:07 -0700

> I’m perhaps misunderstanding something, or we may not have phrased the text clearly, but what you say you want generally matches my understanding of what the draft provides. Can you expand on what…

The first paragraph of Section 11 seems directly contrary to what I outlined.

I don't know how you interpret this, but I read the following text as
saying the complete opposite of my suggestion to allow setting of
CNAME:

Now that I've gone back and re-read again, I think that this text is
possibly confused, and certainly confusing, with respect to use of the
various contexts in play.

 * The text uses RTP end-point, which I infer corresponds to the
(local) end of the ICE component in use (i.e., the selected transport
5-tuple).  An RTP end-point is required to have a unique CNAME, but
that's not consistent with unbundled (SDP negotiated) sessions (i.e.,
what corresponds to a single unbundled RTCPeerConnection), which I
assume will want to use a consistent CNAME if at all possible.

 * We also have guidance regarding RTCPeerConnection.

 * And there is also guidance regarding the browser session,
presumably scoped to a given origin [RFC6454].

 * I'll list RTP session for completeness, though I don't think it's a
useful context to use in any case.

I think that the advice could be much clearer, once all the context is
properly established:

  1. MUST use the same CNAME for an RTP end-point, unless different
SSRCs are on a different time base (i.e., the uncommon case)

  2. MUST use different CNAME for different RTCPeerConnection
instances, following RFC 7022, unless the using application explicitly
provides a CNAME.

The latter point covers the origin case adequately.  Servers and
middleboxes can be given a blanket exemption if you like, allowing for
the fact that they should be doing all the normal and proper RTP
things.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Apr 2014 12:57:59 +0200

> instances, following RFC 7022, unless the using application explicitly

This is the intent of the text provided. So, I guess it is further work
on how things are formulated that are needed, not the intended content.
In fact regarding the first we have been stricter than that, the reason
is to avoid the synchronization issues that arises from creating
MediaStreams from MediaStreamTracks with different time-bases. That
issue would disappear if MediaStream are abandoned in the API, and then
I would prefer your notice of exception when handling multiple timebases
locally.

> the fact that they should be doing all the normal and proper RTP

I think a important aspect from a middlebox why multiple CNAMEs is to be
expected and not necessariyl follow the default rules, is that they may
not be controlled as normal WebRTC endpoint, i.e. no normal JS API.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Apr 2014 14:10:42 +0200

Hi Martin and WG,

Colin has helped clarify the text. Thus, I wanted to provide an updated
version of the text to see if this resolves your concerns properly.

Section 4.1 (Part)

   o  Support for multiple synchronisation contexts.  Participants that
      send multiple simultaneous RTP packet streams SHOULD do so as part
      of a single synchronisation context, using a single RTCP CNAME for
      all streams and allowing receivers to play the streams out in a
      synchronised manner.  For compatibility with potential future
      versions of this specification, or for interoperability with non-
      WebRTC devices through a gateway, receivers MUST support multiple
      synchronisation contexts, indicated by the use of multiple RTCP
      CNAMEs in an RTP session.  This specification requires the usage
      of a single CNAME when sending RTP Packet Streams in some
      circumstances, see Section 4.9.

   The RTCP Canonical Name (CNAME) provides a persistent transport-level
   identifier for an RTP end-point.  While the Synchronisation Source
   (SSRC) identifier for an RTP end-point can change if a collision is
   detected, or when the RTP application is restarted, its RTCP CNAME is
   meant to stay unchanged for the duration of a RTCPeerConnection
   [W3C.WD-webrtc-20130910], so that RTP end-points can be uniquely
   identified and associated with their RTP packet streams within a set
   of related RTP sessions.

   Each RTP end-point MUST have at least one RTCP CNAME, and that RTCP
   CNAME MUST be unique within the RTCPeerConnection.  RTCP CNAMEs
   identify a particular synchronisation context, i.e., all SSRCs
   associated with a single RTCP CNAME share a common reference clock.
   If an end-point has SSRCs that are associated with several
   unsynchronised reference clocks, and hence different synchronisation
   contexts, it will need to use multiple RTCP CNAMEs, one for each
   synchronisation context.

   Taking the discussion in Section 11 into account, a WebRTC end-point
   MUST NOT use more than one RTCP CNAME in the RTP sessions belonging
   to single RTCPeerConnection (that is, an RTCPeerConnection forms a
   synchronisation context).  RTP middleboxes MAY generate RTP packet
   streams associated with more than one RTCP CNAME, to allow them to
   avoid having to resynchronize media from multiple different end-
   points part of a multi-party RTP session.

   The RTP specification [RFC3550] includes guidelines for choosing a
   unique RTP CNAME, but these are not sufficient in the presence of NAT
   devices.  In addition, long-term persistent identifiers can be
   problematic from a privacy viewpoint (Section 13).  Accordingly, a
   WebRTC endpoint MUST generate a new, unique, short-term persistent
   RTCP CNAME for each RTCPeerConnection, following [RFC7022].

Section 11 (Part)

Section 13 (Part)

   RTCP packets convey a Canonical Name (CNAME) identifier that is used
   to associate RTP packet streams that need to be synchronised across
   related RTP sessions.  Inappropriate choice of CNAME values can be a
   privacy concern, since long-term persistent CNAME identifiers can be
   used to track users across multiple WebRTC calls.  Section 4.9 of
   this memo provides guidelines for generation of untraceable CNAME
   values that alleviate this risk.

-- 

Magnus Westerlund

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Apr 2014 10:33:04 -0700

The text looks fine, with one comment.

>       [I-D.ietf-rtcweb-security] for further discussion.

I'd rather not have this hidden in a "Note", and I'd prefer if it were
more concrete.  I think that we need to say something like:

A different CNAME MUST be used for different RTCPeerConnection
instances.  Having two communication sessions with the same CNAME
could enable tracking of a user or device across different services
(see Section 4.4.1 of [security] for details).  A web application MAY
override the CNAME that is selected using the process in [RFC7022] to
allow for synchronization of disjoint sessions; [[this doesn't result
in a tracking issue, since the creation of matching CNAMEs depends on
existing tracking]].

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Apr 2014 14:54:27 +0200

> in a tracking issue, since the creation of matching CNAMEs depends on

The first part is already said in Section 4.9 text:

Thus, I don't want in two places to use Normative RFC 2119 text for the
same purpose.

For the second half, I have to ask what the scope of this overriding is
intended to be. Is it that within the same origin, a web application
creating multiple PeerConnections can request them to use the same (by
browser) selected random CNAME value? Or is it that the web application
can set the CNAME to be used at PeerConnection creation time. The first
I am fine with, as it appear to have very little downsides, and can
really help application that tries to do advanced things where multiple
PCs are used across multiple endpoints and middleboxes.

Thus, I would propose to modify your proposal to result in a change in
Section 4.9:

Old:

NEW:

   The RTP specification [RFC3550] includes guidelines for choosing a
   unique RTP CNAME, but these are not sufficient in the presence of NAT
   devices.  In addition, long-term persistent identifiers can be
   problematic from a privacy viewpoint (Section 13).  Accordingly, a
   WebRTC endpoint MUST generate a new, unique, short-term persistent
   RTCP CNAME for each RTCPeerConnection, following [RFC7022], with a
   single exception; if explicitly requested at creation an
   RTCPeerConnection MAY use the same CNAME as as an existing
   RTCPeerConnection within their common same-origin context.

Section 11:

OLD:

NEW:

   Different CNAMEs are normally required to be used for different
   RTCPeerConnection instances, as specified in Section 4.9.  Having two
   communication sessions with the same CNAME could enable tracking of a
   user or device across different services (see Section 4.4.1 of
   [I-D.ietf-rtcweb-security] for details).  A web application can
   request that the CNAMEs used in different RTCPeerConnection within a
   same-orign context to be the same, this allow for synchronization of
   the endpoint's RTP packet streams across the different
   RTCPeerConnections.

      Note: this doesn't result in a tracking issue, since the creation
      of matching CNAMEs depends on existing tracking.

Is this better/acceptable?

Cheers

Magnus Westerlund

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Apr 2014 16:27:02 -0700

> Is this better/acceptable?

Better, but I don't think that the proposed solution is sufficient for
some use cases.  There is no downside to enabling correlation of
sessions when the signaling entity is able to force correlation.  Let
the app set CNAME.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Apr 2014 12:50:15 +0200

> sessions when the signaling entity is able to force correlation.  Let

Sure from privacy point of view, but there are a potential to really
screw up RTP/RTCP by setting the same CNAME in multiple endpoints part
of the same communication session. That is why I wrote like I wrote.
Even using the same CNAME between different instances of the media
framework, which I assume is the likely result of establishing
PeerConnection in different tabs/windows in a browser instance could get
into issues using the same CNAME, due to them really not being based on
a common context.

Cheers

Magnus Westerlund

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Apr 2014 09:16:02 -0700

> into issues using the same CNAME, due to them really not being based on

Sure, WFM.