Subject: Re: [Hipsec] The HIT prefix once again

From: Pekka Nikander <[email-masked]>
Date: Mon, 1 Aug 2005 15:52:43 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Francis Dupont <[email-masked]>
Date: Mon, 01 Aug 2005 18:58:41 +0200

In your previous mail you wrote:

   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.

=> this was I've believed.

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

=> we can share the same space if it is always to recognize the case
from the context, something which seems to be true.

=> this should be part of the negociation. If it makes easier to get
a shorter prefix why not?

   

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

[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Mon, 01 Aug 2005 09:51:53 -0700

Pekka,

>draft (than the one by Francis) first?

I talked about it with Brian Haberman and we both think the agenda is 
already too tight and it might generate a long unfocused discussion.  We 
think it would be better to write the draft and then ask for comments and 
discussion.

Thanks,
Bob