Subject: Re: [Int-area] Progress on draft-laganier-ipv6-khi-01.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 4 Jun 2006 18:36:02 +0300

El 04/06/2006, a las 18:02, Pekka Nikander escribió:

>>> In my personal opinion, having ORCHIDs that are considered secure 
>>> now and could be estimated to be secure for the next 20 years or so 
>>> might be about the right size.
>>
>> but in that case, you need to make ORCHIDs to support multiple hash 
>> functions, since i guess it is not that clear that we will stick to 
>> sha-1 for the next 20 years right?
>
> ORCHIDs do support multiple hash functions, through different 
> prefixes.  What comes to SHA-1, it is not clear whether it would last 
> for 20 years for the ORCHID purpose or not, but the same applies 
> pretty much to any other hash function.
>

agree
but this point imho affects the length of the prefix.
I mean one thing is to assign a single /8 prefix to all orchids and a 
different thing is to assign a separate /8 per hash function and that 
if we need to move from a given hash function we need to forget the 
used prefix and get a new one.

I mean, after all, it is a matter of bits. We need to encode different 
hash functions in ORCHIDs. The question is whether we encode them in 
the prefix or in the suffix part. My point is that this needs also to 
be taken into account when deciding what would be the prefix length. If 
we use a very short prefix for this version of ORCHIDs and in the 
future we need to change the hash function, then we will need another 
very short prefix to support the ORCHIDs for the new hash function.

I think that the amount of address space required for the orchids would 
be clearer if the hash function was encoded in the suffix rather than 
in the prefix.

one /8 versus one /8 per hash fucntion used may be an important 
difference (depending on how well the attaks on hash functions evolve)

Regards, marcelo

> --Pekka

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Geoff Huston <[email-masked]>
Date: Mon, 05 Jun 2006 11:07:59 +1000

Lets understand why we are having this discussion at all. While the draft 
indicates that these 'tokens' will never be used in ip-level unicast 
forwarding, there is a desire to use a token space drawn from the IP global 
unicast address space. If we ignore this for a second then yes, its quite 
reasonable to move on with a 128 bit orchid, and be done.

The point of compromise lies in the desire to use of the IPv6 global 
unicast address space. At this point a whole set of other considerations of 
address use come into play, best summarized by looking at the material at 
http://www.arin.net/meetings/minutes/ARIN_XV/PDF/wed/Round_Table.pdf

A related commentary  can be found at 
http://www.potaroo.net/ispcol/2005-07/ipv6size.html

So the question arises - what ipv6 global unicast prefix makes sense in 
terms of a compromise between maximising prefix length and not making 
'undue' demands on the pool of IPv6 global unicast addresses.

Geoff

At 01:36 AM 5/06/2006, marcelo bagnulo braun wrote:

>>>>In my personal opinion, having ORCHIDs that are considered secure now 
>>>>and could be estimated to be secure for the next 20 years or so might 
>>>>be about the right size.
>>>
>>prefixes.  What comes to SHA-1, it is not clear whether it would last for 
>>20 years for the ORCHID purpose or not, but the same applies pretty much 
>>to any other hash function.
>
>agree
>different thing is to assign a separate /8 per hash function and that if 
>we need to move from a given hash function we need to forget the used 
>prefix and get a new one.
>
>hash functions in ORCHIDs. The question is whether we encode them in the 
>prefix or in the suffix part. My point is that this needs also to be taken 
>into account when deciding what would be the prefix length. If we use a 
>very short prefix for this version of ORCHIDs and in the future we need to 
>change the hash function, then we will need another very short prefix to 
>support the ORCHIDs for the new hash function.
>
>I think that the amount of address space required for the orchids would be 
>clearer if the hash function was encoded in the suffix rather than in the 
>prefix.
>
>one /8 versus one /8 per hash fucntion used may be an important difference 
>(depending on how well the attaks on hash functions evolve)
>
>Regards, marcelo
>
>>--Pekka
>
>