Subject: [Hipsec] Milestone status

From: [email-masked] ([email-masked])
Date: Fri Jun 18 08:52:00 2004

Hello Julien

I also read the draft. I have one question that might have an obvious answer, but it is not explicit in the draft.

Why is it that the section 4.1 "Different types of HITs" defines the HITs based on IPv6 addressing (i.e. to avoid the most commonly occurring IPv6 addresses). Is it because of the transition period mentioned in 4.2 only? Or is there some more fundamental reason?
What ever the reason could be it would be nice to have mentioned it.

- Hannu

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Miika Komu
> Sent: 16 June, 2004 11:50
> To: Julien Laganier
> Cc: [email-masked]
> Subject: Re: [Hipsec] Milestone status
> 
> 
> On Wed, 19 May 2004, Julien Laganier wrote:
> 
> > Last but not least, a preliminary version of the DNS draft is
> > available at:
> >
> > 
> <http://julien.laganier.free.fr/pub/draft-nikander-hip-dns-00pre1.txt>
> > 
> <http://julien.laganier.free.fr/pub/draft-nikander-hip-dns-00p
re1.html>
>
> We welcome any comments on this proposal. Note that, however, as I'll
> be in vacation until June, 1st, I won't be able to process comments
> until then.

1 Intro
- Perhaps it could be explicitly mentioned that (non-HAA) HITs and HIs
  without the FQDN cannot be resolved to anything for the time being. Or
  maybe you want to leave some space here.

3 Usage Scenarios
- may prevent him -> may prevent it
- A HIP responder use a Rendezvous Server -> uses
- Maybe something could be said about non-HIP nodes as well, such as
  "Non-HIP nodes should not use the HIP RR extensions for anything else
  than diagnostic purposes". Or maybe this just too obvious.

4.4 Providing multiple IP addresses
5.1.4 RDATA format public key
- text coming up in the next version?

Other than that, good work!

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: [email-masked] (Miika Komu)
Date: Sat Jun 19 04:17:01 2004

On Fri, 18 Jun 2004 [email-masked] wrote:

> Why is it that the section 4.1 "Different types of HITs" defines the
> HITs based on IPv6 addressing (i.e. to avoid the most commonly occurring
> IPv6 addresses). Is it because of the transition period mentioned in 4.2
> only?

One practical reason is related to the implementations. The "legacy HIP
API" for the applications is a kludge because the main concern in it is to
trigger HIP base exchange from the application layer. The HITs are
contained in sockaddr_in6 socket address structure in an application, with
the family set to AF_INET6 (at least in our implementation). The "HIP
module" catches these HITs that are disguised as IPv6 addresses and can
tell the difference between an IPv6 address and a HIT by the upper bits in
the address.

I am going to propose a cleaner alternative to this later this month. The
proposal includes a new family, PF_HIP, which dimishes the need for the
upper bits of HIT for comparing with IPv6 addresses.

---

From: [email-masked] (Julien Laganier)
Date: Mon Jun 21 04:45:01 2004

> Hello Julien

Hi Hannu,

> I also read the draft. I have one question that might have an
> obvious answer, but it is not explicit in the draft.
>
> Why is it that the section 4.1 "Different types of HITs" defines
> the HITs based on IPv6 addressing (i.e. to avoid the most commonly
> occurring IPv6 addresses). Is it because of the transition period
> mentioned in 4.2 only? Or is there some more fundamental reason?

The main reason, as Miika explained, is to be able to use the legacy 
IPv6 API (socket w/ AF_INET6) with HITs in place of IP addresses. 
That way it's easier to distinhuish between a HIT or an IPv6 address.

I can remember, also, that at some point there was both pure-HITs and 
IPv6-compatible HITs, the latter being basically the same with the 
two first bits rewritten to avoid commom IPv6 address... 

IMHO, the true question is, do we need more than 126 bits for fighting 
against collision attacks on HITs? If so, would 128 bits be 
sufficient?

AFAICT, 126 bits are enough, and it nicely allows to mix IPv6 
addresses and HITs in the APIs, so I would prefer sticking to 126...

> What ever the reason could be it would be nice to have mentioned

I'll add some text.

Thanks,

--julien