Re: Multihoming by IP Layer Address Rewriting (MILAR)

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Tue, 4 Sep 2001, Peter Tattam wrote:

> The discovery of the alternative destination address is the crux of the problem
> and needs to be handled in such a manner as to prevent spoofing attacks.  IPsec
> is too heavy to deal with the issue - my lightwieght proposal of a SYN/ACK
> exchange like TCP works but is subject to address list explosion issues which I
> hope to resolve through sending compressed address trees instead of lists or
> sets.

Doing this in the SYN/ACK handshake has the disadvantage that you have to
do it over and over again for each TCP session. One popular application
comes to mind that uses many short lived TCP sessions...

I think we should definately not rule out the DNS for this, unless we're
absolutely sure this will not work. Yes, the domain name system has many
problem areas, but since it is already used for normal session setup,
(A/AAAA record), the exposure to these problems is already there and using
the DNS again will not do much, if any, additional harm.

And even if the DNS can't be trusted, it could still be a valuable source
of "hints" that can be validated through some more secure means later.

Another way that could work reasonably well is to use ICMP messages.
Incoming ICMP messages that claim to carry alternative addresses for some
host are highly suspect, but we can work around this by having the source
host first send an ICMP "what are your addresses" message, along with a
certain amount of reasonably random data. (A challenge, if you will.) The
destination host would then respond by echoing back the random data and
supplying the alternative addresses. This is safe if the data is
sufficiently random and the traffic is not intercepted, and there could be
options for "real" security.

The major drawback of ICMP or TCP solutions is that they can only work
when the first address is reachable at the beginning of the session.

> The most difficult task is knowing which addresses to choose first based on DNS
> queries,

You could check the addresses that come back from the DNS against the
routing table, but I suspect that won't help much to find the best route,
but would only help in avoiding a small set of failure modes.

> choosing alternative addresses when a failure occurs and knowing when
> to start choosing an alternative address.  We don't have much empirical
> experience with this and we are only guessing at the right way to do this.

One system could be to periodically cycle through all available addresses
and gather statistics for each. After a while, the system would know which
addresses are best. We could even come up with a scheme to share this
information with other hosts. Thinking about an implementation for my
proposal, I came to the conclusion that there would need to be some kind
of "address discovery daemon" because waiting for DNS replies in the
kernel wouldn't be a very good idea. Such a daemon could of course
communicate to other instances of itself on other hosts. This opens many
cans of worms for sure, and massive amounts of work need to be done to get
it right, but there are many interesting possibilities.

Simple failover schemes are in use today and/or are available as
experimental implementations and nothing suggests that "if A doesn't work,
we'll use B" isn't at least a huge improvement over "if A doesn't work,
we do nothing".

Iljitsch