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

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 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.