Re: [Hipsec] The HIT prefix once again

Pekka,

At 06:52 AM 08/01/2005, Pekka Nikander wrote:
>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?

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

>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