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

[Colin Perkins <[e-mail]>]

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




On 4 Apr 2014, at 16:59, Martin Thomson <[e-mail]> wrote:
> 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,
>   support for generating a short-term persistent RTCP CNAMEs following
>   [RFC7022] is REQUIRED to be implemented and RECOMMENDED to be used.
> 
> 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 <[e-mail]> wrote:
>> 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  [phone]
>> Färögatan 6                 | Mobile [phone]
>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>> ----------------------------------------------------------------------
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb



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