Subject: [Hipsec] Changing HIP DNS (rfc5205) to support the new crypto agility

From: Robert Moskowitz <[email-masked]>
Date: Tue, 08 Dec 2009 22:53:05 -0500

The following is from a series of notes Miika, Tobias, and I had from 
early August.

A HIP system will have multiple HIs to announce to the world, but it 
will have a preference
in their use. Plus it may have different HIs for some processes. And 
each of these HIs will be
subject to multiple Hashes for HIT generation.

The current DNS RR for HIs contains (per rfc 5205):

HIT length
PK length
HIT
PK
RVS list

I could never figure out why we have HIT length, it has been suggested 
that it is there just to make sure that we can easily scale to 256-bit 
HITs without changing DNS record format?

Anyway, this does not matter because we want to get rid of the HIT in 
the record anyway and replace it with a hash list.  It is required that 
the client can generate any HIT from the Hash list.

The current HIP definition supports at least 2 HIs, DSA and RSA based, 
but there is nothing in the DNS information to guide the Initiator in 
deciding which to use, it is assumed that the decision is strictly a 
local decision on the part of the Initator, following the HIP KISS 
principle. But with a potential for a lot more HIs, the Responder should 
be allowed to guide the Initiator in its preferences. To do this at 
first I as thinking of the MX model where the preference is indicated by 
its weight. Then I remembered that we have also discussed HIs associated 
with a process or port, and realized that the SRV model is the correct 
one. So we add two more fields to the RR:

HI preference (ie weight)
Port number (as in SRV)

So we end up with:

Weight
Port(s)
PK length
PK
HIT list
[RVS list]
Experienced DNS people will have to work out how this is structured.

There was also a proposal that we could store the complete LOCATOR 
parameter of the host in the DNS:

http://www.ietf.org/id/draft-ponomarev-hip-dns-locators-01.txt

As I think about this, I see DNS explosions as each HI has to tell how 
it is located. So we SHOULD provide a default RVS/Locator record that 
applies to all HIs. This can either be YARR, or you set weight, port and 
HIlength all to zero and have NULL PK and HITlist. Alternatively you 
could support different default RVS/Locator per port, where Weight and 
HIlength are zero, but not port.

Miika also suggested that the host MAY add its real IP addresses. No 
need to use RVS if you've got fixed public IP addresses.

I countered that you get that anyway from the A and/or AAAA records?

But Miika replied that A/AAAA records can't contain port numbers. It 
will be better for virtualization, object-to-object communications and 
NAT traversal to include the port numbers. Hence, he would suggest to 
switch to SRV records that include both HIT and locator information.

So what do you all think?  How would you structure the DNS information 
and what would the new HIP RR(s) look like?