Subject: [CGA-EXT] One more bit for hash information in CGAs? ( was [Fwd: [BEHAVE] Modified EUI-64 format]

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 06 Jul 2009 20:58:17 +0200

There is an ongoing discussion in BEHAVE ml, where it seems that we 
could use the "g" bit in order to include hash information...
considering that the hash length is one of the key limitations of CGAs, 
we may consider updating 3972 to use this bit...
comments?

I attach the extract of the thread below...

-------- Mensaje original --------
Asunto: 	[BEHAVE] Modified EUI-64 format
Fecha: 	Thu, 2 Jul 2009 04:06:21 +0000
De: 	Dave Thaler <[email-masked]>
Para: 	Xing Li <[email-masked]>
CC: 	Behave WG <[email-masked]>

Similarly, with privacy addresses referred to in the draft quote
at top, RFC 3041 section 3.2.1 point 3 forces the randomized
interface identifier to adhere to this requirement, so that it's
a 63-bit random number, not a 64-bit random number.  And with
CGAs, RFC 3972 section 4 point 6 similarly forces a generated
interface identifier to adhere to this requirement. (As an aside,
it also reserves the "g" bit which is actually unnecessary
since it's not IEEE EUI-64-derived.  RFC 4291 only discusses
the "g" bit for addresses derived from IEEE EUI-64's, which
is why RFC 3041 and a translation format can still use that bit).

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 06 Jul 2009 21:29:31 +0200

Dave Thaler escribió:
> I would agree with that, if 3972 is being updated anyway.
> I think CSI is not currently chartered to do so though.
>   

actually, we are

 From http://www.ietf.org/html.charters/csi-charter.html

- Update base specifications (RFC 3971 and 3972).
So far, though i haven0t seen much that needed to be changed in rfc3972, 
but this maybe be important

> -Dave
>
>   
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:[email-masked]]
>> Sent: Monday, July 06, 2009 11:58 AM
>> To: [email-masked]
>> Cc: Dave Thaler
>> Subject: One more bit for hash information in CGAs? ( was [Fwd:
>> [BEHAVE] Modified EUI-64 format]
>>

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 07 Jul 2009 08:37:25 +0800

Agreed. I think it is useful. Since the hash length is really limited, every
bit is cherish and important. One more bit means, in average, attackers have
to double their efforts in order to break the same CGA. This update suits
CSI charter well as we target to update SEND and CGA specifications from the
beginning of this CSI WG.

The only issue we need to solve is the complicite backwards compatibility.
Since we cannot indicate whether this is CGAv1 without g bit or CGAv2 with b
bit, we may have to fully abandon CGAv1 in the updating process. Personally,
I think it is fine through it requests all existing implementation changed.

Best regards,

Sheng

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
> Sent: Tuesday, July 07, 2009 2:58 AM
> To: [email-masked]
> Cc: Dave Thaler
> Subject: [CGA-EXT] One more bit for hash information in CGAs? 
> ( was [Fwd: [BEHAVE] Modified EUI-64 format]
> 
> There is an ongoing discussion in BEHAVE ml, where it seems 
> that we could use the "g" bit in order to include hash information...
> considering that the hash length is one of the key 
> limitations of CGAs, we may consider updating 3972 to use this bit...
> comments?
> 
> Similarly, with privacy addresses referred to in the draft 
> quote at top, RFC 3041 section 3.2.1 point 3 forces the 
> randomized interface identifier to adhere to this 
> requirement, so that it's a 63-bit random number, not a 
> 64-bit random number.  And with CGAs, RFC 3972 section 4 
> point 6 similarly forces a generated interface identifier to 
> adhere to this requirement. (As an aside, it also reserves 
> the "g" bit which is actually unnecessary since it's not IEEE 
> EUI-64-derived.  RFC 4291 only discusses the "g" bit for 
> addresses derived from IEEE EUI-64's, which is why RFC 3041 
> and a translation format can still use that bit).
> 
> 
> 
> _______________________________________________
> CGA-EXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Tony Cheneau <[email-masked]>
Date: Tue, 7 Jul 2009 11:07:12 +0200 (CEST)

Hello,

I agree too that it would be nice to extend the hash size, even for 1 bit. 
However, I am not sure that it should motivate a break in the backward 
compatibility. I mean, even if there is not wide deployment of SEND, 
other documents rely on the format of the CGA (HBA, RFC 5535 for example).

Maybe a change similar to RFC 4982 modifications could redefine the SEC
bits to indicate: number of bits for the hash2, the hash function and
the CGA version (indicating if "g" bit is used, and maybe more). Only
values 0 to 2 are currently used, leaving 5 values free to be assigned.

Regards,
 	Tony