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

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Francis,

sorry for the delay

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

some answers below...

El 01/11/2004, a las 16:40, Francis Dupont escribió:

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

agree

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

great!
are you planning to make it public?

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

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.

>    So in draft-bagnulo-multi6dt-hba-00.txt the extension is in Hash2
>    (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

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

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

makes sense?

>  - the second point is about the Ext Type (TBD IANA): we have to 
> propose
>    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? :-)

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

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
mbagnulo@ing.uc3m.es is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------