Re: [Hipsec] The HIT prefix once again

Bob,

Do you want me to put up a slide or two on this at the end of the  
IPv6 WG tomorrow?  Or would it be better to have a more compelling  
draft (than the one by Francis) first?

Francis,

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; I didn't see any.  Alone I don't see how you draft would make a  
compelling case.

However, going more to the technical level, we may want to share the  
exactly same name space.

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.  It also looks like that we can  
use the exactly same 'encode' and 'hash' functions, as the  
requirements for them are the same.  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?

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.

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.

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.

--Pekka

_______________________________________________
Hipsec mailing list
Hipsec@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec