[Hipsec-rg] HIT-to-IP mapping presentation follow-up

oleg.ponomarev at hiit.fi (Oleg Ponomarev) Thu, 26 March 2009 20:19 UTC

From: "oleg.ponomarev at hiit.fi"
Date: Thu, 26 Mar 2009 22:19:00 +0200
Subject: [Hipsec-rg] HIT-to-IP mapping presentation follow-up
Message-ID: <alpine.LFD.2.00.0903262218150.29600@stargazer.pc.infrahip.net>

---------- Forwarded message ----------
Date: Thu, 26 Mar 2009 22:09:09 +0200 (EET)
From: Oleg Ponomarev <oleg.ponomarev at hiit.fi>
To: dnsop at ietf.org
Subject: [DNSOP] HIT-to-IP mapping presentation follow-up

Greetings!

I gave a presentation at the WG meeting on using DNS for mapping Host 
Identifiers to IP addresses, but there was no time for any details or 
discussions.

The slides and the draft are avialable at 
http://www.ietf.org/proceedings/09mar/slides/dnsop-5.pdf and 
http://tools.ietf.org/html/draft-ponomarev-hip-hit2ip-03

I apreciate your feedback/questions and would like to post this follow-up to 
the list and answer some of them.


1) Olaf: Why use DNS for flat identifiers?

The Domain Name System is commonly deployed mapping system and existing 
recursive resolvers can cache the link to the second level, such as

8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.1.0.0.1.0.0.2.
                                            hit-to-ip.arpa.
      86400 IN      CNAME   8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.
                      4.3.2.1.0.1.0.0.1.0.0.2.hit-to-ip.domain.example.

and location information (A/AAAA) for static hosts (default TTL is 2, but for 
static hosts it may be much longer). Use of the DNS simplifies the deployment. 
It requires minimal effort from the network operator to start providing mapping 
service, i.e. only configuration change in the software well-known to them.


2) Can you use HIT for updates? IP addresses are not reliable for auth.

A HIT is created by taking a cryptographic hash over a Host Identifier (public 
key of an asymmetric key-pair). The HIT has an important security property that 
it is self-certifying and the server verifies that sender of the update had the 
corresponding private key, therefore no additional pre-configured keys are 
needed.


3) What is the hiprg opinion about reverse names? We have some discussions in 
DNSOP.

I can't speak on behalf of the group, but personally I prefer to see 
human-readable names instead of random hex sequences. They may be used for 
reputation purposes and access control in the legacy applications. When two HIP 
hosts comminucate only to each other, they may exchange their host names and 
resolve peer's HIT to its hostname locally. But 1) it's not implemented 2) it 
does not work, when there are intermediate hosts. We want to allow the HIP 
hosts to publish their hostnames.


4) Did you think of the operator's burden of managing all the HIT's?

Host Identities are self-generated keys, there is no hierarchical delegation or 
manual actions on the updates. If the host key is lost, its identity can't be 
used anyway.


5) Peter: Is there consensus in hiprg?

Two out of the three HIP implementations (with most users) support HIT->IP with 
OpenDHT. Our hit-to-ip interface is supported in HIPL implementation and we had 
much more positive experience. There is hit-to-ip.net for _experimental_ use.


I will be glad to receive any comments and answer any questions I possibly 
forgot.

-- 
Regards, Oleg.