Subject: Re: The state of IPv6 multihoming development

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Nov 2002 18:11:23 +0100 (CET)

> The host stack would then, underneath TCP or UDP, look
> at these two bits.  If the bits indicate a normal IPv6
> address, nothing would happen and the host would work
> just like today.  On the other hand, if the bits indicate
> HIP, the host would select an IP address from the addresses
> currently available for the given host, and replace the
> key hash with the address.  The recipient would then make
> the reverse, thereby preserving transport layer checksums.

Pekka,

In a scheme like this it sounds like something under the API needs to
do some form of lookup in order to establish the mapping from the host
identity to a set of IP destination addresses.
Any thinking on how this lookup/mapping would occur?

BTW: I'm interested in looking at your HIP paper.

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 08 Nov 2002 22:41:36 +0200

Erik,

> Any thinking on how this lookup/mapping would occur?

In our current prototype the kernel maintains an ID -> address
mapping table.  If it encounters an ID that it has no mapping for,
it queues the packet in a queue of length 1, and sends the ID to
a user level daemon for resolution.  The current prototype daemon
reads the mapping from a configuration file.  This is clearly
unacceptable for real life.

My *current* idea of the right way of doing that is to
hack the resolver library.  That is, whenever the application
asks for AAAA records (e.g. through getaddrinfo), the resolver
asks for both AAAA records and KEY records.  If it gets any
HIP key(s), it returns the corresponding HIT(s) as the first
entri(es) in the address list, and the real addresses after them.
Additionally, it pushes the HIT->AAAA mapping(s) to the kernel.
The kernel maintains a status of the addresses and marks
one usable only after an ID verifying RR has been performed
on it.  Exact details to be worked out, but you get the idea.

> BTW: I'm interested in looking at your HIP paper.

Sent off-line.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Nov 2002 17:32:50 +0100 (CET)

> on it.  Exact details to be worked out, but you get the idea.

Implementation details (like trust issues between the shared kernel and a
library) aside, I don't see how one can ensure that you can have
high connection rate servers without opening up a DoS hole.
For a low connection rate server the queue of one (or some rate limiting 
at a value larger than one) might make sense, but that doesn't
allow folks to build high-connection rate servers that do not want to
hard code a limit.

Carrying 2 locators and 2 identifiers in the connection establishment
seems like a way to avoid this performance vs. DoS morass.
Haven't though about UDP though.

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 13 Nov 2002 20:46:56 +0200

> high connection rate servers without opening up a DoS hole.

Why whould a server ever need to do such a lookup?  If a client doesn't
provide a working locator, it's the client's problem, not the servers.
Those servers that currently do a reverse DNS lookup on the first packet
also face the same DoS danger.  Today, it is actually better to reply
to a TCP SYN with a SYN ACK, deferring state creation to the forthcoming
ACK, and to do the reverse lookup at the ACK if really needed.

In other words, what I explained above concerns the client.

> seems like a way to avoid this performance vs. DoS morass.

Right.  Exactly what HIP does.

> Haven't though about UDP though.

If you have a request-reply term UDP transaction, you don't need real
mobility or multi-homing support.   You just retry if the reply doesn't
come through, perhaps trying a different set of locators.  No performance
penalty, but no security or multiple address support.

If you have a longer term UDP service, such as NFS, you can create the
ID -> locator mapping state, and use it just like with TCP.  The benefit
of having it below the transport is that you can share the same state
with all TCP and UDP (and SCTP) sockets.  Plus in the case of HIP you
get the (relative) security there, too.

--Pekka Nikander