Re: Multihoming by IP Layer Address Rewriting (MILAR)

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

On Tue, 4 Sep 2001, Iljitsch van Beijnum wrote:

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

There is the chance that it can be made independent of the TCP session but
still tied to the sessions so that it may only need to be done once, and could
also work for other connection protocols. BTW, my current tcp proposal does
piggy back on the syn/ack so it's only just a little extra baggage.  It's more
expensive to send extra packets than to piggy back on an existing packet IMHO.

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

In my experience, it's much easier to misconfigure DNS.  There are a lot of
clueless admins out there who would not understand the implications of getting
it wrong.  Even I'm guilty of stuffing up DNS delegations and SOA's in recent
times :)

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

I start to get nervous whenever I hear about needing a secure channel to
exchange information.  If the system can operate without requiring rigorous
security, then it is one step more able to withstand a security attack than a
system that requires it.

> 
> 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 DNS should have the initial set for connecting end for starters anyway.  It
was my assumption that this was a prerequisite to all the current discussion.

It doesn't tell the other end what addresses you might be coming from though. 
That would require reverse DNS at the server end (assuming client/server type
connections) and can be a matter of policy for heavily loaded sites.  We do
reverse dns on all our web servers because they are not loaded heavily, but I
bet there are some heavily used sites which might not.  In my experience having
run web servers and also having written some too is that reverse DNS can
significantly reduce the performance of the server.

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

DNS will give roughly the same info, but may acquire it in a less efficient
manner.  Also current DNS has no mechanism for assigning address priorities.
not unless we invent a new RR to do it.

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

Depends if it's a passive or active approach to gather stats.  If it involves
extra traffic just for the sake of gathering statistics I don't think it will
be popular.  The passive approach would rely on traffic already taking place
which I had already hinted at requiring doing in my proposal.

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

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210