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

[Martin Thomson <[e-mail]>]

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