Subject: Re: [Hipsec] Milestone status

From: Lars Eggert <[email-masked]>
Date: Mon, 07 Jun 2004 10:11:56 +0200

Hi,

Julien Laganier wrote:
> 
> A pre-version of the rendezvous draft is (finally ;) available at:
> 
> <http://julien.laganier.free.fr/pub/draft-eggert-hip-rendezvous-01pre1.txt>
> <http://julien.laganier.free.fr/pub/draft-eggert-hip-rendezvous-01pre1.html>
> 
> We would greatly appreciate any comments related to that draft.

I have not seen any discussion on this on the list yet. We'd really like 
to receive some initial feedback before the cutoff for San Diego.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Kristian Slavov <[email-masked]>
Date: Mon, 07 Jun 2004 12:25:03 +0300

> to receive some initial feedback before the cutoff for San Diego.

My plan is to implement few of the mentioned rendezvous mechanisms before the 
IETF meeting. I will try to give some feedback as the work progresses. The other 
HUT/HIIT hippies could probably do a private demo at the meeting (I will not 
attend).

Question:
Section 7.4: Assuming that the Responder will not create state before receiving 
I2, then why the Initiator sends the EREP1 and EREP2 in I2? The respnoder has no 
means to verify that the response matches the request. The only entity that can 
verify the responses is the RVS, but it is not contacted anymore.

-- 
Kristian Slavov, Researcher
Helsinki Institute for Information Technology
Gsm: +358-40-7220960
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Julien Laganier <[email-masked]>
Date: Mon, 07 Jun 2004 11:53:41 +0200

On Monday 07 June 2004 11:25, Kristian Slavov wrote:
>
> Question:
> Section 7.4: Assuming that the Responder will not create state
> before receiving I2, then why the Initiator sends the EREP1 and
> EREP2 in I2? 
>
> The respnoder has no means to verify that the response 
> matches the request. The only entity that can verify the responses
> is the RVS, but it is not contacted anymore.

Hi Kristian,

When the initiator gets an R1 w/ EREQ, it answers blindly with an I2 
w/EREP, because there's no way by which an initiator can distinguish 
between EREQ added by a Responder or a RVS. 

If this EREQ was added by the Responder, then this responder will get 
the corresponding subsequent EREP validating I2; it's fine....

If this EREQ was added by the RVS and the I2 doesn't pass via the RVS, 
then this EREP is useless, but the Initiator doesn't know that....

Hope I'm answering the good question ;)

--julien

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 08 Jun 2004 19:46:39 +0300

Lars, Julien,

I have noticed that your draft uses the boilerplate that keeps the IETF 
from creating derivative work:

"This document may not be modified, and derivative works of
    it may not be created, except to publish it as an RFC and to
    translate it into languages other than English."

Could you please explain why did you decide to do so?

Thanks,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: [email-masked]
Date: Wed, 9 Jun 2004 09:30:54 +0200 (CEST)

> Could you please explain why did you decide to do so?

This is probably left over from my initial draft submission - I always
use "no derivative works" by default. I see no issue in relaxing this
restriction for this particular draft. Julien?

Lars

---

From: Julien Laganier <[email-masked]>
Date: Wed, 09 Jun 2004 11:22:40 +0200

On Wednesday 09 June 2004 09:30, [email-masked] wrote:
> This is probably left over from my initial draft submission - I
> always use "no derivative works" by default. I see no issue in
> relaxing this restriction for this particular draft. Julien?

Fine with me too.

--julien

---

From: Miika Komu <[email-masked]>
Date: Wed, 16 Jun 2004 14:16:49 +0300 (EEST)

The DNS draft does not explicitly mention about the relationship between a
HI and the associated locators, or perphaps I just missed it. The RR
records corresponding to an FQDN are "flat" and it is impossible to
associate a specific HI to a spefic locator. The ascii graphics below
hopefully illustrate my point:

     +---- FQDN ---+----+               FQDN
    /    /   \      \    \              /  \
  HI1   HI2   IP1    IP2  IP3          HI1  HI2
                                       / \    \
                                     IP1 IP2  IP3

In the left, the "flatness" of the RRs is shown. Implicitly, each HI is
associated with all of the locators. One the right, the "ideal"
association tree is shown, where it is possible to associate a specific HI
with only certain IP addresses.

Maybe this should be mentioned in the draft explicitly?

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

---

From: Miika Komu <[email-masked]>
Date: Wed, 16 Jun 2004 11:50:05 +0300 (EEST)

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-00pre1.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!

---

From: Julien Laganier <[email-masked]>
Date: Mon, 21 Jun 2004 10:56:34 +0200

On Wednesday 16 June 2004 10:50, Miika Komu wrote:
>
> 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.

Yes it was intentionnal, because I believe some folks are working on a 
DHT-based lookup on HIs.

> - 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.

Perhaps adding the following sentence: "Note that, storing HIP RR 
informations in the DNS at a FQDN which is assigned to a non-HIP 
node, might have very bad effects on its reachability by HIP nodes"

> - text coming up in the next version?

Yes.

> Other than that, good work!

Thanks!

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 21 Jun 2004 10:57:45 +0200

On Wednesday 16 June 2004 13:16, Miika Komu wrote:
> The DNS draft does not explicitly mention about the relationship
> between a HI and the associated locators, or perphaps I just missed
> it. The RR records corresponding to an FQDN are "flat" and it is
> impossible to associate a specific HI to a spefic locator. The
> ascii graphics below hopefully illustrate my point:
>
> In the left, the "flatness" of the RRs is shown. Implicitly, each
> HI is associated with all of the locators. One the right, the
> "ideal" association tree is shown, where it is possible to
> associate a specific HI with only certain IP addresses.

I like the 'ideal' model, because it might be very useful for doing 
load balancing on a single FQDN which map to multiple hosts, with 
their own HI, and their own set of IP addresses. 

> Maybe this should be mentioned in the draft explicitly?

True, but at the time I wrote I wasn't able to design something good 
enough allowing the 'ideal' model, so I choose to keep this question 
out of the draft for the time being....

About the ideal model, where a HI has a certain pool of IP addresses, 
this means that, either:

o you are able to resolve an HI into a set of IP address, but at this 
time we don't have yet a proper way to implement this lookup (DHT 
might be one solution)

o you store IP addresses in the DNS within a new HIP RR, said HIPLOC, 
along with either the HI or an index to it (or perhaps the HIT), 
allowing to map between several HI and  IP addresses. 

At this point I'm not sure which of the options above makes the most 
sense. Perhaps other HIPpies have an opinion on that topic?

Thanks,

--julien

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 21 Jun 2004 11:55:51 +0200

Thanks, Julien, for a very nice first version.

Some specific comments, in no particular order:

>  The Host Identity  Protocol[10] allows two HIP nodes to establish two 
> pairs of bidirectional IPsec Security Association.

The above statement is not quite right.  IPsec SAs are always
unidirectional.  And there aren't two pairs of them, just one
pair of them.  Hence, please reword.

>  Hence the desire
-> Hence, there is a desire
(otherwise it would be an incomplete sentence)

> it first needs to perform an HIP base exchange to  set-up a HIP 
> association between themselves.

s/between themselves/towards its peer/   or something like that.
Currently it is not clear what is "them".

>  There are two types of HITs.

-> There are _currently_ two types of HITs defined.

I agree with Hannu's and others' comments on the HIT format
on Section 4.1, and I am looking forward on alternatives.
On thing that we may need to do is to separate the format
of HITs are used in the protocol and the format of HITs
used in the legacy IPv6 API.

I am unsure about the language "SHOULD be able to store",
and its meaning.  Usually RFC2119 terms are used to
define protocol practices, not operational practices.

Section 5.1.1:

> 1 A 128-bit HAA is present
Seems like there is a bug or two in the above.

--Pekka

---

From: Miika Komu <[email-masked]>
Date: Mon, 21 Jun 2004 13:08:34 +0300 (EEST)

On Mon, 21 Jun 2004, Julien Laganier wrote:

> > ...

Ok.

---

From: Miika Komu <[email-masked]>
Date: Mon, 21 Jun 2004 13:29:38 +0300 (EEST)

> sense. Perhaps other HIPpies have an opinion on that topic?

IMHO, the DHT approach is more elegant than the HIPLOC. Still, the HIPLOC
seems more practical because we don't know if we will ever have the DHT
stuff anyway.

---

From: Julien Laganier <[email-masked]>
Date: Mon, 21 Jun 2004 17:11:16 +0200

Hi Pekka,

On Monday 21 June 2004 11:55, Pekka Nikander wrote:
> >  The Host Identity  Protocol[10] allows two HIP nodes to
> > establish two pairs of bidirectional IPsec Security Association.
>

Ok, I was counting on the two hosts... :)

Ok.

> used in the legacy IPv6 API.

I'll try to insert a little summary of the discussion on this topic, 
as well as alternatives to the current situation. 

BTW, I agree that we might need to differentiate between HITs (those 
used in the protocol) and HITs representation (used in legacy API), 
but in the meanti 

Ok.

> Seems like there is a bug or two in the above.

Right, also the public key RDATA is missing. I'll fix these bugs 
before submitting.

> --Pekka

Thanks for the comments,

--julien