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

Kevin Gross <kevin.gross@avanw.com> Mon, 15 July 2013 20:48 UTC

Return-Path: <kevin.gross@avanw.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088AC11E81E3 for <avt@ietfa.amsl.com>; Mon, 15 Jul 2013 13:48:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.203
X-Spam-Level: *
X-Spam-Status: No, score=1.203 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob7aGmk9RU+A for <avt@ietfa.amsl.com>; Mon, 15 Jul 2013 13:48:43 -0700 (PDT)
Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 2696D11E81FD for <avt@ietf.org>; Mon, 15 Jul 2013 13:48:43 -0700 (PDT)
Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 0jvi1m0041wfjNsA1koiyl; Mon, 15 Jul 2013 20:48:42 +0000
Received: from mail-ob0-x231.google.com ([IPv6:2607:f8b0:4003:c01::231]) by omta23.emeryville.ca.mail.comcast.net with comcast id 0koh1m00h4ocCJw8jkoiqe; Mon, 15 Jul 2013 20:48:42 +0000
Received: by mail-ob0-f177.google.com with SMTP id ta17so14369857obb.8 for <avt@ietf.org>; Mon, 15 Jul 2013 13:48:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AWpV1Pr0QgOEVCNF2K+uC+qom/lmsffBPHJuyutgcLM=; b=WouFNABTpz00rQ115VV/lKmO0pRtY0c01oEczeFZSsg5FpFsAbiUAuBRFzCAb4nt3O iR+WQ1z0ptXicQbwx5WlEJcg38uJ0TRhT1wtpftY/NeA+wGpcXlbCNAijklMz2sUygkG xTy/Lr6xgfPiD4tLQ1Y9qdHGyc5N4sfevWPLqgggkalC7rSJVJYE8qJMdiJEtcv8RT34 VQR6rjXfRjmIzXnC5ODzVOPOUO6/xCTQ+ZQ1WhcYLtBpe841HeLVW5qI+r991k08FMrE GSRokrQtpZqjkki/PKVOCImYfXwD/m6CriJClvU7GQQlHNUWEhbmjsK+CKh9nIQ6IeNx DxUw==
MIME-Version: 1.0
X-Received: by 10.182.196.1 with SMTP id ii1mr44309468obc.93.1373921321573; Mon, 15 Jul 2013 13:48:41 -0700 (PDT)
Received: by 10.182.34.202 with HTTP; Mon, 15 Jul 2013 13:48:41 -0700 (PDT)
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE9940D1E6F5F@xmb-aln-x01.cisco.com>
References: <20130708212917.31411.52919.idtracker@ietfa.amsl.com> <51DBC578.9000306@ericsson.com> <CALw1_Q0YEQmXpCCercTxRpq97whcM4nswcZqSodbKW8b_asmoA@mail.gmail.com> <C15918F2FCDA0243A7C919DA7C4BE9940D1E6F5F@xmb-aln-x01.cisco.com>
Date: Mon, 15 Jul 2013 14:48:41 -0600
Message-ID: <CALw1_Q1XS6EvAc-yzDd5Sm1j_FDFWD5wNgaxa-ZC1FwD3FtBGg@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
Content-Type: multipart/alternative; boundary=089e015383e05267a204e192fc3e
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373921322; bh=AWpV1Pr0QgOEVCNF2K+uC+qom/lmsffBPHJuyutgcLM=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=Gtd2hnfq5aBhae1ayzeKm0RcSd88M3vP4Tyr9YEVBL/Xxzf5HlJM98kT1eSrGEaGI Y7uvvK5pQvmGzXcSxJ3pSavPPnMzKM1f/jN6S1YGptjYdrs98pTeZqxiBKwx1epeK6 EFYDMF4yuVFR5ATxLzEQHfrTyx4SeIfe9yidO49lyWoSrTLDbvSDtm6LoxnjNIl2iW KY9XTX7RLTA7pARjCtiRW3TiLI2ar6lHjYzDpbLJ5GEDgUjdZW25RZvSXNPpIZCBFM PmRw4LBSgo5yL/E28HOAxNw+U9ntjSm2sQTakYB5BHS2f8UBkq1u4ehGv64HYYdPW8 j+JWP75oL2Fag==
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 20:48:47 -0000

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
+1-303-447-0517
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) <abegen@cisco.com>wrote;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 <kevin.gross@avanw.com> 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
> > +1-303-447-0517
> > Media Network Consultant
> > AVA Networks - www.AVAnw.com, www.X192.org
> >
> >
> > On Tue, Jul 9, 2013 at 2:10 AM, Magnus Westerlund <
> magnus.westerlund@ericsson.com> 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, internet-drafts@ietf.org 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
> > > avt@ietf.org
> > > https://www.ietf.org/mailman/listinfo/avt
> > >
> > >
> >
> >
> > --
> >
> > Magnus Westerlund
> >
> > ----------------------------------------------------------------------
> > Multimedia Technologies, Ericsson Research EAB/TVM
> > ----------------------------------------------------------------------
> > Ericsson AB                | Phone  +46 10 7148287
> > Färögatan 6                | Mobile +46 73 0949079
> > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> > ----------------------------------------------------------------------
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
>
>