Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CABkgnnVD09V80OkXY=ZKicYhjBMR8XZMFYCXrMmHMkVWE7mwVw@mail.gmail.com>
Date: Fri, 4 Apr 2014 17:34:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <005B30AC-F891-481E-A25A-D3705713F1D3@csperkins.org>
References: <533E76AC.7030003@ericsson.com>
 <CABkgnnVD09V80OkXY=ZKicYhjBMR8XZMFYCXrMmHMkVWE7mwVw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/imqrLzQMV9cLaHKFdUgVfgF7T1Q
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage
Precedence: list

Martin,

I=92m 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




On 4 Apr 2014, at 16:59, Martin Thomson <martin.thomson@gmail.com> =
wrote:
> That's a lot of text.
>=20
> 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.
>=20
> That's my minimum ask, but even that isn't ideal.
>=20
> 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".
>=20
> 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.
>=20
> 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.
>=20
> Nits:
>=20
>   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.
>=20
> I can't parse this.
>=20
>   Accordingly,
>   support for generating a short-term persistent RTCP CNAMEs following
>   [RFC7022] is REQUIRED to be implemented and RECOMMENDED to be used.
>=20
> 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.
>=20
>=20
> On 4 April 2014 02:09, Magnus Westerlund =
<magnus.westerlund@ericsson.com> wrote:
>> WG,
>> (As author)
>>=20
>> 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.
>>=20
>> Section 4.1:
>>=20
>>   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.
>>=20
>>=20
>> Section 4.9:
>>=20
>> 4.9.  Generation of the RTCP Canonical Name (CNAME)
>>=20
>>   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.  =46rom =
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.
>>=20
>>   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.
>>=20
>>      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.
>>=20
>>   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.
>>=20
>> Section 11:
>>=20
>>   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.
>>=20
>>      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.
>>=20
>>      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.
>>=20
>>   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.
>>=20
>>   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.
>>=20
>>      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.
>>=20
>> --
>>=20
>> Magnus Westerlund
>>=20
>> =
----------------------------------------------------------------------
>> Services, Media and Network features, Ericsson Research EAB/TXM
>> =
----------------------------------------------------------------------
>> Ericsson AB                 | Phone  +46 10 7148287
>> F=E4r=F6gatan 6                 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> =
----------------------------------------------------------------------
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb



--=20
Colin Perkins
http://csperkins.org/