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

[Kevin Gross <[e-mail]>]

That's technically sound. Editorially speaking, this new (b) method is
already described in the third bullet point in section 4.2. Hopefully the
authors can find a way to reference that instead of repeating it.

Separately, I note that section 5 allows you to create unique identifiers
with more than 96 bits. I now don't see anywhere where you're allowed to
use more than 96 bits so I question why we include that flexibility.

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


On Wed, Mar 6, 2013 at 9:03 PM, Ali C. Begen (abegen) <[e-mail]>wrote:

> Picking up this old thread.
>
> On Jan 13, 2013, at 7:14 AM, Kevin Gross <[e-mail]> 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) <[e-mail]>
> wrote:
> > Kevin,
> >
> > -----Original Message-----
> > From: "Ali C. Begen" <[e-mail]>
> > Date: Monday, November 5, 2012 7:02 PM
> > To: Kevin Gross <[e-mail]>
> > Cc: "[e-mail]" <[e-mail]>
> > 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
> >
> >
>
>