Re: [AVTCORE] New Version Notification for draft-rescorla-avtcore-6222bis-00.txt

"Ali C. Begen (abegen)" <abegen@cisco.com> Thu, 07 March 2013 04:03 UTC

Return-Path: <abegen@cisco.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 B382621F8765 for <avt@ietfa.amsl.com>; Wed, 6 Mar 2013 20:03:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.449
X-Spam-Level:
X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 y-Bw0h382Nfp for <avt@ietfa.amsl.com>; Wed, 6 Mar 2013 20:03:47 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B2A7321F8763 for <avt@ietf.org>; Wed, 6 Mar 2013 20:03:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2347; q=dns/txt; s=iport; t=1362629027; x=1363838627; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YJ4VjDeahlppd0S6PAYmdbbwMvLOAVEFPdELW0jACYo=; b=C/XC+4pQsdboh4KIbAYnDhcn5JAlZUrPMNgMZWR0M+50eVamchnvP+I3 L93z/lUnt0xpGJXSX6NzzmyeU8cmVdtJCEtIjPecg5lkfoV4zoQ5lokw2 ryHdc10/LJira9olBEwxNoXYsuOXaiXLA8lV9YQ8Ahy55aKCuASLANn8h Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAFoQOFGtJV2d/2dsb2JhbABDhEDABoFkFnOCKwEBAQMBdwIFBwQCAQgRAwECAQokMh0IAgQOBQiIBQYBC7tHjUCBGQIxBwaCWWEDiDafBYFTgTaCJw
X-IronPort-AV: E=Sophos;i="4.84,799,1355097600"; d="scan'208";a="184672990"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 07 Mar 2013 04:03:46 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2743k3C021499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Mar 2013 04:03:46 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 22:03:45 -0600
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Kevin Gross <kevin.gross@avanw.com>
Thread-Topic: [AVTCORE] New Version Notification for draft-rescorla-avtcore-6222bis-00.txt
Thread-Index: AQHOGujDIYjOmUvgB02Y2oS6jNl6MQ==
Date: Thu, 07 Mar 2013 04:03:45 +0000
Message-ID: <C15918F2FCDA0243A7C919DA7C4BE9940CF487E3@xmb-aln-x01.cisco.com>
References: <C15918F2FCDA0243A7C919DA7C4BE994F67420@xmb-aln-x01.cisco.com> <C15918F2FCDA0243A7C919DA7C4BE9940CDE16EA@xmb-aln-x01.cisco.com> <CALw1_Q3sBkDeAQMd1MKV1rC4fK4nSAvd88WN_EJXMdh2tSO7UQ@mail.gmail.com>
In-Reply-To: <CALw1_Q3sBkDeAQMd1MKV1rC4fK4nSAvd88WN_EJXMdh2tSO7UQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.247.185]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <4B0B05E9322F4C4181F93370C1BF6F93@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] New Version Notification for draft-rescorla-avtcore-6222bis-00.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: Thu, 07 Mar 2013 04:03:49 -0000

Picking up this old thread.

On Jan 13, 2013, at 7:14 AM, Kevin Gross <kevin.gross@avanw.com> wrote:

> Sorry for the delay responding. I do think otherwise. (a) is fine because OUI registration prevents collisions. (b) relies on statistics to prevent collisions. There's not enough entropy in 48-bit number to statistically prevent collisions in a larger population of participants. See http://en.wikipedia.org/wiki/Birthday_problem. 96-bits is where things are workable.
> 

What about this:

... After obtaining an identifier in case of (a), the 48 bits are converted to the standard colon-separated hexadecimal format [RFC5342], e.g., "00:23:32:af:9b:aa", resulting in a 17-octet printable string representation. In case of (b), the least significant 96 bits are converted to ASCII using Base64 encoding [RFC4648], resulting in a 16-octet string representation.

-acbegen

> Kevin
> 
> On Sat, Dec 29, 2012 at 2:48 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:
> Kevin,
> 
> -----Original Message-----
> From: "Ali C. Begen" <abegen@cisco.com>
> Date: Monday, November 5, 2012 7:02 PM
> To: Kevin Gross <kevin.gross@avanw.com>
> Cc: "avt@ietf.org" <avt@ietf.org>
> Subject: Re: [AVTCORE] FW: New Version Notification for
> draft-rescorla-avtcore-6222bis-00.txt
> 
> >>Second bullet point in section 4.2 Item (b): Proposes truncating our nice
> >>96-bit random CNAME to 48 bits. I think we have an unacceptable
> >>opportunity for duplication with this approach. This CNAME should
> >>probably use RFC 4648 in which case these CNAMEs
> >>take the same form as the per-session CNAMES but differ in the
> >>requirement to create once at software initialization. Is it necessary
> >>for the different types of CNAMEs to have different appearance?
> >
> >I don¹t think there is such a requirement and your suggestion makes sense.
> 
> Thinking more about this, I think the current text is good. Item (a) uses
> 48-bit MAC addresses. So, even if we use truncating in item (b), its
> collision probability will not be any worse than item (a)'s. Note that
> both item (a) and (b) use 17-octet string representation whereas the
> per-session CNAME uses 16-octet string representation.
> 
> Let me know if you think otherwise.
> 
> -acbegen
> 
>