Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt

[Kevin Gross <[e-mail]>]

I've done quick research on this issue and it is real and I'm surprised it
has not been more disruptive. MAC addresses have been assumed by many to be
globally unique for a long time.

Sorry if this has already been discussed somewhere, but it seems harsh to
remove MAC-based CNAMEs entirely. They can be used safely in many
environments and there at least two motivations for doing so. Can we demote
MAC-based CNAMEs to NOT RECOMMENDED instead?

There are other instances in the draft where we describe how previous
recommendations were found to be lacking. How about we add something to the
draft to explain why MAC-based CNAMEs are no longer permitted/recommended.
I'm willing to help with this.

Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org


On Mon, Jul 15, 2013 at 11:26 AM, Ali C. Begen (abegen) <[e-mail]>wrote:

> MAC addresses are not unique anymore, so cannot be reliably used for cname
> generation.
>
> On Jul 15, 2013, at 10:10 AM, Kevin Gross <[e-mail]> wrote:
>
> > Yes, this is a significant change. It appears to imply that a
> cryptographic PRNG is required in every RTP device and things will be more
> difficult for 3rd party network performance monitoring systems.
> >
> > Although there is discussion in the draft downplaying these issues,
> there are RTP applications that won't otherwise require a CPRNG and there
> are applications where ease of monitoring is more important than security.
> >
> > What was the reason given for wanting to remove the MAC option?
> >
> > If we go with this, I suggest an editorial pass to reduce repetition in
> the last two bullets in section 4.2 and clean up references to "multiple",
> "several" as there are now only two methods recommended for generating
> CNAMEs. Let me know if you need any help with this.
> >
> > Kevin Gross
> > [phone]
> > Media Network Consultant
> > AVA Networks - www.AVAnw.com, www.X192.org
> >
> >
> > On Tue, Jul 9, 2013 at 2:10 AM, Magnus Westerlund <
> [e-mail]> wrote:
> > WG,
> >
> > This document has just been in IESG review and the authors has discussed
> > with the IESG. One discuss raised was the implications of the MAC based
> > generation of short-term persistent CNAMES. The conclusion in that
> > discussion was to remove that option and rely only on random names in
> > that case.
> >
> > I wanted to inform the WG about this significant change and give you a
> > chance to react to this change before the document is approved. You will
> > have one week to react.
> >
> > The details can be seen in this diff:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-05
> >
> >
> > Cheers
> >
> > Magnus Westerlund
> >
> >
> > On 2013-07-08 23:29, [e-mail] wrote:
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > >  This draft is a work item of the Audio/Video Transport Core
> Maintenance Working Group of the IETF.
> > >
> > >       Title           : Guidelines for Choosing RTP Control Protocol
> (RTCP) Canonical Names (CNAMEs)
> > >       Author(s)       : Ali Begen
> > >                           Colin Perkins
> > >                           Dan Wing
> > >                           Eric Rescorla
> > >       Filename        : draft-ietf-avtcore-6222bis-05.txt
> > >       Pages           : 10
> > >       Date            : 2013-07-08
> > >
> > > Abstract:
> > >    The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
> > >    persistent transport-level identifier for an RTP endpoint.  While
> the
> > >    Synchronization Source (SSRC) identifier of an RTP endpoint may
> > >    change if a collision is detected or when the RTP application is
> > >    restarted, its RTCP CNAME is meant to stay unchanged, so that RTP
> > >    endpoints can be uniquely identified and associated with their RTP
> > >    media streams.
> > >
> > >    For proper functionality, RTCP CNAMEs should be unique within the
> > >    participants of an RTP session.  However, the existing guidelines
> for
> > >    choosing the RTCP CNAME provided in the RTP standard are
> insufficient
> > >    to achieve this uniqueness.  RFC 6222 was published to update those
> > >    guidelines to allow endpoints to choose unique RTCP CNAMEs.
> > >    Unfortunately, later investigations showed that some parts of the
> new
> > >    algorithms were unnecessarily complicated and/or ineffective.  This
> > >    document addresses these concerns and replaces RFC 6222.
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis
> > >
> > > There's also a htmlized version available at:
> > > http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-05
> > >
> > > A diff from the previous version is available at:
> > > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-05
> > >
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > _______________________________________________
> > > Audio/Video Transport Core Maintenance
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/avt
> > >
> > >
> >
> >
> > --
> >
> > Magnus Westerlund
> >
> > ----------------------------------------------------------------------
> > Multimedia Technologies, Ericsson Research EAB/TVM
> > ----------------------------------------------------------------------
> > Ericsson AB                | Phone  [phone]
> > Färögatan 6                | Mobile [phone]
> > SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> > ----------------------------------------------------------------------
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
>
>