Subject: [Hipsec] General thoughts on ideas in draft-eggert-hip-rendezvous-00

From: [email-masked] (Kristian Slavov)
Date: Wed Feb 11 07:44:01 2004

Hi,

First of all, I think the draft presented the rendezvous server to be more like 
a non-HIP-to-HIP gateway/proxy. This part is ok. Even though not directly 
suggested by the draft, I don't the idea that the "main" HIP 
architecture/infrastructure should handle non-HIP <-> HIP communication.

The "default" rendezvous server, in my view, should be used solely for HIP 
purposes (i.e. not providing "legacy" support). I'd like to keep the base as 
simple as possible. We do not yet know, what are all the tasks the rendezvous 
servers will have to do. That is why we shouldn't overload them with 
functionality that is not essential for HIP.
We could, for example, have the rendezvous servers helping in reverse mapping 
the HITs etc.

The extensions are free to do more things (like providing non-HIP <-> HIP 
communication).

BR,
-- 
Kristian Slavov
Research Assistant
Helsinki Institute for Information Technology
Gsm: +358-40-7220960

---

From: [email-masked] (Lars Eggert)
Date: Wed Feb 11 12:05:01 2004

This is a cryptographically signed message in MIME format.

--------------ms040402030704020107030703
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Kristian,

thanks for the feedback!

Kristian Slavov wrote:
> 
> First of all, I think the draft presented the rendezvous server to be 
> more like a non-HIP-to-HIP gateway/proxy. This part is ok. Even though 
> not directly suggested by the draft, I don't the idea that the "main" 
> HIP architecture/infrastructure should handle non-HIP <-> HIP 
> communication.

The HIP architecture currently states that HIP nodes that use rendezvous 
servers will register the IP addresses of their rendezvous servers in 
the DNS, instead of their own. If they register these IP addresses in A 
records, non-HIP nodes will use the rendezvous servers' addresses to 
reach a HIP node. Thus, HIP-to-non-HIP communication will involve the 
rendezvous server due to this aspect of the current HIP architecure, not 
the proposed ID.

Tom Henderson suggested off-list that this can be avoided by using a 
different record type for rendezvous servers. The -00 ID does not 
currently discuss this alternative. Another option would be to use a 
separate lookup mechanism from the DNS (see below.)

> The "default" rendezvous server, in my view, should be used solely for 
> HIP purposes (i.e. not providing "legacy" support). I'd like to keep the 
> base as simple as possible. We do not yet know, what are all the tasks 
> the rendezvous servers will have to do. That is why we shouldn't 
> overload them with functionality that is not essential for HIP.

I agree that the basic (HIP-HIP) rendezvous mechanism should be kept 
simple. But for the HIP-HIP case there is little reason to even use the 
DNS to store the HI->IP mapping, other than immediate deployability and 
a somewhat reduced base exchange latency. A separate mechanism may offer 
better lookup/update characteristics and may not only keep HIP simple, 
but also the DNS.

I had assumed that one reason for using the DNS to hold the HI->IP 
information was compatibility with non-HIP nodes. If that is not the 
case, it may be useful to investigate non-DNS lookup mechanisms?

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

--------------ms040402030704020107030703
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040402030704020107030703--

---

From: [email-masked] (Mika Kousa)
Date: Wed Feb 11 13:33:00 2004

"4.1 Non-HIP Initiator to HIP Responder

When non-HIP node I starts communication with R, it performs a DNS lookup
on FQDN(R) and receives HI(R) and IP(RVS) in return. Since I does not
support HIP, it disregards the Host Identity HI(R) returned by the DNS
lookup. Instead, it sets up transport-layer connections using the IP
addresses IP(RVS) obtained from the DNS. The Rendezvous Server RVS must
then transparently relay the communication to one of R's current IP
addresses IP(R) in step #5."

Let's assume that I want to make a connection to R: for FQDN(R) I get an
IP address, say IP_RVS. Then I connect using this address IP_RVS, and RVS
relays these packets somehow to R. I understood this, but let's assume
that I want to connect directly to RVP (if I understood right the RVS is
just a host in a network as any other host): for FQDN(RVS) I get the same
IP address IP_RVS and then initiate a new connection to this address
IP_RVS.

What happens now ? How can RVP distinguish these two situations, whether
the second connection should for relayed to R or is this connection really
meant for RVP and therefor must not be relayed ?

4.2 HIP Initiator to Non-HIP Responder

In figure 5 "#4 IP(I)" should be "#4 IP(R)".

5. Rendezvous Broker

"When the non-HIP initiator I performs a DNS lookup in step #6"

Should this be "step #5" ?

On my opinion the draft was interesting and easy to read and understand.
It's a good point to start this discussion on rendezvous mechanisms.

-- 
   printk(KERN_ERR "happy meal: Transceiver BigMac ATTACK!");
      -- linux/drivers/net/sunhme.c

---

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Thu Feb 12 07:29:00 2004

From: "Mika Kousa" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 11, 2004 1:14 PM
Subject: Re: [Hipsec] General thoughts on ideas in
draft-eggert-hip-rendezvous-00

> meant for RVP and therefor must not be relayed ?

Don't we usually solve this problem using tunneling/double
encapsulation? Is there another way?

Spencer

---

From: [email-masked] (Lars Eggert)
Date: Thu Feb 12 07:52:01 2004

--------------ms020608080301070509070800
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

> meant for RVP and therefor must not be relayed ?

That is similar to identifying which HIP node an inbound packet is 
destined to. Section 4.3.3 discusses this. I will add this as an 
additional concern for the next revision.

> Should this be "step #5" ?

Will fix these as well.

Thanks,
Lars

--------------ms020608080301070509070800

--------------ms020608080301070509070800--

---

From: [email-masked] (Lars Eggert)
Date: Thu Feb 12 07:54:01 2004

--------------ms020407070500000006080703
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

> encapsulation? Is there another way?

Right. Section 5 discusses a solution based on tunneling.

Lars

--------------ms020407070500000006080703

--------------ms020407070500000006080703--

---

From: [email-masked] (Pekka Nikander)
Date: Thu Feb 12 09:15:01 2004

Lars,

>> more like a non-HIP-to-HIP gateway/proxy. This part is ok. Even 
>> though not directly suggested by the draft, I don't the idea that the 
>> "main" HIP architecture/infrastructure should handle non-HIP <-> HIP 
>> communication.
>
> The HIP architecture currently states that HIP nodes that use 
> rendezvous servers will register the IP addresses of their rendezvous 
> servers in the DNS, instead of their own. If they register these IP 
> addresses in A records, non-HIP nodes will use the rendezvous servers' 
> addresses to reach a HIP node. Thus, HIP-to-non-HIP communication will 
> involve the rendezvous server due to this aspect of the current HIP 
> architecure, not the proposed ID.

My understanding from the discussions that Dave and I had
with the ADs prior to the WG formation was that the WG
work should really focus on a minimal rendezvous server,
i.e. the baseline minimum needed to solve the double-jump
and fast movement problems.  That would probably be a HIP-only
I1-only forwarding rendezvous server, possibly with some very
small extensions.

The rest should be worked on at the RG side.

In HIP terminology (HIPnology?), the kind of HIP-to-non-HIP
server is often referred to as a "proxy".

> separate lookup mechanism from the DNS (see below.)

I like the idea of different RR.  Indeed, it makes
the potential HIP RR to resemble even more IPSECKEY,
as the RR could contain both the public key (HI) and
the address(es) of rendesvouz server(s).  Or maybe
two RR types, one for the HI and the other one for
rendezvous server address.

> simple. But for the HIP-HIP case there is little reason to even use 
> the DNS to store the HI->IP mapping, other than immediate 
> deployability and a somewhat reduced base exchange latency.  A 
> separate mechanism may offer better lookup/update characteristics and 
> may not only keep HIP simple, but also the DNS.

I don't quite understand what you are trying to say.  Could you
elaborate?

> case, it may be useful to investigate non-DNS lookup mechanisms?

Yes, it has been a goal that both HIP and non-HIP hosts
could contact HIP hosts using information from DNS.
On the other hand, it would certainly be useful to look
at non-DNS lookup mechanisms at the RG side.  I would
really encourage people to look at various DHT approaches
(e.g. i3), and think about deployment incentives and
scalability.

What comes to the present problem, a bootleg solution
is that HIP hosts list their HIP-only rendezvous server
as the lowest priority address in DNS (in DNS servers
that support that), making non-HIP hosts to try to
contact the other addresses first.  Alternatively, a
HIP-only rendezvous server could be configured in such
a way that it does not respond to non-HIP communications
at all.  In that case a non-HIP host would get a
timeout and try another address.

But I think that a separate RR type would probably
be better.

--Pekka

---

From: [email-masked] (Lars Eggert)
Date: Fri Feb 13 08:30:03 2004

--------------ms000102060504070304090300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Pekka,

> The rest should be worked on at the RG side.

thank you for this information. As mentioned in the submission email, I 
wasn't quite sure which group (WG or RG) this ID should be addressed to. 
  Splitting the work into rendezvous mechanisms in the manner you 
describe seems useful.

> rendezvous server address.

I agree that a using something other than an A record for the IP address 
of the (simple, initial) rendezvous service makes sense. At the very 
least, it doesn't paint us in a corner with respect to a design for HIP 
proxies, as overloading the A record can.

> I don't quite understand what you are trying to say.  Could you

I was trying to point out that different ways for finding the set of IP 
addresses associated with a HIP node may exist, other than the DNS. The 
DNS should continue to map names into Host Identities (otherwise IP 
stacks need to change too much), but resolving a Host Identity into a 
set of IP addresses may involve some new lookup service instead of the DNS.

Lars

--------------ms000102060504070304090300

--------------ms000102060504070304090300--