RE: Multihoming by IP Layer Address Rewriting (MILAR)

[Ramakrishna Gummadi <ramki@cs.berkeley.edu>]

I first started writing a solution based on hip (host identity payload)
because hip addresses spoofing, hijacking, and DoS issues cleanly,
especially for "anonymous" connections, with a minimal external overhead.
But the main problem with this approach (as with any other host-based
approach) is that multicast becomes painfully difficult, both in terms of
performance and security. This is why I went back to a router-only
solution that preserves today's semantics for multihoming (draft available
at www.cs.berkeley.edu/~ramki/draft-ramki-multi6-nlmp-00.txt). I am going
to resurrect the host-only draft to see folks' response.

thanks,
ramki

On Tue, 4 Sep 2001, Christian Huitema wrote:

> > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
> >
> > On Tue, 4 Sep 2001, Christian Huitema wrote:
> >
> > > There is no dependency between connectivity and the DNS, and there
> > > should not be. A multi-homing solution that depends on the DNS is a
> > non
> > > starter.
> >
> > Are you saying that if there is a good way to implement multihoming
> > that requires a globally distributed hierarchical database system, we
> > should create a new one?
>
> Well, you should first prove that we actually need a globally
> distributed hierarchical database. I don't think so. We start with the
> assumption that hosts have multiple addresses, but that the
> corresponding host only knows one of them. The obvious solution is to
> have the peers use the address they know to learn the addresses they
> don't. Using a third party as a server is a tortuous way to solve the
> problem. There are indeed security issues, and we need to address them.
> So far, I see at least two security issues:
>
> 1) Spoofing. Alice speaks to Bob at address B; Eve somehow convinces
> Alice to send packets at address E.
>
> 2) DoS. Eve speaks to Bob, then convinces Bob to send packets to
> Carroll, an unsuspecting third party. Carroll receives a DoS attack that
> cannot be traced to Eve.
>
> Note that the server approach may solve spoofing, but does not solve the
> DoS attack -- Eve could just as well put Carroll's address in her server
> entry. Also note that there are many ways to solve spoofing.
>
> -- Christian Huitema
>
>
>