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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 7 Mar 2013 04:03:45 +0000

Picking up this old thread.

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

---

From: Kevin Gross <[email-masked]>
Date: Thu, 7 Mar 2013 09:19:57 -0700

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
+1-303-447-0517
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) <[email-masked]>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
> >

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 8 Mar 2013 22:17:01 +0000

On Mar 8, 2013, at 3:19 AM, Kevin Gross <[email-masked]> wrote:

> 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.
> 
Editorially, I like the straightforward version, if you don't mind.

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

That part says "to compromise between packet size and uniqueness - refer to Section 6.1". So, I think if one does not care about the packet size, he can use longer bits.

> Kevin Gross
> +1-303-447-0517
> Media Network Consultant
> AVA Networks - www.AVAnw.com, www.X192.org
> 
> 
> On Wed, Mar 6, 2013 at 9:03 PM, Ali C. Begen (abegen) <[email-masked]> wrote:

---

From: Kevin Gross <[email-masked]>
Date: Fri, 8 Mar 2013 20:34:39 -0700

Stuff below

Kevin Gross
+1-303-447-0517
Media Network Consultant

> Editorially, I like the straightforward version, if you don't mind.

Author's choice as far as I'm concerned.

>
> > 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.
>
> That part says "to compromise between packet size and uniqueness - refer
> to Section 6.1". So, I think if one does not care about the packet size, he
> can use longer bits.
>
> It also says "the least significant 96 bits are used to generate an identifier".
To resolve this, we're first going to need to clarify the language here.
"Are" needs to be changed to SHOULD or SHALL. This language problem exists
in the other two bullet points in section 4.2. If we choose SHOULD, that
gives implementations leeway to use longer (or shorter) per-session CNAMES
and I will rethdraw my comment. I had been reading "are" and "is" in these
paragraphs as SHALL. Do you think the draft intended SHOULD or SHALL for
these requirements?

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 9 Mar 2013 09:52:00 +0000

On Mar 8, 2013, at 7:34 PM, Kevin Gross <[email-masked]> wrote:

> On Fri, Mar 8, 2013 at 3:17 PM, Ali C. Begen (abegen) <[email-masked]> wrote:
> 
> It also says "the least significant 96 bits are used to generate an identifier". To resolve this, we're first going to need to clarify the language here. "Are" needs to be changed to SHOULD or SHALL. This language problem exists in the other two bullet points in section 4.2. If we choose SHOULD, that gives implementations leeway to use longer (or shorter) per-session CNAMES and I will rethdraw my comment. I had been reading "are" and "is" in these paragraphs as SHALL. Do you think the draft intended SHOULD or SHALL for these requirements?

OK, I see your point. SHOULD should address your concern and I am ok to change it that way. I will make these changes once the submission is open.

Thanks.
-acbegen