Re: [Hipsec] ORCHID IANA allocation

Hi Tom, 

Am 24.02.2010 um 19:57 schrieb Henderson, Thomas R:
[...]

>> Would there be consensus to update ORCHIDs to v2 as follows:
>> 
>> - ORCHIDv2 structured as 28 + 4 + 96 bits
>> - 28 bits are new prefix for ORCHIDv2
>> - 4 bits encodes hash
>> - 96 bits are hashed string
>> 
>> Note that CGA's hash extension techniques (with Sec
>> parameter) have been updated with some hash agility support
>> in [RFC4982]; do we want to do something similar? Or do we
>> want to use standalone hash extension in the 96 bits, as in
>> the original CGA design [RFC3972]?
>> 
> 
> I support the above.  Regarding your question, I would recommend that we say for now that "4 bits encodes the hash string generation algorithm" because it may not simply be a hash algorithm but something like hash extension of CGA.
> 
You got a very good point here. I agree.

> Note that if we make ORCHIDs generic, the 4 bits must be shared among all the possible users in the future.  I don't think it is a big concern because the current use outside of HIP seems to be limited.
> 

I don't think that is a big concern. The ORCHID is designed in a way that the context ID is not visible from the ORCHID. Hence, all protocols that use ORCHIDS need checks whether a given ORCHID actually matches the current protocol context. As far as I can tell, this is done by simple trial and error: hash the public key and the context ID and see if it matches. Now, with the 4 additional bits, for a new (4+96 bit) ORCHID, the protocols that use the old ORCHID format check for the context ID again and the test would fail. In that case, the protocol would figure that it is an ORCHID of another protocol - no harm done... and no need to "share" the four bits. Am I missing something here?

> It would be nice to discuss and then state in one of the drafts (4843-bis, 4423-bis, or 5201-bis) what the consensus or options are for the following:

I tried to distribute your (good) questions to the three documents. I took the liberty to number the questions below.
I think question 3 would fit into 4843-bis nicely. There is already a short part on HITs and LSIs. One could easily extend this to go into ORCHIDS a bit more.
RFC4423 is only concerned with ORCHIDS and is almost HIP agnostic. I think that it should stay like that. Your questions 1 and 2 would be good here.
Do you want to discuss the answers to your questions on the list or are these meant as todo for the authors of the respective documents.

I can adjust the text in RFC5201-bis to match the new HIT format and the resulting changes in the BEX. Part of it was already done together with Bob anyway. I will post the result on the list. 

1.)
> - future allocations of new ORCHID prefixes?  Are there any conditions that would lead to asking for additional ORCHID prefixes, or do we expect only one such prefix?
2.)
> - what happens if the four bits runs out (do we deprecate old values such as in RFC4982?)
3.)
> - some discussion of the relationship between HITs, LSIs, ORCHIDs, and other quantities.
>  ** future extension of HIT size (256 bits has been raised in the past)-- is this possible or are we closing the door on such a future extension?.  More generally, does HIP allow for HITs that are not ORCHIDs?  (e.g. the old type-2 HITs, or more recent proposals for hierarchical HITs)  Do we use the bits in the HIP control field to identify HIT type?
>  ** possible use of RFC 3972 or 4982 CGAs as HITs (Marcelo and Jari have floated this idea in the past)
>  ** LSI prefix for IPv4  (recall we discussed a /16 in the 127/8 space-- do we also want to resolve this issue while we are resolving ORCHIDs?)
>  ** are LSIs possible for IPv6?  When would they be used instead of ORCHIDs?
> 

Tobias

> Tom
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer