Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR)

From: "Christian Huitema" <[email-masked]>
Date: Tue, 4 Sep 2001 13:07:47 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]]
> 
> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Sep 2001 22:23:38 +0200 (CEST)

> distributed hierarchical database. I don't think so.

The problem is that there is no clear "best" way to do multihoming in
IPv6. So router people want the hosts to solve it, layer 4 people want
layer 3 to solve it, and so on. Who will be the tiebreaker? Someone people
are bound to be unhappy, whatever we end up implementing.

> We start with the
> corresponding host only knows one of them.

For multi-address multihoming to work, we need to know more than one
address the time of session establishment. Preferably before setting up a
session, but certainly well before the setup times out. However,
traditional multiple A/AAAA records should suffice for this purpose.

Iljitsch van Beijnum

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 4 Sep 2001 13:26:34 -0700 (PDT)

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

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 4 Sep 2001 13:52:15 -0700 (PDT)

> traditional multiple A/AAAA records should suffice for this purpose.

I disagree. It is possible to build a  layer 3 solution using multiple
addresses that provides high availability semantics to each address, even
if that address is not directly reachable. My draft says how.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Sep 2001 22:53:37 +0200 (CEST)

On Tue, 4 Sep 2001, Ramakrishna Gummadi wrote:

> performance and security.

You've mentioned multicast problems before. Maybe I'm uninformed on the
subject, not having done any real multicasting, but I don't see the
problem.

Isn't multicast addressing and routing pretty much independent from
unicast addressing and routing? What are the problem areas?

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 4 Sep 2001 14:01:06 -0700 (PDT)

> unicast addressing and routing? What are the problem areas?

No, multicast trees are typically (PIM, etc.) built from corresponding
underlying unicast routing entries, which means that, for example, in
source-specific multicast, a client cannot
connect to a multicast tree using a different unicast source address than
the one the multihomed multicasting source is using.

Another problem is that, due to danger of "ack-implosion", it is typically
not possible to generate any path management messages (like what SCTP
does), and discovering source failures can take a long time.

Finally, multicast security (spoofing, DoS, etc.) is still very immature.

regards,
ramki

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Sep 2001 21:27:33 +0300 (EEST)

> Carroll, an unsuspecting third party. Carroll receives a DoS attack that

2) is a very difficult problem to solve at all.  As are many DoS problems.

Only way I can see this happening is that Bob here would have some
security checks in the implementation.

At the moment I see a couple of different approaches:

- checking the correlation of the last 80 bits of the IPv6 addresses.
This would limits the usability pretty much though, and still wouldn't be
foolproof.

- checking in the DNS/... that the new address "Carroll", _in turn_ also
mentions "Eve" as its secondary address; you have to keep the data in some
_external_ database, to avoid the DoS.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords