Subject: Re: about draft-bagnulo-multi6dt-hba-00.txt

From: Francis Dupont <[email-masked]>
Date: Mon, 01 Nov 2004 16:40:07 +0100

In your previous mail you wrote:

   > But there is at least
   > another interpretation... BTW the encoding gives only a static (i.e.,
   > easy to precompute : 0x 30 42 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 
   > 05 00
   > 03 31 00 <48 octets> but please check :-) prefix.

   ok, i will try to clearify this

=> note that I've checked this...
   
   > Finally I am not convinced a type tag is not required for HBA CGAs, 
   > i.e.,
   > today HBA CGAs are not more usable than CGAs...
   
   i am not following this, could you expand a bit?
   
=> the question was about type tags for HBAs... finally I believe we
don't need them, i.e., HBAs which are not CGAs have no use of type tags,
HBAs which are CGAs are covered by the CGA document
(draft-ietf-send-cga-06.txt).

> PS: I have an OpenSSL module for CGAs (with new/free/dup/d2i/i2d and
> check/sign/verify). I can send it to who'd like to extend it to HBA
> (I'm using the standard BSD licence). It should be easy because if I've
> understood the design the multi-prefix extension is an extension field?

   we are planning to implement HBA, so this would be really helpful.
   I will contact you later.
   
=> I had some free time in this long weekend so I wrote the code and
now I have some new comments:
 - draft-ietf-send-cga-06.txt is not clear enough about where the extension
   fields are included in the hash (here the multi-prefix extension) :

   ... Note that the hash values are computed over
   the entire CGA Parameters data structure, including any unrecognized
   extension fields.

   but:

   2.  Concatenate from left to right the modifier, 9 zero octets, and
       the encoded public key. Execute the SHA-1 algorithm on the
       concatenation. Take the 112 leftmost bits of the SHA-1 hash
       value. The result is Hash2.

   and:

   5.  Concatenate from left to right the final modifier value, the
       subnet prefix, the collision count and the encoded public key.
       Execute the SHA-1 algorithm on the concatenation. Take the 64
       leftmost bits of the SHA-1 hash value. The result is Hash1.

   So in draft-bagnulo-multi6dt-hba-00.txt the extension is in Hash2
   (good decision) but not in Hash1 (does it matter?):

   3.  Concatenate from left to right the Modifier, 9 zero octets, the
      encoded public key or the encoded Extended Modifier (if no public
      key was provided) and the Multi-Prefix Extension.  Execute the
      SHA-1 algorithm on the concatenation.  Take the 112 leftmost bits
      of the SHA-1 hash value.  The result is Hash2.

   and:

      6.1.  Concatenate from left to right the final modifier value,
         Prefix[i], the collision count, the encoded public key or the
         encoded Extended Modifier (if no public key was provided).
         Execute the SHA-1 algorithm on the concatenation.  Take the 64
         leftmost bits of the SHA-1 hash value.  The result is Hash1[i].

   Please fix this with Tuomas!

 - the second point is about the Ext Type (TBD IANA): we have to propose
   a common value in order to get interoperability (and examples :-).

 - the last point is about the collision count: I believe it should be
   per HBA not global as described:

   5.  Set the 8-bit collision count to zero.

   6.  For i=1 to n do

   ...

      6.4.  Perform duplicate address detection if required.  If an
         address collision is detected, increment the collision count by
         one and go back to step (6).  However, after three collisions,
         stop and report the error.

   I propose to put the 5 in the first step of 6 and go back to the next
   step (currently 6.1 but it should become 6.2)  when DAD fails.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 3 Nov 2004 15:59:32 +0100

Hi Francis,

sorry for the delay

thanks for these new comments, they are very much appreciated.

some answers below...

> (draft-ietf-send-cga-06.txt).

agree

> => I had some free time in this long weekend so I wrote the code

great!
are you planning to make it public?

>  and

Well, as i read it, the new extensions should be included both in the 
cga generation and verification, only that since at this point there 
are no extension specified, the algorithm presented in the spec doesn't 
explicitely include them.

>    (good decision) but not in Hash1 (does it matter?):

well, this is my mistake, thanks for catching it
The multiprefix extension should be included both in the generation and 
the verification of HAsh1
i will fix this in the next version

>    Please fix this with Tuomas!

AFAIU, the multiprefix extension should be included both in the 
generation and verification of Hash1 and Hash2

makes sense?

>    a common value in order to get interoperability (and examples :-).

Ok, would you propose a value that you like? ( i mean what did you use 
in your implementation? :-)

>    step (currently 6.1 but it should become 6.2)  when DAD fails.

I can see that there is an advantage in making the collision count per 
HBA as you suggest, since in the case that DAD fails, then you only 
need to regenerate a single HBA and not the whole set.
However, i can see some disadvantages when using the HBAs for multi6 if 
we do this. (Note that the following argument is assuming a specific 
usage of HBAs in the multi6 protocol, which may not be the case at the 
end, so it may well not apply)
My point is that if the collision count is per HBA, then the 
differences between the CGA Parameter Data Structure (hereafter 
CGA_PDS) of the different HBas of the HBA set will be increased. I 
mean, if the collision count is global, then the only difference 
between the CGA_PDS of the different HBAs of an HBA set is the prefix 
included in the subnet prefix field, and considering that the prefix is 
included in the HBa itself, it is not a big deal.
However, if the collision count is per HBA, then the difference between 
the different CGA_PDS of the different HBAs of an HBA set will be the 
subnet prefix and maybe the collision count.
Now, why does this matter?
Because this means that the different values of the collision count 
that correspond to each CGA_PDS of each HBA of the HBA set will need to 
the transmitted to the other end, so that the receiver can generate all 
the different CGA_PDSs
I mean, if the collision count are global, then one CGA_PDS contains 
all the information of all the CGA_PDS of all the HBAs of the HBA set. 
If we use per HBA collision counts, then, the last statement is no 
longer true, and we will need to transmit such additional collsion 
count information.

Now, in any case, the probability of collision is low, so i don't think 
that any option would pose any problems, just that i feel that the 
global option would result in a simpler multi6 protocol

Regards, marcelo

------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 04 Nov 2004 16:18:03 +0100

great!
   
=> yes but I don't know how (i.e., where).

   
=> so the text (in draft-ietf-send-cga-06.txt) should be clarified to
explicitely include them...

   
=> well.

=> this is only a problem in specifications (all everywhere should
say the same thing, here that all extensions are included).

   
=> I use 0x12 but it can be easily changed (I have only to fix the define
and to recompute the example in the test).

=> yes, this is the issue... and with a common collision count I have
to add a new function to compute explicitely the addresses (today it
is done by an optional side-effect per HBA). This doesn't really matter
but the point needs (needed) to be clarified.

Thanks

[email-masked]