Re: Multihoming by IP Layer Address Rewriting (MILAR)

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

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. Much of what you have suggested about processing incoming packets is
also dealt with in my proposal.

The most difficult task is knowing which addresses to choose first based on DNS
queries, 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.

I'm not sure that you have addressed these issues - I look forward to any new
ideas on this front.

Peter

On Mon, 3 Sep 2001, Iljitsch van Beijnum wrote:

> Before I write up a draft, let me run it by the list.
> 
> Considering that:
> 
> - using multiple address ranges is the only way disconnect the growth in
>   multihoming from the growth of the global routing table
> 
> - the transport layer is not the best place to implement multihoming:
>   the natural place is layer 3 and implementing it there also avoids large
>   amounts of API problems and higher layer changes
> 
> - multihoming should work in all stages of a connection, including setup
> 
> - tunnels are a Bad Thing: they waste bandwidth, hide the network topology
>   and current PMTU discovery standards and implementations easily break in
>   the presence of careless tunnel deployment
> 
> - a host implementation is a good: no need to change routers and
>   multihoming benefits trickle down all the way to the host, unlike
>   current IPv4 multihoming
> 
> - a router implementation is good: no need to change large numbers of
>   hosts
> 
> a multi-address multihoming system could work as follows:
> 
> Transport layer entities connect to a remote host in exactly the same way
> as they do now. However, in the mean time the network layer takes steps to
> discover alternative addresses for the destination address.
> 
> This can be done using the DNS ip6.int zone, a special ICMP message or
> some other means.
> 
> When the IP layer decides that the destination address is unreachable or
> performance is not what it should be (because it receives an ICMP
> unreachable, an ICMP TTL exceeded or a hint from the transport layer), it
> chooses one of the alternative addresses, and starts to rewrite the
> destination address for packets to the destination host.
> 
> Note that this happens for ALL packets to that host, the only exception
> being layer 4 sessions that have the new "I know about MILAR and I'll pick
> the destination address myself, thankyouverymuch" option in the layer 4 ->
> layer 3 interface enabled.
> 
> When the destination host receives a packet that is addressed to one of
> its alternative addresses, it restores the original destination address
> and delivers the packet to the transport layer. (So the TCP pseudo-header
> will again produce a valid TCP checksum, among other things.)
> 
> The rewriting and/or restoring of the destination address can also be
> performed by a router on behalf of a group of hosts.
> 
> There is a security problem: a host may think it's communicating with host
> with a certain IP address, while it is in fact communicating with a very
> different host, which is not the owner of the IP address in question nor
> reachable over it using regular routing. This breaks "security by looking
> at the IP address", but this was never very secure to begin with anyway.
> 
> Iljitsch van Beijnum
> 
> 
> 

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