Re: [Hipsec] ORCHID IANA allocation (was: 28 + 4 + 96 bit HIT crypto agility)

[Tobias Heer <[e-mail]>]

Hello Julien, Tom, and everyone else on the list, 

since the HIH/HIT/ORCHID discussion died, I'd like to revive it to come to a conclusion. I'll sum up some of the previous mails to make the information a bit more accessible.

Laganier, Julien wrote:

> Hello Tom,
> 
> Henderson, Thomas R wrote:
>> [...]
>> 
>> By the way, can someone who was involved in the ORCHID deliberations
>> chime in about the process for renewing the /28, and what are the
>> issues to make this a permanent allocation?
> 
[...]

> Since we're now discussing a HIT/ORCHID design that differs from the one originally documented in RFC 4843, updating RFC 4843 could 1) update the ORCHID design with hash agility, and 2) establish IETF consensus for a never ending ORCHID assignment in the relevant IANA registry.

I am still in favor of changing the ORCHID format to support hash agility instead of transmitting auxiliary information in the HIP headers or HIP parameters. Advantages are:

a) You'll never get a HIT for which you can't tell which algorithm was used (even if the auxiliary information is missing). This makes it more usable for referrals and legacy applications (also for non-legacy applications that still use the (legacy) socket interface) because these can continue to handle HITs like IPv6 addresses without special treatment.
b) It's far less complex than having an additional parameter in HIP for which you need rules when to transmit it (packet types) and where to put it (parameter number).
c) It's slightly more space efficient than having another field in the HIP header since there isn't terribly much space left in the header. Just adding 4 or 8 bits to the header would screw the alignment. Hence, even more bits would be needed as padding. There are 3 reserved bits but I guess one should try to keep them for future use - I think right now we are agile enough to actually make changes that break compatibility with older versions.

The main disadvantages are:
a) We'd have to change the way ORCHIDs are created because RFC 4843 is quite strict on the procedure.
b) We'd sacrifice some bits and would weaken the HIT against attacks.

Disadvantage b) can be mitigated by using a hash extension mechanism similar to the one in CGA (artificially making HIT generation more CPU intensive). RFC 4843 explicitly states that such mechanism should be considered for future versions of the ORCHID, so I guess there is no fundamental problem here. The only issue might be the IPR questions that were open at the time RFC 4843 was written (it was published in April 2007). I don't have any insight into this but I can investigate if people feel that this is the way to go.

I would like to ask for the opinion of the group regarding the redefinition/extension of the way ORCHIDS are created. Should this be done or should we try to live with one of the workarounds in order to add crypto agility to the HIT.

What would be the right procedure to get this going? Write a draft? If yes: who should/would do it?

BR, 

Tobias

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.cs.rwth-aachen.de/members/heer