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

[Kevin Gross <[e-mail]>]

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.

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
>
>