Re: [Hipsec] The HIT prefix once again

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

   I finally had time to read your draft, http://www.ietf.org/internet- 
   drafts/draft-dupont-ipv6-cgpref-01.txt   I think you need to have  
   reference to a document that defines how GCIDs are supposed to be  
   used;

=> the I-D (submitted some weeks after the cgpref one by Gabriel, holidays
and deadlines...) is draft-dupont-mip6-privacyext-02.txt

   I didn't see any.  Alone I don't see how you draft would make a  
   compelling case.
   
=> there should be a reference to a HIP I-D too.

   However, going more to the technical level, we may want to share the  
   exactly same name space.
   
=> this was I've believed.

   AFAICT, the HITs and CBIDs are formed as follows:
   
       HIT = prefix | encode(hash(public key))
   
      CBID = prefix | encode(hash(any string))
   
   where, in both cases, there prefix defines the 'encode' and 'hash'  
   functions used.  In the HIT case the public key must be understood  
   from the context, and AFAICT in the CBID case the "any string" must  
   also be understood from the context.

=> the 'any string' is in fact PublicKey | imprint_128

   It also looks like that we can  
   use the exactly same 'encode' and 'hash' functions, as the  
   requirements for them are the same.

=> hash() is SHA-1 and encore() is to take the first 112 (128 - prefixlen)
first bits. But I agree, this doesn't matter.

   Initially, we would apparently  
   be just taking the low order bits of the hash as the encoding and use  
   SHA1 as the hash function.  Or do you have different requirements?
   
=> I've hear it is better to take first bits, at least this is true
for pseudo-random numbers...

   Now, based on that we could share the exactly same name space, i.e.,  
   just have a single prefix.  One potential complication is that it is  
   much easier to generate arbitrary strings than even short public  
   keys.  However, based on my strawperson analysis, that doesn't matter  
   since HIP, by default, expects the HIT to be a hash of a public key  
   and does not accept anything else.  Hence, the fact that arbitrary  
   strings are easier to generate that public keys doesn't matter.
   
=> we can share the same space if it is always to recognize the case
from the context, something which seems to be true.

   The biggest difference seems to be on our needs w.r.t the time frame  
   for the assignment.  I really think that a temporary assignment with  
   the default of the assignment going back by, say, 2009, would be  
   better.  In that way that space does not keep assigned if the  
   experimentation fails and it is not used.  On the other hand, if any  
   efforts using the space succeed and the space is being used, the  
   space is there and can be used.
   
=> this should be part of the negociation. If it makes easier to get
a shorter prefix why not?

   Hence, I think we can go for asking a single shared address space.   
   My proposal is to go for a proposal that says:
   
      Assign a /5 provisionally for this use, with the next 3 bits reserved
      for the case that the existing hash algorithm fails, resulting in
      /8 which is the only part that gets assigned at this time.
   
      If the IPv6 WG feels that assigning a /5 or /8 is too much, then we
      just need to live with that and live with the lower security level.
   
   As I said during the f2f meeting, I am planning to write a short  
   draft on this in the near future but would really appreciate help.
   
=> the cgpref I-D is very open but we should not try to defend it as
itself, just to defend the idea and to get an IPv6 WG item about it.

Thanks

[e-mail]

_______________________________________________
Hipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hipsec