Re: Multihoming by IP Layer Address Rewriting (MILAR)

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

On Tue, 4 Sep 2001, Peter Tattam wrote:

> > 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'm not worried about something you might have to do once every hour or
so: that may take a few packets. But these days many Web pages have more
than 20 pictures. That could mean 20 TCP sessions, each negotiating all
addresses all over again. That's not the best way to do it. But you could
cache this information, of course.

> > I think we should definately not rule out the DNS for this, unless we're
> > absolutely sure this will not work.

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

Sure it's easy to misconfigure the DNS. But it's easy to do a lot of
things wrong. We're not trying to build a Word clone, where pressing
random keys on the keybord has to result in the creation of a perfect
business letter.

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

Security is a hot topic, with just about every IP weakness known and
unknown to man being exploited today. We have to be sure the protocols we
come up with aren't easily fooled by someone falsifying header
information. But I agree with you: we shouldn't require all kinds of
strong crypto in simple protocols.

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

In my proposal: not really. The alternative addresses can't be listed as
valid A or AAAA records, since if these addresses can also receive regular
traffic, the destination host can't easily determine if the destination
address must be rewritten or not. On the other hand, if this is deemed
very desirable, it could be done at the cost of keeping extra state and/or
checking the TCP checksum with and without rewriting the destination
address.

The IP layer could discover the extra IP addresses through cooperation
with the resolver library, bypassing the regular DNS -> application -> TCP
-> IP path the destination address follows when creating application layer
sessions so the socket API doesn't have to change.

> It doesn't tell the other end what addresses you might be coming from though.

Good point. But this information could easily be carried in an IP option.

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

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

On hosts the passive approach would be appropriate. Changing to the next
address periodically and keeping a copy of the RTT values for each address
would probably do it. Maybe for routers that rewrite many sessions, the
overhead of sending some extra packets is worth it.

If we want to be really ambitious, we could come up with a TCP
implementation that could actively take advantage of having multiple
destination addresses. This TCP would load balance the traffic over the
different destination addresses, exploiting different bandwidth and delay
properties of the different paths.

Iljitsch