[Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting

[[e-mail] (Henderson, Thomas R)]

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Friday, August 20, 2004 7:38 AM
> To: Miika Komu
> Cc: Henderson, Thomas R; Tim Shepard; Lars Eggert;
> [e-mail]; Andrew McGregor
> Subject: Re: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg
> meeting
>=20
>=20
>=20
>=20
> Miika Komu wrote:
>=20
> > On Thu, 19 Aug 2004, Joe Touch wrote:
> >=20
> >=20
> >>We already have a DNS which provides a global resolution=20
> structure. What
> >>is the gain in having a global ID space?
> >>
> >>Far as I can tell, you need the DNS (or a copy that's just as
> >>complicated and global) to give you the rendezvous points.=20
> If the dest
> >>IS the rendezvous point, you're done. Why bother putting=20
> the ID in the
> >>DNS and ensuring that it's global?
> >=20
> >=20
> > If you don't know the ID of the peer before connection=20
> establishment, it
> > is called "HIP opportunistic mode". A hostile host can DoS=20
> the peer and
> > pretend to be the peer for you.
> >=20
> > On the other hand, you can detect that another host has=20
> replaced the real
> > peer if you can first lookup the ID of the peer from the DNS.
>=20
> A hostile host can just lookup the host it wants to=20
> impersonate and use=20
> its HIP ID anyway.=20

Only the holder of the private key can properly sign the HIP messages.

>If you go to the DNS, presumably the entry=20
> there was=20
> signed - if you need to validate that the endpoint is who the=20
> DNS says=20
> it was, you MUST use the same signing authority as validation anyway;=20
> the HIP ID doesn't add any information.
>=20


It is possible to implement protocol extensions that have some HIP=20
properties without using a new global namespace.  TCP Migrate is a=20
good example based on FQDNs and DNSSEC.  But such solutions end up=20
overloading existing names and mechanisms, and don't have quite the=20
same security properties.  The HIP architecture draft has a=20
discussion of this. =20

The HIP RG is chartered to study whether the costs of deploying
HIP infrastructure are worth the benefits that HIP might bring.
So I think that this is a valid debate.  In particular, a new
resolution infrastructure will be expensive and complicated.
But we have heard concern not to load too many HIP-like=20
responsibilities onto DNS as well, and concern also about=20
HIP dependencies on DNS.

We should also consider that, even if HIP infrastructure were
to be built out, humans typically prefer to deal with FQDNs or=20
other human-readable names to name hosts, and therefore, we need=20
to still consider how bindings between such names=20
(aliases) and HI(T)s are secured in many usage scenarios. =20

Tom